All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Andrea Adami <andrea.adami@gmail.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] bitbake.conf: add whoami to HOSTTOOLS
Date: Thu, 30 Mar 2017 11:02:05 +0100	[thread overview]
Message-ID: <1490868125.13980.347.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAAQYJAtwSctCha6mJqUUFVddnV31oGwaabNPLtV9PqAULDLs-g@mail.gmail.com>

On Thu, 2017-03-30 at 00:52 +0200, Andrea Adami wrote:
> On Thu, Mar 30, 2017 at 12:24 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Wed, 2017-03-29 at 23:09 +0200, Andreas Oberritter wrote:
> > > 
> > > On Wed, 29 Mar 2017 22:45:17 +0200
> > > Andrea Adami <andrea.adami@gmail.com> wrote:
> > > 
> > > > 
> > > > 
> > > > Spotted in log do_compile of linux:
> > > > 
> > > >  /tmp/build/tmp-glibc/work-shared/c7x0/kernel-
> > > > source/scripts/mkcompile_h:
> > > >  line 46: whoami: command not found
> > > As an alternative, we could set KBUILD_BUILD_USER (and possibly
> > > KBUILD_BUILD_HOST) to a fixed or machine-based value in
> > > kernel.bbclass'
> > > EXTRA_OEMAKE variable, which could also improve the
> > > reproducibility
> > > of
> > > builds.
> > Agreed, I already suggested we should figure out how to pass in a
> > deterministic value and said I would not accept a patch to add
> > whoami
> > to HOSTTOOLS.
> > 
> > Cheers,
> > 
> > Richard
> Hello,
> 
> well, I'm all for reproducible builds.
> But there is the fact that this is the standard kernel behavior and
> we
> never limited the user choices about how to build/configure a kernel.

Just because this is the standard kernel behaviour, it doesn't mean its
"right" for us.

There are multiple issues here:

a) Builds are not deterministic
b) Builds leak "host" information about the user that built it

So we've identified an issue which I believe is something our general
userbase (who are asking for reproducibility) will want us to fix, even
if its not the upstream default kernel behaviour.

The fact there is a kconfig option for this and a way to override it
suggest even the upstream kernel people accept this is something people
will want to configure.

Cheers,

Richard


      reply	other threads:[~2017-03-30 10:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 20:45 [PATCH] bitbake.conf: add whoami to HOSTTOOLS Andrea Adami
2017-03-29 21:06 ` Mark Hatle
2017-03-29 21:09 ` Andreas Oberritter
2017-03-29 21:27   ` Mark Hatle
2017-03-29 22:24   ` Richard Purdie
2017-03-29 22:52     ` Andrea Adami
2017-03-30 10:02       ` 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=1490868125.13980.347.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=andrea.adami@gmail.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.