ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.11) Nov 29-Dec 1, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
olani- has joined #yocto
<paulg> rebuild the kernel from scratch every time. That is always the right solution.
<RP> paulg: and rust-native? ;-)
* RP quickly heads afk
<paulg> oh yeah. rust and java and nodejs
seninha has quit [Quit: Leaving]
PhoenixMage has quit [Ping timeout: 246 seconds]
PhoenixMage has joined #yocto
goliath has quit [Quit: SIGSEGV]
sakoman has quit [Quit: Leaving.]
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
eggman has quit [Quit: brb]
eggman has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
demirok has quit [Quit: Leaving.]
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter010067 has joined #yocto
Estrella__ has joined #yocto
Estrella_ has quit [Ping timeout: 268 seconds]
Estrella has quit [Ping timeout: 265 seconds]
Estrella has joined #yocto
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
<zeddii> I'm finally back. build broke. restarting again. and it is working on automake .. again. WTF.
<zeddii> and more concerning. all of my meta-virt go applications went boom.
camus has quit [Quit: camus]
camus has joined #yocto
sakoman has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
xmn has quit [Quit: xmn]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<zeddii> and package_qa tasks taking 20+ minutes.
<zeddii> something is seriously wrong. time to start rm -rf'ing and hoping.
Tokamak has joined #yocto
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
mark_ has quit [Quit: mark_]
schtobia has quit [Quit: Bye!]
thomasd13 has joined #yocto
schtobia has joined #yocto
olani- has quit [Ping timeout: 252 seconds]
alessioigor has joined #yocto
GNUmoon has quit [Ping timeout: 255 seconds]
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter010067 has joined #yocto
rob_w has joined #yocto
demirok has joined #yocto
Herrie|Laptop has joined #yocto
goliath has joined #yocto
GNUmoon has joined #yocto
Herrie|Laptop has quit [Ping timeout: 248 seconds]
Herrie|Laptop has joined #yocto
landgraf has quit [Remote host closed the connection]
<LetoThe2nd> yo dudX
landgraf has joined #yocto
goliath has quit [Quit: SIGSEGV]
d-fens has quit [Read error: Connection reset by peer]
d-fens has joined #yocto
frieder has joined #yocto
frieder has quit [Client Quit]
frieder has joined #yocto
jooli has joined #yocto
zpfvo has joined #yocto
jooli has quit [Client Quit]
mckoan|away is now known as mckoan
<mckoan> good morning
gho has joined #yocto
mvlad has joined #yocto
goliath has joined #yocto
bps2 has joined #yocto
alicef has quit [Quit: install gentoo]
alicef has joined #yocto
bps2 has quit [Ping timeout: 252 seconds]
<qschulz> o/
lamm1 has joined #yocto
* alessioigor waves all
leon-anavi has joined #yocto
azcraft has joined #yocto
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
justReddy is now known as justache
marek has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
Chris[m]1234567 has joined #yocto
dev1990 has joined #yocto
seninha has joined #yocto
florian has joined #yocto
zpfvo has joined #yocto
d-s-e has joined #yocto
manuel1985 has joined #yocto
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
camus has quit [Quit: camus]
Net147 has quit [Quit: Quit]
camus has joined #yocto
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<qschulz> ah shoot. I thought the RDEPENDS dependencies were built only when the package was requested by another dependency or an image, but that's not true is it?
<RP> qschulz: thanks to debian renaming, we have to build them
alessioigor has quit [Quit: alessioigor]
<qschulz> so the only way to avoid a big RDEPENDS dependency is to have a recipe per package :/
alessioigor has joined #yocto
<qschulz> the example here is a recipe with two packages, one I need, another I don't
<qschulz> the one I don't bring in python3-cryptography (so rust, llvm and co)
<qschulz> RP: is this a new thing or did I completely missed this fact?
<RP> qschulz: it has always been like this
<RP> qschulz: I don't like the situation but changing it would be very hard
<qschulz> RP: or packageconfig but that makes little sense since it would only impact rdepends and require bbappends or conf file changes for something that should be image-specific :/
<qschulz> RP: ok, TIL :)
<qschulz> RP: I suggest we remove .deb support, nobody uses that... right? /s
DvorkinDmitry has joined #yocto
jmiehe has joined #yocto
<RP> qschulz: it isn't deb support, it debian renaming. Even if you remove that, you still can't know which rdepends the package manager will follow at image build time
manuel1985 has quit [Ping timeout: 256 seconds]
<RP> Looks like something broke badly in the new uninative. I can guess what the rest of my day will be doing :(
jmiehe has quit [Quit: jmiehe]
starblue has quit [Ping timeout: 265 seconds]
<RP> abelloni: I confirmed the segfault bisects to the uninative upgrade
starblue has joined #yocto
<qschulz> RP: we need the debian renaming because of .deb packages no?
<RP> qschulz: no, something totally different
<RP> debian allows parallel install of libraries by non overlapping package names
<RP> we have debian package renaming through debian.bbclass
<qschulz> moto-timo: mmmm sad. Is there some configuration of patchwork or documentation on mail subject pattern matching so I can forward this to b4 maintainer, I'm pretty sure the project is interested in proper patchwork support
<RP> zeddii: are you running with a bitbake server timeout set?
* RP just noticed some very very weird and broken bitbake behaviour when debugging uninative
* RP wonders if he'll have to debug that first
<qschulz> RP: mmmm I thought it was the ".deb packages containing only one lib is renamed with the name of the lib" mechanism... i'm missing something but thanks for the pointers
<RP> qschulz: it applies to all package names, not just debian
<RP> qschulz: the concept is generically useful in theory
bps2 has joined #yocto
odra has joined #yocto
Granjow has joined #yocto
Herrie|Laptop has quit [Ping timeout: 246 seconds]
Herrie|Laptop has joined #yocto
florian_kc has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
<Granjow> One of my recipes requires /sbin/sh, but QA complains about missing RDEPENDS on it. How do I find out which recipe provides it, or what I can RDEPEND on for /sbin/sh?
<rburton> that should be /bin/sh
<rburton> there isn't a sh in sbin
zpfvo has joined #yocto
<RP> Found the bug. My parsing changes broke uninative
<RP> well, I think uninative is broken, my changes exposed the issue :/
<RP> what a pain to debug
* RP tries to remember where he was with the other issue
<rburton> RP: up there with "why is this thread causing an exception" which obviously goes away when gdb is involved
<rburton> *shakes fist at debuginfod*
<Granjow> rburton: Hm. nut uses it in several scripts. I'll check if I'm not configuring it correctly.
<RP> kanavin: it looks like the something between patchelf 0.14.5 and 0.17.0 breaks
<RP> kanavin: you, me and wang have touched it with upgrades
<rburton> Granjow: grep says only in the solaris and hpux scripts
<rburton> so don't install those
<rburton> RP: so working hunch is that debuginfods woes are because we're hitting it whilst it is still scanning the rpms. the warnings are threads colliding and the occasional fails are when it just hasn't finished sweeping yet. obviously super annoying to fix without a "sleep(60) #hope for the best"
<rburton> at least i can replicate the warnings on demand and sleeping makes them disappear
warthog9 has quit [Quit: Leaving]
warthog9 has joined #yocto
<DvorkinDmitry> I have a lot of warnings like WARNING: mc:tppg2:glib-2.0-1_2.62.6-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-el-gr, but it isn't a build dependency? [build-deps]
<DvorkinDmitry> how can I get rid of it?
amsobr has joined #yocto
<Granjow> rburton: Thanks! I'm trying really hard, but I cannot find out how to get rid of these :D I know this is not a Yocto issue anymore, but in case you know how off the cuff, could you give me a hint? The is --without-solaris-smf which does something else, and Makefile.am:307 looks like it thinks I'm on SunOS and it would not support “Linux” at all.
<JaMa> DvorkinDmitry: are you restricting GLIBC_GENERATE_LOCALES in your DISTRO? we have only en_US.UTF-8 and need to remove all these extra RDEPENDS from ptest packages e.g. latest addition https://github.com/shr-project/meta-webosose/commit/af22606d31b378c2bde5ba043f7545cd1051e076
<RP> rburton: can we know when it is done somehow?
<RP> rburton: that all at least seems to make sense
<DvorkinDmitry> JaMa, yes I've made:GLIBC_GENERATE_LOCALES = "en_US.UTF-8 zh_CN.UTF-8 ru_RU.UTF-8 zh_TW.UTF-8 es_ES.UTF-8 en_GB.UTF-8
<DvorkinDmitry> JaMa, how big the difference is if I'll not restrict locales generation?
<JaMa> DvorkinDmitry: or you can just restrict it to all the ones used in packages
amsobr has quit [Ping timeout: 260 seconds]
<JaMa> this should be relatively complete list https://paste.ubuntu.com/p/kvZJ2QXCDy/
d-s-e has quit [Ping timeout: 268 seconds]
bps2 has quit [Ping timeout: 246 seconds]
Herrie|Laptop has quit [Ping timeout: 260 seconds]
d-s-e has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
<landgraf> Is there a tool to convert spec to bb? Google gave me few results from 2013-2015 which are not in the project anymore and probably not up to date
davidinux has joined #yocto
marek has quit [Quit: Client closed]
<zeddii> RP: I used -k to try and get everything to build, even when my golang applications were blowing up. and it appears that at least everything that completed is not restarting to build now.
<zeddii> at least autotools are not trying to rebuild anymore :)
<rburton> landgraf: easier to just do it by hand
bps2 has joined #yocto
<RP> zeddii: I don't really know what happened there, seems very odd :/
<zeddii> I'll keep an eye on it, and have a better report next time. for now, I'm diving into go.
<landgraf> rburton: well. I'm planning to do this for ~200 spec files :)
sakoman has joined #yocto
<rburton> landgraf: you'll be rewriting them anyway
<RP> For anyone who cares, it is the patchelf patchelf: upgrade 0.15.0 -> 0.16.1 upgrade that breaks uninative
<landgraf> for sure I will. but better start from something semi-crafted
<rburton> landgraf: the tools you found likely still work, once you update them for new override syntax
<rburton> but, as someone who wrote the "generate spec file from bb" layer, it's a terrible idea
<landgraf> :-) and I understand why
Herrie|Laptop has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
<rburton> landgraf: i still have nightmares over https://git.yoctoproject.org/meta-translator/
<JaMa> depends on how different those 200 spec files are, e.g. superflore for ROS packages wasn't too terrible, because they had relatively strict way how to build stuff, so it was quite consistent across couple thousand packages
<landgraf> JaMa: I don't think it will be my case :-/ From the positive side most of this packages are in YP layers already and I may end up bbappending stuff which is missing
<JaMa> that's surely better quality than any translation from .spec
lamm1 has quit [Remote host closed the connection]
lamm1 has joined #yocto
Herrie|Laptop has quit [Ping timeout: 268 seconds]
amsobr has joined #yocto
<DvorkinDmitry> I have SRC_URI:append:class-target = ... how to make it arch-specific, i.e. add my machine name?
<rburton> DvorkinDmitry: another override
<rburton> :append:class-target:aarch64
<DvorkinDmitry> rburton, thanks!
Herrie|Laptop has joined #yocto
kscherer has joined #yocto
Granjow has quit [Quit: leaving]
<moto-timo> qschulz: I don’t know of any docs about what breaks patchwork or lore picking up a patch… just years of seeing it happen give a few tribal knowledge hints …
<moto-timo> qschulz: i for one would be interested in seeing a wiki/blog post about how you used b4…
<rburton> if lore misses a patch it's normally because it's huge and got moderated
<moto-timo> (I use it to grab patches)
<rburton> my b4 workflow is a mailer shortcut to copy the message id to the clipboard, and an alias bz='b4 shazam'. copy id, bz <paste> applies the thread i was looking at
<rburton> very lofi, works
<rburton> jonmason has something better involving scripts and pushes to CI
amsobr has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
<kanavin> RP: I see there's a patch to patchelf, do you still need help?
alessioigor has joined #yocto
<moto-timo> rburton: I know we have seen patchwork fail when certain characters were in the subject line… I don’t remember specifics.
d-s-e has quit [Ping timeout: 268 seconds]
<qschulz> moto-timo: git checkout master; b4 prep -n new-topic; git commit -sm; b4 prep --edit-cover; (b4 prep --auto-to-cc if u-boot or linux); b4 send --no-sign -o patches; git send-email patches/*
<qschulz> b4 prep --manual-reroll <message-id-from-lore> for a new version
<qschulz> b4 shazam --add-link --add-my-sob <lore URL> for cherry-picking a whole series from lore
<qschulz> I probably use b4 very badly, but that works good enough for me for now :)
<qschulz> (my main issue was how to keep track between versions of a patch series across rebases and everything)
<RP> kanavin: I hope this will fix it, will have to run wider tests again
<kanavin> RP: I'm around if needed
<qschulz> (b4 prep --compare-to 4 to compare current tree vs v4, with git range-diff. super nice too)
<qschulz> (don't merge the series, it's broken :( )
<moto-timo> qschulz: ah ok. But you should use ‘—set-prefixes’ to set e.g. (meta-python). Just like the create-pull-request script
yashraj466 has joined #yocto
<qschulz> moto-timo: b4 doesn't allow to have the pattern you expect, I have [PATCH meta-python] there
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<qschulz> and I used set-prefixes, or the manually added [meta-python] as prefix in the git commit title, same result
vladest has quit [Ping timeout: 272 seconds]
<moto-timo> You don’t need PATCH according to the docs, but I’ll play around with it
<qschulz> hence the question where patchwork documents how it picks up commits based on a pattern, so I can give this feeback :)
seninha has quit [Remote host closed the connection]
<moto-timo> This is new to me as well, and you caught my interest
<qschulz> moto-timo: can you share the patchwork URL?
<qschulz> moto-timo: https://patchwork.openembedded.org seems to have some issues right now so I'm not sure if it's the correct one?
<qschulz> seems fine?
<moto-timo> qschulz: I believe the YP was recently upgraded… to vanilla patchwork and not the fork of the fork
<moto-timo> qschulz: right, but at the time you first sent it I saw no sign of the patches… maybe that was just a cli issue on you side
<qschulz> moto-timo: It ended up in spam most likely, I had sent a mail with a From from my professional mail address while sending it from my personal mail server....
<qschulz> (I have a somewhat particular setup :) )
Herrie|Laptop has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Quit: Client closed]
Herrie|Laptop has joined #yocto
manuel1985 has joined #yocto
rob_w has quit [Quit: Leaving]
dev1990 has quit [Quit: Konversation terminated!]
demirok has quit [Quit: Leaving.]
prabhakarlad has joined #yocto
<RP> kanavin: thanks!
yashraj466 is now known as yssh
yssh has quit [Quit: Client closed]
yashraj466 has joined #yocto
yashraj466 has quit [Quit: Client closed]
yashraj466 has joined #yocto
Estrella_ has joined #yocto
Estrella has quit [Ping timeout: 260 seconds]
thomasd13 has quit [Ping timeout: 252 seconds]
Estrella__ has quit [Ping timeout: 272 seconds]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Estrella has joined #yocto
goliath has quit [Quit: SIGSEGV]
sirhcel[m] has joined #yocto
lamm1 has quit [Ping timeout: 252 seconds]
<vmeson> yocto engineering meeting topics? https://www.yoctoproject.org/public-virtual-meetings/
<vmeson> Add qemuppc64, and likely therefore drop qemumips64 ? What's the policy for qemu targets to support?
<vmeson> Build regulation: job server, PSI and all that.
dmoseley has joined #yocto
demirok has joined #yocto
<sirhcel[m]> Hello everyone! Is there a way of specifying a depenency not only to a package but a package built with a certain feature?
<sirhcel[m]> I was working on getting rauc and curl play nice again and it turned out that rauc relies on curl being built with [packageconfig _proxy_](https://git.yoctoproject.org/poky/tree/meta/recipes-support/curl/curl_7.82.0.bb?h=kirkstone&id=ebfc6bdba43761481676b4c9528463546c35dd33#n72) enabled. Rauc defines the dependency to curl again through its package config
<sirhcel[m]> Specifying this through `local.conf` gives the desired result but feels quirky to me. Is there a way of specifying such dependency from rauc's recipes?
<sirhcel[m]> [network](https://github.com/rauc/meta-rauc/blob/815e9130f9aee5c7e6f5c027a3102bc79ada9082/recipes-core/rauc/rauc.inc#L18). However, i did not manage to specify this through rauc's recipes (for example as `PACKAGECONFIG:pn-curl:append = " proxy").
amsobr has joined #yocto
<sirhcel[m]> * Hello everyone! Is there a way of specifying a depenency not only to a package but a package built with a certain feature?
<sirhcel[m]> I was working on getting rauc and curl play nice again and it turned out that rauc relies on curl being built with [packageconfig _proxy_](https://git.yoctoproject.org/poky/tree/meta/recipes-support/curl/curl_7.82.0.bb?h=kirkstone&id=ebfc6bdba43761481676b4c9528463546c35dd33#n72) enabled. Rauc defines the dependency to curl again through its package config
<sirhcel[m]> Specifying this through `local.conf` gives the desired result but feels quirky to me. Is there a way of specifying such dependency from rauc's recipes?
<sirhcel[m]> [_network_](https://github.com/rauc/meta-rauc/blob/815e9130f9aee5c7e6f5c027a3102bc79ada9082/recipes-core/rauc/rauc.inc#L18). However, i did not manage to specify this through rauc's recipes (for example as \`PACKAGECONFIG:pn-curl:append = " proxy"`).
<qschulz> sirhcel[m]: you cannot modify a recipe from another recipe
<shoragan[m]> sirhcel: RAUC shouldn't require proxy support in curl. Which error do you get if you build curl without proxy support?
<sirhcel[m]> qschulz: Alright, is `local.conf` or the bundle configuration the way to go then?
<qschulz> sirhcel[m]: bbappend for both recipes or the override you specified, in a configuration file
<qschulz> the configuration file could be distro, machine or local.conf
<sirhcel[m]> shoragan: Everything builds fine. But when attempting to to install a bundle on the target, confguring the curl session fails for [`CURLOPT_HTTPPROXYTUNNEL`](https://github.com/rauc/rauc/blob/a0974f4eda3dd0938587c2b5d6026f2cc45cc361/src/nbd.c#L443) and stops this update immediately.
<shoragan[m]> Ah, then we should handle that gracefully in RAUC.
<sirhcel[m]> qschulz: Thank you very much! I will try out using bbappend files.
<sirhcel[m]> Alright, then let's switch over to #rauc:matrix.org.
<rburton> kanavin: ERROR: core-image-sato-sdk-1.0-r0 do_rootfs: The postinstall intercept hook 'update_font_cache' failed, details in /home/pokybuild/yocto-worker/meta-clang/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato-sdk/1.0-r0/temp/log.do_rootfs <-- is that your doing with the qemu tune changes?
<sirhcel[m]> shoragan: Thank you very much!
manuel1985 has quit [Ping timeout: 255 seconds]
cambrian_invader has joined #yocto
yashraj466 has quit [Quit: Client closed]
prabhakarlad has joined #yocto
d-s-e has joined #yocto
<RP> rburton: is that not the tune issue on f36-ty-1 as it has the v2 processors?
<rburton> yeah i think so
seninha has joined #yocto
d-s-e has quit [Client Quit]
seninha has quit [Client Quit]
yashraj466 has joined #yocto
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter010067 has joined #yocto
seninha has joined #yocto
frieder has quit [Remote host closed the connection]
<rburton> oh i need to post that series don't it
DvorkinDmitry has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
vquicksilver has quit [Quit: WeeChat 3.6]
invalidopcode has quit [Read error: Connection reset by peer]
invalidopcode has joined #yocto
<moto-timo> khem: vmeson: this is the specific post that had some interesting summary of available hardware https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/message/QZ5WZ33D2NZXR4O447WD3ELV2BTC5VJY/
mckoan is now known as mckoan|away
florian_kc has quit [Ping timeout: 255 seconds]
florian has quit [Quit: Ex-Chat]
seninha has quit [Quit: Leaving]
seninha has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Read error: Connection reset by peer]
PhoenixMage has quit [Ping timeout: 255 seconds]
Guest8 has joined #yocto
PhoenixMage has joined #yocto
<RP> heh, upstream patchelf have merged the patch :)
<Guest8> Hello
<Guest8> Any idea why the file-native recipe throws an error like the one below
<Guest8> Running test: ../../git/tests/fit-map-data.testfile
<Guest8> | test: ERROR: result was (len 130)
<Guest8> | FIT Map data, unit id 65536, serial 3879446968, Sat May 31 11:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity)
<Guest8> | expected (len 131)
<Guest8> | FIT Map data, unit id 65536, serial 3879446968, Sat May 31 10:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity)
<Guest8> | ../../git/tests/fit-map-data.testfile: FIT Map data, unit id 65536, serial 3879446968, Sat May 31 11:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity)
<Guest8> Looking like some clock configuration in my system is causing this
PhoenixMage has quit [Ping timeout: 272 seconds]
PhoenixMage has joined #yocto
<moto-timo> RP: 🎉
olani- has joined #yocto
alessioigor has quit [Quit: alessioigor]
vquicksilver has joined #yocto
florian_kc has joined #yocto
leon-anavi has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 255 seconds]
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter010067 has joined #yocto
Herrie|Laptop has quit [Ping timeout: 255 seconds]
yashraj466 has quit [Quit: Ping timeout (120 seconds)]
Herrie|Laptop has joined #yocto
yashraj466 has joined #yocto
yashraj466 is now known as yssh
yssh has quit [Client Quit]
yashraj466 has joined #yocto
yashraj466 is now known as yssh
yssh has quit [Quit: Client closed]
yashraj466 has joined #yocto
yashraj466 has left #yocto [#yocto]
roussinm has quit [Quit: WeeChat 3.0]
roussinm has joined #yocto
florian_kc has joined #yocto
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
yssh has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
mvlad has quit [Remote host closed the connection]
florian_kc has joined #yocto
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
dmoseley has joined #yocto
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
dmoseley has joined #yocto
Herrie|Laptop has quit [Ping timeout: 248 seconds]
<kanavin> rburton, RP that is not likely, as usermode qemu is not using kvm
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<kanavin> it is emulating the assembly through the TCG, and so v3 code will run on v2 CPUs fine
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<kanavin> rburton, RP but it is possible that clang is generating v3 assembly that qemu's TCG chokes on
<kanavin> but then it should fail similarly everywhere
<kanavin> running [akanavin@fedora36-ty-1 build]$ bitbake core-image-sato-sdk
<kanavin> (with gcc) to confirm one or the other
<kanavin> yeah, with gcc it works: NOTE: Tasks Summary: Attempted 7536 tasks of which 7457 didn't need to be rerun and all succeeded.
<kanavin> failed on opensuse as well https://autobuilder.yoctoproject.org/typhoon/#/builders/142/builds/10 so it's not a v2 host issue, but rather clang generating something iffy
Guest8 has quit [Ping timeout: 265 seconds]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
yssh has quit [Quit: Client closed]
azcraft has quit [Remote host closed the connection]
dmoseley has quit [Ping timeout: 260 seconds]
dmoseley has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
dmoseley has quit [Ping timeout: 252 seconds]
dmoseley has joined #yocto
dmoseley has quit [Ping timeout: 272 seconds]
chap has joined #yocto
dmoseley has joined #yocto
amsobr has quit [Ping timeout: 260 seconds]
chap has quit [Quit: I laugh with many, but don't trust any.]
bps2 has quit [Ping timeout: 265 seconds]
<RP> JPEW: your code looks right to be btw now I've had a better chance to look at the issues
florian_kc has joined #yocto
xmn has joined #yocto
<JPEW> RP: :D
<RP> JPEW: I've sent an updated version of the patch. I'm pretty sure it wasn't one we would have run into with the current code but who knows what might happen in the future. I did have to add some timeout bits to it
<JPEW> Ya. Cool. Better to have it right now and not have to figure out why later
<JPEW> If your want a timeout on the 'with self.idle_cond' you can lock the semaphore instead (as long as it's the same one the condition variable is bound to)
<JPEW> with self.idle_cond is just short have so you don't have to know which mutex you need to lock
<RP> JPEW: so I could just replace that with with bb.utils.lock_timeout(self._idlefuncsLock) ?
<JPEW> Ya I think so
<RP> If we can, we should do that as it avoids deadlocks in theory
<JPEW> Yep
<RP> JPEW: I've updated the patch, thanks
<RP> quick local testing looks ok so I'll run it on the AB overnight