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
sugarbeet has quit [*.net *.split]
Daanct12 has quit [*.net *.split]
Estrella__ has quit [*.net *.split]
Ablu has quit [*.net *.split]
chep has quit [*.net *.split]
khem has quit [*.net *.split]
brrm has quit [*.net *.split]
jmk1 has quit [*.net *.split]
LocutusOfBorg has quit [*.net *.split]
olani- has quit [*.net *.split]
schtobia has quit [*.net *.split]
lukma has quit [*.net *.split]
fullstop has quit [*.net *.split]
risca has quit [*.net *.split]
jmiehe has quit [*.net *.split]
tleb has quit [*.net *.split]
CosmicPenguin has quit [*.net *.split]
rhadye has quit [*.net *.split]
diamondman__ has quit [*.net *.split]
dlan has quit [*.net *.split]
camus has quit [*.net *.split]
madisox_ has quit [*.net *.split]
Omax has quit [*.net *.split]
Perflosopher has quit [*.net *.split]
joeythesaint has quit [*.net *.split]
mlaga97 has quit [*.net *.split]
dario has quit [*.net *.split]
nerdboy has quit [*.net *.split]
dvergatal has quit [*.net *.split]
ecdhe has quit [*.net *.split]
warthog9 has quit [*.net *.split]
paulg has quit [*.net *.split]
dmoseley has quit [*.net *.split]
ardo has quit [*.net *.split]
Ram-Z has quit [*.net *.split]
__lore__ has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
astlep55040 has quit [*.net *.split]
sukbeom has quit [*.net *.split]
Scorpi has quit [*.net *.split]
mcfrisk has quit [*.net *.split]
tprrt has quit [*.net *.split]
Net147 has quit [*.net *.split]
xantoz has quit [*.net *.split]
schtobia has joined #yocto
Omax has joined #yocto
LocutusOfBorg has joined #yocto
khem has joined #yocto
dario has joined #yocto
ecdhe has joined #yocto
_lore_ has joined #yocto
sukbeom has joined #yocto
CosmicPenguin has joined #yocto
madisox_ has joined #yocto
rhadye has joined #yocto
diamondman__ has joined #yocto
Haxxa has quit [*.net *.split]
lexano has quit [*.net *.split]
olani has quit [*.net *.split]
mrpelotazo has quit [*.net *.split]
Piraty has quit [*.net *.split]
jgrossholtz has quit [*.net *.split]
Bardon has quit [*.net *.split]
bantu has quit [*.net *.split]
JaMa has quit [*.net *.split]
jonmason has quit [*.net *.split]
stacktrust_ has quit [*.net *.split]
bradfa has quit [*.net *.split]
tleb has joined #yocto
nerdboy has joined #yocto
jgrossholtz has joined #yocto
jmk1 has joined #yocto
sugarbeet has joined #yocto
bradfa has joined #yocto
jonmason has joined #yocto
stacktrust_ has joined #yocto
ecdhe has joined #yocto
ecdhe has quit [Changing host]
nerdboy has quit [Changing host]
nerdboy has joined #yocto
xantoz has joined #yocto
prabhakarlad has quit [Ping timeout: 245 seconds]
Ablu has joined #yocto
astlep55040 has joined #yocto
joeythesaint has joined #yocto
Ablu has joined #yocto
Ablu has quit [Changing host]
Scorpi has joined #yocto
brrm has joined #yocto
Bardon has joined #yocto
bantu has joined #yocto
tangofoxtrot has joined #yocto
dlan has joined #yocto
JaMa has joined #yocto
tangofoxtrot has quit [Changing host]
tangofoxtrot has joined #yocto
dlan has quit [Changing host]
dlan has joined #yocto
jmiehe has joined #yocto
prabhakar has quit [Quit: Connection closed]
Danct12 has joined #yocto
Net147 has joined #yocto
Estrella__ has joined #yocto
Net147 is now known as Guest1119
camus has joined #yocto
dmoseley has joined #yocto
chep has joined #yocto
fullstop has joined #yocto
risca has joined #yocto
Ram-Z has joined #yocto
mlaga97 has joined #yocto
Piraty has joined #yocto
mrpelotazo has joined #yocto
lukma has joined #yocto
dvergatal has joined #yocto
tprrt has joined #yocto
mcfrisk has joined #yocto
Haxxa has joined #yocto
warthog9 has joined #yocto
ardo has joined #yocto
yates_work has joined #yocto
<yates_work> what are "ptest"s?
<yates_work> the meta-qt5/recipes-qt/qt5/qtbase_git.bb recipe includes qt5-ptest.inc, which inherits ptest and defines "do_compile_ptest" and "fakeroot do_install_ptest". if i want to disable ptests in my qtbase_git.bbappend, can i just redefine "do_compile_ptest" and "fakeroot do_install_ptest" to do nothing?
jmiehe has quit [Quit: jmiehe]
<yates_work> or is there a more elegant way?
<yates_work> i am building qtbase using a config of -debug rather than -release and that hoses the ptests.
mrpelotazo has quit [Ping timeout: 272 seconds]
yocti has quit [Remote host closed the connection]
yocti has joined #yocto
mrpelotazo has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
Ablu has quit [Ping timeout: 240 seconds]
Ablu has joined #yocto
Daanct12 has joined #yocto
Daanct12 has quit [Ping timeout: 272 seconds]
<khem> @yates_work ptests are "package tests", its akin to unit tests
<khem> you wont compile them in unless you have 'ptest' added to DISTRO_FEATURES
<khem> I think poky defaults to adding ptest to distro features which makes sense as it is a reference distro, but you might choose to override it in your own distro
<khem> or maybe generate two distro policies one with ptests and one without
vlrk42 has quit [Quit: Client closed]
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #yocto
Daanct12 has joined #yocto
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
vlrk42 has joined #yocto
amitk has joined #yocto
<moto-timo> Seems every time the queue is emptied bitbake rechecks the cdn sstate mirror object availability... wondering what the "recommended" settings in local.conf are @khem
<moto-timo> e.g. run 24 tasks (my number of threads) and then 35 seconds to re check the availability
<moto-timo> local.conf (using kas fwiw): https://snips.sh/f/QzaX9sZkU2
<moto-timo> ah, looks like rm_work might muck with things RP?
vlrk42 has quit [Quit: Client closed]
vlrk42 has joined #yocto
amitk_ has joined #yocto
vlrk42 has quit [Quit: Client closed]
vlrk42 has joined #yocto
starblue has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.0.4]
alessioigor has joined #yocto
c_sutton has quit [Ping timeout: 264 seconds]
c_sutton has joined #yocto
Daanct12 has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Guest98 has joined #yocto
Vonter has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.0.4]
amitk has quit [Quit: Lost terminal]
camus has quit [Remote host closed the connection]
<yates_work> thanks khem.
starblue has quit [Ping timeout: 272 seconds]
Daanct12 has joined #yocto
amitk has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
linfax has joined #yocto
linfax has quit [Remote host closed the connection]
vlrk24 has joined #yocto
linfax has joined #yocto
vlrk15 has joined #yocto
vlrk42 has quit [Ping timeout: 245 seconds]
vlrk24 has quit [Ping timeout: 245 seconds]
GNUmoon has quit [Ping timeout: 252 seconds]
GNUmoon has joined #yocto
brrm has quit [Ping timeout: 240 seconds]
Schlumpf has joined #yocto
brrm has joined #yocto
mckoan|away is now known as mckoan
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rob_w has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
rfuentess has joined #yocto
mvlad has joined #yocto
Kubu_work has joined #yocto
xmn has quit [Quit: ZZZzzz…]
wooosaiiii has quit [Remote host closed the connection]
zpfvo has joined #yocto
Kubu_work has quit [Ping timeout: 240 seconds]
zpfvo has quit [Ping timeout: 255 seconds]
luc4 has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
<Guest98> when i create a bbappend for one recipe, add a file to SRC_URI and see it in ${WORKDIR}, also create a bbappend for another recipe and cant see it in ${WORKDIR}. what could be the reason for this?
Kubu_work has joined #yocto
rfuentess has joined #yocto
<Guest98> Thanks to JaMa for answered the question :)
<Guest98> I'll try to do it.
<JaMa> yw :)
zpfvo has joined #yocto
l3s8g has joined #yocto
prabhakar has joined #yocto
prabhakarlad has joined #yocto
amitk has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
leon-anavi has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has joined #yocto
amitk_ has quit [Remote host closed the connection]
amitk has joined #yocto
<RP> moto-timo: the challenge is that when you get a hash-equivalence match, it will recheck the mirrors
<RP> exactly how much it checks depends on how many hashes changed checksum
<RP> how many tasks
<LetoThe2nd> yo dudX
wooosaiiii has joined #yocto
Marmottus has quit [Quit: The Lounge - https://thelounge.chat]
Marmottus has joined #yocto
ad__ is now known as pippo444
pippo444 is now known as ad__
olani_ has quit [Read error: Connection reset by peer]
olani has joined #yocto
ptsneves1 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
mckoan is now known as mckoan|away
vladest1 has joined #yocto
Schlumpf has quit [Ping timeout: 245 seconds]
vlrk15 has quit [Quit: Ping timeout (120 seconds)]
vlrk15 has joined #yocto
speeder has quit [Remote host closed the connection]
Daanct12 has quit [Quit: WeeChat 4.0.4]
rob_w has quit [Quit: Leaving]
Guest98 has quit [Ping timeout: 245 seconds]
slimak has joined #yocto
ptsneves1 has quit [Quit: ptsneves1]
vladest1 has quit [Ping timeout: 255 seconds]
ptsneves has joined #yocto
jmiehe has joined #yocto
goliath has quit [Quit: SIGSEGV]
ptsneves has quit [Ping timeout: 240 seconds]
Daanct12 has joined #yocto
Schlumpf has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.0.4]
Daanct12 has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
ptsneves has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #yocto
lexano has joined #yocto
ptsneves has quit [Ping timeout: 260 seconds]
Guest98 has joined #yocto
leon-anavi has quit [Remote host closed the connection]
Daanct12 has quit [Ping timeout: 255 seconds]
Daanct12 has joined #yocto
leon-anavi has joined #yocto
goliath has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.0.4]
vlrk15 has quit [Quit: Client closed]
luc4 has quit [Quit: Konversation terminated!]
luc4 has joined #yocto
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
xmn has joined #yocto
Guillaume has joined #yocto
<Guillaume> Hi! I want to add en_US.utf8 language to my build, so I set GLIBC_GENERATE_LOCALES = "en_US.UTF-8" and IMAGE_LINGUAS = "en-us" in my conf/local.conf. When I use bitbake -e to see my environment, i see that GLIBC_GENERATE_LOCALES worths "en_US.UTF-8" as expected but IMAGE_LINGUAS is always an empty string. I don't know how to determine what recipe
<Guillaume> sets this variable, I see many recipes that set it to "" and I don't know why
<rburton> bitbake -e will tell you, above the assignment.
<rburton> or bitbake-getvar IMAGE_LINGUAS if you have a reasonably modern release
<Guillaume> Ho. Thanks rburton
Guest98 has quit [Ping timeout: 245 seconds]
<rburton> your distro may forcibly set the linguas or something
Guest98 has joined #yocto
Xagen has joined #yocto
<Guillaume> I found my issue, in my recipe, I have "require recipes-core/images/core-image-minimal.bb" and this recipe set IMAGE_LINGUAS to "". Many thanks again rburton!
<rburton> yeah, minimal is minimal
<rburton> create your own image, don't pull in other recipes
<rburton> copy-and-paste is the right thing to do here - the core-image-* recipes are examples, nothing else
<Guillaume> I see. I'm new on this project and yocto, I'm going to talk to "knowers" about this
bunk has joined #yocto
vlrk15 has joined #yocto
vlrk15 has quit [Client Quit]
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest63 has joined #yocto
Guest98 has quit [Ping timeout: 245 seconds]
Guest98 has joined #yocto
Guest98 has quit [Client Quit]
Guest63 has quit [Ping timeout: 245 seconds]
Schlumpf has quit [Quit: Client closed]
Guest98 has joined #yocto
Guest82 has joined #yocto
Guest98 has quit [Ping timeout: 245 seconds]
Guest82 has quit [Ping timeout: 245 seconds]
Guest98 has joined #yocto
goliath has quit [Quit: SIGSEGV]
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
bunk has quit [Quit: leaving]
Guest93 has joined #yocto
Guest98 has quit [Ping timeout: 245 seconds]
<moto-timo> Anybody else seeing mesa-native do_compile failure on latest master (host is Ubuntu 22.04)
Guest93 has quit [Ping timeout: 245 seconds]
luc4 has quit [Ping timeout: 260 seconds]
Guest8 has joined #yocto
* RP is seeing it too FWIW
<RP> moto-timo: I think it is the llvm upgrade breaking things btw
<moto-timo> RP: that was what I was beginning to suspect as well
<RP> khem: is there another tweak needed to the mesa llvm patch?
<RP> moto-timo: my build during the calls failed. There is a mesa patch khem recently tweaked and I think the versions are out again
* moto-timo just glad someone else is seeing it and it's not just a cursed development machine
<moto-timo> I've had reasons to be suspicious of this box a couple times
vvn has quit [Quit: WeeChat 4.0.4]
bhstalel has joined #yocto
vvn has joined #yocto
<RP> moto-timo: I still can't get the thing to build :(
<moto-timo> 🤬
<moto-timo> I'm looking at the git history in poky for clues
<dl9pf> we see it as well in our tests of YP master (aka AGLs -next branch), https://jira.automotivelinux.org/browse/SPEC-4917
<moto-timo> 🤬
<RP> I guess the autobuilder runs a slightly different config but it raises questions about our test matrix
Guest8 has quit [Ping timeout: 245 seconds]
jmiehe has quit [Quit: jmiehe]
Guest98 has joined #yocto
linfax has quit [Ping timeout: 255 seconds]
<moto-timo> questions we'd rather not see at this stage of the release cycle ;)
<moto-timo> :(
<dl9pf> our case is on "Debian GNU/Linux bookworm/sid"
<RP> moto-timo: reverting the mesa and llvm changes seems to let it build
goliath has joined #yocto
geoffhp has joined #yocto
KanjiMonster has quit [Ping timeout: 252 seconds]
KanjiMonster has joined #yocto
rfuentess has quit [Remote host closed the connection]
Danct12 has quit [Quit: What if we rewrite the code?]
rfuentess has joined #yocto
dlan has quit [Ping timeout: 258 seconds]
Guest98 has quit [Quit: Client closed]
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
amitk_ has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
kscherer has joined #yocto
dlan has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
rfuentess has quit [Remote host closed the connection]
zpfvo has quit [Quit: Leaving.]
slimak has quit [Ping timeout: 272 seconds]
bhstalel has quit [Quit: Client closed]
leon-anavi has quit [Quit: Leaving]
Guillaume has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
mvlad has joined #yocto
amitk_ has quit [Quit: Lost terminal]
Danct12 has joined #yocto
<JPEW> rburton: I just pushed an RFC to the bitbake ML for a websockets based hash equivalent client, and the server is here: https://github.com/JoshuaWatt/bb-hashserver
<khem> RP: moto-timo this seems to be due to this host having older llvm installed locally
<JPEW> Also in poky-contrib
<khem> JPEW: RP the spdx issue popped up again in my CI last night
<khem> this time without rm_work so one less thing to worry about
<JPEW> khem: Ya, I figured it wasn't an rm_work problem
<JPEW> (since deploydir shouldn't be affected by rm_work)
<JPEW> khem: I _think_ that there is some code somewhere that removes sstate files based on the manifest?
<JPEW> I don't know exactly where, but I'm guess that should also remove the stamp file
<rburton> JPEW: nice
<JPEW> khem: Are there any other log messages related to wayland-native?
<khem> ok makes sense, its perhaps in sstate class
<rburton> JPEW: you made that look very easy. i should inspect every line of it to learn :)
<JPEW> rburton: I initially wrote it with the intention of doing this, so that helped
<moto-timo> khem: so we're now saying ubuntu-22.04 is not new enough and is going to need buildtools-tarball? it's got clang-14/llvm-14
<khem> thats it
<moto-timo> can someone kick debian and canonical to update llvm/clang?
<khem> moto-timo: no, we are saying it should be linking with libllvm from native-sysroot not from build host
<JPEW> khem: Apparently I have to be 18 to see that
<khem> JPEW: lol, show your DL
<moto-timo> I've reverted at least 3 commits and still no joy
<moto-timo> mesa, llvm upgrades and mesa/llvm patch
<khem> its possible that mesa's way of detecting llvm needs some inspection
<khem> it could be that its using llvm-config and we are pointing to wrong llvm-config
<khem> JPEW: I like snippets, they convey more than text and GPT4 can search through them :)
<JPEW> Ya
<JPEW> Err, I guess it would have been when the IMX8 build was done (so the build before that?)
<JPEW> I'm looking for the log messages that says it's removing the wayland-native sstate files
<khem> JPEW: The sequence is qemux86-64/musl then qemux86-64/glibc then imx8/glibc
goliath has quit [Quit: SIGSEGV]
<khem> I can build mesa-native inside debian12 container and it does have /usr/lib/x86_64-linux-gnu/libLLVM-14.so.1 installed
<khem> this is using llvm-native provided by clang-native
<khem> so perhaps something in llvm-native needs to be brought from clang-native maybe
Danct12 has quit [Quit: What if we rewrite the code?]
brazuca has joined #yocto
CapEnt has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
goliath has joined #yocto
starblue has joined #yocto
Kubu_work has quit [Quit: Leaving.]
brazuca has quit [Quit: Client closed]
flom84 has joined #yocto
<JPEW> khem: I thought it was qemux86-64/glibc, imx8/glibc, qemux86-64/glibc
xmn_ has joined #yocto
xmn has quit [Ping timeout: 248 seconds]
<khem> JPEW: no the order is the one I described just now
<JPEW> And the IMX8 one fails?
<khem> yes
<JPEW> Well.... thats different then
<khem> it fails with some random target package but that target package is bringing in wayland-native as dep thats common across all problems
<JPEW> Which layer?
<JPEW> which layer provides the im8 wayland version?
<khem> meta-freescale
xmn_ has quit [Quit: xmn_]
<JPEW> khem: This recipe is... why does it exist :)
<khem> yeah I wonder that too.
<khem> now that they dont even use their own fork
<khem> diff is minimal too
<khem> this is better
<JPEW> I mean, it should still _work_ I just question why it exists :)
<khem> historically it was a fork
<khem> and was not matching oe-core versions
<khem> DEFAULT_PREFERENCE = "-1"
<khem> I think its existence is a different question, I will discuss it and perhaps turn it into a bbappend at best
<khem> but the spdx issue its reproducing is general, it can happen with other recipes too I guess
<JaMa> negative D_P doesn't really do much when this recipe is in layer with higher prio than oe-core
<khem> where we have two machines using two different native providers for same
florian_kc has joined #yocto
<JPEW> khem: Ya. I need to rethink my reasoning, since I misunderstood how it was reproducing
<khem> JaMa: even DP ? I thought it ignored version precendence
<JPEW> DP is only for recipes _in the same layer_ IIRC
<JaMa> yes, layer prio has highest importance
<khem> true, but even for DP thats insane
xmn has joined #yocto
<JaMa> I agree, DP is quite useless in layers as the cases where you have multiple version in the same layer are quite rare and easy to solve with P_V
<khem> JaMa: reported in 2012 :)
<JPEW> khem: So to reproduce, all I should need to do is add meta-freescale to bblayers.conf and set my MACHINE to ??
<JaMa> while if you want to have opt-in newer version in your layer, you would need to maintain P_V pointing to the "old" PV from upper layers (to avoid your newer devel version to be used whenever your layer is in BBLAYERS)
<khem> JPEW: you only add it when you build the imx machine not always
<JPEW> Right
<khem> in my setup I have projects which use different bblayers
<JaMa> khem: and didn't change since 2012 :)
<JPEW> khem: Ya I do that all the time too
<khem> for qemu use just poky
<JPEW> Which machine are you using for imx?
<JaMa> in this case setting COMPATIBLE_MACHINE to at least restrict it only for imx MACHINEs would be more useful than DP
<khem> and then add meta-freescale for MACHINE=imx8mm-ddr4-evk
<JPEW> khem: Hmm.... not sure if I can test this since mesa doesn't build :/
<JPEW> (same problem as above)
<khem> you are seeing the mesa llvm issue too ?
<JPEW> Yes
<khem> whats your build host OS
<JPEW> Ubuntu 22.04
<khem> ok
<khem> revert the llvm upgrade
<JPEW> k
<khem> that should fix it
<khem> I think there are two patches one for 17.0.1 and another for 17.0.2
<khem> revert both
<JaMa> FWIW I haven't seen this with ubuntu-23.10 yet (but I do use meta-clang in many of those builds in ubuntu)
<JaMa> and I haven't seen it with gentoo as well
<khem> JaMa: yeah it does not happen with clang provided llvm-native
<khem> I am trying to see why,
<khem> it did not fail for me on arch either but arch has llvm-15 installed so may be problem is still there but since llvm is newer it gets by
<khem> JaMa: can you post your mesa-native log.do_compile if you have it handy
<JaMa> cannot ATM, kids are playing games on my threadripper :)
<khem> heh ok
<khem> OK I can see that with clang-native its properly specifying -lLLVM-17
<khem> now lets see what is does with llvm-native
sakman_ has joined #yocto
sakman has quit [Ping timeout: 264 seconds]
starblue has quit [Ping timeout: 255 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sakman_ is now known as sakman
prabhakarlad has joined #yocto
<khem> debian12 it builds ok too
<khem> so how do I reproduce it
<khem> just with llvm-native
<khem> RP: is there an AB where the mesa-native failure is reproducible ?
<khem> node
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alimon has quit [Remote host closed the connection]
flom84 has quit [Quit: Leaving]
alimon has joined #yocto
l3s8g has quit [Quit: l3s8g]
<khem> JPEW: can you check if you have llvm-14-dev installed on your build machine ?
<khem> try to remove it and see if mesa-native then succeeds to compile ?
<JPEW> khem: How?
<khem> you are on ubuntu right ?
<JPEW> Ya
<khem> apt list --installed | grep llvm
gmorell has joined #yocto
<gmorell> Hey all, I was wondering if anyone has any tips on packaging multiple go apps with multiple, incompatible versions in Yocto
starblue has joined #yocto
gmorell_ has joined #yocto
gmorell has quit [Quit: Konversation terminated!]
<RP> khem: we've not seen it on the AB
<RP> JPEW: the hashserv patches are interesting. I'm wondering if we should just accept a websocket dependency
<RP> JPEW: is that enough to make the server work ignoring the other DB backends?
gmorell_ is now known as gmorell
<JPEW> I think so. The only other dependencies my implementation has are the sqlalchemy stuff to allow using non-sqlite databases
<RP> JPEW: I need to think through all the implications but I'm tempted to make websockets the standard. I don't think our current way of doing it will scale
<RP> JPEW: another crazy thought - would we be able to piggyback some kind of "sstate available" signal into the server?
<RP> JPEW: on of the worries with the CDN is the number of 404s we trigger, which are painful for a CDN
<JPEW> mmm, ya maybe
<gmorell> additional context: re my question above, mender-client is on go 1.17, while podman from meta-virtualization requires 1.18
<RP> halstead: JPEW has some interesting client/server websocket implementations of hashserv
<khem> RP: yeah I have a hunch that llvm-dev package is causing it.
brazuca has joined #yocto
<khem> its perhaps due to llvm-config getting confused perhaps
<RP> khem: llvm-config getting confused seems most likely
<RP> khem: I'm going to bed soon and not powering up my build machine again tonight
<khem> JPEW: is seeing it too, so once he checks his system and uninstalls llvm-14-dev and see if that makes it succeed then we might have narrowed it down a bit
<RP> khem: right, I'm just tired and really shouldn't get involved in another debug session
<khem> yeah dont worry go to bed :)
<RP> JPEW: do you think we could/should include the websockets client and server in bitbake?
<JPEW> client.... probably. Server... maybe; have to see if there is a clean way to make that work.
<RP> JPEW: is there a decent speed win for this even for local query use?
<RP> i.e. do we give in and mandate websockets if you're using a hashserv?
<JPEW> I'm not sure. My server is slower, but IDK if that is websockets or sqlalchemy
<RP> fair enough. We probably need more data then
<JPEW> Ya. I'll see if I can get the bitbake server to use websockets
<RP> ok, I should get a break from screens :)
* RP really goes
prabhakarlad has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 240 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mvlad has quit [Remote host closed the connection]
<halstead> Excellent.
<halstead> JPEW: is it ready to put up as a public read only resource?
<JPEW> halstead: No, I need to do a lot more testing before we can do that :)
<JPEW> It's very much PoC right now
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
brazuca has quit [Quit: Client closed]
<halstead> JPEW: alright. Still very exciting.
brazuca has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
<khem> JPEW: I sent couple of patches for mesa, try them out on your env
<khem> and see if it helps your case
<khem> hmm seeing this
<khem> JPEW: something to do with websocket stuff ?
<khem> yep confirmed
brazuca has quit [Quit: Client closed]
lexano has quit [Ping timeout: 255 seconds]