Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
florian__ has quit [Ping timeout: 252 seconds]
ardo has joined #yocto
ardo has quit [Ping timeout: 264 seconds]
ardo has joined #yocto
lexano has quit [Ping timeout: 272 seconds]
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
benkard has joined #yocto
mulk has quit [Ping timeout: 272 seconds]
benkard is now known as mulk
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #yocto
ablu has quit [Read error: Connection reset by peer]
npcomp has quit [Ping timeout: 268 seconds]
joeythesaint has quit [Ping timeout: 268 seconds]
joeythesaint has joined #yocto
ablu has joined #yocto
npcomp has joined #yocto
sev99 has quit [Quit: Client closed]
amitk has joined #yocto
nerdboy has quit [Ping timeout: 255 seconds]
xmn has quit [Ping timeout: 264 seconds]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
Xagen has joined #yocto
Xagen has quit [Client Quit]
Chaser has joined #yocto
mulk has quit [Ping timeout: 252 seconds]
salahaldeen has joined #yocto
<salahaldeen>
Including Python3 modules in generated SDK do not work (python3-node-semver, kirkstone)
<salahaldeen>
Hello,
<salahaldeen>
I am using one application which is using a python3 module (python3-node-semver), I was trying to provide the application developer with the yocto SDK but I cannot locate this module in the new generate SDK, I have tried to add this manually by adding these lines to machine config like this
<yocton>
mcfrisk_: there may be more CVE but as long as they have better CPE data than now, it should be easier for us (cve_check will do most of the work)
Kubu_work has joined #yocto
<yocton>
No CVE for unmaintained kernel. This will make interesting dashboards...
<yocton>
No published CVE without a merged fix first
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
zpfvo has joined #yocto
<yocton>
This will definitely push people towards stable branches (which is a good thing IMHO).... or bury their head in the sand with unmaintained/CVE-free kernels.
<mcfrisk_>
heads in sand already, and vendors claiming that's ok and good enough grr /rants
<yocton>
"it is going to be interesting to watch; popcorn is recommended." -- the LWN article :)
rfuentess has joined #yocto
<polprog>
is there a way to avoid cleaning the whole project to rebuild the rootfs after I updated my distro conf?
<polprog>
I've changed EXTRA_USERS_PARAMS and I want to rebuild the rootfs, but running 'bitbake foo-image' (this is the name of my image .bb) the .wic file is not updated
<polprog>
alternative question, how do i find out which task uses that variable to invalidate it and re-run all steps that depend on it?
Chaser has joined #yocto
<mcfrisk_>
polprog: "bitbake -e foo-image" and check EXTRA_USERS_PARAMS variable. if the effective variable, e.g. contents, did not change, then image is not recreated
zpfvo has quit [Ping timeout: 255 seconds]
<polprog>
oh, my bad
<polprog>
it actually works by changing the variable, i had a different problem :)
<polprog>
(forgot that usermod -p takes a hash, not a password, thats why my assignment didnt work)
Thorn_ has joined #yocto
Thorn has quit [Ping timeout: 268 seconds]
kpo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
rob_w has joined #yocto
prabhakar has joined #yocto
prabhakarlad has joined #yocto
leon-anavi has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
<mckoan>
polprog: bitbake -C image -> force image generation (-C is uppercase)
<RP>
yocton: the implication is that if you are using a maintained stable tree, you have no CVEs
<polprog>
mckoan: thanks!
jmiehe has joined #yocto
<yocton>
RP: yes! Or, if you're not up-to-date, only the CVEs that are fixable by an upgrade.
<RP>
yocton: it is an interesting strategy :)
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
prabhakar has quit [Ping timeout: 260 seconds]
goliath has left #yocto [SIGILL]
goliath has joined #yocto
prabhakarlad has quit [Ping timeout: 250 seconds]
<polprog>
apparently usermod in EXTRA_USERS_PARAMS does not support -6 type hashes?
<polprog>
but escaping the PW_HASH=.. value doesnt work, the $-parts are susbtituted with empty strings
<polprog>
so PW_HASH = "\$1\$IW9RRezN\$Y2koUDS0xs.P1bSn9fRU8."
<polprog>
becomes .P1bSn9fRU8. in /etc/shadow
<polprog>
(this hash is a test hash, dont worry)
<polprog>
how should i do it?
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<polprog>
i forgot the ' in usermod invocation. it now works. rtfm
jmiehe has quit [Quit: jmiehe]
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar has quit [Ping timeout: 255 seconds]
florian has joined #yocto
kpo has joined #yocto
pvogelaar has joined #yocto
<pvogelaar>
Hi all, in the SRC_URI I specify a source in my_source.tar.zip. Unzip and untar works find and the source land in a directory named my_source.tar. Is there a way to tell the fetch to name the directory just my_source instead of my_source.tar?
<mckoan>
pvogelaar: rename my_source.tar.zip in my_source.zip ?
<pvogelaar>
oh, now I see. It is not even a tar it is just called *.tar. Thx for the hint and sorry for the stupid question
pasherring has joined #yocto
<pasherring>
Hello, all =) One question regarding sstate-cache. What are a few good reasons for sstate not being used to populate native packages for instance?
<pasherring>
I work on a project that uses an outdated version (morty). We work on a handful of packages, and rarely need to change native packages. But, even though I configure sstate-cache to be shared among builds, it is always rebuilding native packages, such as glibc, gcc, cmake etc.
<rburton>
pasherring: glibc isn't native
<rburton>
pasherring: but are the host OSs all the same?
<rburton>
native sstate is per-host unless you use uninative, and i'm not sure if that existed in morty
<pasherring>
rburton, yes, the reference is my host machine only for now.
<rburton>
should work then.
<pasherring>
:\ Are there any "metadata smells" that could lead to that? I looked for things with ${AUTOREV}, but only found a target package that was using it.
<rburton>
not for stuff like cmake-native. can you replicate with _just_ an unmodified poky and no other layers?
<pasherring>
I can try to strip off the layers, but, wouldn't quite reproduce the issue as the image is our own. I'll try, anyway, to build with poky only and let you know.
<kanavin>
pasherring, it's perhaps easiest to start with a blank cache, make a build, then make another build (which is supposed to use items from the first build but does not)
<kanavin>
pasherring, then you can inspect the cache for two copies of each item where there should be just one
<kanavin>
pasherring, once you find them, use bitbake-diffsigs and it will tell you what is the difference between them in the metadata that caused a rebuild
Vonter has quit [Ping timeout: 256 seconds]
<kanavin>
it's probable there's something silly like inserting current date and time at the root of the metadata
Vonter has joined #yocto
<kanavin>
or other host-specific info such as build paths
<rburton>
if you think you can replicate on demand then definitely try with just poky instead of trying to strip your setup down, that will tell you if poky itself is good. also, morty is ancient, please upgrade.
<kanavin>
rburton, it's probably not that project, but current mercedes benz cars run it :D
prabhakarlad has joined #yocto
prabhakar has joined #yocto
<kanavin>
upcoming will be on dunfell, just as it goes EOL
<pasherring>
I wish we could do that, we are broadcom locked, and the effort to upgrade everything else, including outdated broadcom layers, are just too big :(
<kanavin>
how are you ensuring security of the product?
<pasherring>
I, myself, am not :| But the company try to shield itself by hiring some security assessment services.
<kanavin>
even then, there will be at some point a business requirement that can't be fulfilled without updating to modern yocto. at that point the cost of that update will enormous.
<pasherring>
It already is not viable, due to the use of broadcom stuff.
<pasherring>
Broadcom delivers a bundled package with lots of dependencies and built-in packages that are formal recipes in the yocto world.
<rburton>
this is when you threaten to switch hardware provider, or just write your own bsp using their patches as a start.
<kanavin>
rburton, enter evil ancient vendor kernel with thousands of patches
<rburton>
well, yeah
* Crofton
sighs the bottom up approach explaining best practices is failing
<RP>
"Don't build a Frankenstein OS" becomes "Don't use a Frankenstein Vendor" ? :)
<Crofton>
LOL
<RP>
LetoThe2nd: I'm not sure we can say that but...
<LetoThe2nd>
translation to embedded linux: while in this group there often is consensus about best practises and such, reality and decision makers sometimes disagree and are happy with it.
<LetoThe2nd>
RP: I know the tale :-)
<RP>
LetoThe2nd: ok, it was just the the emperor in question didn't despise clothes :)
<LetoThe2nd>
RP: indeed.
<kanavin>
Linus (not the embedded one) does work in bathrobes, and he mentioned that proudly
* RP
thinks some information doesn't need to be shared
* LetoThe2nd
hmmmmmmmssssss
<LetoThe2nd>
but again then, why should we care.
<Crofton>
kanavin: should I post a selfie?
<RP>
LetoThe2nd: the point was that in that case, the emperor was being scammed but nobody would tell him. Presumably people should care about that happening but who knows, perhaps nobody liked him.
<LetoThe2nd>
Crofton: my CM for YP role requires me to demand this not taking place here. my social media role for OE asks you to go ahead, this will get clicks!
<Crofton>
Why do we care? If vendors want to ship for bitcoin miners or botnet nodes, why shoudl we care as long as we get paid to help them?
<LetoThe2nd>
RP: if we translate the story to real life YP, then actually its more like that the emperor knows that he's being treated badly, but he'll have to bear with it because finding a new tailor is going to cost him multiple times the scammed money.
<RP>
YP doesn't have an emperor ;-)
lexano has joined #yocto
<Crofton>
Reality is always messier than fiction.
<LetoThe2nd>
RP: the emperor, at least in my understanding, is the PO/C-level/whatever in charge of a specific product being locked into a Frankenvendor. We can all be Jesters and tell them, but reality in their situation and life just is different. Been there way too long myself.
<kanavin>
there's still a poetic justice in that situation
prabhakarlad has quit [Quit: Client closed]
<kanavin>
neglect product sustainability, and you'll pay for it, in the shape of product becoming increasingly unviable
<pasherring>
Regarding that sstate stuff, I just moved stuff around, deleted the tmp folder and the sstate was not (re)used. I do see some setscene action going on, but then it starts basically from scratch, including native stuff :\
<RP>
pasherring: it could have been the hash equivalence database
<RP>
in cache rather than tmp/cache iirc
Starfoxxes has quit [Ping timeout: 260 seconds]
<kanavin>
RP: it's on morty
<RP>
kanavin: oh, who knows then.
<RP>
we have fixed bugs
<pasherring>
RP, after a quick search, I couldn't understand the concept :(
<kanavin>
pasherring, hash equivalence was added long after morty, so you needn't worry about that. You should proceed as I suggested.
prabhakar48 has joined #yocto
prabhakarlad has joined #yocto
<pasherring>
But, I just noticed that the issue (if it is morty, is it still an issue though?) is path sensitive.
Guest95 has joined #yocto
prabhakar has quit [Ping timeout: 264 seconds]
<pasherring>
I.e., if the newly checked out build has the exact same path as the build that generated the sstate-cache, it will be reused.
<rburton>
with pristine poky or your layers too?
xmn has joined #yocto
<pasherring>
Mine as well. Still didn't managed to split things.
<rburton>
well if you can say that sstate isn't used for eg cmake-native then do your reproducer with just poky and cmake-native, and then you'll know if its a poky thing or a your-layer thing
prabhakar48 has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
sev99 has joined #yocto
<kanavin>
pasherring, this looks like the build path is included into a variable that affects even the most core native recipes. I suspect some oddity in one of the custom layers. To find out, you really need to find two sstate signatures in the cache for the same object coming from builds in different paths and compare them.
<pasherring>
kanavin, these should all be relative path for this to be avoided, correct?
<rburton>
build paths shouldn't be counted at all for sstate purposes
<kanavin>
pasherring, not necessarily. Find what the issue is first.
<Guest95>
Hi,
<Guest95>
To create a smaller image size, I want to disable/remove the systemd service and include the sysvinit in IMX8. To do this I have added the following code in local.conf.
<Guest95>
ERROR: /work/new_yocto/varasicte/sources/meta-openembedded/meta-oe/recipes-core/packagegroups/packagegroup-boot.bb: Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (sysvinit) matches the entries enabled in DISTRO_FEATURES
<Guest95>
ERROR: Parsing halted due to errors, see error messages above
<Guest95>
I don't understand this error. any help would be appreciated
<rburton>
you can just set INIT_MANAGER=sysvinit
<rburton>
note that sysvinit is the default, so that tells me your using a custom (imx8 provided?) distro. just make your own and set INIT_MANAGER directly instead of using local.conf.
<Guest95>
I already tried by setting INIT_MANAGER=sysvinit in local.conf. Even this gives the same error :
<Guest95>
ERROR: /data/work/sunil/new_yocto/varasicte/sources/poky/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb: Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (systemd) matches the entries enabled in DISTRO_FEATURES
<Guest95>
ERROR: Parsing halted due to errors, see error messages above
<rburton>
most likely the distro you're using is poking at the features itself and you're fighting it.
<rburton>
which is why you should make your own distro
<kanavin>
Guest95, you can read the packagegroup.bbclass to see where the error comes from, and what variables are being checked there. Then use bitbake -e to find out what sets them and where.
<rburton>
99% sure its because DISTRO_FEATURES doesn't have sysvinit in
<kanavin>
and what rburton said: local.conf is the wrong place to set those things. Adjust the original distro, or make your own.
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<Guest95>
I'm using fslc-xwayland distro. May I know any bare minimal distro where I can use sysvinit.
<kanavin>
Guest95, poky as a starting point is okay, although it enabled a lot of things you may not need
<kanavin>
it uses sysvinit by default even, so you can just set DISTRO="poky"
<kanavin>
you should have meta-poky in your layers somewhere
<kanavin>
most likely
<Xogium>
that is, if imx does the right thing
<kanavin>
yeah, I suspect a lot of things have never been tested with anything except that vendor distro and may break
<Xogium>
I tried to use poky to get started with yocto, but truth be told, it was very overwhelming to me. I understood better when I used the simplest-yocto-setup from bootlin
<Xogium>
nothing against poky, but it just was doing WAY too much for my brain I guess ;)
<Guest95>
thanks for info. I will check it out
<mckoan>
Guest95: i.MX8 doesn't like sysvinit and doesn't work with X11, you have to use (x)wayland
<mckoan>
Guest95: you have a system alredy tailored to your system
kanavin_ has joined #yocto
kanavin has quit [Read error: Connection reset by peer]
Tyaku_ has joined #yocto
<Tyaku_>
Hello is it possible to apply a patch for a specific distro AND specific machine ? for exemple: SRC_URI:append:mydistro:mymachine = " file://mypatch.patch "
<Saur>
Tyaku_: Yes, it will work. Just be aware of the implications of machine specific changes in a recipe.
<Tyaku_>
@Saur, With my syntax the meaning is "Append the patch in SRC_URI if we build with DISTRO=mydistro AND MACHINE=mymachine right ? (I mean, it's not a OR ?)
<Saur>
Correct.
<Tyaku_>
Also the documentations about these things is only "3.3 Conditional Syntax (Overrides)" ?
<Tyaku_>
Becasue there is no example with a "AND" like what I try to do
luc4 has joined #yocto
prabhakar has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
ptsneves has joined #yocto
<luc4>
Hello! I recently ported my image recipe to nanbield and recompiled everything. Apparently the resulting image seems to have the entire rootfs with owner set to 1000 instead of 0. Any idea why?
<rburton>
does that happen for eg core-image-minimal?
<luc4>
rburton: I did not try, but I can do it
<luc4>
rburton: 1000 is the id of a user I create with useradd however. I suspect it is somehow related.
<rburton>
how are you looking at the ownership of the files in the rootfs? on the target?
<luc4>
rburton: I noticed it on the target, but I'm now mounting the image directly in my linux machine
<rburton>
possibly your useradd is confusing things
<luc4>
I'll try to remove that
<luc4>
In testing something like this, should I simply rebuild the image or should I also somehow clean it up?
<rburton>
just rebuild, that should be fine
<luc4>
thanks
<luc4>
rburton: I removed everything related to that user, but permissions did not change. Do you have any advice on how to debug this?
<rburton>
luc4: fresh poky clone, bitbake core-image-minimal, verify that at least generates an image with correct perms.
<luc4>
rburton: thanks
<luc4>
actually, 1000 is also the id of my user on the host machine
<rburton>
indeed
prabhakarlad has joined #yocto
prabhakar has joined #yocto
jmd has joined #yocto
<luc4>
the fact that I'm running on wsl2 inside a docker container may not help
<rburton>
a custom container or a well tested one?
<rburton>
(crops, kas)
<luc4>
rburton: it is the same I was using with kirkstone
<luc4>
however, I built a different image a couple of hours ago and permissions were just fine
Xagen has joined #yocto
Vonter has quit [Ping timeout: 264 seconds]
Vonter has joined #yocto
goliath has quit [Quit: SIGSEGV]
<Ad0>
is there a built in way to modify sysctl.conf ?
<Ad0>
I want to disable ipv6
<rburton>
Ad0: ipv6 is the glorious future, but if you want to have to ipv6 then don't build it in your kernel
<rburton>
(and remove the ipv6 DISTRO_FEATURE to remove the user-space code that supports it)
<rburton>
"no ipv6", even
<Ad0>
there's like 10000 variables hehe
<Ad0>
I had a docker container connecting to localhost and it got ::1
<Ad0>
that pissed me off
<rburton>
that's the glorious future!
<Ad0>
I am fine with just doing it in sysctl.conf
<Ad0>
haha
<Ad0>
I guess making a bbappend for poky/meta/recipes-extended/procps/procps_3.3.17.bb ?
<Ad0>
put my file in /etc/sysctl.d
joekale has joined #yocto
Vonter has quit [Ping timeout: 246 seconds]
Vonter has joined #yocto
Tyaku_ has quit [Quit: Lost terminal]
<pasherring>
Are there tools to dump/compare siginfo files? Since I haven't really looked into this siginfo files, I really can't tell, but here is the dump of a do_compile for cmake, for instance https://pastebin.com/e1puAb2P
<Saur>
pasherring: bitbake-dumpsig and bitbake-diffsigs are what you are looking for.
luc4 has quit [Quit: Konversation terminated!]
<pasherring>
Saur, thanks!
rfuentess has quit [Remote host closed the connection]
brrm has quit [Ping timeout: 268 seconds]
brrm has joined #yocto
<pasherring>
Is it too bad that siginfo of the same package for builds in different paths result in dictionaries ordered differently, but the same content?
<rburton>
pasherring: in the last decade of work post-morty, lots of dictionaries and lists were sorted for that exact reason
<pasherring>
Right :/
<tlwoerner>
qschulz: i know you're probably busy, but do you have any opinion on the 4 patches i submitted for meta-rockchip at the start of the week? i'm hoping to apply them soon-ish
<qschulz>
tlwoerner: I actually have an opinion :D
joekale has quit [Ping timeout: 272 seconds]
joekale has joined #yocto
<khem>
RP: I see that you have mesa-24 upgrade staged, with that we wont need the mesa: Fix build with llvm 18 patch that I sent, its only needed with mesa-23
<khem>
RP: you have it staged in master-next so you can remove it if we have mesa-24
zpfvo has quit [Quit: Leaving.]
<tlwoerner>
qschulz: i appreciate your opinions
<tlwoerner>
(i might not agree, by i do appreciate)
<qschulz>
tlwoerner: i'm sure you won't agree with the ones I'm going to give you :0
<qschulz>
:)
joekale has quit [Ping timeout: 272 seconds]
joekale has joined #yocto
ptsneves has quit [Ping timeout: 264 seconds]
joekale has quit [Ping timeout: 264 seconds]
joekale_ has joined #yocto
rob_w has quit [Quit: Leaving]
<RP>
khem: I was actually just checking that, thanks!
mckoan is now known as mckoan|away
goliath has joined #yocto
nerdboy has quit [Remote host closed the connection]
linfax has quit [Ping timeout: 264 seconds]
nerdboy has joined #yocto
simonew has joined #yocto
<qschulz>
tlwoerner: done
<nerdboy>
moin
bhstalel has joined #yocto
<khem>
RP: regarding RISCV failures, the hang in my runs is due to a local fix I am doing to touch the configure to avoid timestamp issue, configure keeps running in a loop mindlessly, so atleast I know the reason.
<khem>
I think we need to get to root cause of system time issue that cpio builds are reporting
<khem>
it could be a bug in lower layers of s/w
Guest95 has quit [Quit: Client closed]
<khem>
what I was trying was to bypass it and see if there are more failures left
<khem>
in general RV64 is in a relatively good shape, where we can say its not tier1 but tier2 architecture in LTS ( worst case )
<khem>
which means we dont need whole sale backports but tests could be improved ( fixed )
florian__ has joined #yocto
Vonter has quit [Ping timeout: 264 seconds]
hus has joined #yocto
xmn has quit [Read error: Connection reset by peer]
xmn has joined #yocto
<hus>
I have two build systems, an old one with debian 4.19.0-21-amd64 and a newer one with debian 6.1.0-13-amd64. Buildwith the old one private kernel modules get not signed. Using the newer one this works. Problem is the older one is the official server. Any ideas?
<khem>
hus: how do you sign the kmods ?
<khem>
IOW whats the dependency on build system kernel
<hus>
Not explicitly. Just the config set: CONFIG_MODULE_SIG=y
<hus>
CONFIG_MODULE_SIG_ALL=y
<hus>
CONFIG_MODULE_SIG_FORCE=y
<hus>
CONFIG_MODULE_SIG_SHA256=y
<hus>
CONFIG_MODULE_SIG_SHA512=y
<hus>
CONFIG_MODULE_SIG_HASH="sha512"
<hus>
CONFIG_MODULE_COMPRESS=y
<hus>
# CONFIG_MODULE_COMPRESS_GZIP is not set
<hus>
CONFIG_MODULE_COMPRESS_XZ=y
<hus>
CONFIG_CRYPTO_SHA1=y
<hus>
CONFIG_CRYPTO_SHA256=y
<hus>
CONFIG_CRYPTO_SHA512=y
<khem>
does 4.19 have kmod signing support ?
<hus>
I have to check. what is the flags name?
<khem>
I guess it was added in 3.7 so you should be ok
<khem>
firstly I am not clear on your setup, are you building yocto on top of this debian system ?
leon-anavi has quit [Quit: Leaving]
<khem>
and using yocto to create images which should have signed kernel mods ?
hus has quit [Quit: Client closed]
florian__ has quit [Ping timeout: 252 seconds]
amitk has quit [Remote host closed the connection]
hus has joined #yocto
amitk has joined #yocto
joekale_ has quit [Ping timeout: 272 seconds]
joekale has joined #yocto
sev99 has quit [Quit: Client closed]
florian__ has joined #yocto
frieder has quit [Remote host closed the connection]
wmills_ has joined #yocto
joekale has quit [Ping timeout: 246 seconds]
joekale has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amitk has quit [Ping timeout: 264 seconds]
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jmd has quit [Remote host closed the connection]
pasherring_ has joined #yocto
pasherring has quit [Read error: Connection reset by peer]
Thorn has joined #yocto
Thorn_ has quit [Ping timeout: 264 seconds]
pasherring_ has quit [Ping timeout: 261 seconds]
pasherring has joined #yocto
pasherring has quit [Ping timeout: 255 seconds]
bhstalel has quit [Read error: Connection reset by peer]
<RP>
khem: I somehow need to get to the point of clean builds with riscv though
<RP>
khem: even if we have to just disable some things
florian has quit [Killed (NickServ (GHOST command used by florian__!~florian@dynamic-093-131-148-062.93.131.pool.telefonica.de))]
florian__ is now known as florian
florian_kc has joined #yocto
hus has quit [Quit: Client closed]
Starfoxxes has joined #yocto
alessioigor has quit [Ping timeout: 240 seconds]
<khem>
yeah.
<khem>
btw. I see you dropped LLVM upgrade along with vulkan-samples
<khem>
they are unrelated
<khem>
so you can still keep llvm upgrade
mvlad has quit [Remote host closed the connection]
<khem>
that will be good. I will meanwhile fix the issue with vulkan-samples for 32bit
prabhakarlad has quit [Quit: Client closed]
<RP>
khem: I was confused as they seemed to be in an llvm series together
<RP>
khem: the llvm version number also seems a little odd to me - 18.1.0 ?