All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Francisco Pedraza <francisco.j.pedraza.gonzalez@intel.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v4 2/2] meta/classes/populate_sdk: Adds support for generating eSDK manifest files
Date: Thu, 30 Mar 2017 17:12:57 +0100	[thread overview]
Message-ID: <1490890377.13980.364.camel@linuxfoundation.org> (raw)
In-Reply-To: <1490807554-33473-2-git-send-email-francisco.j.pedraza.gonzalez@intel.com>

On Wed, 2017-03-29 at 10:12 -0700, Francisco Pedraza wrote:
> The functionalities to generate SDK and eSDK manifest files are
> different,
> the SDK comes from package information and the eSDK comes from sstate
> artifacts.
> Only execute write_sdk_{host, target}_manifest when is on
> populate_sdk class.
> 
> Adds new functions write_sdk{host, target}_ext_manifest to execute on
> postprocess
> in populate_sdk_ext because at the end we have all the sstate
> artifacts to generate the manifest.
> [YOCTO #9038]
> 
> Signed-off-by: Francisco Pedraza
> <francisco.j.pedraza.gonzalez@intel.com>

Whilst this works to a point, the minimal eSDK doesn't contain sstate
objects so I'm not sure this is actually going to work in that case? We
could always used the locked-sigs.inc file to act as an idea of what
the eSDK contains?

Also, your patch only considers MULTIMACH_TARGET_SYS and TARGET_SYS
architectures and we also have allarch and machine specific packages it
would miss.

Cheers,

Richard


      reply	other threads:[~2017-03-30 16:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 17:12 [PATCH v4 1/2] lib/oe/sdk: Adds get_extra_sdk_info to reuse code in buildhistory Francisco Pedraza
2017-03-29 17:12 ` [PATCH v4 2/2] meta/classes/populate_sdk: Adds support for generating eSDK manifest files Francisco Pedraza
2017-03-30 16:12   ` Richard Purdie [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=1490890377.13980.364.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=francisco.j.pedraza.gonzalez@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.