On Thu, Nov 28, 2024 at 2:19 AM Enrico Jörns <e...@pengutronix.de> wrote:
> Hi Bruce,
>
> Am Mittwoch, dem 27.11.2024 um 10:28 -0500 schrieb Bruce Ashfield:
> >
> > [...]
> > >
> > > I have some context on this that I would like to add since we just
> faced a similar issue in a
> > > project.
> > >
> > > The above-mentioned issue is caused by a combinations of:
> > >
> > > * a kernel recipe using kernel-yocto.bbclass
> > > * kernel source pointing to tar (rather than a git)
> > > * CONFIG_LOCALVERSION_AUTO set in kernel config
> > >
> > > The kernel-yocto class creates a Git repository from the archive
> content, resulting in an
> > > unreproducible commit hash (due to using the current user's Git author
> settings and the current
> > > system time). Subsequently, CONFIG_LOCALVERSION_AUTO causes this
> commit hash to be embedded in
> > > the
> > > kernel version, leading to non-reproducible kernel version strings.
> > >
> > > I guess the correct way to handle this would be to create the initial
> git commit with e.g.
> > > PATCH_GIT_USER_NAME/PATCH_GIT_USER_EMAIL and set the date to something
> like SOURCE_DATE_EPOCH.
> >
> > That should already be in place (the username and email). See the call
> to "check_git_config" in
> > the bbclass.
>
> yes, exactly. They are already defined, but not used (except for the
> config check).
>
Hmm. That's not my experience. Since without them, git won't apply any
patches and that's exactly why we added the check.
Something else probably changed since I added the check that pulled it out
of the environment.
>
> > If it really is just the creation of the repository that is the issue
> here, then I could
> > absolutely bring over some of the reproducible git options that are used
> in the kern-tools (see
> > below).
>
> As far as we and our customer have analyzed the issue, it was just the
> initial git commit when
> creating a git out of an archive.
> The subsequent commits for patches are reproducible (at least in our test
> case).
>
> The proof-of-concept that worked here is:
>
We'd want those exported to the environment, not directly in the location
that git is invoked.
That is what it used to do .. and as you've noted, it may be broken. But
yes, that was the
intent all along of those variables. There is also an alternative to
simplify the flags where
we can just make the committer and author date the same (like the
kern-tools do).
But those are all just minor details, the concept is the same.
> --- a/meta/classes-recipe/kernel-yocto.bbclass
> +++ b/meta/classes-recipe/kernel-yocto.bbclass
> @@ -428,6 +428,9 @@ do_kernel_checkout() {
> git init
> check_git_config
> git add .
> + # create a reproducible initial commit
> + GIT_AUTHOR_NAME="${PATCH_GIT_USER_NAME}"
> GIT_AUTHOR_EMAIL="${PATCH_GIT_USER_EMAIL}" GIT_AUTHOR_DATE="$(date -d
> @${SOURCE_DATE_EPOCH})" \
> + GIT_COMMITTER_NAME="${GIT_AUTHOR_NAME}"
> GIT_COMMITTER_EMAIL="${GIT_AUTHOR_EMAIL}"
> GIT_COMMITTER_DATE="${GIT_AUTHOR_DATE}" \
> git commit -q -n -m "baseline commit: creating repo for
> ${PN}-${PV}"
> git clean -d -f
> fi
>
> > It also depends on exactly how the kernel is being patched. If the
> kern-tools are being used, then
> > reproducible commits are already the case.
> >
> > If the lib/oe/patch.bbclass is being used, I don't see options like
> --committer-date-is-author-
> > date being used, but I suspect I'm just not looking in the right place,
> since if the weren't
> > anyone using PATCHTOOL="git" might be running into reproducibility
> issues, but only if what they
> > are building captures git hashes .... which is the hint).
>
> Haven't used PATCHTOOL="git" yet, but when doing so I can actually confirm
> that the initial commit
> there is also *not* reproducible. As you noted, this isn't much of a
> surprise since patch.py makes a
> simple "git commit" there, too.
> The better way would be to set the env variable here, too
> ("--commiter-date-is-author-date" doesn't
> work in this case since this is a "git am" flag). Would you agree?
>
I thought it was a flag which was passed down to the actual application,
but I haven't
looked at it in detail, so I'll take your word for it. As long as they are
in the environment
and not defined at the location of the git call, it will be fine.
Cheers,
Bruce
> > > If that sounds right, I could make a patch against
> kernel-yocto.bbclass.
> > >
> > > A project-specific quick fix would be of course to just disable
> CONFIG_LOCALVERSION_AUTO.
> >
> > This is what I do in oe-core (I've never liked localversion_auto).
>
> Yes. In our specific case it was also enabled more accidentally than
> intended.
>
>
> Regards, Enrico
>
> > Bruce
> >
> >
> > >
> > > Regards, Enrico
> > >
> > > > Christian
> > > >
> > > >
> > > >
> > >
>
> --
> Pengutronix e.K. | Enrico Jörns |
> Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
> Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
> 31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |
>
--
- 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 (#64373): https://lists.yoctoproject.org/g/yocto/message/64373
Mute This Topic: https://lists.yoctoproject.org/mt/109804058/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
