From: "Petter Mabäcker" <petter@technux.se>
To: <openembedded-core@lists.openembedded.org>,
Ross burton <ross.burton@intel.com>
Subject: Re: [PATCH v2 1/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR
Date: Wed, 07 Jun 2017 22:46:33 +0200 [thread overview]
Message-ID: <52ce814f7d286b1687a40874eadb0646@technux.se> (raw)
In-Reply-To: <7c0aa8330757a50d9a69a4c23be83e4cc045566c.1494796923.git.petter@technux.se>
[-- 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 --]
prev parent reply other threads:[~2017-06-07 20:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 4:17 [PATCH v2 0/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR Petter Mabäcker
2017-05-15 4:17 ` [PATCH v2 1/1] " Petter Mabäcker
2017-06-07 20:46 ` Petter Mabäcker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52ce814f7d286b1687a40874eadb0646@technux.se \
--to=petter@technux.se \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross.burton@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox