Re: revision not displayed in a2440348eed7
- In reply to: Warner Losh : "Re: revision not displayed in a2440348eed7"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 09 Nov 2023 05:44:51 UTC
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.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 > <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. > 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.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org > <https://FreeBSD.org> > NTP: <cy@nwtime.org> Web: https://nwtime.org > > e^(i*pi)+1=0 > Thank you for your help. -- Marek Zarychta