From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: alexander.kanevskiy@intel.com, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/4] extend buildhistory
Date: Fri, 27 Nov 2015 09:36:33 +0100 [thread overview]
Message-ID: <20151127083633.GY17303@jama> (raw)
In-Reply-To: <3117759.OV2fKNkn7Z@peggleto-mobl.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]
On Fri, Nov 27, 2015 at 01:34:27PM +1300, Paul Eggleton wrote:
> On Wednesday 25 November 2015 10:30:28 Patrick Ohly wrote:
> > The initial implementation of YOCTO #8138
> > ("buildhistory-extra.bbclass: store more information about a build")
> > had some issues ("kconfig" file not preserved) but more importantly,
> > additional changes are needed to support also gathering information
> > about native recipes.
> >
> > I am proposing to include only the "buildhistory.bbclass: support
> > extending the content of the build history" patch into OE-core.
> >
> > The original buildhistory-extra.bbclass and the modifications made to
> > it are included here merely to provide the context for that change and
> > to publish the modifications.
>
> For others' reference, buildhistory-extra.bbclass was previously attached to
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8138 - I didn't and wouldn't
> propose introducing it into OE-Core in its current form because it's kind of
> turning buildhistory into something it wasn't designed for, though I don't
> disagree that it's useful. Happy to hear opinions from others on this though.
I agree it's useful.
I wonder if we can abstract some of these functions to be able to run
some of them without the actual build - we want to generate BOM (Bill of
materials) before building the image and e.g. for verification builds we
generate them twice (for base metadata, then with verification changes
applied) and generate diff.
I've implemented this as separate task which traverse the dependency
tree from the image we're going to build and writes all interesting
metadata in JSON.
Regards,
> One aspect that will probably change in the future is how it picks up the
> kernel configuration - for
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574 (which I hope to get to
> for 2.1, but no promises) we will need to write the kernel configuration to the
> sysroot so that we have somewhere we can look for it; if that's the case
> there'll be no need to copy it specially in buildhistory-extra.bbclass.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
next prev parent reply other threads:[~2015-11-27 8:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 9:30 [PATCH 0/4] extend buildhistory Patrick Ohly
2015-11-25 9:30 ` [PATCH 1/4] buildhistory-extra.bbclass: store more information about a build Patrick Ohly
2015-11-25 9:30 ` [PATCH 2/4] buildhistory.bbclass: support extending the content of the build history Patrick Ohly
2015-11-27 0:25 ` Paul Eggleton
2015-11-25 9:30 ` [PATCH 3/4] buildhistory-extra.bbclass: simplify usage Patrick Ohly
2015-11-25 9:30 ` [PATCH 4/4] buildhistory-extra.bbclass: more complete and reliable data gathering Patrick Ohly
2015-11-27 0:38 ` Paul Eggleton
2015-11-27 0:34 ` [PATCH 0/4] extend buildhistory Paul Eggleton
2015-11-27 8:36 ` Martin Jansa [this message]
2015-12-01 19:36 ` Paul Eggleton
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=20151127083633.GY17303@jama \
--to=martin.jansa@gmail.com \
--cc=alexander.kanevskiy@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.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 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.