From: Henning Schild <henning.schild@siemens.com>
To: "Moessbauer, Felix (T CED INW-CN)" <felix.moessbauer@siemens.com>
Cc: "roberto.foglietta@gmail.com" <roberto.foglietta@gmail.com>,
"ubely@ilbers.de" <ubely@ilbers.de>,
"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: Re: [PATCH v2 01/10] fix rebuild of rootfs_finalize task
Date: Mon, 23 Jan 2023 10:00:59 +0100 [thread overview]
Message-ID: <20230123100059.0b4fdc57@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <6c56ebc3f7d1524c2799afc0e520bf9aff216cf9.camel@siemens.com>
Am Sun, 15 Jan 2023 14:31:46 +0100
schrieb "Moessbauer, Felix (T CED INW-CN)"
<felix.moessbauer@siemens.com>:
> On Sat, 2023-01-14 at 23:47 +0300, Uladzimir Bely wrote:
> > In the email from Thursday, 12 January 2023 08:56:10 +03 user Felix
> > Moessbauer
> > wrote:
> > > [PATCH v2 01/10] fix rebuild of rootfs_finalize task
> >
> > Again, we had 4 different solutions for this (as single patches)
>
> I'm fully aware of that. In the end it is the maintainers decision
> which patch to integrate. We just need the fix here as otherwise the
> whole reproducibility story cannot be tested.
That was all a mess. My patch was first and later people wrote
conflicting patches without saying so. We can do that but it would help
the maintainer a lot if the cover-letters would say which other patches
become obsolete, or if one comments on those other patches.
I also do not care which one gets picked. Just try to point out
conflicts to help the maintainer.
Henning
> I'm perfectly fine with taking Hennings patch. It anyways looks like
> we will need a v3 of this series. Then, I can either add Hennings
> patch or simply rebase against next in case one of the patches will
> already be integrated then.
>
> PS: Please do not discuss details of this particular patch as part of
> this series. It is really only a necessary enabler, but has been sent
> as dedicated patches already. Please discuss it on the original patch
> series.
>
> Felix
>
> >
> > Felix: [PATCH] fix rebuild of rootfs_finalize task
> > Roberto: [PATCH v4] image: make sure do_rootfs_finalize can run
> > multiple
> > times, v4
> > Roberto: [PATCH] image class bugfix: interuption does not break the
> > rebuild
> > Henning: [PATCH] image: make sure do_rootfs_finalize can run
> > multiple times
> >
> > Now, the first one comes as part of series... I think, we should
> > pick Henning's solution instead, since it acts better ("check first
> > than do stuff"
> > instead of "try stuff and 'true' if fails), and drop the alternative
> > patch
> > from the series.
> >
> >
>
next prev parent reply other threads:[~2023-01-23 9:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 5:56 [PATCH v2 00/10] Make rootfs build reproducible Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 01/10] fix rebuild of rootfs_finalize task Felix Moessbauer
2023-01-14 20:47 ` Uladzimir Bely
2023-01-14 22:16 ` Roberto A. Foglietta
2023-01-14 23:35 ` Roberto A. Foglietta
2023-01-15 13:31 ` Moessbauer, Felix
2023-01-23 9:00 ` Henning Schild [this message]
2023-01-12 5:56 ` [PATCH v2 02/10] image.bbclass: fix non-reproducible file time-stamps inside rootfs Felix Moessbauer
2023-01-14 20:26 ` Uladzimir Bely
2023-01-14 20:31 ` Roberto A. Foglietta
2023-01-14 20:39 ` Uladzimir Bely
2023-01-15 13:42 ` Moessbauer, Felix
2023-01-15 21:57 ` Roberto A. Foglietta
2023-01-12 5:56 ` [PATCH v2 03/10] rootfs postprocess: clean python cache Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 04/10] remove non-portable ldconfig aux-cache Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 05/10] generate deterministic clear-text password hash Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 06/10] update debian initramfs in deterministic mode Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 07/10] create custom " Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 08/10] make deb_add_changelog idempotent Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 09/10] deb_add_changelog: set timestamp to valid epoch Felix Moessbauer
2023-01-12 5:56 ` [PATCH v2 10/10] make custom linux-image bit-by-bit reproducible Felix Moessbauer
2023-01-12 9:35 ` [PATCH v2 00/10] Make rootfs build reproducible Henning Schild
[not found] ` <CAJGKYO6i0hUBs4XeBtzLKnVVS6sRdVuEG9v87+wHPvXpiHzMWA@mail.gmail.com>
2023-01-13 2:29 ` 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=20230123100059.0b4fdc57@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=felix.moessbauer@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=roberto.foglietta@gmail.com \
--cc=ubely@ilbers.de \
/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