[PATCH] image.bbclass: set file timestamps inside the rootfs and initramfs image

[venkat...@toshiba-tsip.com]

From: venkata pyla <venkat...@toshiba-tsip.com>

As part of reproducible-build work, one of the problem chosen to solve
is the file time stamps inside rootfs and initramfs are not identical
between two builds.

With the help of reproducible-builds.org and their suggestions, the
above problem can be fixed using 'SOURCE_DATE_EPOCH' variable [2].

In case of rootfs file time-stamps, set all the files and folders that
are newer than 'SOURCE_DATE_EPOCH' and set it to same.
In case of initramfs, regenerate the initramfs image with
'SOURCE_DATE_EPOCH' variable set as the mkinitramfs script is already
taken care of creating reproducible initramfs image when the
variable is set in the environment[3].

The SOURCE_DATE_EPOCH variable should be set to the last modification of
the git repository as explained in the documentation[2].

e.g:
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)

To know more about the reproducible builds and its goals please refer [1].

[1] https://reproducible-builds.org/
[2] https://reproducible-builds.org/docs/source-date-epoch/
[3] https://manpages.debian.org/bullseye/initramfs-tools-core/mkinitramfs.8.en.html#ENVIRONMENT

Signed-off-by: venkata pyla <venkat...@toshiba-tsip.com>
---
meta/classes/image.bbclass | 15 +++++++++++++++
1 file changed, 15 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index ccff810..c1bb4fd 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -431,6 +431,21 @@ do_rootfs_finalize() {
"${ROOTFSDIR}/etc/apt/sources.list.d/bootstrap.list"

rm -f "${ROOTFSDIR}/etc/apt/sources-list"
+
+ # Recreate initramfs inorder to set timestamps to SOURCE_DATE_EPOCH
+ # inorder to make reproducible initramfs
+ test ! -z "${SOURCE_DATE_EPOCH}" && \
+ SOURCE_DATE_EPOCH=${SOURCE_DATE_EPOCH} chroot "${ROOTFSDIR}" \
+ update-initramfs -u -v
+
+ # Set timestamp to files inside the rootfs image inorder to make
+ # reproducible rootfs
+ test ! -z "${SOURCE_DATE_EPOCH}" && \
+ find ${ROOTFSDIR} -newermt \
+ "$(date -d@${SOURCE_DATE_EPOCH} '+%Y-%m-%d %H:%M:%S')" \
+ -printf "%y %p\n" \
+ -exec touch '{}' -h -d@${SOURCE_DATE_EPOCH} ';'
+
EOSUDO
}
addtask rootfs_finalize before do_rootfs after do_rootfs_postprocess
--
2.20.1

[Moessbauer, Felix]

On Mon, 2022-11-07 at 13:55 +0530, venkat...@toshiba-tsip.com wrote:
> From: venkata pyla <venkat...@toshiba-tsip.com>
>
> As part of reproducible-build work, one of the problem chosen to
> solve
> is the file time stamps inside rootfs and initramfs are not identical
> between two builds.
>
> With the help of reproducible-builds.org and their suggestions, the
> above problem can be fixed using 'SOURCE_DATE_EPOCH' variable [2].
>
> In case of rootfs file time-stamps, set all the files and folders
> that
> are newer than 'SOURCE_DATE_EPOCH' and set it to same.

Hi,

is there a particular reason why we don't set all dates exactly to
SOURCE_DATE_EPOCH? Otherwise we might still have reproducibility issues
in case some files are provided by the sstate cache, hence have an
older timestamp. Building w/ or w/o cache should not make a difference.

Felix

[Henning Schild]

Am Mon, 7 Nov 2022 13:55:03 +0530
schrieb venkat...@toshiba-tsip.com:

This should be done where that initial update-initramfs can be found.
And not fix things up later. Not every image will have an initrd so
that is wrong in multiple ways.

> +
> + # Set timestamp to files inside the rootfs image inorder to
> make
> + # reproducible rootfs
> + test ! -z "${SOURCE_DATE_EPOCH}" && \
> + find ${ROOTFSDIR} -newermt \
> + "$(date -d@${SOURCE_DATE_EPOCH} '+%Y-%m-%d
> %H:%M:%S')" \
> + -printf "%y %p\n" \
> + -exec touch '{}' -h -d@${SOURCE_DATE_EPOCH} ';'
> +

No! Which files do we care about? My guess would content of packages
built with isar. We should export the variable in the dpkg class then
the packages will be correct and we do not have to mess around with
that rootfs and fix problems that should have never been there.

I would like to ask for test cases. Ideally first a breaking test and
later a commit fixing the issue.

Note that deriving the time from git means one needs git. And when
using layers just that one Isar git is clearly not good enough. And we
will have to check how that works with sstate. I assume any new commit
would rebuild all custom packages. Here i see a conflict between
regular dev work and repro pedantics. We might need a way to turn that
stuff off.

regards,
Henning

[Venkat...@toshiba-tsip.com]

Hi Felix,

Thanks for your review, please check my comments below.

Thanks,
Venkata.
>-----Original Message-----
>From: isar-...@googlegroups.com <isar-...@googlegroups.com> On Behalf
>Of Moessbauer, Felix
>Sent: 07 November 2022 14:21
>To: pyla venkata(ＴＳＩＰ TMIEC ODG Porting) <Venkata.Pyla@toshiba-
>tsip.com>
>Cc: dinesh kumar(ＴＳＩＰ TMIEC ODG Porting) <dinesh.kumar@toshiba-
>tsip.com>; isar-...@googlegroups.com; Kiszka, Jan <jan.k...@siemens.com>;
>hayashi kazuhiro(林 和宏 □ＳＷＣ◯ＡＣＴ) <kazuhiro...@toshiba.co.jp>;
>Schild, Henning <henning...@siemens.com>
>Subject: Re: [PATCH] image.bbclass: set file timestamps inside the rootfs and
>initramfs image

>
>On Mon, 2022-11-07 at 13:55 +0530, venkat...@toshiba-tsip.com wrote:
>> From: venkata pyla <venkat...@toshiba-tsip.com>
>>
>> As part of reproducible-build work, one of the problem chosen to solve
>> is the file time stamps inside rootfs and initramfs are not identical
>> between two builds.
>>
>> With the help of reproducible-builds.org and their suggestions, the
>> above problem can be fixed using 'SOURCE_DATE_EPOCH' variable [2].
>>
>> In case of rootfs file time-stamps, set all the files and folders that
>> are newer than 'SOURCE_DATE_EPOCH' and set it to same.
>
>Hi,
>
>is there a particular reason why we don't set all dates exactly to
>SOURCE_DATE_EPOCH? Otherwise we might still have reproducibility issues in
>case some files are provided by the sstate cache, hence have an older
>timestamp. Building w/ or w/o cache should not make a difference.

It is considered to change only the files that are created during build time and preserve the times in the files that are come with package,
anyway the files and their timestamps comes with the package are reproducible.

see some discussions about this change in the Debian live-build [1], where it is used for the same purpose to build Debian images reproducibly.

Regarding the files comes sstate cache, the reproducible builds should carry out in the fresh build or after cleaned up state, so I think this should not be a problem.

[1] https://salsa.debian.org/live-team/live-build/-/merge_requests/218

>--
>You received this message because you are subscribed to the Google Groups
>"isar-users" group.
>To unsubscribe from this group and stop receiving emails from it, send an email
>to isar-users+...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/isar-
>users/383fd6d397ccdb132b8e97602784417fcf2cd63d.camel%40siemens.com.

[Venkat...@toshiba-tsip.com]

Hi Henning Schild,

Thanks for your review, please find my comments below.

Thanks,
Venkata.

>-----Original Message-----
>From: Henning Schild <henning...@siemens.com>
>Sent: 07 November 2022 14:24
>To: pyla venkata(ＴＳＩＰ TMIEC ODG Porting) <Venkata.Pyla@toshiba-
>tsip.com>
>Cc: isar-...@googlegroups.com; jan.k...@siemens.com; hayashi kazuhiro(林
>和宏 □ＳＷＣ◯ＡＣＴ) <kazuhiro...@toshiba.co.jp>; dinesh kumar(ＴＳ
>ＩＰ TMIEC ODG Porting) <dinesh...@toshiba-tsip.com>
>Subject: Re: [PATCH] image.bbclass: set file timestamps inside the rootfs and
>initramfs image
>

Thanks for correcting me, I understood the initrd update should not be in the goal of image class, as some of the images may not be required initrd as you mentioned.
I will find the better place to do this and send the another patch.

>
>> +
>> + # Set timestamp to files inside the rootfs image inorder to
>> make
>> + # reproducible rootfs
>> + test ! -z "${SOURCE_DATE_EPOCH}" && \
>> + find ${ROOTFSDIR} -newermt \
>> + "$(date -d@${SOURCE_DATE_EPOCH} '+%Y-%m-%d
>> %H:%M:%S')" \
>> + -printf "%y %p\n" \
>> + -exec touch '{}' -h -d@${SOURCE_DATE_EPOCH} ';'
>> +
>
>No! Which files do we care about? My guess would content of packages built
>with isar. We should export the variable in the dpkg class then the packages will
>be correct and we do not have to mess around with that rootfs and fix
>problems that should have never been there.

This will only change the files are created during build, and not the files come with package.

The idea is to set time stamps to the files as same that are modified or added during build time (e.g: /etc/*) and they are newer than SOURCE_DATE_EPOCH date.

>
>I would like to ask for test cases. Ideally first a breaking test and later a commit
>fixing the issue.

I executed this in one of the child project (isar-cip-core) and reported the issue here [1], are you expecting to write test cases in isar?

[1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/31

[Henning Schild]

Am Wed, 9 Nov 2022 09:27:20 +0000
schrieb <Venkat...@toshiba-tsip.com>:

All files, or very close to all, come with packages. Because isar
builds packages for stuff it does. The wanted timestamp has to be
provided at build time of those packages so that later on one does not
need to run such a find.

You basically first want to make sure the packages (those from
isar-apt) are reproducible and only later look at the whole rootfs. That
whole rootfs will have remaining differences, just from what maintainer
hooks and stuff do.

That find violates the rule that everything should come from a package.
There are some exceptions to that rule in isar, but those are likely
the ones causing repro issues. And anyhow not everyone delivers only
the images, some people also deliver the packages. So those need to be
reproducible as well ... or even first.

> The idea is to set time stamps to the files as same that are modified
> or added during build time (e.g: /etc/*) and they are newer than
> SOURCE_DATE_EPOCH date.
>
>
> >
> >I would like to ask for test cases. Ideally first a breaking test
> >and later a commit fixing the issue.
>
> I executed this in one of the child project (isar-cip-core) and
> reported the issue here [1], are you expecting to write test cases in
> isar?
>
> [1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/31

The motivation always has to come with the patch. So that manual
diffoscope workflow should be explained in the commit message or
documentation. Ideally you would add a test that actually runs that and
asserts that there are no problems left. Or ignoring the left ones for
starters.

That layer and all other layers will later benefit. But whatever you
try to fix has to be explained and consistent inside isar only. So
issues from some layer clearly do not count.

Say we get the debian package feed to become reproducible, i bet we
could just compare the repo metadata and the package checksums. Not
even dive into the packages and check what might be different.

A good way of explaining a change is also to first write the test and
later the code to fix the problem a test shows. Everybody would
understand easily and if any future change would break it again we
would see before a merge.

regards,
Henning

[Balasubramanian Sundaram]

Hi 

I am using ISAR build system can you help me how to create a recipe for Bluez5

 in ISAR build system

Thanks & Regrads

--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/20221107082503.14774-1-venkata.pyla%40toshiba-tsip.com.

--

Balasubramanian Sundaram 

Firmware Engineer |  Sanmina Tech services |  India, Chennai  |  Desk: +91 044 61309865

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.

[Anton Mikanovich]

10.11.2022 12:52, 'Balasubramanian Sundaram' via isar-users wrote:

Hi 

I am using ISAR build system can you help me how to create a recipe for Bluez5

 in ISAR build system

Thanks & Regrads

Hello, Balasubramanian.

Current Debian repositories already provide bluez package (v5.55 for bullseye),
so you can just add it to IMAGE_INSTALL.
If you need to rebuild bluez to make some changes there, SRC_URI = "apt://bluez"
can be used (see hello.bb as a reference).

P.S. please avoid replying to existing maillist threads with the new questions

[Balasubramanian Sundaram]

Hi Anton

Iam getting this error for bluez

Thanks & Regards

[Balasubramanian Sundaram]

Hi Anton

And also could not open hello.bb for reference can you send it again

Regards

[Anton Mikanovich]

10.11.2022 13:17, Balasubramanian Sundaram wrote:

Hi Anton

Iam getting this error for bluez

Thanks & Regards

Sorry, I've meant IMAGE_PREINSTALL, not IMAGE_INSTALL.
IMAGE_PREINSTALL should be used for any package from external repos.
IMAGE_INSTALL should be used in case you will rebuild the package from repo
with your custom recipe.

hello.bb is located in Isar examples:
https://github.com/ilbers/isar/blob/master/meta-isar/recipes-app/hello/hello.bb

[Balasubramanian Sundaram]

Thank you for the clarification. 

but iam getting following error can you tell what it can be 

Regards

[Henning Schild]

Hey Balasubramanian,

you are making some fundamental mistakes here so that is why people
might not want to help you or would not know how to do so.

When you have a question for help please formulate it clearly and
give some context. You just want to install a debian package in your
image, use IMAGE_PREINSTALL.
You have to modify/rebuild that package ... check out the hello example
and use IMAGE_INSTALL.

So say you can just use the meta-package "bluetooth" you can have a
look at this part of the docs.
https://github.com/ilbers/isar/blob/master/doc/user_manual.md#create-a-custom-image-recipe

And consider giving this whole manual a read. It is not the best and
maybe not all clear when you read it first. But over time it should
make sense.

That said. Please avoid these mistakes:

- taking over a random discussion to talk about something totally
different, rather open a new one
- send debug output as screenshots ... they are hard to read and cite
(they all have the same name), and you leak stuff like the model of
your cell phone, or that your firmware is "Music" ... send the
relevant bits as text and say how you got there. Without your recipe
or change it is really hard to put your errors into any context.
the last one looks like you modified the image recipe of the cip
layer and added bluez as IMAGE_INSTALL where it should have been
IMAGE_PREINSTALL
- do not send html mails
- do not include CONFIDENTIALITY disclaimers, your mails are super
public so that does not make any sense

regards,
Henning

Am Thu, 10 Nov 2022 16:21:18 +0530
schrieb Balasubramanian Sundaram <balasubraman...@sanmina.com>:

[Henning Schild]

Am Thu, 10 Nov 2022 18:30:58 +0200
schrieb Henning Schild <henning...@siemens.com>:

> Hey Balasubramanian,
>
> you are making some fundamental mistakes here so that is why people
> might not want to help you or would not know how to do so.
>
> When you have a question for help please formulate it clearly and
> give some context. You just want to install a debian package in your
> image, use IMAGE_PREINSTALL.
> You have to modify/rebuild that package ... check out the hello
> example and use IMAGE_INSTALL.
>
> So say you can just use the meta-package "bluetooth" you can have a
> look at this part of the docs.
> https://github.com/ilbers/isar/blob/master/doc/user_manual.md#create-a-custom-image-recipe

I used plain isar, added "IMAGE_PREINSTALL += "bluetooth"" to the end
of meta-isar/recipes-core/images/isar-image-base.bb and did build it
with "bitbake mc:qemuamd64-bullseye:isar-image-base".

I booted it with
qemu-system-x86_64 -smp 2 -enable-kvm -M q35 -m 2G -snapshot
build/tmp/deploy/images/qemuamd64/isar-image-base-debian-bullseye-qemuamd64.wic
-bios /usr/share/OVMF/OVMF_CODE.fd

Works as expected. Well i have the packages like "bluez" installed ...

Of cause in a real project one would create a layer with an own image
recipe and add the line there.

Henning

[venkat...@toshiba-tsip.com]

From: venkata pyla <venkat...@toshiba-tsip.com>

This script helps to identify reproducible problems in isar image, it
uses 'diffoscope'[1] tool to check the difference between two
consecutive builds and copy the differeneces in html format.

[1] https://diffoscope.org/

Signed-off-by: venkata pyla <venkat...@toshiba-tsip.com>
---

scripts/repro-test.sh | 105 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
create mode 100755 scripts/repro-test.sh

diff --git a/scripts/repro-test.sh b/scripts/repro-test.sh
new file mode 100755
index 0000000..0509f32
--- /dev/null
+++ b/scripts/repro-test.sh
@@ -0,0 +1,105 @@
+#!/bin/bash
+
+set -e
+
+DISTRO="debian-bullseye"
+MACHINE="qemuamd64"
+DISTRO_ARCH="amd64"
+IMAGE_TYPE="isar-image-base"
+
+clean(){
+ if [ $? -eq 0 ]; then
+ [ -d $tmpdir ] && sudo rm -rf $tmpdir
+ else
+ echo "Keep build artifacts at $tmpdir"
+ fi
+}
+
+build(){
+ build_id="$1"
+ echo "Build name: $build_id"
+ mkdir "$tmpdir/build"
+
+ cd "$isar_root_dir"
+ . isar-init-build-env "$tmpdir/build" && bitbake mc:${MACHINE}-${DISTRO#*-}:${IMAGE_TYPE}
+
+ mv "$tmpdir/build" "$tmpdir/$build_id"
+}
+
+repro_check(){
+ image1="$tmpdir/$1/tmp/deploy/images/${MACHINE}/${IMAGE_TYPE}-${DISTRO}-${MACHINE}.tar.gz"
+ image2="$tmpdir/$2/tmp/deploy/images/${MACHINE}/${IMAGE_TYPE}-${DISTRO}-${MACHINE}.tar.gz"
+
+ # Compare two build artifacts
+ if diffoscope --html-dir "$tmpdir/diffoscope_html_output" "$image1" "$image2"; then
+ echo "[Success] The build artifacts are reproduicible"
+ else
+ echo "[Fail] The build artifacts are not matching"
+ fi
+}
+
+usage() {
+ echo "This script verifies the reproducibility of the Isar images."
+ echo
+ echo "Usage:"
+ echo " $0 [params]"
+ echo
+ echo "Parameters:"
+ echo " -d, --distro DISTRO set DISTRO variable for the builds (e.g.: debian-buster, debian-bullseye)"
+ echo " -m, --machine MACHINE set MACHINE variable for the builds (e.g.: qemuamd64, qemuarm64, qemuarmhf)"
+ echo " -a, --arch DISTRO_ARCH set DISTRO_ARCH variable for the builds (e.g.: amd64, arm64, armhf)"
+ echo " -h, --help"
+ echo
+}
+
+while [ "$1" != "" ]; do
+ case $1 in
+ -d | --distro )
+ shift
+ DISTRO="$1"
+ ;;
+ -m | --mahcine )
+ shift
+ MACHINE="$1"
+ ;;
+ -a | --arch )
+ shift
+ DISTRO_ARCH="$1"
+ ;;
+ -h | --help )
+ usage
+ exit
+ ;;
+ * )
+ usage
+ exit 1
+ esac
+ shift
+done
+
+if ! command -v diffoscope &> /dev/null
+then
+ echo "diffoscope could not be found"
+ exit
+fi
+
+cd "$(dirname "$0")/.."
+isar_root_dir="$(pwd)"
+
+echo "Distro: $DISTRO"
+echo "MACHINE: $MACHINE"
+echo "DISTRO_ARCH: $DISTRO_ARCH"
+
+# export the variables for the build
+export DISTRO=${DISTRO}
+export MACHINE=${MACHINE}
+export DISTRO_ARCH=${DISTRO_ARCH}
+
+# Temorary directory for keeping build artifacts
+tmpdir=$(mktemp --directory --tmpdir /home/seshu/temp/isar.repro.test.XXXXXXXXXX)
+trap clean INT TERM EXIT
+
+build build1
+build build2
+
+repro_check build1 build2
--
2.20.1

[Venkat...@toshiba-tsip.com]

>-----Original Message-----
>From: isar-...@googlegroups.com <isar-...@googlegroups.com> On Behalf

>Of Henning Schild
>Sent: 10 November 2022 12:42
>To: pyla venkata(ＴＳＩＰ TMIEC ODG Porting) <Venkata.Pyla@toshiba-
>tsip.com>

>Cc: isar-...@googlegroups.com; jan.k...@siemens.com; hayashi kazuhiro(林
>和宏 □ＳＷＣ◯ＡＣＴ) <kazuhiro...@toshiba.co.jp>; dinesh kumar(ＴＳ

I am trying to understand Isar and how it installs the debian packages, I think Isar rebuilds some of the packages from the sources using sbuild,
If that is so, then sbuild taken care of creating the package reproducibly, if it is not creating then we should definitely check why it is no generating reproducible packages.

The find command here mostly fixes the timestamps of files or folders that are created or modified during 'postinst' scripts (or after package installation).

>
>> The idea is to set time stamps to the files as same that are modified
>> or added during build time (e.g: /etc/*) and they are newer than
>> SOURCE_DATE_EPOCH date.
>>
>>
>> >
>> >I would like to ask for test cases. Ideally first a breaking test and
>> >later a commit fixing the issue.
>>
>> I executed this in one of the child project (isar-cip-core) and
>> reported the issue here [1], are you expecting to write test cases in
>> isar?
>>
>> [1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/31
>
>The motivation always has to come with the patch. So that manual diffoscope
>workflow should be explained in the commit message or documentation. Ideally
>you would add a test that actually runs that and asserts that there are no
>problems left. Or ignoring the left ones for starters.
>
>That layer and all other layers will later benefit. But whatever you try to fix has
>to be explained and consistent inside isar only. So issues from some layer
>clearly do not count.
>
>Say we get the debian package feed to become reproducible, i bet we could just
>compare the repo metadata and the package checksums. Not even dive into the
>packages and check what might be different.
>
>A good way of explaining a change is also to first write the test and later the
>code to fix the problem a test shows. Everybody would understand easily and if
>any future change would break it again we would see before a merge.

I agree with you and I have also sent patch[1] for this that have test script for verifying the reproducibility in Isar images.

[1] https://groups.google.com/g/isar-users/c/4ZIuKCOQzVc/m/sPUafWDgAgAJ

>
>regards,
>Henning
>
>> >
>> >Note that deriving the time from git means one needs git. And when
>> >using layers just that one Isar git is clearly not good enough. And
>> >we will have to check how that works with sstate. I assume any new
>> >commit would rebuild all custom packages. Here i see a conflict
>> >between regular dev work and repro pedantics. We might need a way to
>> >turn that stuff off.
>> >
>> >regards,
>> >Henning
>> >
>> >> EOSUDO
>> >> }
>> >> addtask rootfs_finalize before do_rootfs after
>> >> do_rootfs_postprocess
>>
>

>--
>You received this message because you are subscribed to the Google Groups
>"isar-users" group.
>To unsubscribe from this group and stop receiving emails from it, send an email
>to isar-users+...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/isar-

>users/20221110091226.4a3695f2%40md1za8fc.ad001.siemens.net.

[Anton Mikanovich]

20.11.2022 10:53, venkat...@toshiba-tsip.com wrote:
> From: venkata pyla <venkat...@toshiba-tsip.com>
>
> This script helps to identify reproducible problems in isar image, it
> uses 'diffoscope'[1] tool to check the difference between two
> consecutive builds and copy the differeneces in html format.
>
> [1] https://diffoscope.org/
>
> Signed-off-by: venkata pyla <venkat...@toshiba-tsip.com>

Hello, any chance this can be integrated into our testsuite?

[Venkat...@toshiba-tsip.com]

>-----Original Message-----
>From: isar-...@googlegroups.com <isar-...@googlegroups.com> On Behalf

>Of Anton Mikanovich
>Sent: 22 November 2022 12:58
>To: pyla venkata(ＴＳＩＰ TMIEC ODG Porting) <Venkata.Pyla@toshiba-

>tsip.com>; isar-...@googlegroups.com
>Cc: jan.k...@siemens.com; henning...@siemens.com; hayashi kazuhiro(林
>和宏 □ＳＷＣ◯ＡＣＴ) <kazuhiro...@toshiba.co.jp>; dinesh kumar(ＴＳ

>ＩＰ TMIEC ODG Porting) <dinesh...@toshiba-tsip.com>

>Subject: Re: [PATCH] scripts/repro-test.sh: script to test reproducibility of Isar
>image

Hi,
Thanks for considering, I have not used avocado framework much, so it will take some more time for me to implement this test in the testsuite format.

Can we use this bash script test case currently and later upgrade to testsuite format?

>
>--
>You received this message because you are subscribed to the Google Groups
>"isar-users" group.
>To unsubscribe from this group and stop receiving emails from it, send an email
>to isar-users+...@googlegroups.com.
>To view this discussion on the web visit

>https://groups.google.com/d/msgid/isar-users/18251c8e-6732-5f0e-dcf4-
>1e34fbe804ef%40ilbers.de.

[venkat...@toshiba-tsip.com]

From: venkata pyla <venkat...@toshiba-tsip.com>

Hi,

The below patch set will add the test for verifying the rootfs images
are reproducible, it will help to identify the reproducible problems
and also can verify the fixes that solves the problem.

Please check if this can add to the isar testsuite and eventually helps
to verify the reproducible problems in isar.

Looking forward for your feedback.

Thanks,
Venkata.

venkata pyla (2):
cibuilder.py: Add source_date_epoch to build configuration
repro-build-test.py: Test to check images are reproducible

testsuite/cibuilder.py | 5 ++-
testsuite/repro-build-test.py | 68 +++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 1 deletion(-)
create mode 100755 testsuite/repro-build-test.py

--
2.20.1

[venkat...@toshiba-tsip.com]

From: venkata pyla <venkat...@toshiba-tsip.com>

This test verifies whether the images are reproducible by checking with
in-depth comparision tool `diffoscope` and produces a comparision output
in plain text format for checking the differences.

Signed-off-by: venkata pyla <venkat...@toshiba-tsip.com>
---

testsuite/repro-build-test.py | 68 +++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100755 testsuite/repro-build-test.py

diff --git a/testsuite/repro-build-test.py b/testsuite/repro-build-test.py
new file mode 100755
index 0000000..e89becf
--- /dev/null
+++ b/testsuite/repro-build-test.py
@@ -0,0 +1,68 @@
+#!/usr/bin/env python3
+
+import glob
+import os
+import re
+import tempfile
+import time
+
+from cibuilder import CIBuilder, isar_root
+from avocado.utils import process
+
+class ReproBuild(CIBuilder):
+
+ """
+ Test reproducible builds by comparing the artifacts
+
+ :avocado: tags=repro-build
+ """
+ def test_repro_build(self):
+ target = self.params.get('build_target', default='mc:qemuamd64-bullseye:isar-image-base')
+ source_date_epoch = self.params.get('source_date_epoch', default=self.git_last_commit_timestamp())
+ self.init()
+ self.build_repro_image(target, source_date_epoch, 'image1.tar.gz')
+ self.build_repro_image(target, source_date_epoch, 'image2.tar.gz')
+ self.compare_repro_image('image1.tar.gz', 'image2.tar.gz')
+
+ def git_last_commit_timestamp(self):
+ return process.run('git log -1 --pretty=%ct').stdout
+
+ def get_image_path(self, target_name):
+ image_dir = "tmp/deploy/images"
+ target_params = target_name.split(':')
+ machine = target_params[1].split('-')[0]
+ distro = 'debian-' + target_params[1].split('-')[1]
+ image_type = target_params[2]
+ return f'{image_dir}/{machine}/{image_type}-{distro}-{machine}.tar.gz'
+
+ def build_repro_image(self, target, source_date_epoch=None ,image_name='image.tar.gz'):
+
+ if not source_date_epoch:
+ self.error("Reproducible build should configure with source_date_epoch time")
+
+ # clean artifacts before build
+ self.clean()
+
+ # Build
+ self.log.info("Started Build " + image_name)
+ self.configure(source_date_epoch=source_date_epoch)
+ self.bitbake(target)
+
+ # copy the artifacts image name with given name
+ image_path = self.get_image_path(target)
+ self.log.info("Copy image " + image_path + " as " + image_name)
+ self.move_in_build_dir(image_path, image_name)
+
+ def clean(self):
+ self.delete_from_build_dir('tmp')
+ self.delete_from_build_dir('sstate-cache')
+
+ def compare_repro_image(self, image1, image2):
+ self.log.info("Compare artifacts image1: " + image1 + ", image2: " + image2)
+ result = process.run('diffoscope '
+ '--text ' + self.build_dir + '/diffoscope-output.txt'
+ ' ' + self.build_dir + '/' + image1 +
+ ' ' + self.build_dir + '/' + image2 ,
+ ignore_status = True)
+ if result.exit_status > 0:
+ self.fail(f'Images {image1} and {image2} are not reproducible')
--
2.20.1

[venkat...@toshiba-tsip.com]

From: venkata pyla <venkat...@toshiba-tsip.com>

This variable sets the SOURCE_DATE_EPOCH variable for the reproducible
builds check.

Importance of this vairable for the reproducible builds can find here [1]

[1] https://reproducible-builds.org/docs/source-date-epoch/

Signed-off-by: venkata pyla <venkat...@toshiba-tsip.com>
---

testsuite/cibuilder.py | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/testsuite/cibuilder.py b/testsuite/cibuilder.py
index d5c83b2..956d795 100755
--- a/testsuite/cibuilder.py
+++ b/testsuite/cibuilder.py
@@ -54,7 +54,7 @@ class CIBuilder(Test):

def configure(self, compat_arch=True, cross=None, debsrc_cache=False,
container=False, ccache=False, sstate=False, offline=False,
- gpg_pub_key=None, wic_deploy_parts=False, **kwargs):
+ gpg_pub_key=None, wic_deploy_parts=False, source_date_epoch=None, **kwargs):
# write configuration file and set bitbake_args
# can run multiple times per test case
self.check_init()
@@ -78,6 +78,7 @@ class CIBuilder(Test):
f' sstate = {sstate}\n'
f' gpg_pub_key = {gpg_pub_key}\n'
f' wic_deploy_parts = {wic_deploy_parts}\n'
+ f' source_date_epoch = {source_date_epoch} \n'
f'===================================================')

# determine bitbake_args
@@ -113,6 +114,8 @@ class CIBuilder(Test):
if ccache:
f.write('USE_CCACHE = "1"\n')
f.write('CCACHE_TOP_DIR = "${TOPDIR}/ccache"\n')
+ if source_date_epoch:
+ f.write('SOURCE_DATE_EPOCH = "%s"\n' % source_date_epoch)

# include ci_build.conf in local.conf
with open(self.build_dir + '/conf/local.conf', 'r+') as f:
--
2.20.1

[Anton Mikanovich]

Applied to next, thanks.

[venkat...@toshiba-tsip.com]

From: venkata pyla <venkat...@toshiba-tsip.com>

Signed-off-by: venkata pyla <venkat...@toshiba-tsip.com>
---

testsuite/repro-build-test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuite/repro-build-test.py b/testsuite/repro-build-test.py
index e89becf..128081e 100755
--- a/testsuite/repro-build-test.py
+++ b/testsuite/repro-build-test.py
@@ -25,7 +25,7 @@ class ReproBuild(CIBuilder):

self.compare_repro_image('image1.tar.gz', 'image2.tar.gz')

def git_last_commit_timestamp(self):
- return process.run('git log -1 --pretty=%ct').stdout
+ return process.run('git log -1 --pretty=%ct').stdout.decode().strip()

def get_image_path(self, target_name):
image_dir = "tmp/deploy/images"
--
2.20.1

[Henning Schild]

This was merged into "master", if we did have linter checks like
"flake8" on python code this one would certainly fail them.

A simple
black testsuite/repro-build-test.py

already makes it much happier.

And the several "imported but unused" could also be checked.

venkata pyla please have a look at this if you want

run
black testsuite/repro-build-test.py

and see if you like the result

run
flake8 testsuite/repro-build-test.py

and see if you can fix things it reports

possibly do that in "black" and "flake8" loops until both agree

And maybe do the same thing for other .py files if you like.

The whole repro story is about being pedantic so let us use tools that
help us with being very pedantic.

Henning


Am Mon, 19 Dec 2022 20:11:47 +0530
schrieb venkat...@toshiba-tsip.com:

[Uladzimir Bely]

In the email from Monday, 2 January 2023 09:24:37 +03 user

venkat...@toshiba-tsip.com wrote:
> From: venkata pyla <venkat...@toshiba-tsip.com>
>
> Signed-off-by: venkata pyla <venkat...@toshiba-tsip.com>
> ---
> testsuite/repro-build-test.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>

Applied to next, thanks.