All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Bartosh <ed.bartosh@linux.intel.com>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 00/18] Provide list of deployment artifacts
Date: Tue, 30 Aug 2016 14:21:59 +0300	[thread overview]
Message-ID: <20160830112159.GB3482@linux.intel.com> (raw)
In-Reply-To: <CAP9ODKqrhofQDSL9zfhJC6HFKbk0bxnDhoaaqbn6ooj-0jqX8Q@mail.gmail.com>

On Tue, Aug 30, 2016 at 07:58:31AM -0300, Otavio Salvador wrote:
> On Tue, Aug 30, 2016 at 7:35 AM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> > On Tue, Aug 30, 2016 at 07:21:20AM -0300, Otavio Salvador wrote:
> >> On Tue, Aug 30, 2016 at 6:29 AM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> >> > Hi,
> >> >
> >> > This is a fix for Bug #9869 - Provide a per-target manifest of files which were, or would have been, produced
> >> >
> >> > The list of artifacts produced by deployment tasks (do_deploy, do_image_complete and do_populate_sdk[_ext] is
> >> > obtained from sstate manifests and fired as a TaskArtifacts metadata event. This should allow Toaster to
> >> > handle artifacts in simple way and remove a lot of current Toaster code doing guess work.
> >> >
> >> > To generate manifests for do_image_complete and do_populate_sdk they have been put under sstate control.
> >> >
> >> > To avoid storing big files(images and sdk installer) in sstate new variable SSTATE_SKIP_CREATION has been
> >> > set in image.bbclass and populate_sdk_base.bbclass and sstate code was modified to avoid adding files
> >> > to sstate if SSTATE_SKIP_CREATION is set.
> >>
> >> SKIP creation of what?
> > SKIP creation of SSTATE entity.
> 
> I know but of WHAT?
Of anything we don't want to put to sstate. In this patchset it's set
for do_image_complete and do_populate_sdk, so it's for images and sdk
installer.

> SSTATE_SKIP_IMAGE_CREATION would be a clearer name for me.
I'm not sure about it. I'd need one more variable
SSTATE_SKIP_SDK_INSTALLER if I go this way.

> >> Variable name seems a little vague for me. Even
> >> needing the manifest, does it makes sense to store the image and SDK
> >> on sstate?
> > It doesn't and skipping this is a purpose of introducing SSTATE_SKIP_CREATION variable.
>
> So it is always going to be skipped?
Yes it is for do_image_complete and do_populate_sdk tasks for now.

--
Regards,
Ed


  reply	other threads:[~2016-08-30 11:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-30  9:29 [PATCH 00/18] Provide list of deployment artifacts Ed Bartosh
2016-08-30  9:29 ` [PATCH 01/18] image-live.bbclass: deploy images to DEPLOYDIR Ed Bartosh
2016-08-30  9:29 ` [PATCH 02/18] image-vm.bbclass: " Ed Bartosh
2016-08-30  9:29 ` [PATCH 03/18] image.bbclass: " Ed Bartosh
2016-08-30  9:29 ` [PATCH 04/18] " Ed Bartosh
2016-08-30  9:29 ` [PATCH 05/18] image_types_uboot.bbclass: " Ed Bartosh
2016-08-30  9:29 ` [PATCH 06/18] syslinux.bbclass: deploy bootloader " Ed Bartosh
2016-08-30  9:29 ` [PATCH 07/18] build-appliance-image: process images in DEPLOYDIR Ed Bartosh
2016-08-30  9:29 ` [PATCH 08/18] populate_sdk_base.bbclass: deploy sdk artifacts to DEPLOYDIR Ed Bartosh
2016-08-30  9:29 ` [PATCH 09/18] rootfs-postcommands.bbclass: generate manifest in DEPLOYDIR Ed Bartosh
2016-08-30  9:29 ` [PATCH 10/18] selftest: renamed variable Ed Bartosh
2016-08-30  9:29 ` [PATCH 11/18] rootfs.py: use DEPLOYDIR instead of DEPLOY_DIR_IMAGE Ed Bartosh
2016-08-30  9:29 ` [PATCH 12/18] image.bbclass: put image_complete under sstate control Ed Bartosh
2016-08-30  9:29 ` [PATCH 13/18] image.bbclass: cleanup DEPLOYDIR Ed Bartosh
2016-08-30  9:29 ` [PATCH 14/18] populate_sdk_base: put populate_sdk under sstate control Ed Bartosh
2016-08-30  9:29 ` [PATCH 15/18] sstate.bbclass: skip packaging if SSTATE_SKIP_CREATION is set Ed Bartosh
2016-08-30  9:29 ` [PATCH 16/18] image: populate_sdk_base: skip sstate creation Ed Bartosh
2016-08-30  9:29 ` [PATCH 17/18] image: populate_sdk_base: set stamp-extra-info flag Ed Bartosh
2016-08-30  9:29 ` [PATCH 18/18] toaster: fire TaskArtifacts event Ed Bartosh
2016-08-30 10:08 ` [PATCH 00/18] Provide list of deployment artifacts Richard Purdie
2016-08-30 10:21 ` Otavio Salvador
2016-08-30 10:35   ` Ed Bartosh
2016-08-30 10:58     ` Otavio Salvador
2016-08-30 11:21       ` Ed Bartosh [this message]
2016-08-30 13:36         ` Otavio Salvador
2016-08-30 14:06           ` Richard Purdie

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=20160830112159.GB3482@linux.intel.com \
    --to=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    /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.