All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Mikko.Rapeli@bmw.de, JPEWhacker@gmail.com
Cc: liezhi.yang@windriver.com, openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 2/3] buildtools-tarball: Add nativesdk-ccache
Date: Fri, 08 Jan 2021 08:23:49 +0000	[thread overview]
Message-ID: <5f94d003548fc2d0208b02d62773489507d03a99.camel@linuxfoundation.org> (raw)
In-Reply-To: <X/gODKFF9WGz8e8w@korppu>

On Fri, 2021-01-08 at 07:47 +0000, Mikko.Rapeli@bmw.de wrote:
> On Thu, Jan 07, 2021 at 10:12:54AM -0600, Joshua Watt wrote:
> > We had the same problem with icecream and solved it by building in a docker
> > container with the version of ice cream that we wanted FWIW.
> > 
> > Alternatively, I think it's possible to roll your own buildtools that has
> > ccache?
> 
> Yea, it's a long standing best practice that an LXC or docker container
> or buildtools tarball must be used to get reproducible builds in
> CI systems and on developers machines with random Linux distros and
> versions. Host contamination issues have reduced considerably
> in recent years, thanks for all fixes, but I still can't recommend
> mixing builds from different Linux distros when developing yocto
> based products.

Whilst this has been an issue I am quite proud of the work we've done
with the autobuilder to detect and resolve reproducibility issues which
has now been extended to world builds, i.e. apart from a small subset
of known issues (~65 packages), OE-Core is fully reproducible over all
out tested distros.

Whilst containers are a way of avoiding such issues, I think some of
the recent issues would even have caused differences between containers
(though kernel config or the geo of nameservers).

I appreciate that it hasn't been extended beyond OE-Core as yet but
think it does show what is possible and that there aren't that many
issues, certainly the core and tools are in a strong position.

Cheers,

Richard


  reply	other threads:[~2021-01-08  8:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 12:09 [PATCH 0/3] ccache: Fixes for 4.1 Robert Yang
2021-01-06 12:09 ` [PATCH 1/3] ccache: Extend to nativesdk Robert Yang
2021-01-06 12:09 ` [PATCH 2/3] buildtools-tarball: Add nativesdk-ccache Robert Yang
2021-01-06 13:56   ` [OE-core] " Richard Purdie
2021-01-07  2:44     ` Robert Yang
2021-01-07 10:40       ` Richard Purdie
2021-01-07 10:59         ` Robert Yang
2021-01-07 16:12           ` Joshua Watt
2021-01-08  7:47             ` Mikko Rapeli
2021-01-08  8:23               ` Richard Purdie [this message]
2021-01-08 10:48             ` Robert Yang
2021-01-07 17:10           ` Richard Purdie
2021-01-08 10:48             ` Robert Yang
2021-01-06 12:09 ` [PATCH 3/3] ccache.bbclass: Set CCACHE_TEMPDIR Robert Yang

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=5f94d003548fc2d0208b02d62773489507d03a99.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=JPEWhacker@gmail.com \
    --cc=Mikko.Rapeli@bmw.de \
    --cc=liezhi.yang@windriver.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.