public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Moessbauer, Felix" <felix.moessbauer@siemens.com>
To: "Schild, Henning" <henning.schild@siemens.com>
Cc: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"Kiszka, Jan" <jan.kiszka@siemens.com>,
	"venkata.pyla@toshiba-tsip.com" <venkata.pyla@toshiba-tsip.com>
Subject: Re: [PATCH 0/3] Fix reproducability issues in deb_add_changelog
Date: Mon, 9 Jan 2023 10:33:39 +0000	[thread overview]
Message-ID: <e8f2c222c7560f36dd8ccf147b8395c9634ed77d.camel@siemens.com> (raw)
In-Reply-To: <20230109102831.49a9b39b@md1za8fc.ad001.siemens.net>

On Mon, 2023-01-09 at 10:28 +0100, Henning Schild wrote:
> Maybe you explain what exactly can go wrong. All i see is the 0 for
> when we create the changelog ... move the +=42 a few lines down to
> cover create and prepend ... done?

Here it depends on the exact definition of reproducability.
While the issue discussed in p2 could indeed be solved by the +=42
(which IMHO is a bad design anyways), the more severe issue of
accumulation of changelog entries is not solved.

Previously to p1, whenever the build failed in do_prepare_build (or
technically wherever deb_add_changelog is transitively used), we got a
new changelog entry. By that, I saw changelogs with dozens of ISAR
created changelog entries on top of each other.

> 
> partial rebuilds and reproducible builds is a tricky topic. Is it
> done
> because we value the cache ... or because someone changed the code in
> the meantime? Cache being valid, any sort of code change of cause
> invalid.

In general all caches should be fully transparent. That is also why it
is extremely important to get (bit-by-bit) reproducible builds as
otherwise the Bitbake signatures (which are used for the SSTATE) and
the state of the packages diverges. This is a concept we inherit from
Yocto and we should really try to not break it.

Partial rebuilds have the problem, that the input of a task might
change over time when cleanup mechanisms like [cleandirs] are not used
properly. This is more an annoying kind of thing, but not too relevant
for product builds. Anyways, we should try to at least fix the most
obvious cases.

Felix

> 
> Henning
> 
> Am Mon,  9 Jan 2023 05:14:25 +0000
> schrieb Felix Moessbauer <felix.moessbauer@siemens.com>:
> 
> > This series fixes both reproducability and rebuild issues when
> > using
> > the deb_add_changelog function.
> > 
> > p1, p2: fix the reproducability issue
> > p3:     add support for SOURCE_DATE_EPOCH
> > 
> > Best regards,
> > Felix
> > 
> > Felix Moessbauer (3):
> >   make deb_add_changelog idempotent
> >   deb_add_changelog: set timestamp to valid epoch
> >   deb_add_changelog: use SOURCE_DATE_EPOCH
> > 
> >  meta/classes/debianize.bbclass | 25 +++++++++++++++----------
> >  1 file changed, 15 insertions(+), 10 deletions(-)
> > 
> 


      reply	other threads:[~2023-01-09 10:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09  5:14 Felix Moessbauer
2023-01-09  5:14 ` [PATCH 1/3] make deb_add_changelog idempotent Felix Moessbauer
2023-01-09  9:19   ` Henning Schild
2023-01-09 10:42     ` Moessbauer, Felix
2023-01-09  5:14 ` [PATCH 2/3] deb_add_changelog: set timestamp to valid epoch Felix Moessbauer
2023-01-09  5:14 ` [PATCH 3/3] deb_add_changelog: use SOURCE_DATE_EPOCH Felix Moessbauer
2023-01-09  5:34   ` Jan Kiszka
2023-01-09  9:25   ` Henning Schild
2023-01-09 10:24     ` Moessbauer, Felix
2023-01-09 10:30     ` Jan Kiszka
2023-01-09  9:28 ` [PATCH 0/3] Fix reproducability issues in deb_add_changelog Henning Schild
2023-01-09 10:33   ` Moessbauer, Felix [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=e8f2c222c7560f36dd8ccf147b8395c9634ed77d.camel@siemens.com \
    --to=felix.moessbauer@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=venkata.pyla@toshiba-tsip.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox