On Sat, Feb 19, 2022 at 5:28 AM Jimmy Assarsson <[email protected]> wrote: > > When patching a kernel git repository, in a recipe inheriting > kernel-yocto.bbclass, > the resulting commit hash will become different every time the source is > unpacked and patched. > > This is a problem that causes non-reproducible builds, when the commit hash > is built > into the kernel (CONFIG_LOCALVERSION_AUTO=y). > > > Currently it is not a problem in linux-yocto, since an empty .scmversion is > created in kernel_do_configure [1]. This is preventing the kernel build from > generating its own .scmversion. > > If removing this commit, setting CONFIG_LOCALVERSION_AUTO=y and applying any > patch in the linux-yocto recipe, this will result in a non-reproducible build. > > > However, there are other kernel recipes where this is already a problem; > meta-freescale [2] and meta-tegra [3]. > > Currently we solve this problem by using the --committer-date-is-author-date > "git am" option, when applying patches with kgit-s2q: > From f2b6cdb745e7a7965497efccff415ec81207f4d7 Mon Sep 17 00:00:00 2001 > From: Jimmy Assarsson <[email protected]> > Date: Fri, 4 Feb 2022 17:58:29 +0100 > Subject: [PATCH] kgit-s2q: call "git am" with --committer-date-is-author-date > > Produce deterministic commit hashes, by passing the > "--committer-date-is-author-date" option when applying patches with "git am". > > Signed-off-by: Jimmy Assarsson <[email protected]> > --- > tools/kgit-s2q | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/kgit-s2q b/tools/kgit-s2q > index 706783e..b46a138 100755 > --- a/tools/kgit-s2q > +++ b/tools/kgit-s2q > @@ -558,7 +558,7 @@ do > echo "($APPLIED/$COUNT) `basename $i`" > fi > > - git am --keep-non-patch $DIR/$i > /dev/null 2>&1 > + git am --keep-non-patch --committer-date-is-author-date $DIR/$i > > /dev/null 2>&1 > if [ $? != 0 ];then > git am --abort > /dev/null 2>&1 > echo "[INFO]: check of $DIR/$i with \"git am\" did not pass, > trying reduced context." > > > > I'm not sure if this is a proper solution to fix the problem or what side > effects it may introduce?
There's nothing fundamentally wrong with that solution, but there are modes for the kernel builds where we absolutely do not want the reproducible build (and older dates) to be in effect (see my comments on the OE core mailing list when the ability to disable reproducible builds was almost removed). We could add an option to the patch queue management that was enabled when reproducible builds are in play, so git am could operate like that. Alternatively, you could bbappend the other kernel's do_configure and do the same .scmversion trick to make sure that everything is consistent. Bruce > > [1] > https://git.yoctoproject.org/poky/tree/meta/classes/kernel.bbclass?h=honister#n589 > [2] > https://git.yoctoproject.org/meta-freescale/tree/classes/fsl-kernel-localversion.bbclass?h=honister > [3] > https://github.com/OE4T/meta-tegra/blob/honister/recipes-kernel/linux/linux-tegra_4.9.bb > > Best regards, > jimmy -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10964): https://lists.yoctoproject.org/g/linux-yocto/message/10964 Mute This Topic: https://lists.yoctoproject.org/mt/89251386/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
