Re: revision not displayed in a2440348eed7

2023-11-08 Thread Marek Zarychta 

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  
wrote:


On Wed, 8 Nov 2023 15:14:34 +0100
Marek Zarychta  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  wrote:
> >>
> >>> In message
<20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>,
> >>> Tomoaki
> >>> AOKI writes:
>  On Tue, 26 Sep 2023 15:48:50 +0200
>  Marek Zarychta  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 
> >>> FreeBSD UNIX:    Web: https://FreeBSD.org

> >>> NTP:    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 ..." 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

Re: revision not displayed in a2440348eed7

2023-11-08 Thread Warner Losh 
Do you have WITHOUT_REPRODUCEABLE_BUILDS=YES in your src.conf?

Warner

On Wed, Nov 8, 2023, 9:03 PM Cy Schubert  wrote:

> On Wed, 8 Nov 2023 15:14:34 +0100
> Marek Zarychta  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  wrote:
> > >>
> > >>> In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp
> >,
> > >>> Tomoaki
> > >>> AOKI writes:
> >  On Tue, 26 Sep 2023 15:48:50 +0200
> >  Marek Zarychta  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 
> > >>> FreeBSD UNIX: Web: https://FreeBSD.org
> > >>> NTP:   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 ..." 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

Re: revision not displayed in a2440348eed7

2023-11-08 Thread Cy Schubert 
On Wed, 8 Nov 2023 15:14:34 +0100
Marek Zarychta  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  wrote:
> >>  
> >>> In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>,
> >>> Tomoaki
> >>> AOKI writes:  
>  On Tue, 26 Sep 2023 15:48:50 +0200
>  Marek Zarychta  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 
> >>> FreeBSD UNIX:     Web: https://FreeBSD.org
> >>> NTP:       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 ..." 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 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:

Re: revision not displayed in a2440348eed7

2023-11-08 Thread Marek Zarychta 



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  wrote:


In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>,
Tomoaki
AOKI writes:

On Tue, 26 Sep 2023 15:48:50 +0200
Marek Zarychta  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 
FreeBSD UNIX:     Web: https://FreeBSD.org
NTP:       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 ..." 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


--
Marek Zarychta

Re: revision not displayed in a2440348eed7

2023-11-08 Thread Marek Zarychta 



W dniu 27.09.2023 o 01:07, Tomoaki AOKI pisze:

On Tue, 26 Sep 2023 15:19:46 -0700
Cy Schubert  wrote:


In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>,
Tomoaki
AOKI writes:

On Tue, 26 Sep 2023 15:48:50 +0200
Marek Zarychta  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 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   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 ..." 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 ?


--
Marek Zarychta

Re: revision not displayed in a2440348eed7

2023-09-26 Thread Tomoaki AOKI 
On Tue, 26 Sep 2023 15:19:46 -0700
Cy Schubert  wrote:

> In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>, 
> Tomoaki
> AOKI writes:
> > On Tue, 26 Sep 2023 15:48:50 +0200
> > Marek Zarychta  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 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   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.

-- 
Tomoaki AOKI

Re: revision not displayed in a2440348eed7

2023-09-26 Thread Cy Schubert 
In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>, 
Tomoaki
AOKI writes:
> On Tue, 26 Sep 2023 15:48:50 +0200
> Marek Zarychta  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 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0




Re: revision not displayed in a2440348eed7

2023-09-26 Thread Tomoaki AOKI 
On Tue, 26 Sep 2023 15:48:50 +0200
Marek Zarychta  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


-- 
Tomoaki AOKI

Re: revision not displayed in a2440348eed7

2023-09-26 Thread Marek Zarychta 

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

Re: revision not displayed in a2440348eed7

2023-09-26 Thread KIRIYAMA Kazuhiko 
On Tue, 26 Sep 2023 18:18:45 +0900,
Tomoaki AOKI wrote:
> 
> On Tue, 26 Sep 2023 15:29:00 +0900
> KIRIYAMA Kazuhiko  wrote:
> 
> > Hi, Yuri
> > 
> > On Tue, 26 Sep 2023 10:31:34 +0900,
> > Yuri wrote:
> > > 
> > > KIRIYAMA Kazuhiko wrote:
> > > > Hi, list
> > > > 
> > > > I updated to a2440348eed7, but could not display revision:
> > > > 
> > > > admin@tbedfc:~ % uname -a
> > > > FreeBSD tbedfc 15.0-CURRENT FreeBSD 15.0-CURRENT #0: Tue Sep 26 
> > > > 00:15:10 JST 2023 
> > > > root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> > > > admin@tbedfc:~ % 
> > > > 
> > > > Why ???
> > > 
> > > Are you using WITH_REPRODUCIBLE_BUILD?
> > > 
> > 
> > Exact opposite state of affairs:
> > 
> > admin@tbedfc:~ % cat /etc/src.conf
> > WITHOUT_REPRODUCIBLE_BUILD=yes
> > admin@tbedfc:~ % 
> > 
> > ---
> > Kazuhiko Kiriyama
> 
> So next possibility.
> Are you sure that...
> 
>   *There is no "WITH_REPRODUCIBLE_BUILD=no" nor
>"WITH_REPRODUCIBLE_BUILD=false" lines both in /etc/src.conf
>and /etc/make.conf
> 
>   *If you are using any script to automate src builds,
>there are none like above in the `make` command lines in the script.
> 
> As you may alreay know of, but easily forgotton, values set to WITH_foo
> and/or WITHOUT_bar does not have any meaning. Just the variable is set
> or not is checked. I've bitten by something alike before.

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 

---
Kazuhiko Kiriyama

Re: revision not displayed in a2440348eed7

2023-09-26 Thread Tomoaki AOKI 
On Tue, 26 Sep 2023 15:29:00 +0900
KIRIYAMA Kazuhiko  wrote:

> Hi, Yuri
> 
> On Tue, 26 Sep 2023 10:31:34 +0900,
> Yuri wrote:
> > 
> > KIRIYAMA Kazuhiko wrote:
> > > Hi, list
> > > 
> > > I updated to a2440348eed7, but could not display revision:
> > > 
> > > admin@tbedfc:~ % uname -a
> > > FreeBSD tbedfc 15.0-CURRENT FreeBSD 15.0-CURRENT #0: Tue Sep 26 00:15:10 
> > > JST 2023 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> > > admin@tbedfc:~ % 
> > > 
> > > Why ???
> > 
> > Are you using WITH_REPRODUCIBLE_BUILD?
> > 
> 
> Exact opposite state of affairs:
> 
> admin@tbedfc:~ % cat /etc/src.conf
> WITHOUT_REPRODUCIBLE_BUILD=yes
> admin@tbedfc:~ % 
> 
> ---
> Kazuhiko Kiriyama

So next possibility.
Are you sure that...

  *There is no "WITH_REPRODUCIBLE_BUILD=no" nor
   "WITH_REPRODUCIBLE_BUILD=false" lines both in /etc/src.conf
   and /etc/make.conf

  *If you are using any script to automate src builds,
   there are none like above in the `make` command lines in the script.

As you may alreay know of, but easily forgotton, values set to WITH_foo
and/or WITHOUT_bar does not have any meaning. Just the variable is set
or not is checked. I've bitten by something alike before.

-- 
Tomoaki AOKI

Re: revision not displayed in a2440348eed7

2023-09-26 Thread KIRIYAMA Kazuhiko 
Hi, Yuri

On Tue, 26 Sep 2023 10:31:34 +0900,
Yuri wrote:
> 
> KIRIYAMA Kazuhiko wrote:
> > Hi, list
> > 
> > I updated to a2440348eed7, but could not display revision:
> > 
> > admin@tbedfc:~ % uname -a
> > FreeBSD tbedfc 15.0-CURRENT FreeBSD 15.0-CURRENT #0: Tue Sep 26 00:15:10 
> > JST 2023 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> > admin@tbedfc:~ % 
> > 
> > Why ???
> 
> Are you using WITH_REPRODUCIBLE_BUILD?
> 

Exact opposite state of affairs:

admin@tbedfc:~ % cat /etc/src.conf
WITHOUT_REPRODUCIBLE_BUILD=yes
admin@tbedfc:~ % 

---
Kazuhiko Kiriyama

Re: revision not displayed in a2440348eed7

2023-09-25 Thread Yuri 
KIRIYAMA Kazuhiko wrote:
> Hi, list
> 
> I updated to a2440348eed7, but could not display revision:
> 
> admin@tbedfc:~ % uname -a
> FreeBSD tbedfc 15.0-CURRENT FreeBSD 15.0-CURRENT #0: Tue Sep 26 00:15:10 JST 
> 2023 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> admin@tbedfc:~ % 
> 
> Why ???

Are you using WITH_REPRODUCIBLE_BUILD?

revision not displayed in a2440348eed7

2023-09-25 Thread KIRIYAMA Kazuhiko 
Hi, list

I updated to a2440348eed7, but could not display revision:

admin@tbedfc:~ % uname -a
FreeBSD tbedfc 15.0-CURRENT FreeBSD 15.0-CURRENT #0: Tue Sep 26 00:15:10 JST 
2023 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
admin@tbedfc:~ % 

Why ???

Regards

---
Kazuhiko Kiriyama