[PATCH v2 0/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

[PATCH v2 0/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

[Petter Mabäcker]

Realized that http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130003.html
change set never was merged, trying this again.

(Rebased to handle '3c59b1b meta: remove True option to getVarFlag calls')

The following changes since commit 5d301e9f19048b4cd0d5f702860e318c85f1c037:

  python*-git: Upgrade to version 2.1.3 (2017-05-12 08:51:10 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib epetmab/staging_kernel_dir_02
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=epetmab/staging_kernel_dir_02

Petter Mabäcker (1):
  multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

 meta/classes/multilib.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH v2 1/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

[Petter Mabäcker]

Due to the problem fixed in
'56c677a multilib: Move redefinition of STAGING_DIR_KERNEL'
STAGING_KERNEL_DIR must be redefined for lib32 in multilib.bbclass.
However this redefinition expanded STAGING_KERNEL_DIR to an absolute
path. This unconsciously added the TMPDIR path in the sstate object,
causing packages depended on STAGING_KERNEL_DIR being rebuild if the
TMPDIR was changed.

Solve this by forcing the unexpanded TMPDIR variable to remain in the
beginning of STAGING_DIR_KERNEL (as default). Since TMPDIR is included in
BB_HASHBASE_WHITELIST, the sstate object will not be depended on the
expanded path anymore.

Signed-off-by: Petter Mabäcker <petter@technux.se>
---
 meta/classes/multilib.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index ab04597..816f54e 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -4,7 +4,9 @@ python multilib_virtclass_handler () {
     if cls != "multilib" or not variant:
         return
 
-    e.data.setVar('STAGING_KERNEL_DIR', e.data.getVar('STAGING_KERNEL_DIR'))
+    localdata = bb.data.createCopy(e.data)
+    localdata.delVar('TMPDIR')
+    e.data.setVar('STAGING_KERNEL_DIR', localdata.getVar('STAGING_KERNEL_DIR'))
 
     # There should only be one kernel in multilib configs
     # We also skip multilib setup for module packages.
-- 
1.9.1

Re: [PATCH v2 1/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

 

Hi, 

Just realized this change was never merged into master, so see
this as a friendly reminder about this change-set (might have been lost
in the flood of changes in this time-frame). Not the most common use
case I guess, but would be good to finally get rid of the problem. If
you have any concerns about the change, please let me know. The solution
was briefly discussed with Richard on irc a couple of month ago, but if
someone thinks this should be solved in some other way, please initiate
a discussion :) 

BR Petter 

2017-05-15 06:17 skrev Petter Mabäcker:


> Due to the problem fixed in
> '56c677a multilib: Move redefinition
of STAGING_DIR_KERNEL'
> STAGING_KERNEL_DIR must be redefined for lib32
in multilib.bbclass.
> However this redefinition expanded
STAGING_KERNEL_DIR to an absolute
> path. This unconsciously added the
TMPDIR path in the sstate object,
> causing packages depended on
STAGING_KERNEL_DIR being rebuild if the
> TMPDIR was changed.
> 
> Solve
this by forcing the unexpanded TMPDIR variable to remain in the
>
beginning of STAGING_DIR_KERNEL (as default). Since TMPDIR is included
in
> BB_HASHBASE_WHITELIST, the sstate object will not be depended on
the
> expanded path anymore.
> 
> Signed-off-by: Petter Mabäcker
<petter@technux.se>
> ---
> meta/classes/multilib.bbclass | 4 +++-
> 1
file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git
a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index
ab04597..816f54e 100644
> --- a/meta/classes/multilib.bbclass
> +++
b/meta/classes/multilib.bbclass
> @@ -4,7 +4,9 @@ python
multilib_virtclass_handler () {
> if cls != "multilib" or not variant:
>
return
> 
> - e.data.setVar('STAGING_KERNEL_DIR',
e.data.getVar('STAGING_KERNEL_DIR'))
> + localdata =
bb.data.createCopy(e.data)
> + localdata.delVar('TMPDIR')
> +
e.data.setVar('STAGING_KERNEL_DIR',
localdata.getVar('STAGING_KERNEL_DIR'))
> 
> # There should only be one
kernel in multilib configs
> # We also skip multilib setup for module
packages.
> -- 
> 1.9.1
 

[-- Attachment #2: Type: text/html, Size: 2472 bytes --]