<khem>
if its running on host then problem seems to be that it was built on a host where libmpfr.so.6 is present in /usr/lib but alma-8 does not have libmpfr.so.6
<khem>
but it has older version - libmpfr.so.4
<sakoman>
do we require that hosts have libmpfr.so?
<khem>
are we using buildtools-tarball on alma8 ?
<khem>
if we are then we should add nativeskd-mpfr to it
<sakoman>
let me check, I think we are using buildtools
<khem>
another way would be to statically link it into gcc
<sakoman>
so to make sure I understand you, we should be using a buildtools that includes nativeskd-mpfr, since we currently don't explicitly include it
<khem>
the problem to me looks like on all host except alma8 we have libmpfr.so.6 installed and alma has libmpfr.so.4
<khem>
if its looking for mpfr on build host then it will be problem we need to either abstract it and remove the dependency
<khem>
./yocto-worker/edgerouter-alt/build/build/tmp/work/mips64-poky-linux/libgcc/11.4.0-r0/build/gcc/cc1: error while loading shared libraries: libmpfr.so.6: cannot open shared object file: No such file or directory
<khem>
and this works
<khem>
LD_LIBRARY_PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/lib /home/pokybuild/yocto-worker/edgerouter-alt/build/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 ./yocto-worker/edgerouter-alt/build/build/tmp/work/mips64-poky-linux/libgcc/11.4.0-r0/build/gcc/cc1 -version... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/56488c4366363f0b67821212046b0c8eb3ecf723>)
<khem>
I am just thinking that we should perhaps build gcc in unified tree
<khem>
and avoid these dependencies
<khem>
basically have local copies of mpfr/mpc/gmp sources in gcc combined source tree when building gcc
<sakoman>
Any idea why we only have seen this on dunfell?
<sakoman>
Just "luck"?
<khem>
could be that
<khem>
is uninative version same across all releases, I dont know
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sakoman>
Just checked, both master and dunfell are at uninative 4.0
<khem>
yeah
<khem>
I thought when I source buildtools-tarball SDK then it will add it to lib search path too but it does not
<khem>
so perhaps its only tooled to be used during building of something native but not used when using a binary that needs something from it
<khem>
or atleast that would be one issue
<sakoman>
Sadly this is all way out of my league, I don't even know enough to be dangerous!
<khem>
yeah no worries 🙂
<sakoman>
I have a concrete contractor knocking at the door now -- need to go show him what work needs to be done
<sakoman>
Thanks for looking into this!
<khem>
no worries,
<khem>
maybe RP will peruse through IRC logs when he wakes up, critically we need to see why binary is not using libmpfr.so.6 from buildtools-tarball basically
Ablu has quit [Ping timeout: 246 seconds]
Ablu has joined #yocto
Circuitsoft has quit [Quit: Connection closed for inactivity]
<RP>
khem: I suspect we should be using libmpfr from the recipe-sysroot-native of that recipe
<LetoThe2nd>
yo dudX
mckoan|away is now known as mckoan
<mckoan>
good morning
rfuentess has joined #yocto
ray-san has quit [Ping timeout: 245 seconds]
frieder has joined #yocto
ray-san has joined #yocto
JerryM has joined #yocto
zpfvo has joined #yocto
Vonter has quit [Ping timeout: 250 seconds]
leon-anavi has joined #yocto
xmn has quit [Quit: ZZZzzz…]
davidinux has quit [Quit: WeeChat 3.5]
florian has joined #yocto
<LetoThe2nd>
yo mckoan
vladest has joined #yocto
Vonter has joined #yocto
brrm has quit [Ping timeout: 246 seconds]
<mckoan>
hey LetoThe2nd
davidinux has joined #yocto
davidinux has quit [Client Quit]
davidinux has joined #yocto
brrm has joined #yocto
xmn has joined #yocto
Vonter has quit [Ping timeout: 250 seconds]
Vonter has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
xmn has quit [Ping timeout: 260 seconds]
Kubu_work has joined #yocto
Guest21 has joined #yocto
<Guest21>
A simple question: where does the result to uname is set in the configuration of the kernel?
el_gatito has joined #yocto
<JerryM>
is it save to have a layer (without .bb files) where BBFILE_COLLECTIONS is not set/appended in layer.conf ?
<JerryM>
it's a layer where I've only got files in meta/lib to extend bitbake functionality
prabhakarlad has joined #yocto
<Guest21>
A simple question: where does the result to uname is set in the configuration of the kernel?
<RP>
JerryM: if it is working without warnings/errors that should be ok
<RP>
Guest21: I know it comes from sys/utsname.h if that helps, something like UTS_NAME in the kernel sources
jonesv has joined #yocto
<jonesv>
hello :). I am having a hard time building a `linux-msm` recipe, because it doesn't find some *.dtb files. I get error messages like `arch/arm64/boot/dts/vendor/qcom/kona-v2.1-iot-rb5.dtb: No such file or directory`
<jonesv>
Though I do have the *.dts / *.dtsi, and I am assuming that something somewhere should build them. Is there a canonical way of doing that for linux-msm, or is it happening in this custom layer I am trying to build?
<jonesv>
(reading the linux-msm.bb, it feels like it does some dtb building from `dts/`, but here it is in `dts/vendor`
<alessioigor>
Which make Bitbake uses to build software? Is the make provided by the build machine (4.1 in Ubuntu 18.04) or the make provided by recipe (4.3)?
<KanjiMonster>
jonesv: dtsi aren't built directly, these are included by .dts files. e.g. kona-v2.1-iot-rb5.dtb is built from kona-v2.1-iot-rb5.dts, which presumably includes kona-v2.1-iot-rb5.dtsi
<jonesv>
Yes, that is what I figured. It seems like the Makefile does include all of those. I just don't get who would be calling that Makefile
<jonesv>
Like is it a very custom way of doing it, or is it usual in Yocto to have such a Makefile there? I don't see it being called in the .bbappend
<jonesv>
Or should I call it manually? I did not even try that actually
<jonesv>
(but I don't see a target there, so I don't really get that Makefile)
<LetoThe2nd>
jonesv: as already pointed out, dtsis are not built directly. just like you're not calling the c compiler on an include header.
<LetoThe2nd>
jonesv: there are some variations of doing kernel things in Yocto, and every bsp vendor essentially whacks things just up. the one that you linked is a perfect example for that.
<jonesv>
LetoThe2nd: haha yeah, they make this weird Ubuntu image from Yocto, I am not a very big fan of that, but I need to build their kernel :-)
florian has quit [Ping timeout: 245 seconds]
zkrx has quit [Ping timeout: 244 seconds]
<jonesv>
LetoThe2nd: Not sure I understand the include header comparison, though. Do you mean that the dts/dtsi are not enough to build a dtb? I'll go read about that... let me know if you have a keyword of stuff I should read to try to understand what's happening there
<LetoThe2nd>
jonesv: you can build a dts, resulting in a dtb. you cannot build a dtsi.
zkrx has joined #yocto
<jonesv>
LetoThe2nd: but I do have m0054-kona-v2.1-iot-rb5.dts, and a bunch of dtsi (which I thought were just includes for a dts)
<LetoThe2nd>
jonesv: yes. and if you build the dts, those are automatically pulled into it.
<jonesv>
LetoThe2nd: and the Makefile seems to be targeting this m0054-kona-v2.1-iot-rb5.dts. It's just that I can't go there and run `make` (it says "no targets")
<KanjiMonster>
let's not get sidetracked too much about the dtsi/dts stuff; from the error message it seems it is not (trying to) build kona-v2.1-iot-rb5.dtb
<jonesv>
KanjiMonster: right. The `.dtb` does not exist anywhere, so it is not built. From what you are saying, it seems like it's not supposed to happen magically when building the kernel, so I guess they call this Makefile somehow somewhere, and I need to find that, right?
<KanjiMonster>
jonesv: depends. IIRC yocto supports out-of-tree dtb builds, but if you want to build it as part of the kernel there needs to be a Makefile that builds it
<LetoThe2nd>
.. which takes us back to why vendor bsps are a constant source of pain.
<jonesv>
KanjiMonster: ok let me read about out-of-tree dtb builds... But I get that error message when I build the whole image too, not just the `linux-msm` recipe. So I suspect something else is off
<jonesv>
LetoThe2nd: yeah, that too. I don't know if the comparison is right, but to me it's a bit like all those complaints I read about CMake from people who use CMake wrong. Okay, CMake is not perfect (nothing is), but if you use it right, I think it's fine (for most projects). It's just that most CMakeLists.txt out there are a big mess.
<jonesv>
LetoThe2nd: Same for Yocto: I have seen more Yocto builds that were a big mess than actually clean ones. Of course it's hard, if it is a mess.
<074AAANB9>
Hi, I have a build issue that appear sudently, I don't know how to solve it and google doesn't helps me :
<074AAANB9>
package jailhouse requires kernel-module-jailhouse, but none of the providers can be installed
074AAANB9 is now known as _Tyaku
<_Tyaku>
"Solution 1: do not ask to install a package providing jailhouse"
<LetoThe2nd>
_Tyaku: "suddenly" means "it worked always until ...?"
<_Tyaku>
I do a "bitbake -c cleansstate linux-imx" previously
<_Tyaku>
I don't know what is jailhouse package
<_Tyaku>
And it's not a package from my yocto-layers
<_Tyaku>
package jailhouse-0.12-r0.hub_mz_maquette_poseidom requires kernel-module-jailhouse-5.10.52-lts-5.10.y-az-p01+gc0343b5ab8de, but none of the providers can be installed
<_Tyaku>
nothing provides kernel-5.10.52-lts-5.10.y-az-p01+gc0343b5ab8de needed by kernel-module-jailhouse-5.10.52-lts-5.10.y-az-p01+gc0343b5ab8de-0.12-r0.hub_mz_maquette_poseidom
<expert[m]>
So how do you look like you are productive at work when doing a compile from scratch?
<xantoz>
I dunno. At the previous place, I ended up lobbying for a faster build machine to get my builds from scratch to be faster
<expert[m]>
I seem to be coming back to the same problem with every build: for some reason it keeps adding a window manager, I've removed it so far, but is there any way to make it obvious (configure error or something ) if graphics is included ?
<expert[m]>
when I removed Xorg as an option bitbake just added Wayland 😃
<LetoThe2nd>
expert[m]: then my suggestion would be to look busy by actually removing things properly instead of building :-) pro tip: in Yocto land, its almost always better to start small and add, instead of taking a bloat setup and try to remove things.
<rburton>
expert[m]: remove x11 and wayland DISTRO_FEATURES, then you can't build those
<jonesv>
KanjiMonster: hmm I tried with `KERNEL_DEVICE = "vendor/qcom/m0054-kona-v2.1-iot-rb5.dts"` but it doesn't seem to change anything :(
<KanjiMonster>
jonesv: somehow I dropped the ..TREE, KERNEL_DEVICETREE is the variablename (unless you fixed that up yourself)
<KanjiMonster>
also that should be *.dtb, not *.dts
otavio_ has joined #yocto
otavio_ has quit [Client Quit]
otavio_ has joined #yocto
<jonesv>
KanjiMonster: oh now it does something: `make[3]: *** No rule to make target 'arch/arm64/boot/dts/vendor/qcom/m0054-kona-v2.1-iot-rb5.dtb'. Stop.` Not sure how bad that is. Also that is apparently a Yocto 2.8 system, I wonder if KERNEL_DEVICETREE did not come with Yocto 3 (from what I saw in the docs)
<jonesv>
KanjiMonster: but at least `KERNEL_DEVICETREE` did something, since it now apparently tries to run `make` for it
Vonter has quit [Ping timeout: 246 seconds]
<jonesv>
(would have been nice if this had called the Makefile xD)
<KanjiMonster>
jonesv: might be that this depends on kernel changes introduced in a later kernel
<jonesv>
I am not super good with Makefiles, but it feels like the build system wants the target `arch/arm64/boot/dts/vendor/qcom/m0054-kona-v2.1-iot-rb5.dtb`, and the Makefile defines `m0054-kona-v2.1-iot-rb5.dtb`?
xmn has joined #yocto
<KanjiMonster>
jonesv: yocto is calling the kernel's Makefile, not the one added by the recipe. And it might be that compiling any dtb is a feature that was added after 4.9
<KanjiMonster>
maybe not the issue
<jonesv>
KanjiMonster: but I added a "blah" at the beginning of the recipe's Makefile, and the build failed with "missing separator"... which suggests that the recipe's Makefile is being called, right?
<jonesv>
I just don't understand what the recipe's Makefile does :/. I don't see it define any task
<jonesv>
It's sooo frustrating. If it was done correctly I would be learning about Yocto right now. But they make a mess, so I'm just trying to reverse engineering their mess.
<KanjiMonster>
jonesv: can you open a devshell and check if arch/arm64/boot/dts/vendor/qcom/m0054-kona-v2.1-iot-rb5.dts exists? (e.g. make -c devshell virtual/kernel)
kpo has joined #yocto
tepperson has joined #yocto
ray-san has quit [Ping timeout: 246 seconds]
Xagen has joined #yocto
<jonesv>
KanjiMonster: I assume you meant `bitbake -c devshell virtual/kernel`. And `arch/arm64/boot/dts/vendor/qcom/m0054-kona-v2.1-iot-rb5.dts` does not exist, but `arch/arm64/boot/dts/vendor/qcom/kona-v2.1-iot-rb5.dts` does (the `m0054` prefix is removed by the recipe when the file is copied)
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
amsobr has joined #yocto
<KanjiMonster>
jonesv: ah, then you probably just need to drop it from your KERNEL_DEVICETREE definition as well and it should then work
sakoman has joined #yocto
<jonesv>
KanjiMonster: yes I'm trying that now :). Fingers crossed
<jonesv>
KanjiMonster: I think it's better (kona-v2.1-iot-rb5.dtb was generated), but none of the corresponding dtsi were (it complains about not finding the `.dtb` for each of the `.dtsi`).
<KanjiMonster>
there should be no dtb for a dtsi, only for dts
<jonesv>
oh right, so maybe it's just other dts files that I need to add to KERNEL_DEVICETREE?
<jonesv>
I lost the log output now, let me try again
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jonesv>
KanjiMonster: oh it seems like adding the others to KERNEL_DEVICETREE made it compile! \o/ thanks a lot for all the help! Let's see now what happens with the final image (if it gets there :) )
goliath has quit [Quit: SIGSEGV]
rber|res has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 246 seconds]
Xagen has joined #yocto
tepperson has quit [Quit: Client closed]
amitk has joined #yocto
prabhakarlad has joined #yocto
randomgeek has joined #yocto
JerryM has quit [Quit: Konversation terminated!]
<randomgeek>
Hi when trying to bitbake the gpsd daemon I am getting the below errors:
<randomgeek>
| gpsclient.c:17:10: fatal error: Python.h: No such file or directory
<randomgeek>
| 17 | #include <Python.h>
<randomgeek>
Anyone seen this issue?
<rburton>
probably a missing dependency on python and everyone who built it in the past has python-dev installed locally
<randomgeek>
rburton: ive installed python3-dev the host
<randomgeek>
but still getting this issue.
<randomgeek>
s/the host/on the host
<rburton>
yeah that't not the fix
<rburton>
try adding python3 to DEPENDS
tepperson has joined #yocto
<tepperson>
how can i update the clock on my board based on the modification time of a specific file? (automatically on boot rather than manually)
<neverpanic>
tepperson: write a small utility that does stat(2) on the file, converts its st_mtime into a struct timeval, and call settimeofday, then write a systemd service file to start it early during boot?
zelgomer has joined #yocto
florian has joined #yocto
<tepperson>
neverpanic: i was thinking that there was a built-in way already with a kernel config
<rburton>
randomgeek: old recipe without the inherit of python3native or pkgconfig?
<neverpanic>
tepperson: Not that i'm aware. This isn't really a common use-case outside of embedded devices, and it's easily solved from user space, so why would the kernel get involved?
<tepperson>
neverpanic: I was thinking it would be in the real-time-clock driver
<randomgeek>
rburton: you mean I changed DEPENDS to pyhton3-native instead?
<neverpanic>
tepperson: Why would it be? If you have a battery-backed RTC, you wouldn't need it.
<rburton>
randomgeek: no, i mean the recipe in master has an inherit of python3native and pkgconfig. are you using an old release without those
<rburton>
tepperson: bootmisc.sh literally does that already
<rburton>
(assuming sysv)
<rburton>
see meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
<randomgeek>
rburton: I was using Hardknott release. I'll try the latest thanks.
<rburton>
randomgeek: hardknott has been EOL since april 2022, so please do upgrade
grma has quit [Ping timeout: 245 seconds]
<randomgeek>
sure will do, thank you!
<tepperson>
rburton: ah thank you
rfuentess has quit [Remote host closed the connection]
goliath has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
el_gatito has quit [Ping timeout: 244 seconds]
mckoan is now known as mckoan|away
zpfvo has quit [Quit: Leaving.]
<khem>
RP: about cc1 missing libmpfr.so.6 you mean its a fully populated sysroot-native for gcc at that time ?
Vonter has joined #yocto
<khem>
cc1 is launched by gcc driver
<khem>
does this mean we always need to stage mpfr-native in every package build which uses c/c++
<khem>
since cc1 will always need this library to run
<khem>
I was thinking about using a combined source tree for gcc builds which will include a version of mpc/mpfr/gmp built as part of gcc and linked in statically
<khem>
its effectively same like staging the native versions of these libs in sysroot-native
<rfs613>
bit of a long shot: has anyone dealt with networkmanager deciding a device is "unmanaged"? i've checked the more obvious things, such as unmanaged-devices setting, but I cannot fivure out why it's ignoring eth0. FWIW this is on a yocto-built rootfs running under qemu with default (slirp) networking.
<khem>
sakoman: Are we editing it anyway using patchelf ?
<rfs613>
most of the google results are for older Ubuntu when they transitioned from netplan to networkmanager... that's not relevant here, the rootfs is built by yocto.
florian_kc has joined #yocto
<sakoman>
khem: I don't have a clue what the gcc/libcc recipes are doing!
<RP>
sakoman: khem: we probably do edit it as we relocate the binaries around
<RP>
probably with chrpath or patchelf, not sure which
<khem>
it seems to be relative to final location of cc1
<khem>
but we are using it in-place
<khem>
cc1 is being used from build/ not from recipe-sysroot-native here
<sakoman>
RP: greping dunfell sources for patchelf I don't see anything suspicious, but greping for chrpatch I do see a couple of places where pseudo uses chrpatch
<RP>
that is just tweaking it's own libraries so not the suspicious to me...
<RP>
I'm more wondering how the cc1 binary is moving around...
<khem>
sakoman: do you have in /home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/libgcc/9.5.0-r0/build/gcc/../../../recipe-sysroot-native
<khem>
if you do then $ORIGIN/../../../recipe-sysroot-native/usr/lib will find libmpfr.so.6 in native sysroot correctly for cc1 from libgcc build dir even
<sakoman>
$ ls /home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/libgcc/9.5.0-r0/build/gcc/../../../recipe-sysroot-native
<sakoman>
ls: cannot access '/home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/libgcc/9.5.0-r0/build/gcc/../../../recipe-sysroot-native': No such file or directory
<sakoman>
As I said above there is an extra "../" in the path. If I remove that then it succeeds
<khem>
% ls ./libgcc/13.2.0-r0/gcc-13.2.0/build.x86_64-yoe-linux-musl.x86_64-yoe-linux-musl/gcc/../../../recipe-sysroot-native/
<sakoman>
$ ls /home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/libgcc/9.5.0-r0/build/gcc/../../recipe-sysroot-native
<sakoman>
bin etc installeddeps sbin sysroot-providers usr var
<khem>
so I do have it referenced correctly but you dont
<sakoman>
Yes, so some change post dunfell? I have no clue where to even look!
<khem>
did you build this gcc locally ?
<khem>
in my build there is one more directory gcc-13.2.0 under BPN/PR/ your build does not
<khem>
so is it staged from somewhere cached ?
<khem>
mine is a fresh build
<khem>
local
<sakoman>
Yes, this is all built locally from dunfell head
<khem>
cool so that is consistent
<khem>
libgcc build uses a canned pre-built gcc tree
<khem>
see extract_stashed_builddir
<sakoman>
I did a -c cleansstate on gcc and libgcc and then rebuild prior to the above
<khem>
yeah thats ok
<khem>
it builds gcc-cross first and than stashes that tree away
<khem>
and brings it back when building compiler runtime stuff like gcc-runtime and libgcc etc.
<khem>
check the build dir of gcc-cross
<kergoth_>
Ugh, hitting pseudo issues on an ancient version, that's going to be a pain to deal with. Are there any consequences to upgrading pseudo in an old oe-core/bitbake environment?
<khem>
sakoman: e.g. I have /mnt/b/yoe/master/build/tmp/work/x86_64-linux/gcc-cross-x86_64/13.2.0-r0/gcc-13.2.0/build.x86_64-linux.x86_64-yoe-linux-musl/gcc/../../../recipe-sysroot-native/usr/lib/libmpfr.so.6
<khem>
thats from gcc-cross
<sakoman>
steve@hexa ~/builds/poky-contrib ((no branch)) $ ls /home/steve/builds/poky-contrib/build/tmp/work/x86_64-linux/gcc-cross-x86_64/9.5.0-r0/
<sakoman>
khem: with your patch I'm now seeing a directory structure more like master, and now the three ../ in the patch are correct: https://pastebin.com/r3mF1d86
<khem>
so can you launch cc1 successfully ?
<khem>
from build dir ?
<JaMa>
khem: yes, that's the same as what abelloni shared
<JaMa>
abelloni: there were also some changes in gnu-efi, not sure if it might be related
<sakoman>
JaMa: I will wait for you to give me the ok
<JaMa>
abelloni: you mean, confirm that it's not caused by efivar change?
<abelloni>
exactly
<JaMa>
thanks
<sakoman>
JaMa: it is now removed from the queue :-)
<JaMa>
sakoman: so it should be OK, but your call if you want to rather bring 23 commits and remove 5 .patch files or add 5 new .patch files
<abelloni>
I have a last culprit to test
<sakoman>
JaMa: I'm trying to close out the patch set for the 4.0.12 build, so how about I take it after the release?
<sakoman>
khem: I'll try a dunfell world build with your patch to see if anything blows up
mckoan_ has joined #yocto
<khem>
sakoman: yes that would be cool. Let me know how it goes and also see if original problem is fixed with this first
<khem>
then do world builds
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sakoman>
khem: OK, I'll do the world build locally, and simultaneously do an autobuilder run on alma8 to see if that still fails
<khem>
JaMa: abelloni recent gnu-efi recipe update is borked for RISCV64 and also on clang, there were many patches done to fix these issues immediately after 3.17 was released
mckoan|away has quit [Ping timeout: 246 seconds]
<khem>
sounds good
<JaMa>
it's also broken by -funwind-tables in TUNE_CCARGS (our tunes have it): since the upgrade to 3.0.17 t2.o(.ARM.exidx+0x0): error: undefined reference to '__aeabi_unwind_cpp_pr0'
<JaMa>
systemd-boot has the same issue, but we don't use either of them, so in the end I've just blacklisted both to keep my world builds cleean
<sakoman>
khem: it will be a while for the test, abelloni is hogging all the workers ;-)
<sakoman>
I need to make sure the first build isn't on an alma8 worker to populate sstate, then run the ptest on alma8 to try to trigger the old error
<khem>
its almost sleeping time in europe, then you can take over 🙂
<JaMa>
hehe I always queue tons of jobs on jenkins before going to bed :)
<JaMa>
and some jobs from yesterday, still didn't finish building today
<sakoman>
khem: other people do the same as JaMa! So often I can't take over!
<sakoman>
I'll get the first job queued and then do the alma8 job later
dgriego has quit [Ping timeout: 252 seconds]
dgriego has joined #yocto
<khem>
yeah I know, It was on a lighter note 🙂
Kubu_work has quit [Quit: Leaving.]
zkrx has quit [Ping timeout: 250 seconds]
zkrx has joined #yocto
<sakoman>
khem: the local world build is 85% done with no issues, autobuilder is still queued waiting for worker