public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: Felix Moessbauer <felix.moessbauer@siemens.com>
Cc: isar-users@googlegroups.com, jan.kiszka@siemens.com,
	venkata.pyla@toshiba-tsip.com
Subject: Re: [PATCH 1/3] make deb_add_changelog idempotent
Date: Mon, 9 Jan 2023 10:19:29 +0100	[thread overview]
Message-ID: <20230109101929.6e3eb90e@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <20230109051428.450854-2-felix.moessbauer@siemens.com>

Am Mon,  9 Jan 2023 05:14:26 +0000
schrieb Felix Moessbauer <felix.moessbauer@siemens.com>:

> Previously, the deb_add_changelog function considered an
> auto-generated changelog as a base to add changes on top. This
> behavior is not idempontent on subsequent invocations of the function
> (e.g. on partial rebuilds). This lead to both reproducability issues,
> as well as unclean changelog files having multiple "generated by
> ISAR" entries.

Can you provide an example of that? Like how the wrong changelog would
look like and why it would be wrong.

partial rebuilds (especially when code was modified inbetween) are hard
to argue in the context of reproducible builds.

> This patch changes this implementation in a way to always create a
> (possibly empty) orig changelog on the first invocation. On subequent
> invocations, the orig changelog is only considered as provided by the
> user, if it is not empty.
> 
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> ---
>  meta/classes/debianize.bbclass | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/classes/debianize.bbclass
> b/meta/classes/debianize.bbclass index d125256..34347b5 100644
> --- a/meta/classes/debianize.bbclass
> +++ b/meta/classes/debianize.bbclass
> @@ -15,7 +15,9 @@ MAINTAINER ??= "Unknown maintainer
> <unknown@example.com>" deb_add_changelog() {
>  	changelog_v="${CHANGELOG_V}"
>  	timestamp=0
> -	if [ -f ${S}/debian/changelog ]; then
> +	# we have a changelog and that is not autogenerated
> +	# (when autogenerated, changelog.orig is empty)
> +	if [ -f ${S}/debian/changelog ] && [ -s
> ${WORKDIR}/changelog.orig ]; then if [ ! -f ${WORKDIR}/changelog.orig

can that condition inside the condition still be met?

Henning

> ]; then cp ${S}/debian/changelog ${WORKDIR}/changelog.orig
>  		fi
> @@ -34,10 +36,12 @@ ${PN} (${changelog_v}) UNRELEASED; urgency=low
>  
>   -- ${MAINTAINER}  ${date}
>  EOF
> -	if [ -f ${WORKDIR}/changelog.orig ]; then
> -		# prepend our entry to the original changelog
> -		echo >> ${S}/debian/changelog
> -		cat ${WORKDIR}/changelog.orig >>
> ${S}/debian/changelog
> +	# ensure that we always start with the orig version of the
> +	# changelog on repeated invocations (e.g. on partial
> rebuilds)
> +	touch ${WORKDIR}/changelog.orig
> +	# prepend our entry to the original changelog
> +	echo >> ${S}/debian/changelog
> +	cat ${WORKDIR}/changelog.orig >> ${S}/debian/changelog
>  	fi
>  
>  	if [ -f ${WORKDIR}/changelog ]; then


  reply	other threads:[~2023-01-09  9:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09  5:14 [PATCH 0/3] Fix reproducability issues in deb_add_changelog Felix Moessbauer
2023-01-09  5:14 ` [PATCH 1/3] make deb_add_changelog idempotent Felix Moessbauer
2023-01-09  9:19   ` Henning Schild [this message]
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

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=20230109101929.6e3eb90e@md1za8fc.ad001.siemens.net \
    --to=henning.schild@siemens.com \
    --cc=felix.moessbauer@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