openembedded-core.lists.openembedded.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH 7/7] reproducible: Drop BUILD_REPRODUCIBLE_BINARIES variable
Date: Thu, 14 Oct 2021 15:45:11 +0200	[thread overview]
Message-ID: <YWg0Zxz52+65ukRp@piout.net> (raw)
In-Reply-To: <CADkTA4NZRmGhb92Y22MnGsQhdxZOUtpg99pu0LahdZgyCJCzzw@mail.gmail.com>

On 14/10/2021 08:38:46-0400, Bruce Ashfield wrote:
> On Thu, Oct 14, 2021 at 8:32 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Thu, 2021-10-14 at 08:28 -0400, Bruce Ashfield wrote:
> > > On Thu, Oct 14, 2021 at 8:10 AM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > >
> > > > We want things to be reproduicble and the variable doesn't really change
> > > > much any more. Drop the remaining uses and make those code paths always
> > > > active.
> > >
> > > It wasn't clear to me from reading the patch.  What is the way that
> > > someone would now get the current timestamp into a kernel build, if
> > > that's the behaviour that they want ?
> >
> > With this change they probably don't get the option. If we want that to be
> > configurable, we should probably move the control to a different variable which
> > is focused specifically on the kernel. The hardest bit is probably picking a
> > name!
> 
> This is probably the most surprising feature of reproducibility for
> kernel developers, and a question that I've gotten multiple times
> ("what happened to my timestamp ?" followed by "how do I turn this
> off?")
> 
> Most kernel developers already don't really like the "yocto workflow",
> and this adds another element in that category. It is common in a
> debug scenario to check the timestamp of the running kernel to make
> sure that you've actually booted the one you just built.
> 

But do kernel developers actually do their development using YP?
I definitively not. I do all my BSP work outside of any build system and
then I finally integrate everything once this is working/ready.

It did indeed surprise me the first time I saw that but this doesn't
have any actual effect on my workflow. Also, the issue was already
existing if what you were trying to build was already in the sstate
cache (e.G from a nightly build), it would contain the time of the
actual build.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  reply	other threads:[~2021-10-14 13:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 12:10 [PATCH 1/7] reproducible_build: Drop now unneeded compiler warning Richard Purdie
2021-10-14 12:10 ` [PATCH 2/7] reproducible_build: Drop obsolete sstate workaround Richard Purdie
2021-10-14 12:10 ` [PATCH 3/7] reproducible: Move class function code into library Richard Purdie
2021-10-14 12:10 ` [PATCH 4/7] reproducible: Move variable definitions to bitbake.conf Richard Purdie
2021-10-14 12:10 ` [PATCH 5/7] reproducible: Merge code into base.bbclass Richard Purdie
2021-10-14 12:10 ` [PATCH 6/7] python: Update now reproducibile builds are the default Richard Purdie
2021-10-14 12:10 ` [PATCH 7/7] reproducible: Drop BUILD_REPRODUCIBLE_BINARIES variable Richard Purdie
2021-10-14 12:28   ` [OE-core] " Bruce Ashfield
2021-10-14 12:31     ` Richard Purdie
2021-10-14 12:38       ` Bruce Ashfield
2021-10-14 13:45         ` Alexandre Belloni [this message]
2021-10-14 13:46           ` Bruce Ashfield
2021-10-14 15:26             ` Richard Purdie
2021-10-14 16:36 ` [OE-core] [PATCH 1/7] reproducible_build: Drop now unneeded compiler warning Khem Raj
2021-10-14 21:48   ` Richard Purdie
2021-10-14 23:22     ` Khem Raj

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=YWg0Zxz52+65ukRp@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).