Re: revision not displayed in a2440348eed7

Do you have WITHOUT_REPRODUCEABLE_BUILDS=YES in your src.conf?

Warner

On Wed, Nov 8, 2023, 9:03 PM Cy Schubert <Cy.Schubert@cschubert.com> wrote:

> On Wed, 8 Nov 2023 15:14:34 +0100
> Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:
>
> > W dniu 8.11.2023 o 14:10, Marek Zarychta pisze:
> > >
> > > W dniu 27.09.2023 o 01:07, Tomoaki AOKI pisze:
> > >> On Tue, 26 Sep 2023 15:19:46 -0700
> > >> Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> > >>
> > >>> In message <20230926231431.20f42fec1075c3980446c50a@dec.sakura.ne.jp
> >,
> > >>> Tomoaki
> > >>> AOKI writes:
> > >>>> On Tue, 26 Sep 2023 15:48:50 +0200
> > >>>> Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:
> > >>>>
> > >>>>> W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze:
> > >>>>>> At least up to 15.0-CURRENT, nothing has happend by
> > >>>>>> WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in
> > >>>>>> 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7,
> > >>>>>> but revision not showed by `uname -a' ;-(
> > >>>>>>
> > >>>>>> What changed ????
> > >>>>> Nothing changed. Perhaps your build system can't check git hash ?
> If
> > >>>>> your sources are from git repository, you need at least git-lite
> > >>>>> installed and full git repository available on build machine. If
> you
> > >>>>> checked out the repository with gitup and have gitup installed, it
> > >>>>> should also work. It won't work if your build machine has accessÂ
> to
> > >>>>> only a part of the repository like worktree.
> > >>>>>
> > >>>>> Cheers
> > >>>>>
> > >>>>> --
> > >>>>> Marek Zarychta
> > >>>> Just a possibility, but copying src tree to directory other than the
> > >>>> directory where checked out from git repo and building there could
> > >>>> lose track with git hash.
> > >>>>
> > >>>> Another possibility is that if you build src with any user other
> than
> > >>>> the one owning local (pulled) git repo could also lose track with
> git
> > >>>> hash. For example, if I `git log HEAD` with regular user and the
> local
> > >>>> repo is pulled by root, it fails. No special configuration is done.
> > >>>>
> > >>>> % git log HEAD
> > >>>> fatal: detected dubious ownership in repository at '/usr/src'
> > >>>> To add an exception for this directory, call:
> > >>>>
> > >>>>          git config --global --add safe.directory /usr/src
> > >>>>
> > >>>>
> > >>> This could be due to e6dc6a27230, which was committed this morning.
> > >>> There
> > >>> is discussion on the src commits ML (dev-commits-src-all,
> > >>> dev-commits-src-main) about reverting the change.
> > >>>
> > >>>
> > >>> --
> > >>> Cheers,
> > >>> Cy Schubert <Cy.Schubert@cschubert.com>
> > >>> FreeBSD UNIX:  <cy@FreeBSD.org>   Web: https://FreeBSD.org
> > >>> NTP:           <cy@nwtime.org>    Web: https://nwtime.org
> > >>>
> > >>>             e^(i*pi)+1=0
> > >> Would be unrelated here, unfortunately.
> > >> As the subject says, the commit the original reporter is bitten at
> (not
> > >> bi-sected) is at a2440348eed7, which is before e6dc6a27230.
> > >
> > > Let's refresh this thread. It looks like (at least for stable/14)
> > > build system doesn't hardcode revision into the kernel anymore. Last
> > > time it worked to me was just after branching stable/14. Today I tried
> > > to build kernel from sources mounted over NFS and I ened with:
> > >
> > > # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel | grep
> > > 14.0-STABLE
> > > @(#)FreeBSD 14.0-STABLE #6 -dirty: Tue Nov  7 14:04:35 CET 2023
> > > FreeBSD 14.0-STABLE #6 -dirty: Tue Nov  7 14:04:35 CET 2023
> > > 14.0-STABLE
> > >
> > > the source repository is updated, consisted, but mounted read-only
> > > over NFS
> > >
> > > /usr/src# git status
> > > On branch stable/14
> > > Your branch is up to date with 'origin/stable/14'.
> > >
> > > Untracked files:
> > >   (use "git add <file>..." to include in what will be committed)
> > >         sys/amd64/conf/BSDONDELL
> > >
> > > It took 2.53 seconds to enumerate untracked files.
> > > See 'git help status' for information on how to improve this.
> > >
> > > nothing added to commit but untracked files present (use "git add" to
> > > track)
> > >
> > >
> > > Any clues what could be wrong ? Does /usr/src/  require write
> > > permissions now ?
> >
> >
> > I am sorry for the false alarm. It looks like using META MODE prevented
> > updating this info. After cleaning obj dir and rebuilding revision is
> > visible:
> > # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel | grep
> > 14.0-STABLE
> > @(#)FreeBSD 14.0-STABLE #0 stable/14-n265707-d2c65a1c9486: Wed Nov  8
> > 14:16:31 CET 2023
> > FreeBSD 14.0-STABLE #0 stable/14-n265707-d2c65a1c9486: Wed Nov  8
> > 14:16:31 CET 2023
> >
>
> sys/conf/newvers.sh is responsible for getting the git hash into the
> kernel. If it finds a .git directory it will extract the hash to insert
> it into the kernel.
>
> I suspect there is something about your source tree that causes it to
> think there is no .git directory. In sys/conf/newvers.sh you will see
> where it sets $git_cmd when a .git directory exists. It subsequently
> tests for a non-zero $git_cmd string whereby it extracts the git hash.
>
> You might want to look through newvers.sh. Understanding what it does
> might point you to the cause of your problem, should it be that your
> tree is missing a .git directory or if your .git directory isn't quite
> right.
>
> That's the hypothesis ATM.
>
> --
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
> NTP:           <cy@nwtime.org>    Web:  https://nwtime.org
>
>                         e^(i*pi)+1=0
>
>