Wednesday, 2023-08-02

*** tepperson <tepperson!~tepperson@> has quit IRC (Quit: Client closed)00:11
*** lexano <lexano!~lexano@> has quit IRC (Ping timeout: 245 seconds)00:18
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)00:32
*** qschulz <qschulz!> has joined #yocto00:34
sakomankhem: I assume running on the host since the log says "Executing on host: /home/pokybuild/yocto-worker/qemux86 ..."00:35
sakomanso that looks like it is running on the autobuilder worker00:35
khemOK, so I wonder where cc1 was built00:36
khemwas it on a different build host and reused from sstate when it failed ?00:36
sakomankhem: my theory is yes, reused from sstate00:38
sakomanNot really sure how to tell where it might have been built intially :-(00:38
sakomanIf you want to see the complete log:
khemif its running on host then problem seems to be that it was built on a host where is present in /usr/lib but alma-8 does not have
khembut it has older version -
sakomando we require that hosts have
khemare we using buildtools-tarball on alma8 ?00:42
khemif we are then we should add nativeskd-mpfr to it00:42
sakomanlet me check, I think we are using buildtools00:42
khemwe dont explicitly00:44
khemanother way would be to statically link it into gcc00:44
sakomanso to make sure I understand you, we should be using a buildtools that includes nativeskd-mpfr, since we currently don't explicitly include it00:44
khemthe problem to me looks like on all host except alma8 we have installed and alma has
khemif its looking for mpfr on build host then it will be problem we need to either abstract it and remove the dependency00:46
khem% ldd /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/cc1... (full message at <>)00:47
khemthats on my host archlinux box00:47
khemso cc1 is really needing libmpfr00:47
sakomansigh, for some reason I'm not able to ssh into the alma8 workers :-(00:48
khemalma8-ty-1 is accessible00:49
sakomanneither seem to have my key, so it is asking for a password00:49
sakomansigh, user error -- literally, I was trying to log in as user steve rather than sakoman :-)00:51 is not ABI compatible with
khemso if we really have to use it across board we need to stick to one00:52
khemso my suggestion would be to add it to buildtools-tarball and use buildtools-tarball on alma8 if we are not already doing it00:53
khemstatic linking might be a bit trickier since its not only cc1 needing it but also libmpc00:53
khemand maybe other apps/libs too00:53
khemmaybe there is a mpfr-6 package available for alma800:54
sakomanOK, I'll discuss this with Richard tomorrow00:54
sakomanWe definitely are using buildtools tarball with dunfell on alma800:54
khemubuntu 18.04 does have libmpfr6 package00:55
*** amsobr <amsobr!~amsobr@2a01:14:113:9e60:c700:4a82:a3fc:890c> has quit IRC (Quit: Konversation terminated!)00:55
khembut centos/alma8 might be a different story00:56
khemdnf search mpfr results only show one version00:58
khemso perhaps we might be out of luck from system pov00:58
sakomanI see dunfell is using an older version of buildtools, so that's also something for me to investigate01:00
khemhmm so it seems to be in buildtools-tarball installed on alma801:01
khem[pokybuild@alma8-ty-1 ~]$ find /opt/poky -name "libmpfr*"01:01
khemso now question is. are we sourcing it always when doing any yocto builds/tests01:01
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 246 seconds)01:03
khemsee -01:04
khem[pokybuild@alma8-ty-1 ~]$ ldd ./yocto-worker/edgerouter-alt/build/build/tmp/work/mips64-poky-linux/libgcc/11.4.0-r0/build/gcc/cc1... (full message at <>)01:04
sakomanyes, not found :-(01:05
*** davidinux <davidinux!~davidinux@> has joined #yocto01:05
sakomanbut so.4 is found01:05
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)01:08
khemor maybe it should be in uninative in this case01:09
khem[pokybuild@alma8-ty-1 ~]$ /home/pokybuild/yocto-worker/edgerouter-alt/build/build/tmp/sysroots-uninative/x86_64-linux/lib/ ./yocto-worker/edgerouter-alt/build/build/tmp/work/mips64-poky-linux/libgcc/11.4.0-r0/build/gcc/cc101:09
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: cannot open shared object file: No such file or directory01:09
khemand this works01:14
khemLD_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/ ./yocto-worker/edgerouter-alt/build/build/tmp/work/mips64-poky-linux/libgcc/11.4.0-r0/build/gcc/cc1 -version... (full message at <>)01:14
khemI am just thinking that we should perhaps build gcc in unified tree01:15
khemand avoid these dependencies01:15
khembasically have local copies of mpfr/mpc/gmp sources in gcc combined source tree when building gcc01:16
sakomanAny idea why we only have seen this on dunfell?01:16
sakomanJust "luck"?01:16
khemcould be that01:16
khemis uninative version same across all releases, I dont know01:17
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)01:17
sakomanJust checked, both master and dunfell are at uninative 4.001:17
khemI thought when I source buildtools-tarball SDK then it will add it to lib search path too but it does not01:19
khemso perhaps its only tooled to be used during building of something native  but not used when using a binary that needs something from it01:20
khemor atleast that would be one issue01:20
sakomanSadly this is all way out of my league, I don't even know enough to be dangerous!01:22
khemyeah no worries 🙂01:23
sakomanI have a concrete contractor knocking at the door now -- need to go show him what work needs to be done01:24
sakomanThanks for looking into this!01:24
khemno worries,01:25
khemmaybe RP will peruse through IRC logs when he wakes up, critically we need to see why binary is not using from buildtools-tarball basically01:26
*** Ablu <Ablu!~Ablu@user/Ablu> has quit IRC (Ping timeout: 246 seconds)01:41
*** Ablu <Ablu!~Ablu@user/Ablu> has joined #yocto01:43
*** Circuitsoft <Circuitsoft!> has quit IRC (Quit: Connection closed for inactivity)01:55
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto02:17
*** kpo <kpo!> has quit IRC (Ping timeout: 245 seconds)02:45
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto02:47
*** jclsn <jclsn!~jclsn@2a04:4540:651a:2b00:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 246 seconds)02:50
*** jclsn <jclsn!~jclsn@2a04:4540:651e:fd00:2ce:39ff:fecf:efcd> has joined #yocto02:52
*** otavio_ <otavio_!> has quit IRC (Ping timeout: 245 seconds)03:06
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)03:18
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto03:21
*** amitk <amitk!~amit@> has joined #yocto04:58
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)05:04
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 250 seconds)05:20
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:59
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 244 seconds)06:16
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 260 seconds)06:22
*** davidinux <davidinux!> has joined #yocto06:23
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:25
*** mvlad <mvlad!~mvlad@2a02:2f08:4c1b:8200:7656:3cff:fe3f:7ce9> has joined #yocto06:28
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto06:38
RPkhem: I suspect we should be using libmpfr from the recipe-sysroot-native of that recipe06:39
LetoThe2ndyo dudX06:39
*** mckoan|away is now known as mckoan06:43
mckoangood morning06:43
*** rfuentess <rfuentess!> has joined #yocto06:44
*** ray-san <ray-san!> has quit IRC (Ping timeout: 245 seconds)06:47
*** frieder <frieder!> has joined #yocto06:47
*** ray-san <ray-san!~ray-san@> has joined #yocto06:57
*** JerryM <JerryM!~jermain@> has joined #yocto07:10
*** zpfvo <zpfvo!> has joined #yocto07:11
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 250 seconds)07:14
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:19
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)07:24
*** davidinux <davidinux!> has quit IRC (Quit: WeeChat 3.5)07:29
*** florian <florian!> has joined #yocto07:33
LetoThe2ndyo mckoan07:39
*** vladest <vladest!> has joined #yocto07:41
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto07:47
*** brrm <brrm!> has quit IRC (Ping timeout: 246 seconds)07:48
mckoanhey LetoThe2nd07:48
*** davidinux <davidinux!~davidinux@> has joined #yocto07:50
*** davidinux <davidinux!~davidinux@> has quit IRC (Client Quit)07:52
*** davidinux <davidinux!~davidinux@> has joined #yocto07:53
*** brrm <brrm!> has joined #yocto07:53
*** xmn <xmn!> has joined #yocto08:03
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 250 seconds)08:04
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto08:05
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)08:10
*** xmn <xmn!> has quit IRC (Ping timeout: 260 seconds)08:11
*** Kubu_work <Kubu_work!> has joined #yocto08:19
*** Guest21 <Guest21!> has joined #yocto08:22
Guest21A simple question: where does the result to uname is set in the configuration of the kernel?08:23
*** el_gatito <el_gatito!> has joined #yocto08:23
JerryMis it save to have a layer (without .bb files) where BBFILE_COLLECTIONS is not set/appended in layer.conf ?08:26
JerryMit's a layer where I've only got files in meta/lib to extend bitbake functionality08:27
*** prabhakarlad <prabhakarlad!> has joined #yocto08:28
Guest21A simple question: where does the result to uname is set in the configuration of the kernel?08:29
RPJerryM: if it is working without warnings/errors that should be ok08:33
RPGuest21: I know it comes from sys/utsname.h if that helps, something like UTS_NAME in the kernel sources08:35
*** jonesv <jonesv!e7e4272e85@2604:bf00:561:2000::10b5> has joined #yocto08:43
jonesvhello :). 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`08:45
jonesvThough 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?08:46
jonesv(reading the, it feels like it does some dtb building from `dts/`, but here it is in `dts/vendor`08:47
alessioigorWhich 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)?08:48
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)08:49
jonesvIn other words I don't understand where those dtsi are being built:
*** alessioigor <alessioigor!~alessioig@> has joined #yocto08:50
LetoThe2ndjonesv: my *guess* is that the Makefile here does the trick:
KanjiMonsterjonesv: 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.dtsi08:57
jonesvYes, 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 Makefile08:58
jonesvLike 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 .bbappend08:58
jonesvOr should I call it manually? I did not even try that actually08:59
jonesv(but I don't see a target there, so I don't really get that Makefile)09:00
LetoThe2ndjonesv: as already pointed out, dtsis are not built directly. just like you're not calling the c compiler on an include header.09:01
LetoThe2ndjonesv: 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.09:02
jonesvLetoThe2nd: 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 :-)09:05
*** florian <florian!> has quit IRC (Ping timeout: 245 seconds)09:06
*** zkrx <zkrx!> has quit IRC (Ping timeout: 244 seconds)09:07
jonesvLetoThe2nd: 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 there09:07
LetoThe2ndjonesv: you can build a dts, resulting in a dtb. you cannot build a dtsi.09:08
*** zkrx <zkrx!> has joined #yocto09:08
jonesvLetoThe2nd: 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)09:09
LetoThe2ndjonesv: yes. and if you build the dts, those are automatically pulled into it.09:09
jonesvLetoThe2nd: 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")09:10
KanjiMonsterlet'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.dtb09:10
jonesvKanjiMonster: 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?09:11
KanjiMonsterjonesv: 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 it09:12
LetoThe2nd.. which takes us back to why vendor bsps are a constant source of pain.09:13
jonesvKanjiMonster: 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 off09:14
jonesvLetoThe2nd: 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.09:15
jonesvLetoThe2nd: 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.09:16
LetoThe2ndjonesv: see, and is a mess.09:16
jonesvLetoThe2nd: Would the proper way to use the out-of-tree dtb builds, like KanjiMonster mentioned?09:22
*** RobertBerger <RobertBerger!~rber|> has joined #yocto09:23
LetoThe2ndjonesv: probably yes09:24
jonesvRight xD. Well right now I'm stuck with their thing, I need to understand how this dtb is supposed to be built09:25
*** rber|res <rber|res!~rber|res@2001:871:20c:d916:35f8:efb7:f2e3:d435> has quit IRC (Ping timeout: 246 seconds)09:26
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto09:32
KanjiMonsterjonesv: you can try setting KERNEL_DEVICE as in (note it takes a relative path from the boot/dts dir, so you need to include any subdirectories), this should trigger compiling it regardless what the Makefiles say09:37
jonesvKanjiMonster: thanks, let me try that!09:40
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto09:43
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:50
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:50
*** kaolalong <kaolalong!~Guest37@> has joined #yocto10:00
*** kaolalong <kaolalong!~Guest37@> has quit IRC (Quit: Client closed)10:00
*** el_gatito <el_gatito!> has quit IRC (Ping timeout: 246 seconds)10:12
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)10:15
*** alessioigor <alessioigor!~alessioig@> has joined #yocto10:15
*** el_gatito <el_gatito!> has joined #yocto10:17
*** 074AAANB9 <074AAANB9!> has joined #yocto10:31
074AAANB9Hi, I have a build issue that appear sudently, I don't know how to solve it and google doesn't helps me :10:31
074AAANB9package jailhouse requires kernel-module-jailhouse, but none of the providers can be installed10:31
*** 074AAANB9 is now known as _Tyaku10:31
_Tyaku"Solution 1: do not ask to install a package providing jailhouse"10:32
LetoThe2nd_Tyaku: "suddenly" means "it worked always until ...?"10:33
_TyakuI do a "bitbake -c cleansstate linux-imx" previously10:38
_TyakuI don't know what is jailhouse package10:40
_TyakuAnd it's not a package from my yocto-layers10:40
_Tyakupackage 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 installed10:41
_Tyakunothing 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_poseidom10:41
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)10:55
*** Guest72 <Guest72!~Guest72@> has joined #yocto11:07
*** Guest72 <Guest72!~Guest72@> has quit IRC (Client Quit)11:08
rburton_Tyaku: jailhouse is part of meta-freescale
*** Guest21 <Guest21!> has quit IRC (Quit: Client closed)11:27
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Ping timeout: 252 seconds)11:34
expert[m]So how do you look like you are productive at work when doing a compile from scratch?11:53
xantozI dunno. At the previous place, I ended up lobbying for a faster build machine to get my builds from scratch to be faster11:55
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 ?12:04
expert[m]when I removed Xorg as an option bitbake just added Wayland 😃12:04
LetoThe2ndexpert[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.12:06
rburtonexpert[m]: remove x11 and wayland DISTRO_FEATURES, then you can't build those12:09
jonesvKanjiMonster: hmm I tried with `KERNEL_DEVICE = "vendor/qcom/m0054-kona-v2.1-iot-rb5.dts"` but it doesn't seem to change anything :(12:22
KanjiMonsterjonesv: somehow I dropped the ..TREE, KERNEL_DEVICETREE is the variablename (unless you fixed that up yourself)12:27
KanjiMonsteralso that should be *.dtb, not *.dts12:30
*** otavio_ <otavio_!> has joined #yocto12:33
*** otavio_ <otavio_!> has quit IRC (Client Quit)12:34
*** otavio_ <otavio_!> has joined #yocto12:34
jonesvKanjiMonster: 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)12:45
jonesvKanjiMonster: but at least `KERNEL_DEVICETREE` did something, since it now apparently tries to run `make` for it12:45
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)12:45
jonesv(would have been nice if this had called the Makefile xD)12:46
KanjiMonsterjonesv: might be that this depends on kernel changes introduced in a later kernel12:55
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto12:57
*** _Tyaku <_Tyaku!> has quit IRC (Quit: Lost terminal)12:58
jonesvKanjiMonster: actually it does call that Makefile somehow (just introduced an error there to confirm it fails).12:59
jonesvKanjiMonster: so it feels like it is not a Yocto problem. Just that the Makefile is not happy for some reason...13:00
jonesv(this guy:
jonesvI 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`?13:03
*** xmn <xmn!> has joined #yocto13:05
KanjiMonsterjonesv: 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.913:08
KanjiMonstermaybe not the issue13:11
jonesvKanjiMonster: 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?13:16
jonesvI just don't understand what the recipe's Makefile does :/. I don't see it define any task13:19
jonesvIt'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.13:20
KanjiMonsterjonesv: 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)13:28
*** kpo <kpo!> has joined #yocto13:36
*** tepperson <tepperson!~tepperson@> has joined #yocto13:37
*** ray-san <ray-san!~ray-san@> has quit IRC (Ping timeout: 246 seconds)13:41
*** Xagen <Xagen!> has joined #yocto13:47
jonesvKanjiMonster: 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)13:47
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)13:50
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto13:50
*** amsobr <amsobr!~amsobr@2a01:14:113:9e60:e644:20ff:ed62:f3a> has joined #yocto13:51
KanjiMonsterjonesv: ah, then you probably just need to drop it from your KERNEL_DEVICETREE definition as well and it should then work13:52
*** sakoman <sakoman!> has joined #yocto13:58
jonesvKanjiMonster: yes I'm trying that now :). Fingers crossed14:00
jonesvKanjiMonster: 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`).14:11
KanjiMonsterthere should be no dtb for a dtsi, only for dts14:12
jonesvoh right, so maybe it's just other dts files that I need to add to KERNEL_DEVICETREE?14:14
jonesvI lost the log output now, let me try again14:15
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)14:28
jonesvKanjiMonster: 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 :) )14:31
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:32
*** rber|res <rber|res!~rber|res@2001:4bb8:199:ed4f:4e84:bb11:6fad:a55e> has joined #yocto14:35
*** RobertBerger <RobertBerger!~rber|> has joined #yocto14:41
*** rber|res <rber|res!~rber|res@2001:4bb8:199:ed4f:4e84:bb11:6fad:a55e> has quit IRC (Ping timeout: 246 seconds)14:43
*** Xagen <Xagen!> has joined #yocto14:48
*** tepperson <tepperson!~tepperson@> has quit IRC (Quit: Client closed)15:18
*** amitk <amitk!~amit@> has joined #yocto15:21
*** prabhakarlad <prabhakarlad!> has joined #yocto15:22
*** randomgeek <randomgeek!> has joined #yocto15:22
*** JerryM <JerryM!~jermain@> has quit IRC (Quit: Konversation terminated!)15:23
randomgeekHi when trying to bitbake the gpsd daemon I am getting the below errors:15:23
randomgeek| gpsclient.c:17:10: fatal error: Python.h: No such file or directory15:23
randomgeek|    17 | #include <Python.h>15:23
randomgeekAnyone seen this issue?15:23
rburtonprobably a missing dependency on python and everyone who built it in the past has python-dev installed locally15:24
randomgeekrburton: ive installed python3-dev the host15:25
randomgeekbut still getting this issue.15:25
randomgeeks/the host/on the host15:25
rburtonyeah that't not the fix15:26
rburtontry adding python3 to DEPENDS15:27
*** tepperson <tepperson!~tepperson@> has joined #yocto15:27
teppersonhow can i update the clock on my board based on the modification time of a specific file? (automatically on boot rather than manually)15:28
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has quit IRC (Ping timeout: 240 seconds)15:30
randomgeekDEPENDS already has pyhton3 (DEPENDS = "dbus ncurses python3 pps-tools)15:30
neverpanictepperson: 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?15:32
*** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto15:32
*** florian <florian!> has joined #yocto15:32
teppersonneverpanic: i was thinking that there was a built-in way already with a kernel config15:33
rburtonrandomgeek: old recipe without the inherit of python3native or pkgconfig?15:33
neverpanictepperson: 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?15:36
teppersonneverpanic: I was thinking it would be in the real-time-clock driver15:37
randomgeekrburton: you mean I changed DEPENDS to pyhton3-native instead?15:38
neverpanictepperson: Why would it be? If you have a battery-backed RTC, you wouldn't need it.15:38
rburtonrandomgeek: no, i mean the recipe in master has an inherit of python3native and pkgconfig. are you using an old release without those15:39
rburtontepperson: literally does that already15:39
rburton(assuming sysv)15:39
rburtonsee meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh15:40
randomgeekrburton: I was using Hardknott release. I'll try the latest thanks.15:40
rburtonrandomgeek: hardknott has been EOL since april 2022, so please do upgrade15:40
*** grma <grma!~gruberm@> has quit IRC (Ping timeout: 245 seconds)15:43
randomgeeksure will do, thank you!15:43
teppersonrburton: ah thank you15:43
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)15:45
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:54
*** vladest <vladest!> has quit IRC (Quit: vladest)15:58
*** vladest <vladest!> has joined #yocto15:59
*** el_gatito <el_gatito!> has quit IRC (Ping timeout: 244 seconds)16:07
*** mckoan is now known as mckoan|away16:13
*** zpfvo <zpfvo!> has quit IRC (Quit: Leaving.)16:15
khemRP: about cc1 missing you mean its a fully populated sysroot-native for gcc at that time ?16:26
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto16:28
khemcc1 is launched by gcc driver16:28
khemdoes this mean we always need to stage mpfr-native in every package build which uses c/c++16:30
khemsince cc1 will always need this library to run16:32
khemI 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 statically16:33
khemits effectively same like staging the native versions of these libs in sysroot-native16:34
*** florian <florian!> has quit IRC (Ping timeout: 258 seconds)16:38
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has quit IRC (Quit: The Lounge -
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has joined #yocto16:40
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has quit IRC (Client Quit)16:41
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has joined #yocto16:41
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has quit IRC (Client Quit)16:43
*** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has joined #yocto16:43
*** florian <florian!> has joined #yocto16:51
*** tepperson <tepperson!~tepperson@> has quit IRC (Quit: Client closed)16:55
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)16:55
*** florian <florian!> has quit IRC (Ping timeout: 246 seconds)16:56
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 245 seconds)16:57
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 252 seconds)17:02
*** frieder <frieder!> has quit IRC (Remote host closed the connection)17:05
*** florian <florian!> has joined #yocto17:09
*** florian <florian!> has quit IRC (Ping timeout: 245 seconds)17:17
*** amitk <amitk!~amit@> has joined #yocto17:28
vvnwhat is the recommended way to fetch a given release (tag) for a github repo?17:28
*** florian <florian!> has joined #yocto17:30
RPkhem: it should always have that library in the recipe-sysroot-native, I'm puzzled about which case that wouldn't happen in :/17:39
sakomankhem: it appears that the runpath fr cc1 isn't quite right:
sakomanSeems to have an extra "../":
rfs613bit 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.17:52
khemsakoman: Are we editing it anyway using patchelf ?17:53
rfs613most 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.17:53
*** florian_kc <florian_kc!> has joined #yocto17:54
sakomankhem: I don't have a clue what the gcc/libcc recipes are doing!17:54
RPsakoman: khem: we probably do edit it as we relocate the binaries around17:55
RPprobably with chrpath or patchelf, not sure which17:55
khemit seems to be relative to final location of cc117:56
khembut we are using it in-place17:56
khemcc1 is being used from build/ not from recipe-sysroot-native here17:57
sakomanRP: 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 chrpatch17:58
sakomanmeta/recipes-devtools/pseudo/        chrpath ${D}${bindir}/pseudo -r `chrpath ${D}${bindir}/pseudo | cut -d = -f 2 | sed s/XORIGIN/\\$ORIGIN/`17:59
sakomanmeta/recipes-devtools/pseudo/        chrpath -d ${D}${prefix}/lib/pseudo/lib*/libpseudo.so17:59
RPsakoman: pseudo is a bit special ;-)18:00
RPthat is just tweaking it's own libraries so not the suspicious to me...18:00
RPI'm more wondering how the cc1 binary is moving around...18:00
khemsakoman: 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-native18:08
khemif you do then $ORIGIN/../../../recipe-sysroot-native/usr/lib will find in native sysroot correctly for cc1 from libgcc build dir even18:09
sakoman$ ls /home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/libgcc/9.5.0-r0/build/gcc/../../../recipe-sysroot-native18:09
sakomanls: 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 directory18:09
sakomanAs I said above there is an extra "../" in the path.  If I remove that then it succeeds18:10
khem[kraj@apollo /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl]18:11
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/18:11
khembin/  environment-setup.d/  etc/  installeddeps/  sysroot-providers/  usr/18:11
sakoman$ ls /home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/libgcc/9.5.0-r0/build/gcc/../../recipe-sysroot-native18:11
sakomanbin  etc  installeddeps  sbin  sysroot-providers  usr  var18:11
khemso I do have it referenced correctly but you dont18:11
sakomanYes, so some change post dunfell? I have no clue where to even look!18:13
khemdid you build this gcc locally ?18:14
khemin my build there is one more directory gcc-13.2.0 under BPN/PR/ your build does not18:15
khemso is it staged from somewhere cached ?18:15
khemmine is a fresh build18:15
sakomanYes, this is all built locally from dunfell head18:16
khemcool so that is consistent18:16
khemlibgcc build uses a canned pre-built gcc tree18:16
khemsee extract_stashed_builddir18:17
sakomanI did a -c cleansstate on gcc and libgcc and then rebuild prior to the above18:17
khemyeah thats ok18:17
khemit builds gcc-cross first and than stashes that tree away18:18
khemand brings it back when building compiler runtime stuff like gcc-runtime and libgcc etc.18:18
khemcheck the build dir of gcc-cross18:19
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?18:20
khemsakoman: 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/
khemthats from gcc-cross18:22
sakomansteve@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/18:23
sakomanlicense-destdir  sstate-install-gcc_stash_builddir  sstate-install-populate_lic  sstate-install-populate_sysroot  stashed-builddir  sysroot-destdir  temp18:23
sakomanI have no build.x86_64... directory there18:24
sakomanShould I rebuild gcc-cross to get that?18:24
khembut do you have some build*18:25
sakomannope, see the ls above for what is there18:25
khemso it got it from some sstate18:25
khemsstate-install-gcc_stash_builddir seems to indicate that18:26
sakomanshould I clean sstate and rebuild?18:26
sakoman(for gcc-cross)18:26
khemif you do that then I am afraid the problem will be gone18:26
khemso we need to grab the tarball of sstate element for this task and analyse it18:27
sakomanthere hasn't been a failure on this machine since ubuntu has the required library on the host18:29
sakomanso I suspect it will be exactly the same after a rebuild18:29
sakomanI'm guessing it has always been this way and we only see it now on alma8 since they don't have the require library version18:30
sakomanbut I'm happy to try to find the tarball if you can give me a hint on where to find it!18:31
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)18:35
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 245 seconds)18:41
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto18:43
khemOK mv the gcc-cross build dir to something so we can refer to it18:59
khemand then do a bitbake -ccompile gcc-cross-<arch>19:00
sakomankhem: same deal, an extra "../" :
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)19:35
*** alessioigor <alessioigor!~alessioig@> has joined #yocto19:36
sakomankhem: interestingly the library itself has the right number of ../
sakomankhem: breaking for lunch now, happy to run more experiments when I get back20:00
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Remote host closed the connection)20:06
*** amitk <amitk!~amit@> has quit IRC (Remote host closed the connection)20:13
*** Haxxa <Haxxa!> has quit IRC (Quit: Haxxa flies away.)20:15
*** Haxxa <Haxxa!> has joined #yocto20:17
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:18
*** mvlad <mvlad!~mvlad@2a02:2f08:4c1b:8200:7656:3cff:fe3f:7ce9> has quit IRC (Remote host closed the connection)20:29
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 264 seconds)20:35
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto20:37
khemabelloni: whats the testing status on binutils ?20:56
abelloniI think it is ok, I had oe-selftest failures that I attributed to it but I now think it is because of the efivar change from JaMa20:57
abelloniI have a build ongoing to confirm20:57
khemcool ok21:01
khemefivar change will be needed for lld21:01
*** ajfriesen847 <ajfriesen847!> has joined #yocto21:02
*** ajfriesen84 <ajfriesen84!> has quit IRC (Ping timeout: 250 seconds)21:03
*** ajfriesen847 is now known as ajfriesen8421:03
JaMaFWIW: efivar builds for me in nanbield with gold as well as lld, for kirkstone I had to backport couple commits from newer efivar21:06
abelloniJaMa: this is the failure I get:
khemsakoman: can you try this patch -
khemand rebuild gcc-cross and see if this sorts it out21:16
JaMaabelloni: aha, then it might be caused by my change, I don't use it anywhere in runtime yet (was just seeing build failure in world builds)21:16
*** florian_kc <florian_kc!> has joined #yocto21:25
khemRP: aha scarthgap -
khemGood thing is that is 2300ft higher than honister 🙂21:29
*** vladest <vladest!> has quit IRC (Ping timeout: 246 seconds)21:37
sakomankhem: with your patch I'm now seeing a directory structure more like master, and now the three ../ in the patch are correct:
khemso can you launch cc1 successfully ?21:40
khemfrom build dir ?21:40
JaMakhem: yes, that's the same as what abelloni shared21:40
sakomankhem: yes, I can21:44
JaMakhem: abelloni: LDFLAGS was added to efivar by rburton between meta-oe removal and adding it to oe-core
JaMathe changes from allows to use gold or lld for build (it was failing to build with gold even with the LDFLAGS set to bfd)21:47
abelloniJaMa: I think I had the issue without your patch just now21:47
JaMasakoman: please wait for ^^ to be resolved before taking
abelloniI confirm21:48
JaMaabelloni: there were also some changes in gnu-efi, not sure if it might be related21:49
sakomanJaMa: I will wait for you to give me the ok21:49
JaMaabelloni: you mean, confirm that it's not caused by efivar change?21:49
sakomanJaMa: it is now removed from the queue :-)21:51
JaMasakoman: 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 files21:52
abelloniI have a last culprit to test21:52
sakomanJaMa: I'm trying to close out the patch set for the 4.0.12 build, so how about I take it after the release?21:53
sakomankhem: I'll try a dunfell world build with your patch to see if anything blows up21:54
*** mckoan_ <mckoan_!> has joined #yocto21:56
khemsakoman: yes that would be cool. Let me know how it goes and also see if original problem is fixed with this first21:56
khemthen do world builds21:56
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)21:57
sakomankhem: OK, I'll do the world build locally, and simultaneously do an autobuilder run on alma8 to see if that still fails21:58
khemJaMa: 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 released21:58
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 246 seconds)21:58
khemsounds good21:58
JaMait'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'21:59
JaMasystemd-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 cleean22:00
sakomankhem: it will be a while for the test, abelloni is hogging all the workers ;-)22:05
sakomanI 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 error22:06
khemits almost sleeping time in europe, then you can take over 🙂22:07
JaMahehe I always queue tons of jobs on jenkins before going to bed :)22:07
JaMaand some jobs from yesterday, still didn't finish building today22:08
sakomankhem: other people do the same as JaMa!  So often I can't take over!22:08
sakomanI'll get the first job queued and then do the alma8 job later22:09
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 252 seconds)22:12
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto22:14
khemyeah I know, It was on a lighter note 🙂22:30
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)22:33
*** zkrx <zkrx!> has quit IRC (Ping timeout: 250 seconds)22:49
*** zkrx <zkrx!> has joined #yocto22:55
sakomankhem: the local world build is 85% done with no issues, autobuilder is still queued waiting for worker23:05
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 244 seconds)23:24

Generated by 2.17.2 by Marius Gedminas - find it at!