From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 588CFC38150 for ; Sun, 7 Jul 2024 12:55:51 +0000 (UTC) Subject: Re: [PATCH] bluez5: upgrade 5.72 -> 5.76 To: openembedded-core@lists.openembedded.org From: =?UTF-8?B?R3XDsG5pIE3DoXIgR2lsYmVydA==?= X-Originating-Location: Kopavogur, Capital Region, IS (81.15.100.92) X-Originating-Platform: Windows Chrome 126 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Sun, 07 Jul 2024 05:55:46 -0700 References: In-Reply-To: Message-ID: <20061.1720356946240260660@lists.openembedded.org> Content-Type: multipart/alternative; boundary="wXiHuAgBxGpxUyI714PP" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Sun, 07 Jul 2024 12:55:51 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/201623 --wXiHuAgBxGpxUyI714PP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 7, 2024 at 10:00 AM, Richard Purdie wrote: >=20 > Thanks for the patch, unfortunately this ran into issues in our CI. One > interesting one is this: >=20 > https://valkyrie.yoctoproject.org/#/builders/40/builds/65 > https://valkyrie.yoctoproject.org/#/builders/36/builds/64/steps/17/logs/s= tdio >=20 >=20 > which isn't very clear what is going on until you look at the files: >=20 > (buildbot-venv) [pokybuild@rocky9-vk-1 ~]$ ls > /home/pokybuild/yocto-worker/qemuarm-oecore/build/build/tmp-glibc/work/qe= muarm-oe-linux-gnueabi/core-image-sato/1.0/testimage-sdk/sysroots/cortexa15= t2hf-neon-oe-linux-gnueabi/etc/bluetooth/ > -la > total 32 > dr-xr-xr-x. 2 pokybuild pokybuild 4096 Jul 7 11:11 . > drwxr-xr-x. 3 pokybuild pokybuild 4096 Jul 7 11:26 .. > -rw-r--r--. 1 pokybuild pokybuild 928 Jul 7 11:11 input.conf > -rw-r--r--. 1 pokybuild pokybuild 12597 Jul 7 11:11 main.conf > -rw-r--r--. 1 pokybuild pokybuild 120 Jul 7 11:11 network.conf >=20 > The missing write bit on the directory is stopping the files from being > deleted. I wonder if this resolves the issue, looks exactly like something we need: = https://docs.python.org/3/library/shutil.html#rmtree-example ( https://docs.python.org/3/library/shutil.html#rmtree-example ) There's a = comment in the Bitbake code saying rmtree is too slow, but that's from 12 y= ears ago. Perhaps it is fast enough today with Python 3.12. I don't think the solution is to request BlueZ to change how it installs it= 's files/directory. --wXiHuAgBxGpxUyI714PP Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 7, 2024 at 10:00 AM, Richard Purdie wrote:
Thanks for the patch, unfortunately this ran into issues in our= CI. One
interesting one is this:

https://valkyrie.yoctoproject.org/#/builders/40/builds/65
https://valkyrie.yoctoprojec= t.org/#/builders/36/builds/64/steps/17/logs/stdio

which isn'= t very clear what is going on until you look at the files:

(buil= dbot-venv) [pokybuild@rocky9-vk-1 ~]$ ls /home/pokybuild/yocto-worker/qemua= rm-oecore/build/build/tmp-glibc/work/qemuarm-oe-linux-gnueabi/core-image-sa= to/1.0/testimage-sdk/sysroots/cortexa15t2hf-neon-oe-linux-gnueabi/etc/bluet= ooth/ -la
total 32
dr-xr-xr-x. 2 pokybuild pokybuild 4096 Jul 7 1= 1:11 .
drwxr-xr-x. 3 pokybuild pokybuild 4096 Jul 7 11:26 ..
-rw-= r--r--. 1 pokybuild pokybuild 928 Jul 7 11:11 input.conf
-rw-r--r--. 1= pokybuild pokybuild 12597 Jul 7 11:11 main.conf
-rw-r--r--. 1 pokybui= ld pokybuild 120 Jul 7 11:11 network.conf

The missing write bit = on the directory is stopping the files from being
deleted. I wonder if this resolves the issue, looks exactly like something we need: = https://docs.python.org/3/library/shutil.h= tml#rmtree-example

There's a comment in the Bitbake code say= ing rmtree is too slow, but that's from 12 years ago. Perhaps it is fast en= ough today with Python 3.12.

I don't think the solution is to re= quest BlueZ to change how it installs it's files/directory. --wXiHuAgBxGpxUyI714PP--