| *** tepperson <tepperson!~tepperson@24.144.20.149> has quit IRC (Quit: Client closed) | 00:11 | |
| *** lexano <lexano!~lexano@174.119.69.134> has quit IRC (Ping timeout: 245 seconds) | 00:18 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 00:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:34 | |
| sakoman | khem: I assume running on the host since the log says "Executing on host: /home/pokybuild/yocto-worker/qemux86 ..." | 00:35 |
|---|---|---|
| sakoman | so that looks like it is running on the autobuilder worker | 00:35 |
| khem | OK, so I wonder where cc1 was built | 00:36 |
| khem | was it on a different build host and reused from sstate when it failed ? | 00:36 |
| sakoman | khem: my theory is yes, reused from sstate | 00:38 |
| sakoman | Not really sure how to tell where it might have been built intially :-( | 00:38 |
| sakoman | If you want to see the complete log: http://builder.sakoman.com/downloads/gcc.log | 00:39 |
| 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 | 00:40 |
| khem | but it has older version - libmpfr.so.4 | 00:40 |
| sakoman | do we require that hosts have libmpfr.so? | 00:42 |
| khem | are we using buildtools-tarball on alma8 ? | 00:42 |
| khem | if we are then we should add nativeskd-mpfr to it | 00:42 |
| sakoman | let me check, I think we are using buildtools | 00:42 |
| sakoman | yes: https://git.yoctoproject.org/yocto-autobuilder-helper/commit/?h=dunfell&id=23635c59db9e62e42d824ec1d6dcf9dc52a23ffa | 00:42 |
| khem | we dont explicitly | 00:44 |
| khem | another way would be to statically link it into gcc | 00:44 |
| 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 | 00:44 |
| khem | the problem to me looks like on all host except alma8 we have libmpfr.so.6 installed and alma has libmpfr.so.4 | 00:45 |
| khem | if its looking for mpfr on build host then it will be problem we need to either abstract it and remove the dependency | 00:46 |
| khem | % ldd /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/cc1... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/aaae747a0fd337d61d1af9f1d9331ed2b61943b1>) | 00:47 |
| khem | thats on my host archlinux box | 00:47 |
| khem | so cc1 is really needing libmpfr | 00:47 |
| sakoman | sigh, for some reason I'm not able to ssh into the alma8 workers :-( | 00:48 |
| khem | alma8-ty-1 is accessible | 00:49 |
| sakoman | neither seem to have my key, so it is asking for a password | 00:49 |
| khem | ok | 00:51 |
| sakoman | sigh, user error -- literally, I was trying to log in as user steve rather than sakoman :-) | 00:51 |
| khem | libmpfr.so.6 is not ABI compatible with libmpfr.so.4 | 00:51 |
| khem | so if we really have to use it across board we need to stick to one | 00:52 |
| khem | so my suggestion would be to add it to buildtools-tarball and use buildtools-tarball on alma8 if we are not already doing it | 00:53 |
| khem | static linking might be a bit trickier since its not only cc1 needing it but also libmpc | 00:53 |
| khem | and maybe other apps/libs too | 00:53 |
| khem | maybe there is a mpfr-6 package available for alma8 | 00:54 |
| sakoman | OK, I'll discuss this with Richard tomorrow | 00:54 |
| sakoman | We definitely are using buildtools tarball with dunfell on alma8 | 00:54 |
| khem | ubuntu 18.04 does have libmpfr6 package | 00:55 |
| *** amsobr <amsobr!~amsobr@2a01:14:113:9e60:c700:4a82:a3fc:890c> has quit IRC (Quit: Konversation terminated!) | 00:55 | |
| khem | but centos/alma8 might be a different story | 00:56 |
| khem | dnf search mpfr results only show one version | 00:58 |
| khem | so perhaps we might be out of luck from system pov | 00:58 |
| sakoman | I see dunfell is using an older version of buildtools, so that's also something for me to investigate | 01:00 |
| khem | hmm so it seems to be in buildtools-tarball installed on alma8 | 01:01 |
| khem | [pokybuild@alma8-ty-1 ~]$ find /opt/poky -name "libmpfr*" | 01:01 |
| khem | /opt/poky/sysroots/x86_64-pokysdk-linux/usr/lib/libmpfr.so.6.1.0 | 01:01 |
| khem | /opt/poky/sysroots/x86_64-pokysdk-linux/usr/lib/libmpfr.so.6 | 01:01 |
| khem | so now question is. are we sourcing it always when doing any yocto builds/tests | 01:01 |
| *** davidinux <davidinux!~davidinux@45.11.82.249> has quit IRC (Ping timeout: 246 seconds) | 01:03 | |
| khem | see - | 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 <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6b4b1a8fa45bac36d1b4a0d5e30a43524add8bfd>) | 01:04 |
| sakoman | yes, not found :-( | 01:05 |
| *** davidinux <davidinux!~davidinux@45.11.82.245> has joined #yocto | 01:05 | |
| sakoman | but so.4 is found | 01:05 |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 01:08 | |
| khem | or maybe it should be in uninative in this case | 01:09 |
| khem | [pokybuild@alma8-ty-1 ~]$ /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 | 01: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: libmpfr.so.6: cannot open shared object file: No such file or directory | 01:09 |
| khem | and this works | 01:14 |
| 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>) | 01:14 |
| khem | I am just thinking that we should perhaps build gcc in unified tree | 01:15 |
| khem | and avoid these dependencies | 01:15 |
| khem | basically have local copies of mpfr/mpc/gmp sources in gcc combined source tree when building gcc | 01:16 |
| sakoman | Any idea why we only have seen this on dunfell? | 01:16 |
| sakoman | Just "luck"? | 01:16 |
| khem | could be that | 01:16 |
| khem | is uninative version same across all releases, I dont know | 01:17 |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 01:17 | |
| sakoman | Just checked, both master and dunfell are at uninative 4.0 | 01:17 |
| khem | yeah | 01:19 |
| khem | I thought when I source buildtools-tarball SDK then it will add it to lib search path too but it does not | 01:19 |
| 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 | 01:20 |
| khem | or atleast that would be one issue | 01:20 |
| sakoman | Sadly this is all way out of my league, I don't even know enough to be dangerous! | 01:22 |
| khem | yeah no worries 🙂 | 01:23 |
| sakoman | I have a concrete contractor knocking at the door now -- need to go show him what work needs to be done | 01:24 |
| sakoman | Thanks for looking into this! | 01:24 |
| khem | no worries, | 01:25 |
| 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 | 01:26 |
| *** Ablu <Ablu!~Ablu@user/Ablu> has quit IRC (Ping timeout: 246 seconds) | 01:41 | |
| *** Ablu <Ablu!~Ablu@user/Ablu> has joined #yocto | 01:43 | |
| *** Circuitsoft <Circuitsoft!uid393878@id-393878.lymington.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 01:55 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 02:17 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 02:17 | |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has quit IRC (Ping timeout: 245 seconds) | 02:45 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 02: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 #yocto | 02:52 | |
| *** otavio_ <otavio_!~otavio@189-11-177-7.user3p.brasiltelecom.net.br> 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 #yocto | 03:21 | |
| *** amitk <amitk!~amit@58.84.61.42> has joined #yocto | 04:58 | |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 05:04 | |
| *** amitk <amitk!~amit@58.84.61.42> has quit IRC (Ping timeout: 250 seconds) | 05:20 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:59 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 244 seconds) | 06:16 | |
| *** davidinux <davidinux!~davidinux@45.11.82.245> has quit IRC (Ping timeout: 260 seconds) | 06:22 | |
| *** davidinux <davidinux!~davidinux@host-87-5-68-48.retail.telecomitalia.it> has joined #yocto | 06:23 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:25 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4c1b:8200:7656:3cff:fe3f:7ce9> has joined #yocto | 06:28 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 06:38 | |
| RP | khem: I suspect we should be using libmpfr from the recipe-sysroot-native of that recipe | 06:39 |
| LetoThe2nd | yo dudX | 06:39 |
| *** mckoan|away is now known as mckoan | 06:43 | |
| mckoan | good morning | 06:43 |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 06:44 | |
| *** ray-san <ray-san!~ray-san@ip5b42c32d.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 245 seconds) | 06:47 | |
| *** frieder <frieder!~frieder@i577B9216.versanet.de> has joined #yocto | 06:47 | |
| *** ray-san <ray-san!~ray-san@195.50.168.194> has joined #yocto | 06:57 | |
| *** JerryM <JerryM!~jermain@149.3.168.10> has joined #yocto | 07:10 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE34.versanet.de> has joined #yocto | 07:11 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 250 seconds) | 07:14 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:19 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 07:24 | |
| *** davidinux <davidinux!~davidinux@host-87-5-68-48.retail.telecomitalia.it> has quit IRC (Quit: WeeChat 3.5) | 07:29 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:33 | |
| LetoThe2nd | yo mckoan | 07:39 |
| *** vladest <vladest!~Thunderbi@88-103-237-26.rci.o2.cz> has joined #yocto | 07:41 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 07:47 | |
| *** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> has quit IRC (Ping timeout: 246 seconds) | 07:48 | |
| mckoan | hey LetoThe2nd | 07:48 |
| *** davidinux <davidinux!~davidinux@194.34.233.241> has joined #yocto | 07:50 | |
| *** davidinux <davidinux!~davidinux@194.34.233.241> has quit IRC (Client Quit) | 07:52 | |
| *** davidinux <davidinux!~davidinux@194.34.233.241> has joined #yocto | 07:53 | |
| *** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> has joined #yocto | 07:53 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 08:03 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 250 seconds) | 08:04 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 08:05 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds) | 08:10 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 260 seconds) | 08:11 | |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has joined #yocto | 08:19 | |
| *** Guest21 <Guest21!~Guest62@host-89-241-87-58.as13285.net> has joined #yocto | 08:22 | |
| Guest21 | A simple question: where does the result to uname is set in the configuration of the kernel? | 08:23 |
| *** el_gatito <el_gatito!~thomas@2a02-a466-e8b5-fd--15.fixed6.kpn.net> has joined #yocto | 08:23 | |
| JerryM | is it save to have a layer (without .bb files) where BBFILE_COLLECTIONS is not set/appended in layer.conf ? | 08:26 |
| JerryM | it's a layer where I've only got files in meta/lib to extend bitbake functionality | 08:27 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:28 | |
| Guest21 | A simple question: where does the result to uname is set in the configuration of the kernel? | 08:29 |
| RP | JerryM: if it is working without warnings/errors that should be ok | 08:33 |
| RP | Guest21: I know it comes from sys/utsname.h if that helps, something like UTS_NAME in the kernel sources | 08:35 |
| *** jonesv <jonesv!e7e4272e85@2604:bf00:561:2000::10b5> has joined #yocto | 08:43 | |
| 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` | 08:45 |
| 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? | 08:46 |
| jonesv | (reading the linux-msm.bb, it feels like it does some dtb building from `dts/`, but here it is in `dts/vendor` | 08:47 |
| 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)? | 08:48 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 08:49 | |
| jonesv | In other words I don't understand where those dtsi are being built: https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/master/recipes-kernel/linux-msm/linux-msm_4.19.bbappend?ref_type=heads#L55-65 | 08:49 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 08:50 | |
| LetoThe2nd | jonesv: my *guess* is that the Makefile here does the trick: https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/master/recipes-kernel/linux-msm/files/dts/Makefile?ref_type=heads | 08:56 |
| 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 | 08:57 |
| 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 | 08:58 |
| 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 | 08:58 |
| jonesv | Or should I call it manually? I did not even try that actually | 08:59 |
| jonesv | (but I don't see a target there, so I don't really get that Makefile) | 09:00 |
| LetoThe2nd | jonesv: as already pointed out, dtsis are not built directly. just like you're not calling the c compiler on an include header. | 09:01 |
| 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. | 09:02 |
| 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 :-) | 09:05 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 245 seconds) | 09:06 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-154.adslplus.ch> has quit IRC (Ping timeout: 244 seconds) | 09:07 | |
| 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 | 09:07 |
| LetoThe2nd | jonesv: you can build a dts, resulting in a dtb. you cannot build a dtsi. | 09:08 |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-154.adslplus.ch> has joined #yocto | 09:08 | |
| 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) | 09:09 |
| LetoThe2nd | jonesv: yes. and if you build the dts, those are automatically pulled into it. | 09:09 |
| 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") | 09:10 |
| 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 | 09:10 |
| 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? | 09:11 |
| 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 | 09:12 |
| LetoThe2nd | .. which takes us back to why vendor bsps are a constant source of pain. | 09:13 |
| 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 | 09:14 |
| 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. | 09:15 |
| 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. | 09:16 |
| LetoThe2nd | jonesv: see, and https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/master/recipes-kernel/linux-msm/linux-msm_4.19.bbappend?ref_type=heads is a mess. | 09:16 |
| jonesv | LetoThe2nd: Would the proper way to use the out-of-tree dtb builds, like KanjiMonster mentioned? | 09:22 |
| *** RobertBerger <RobertBerger!~rber|res@62-46-95-212.adsl.highway.telekom.at> has joined #yocto | 09:23 | |
| LetoThe2nd | jonesv: probably yes | 09:24 |
| jonesv | Right xD. Well right now I'm stuck with their thing, I need to understand how this dtb is supposed to be built | 09: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!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 09:32 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 09:32 | |
| KanjiMonster | jonesv: you can try setting KERNEL_DEVICE as in https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf#n30 (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 say | 09:37 |
| jonesv | KanjiMonster: thanks, let me try that! | 09:40 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 09:43 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 09:50 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 09:50 | |
| *** kaolalong <kaolalong!~Guest37@205.251.233.239> has joined #yocto | 10:00 | |
| *** kaolalong <kaolalong!~Guest37@205.251.233.239> has quit IRC (Quit: Client closed) | 10:00 | |
| *** el_gatito <el_gatito!~thomas@2a02-a466-e8b5-fd--15.fixed6.kpn.net> has quit IRC (Ping timeout: 246 seconds) | 10:12 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 10:15 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:15 | |
| *** el_gatito <el_gatito!~thomas@2a02-a466-e8b5-fd--15.fixed6.kpn.net> has joined #yocto | 10:17 | |
| *** 074AAANB9 <074AAANB9!~Tyaku@lfbn-orl-1-202-97.w92-152.abo.wanadoo.fr> has joined #yocto | 10:31 | |
| 074AAANB9 | Hi, I have a build issue that appear sudently, I don't know how to solve it and google doesn't helps me : | 10:31 |
| 074AAANB9 | package jailhouse requires kernel-module-jailhouse, but none of the providers can be installed | 10:31 |
| *** 074AAANB9 is now known as _Tyaku | 10: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 |
| _Tyaku | I do a "bitbake -c cleansstate linux-imx" previously | 10:38 |
| _Tyaku | I don't know what is jailhouse package | 10:40 |
| _Tyaku | And it's not a package from my yocto-layers | 10:40 |
| _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 | 10:41 |
| _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 | 10:41 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 10:55 | |
| *** Guest72 <Guest72!~Guest72@92.79.125.166> has joined #yocto | 11:07 | |
| *** Guest72 <Guest72!~Guest72@92.79.125.166> has quit IRC (Client Quit) | 11:08 | |
| rburton | _Tyaku: jailhouse is part of meta-freescale https://layers.openembedded.org/layerindex/recipe/131664/ | 11:11 |
| *** Guest21 <Guest21!~Guest62@host-89-241-87-58.as13285.net> has quit IRC (Quit: Client closed) | 11:27 | |
| *** RobertBerger <RobertBerger!~rber|res@62-46-95-212.adsl.highway.telekom.at> 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 |
| 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 | 11: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 |
| 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. | 12:06 |
| rburton | expert[m]: remove x11 and wayland DISTRO_FEATURES, then you can't build those | 12:09 |
| 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 :( | 12:22 |
| KanjiMonster | jonesv: somehow I dropped the ..TREE, KERNEL_DEVICETREE is the variablename (unless you fixed that up yourself) | 12:27 |
| KanjiMonster | also that should be *.dtb, not *.dts | 12:30 |
| *** otavio_ <otavio_!~otavio@189-11-177-7.user3p.brasiltelecom.net.br> has joined #yocto | 12:33 | |
| *** otavio_ <otavio_!~otavio@189-11-177-7.user3p.brasiltelecom.net.br> has quit IRC (Client Quit) | 12:34 | |
| *** otavio_ <otavio_!~otavio@189-11-177-7.user3p.brasiltelecom.net.br> has joined #yocto | 12:34 | |
| 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) | 12:45 |
| jonesv | KanjiMonster: but at least `KERNEL_DEVICETREE` did something, since it now apparently tries to run `make` for it | 12: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 |
| KanjiMonster | jonesv: might be that this depends on kernel changes introduced in a later kernel | 12:55 |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 12:57 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 12:57 | |
| *** _Tyaku <_Tyaku!~Tyaku@lfbn-orl-1-202-97.w92-152.abo.wanadoo.fr> has quit IRC (Quit: Lost terminal) | 12:58 | |
| jonesv | KanjiMonster: actually it does call that Makefile somehow (just introduced an error there to confirm it fails). | 12:59 |
| jonesv | KanjiMonster: 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: https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/master/recipes-kernel/linux-msm/files/dts/Makefile?ref_type=heads) | 13:00 |
| 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`? | 13:03 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:05 | |
| 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 | 13:08 |
| KanjiMonster | maybe not the issue | 13:11 |
| 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? | 13:16 |
| jonesv | I just don't understand what the recipe's Makefile does :/. I don't see it define any task | 13:19 |
| 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. | 13:20 |
| 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) | 13:28 |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has joined #yocto | 13:36 | |
| *** tepperson <tepperson!~tepperson@24.144.20.149> has joined #yocto | 13:37 | |
| *** ray-san <ray-san!~ray-san@195.50.168.194> has quit IRC (Ping timeout: 246 seconds) | 13:41 | |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto | 13:47 | |
| 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) | 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 #yocto | 13:50 | |
| *** amsobr <amsobr!~amsobr@2a01:14:113:9e60:e644:20ff:ed62:f3a> has joined #yocto | 13:51 | |
| KanjiMonster | jonesv: ah, then you probably just need to drop it from your KERNEL_DEVICETREE definition as well and it should then work | 13:52 |
| *** sakoman <sakoman!~steve@dhcp-72-234-106-30.hawaiiantel.net> has joined #yocto | 13:58 | |
| jonesv | KanjiMonster: yes I'm trying that now :). Fingers crossed | 14:00 |
| 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`). | 14:11 |
| KanjiMonster | there should be no dtb for a dtsi, only for dts | 14:12 |
| jonesv | oh right, so maybe it's just other dts files that I need to add to KERNEL_DEVICETREE? | 14:14 |
| jonesv | I lost the log output now, let me try again | 14:15 |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 14:28 | |
| 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 :) ) | 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 #yocto | 14:35 | |
| *** RobertBerger <RobertBerger!~rber|res@089144205002.atnat0014.highway.webapn.at> has joined #yocto | 14: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!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has joined #yocto | 14:48 | |
| *** tepperson <tepperson!~tepperson@24.144.20.149> has quit IRC (Quit: Client closed) | 15:18 | |
| *** amitk <amitk!~amit@58.84.61.42> has joined #yocto | 15:21 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 15:22 | |
| *** randomgeek <randomgeek!~randomgee@host81-152-142-149.range81-152.btcentralplus.com> has joined #yocto | 15:22 | |
| *** JerryM <JerryM!~jermain@149.3.168.10> has quit IRC (Quit: Konversation terminated!) | 15:23 | |
| randomgeek | Hi 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 directory | 15:23 |
| randomgeek | | 17 | #include <Python.h> | 15:23 |
| randomgeek | Anyone seen this issue? | 15:23 |
| rburton | probably a missing dependency on python and everyone who built it in the past has python-dev installed locally | 15:24 |
| randomgeek | rburton: ive installed python3-dev the host | 15:25 |
| randomgeek | but still getting this issue. | 15:25 |
| randomgeek | s/the host/on the host | 15:25 |
| rburton | yeah that't not the fix | 15:26 |
| rburton | try adding python3 to DEPENDS | 15:27 |
| *** tepperson <tepperson!~tepperson@24.144.20.149> has joined #yocto | 15:27 | |
| 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) | 15:28 |
| *** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has quit IRC (Ping timeout: 240 seconds) | 15:30 | |
| randomgeek | DEPENDS already has pyhton3 (DEPENDS = "dbus ncurses python3 pps-tools) | 15:30 |
| 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? | 15:32 |
| *** zelgomer <zelgomer!~jake@gateway/tor-sasl/zelgomer> has joined #yocto | 15:32 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 15:32 | |
| tepperson | neverpanic: i was thinking that there was a built-in way already with a kernel config | 15:33 |
| rburton | randomgeek: old recipe without the inherit of python3native or pkgconfig? | 15:33 |
| 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? | 15:36 |
| tepperson | neverpanic: I was thinking it would be in the real-time-clock driver | 15:37 |
| randomgeek | rburton: you mean I changed DEPENDS to pyhton3-native instead? | 15:38 |
| neverpanic | tepperson: Why would it be? If you have a battery-backed RTC, you wouldn't need it. | 15:38 |
| rburton | randomgeek: no, i mean the recipe in master has an inherit of python3native and pkgconfig. are you using an old release without those | 15:39 |
| rburton | tepperson: bootmisc.sh literally does that already | 15:39 |
| rburton | (assuming sysv) | 15:39 |
| rburton | see meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh | 15:40 |
| randomgeek | rburton: I was using Hardknott release. I'll try the latest thanks. | 15:40 |
| rburton | randomgeek: hardknott has been EOL since april 2022, so please do upgrade | 15:40 |
| *** grma <grma!~gruberm@86.111.57.109> has quit IRC (Ping timeout: 245 seconds) | 15:43 | |
| randomgeek | sure will do, thank you! | 15:43 |
| tepperson | rburton: ah thank you | 15:43 |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 15:45 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 15:54 | |
| *** vladest <vladest!~Thunderbi@88-103-237-26.rci.o2.cz> has quit IRC (Quit: vladest) | 15:58 | |
| *** vladest <vladest!~Thunderbi@88-103-237-26.rci.o2.cz> has joined #yocto | 15:59 | |
| *** el_gatito <el_gatito!~thomas@2a02-a466-e8b5-fd--15.fixed6.kpn.net> has quit IRC (Ping timeout: 244 seconds) | 16:07 | |
| *** mckoan is now known as mckoan|away | 16:13 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE34.versanet.de> has quit IRC (Quit: Leaving.) | 16:15 | |
| khem | RP: about cc1 missing libmpfr.so.6 you mean its a fully populated sysroot-native for gcc at that time ? | 16:26 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 16:28 | |
| khem | cc1 is launched by gcc driver | 16:28 |
| khem | does this mean we always need to stage mpfr-native in every package build which uses c/c++ | 16:30 |
| khem | since cc1 will always need this library to run | 16:32 |
| 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 | 16:33 |
| khem | its effectively same like staging the native versions of these libs in sysroot-native | 16:34 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 258 seconds) | 16:38 | |
| *** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 16:40 | |
| *** Marmottus <Marmottus!~marmottus@2001:bc8:1820:2715::1> has joined #yocto | 16: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 #yocto | 16: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 #yocto | 16:43 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 16:51 | |
| *** tepperson <tepperson!~tepperson@24.144.20.149> has quit IRC (Quit: Client closed) | 16:55 | |
| *** GillesM <GillesM!~gilles@116.79.123.78.rev.sfr.net> has quit IRC (Quit: Leaving) | 16:55 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 246 seconds) | 16:56 | |
| *** amitk <amitk!~amit@58.84.61.42> 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!~frieder@i577B9216.versanet.de> has quit IRC (Remote host closed the connection) | 17:05 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 17:09 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 245 seconds) | 17:17 | |
| *** amitk <amitk!~amit@58.84.61.42> has joined #yocto | 17:28 | |
| vvn | what is the recommended way to fetch a given release (tag) for a github repo? | 17:28 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 17:30 | |
| RP | khem: it should always have that library in the recipe-sysroot-native, I'm puzzled about which case that wouldn't happen in :/ | 17:39 |
| sakoman | khem: it appears that the runpath fr cc1 isn't quite right: https://pastebin.com/vSfv0bxF | 17:42 |
| sakoman | Seems to have an extra "../": https://pastebin.com/Cnn2VuMR | 17:43 |
| 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. | 17:52 |
| khem | sakoman: Are we editing it anyway using patchelf ? | 17:53 |
| 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. | 17:53 |
| *** florian_kc <florian_kc!~florian@dynamic-092-229-245-112.92.229.pool.telefonica.de> has joined #yocto | 17:54 | |
| sakoman | khem: I don't have a clue what the gcc/libcc recipes are doing! | 17:54 |
| RP | sakoman: khem: we probably do edit it as we relocate the binaries around | 17:55 |
| RP | probably with chrpath or patchelf, not sure which | 17:55 |
| khem | it seems to be relative to final location of cc1 | 17:56 |
| khem | but we are using it in-place | 17:56 |
| khem | cc1 is being used from build/ not from recipe-sysroot-native here | 17:57 |
| 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 | 17:58 |
| sakoman | meta/recipes-devtools/pseudo/pseudo.inc: chrpath ${D}${bindir}/pseudo -r `chrpath ${D}${bindir}/pseudo | cut -d = -f 2 | sed s/XORIGIN/\\$ORIGIN/` | 17:59 |
| sakoman | meta/recipes-devtools/pseudo/pseudo.inc: chrpath -d ${D}${prefix}/lib/pseudo/lib*/libpseudo.so | 17:59 |
| RP | sakoman: pseudo is a bit special ;-) | 18:00 |
| RP | that is just tweaking it's own libraries so not the suspicious to me... | 18:00 |
| RP | I'm more wondering how the cc1 binary is moving around... | 18:00 |
| 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 | 18:08 |
| 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 | 18:09 |
| sakoman | $ ls /home/steve/builds/poky-contrib/build/tmp/work/core2-64-poky-linux/libgcc/9.5.0-r0/build/gcc/../../../recipe-sysroot-native | 18:09 |
| 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 | 18:09 |
| sakoman | As I said above there is an extra "../" in the path. If I remove that then it succeeds | 18: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 |
| khem | bin/ 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-native | 18:11 |
| sakoman | bin etc installeddeps sbin sysroot-providers usr var | 18:11 |
| khem | so I do have it referenced correctly but you dont | 18:11 |
| sakoman | Yes, so some change post dunfell? I have no clue where to even look! | 18:13 |
| khem | did you build this gcc locally ? | 18:14 |
| khem | in my build there is one more directory gcc-13.2.0 under BPN/PR/ your build does not | 18:15 |
| khem | so is it staged from somewhere cached ? | 18:15 |
| khem | mine is a fresh build | 18:15 |
| khem | local | 18:16 |
| sakoman | Yes, this is all built locally from dunfell head | 18:16 |
| khem | cool so that is consistent | 18:16 |
| khem | libgcc build uses a canned pre-built gcc tree | 18:16 |
| khem | see extract_stashed_builddir | 18:17 |
| sakoman | I did a -c cleansstate on gcc and libgcc and then rebuild prior to the above | 18:17 |
| khem | yeah thats ok | 18:17 |
| khem | it builds gcc-cross first and than stashes that tree away | 18:18 |
| khem | and brings it back when building compiler runtime stuff like gcc-runtime and libgcc etc. | 18:18 |
| khem | check the build dir of gcc-cross | 18: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 |
| 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 | 18:21 |
| khem | thats from gcc-cross | 18:22 |
| 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/ | 18:23 |
| sakoman | license-destdir sstate-install-gcc_stash_builddir sstate-install-populate_lic sstate-install-populate_sysroot stashed-builddir sysroot-destdir temp | 18:23 |
| sakoman | I have no build.x86_64... directory there | 18:24 |
| sakoman | Should I rebuild gcc-cross to get that? | 18:24 |
| khem | but do you have some build* | 18:25 |
| sakoman | nope, see the ls above for what is there | 18:25 |
| khem | so it got it from some sstate | 18:25 |
| khem | sstate-install-gcc_stash_builddir seems to indicate that | 18:26 |
| sakoman | should I clean sstate and rebuild? | 18:26 |
| sakoman | (for gcc-cross) | 18:26 |
| khem | if you do that then I am afraid the problem will be gone | 18:26 |
| khem | so we need to grab the tarball of sstate element for this task and analyse it | 18:27 |
| sakoman | there hasn't been a failure on this machine since ubuntu has the required library on the host | 18:29 |
| sakoman | so I suspect it will be exactly the same after a rebuild | 18:29 |
| sakoman | I'm guessing it has always been this way and we only see it now on alma8 since they don't have the require library version | 18:30 |
| sakoman | but 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@46.55.231.62> 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 #yocto | 18:43 | |
| khem | OK mv the gcc-cross build dir to something so we can refer to it | 18:59 |
| khem | and then do a bitbake -ccompile gcc-cross-<arch> | 19:00 |
| sakoman | khem: same deal, an extra "../" : https://pastebin.com/TBuaHEB5 | 19:28 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 19:35 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:36 | |
| khem | hmm | 19:48 |
| sakoman | khem: interestingly the library itself has the right number of ../ https://pastebin.com/kdSydE8D | 19:56 |
| sakoman | khem: breaking for lunch now, happy to run more experiments when I get back | 20:00 |
| *** RobertBerger <RobertBerger!~rber|res@089144205002.atnat0014.highway.webapn.at> has quit IRC (Remote host closed the connection) | 20:06 | |
| *** amitk <amitk!~amit@58.84.61.42> has quit IRC (Remote host closed the connection) | 20:13 | |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has quit IRC (Quit: Haxxa flies away.) | 20:15 | |
| *** Haxxa <Haxxa!~Haxxa@202-65-68-206.ip4.superloop.au> has joined #yocto | 20:17 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> 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!~florian@dynamic-092-229-245-112.92.229.pool.telefonica.de> has quit IRC (Ping timeout: 264 seconds) | 20:35 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 20:37 | |
| *** Wouter0100670440 <Wouter0100670440!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 20:37 | |
| khem | abelloni: whats the testing status on binutils ? | 20:56 |
| abelloni | I 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 JaMa | 20:57 |
| abelloni | I have a build ongoing to confirm | 20:57 |
| khem | cool ok | 21:01 |
| khem | efivar change will be needed for lld | 21:01 |
| *** ajfriesen847 <ajfriesen847!~ajfriesen@p4fd49ef5.dip0.t-ipconnect.de> has joined #yocto | 21:02 | |
| *** ajfriesen84 <ajfriesen84!~ajfriesen@p4fd4980f.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 250 seconds) | 21:03 | |
| *** ajfriesen847 is now known as ajfriesen84 | 21:03 | |
| JaMa | FWIW: efivar builds for me in nanbield with gold as well as lld, for kirkstone I had to backport couple commits from newer efivar | 21:06 |
| abelloni | JaMa: this is the failure I get: https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5577/steps/14/logs/stdio | 21:11 |
| khem | sakoman: can you try this patch - https://snips.sh/f/eh-NGOEhy7 | 21:12 |
| khem | and rebuild gcc-cross and see if this sorts it out | 21:16 |
| JaMa | abelloni: 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!~florian@dynamic-092-229-245-112.92.229.pool.telefonica.de> has joined #yocto | 21:25 | |
| khem | RP: aha scarthgap - https://www.komoot.com/highlight/1097510 | 21:28 |
| khem | Good thing is that is 2300ft higher than honister 🙂 | 21:29 |
| *** vladest <vladest!~Thunderbi@88-103-237-26.rci.o2.cz> has quit IRC (Ping timeout: 246 seconds) | 21:37 | |
| khem | JaMa: https://snips.sh/f/R2rT37znCb | 21:38 |
| 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 | 21:39 |
| khem | so can you launch cc1 successfully ? | 21:40 |
| khem | from build dir ? | 21:40 |
| JaMa | khem: yes, that's the same as what abelloni shared | 21:40 |
| sakoman | khem: yes, I can | 21:44 |
| JaMa | khem: abelloni: LDFLAGS was added to efivar by rburton between meta-oe removal https://git.openembedded.org/meta-openembedded/commit/?id=d8bbcf5689603194bb7aeb538ec4a696018cfcae and adding it to oe-core https://git.openembedded.org/openembedded-core/commit/?id=53fe0133432f62024850e87456292b044d1280ee | 21:46 |
| JaMa | the changes from https://git.openembedded.org/openembedded-core/commit/?id=4df808c616f847d90203582fd950a49bb8360dd0 allows to use gold or lld for build (it was failing to build with gold even with the LDFLAGS set to bfd) | 21:47 |
| abelloni | JaMa: I think I had the issue without your patch just now | 21:47 |
| JaMa | sakoman: please wait for ^^ to be resolved before taking https://lists.openembedded.org/g/openembedded-core/message/185170 | 21:48 |
| abelloni | I confirm | 21:48 |
| JaMa | abelloni: there were also some changes in gnu-efi, not sure if it might be related | 21:49 |
| sakoman | JaMa: I will wait for you to give me the ok | 21:49 |
| JaMa | abelloni: you mean, confirm that it's not caused by efivar change? | 21:49 |
| abelloni | exactly | 21:50 |
| JaMa | thanks | 21:50 |
| sakoman | JaMa: it is now removed from the queue :-) | 21:51 |
| 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 | 21:52 |
| abelloni | I have a last culprit to test | 21:52 |
| 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? | 21:53 |
| sakoman | khem: I'll try a dunfell world build with your patch to see if anything blows up | 21:54 |
| *** mckoan_ <mckoan_!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 21:56 | |
| khem | sakoman: yes that would be cool. Let me know how it goes and also see if original problem is fixed with this first | 21:56 |
| khem | then do world builds | 21:56 |
| *** Xagen <Xagen!~Xagen@rrcs-98-6-114-13.sw.biz.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 21:57 | |
| sakoman | khem: OK, I'll do the world build locally, and simultaneously do an autobuilder run on alma8 to see if that still fails | 21:58 |
| 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 | 21:58 |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 246 seconds) | 21:58 | |
| khem | sounds good | 21:58 |
| 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' | 21:59 |
| 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 | 22:00 |
| sakoman | khem: it will be a while for the test, abelloni is hogging all the workers ;-) | 22:05 |
| 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 | 22:06 |
| khem | its almost sleeping time in europe, then you can take over 🙂 | 22:07 |
| JaMa | hehe I always queue tons of jobs on jenkins before going to bed :) | 22:07 |
| JaMa | and some jobs from yesterday, still didn't finish building today | 22:08 |
| sakoman | khem: other people do the same as JaMa! So often I can't take over! | 22:08 |
| sakoman | I'll get the first job queued and then do the alma8 job later | 22:09 |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 252 seconds) | 22:12 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 22:14 | |
| khem | yeah I know, It was on a lighter note 🙂 | 22:30 |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 22:33 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-154.adslplus.ch> has quit IRC (Ping timeout: 250 seconds) | 22:49 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-237-154.adslplus.ch> has joined #yocto | 22:55 | |
| sakoman | khem: the local world build is 85% done with no issues, autobuilder is still queued waiting for worker | 23:05 |
| *** florian_kc <florian_kc!~florian@dynamic-092-229-245-112.92.229.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds) | 23:24 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!