RE: [OE-core] [PATCH v2 1/2] buildhistory: fix package output folder creation

Pedro Silva Ferreira
2024-08-29T10:55:13Z

Hi Richard,

I tried to pickup your patch and make it fit but unsuccessful. Would this be an alternative only for LTS branches?

Thanks,

Pedro

From 3ab48da7a94b80bb67ebef5a06d92ace134e0bbf Mon Sep 17 00:00:00 2001
From: Pedro Ferreira <pedro.silva.ferreira@criticaltechworks.com>
Date: Thu, 29 Aug 2024 11:37:19 +0100
Subject: [PATCH] sstate: making sstate_install run after plaindirs creation

Based on oe-core rev:62ee349cf18532dac8736488752c00e89de78fcd

Plaindirs are handled after SSTATEPOSTINSTFUNCS
(buildhistory_emit_pkghistory) and causes buildhistory
class fail due to missing dirs.

sstate_install call moved after plaindirs creation loop.

Signed-off-by: Pedro Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
---
meta/classes/sstate.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index dd6cf12920..ed6bf59e42 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -415,7 +415,6 @@ def sstate_installpkgdir(ss, d):
for state in ss['dirs']:
prepdir(state[1])
bb.utils.rename(sstateinst + state[0], state[1])
- sstate_install(ss, d)

for plain in ss['plaindirs']:
workdir = d.getVar('WORKDIR')
@@ -427,6 +426,7 @@ def sstate_installpkgdir(ss, d):
bb.utils.mkdirhier(src)
prepdir(dest)
bb.utils.rename(src, dest)
+ sstate_install(ss, d)

return True

--
2.34.1

-----Original Message-----
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Sent: Tuesday, August 27, 2024 3:11 PM
To: Pedro Silva Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>; Steve Sakoman <steve@sakoman.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 1/2] buildhistory: fix package output folder creation

Notice: This e-mail has originated from an external email service, so do not click on any links, nor open any attachments unless you know who the sender is and are sure the content is secure.

On Tue, 2024-08-27 at 12:50 +0000, Pedro Silva Ferreira wrote:
> Hi Steve and Richard,
>
> I tried to backport locally patches [4] and [5] to kirkstone and
> scarthgap but i ran into some issues related to sstate.bbclass. After
> some investigation i saw that i was missing a patch done by Richard
> [3] in the context of this buildhistory change but after applying the
> patch [3], due to the `interceptfuncs` logic i ran into an undefined
> variable (SSTATE_INSTDIR) while executing `bb.utils.rename` helper
> function. Applying patch [1] and [2] in combination with [3] , [4] and
> [5] seems to do the job but im not really sure if patch [1] and [2]
> can be backported to lts branches since they remove some
> features/class that might be used by other components that I am not
> aware of. I tested this with ncurses recipe and with core-image-
> minimal.
>
> 1: siteconfig: Drop siteconfig class/code/support
> f3766dc038f7ba9780ddaf5eb8d27385ea31d7d0
> 2: sstate: Drop intercept functions support
> cfbfd0b2e89eb71783c55a1be4a7e63e6cd82c2f

We definitely can't backport those.

> 3: sstate/buildhistory: Fix plaindirs handling to occur before
> SSTATEPOSTINSTFUNCS 62ee349cf18532dac8736488752c00e89de78fcd

We'd probably need to find a way to make that change and continue to work with the intercept functions :/.

Cheers,

Richard
The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt

This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it!