08:15 <halloy7836> I use podamn to build Kirkstone and I get belowe error:

08:16 <halloy7836> I use podamn to build Kirkstone and I get belowe error:

08:16 <halloy7836> I use podamn to build Kirkstone and I get belowe error: ERROR: m4-native-1.4.19-r0 do_patch: Applying patch 'ac_config_links.patch' on target directory '/workdir/picloud-kirkstone/build/tmp/work/aarch64-linux/m4-native/1.4.19-r0/m4-1.4.19'CmdError('quilt --quiltrc /workdir/picloud-kirkstone/build/tmp/work/aarch64-linux/m4-native/1.4.19-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: stderr: /bin/sh: 1: quilt: Permission denied

08:16 <halloy7836> I checked and idntified that "quilt" does not get exec flags

08:17 <halloy7836> it only happens on MacOS, the build works on Fedora

08:18 <RP> halloy7836: we've never got the builds working under MacOS

08:19 <RP> sadly tools like pseudo won't work properly there due to decisions made about LD_PRELOAD support (they dropped it)

08:19 <halloy7836> I do not build on MacOS, I build it in a Docker/Podman container on a MacOS .... technically it is being built under Ubuntu 22.04

08:20 <RP> halloy7836: well, yes but there is clearly something leaking through around the filesystem :/

08:21 <halloy7836> I bind /workdir inside the container to a folder on macos for data persistency

08:22 <halloy7836> it seems quilt does not get x flags after being compiled and installed as a native tool

08:22 <RP> That does sound like the issue, yes. The filesystem isn't noexec or something like that is it?

08:23 <halloy7836> I did everal tests and confirmed that filesystem binding between Podmancontainer and MacOS filesystems works including the permissions and flags

08:24 <halloy7836> in the container quilt shows as "noexec"without x flags

08:24 <halloy7836> the sam on MacOS side

08:24 <RP> halloy7836: I was meaning noexec as a filesystem mount option

08:25 <RP> you're doing the right things to debug it by the sounds of it. Since kirkstone was extensively tested with 22.04, it seems likely something about that mount is the problem

08:27 <halloy7836> interesting point ! I gotta check podman volume mount options

08:29 <halloy7836> I do not see noexec option: core@85d1d6c88c58:~$ mount | grep workdir a2a0ee2c717462feb1de2f5afd59de5fd2d8 on /workdir type virtiofs (rw,relatime,context=system_u:object_r:nfs_t:s0)

08:30 <RP> halloy7836: fair enough, it was just a thought

08:32 <halloy7836> Others have reported the same problem on Stackoverflow: https://stackoverflow.com/questions/78819747/yocto-build-failed-due-to-permission-denied-due-to-failed-execution-flags-when-b

08:35 <RP> someone will need to debug it. Step back through the quilt-native build do_install step and see where/why/when the quilt binary doens't get exec bits set

08:40 <armando> It's in the quilt native build scripts .... do_install does not do much AFAIK

08:41 <RP> Our do_install runs "make BUILD_ROOT=XXX install"

08:42 <RP> so it may be a case of seeing what the makefile does, assuming the files in XXX are missing the exec bit too

08:44 <armando> note that it all works fine when I run the containerized build on a Fedora Linux host. This only happens on MacOS

08:45 <RP> the makefile looks to use "install -m 755"

08:46 <RP> you need to find out at which point it breaks the permissions. I have a worry it is our copy command rather than the makefile install

08:47 <RP> you could look at tmp/work/x86_64-linux/quilt-native/sysroot-destdir/xxxx/bin/quilt and see what permissions it has

08:47 <RP> xxxx will be the installed path to it

08:49 <armando> -rw-------+ 1 core dialout 3.2K Dec 29 07:56 ./build/tmp/sysroots-components/aarch64/quilt-native/usr/bin/quilt

08:49 <armando> The VM machine is a 64 bit Arm

08:49 <armando> would that be a problem ?

08:50 <RP> for arm it would be tmp/work/aarch64*-linux/quilt-native/sysroot-destdir/xxxx/bin/quilt

08:50 <armando> yeah, you got it in my prev. message

08:51 <RP> no, that is a different file

08:51 <armando> I meant has the build system been tested on a aarch64 host ?

08:51 <RP> yes, we have several arm hosts in our automated test setup

08:54 <armando> each package builds and install quilt independently !

08:54 <RP> no, it gets build once and then shared

08:54 <armando> ./picloud-kirkstone/build/tmp/work/aarch64-linux/texinfo-dummy-native/1.0-r0/recipe-sysroot-native/usr/bin/quilt./picloud-kirkstone/build/tmp/work/aarch64-linux/texinfo-dummy-native/1.0-r0/recipe-sysroot-native/etc/bash_completion.d/quilt

08:54 <armando> ./picloud-kirkstone/build/tmp/work/aarch64-linux/autoconf-native/2.71-r0/recipe-sysroot-native/usr/bin/quilt./picloud-kirkstone/build/tmp/work/aarch64-linux/autoconf-native/2.71-r0/recipe-sysroot-native/etc/bash_completion.d/quilt

08:54 <armando> ./picloud-kirkstone/build/tmp/work/aarch64-linux/m4-native/1.4.19-r0/recipe-sysroot-native/usr/bin/quilt./picloud-kirkstone/build/tmp/work/aarch64-linux/m4-native/1.4.19-r0/recipe-sysroot-native/etc/bash_completion.d/quilt

08:54 <armando> and so on ...

08:55 <RP> each recipe has its own copy of dependencies which are shared and hardlinked. It means we verify each recipe's dependencies and have isolation between them

08:57 <RP> The sysroots-components copy is the central one which is shared and that is missing the exec bit. This was why I was asking about the built copy which is in the other location I mentioned

08:57 <armando> core@85d1d6c88c58:~$ ll ./picloud-kirkstone/build/tmp/work/aarch64-linux/quilt-native/total 0drwxr-xr-x. 3 core dialout 96 Dec 29 07:56 0.67-r0drwxr-xr-x. 15 core dialout 480 Dec 29 07:56 ..drwxr-xr-x. 3 core dialout 96 Dec 29 07:56 .

08:58 <armando> "./picloud-kirkstone/build/tmp/work/aarch64-linux/quilt-native/" does not have "/sysroot-destdir/xxxx/bin/quilt"

08:59 <RP> does something like "tmp/work/aarch64-linux/quilt-native/0.68/sysroot-destdir/" exist?

08:59 <RP> I can't remember the quilt version for kirkstone off the top of my head

09:00 <armando> "sysroot-destdir" is not in "./picloud-kirkstone/build/tmp/work/aarch64-linux/quilt-native/0.67-r0/"

09:00 <RP> picloud-kirkstone/build/tmp/work/aarch64-linux/quilt-native/0.67-r0/image/ ?

09:01 <armando> no

09:01 <RP> ok, different question, what is there?

09:01 <RP> are you installing from sstate mirrors?

09:02 <armando> no I build from scratch

09:02 <RP> well, something isn't adding up as there doesn't appear to be a build there :/

09:05 <armando> when I run "bitbake quilt" I get the same errors...it seems "quilt" does not build correctly

09:06 <RP> it would be quilt-native that is the issue, not quilt

09:07 <armando> when I run "bitbake quilt-native" it returns without any errors

09:09 <armando> -rw-------+ 1 core dialout 3.2K Dec 29 07:56 ./tmp/sysroots-components/aarch64/quilt-native/usr/bin/quilt

09:10 <armando> RP: thank you, gotta got to bed, it's late night here

10:04 <RP> armando: mention which directories are in picloud-kirkstone/build/tmp/work/aarch64-linux/quilt-native/0.67-r0/ next time you're around, maybe the list of files in temp there too. Something doesn't add up...

14:15 <uglyoldbob> I am trying to put together a native recipe for running a tool used in another recipe. I can run the tool, but run into issues with shared libraries: specifically libbz2.so.1. It clams it can't find it, however ./tmp/work/(machine)/(recipe)/(version)/recipe-sysroot-native/usr/lib definitely contains a valid symlink for libbz2.so.1, and so does

14:15 <uglyoldbob> ./tmp/work/(machine)/(recipe)/(version)/recipe-sysroot/usr/lib

15:03 <vladest> Helly

15:03 <vladest> merry xmas to everyone

15:03 <vladest> ERROR: gcc-14.2.0-r0 do_package_qa: QA Issue: File /usr/src/debug/gcc/14.2.0/gcc/configargs.h in package gcc-src contains reference to TMPDIR [buildpaths]

15:03 <vladest> ERROR: gcc-14.2.0-r0 do_package_qa: QA Issue: File /usr/libexec/gcc/aarch64-poky-linux/14.2.0/.debug/cc1 in package gcc-dbg contains reference to TMPDIR [buildpaths]

15:03 <vladest> I have weird issue in latest yocto building GCC:

15:03 <vladest> ERROR: gcc-14.2.0-r0 do_package_qa: QA Issue: File /usr/libexec/gcc/aarch64-poky-linux/14.2.0/.debug/cc1plus in package gcc-dbg contains reference to TMPDIR [buildpaths]

15:03 <vladest> ERROR: gcc-14.2.0-r0 do_package_qa: QA Issue: File /usr/lib/gcc/aarch64-poky-linux/14.2.0/plugin/include/configargs.h in package gcc-plugins contains reference to TMPDIR [buildpaths]

15:03 <vladest> ERROR: gcc-14.2.0-r0 do_package_qa: QA Issue: File /usr/libexec/gcc/aarch64-poky-linux/14.2.0/cc1plus in package g++ contains reference to TMPDIR [buildpaths]

15:03 <vladest> ERROR: gcc-14.2.0-r0 do_package_qa: QA Issue: File /usr/bin/aarch64-poky-linux-g++ in package g++ contains reference to TMPDIR [buildpaths]

15:03 <vladest> ERROR: gcc-14.2.0-r0 do_package_qa: Fatal QA errors were found, failing task.

15:03 <vladest> ERROR: Logfile of failure stored in: /hdd/rpiyocto/build/tmp/work/cortexa76-poky-linux/gcc/14.2.0/temp/log.do_package_qa.231001

15:03 <vladest> ERROR: Task (/hdd/rpiyocto/poky/meta/recipes-devtools/gcc/gcc_14.2.bb:do_package_qa) failed with exit code '1'

15:03 <vladest> NOTE: Tasks Summary: Attempted 7729 tasks of which 7628 didn't need to be rerun and 1 failed.

15:04 <vladest> I've created bbappend for gcc recipe with INSANE_SKIP:${PN} += "buildpaths" but it didnt help

18:09 <RP> vladest: which release is that?

18:55 <vladest> @RP: latest master

21:22 <RP> vladest: did you reconfigure gcc somehow? We don't see that in our automated testing :/