**** BEGIN LOGGING AT Mon Mar 22 02:59:56 2021 Mar 22 07:49:07 Hi i am trying to build fakeroot1.18.4 for raspberry pi4 but i am getting following error Mar 22 07:49:08 ERROR: fakeroot-1.18.4-r0 do_compile: oe_runmake failed Mar 22 07:49:08 ERROR: fakeroot-1.18.4-r0 do_compile: Execution of '/home/pankaj/Yocto/ARM/Build_Dir_ARM/tmp-glibc/work/cortexa72-oe-linux/fakeroot/1.18.4-r0/temp/run.do_compile.7978' failed with exit code 1: Mar 22 07:49:09 make  all-recursive Mar 22 07:49:09 make[1]: Entering directory '/home/pankaj/Yocto/ARM/Build_Dir_ARM/tmp-glibc/work/cortexa72-oe-linux/fakeroot/1.18.4-r0/build' Mar 22 07:49:10 Making all in scripts Mar 22 07:49:10 make[2]: Entering directory '/home/pankaj/Yocto/ARM/Build_Dir_ARM/tmp-glibc/work/cortexa72-oe-linux/fakeroot/1.18.4-r0/build/scripts' Mar 22 07:49:11 sed -e 's,[@]prefix[@],/usr,g' -e 's,[@]bindir[@],/usr/bin,g' -e 's,[@]libdir[@],/usr/lib,g' -e 's,[@]fakeroot_transformed[@],'`echo fakeroot | sed -e 's,x,x,'`',g' -e 's,[@]faked_transformed[@],'`echo faked | sed -e 's,x,x,'`',g' -e 's,[@]signal[@],TERM,g' -e 's,[@]SHELL[@],/bin/bash,g' -e 's,[@]VERSION[@],1.18.4,g' -e 's,[@]DLSUFFIX[@],.so,g' -e Mar 22 07:49:11 's,[@]LDLIBPATHVAR[@],LD_LIBRARY_PATH,g' -e 's,[@]LDPRELOADVAR[@],LD_PRELOAD,g' -e 's,[@]LDPRELOADABS[@],0,g' -e 's,[@]LDEXTRAVAR[@],,g' -e 's,[@]MACOSX_FALSE[@],,g' -e 's,[@]MACOSX_TRUE[@],#,g' < ../../fakeroot-1.18.4/scripts/fakeroot.in > fakeroot Mar 22 07:49:12 chmod +x fakeroot Mar 22 07:50:53 can someone help me if they have latest fakeroot sources or to fix this issue ?? Mar 22 07:56:45 khem: thx Mar 22 08:23:36 Hey guys. Does meta-security have it's separate mailing list? Mar 22 08:51:28 ptsneves: meta-security/README says yocto@lists.yoctoproject.org Mar 22 09:01:12 JaMa thanks, and sorry for the stupid question. Mar 22 09:02:07 hi Mar 22 09:02:23 how to inherit any classes in bbclass file Mar 22 09:05:31 Manju:  inherit inside it, the same as you would in any bb Mar 22 09:06:51 what i meant to ask was how to define a class globally so that i can create its instances in different functions Mar 22 09:13:56 i think you might be misunderstanding classes in yocto. You do not instantiate classes in yocto Mar 22 09:32:08 Is u-boot-fslc supposed to work with the NXP uuu tool? Mar 22 09:34:05 if so, do I need to enable something special? Mar 22 10:14:49 Hi folks, I'm trying to provide documentation links to a customer. Using the version selector dropdown field on https://docs.yoctoproject.org/ doesn't seem to load previous versions anymore Mar 22 10:15:02 Looking at https://docs.yoctoproject.org/releases.html#previous-release-manuals, the links for dunfell don't work Mar 22 10:15:21 * paulbarker Ok, it's just 3.1.6 that doesn't work: https://docs.yoctoproject.org/3.1.6 Mar 22 10:20:04 paulbarker: not a problem with the dropdown menu, I remember searching https://www.yoctoproject.org/docs/3.1.4 and that doesn't work either Mar 22 10:25:05 any hints or resources from yocto side to reproducible and archived build environments? e.g. collecting a full download cache and building in off line mode only? am fed up with on-line builds doing silly things and things like python setup script changes breaking every other SW component build.. Mar 22 10:28:05 I'm guessing a separate download cache update process needs to be executed before the off-line build, e.g. to run bitbake all fetcher tasks to update download cache locally, then a way to upload to central download cache for releases, then do the off line build. Mar 22 11:04:58 mcfrisk, something like this? https://docs.yoctoproject.org/singleindex.html#replicating-a-build-offline Mar 22 11:07:33 shoragan: yea, but I'd need to convert this to be the default, and provide way to update caches. otherwise on-line builds will erode things as SW components rely on internet access etc. Mar 22 11:08:36 essentially you can use the archiver to create a proper DL/mirror (paulbarker's changes make that now nicer than just cp'ing the DL folder) . Mar 22 11:08:41 then setup PREMIRROR Mar 22 11:09:01 BB_NO_NETWORK and BB_FETCH_PREMIRROR_ONLY Mar 22 11:09:14 would complete that Mar 22 11:11:06 mcfrisk, generally, all dependencies (for python packages as well) should come via SRC_URIs, so should be fixed to a known hash Mar 22 11:11:19 if not, i'd argue that that Mar 22 11:11:23 's a bug Mar 22 11:26:50 shoragan: yea, except in reality that't not the case at all. maybe it is for poky layers, but in custom project specific meta layers I have severe issues with build reproducibility, including BSP layers. I think only way to fix this is to move all builds to happen off line, e.g. kill network access from build container and configure bitbake to only access local download mirror. but then I need some way for Mar 22 11:26:56 developers to update things into the download mirror. I guess the mirror needs a version/hash based on content. Mar 22 12:00:03 hello, any good recommendation for a lightweight, but secure HTTP server usable on an embedded Linux device? Mar 22 12:00:36 preferably already packaged for Yocto/OE Mar 22 12:01:05 there are quite a few options and I am unsure what to use for a new project Mar 22 12:07:44 nginx? Mar 22 12:07:52 define lightweight :) Mar 22 12:15:15 eduardas, what kind of support do you need? only CGIs, python, php.. lua scripting...? Multiple user auth...? Mar 22 12:16:38 eduardas, http://layers.openembedded.org/layerindex/branch/master/recipes/?q=httpd Mar 22 12:21:16 caiortp: only CGI, should be usable on systems with only 128 MiB RAM Mar 22 12:22:40 busybox httpd :) Mar 22 12:25:20 derRichard: yes, that certainly came to mind. But I am not sure how much maintenance it gets, how popular it really is compared to other options for this usecase or how secure it is. Mar 22 12:42:49 Hi everyone, Mar 22 12:42:57 Hope you are doing well Mar 22 12:55:01 derRichard: seems busybox-httpd does not support SSL, so that is not acceptable Mar 22 12:56:30 eduardas: well, use stunnel Mar 22 12:56:38 this is a common approach Mar 22 13:01:07 derRichard: was not aware. first time I've heard about it. thanks Mar 22 13:06:16 on the other hand, a real websever like apache/nginx isn't much larger Mar 22 13:06:39 since you seem to depend on ssl you system is goning to be bloated anyway :P Mar 22 13:37:38 Quick question, when there are multiple recipes of the same name, the one in the highest priority layer is chosen, correct? Mar 22 13:38:12 psplash_git.bb in my custom layer doesn't seem to override the one from poky Mar 22 13:40:37 derRichard: a colleague ust found that Technicolor SA routers provided to end-users by Telia here in Lithuania do in fact use nginx Mar 22 13:47:40 eduardas: lighttpd is widely used, I think Mar 22 13:51:42 IMHO either go super mini using busybox httpd, or go real with apache or nginx Mar 22 13:52:12 Just hopped in, but I just went through setting up nginx on our rpi4 Mar 22 13:52:15 none of these is huge nor a memory waster (if configured properly) Mar 22 13:55:34 I missed the first half, but we're planning on displaying the website through Chromium... Running webkit in some sort of a slimmer fashion might be worth looking into if you're trying to keep system resources to an absolute minimum Mar 22 14:57:33 Hey guys, I'm facing to an issue when using the FIT image. fitImage in not installed into the rootfs (in /boot directory). Mar 22 14:57:42 I'm using Poky with a master branch, I'm enabling the fitImage. Mar 22 14:57:51 Unfortunately, the fitImage is not packaged and not installed into the root file system. Mar 22 14:57:59 Any help would be much appreciated. Mar 22 14:58:38 I haven't worked in with FIT's in a long while, but one debugging step would be to check if you successfully built the fit artifact... Mar 22 14:59:30 The fitImage is well generated and deployed in the deploy directory but it is not installed into the root file system and it is not packaged. Mar 22 15:00:50 Awesome. I'm definitely going to show my inexperience here... but the last time I remember workign with FIT's, I recall having to flash the FIT, and rootfs onto the device's storage into two different locations Mar 22 15:01:53 and then telling u-boot where everything went in the config... but at the time, I was working with u-boot's shell to handle loading a couple of binaries Mar 22 15:02:41 How you have done it ? could you please elaborate ? Mar 22 15:04:22 We'll see how much of this ends up being accurate... it's literally been years... but I remember using dd to copy multiple images onto the devices storage at specific offsets... then booting, and dropping into u-boots shells Mar 22 15:04:29 *u-boot's shell Mar 22 15:05:09 from there, I could load multiple kernels, and Xen, and kick off the boot process... Mar 22 15:05:16 that was later hardened into a u-boot config Mar 22 15:06:11 so I don't think that's the best path forward for you here... ideally you just have one big-binary blog that you write to your devices storage.. and it boots happily... but I don't know how much of that will be out of the box here Mar 22 15:06:14 ichergui12: iirc, you'll probably have to add the fitImage to IMAGE_INSTALL Mar 22 15:06:49 @smu Mar 22 15:08:03 I can not use IMAGE_INSTALL because the fitImage is not packaged Mar 22 15:14:54 ichergui12: is this the first FIT? or are you loading multiple? Mar 22 15:15:30 I have only one taht I want to install it in /boot (rootfs) Mar 22 15:16:05 Here is my updates in the conf/local.conf file Mar 22 15:16:06 KERNEL_CLASSES += "kernel-fitimage" Mar 22 15:16:07 KERNEL_IMAGETYPE = "fitImage" Mar 22 15:16:07 INITRAMFS_IMAGE_BUNDLE = "1" Mar 22 15:16:31 I saw one user in the mailing list mention setting INITRAMFS_IMAGE in the conf Mar 22 15:16:41 might be something to follow up Mar 22 15:16:49 Yeah Mar 22 15:17:04 which mailing list ? Mar 22 15:17:08 https://www.yoctoproject.org/pipermail/yocto/2017-August/037676.html Mar 22 15:17:59 Sorry, but this old, I'm talking about the recent implementation Mar 22 15:18:28 I'm using master branch of Poky repo Mar 22 15:19:29 It looks like that property is still supported... Mar 22 15:19:49 do you have it set? does it not do anything? Mar 22 15:20:28 https://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#var-INITRAMFS_IMAGE Mar 22 15:24:43 The problem is not in the FIT image generation but it is not packaged and not installed by default into the root file system Mar 22 15:26:45 I think you already answered this... but you aren't interested in loading the rootfs from within the FIT right? Mar 22 15:30:38 this seems eerily close https://www.yoctoproject.org/pipermail/yocto/2017-October/038437.html Mar 22 15:32:41 I will take a look, thanks Mar 22 15:33:28 looks like this user hacked up the kernel recipe to avoid coping over certain files when deploying the FIT... I'm unsure if we're missing the first part... and we're missing a config option to not deploy the FIT... or we're in some new territory Mar 22 15:33:32 happy hunting! Mar 22 16:00:55 RP: Any reason /var and /tmp aren't in PSEUDO_IGNORE_PATHS? We apparently has some tool that is executed in pseudo context that creates files in /var/tmp, which may cause pseudo to abort. Mar 22 16:03:28 Saur: I was warned about these by Peter/Mark Mar 22 16:03:48 Ok. What's the problem with them? Mar 22 16:15:22 hi all -- bitbake core-image-minimal and bitbake mc::core-image-minimal must produce the same image, correct? Mar 22 16:15:54 * vdl is confused whether local.conf is read or not in a multiconfig-enabled build Mar 22 16:20:27 vdl: It is read in all multiconfigs Mar 22 16:23:48 JPEW: is multiconfig/foo.conf defines DISTRO = "dist-foo" and local.conf defines DISTRO = "dist-local", which distro is picked when building the targets "mc:foo:core-image-minimal", "mc::core-image-minimal", and "core-image-minimal"? Mar 22 16:24:03 s/is/if/ Mar 22 16:30:14 The local.conf one I think? Mar 22 16:30:51 "mc::core-image-minimal" and "core-image-minimal" are the same thing IIRC Mar 22 16:31:47 And, I *think* local.conf always overrides a multiconfig (but, I could be wrong). Try "bitbake -e mc:foo | grep DISTRO=" vs "bitbake -e | grep DISTRO=" Mar 22 16:32:40 I'm confused about why one would use the "mc::" target preifx Mar 22 16:32:42 prefix* Mar 22 16:32:43 you can override DISTRO in the multiconfig, I've done so Mar 22 16:33:14 smurray: Ya, I guess that makes sense, given the intended use Mar 22 16:33:48 vdl: In most cases, you wouldn't use it. The only time you might want to is if you need an mcdepends (or similar) on the "base" configuration Mar 22 16:35:05 vdl: OK, smurray is correct. In your case, DISTRO for mc:foo:... will be dist-foo Mar 22 16:35:18 local.conf is read, but multiconfig/foo.conf overrides it Mar 22 16:39:36 JPEW: that makes sense, thank you Mar 22 16:44:03 should I also set different TMPDIR values in multiconfig if I'm building different distros? Mar 22 16:44:20 s/also/always Mar 22 16:44:31 (damn mondays) Mar 22 16:54:54 yes Mar 22 17:00:24 and same goes for different machine I presume Mar 22 17:43:43 I know I already asked, but just in case: I opened a bounty with my "MBR to GPT" question here: https://unix.stackexchange.com/questions/639647/system-boots-with-mbr-but-not-with-gpt Mar 22 17:45:23 jonesv[m]: AFAIK wic doesn't support GPT properly Mar 22 17:45:59 jonesv[m]: try creating the partition table manually Mar 22 17:48:07 aha! That's interesting Mar 22 17:48:44 mckoan: though I don't know how to do that, so I'll need to read about it. But thanks for the insights, at least I have something to try now :) Mar 22 18:21:04 mckoan|away: Can you clarify on wic not supporting GPT? I've been using it fine on several platforms Mar 22 18:23:36 zeddii: https://errors.yoctoproject.org/Errors/Details/574320/ Mar 22 18:26:09 khem: my scripts aren't bumping those SRCREVs, I'm sending a few patches shortly and will bump them. Mar 22 18:37:36 build/conf/auto.conf is read after build/conf/local.conf, correct? Mar 22 18:38:33 hum no actually the opposite would make more sense Mar 22 18:47:05 vdl: auto.conf is before local.conf Mar 22 18:47:18 local.conf is last.... multiconfig is even last-er ;) Mar 22 18:52:18 khem: should meta-clang start providing llvm-native? the issue is that mesa adds dependency on llvm-native with gallium-llvm PACKAGECONFIG mesa.inc:PACKAGECONFIG[gallium-llvm] = "-Dllvm=enabled -Dshared-llvm=enabled, -Dllvm=disabled, llvm${MESA_LLVM_RELEASE} llvm-native and then tcmode-default.inc sets LLVMVERSION to 9 in dunfell and meta-clang to 10 which causes mesa to depend on unavailable llvm-native-10 Mar 22 18:52:25 what does the term "virtual" represent in the yocto lexicon? Mar 22 18:52:50 e.g., PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = "external-arm-toolchain" Mar 22 18:53:12 or (i believe) bitbake virtual/kernel Mar 22 18:53:14 ? Mar 22 18:53:27 JaMa: if you use meta-clang then it overrides the Core version Mar 22 18:53:43 khem: yes it does, which break mesa Mar 22 18:54:11 it should not Mar 22 18:54:21 I can set LLVMVERSION back to 9 to unbreak mesa, but that might break clang instead Mar 22 18:54:27 atleast on master Mar 22 18:54:40 khem: llvm in meta-clang doesn't provide llvm-native (at least in dunfell) Mar 22 18:55:33 nm Mar 22 18:56:14 and meta-qti adds LLVM_VERSION variable into the mix for their llvm-arm-toolchain-native_git.bb :/ Mar 22 18:57:06 JaMa: yeah backport some parts of https://github.com/kraj/meta-clang/commit/003dd05e4c168f7c3cccb9cbfad3fd8f38fe8741 Mar 22 18:58:24 khem: ah, thanks, should have looked a bit more Mar 22 19:17:28 RP: at times I do see https://errors.yoctoproject.org/Errors/Details/574326/ which seems like pseudo is bailing out, see http://cgit.openembedded.org/meta-openembedded/tree/meta-python/recipes-devtools/python/python3-hexdump_3.3.bb?h=master#n22 I plan to remove that function and just delete this in do_install_append or something, but thought of sharing it if you want to see something for pseudo's point of view Mar 22 19:58:26 JPEW: Oh you're using GPT with wic? Have you seen my wks here? Is there something that seems obviously wrong? https://unix.stackexchange.com/questions/639647/system-boots-with-mbr-but-not-with-gpt Mar 22 20:23:36 khem: the issue with llvm-native was reproducible with meta-clang master as well, but the root cause was something stupid in our internal build (someone added whole meta-clang to BBMASK) so the LLVMVERSION was set in layer.conf, but clang recipe to provide it wasn't available due to BBMASK Mar 22 20:32:39 JaMa: k Mar 22 20:33:48 anybody here using the cve-update-db-native recipe in an air gapped network? Mar 22 20:34:12 We do have a local copy of the meta and json.gz files on our own servers Mar 22 20:34:33 khem: the fix is probably to mark that task as fakeroot, then it should be ok? Mar 22 20:34:39 But the recipe does't use e.g. SRC_URI what could be handled by pre_mirror e.g. Mar 22 20:39:06 RP: yeah I think something for pseudo ignore paths probably too Mar 22 20:52:56 vermaete: yeah that won't work. patches welcome. Mar 22 20:55:35 Hi, I'm looking for syntax documentation of /etc/network.conf Mar 22 21:00:16 khem: but that isn't an ignore path issue, its because you're changing do_install data outside of pseudo Mar 22 21:01:43 RP: its an idependent task though or is D owned by do_install alone ? Mar 22 21:02:19 code looks legit to me Mar 22 21:02:43 its inserting a function between do_install and do_package which alters D Mar 22 21:05:51 khem: any task altering D needs to be fakeroot Mar 22 21:06:35 khem: also, the code assumes that things are done altering D when do_install finished so its likely a race issue Mar 22 21:06:59 khem: definitely not legit Mar 22 21:10:34 Hi, I'm looking for documentation, don't know if this is the correct channel or #yocto-training Mar 22 21:10:44 I have this embedded system, running poki 8.0.2 (Yocto Project 1.3.2 Reference Distro), and I want to modify /etc/network.conf Mar 22 21:10:51 This is the current configuration, https://paste.debian.net/1190574/ Mar 22 21:10:59 But I don't know how to add another static address. (Only have knowledge in Debian and Gentoo) Mar 22 21:13:32 If I always build for the same underlying hardware architecture and libc, I can share TMPDIR between multiconfig, correct? Mar 22 21:15:37 vdl: even changing arch should work. multimachine builds have long been supported. but libc and distro stuff needs a different one Mar 22 21:15:40 so yeah Mar 22 21:19:45 RP: ah yes I was not thinking straight 🙂 you are right Mar 22 21:20:03 I think I will move this into a do_install_append and get the issue sorted Mar 22 21:21:47 RP: stress-ng failure is interesting, so musl declares sigqueue function in system headers but its not impelmented, stress-ng has added a check to find if platform implemented this function but the linking succeeds and sigque is marked as UNDEF :( Mar 22 21:24:45 khem: yes, moving to do_install append will fix it Mar 22 21:25:11 khem: should musl really be declaring it then? :/ Mar 22 21:39:05 is the output of do_populate_sysroot the items in tmp/sysroots-components? Mar 22 21:39:42 yates: effectively Mar 22 21:42:08 khem: on a musl target system, does the gettest iconv macro am_cv_func_iconv_works report yes? Mar 22 21:42:28 I think yes Mar 22 21:42:36 it has internal iconv Mar 22 21:42:57 khem: so we could set that in the site files everywhere? Mar 22 21:47:06 I think so Mar 22 21:49:22 khem: wondering about http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=f2dbd797ea8ff0eb723d621dfddcf0c95105dc3a Mar 22 21:51:29 looks ok. you might also set ac_cv_have_iconv_detect_h=yes Mar 22 21:51:53 khem: Well, I'm just avoiding the broken test right now... Mar 22 21:52:22 khem: this way it should be safe for baremetal and other things Mar 22 21:52:36 not that you'd use gettext with baremetal :) Mar 22 21:52:48 while hear fix this test too perhaps although its ok to defer it Mar 22 21:53:08 khem: are there issues with the other test? Mar 22 21:54:10 khem: that doesn't look like a standard marcro from iconv.m4? :/ Mar 22 21:54:12 I think I was thinking if it will use predefined iconv-detect.h too Mar 22 21:54:19 but I think we are not using that at present Mar 22 21:54:23 jonesv[m]: No, it looks OK to me Mar 22 21:54:41 RP: lets stay with what you have Mar 22 21:54:57 khem: I'll put it in for testing Mar 22 21:55:33 I think you will need a pregenerated iconv-detect.h too Mar 22 21:55:44 khem: for that error-report issue, I think it should be fixed server side Mar 22 21:56:00 khem: I put out a patch to use bleach instead, hard part is testing Mar 22 21:56:06 to completely bypass iconv poking Mar 22 21:56:17 jonesv[m]: I've used that SoC family a lot, but we've always used MBR partitions Mar 22 21:56:34 khem: I'm simply trying to avoid having to patch gettext macros at this point Mar 22 21:56:52 JPEW: right, so it could be an issue with the SoC and not with wic, correct? Mar 22 21:56:58 and get rid of a couple of non-upstreamable patches Mar 22 21:57:24 jonesv[m]: It could be. Someone from TI might be able to tell you if the boot ROM support GPT Mar 22 21:57:51 JPEW: you mean I may find somebody from TI here in #yocto? Mar 22 21:58:01 jonesv[m]: Ya, or on a forum or something Mar 22 21:58:09 got it Mar 22 21:58:11 Thanks a lot :) Mar 22 21:58:15 jonesv[m]: np Mar 22 22:24:48 RP: the sigqueue issue is actually a bit different, problem is pthread_sigqueue not sigqueue which is there in musl, but pthread version is not. and its also not defined in headers, and local build passes ok and it rightly detects that this function is absent but on OE jenkins the test for pthread_sigqueue passes and it fails see https://errors.yoctoproject.org/Errors/Details/574327/ Mar 22 22:25:20 so now I wonder if there is some cross compilation issue where its poking at host libc somehow Mar 22 22:25:41 but then local build seems to work ok Mar 22 22:26:46 in the error log if you search for pthread_sigqueue you see it being detected autoconfig: using pthread_sigqueue Mar 22 22:27:09 on my local build this detection fails so final build works Mar 22 22:30:22 khem: hmm, that does sound a bit like a host issues :/ Mar 22 22:34:23 khem: its all custom makefile tests so it could be having cross compile issues Mar 22 22:34:55 I think another difference is ld-is-gold so let me do a local build with ld-is-gold Mar 22 22:35:19 gold linker has subtle differences too Mar 22 22:35:39 khem: could be a pthread linking issues I guess Mar 22 22:36:44 khem: the Makefile calls uname to determine some features to build :/ Mar 22 22:36:46 right the make tests for test binary creation and calls it a success I wonder if somehow it ends up creating the binary even though it is not correct Mar 22 22:37:57 yeah saw that too, earlier I was also suspecting that its perhaps calling host CC and detecting the features which works on glibc systems most of the times Mar 22 22:38:17 do you see it fail on AB on any musl builds ? Mar 22 22:38:28 khem: no, I was a bit puzzled on that Mar 22 22:39:28 I also dont see it on arm64/musl build Mar 22 22:39:38 but only on x86/musl Mar 22 22:40:11 arm64 build is not with gold linker though Mar 22 22:40:53 khem: looks like it only builds the test prog, doesn't run it, so it should be cross compile safe Mar 22 22:41:53 khem: hack it to remove the 2> /dev/null and see what the error is on the OE builder? Mar 22 22:41:54 there was another failure https://errors.yoctoproject.org/Errors/Details/574188/ where it also detected pidfd_open function Mar 22 22:43:14 khem: although I guess somehow it gets compiled even when it shouldn't :/ Mar 22 22:43:25 khem: is TMPDIR reused? Mar 22 22:43:25 right Mar 22 22:43:46 no, it just builds musl/x86 Mar 22 22:49:03 khem: I can't see any change in the upgrade around this :/ Mar 22 22:49:20 khem: also seems to build here correctly Mar 22 22:49:29 (for musl) Mar 22 22:50:01 yeah its a bit baffling Mar 22 22:50:49 and its consistently failing in everything either 1 or 2 undefined symbols as seen above Mar 22 22:51:26 maybe gold linker has something to do lets see Mar 22 23:02:01 oh well its not even gold linker Mar 22 23:12:36 khem: some kind of disk cache race on that system? the linker may create the file then destroy it and the makefile races and sees it? Mar 22 23:12:54 it shouldn't do that... Mar 22 23:13:11 khem: removing the 2> /dev/null redirect would make that clearer Mar 22 23:13:22 khem: maybe add an echo of the command too Mar 22 23:13:44 hmm its using ramfs Mar 22 23:14:14 yeah I will add it Mar 22 23:14:51 it forces -j1 on those tests so there must be a reason why they do it Mar 22 23:17:58 I think one workaround is to pass these via EXTRA_OEMAKE += "HAVE_PTHREAD_SIGQUEUE=0" so the test is avoided Mar 22 23:26:58 khem: the real fix may be to move the compiler output into place, gcc X -o A && mv A real.name || true Mar 22 23:27:21 yeah true Mar 22 23:28:12 I have added a vebose patch https://github.com/YoeDistro/openembedded-core/commit/c8a9eb7e16bc1c6c83b9043794b0c976ac726ed0 Mar 22 23:28:39 will run with this one cycle and see if logs show something interesting, then second try will be to try mv path Mar 22 23:29:40 these builders are slow so each cycle is 6 hrs Mar 22 23:29:43 atleast Mar 22 23:59:03 khem: ok Mar 22 23:59:25 khem: might be worth a local try redirecting that task's workdir to a ramfs? **** ENDING LOGGING AT Tue Mar 23 02:59:56 2021