W dniu 9.11.2023 o 05:32, Warner Losh pisze:
Do you have WITHOUT_REPRODUCEABLE_BUILDS=YES in your src.conf?
Yes, I have it.
Warner
On Wed, Nov 8, 2023, 9:03 PM Cy Schubert <cy.schub...@cschubert.com>
wrote:
On Wed, 8 Nov 2023 15:14:34 +0100
Marek Zarychta <zarych...@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.schub...@cschubert.com> wrote:
> >>
> >>> In message
<20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>,
> >>> Tomoaki
> >>> AOKI writes:
> >>>> On Tue, 26 Sep 2023 15:48:50 +0200
> >>>> Marek Zarychta <zarych...@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.schub...@cschubert.com>
> >>> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
<https://FreeBSD.org>
> >>> NTP: <c...@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.
Thank you for the clue. The error was temporary only, due to not
mounting /usr/src_head which holds the repository but mounting only
workdir /usr/src_14 newvers.sh wasn't able to check git hash. Cleanup,
mounting again both directories and rebuilding the kernel solved the
problem.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
<https://FreeBSD.org>
NTP: <c...@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
Thank you for your help.
--
Marek Zarychta
