Re: Files in /etc containing empty VCSId header

2021-06-11 Thread Rodney W. Grimes
> On Thu, Jun 10, 2021 at 03:26:58PM -0700, Kevin Oberman wrote:
> > On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin  wrote:
> > >
> > > > On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
> > > >
> > > > ?On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > > >>> On Tue, 8 Jun 2021 09:41:34 +
> > > >>> Mark Linimon  wrote:
> > > >>>
> > >  On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > > Sometimes it's a real interesting exercise to figure out where
> > > > a
> > > > file on your runtime system comes from in the source world.
> > > >>
> > > >> There is a command for that which does or use to do a pretty
> > > >> decent job of it called whereis(1).
> > > >>
> > > >
> > > > revolution > whereis ntp.conf
> > > > ntp.conf:
> > > > revolution > whereis netif
> > > > netif:
> > >
> > > That line might make it to a shirt one day:
> > >
> > > > revolution > whereis services
> > >
> > > ;)
> > > Michael
> > >
> > Just to clarify for those not willing or able to RTFM, it only works for
> > executables, not conf files or libraries. It reports the location of the
> > executable, the man page and the port location, if it is a port. For those
> > who did RTFM, it is wrong. It claims that it reports on the location of the
> > source, but that is not the case as far as I know. I have never seen it
> > return anything from /usr/src.
> > > whereis cc
> > cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
> > > whereis postfix
> > postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
> > /usr/ports/mail/postfix
> 
> I should probably just lurk, but I believe the command that
> some are looking for is ident(1).  This command is, of course,
> broken by the lost of $FreeBSD$ expansion.

ident provides a bit more detail, but yes, it WAS the solution, and
it would be nice to have that back.  

-- 
Rod Grimes rgri...@freebsd.org



Re: Files in /etc containing empty VCSId header

2021-06-10 Thread Steve Kargl
On Thu, Jun 10, 2021 at 03:26:58PM -0700, Kevin Oberman wrote:
> On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin  wrote:
> >
> > > On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
> > >
> > > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > >>> On Tue, 8 Jun 2021 09:41:34 +
> > >>> Mark Linimon  wrote:
> > >>>
> >  On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > Sometimes it's a real interesting exercise to figure out where
> > > a
> > > file on your runtime system comes from in the source world.
> > >>
> > >> There is a command for that which does or use to do a pretty
> > >> decent job of it called whereis(1).
> > >>
> > >
> > > revolution > whereis ntp.conf
> > > ntp.conf:
> > > revolution > whereis netif
> > > netif:
> >
> > That line might make it to a shirt one day:
> >
> > > revolution > whereis services
> >
> > ;)
> > Michael
> >
> Just to clarify for those not willing or able to RTFM, it only works for
> executables, not conf files or libraries. It reports the location of the
> executable, the man page and the port location, if it is a port. For those
> who did RTFM, it is wrong. It claims that it reports on the location of the
> source, but that is not the case as far as I know. I have never seen it
> return anything from /usr/src.
> > whereis cc
> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
> > whereis postfix
> postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
> /usr/ports/mail/postfix

I should probably just lurk, but I believe the command that
some are looking for is ident(1).  This command is, of course,
broken by the lost of $FreeBSD$ expansion.

-- 
Steve



Re: Files in /etc containing empty VCSId header

2021-06-10 Thread Michael Gmelin


> On 11. Jun 2021, at 00:42, Cameron Katri via freebsd-current 
>  wrote:
> 
> On 6/10/21 6:26 PM, Kevin Oberman wrote:
>> I have never seen it return anything from /usr/src.
> 
> It seems to return stuff from /usr/src for me
> > whereis cc
> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz 
> /usr/src/contrib/netbsd-tests/usr.bin/cc
> 
> Although I question the validity of that response. But other times it works 
> fine.
> 

Again, (among other ways) it does so using locate, see 
https://lists.freebsd.org/archives/freebsd-current/2021-June/000193.html

-m


> > whereis whereis
> whereis: /usr/bin/whereis /usr/share/man/man1/whereis.1.gz 
> /usr/src/usr.bin/whereis
> 
>>> whereis cc
>> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
>>> whereis postfix
>> postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
>> /usr/ports/mail/postfix
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> - Cameron Katri




Re: Files in /etc containing empty VCSId header

2021-06-10 Thread Cameron Katri via freebsd-current

On 6/10/21 6:26 PM, Kevin Oberman wrote:

I have never seen it return anything from /usr/src.


It seems to return stuff from /usr/src for me
> whereis cc
cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz 
/usr/src/contrib/netbsd-tests/usr.bin/cc


Although I question the validity of that response. But other times it 
works fine.


> whereis whereis
whereis: /usr/bin/whereis /usr/share/man/man1/whereis.1.gz 
/usr/src/usr.bin/whereis



whereis cc

cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz

whereis postfix

postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
/usr/ports/mail/postfix
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683



- Cameron Katri



Re: Files in /etc containing empty VCSId header

2021-06-10 Thread Michael Gmelin



> On 11. Jun 2021, at 00:28, Kevin Oberman  wrote:
> 
> On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin  wrote:
> 
>> 
>> 
 On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
>>> 
>>> On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> On Tue, 8 Jun 2021 09:41:34 +
> Mark Linimon  wrote:
> 
>> On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
>>> Sometimes it's a real interesting exercise to figure out where
>>> a
>>> file on your runtime system comes from in the source world.
 
 There is a command for that which does or use to do a pretty
 decent job of it called whereis(1).
 
>>> 
>>> revolution > whereis ntp.conf
>>> ntp.conf:
>>> revolution > whereis netif
>>> netif:
>> 
>> That line might make it to a shirt one day:
>> 
>>> revolution > whereis services
>> 
>> ;)
>> Michael
>> 
> Just to clarify for those not willing or able to RTFM, it only works for
> executables, not conf files or libraries. It reports the location of the
> executable, the man page and the port location, if it is a port. For those
> who did RTFM, it is wrong. It claims that it reports on the location of the
> source, but that is not the case as far as I know. I have never seen it
> return anything from /usr/src.

I have, just earlier today. Like I wrote somewhere else in this thread, it does 
so by using locate (it’s debatable how useful this really is though).

-m


>> whereis cc
> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
>> whereis postfix
> postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
> /usr/ports/mail/postfix
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683




Re: Files in /etc containing empty VCSId header

2021-06-10 Thread Kevin Oberman
On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin  wrote:

>
>
> > On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
> >
> > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> >>> On Tue, 8 Jun 2021 09:41:34 +
> >>> Mark Linimon  wrote:
> >>>
>  On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > Sometimes it's a real interesting exercise to figure out where
> > a
> > file on your runtime system comes from in the source world.
> >>
> >> There is a command for that which does or use to do a pretty
> >> decent job of it called whereis(1).
> >>
> >
> > revolution > whereis ntp.conf
> > ntp.conf:
> > revolution > whereis netif
> > netif:
>
> That line might make it to a shirt one day:
>
> > revolution > whereis services
>
> ;)
> Michael
>
Just to clarify for those not willing or able to RTFM, it only works for
executables, not conf files or libraries. It reports the location of the
executable, the man page and the port location, if it is a port. For those
who did RTFM, it is wrong. It claims that it reports on the location of the
source, but that is not the case as far as I know. I have never seen it
return anything from /usr/src.
> whereis cc
cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
> whereis postfix
postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
/usr/ports/mail/postfix
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


Re: Files in /etc containing empty VCSId header

2021-06-09 Thread Michael Gmelin



On Wed, 09 Jun 2021 08:23:20 -0600
Ian Lepore  wrote:

> On Wed, 2021-06-09 at 18:54 +1000, Peter Jeremy via freebsd-current
> wrote:
> > On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:  
> > > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:  
> > > > There is a command for that which does or use to do a pretty
> > > > decent job of it called whereis(1).  
> > 
> > Thanks.  That looks useful.
> >   
> > > revolution > whereis ntp.conf
> > > ntp.conf:
> > > revolution > whereis netif
> > > netif:
> > > revolution > whereis services
> > > services:
> > > 
> > > So how does that help me locate the origin of these files in the
> > > source
> > > tree?  
> > 
> > It works for me™:
> > server% whereis ntp.conf
> > ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
> > server% whereis netif   
> > netif: /usr/src/libexec/rc/rc.d/netif
> > server% whereis services
> > services: /usr/src/contrib/unbound/services
> > 
> > Is your source tree somewhere other than /usr/src?
> >   
> 
> My /usr/src is a symlink to the actual source tree on a different
> filesystem (but it is the source tree the running system was built
> from).  It seems odd that that would make whereis(1) not work.
> 

whereis(1) falls back to using "locate" if it can't find the sources
directly, so e.g., in case of `whereis -s ls', it will get through the
results of `locate '*'/ls` and see if they match "^/usr/src" (or
whatever you gave as source dir using -S).

Therefore if

  locate '*'/ntp.conf | grep "^/usr/src"

gives you a result, then `whereis -s ntp.conf' will too.

See also
https://cgit.freebsd.org/src/tree/usr.bin/whereis/whereis.c#n607

Michael

(re-sent, as the previous mail bounced from the list)

-- 
Michael Gmelin



Re: Files in /etc containing empty VCSId header

2021-06-09 Thread Ian Lepore
On Wed, 2021-06-09 at 18:54 +1000, Peter Jeremy via freebsd-current
wrote:
> On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:
> > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > > There is a command for that which does or use to do a pretty
> > > decent job of it called whereis(1).
> 
> Thanks.  That looks useful.
> 
> > revolution > whereis ntp.conf
> > ntp.conf:
> > revolution > whereis netif
> > netif:
> > revolution > whereis services
> > services:
> > 
> > So how does that help me locate the origin of these files in the
> > source
> > tree?
> 
> It works for me™:
> server% whereis ntp.conf
> ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
> server% whereis netif   
> netif: /usr/src/libexec/rc/rc.d/netif
> server% whereis services
> services: /usr/src/contrib/unbound/services
> 
> Is your source tree somewhere other than /usr/src?
> 

My /usr/src is a symlink to the actual source tree on a different
filesystem (but it is the source tree the running system was built
from).  It seems odd that that would make whereis(1) not work.

-- Ian




Re: Files in /etc containing empty VCSId header

2021-06-09 Thread Rodney W. Grimes
> On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:
> >On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> >> There is a command for that which does or use to do a pretty
> >> decent job of it called whereis(1).
> 
> Thanks.  That looks useful.
> 
> >revolution > whereis ntp.conf
> >ntp.conf:
> >revolution > whereis netif
> >netif:
> >revolution > whereis services
> >services:
> >
> >So how does that help me locate the origin of these files in the source
> >tree?
> 
> It works for me?:
> server% whereis ntp.conf
> ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
> server% whereis netif   
> netif: /usr/src/libexec/rc/rc.d/netif
> server% whereis services
> services: /usr/src/contrib/unbound/services
> 
> Is your source tree somewhere other than /usr/src?

And if source is not located at /usr/src, /usr/ports there is
the -S option.

> Peter Jeremy
-- 
Rod Grimes rgri...@freebsd.org



Re: Files in /etc containing empty VCSId header

2021-06-09 Thread Michael Gmelin



> On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
> 
> On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
>>> On Tue, 8 Jun 2021 09:41:34 +
>>> Mark Linimon  wrote:
>>> 
 On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> Sometimes it's a real interesting exercise to figure out where
> a
> file on your runtime system comes from in the source world.  
>> 
>> There is a command for that which does or use to do a pretty
>> decent job of it called whereis(1).
>> 
> 
> revolution > whereis ntp.conf
> ntp.conf:
> revolution > whereis netif
> netif:

That line might make it to a shirt one day:

> revolution > whereis services

;)
Michael





Re: Files in /etc containing empty VCSId header

2021-06-09 Thread Peter Jeremy via freebsd-current
On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:
>On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
>> There is a command for that which does or use to do a pretty
>> decent job of it called whereis(1).

Thanks.  That looks useful.

>revolution > whereis ntp.conf
>ntp.conf:
>revolution > whereis netif
>netif:
>revolution > whereis services
>services:
>
>So how does that help me locate the origin of these files in the source
>tree?

It works for me™:
server% whereis ntp.conf
ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
server% whereis netif   
netif: /usr/src/libexec/rc/rc.d/netif
server% whereis services
services: /usr/src/contrib/unbound/services

Is your source tree somewhere other than /usr/src?

-- 
Peter Jeremy


signature.asc
Description: PGP signature


Re: Files in /etc containing empty VCSId header

2021-06-08 Thread Ian Lepore
On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > On Tue, 8 Jun 2021 09:41:34 +
> > Mark Linimon  wrote:
> > 
> > > On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > > Sometimes it's a real interesting exercise to figure out where
> > > > a
> > > > file on your runtime system comes from in the source world.  
> 
> There is a command for that which does or use to do a pretty
> decent job of it called whereis(1).
> 

revolution > whereis ntp.conf
ntp.conf:
revolution > whereis netif
netif:
revolution > whereis services
services:

So how does that help me locate the origin of these files in the source
tree?

-- Ian

> > > 
> > > A tangential problem I trip over is "what is on this SD card?"
> > > 
> > > It generally takes me 5-10 minutes to remember:
> > > 
> > >   strings //boot/kernel/kernel | tail
> > > 
> > > AFIAK it's the only way to be sure; nothing in //* seems
> > > to have that data.
> > > 
> > > (Yes, in theory they all live in their own little box each of
> > > which is labeled but things happen ...)
> > > 
> > 
> > I use locate for this kind of search, e.g.
> > 
> > locate netoptions
> > /etc/rc.d/netoptions
> > /usr/src/libexec/rc/rc.d/netoptions
> > 
> > -- 
> > Gary Jennejohn
> > 
> > 
> 
> 




Re: Files in /etc containing empty VCSId header

2021-06-08 Thread Rodney W. Grimes
> On Tue, 8 Jun 2021 09:41:34 +
> Mark Linimon  wrote:
> 
> > On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > Sometimes it's a real interesting exercise to figure out where a
> > > file on your runtime system comes from in the source world.  

There is a command for that which does or use to do a pretty
decent job of it called whereis(1).


> > 
> > A tangential problem I trip over is "what is on this SD card?"
> > 
> > It generally takes me 5-10 minutes to remember:
> > 
> >   strings //boot/kernel/kernel | tail
> > 
> > AFIAK it's the only way to be sure; nothing in //* seems
> > to have that data.
> > 
> > (Yes, in theory they all live in their own little box each of
> > which is labeled but things happen ...)
> > 
> 
> I use locate for this kind of search, e.g.
> 
> locate netoptions
> /etc/rc.d/netoptions
> /usr/src/libexec/rc/rc.d/netoptions
> 
> -- 
> Gary Jennejohn
> 
> 

-- 
Rod Grimes rgri...@freebsd.org



Re: Files in /etc containing empty VCSId header

2021-06-08 Thread John Baldwin

On 6/7/21 12:58 PM, Ian Lepore wrote:

On Mon, 2021-06-07 at 13:53 -0600, Warner Losh wrote:

On Mon, Jun 7, 2021 at 12:26 PM John Baldwin  wrote:


On 5/20/21 9:37 AM, Michael Gmelin wrote:

Hi,

After a binary update using freebsd-update, all files in /etc
contain
"empty" VCS Id headers, e.g.,

  $ head  /etc/nsswitch.conf
  #
  # nsswitch.conf(5) - name service switch configuration file
  # $FreeBSD$
  #
  group: compat
  group_compat: nis
  hosts: files dns
  netgroup: compat
  networks: files
  passwd: compat

After migrating to git, I would've expected those to contain
something
else or disappear completely. Is this expected and are there any
plans
to remove them completely?


I believe we might eventually remove them in the future, but doing
so
right now would introduce a lot of churn and the conversion to git
had enough other churn going on.



We'd planned on not removing things that might be merged to stable/12
since
those releases (12.3 only I think) will be built out of svn. We'll
likely
start to
remove things more widely as the stable/12 branch reaches EOL and
after.

Warner


It would be really nice if, instead of just deleting the $FreeBSD$
markers, they could be replaced with the path/filename of the file in
the source tree.  Sometimes it's a real interesting exercise to figure
out where a file on your runtime system comes from in the source world.
All the source tree layout changes that happened for packaged-base
makes it even more interesting.


My hope is that we un-break src/etc. :(  A few folks have looked at doing
that (notably Kyle).

--
John Baldwin



Re: Files in /etc containing empty VCSId header

2021-06-08 Thread Ian Lepore
On Tue, 2021-06-08 at 13:47 +0200, Gary Jennejohn wrote:
> On Tue, 8 Jun 2021 09:41:34 +
> Mark Linimon  wrote:
> 
> > On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > Sometimes it's a real interesting exercise to figure out where a
> > > file on your runtime system comes from in the source world.  
> > 
> > A tangential problem I trip over is "what is on this SD card?"
> > 
> > It generally takes me 5-10 minutes to remember:
> > 
> >   strings //boot/kernel/kernel | tail
> > 
> > AFIAK it's the only way to be sure; nothing in //* seems
> > to have that data.
> > 
> > (Yes, in theory they all live in their own little box each of
> > which is labeled but things happen ...)
> > 
> 
> I use locate for this kind of search, e.g.
> 
> locate netoptions
> /etc/rc.d/netoptions
> /usr/src/libexec/rc/rc.d/netoptions
> 

Not a useful technique on my machine:

revolution > locate netoptions | wc -l
 192

I have dozens of build chroots for various products for $work.

-- Ian





Re: Files in /etc containing empty VCSId header

2021-06-08 Thread Gary Jennejohn
On Tue, 8 Jun 2021 09:41:34 +
Mark Linimon  wrote:

> On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > Sometimes it's a real interesting exercise to figure out where a
> > file on your runtime system comes from in the source world.  
> 
> A tangential problem I trip over is "what is on this SD card?"
> 
> It generally takes me 5-10 minutes to remember:
> 
>   strings //boot/kernel/kernel | tail
> 
> AFIAK it's the only way to be sure; nothing in //* seems
> to have that data.
> 
> (Yes, in theory they all live in their own little box each of
> which is labeled but things happen ...)
> 

I use locate for this kind of search, e.g.

locate netoptions
/etc/rc.d/netoptions
/usr/src/libexec/rc/rc.d/netoptions

-- 
Gary Jennejohn



Re: Files in /etc containing empty VCSId header

2021-06-08 Thread Mark Linimon
On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> Sometimes it's a real interesting exercise to figure out where a
> file on your runtime system comes from in the source world.

A tangential problem I trip over is "what is on this SD card?"

It generally takes me 5-10 minutes to remember:

  strings //boot/kernel/kernel | tail

AFIAK it's the only way to be sure; nothing in //* seems
to have that data.

(Yes, in theory they all live in their own little box each of
which is labeled but things happen ...)

mcl



Re: Files in /etc containing empty VCSId header

2021-06-07 Thread Ian Lepore
On Mon, 2021-06-07 at 13:53 -0600, Warner Losh wrote:
> On Mon, Jun 7, 2021 at 12:26 PM John Baldwin  wrote:
> 
> > On 5/20/21 9:37 AM, Michael Gmelin wrote:
> > > Hi,
> > > 
> > > After a binary update using freebsd-update, all files in /etc
> > > contain
> > > "empty" VCS Id headers, e.g.,
> > > 
> > >  $ head  /etc/nsswitch.conf
> > >  #
> > >  # nsswitch.conf(5) - name service switch configuration file
> > >  # $FreeBSD$
> > >  #
> > >  group: compat
> > >  group_compat: nis
> > >  hosts: files dns
> > >  netgroup: compat
> > >  networks: files
> > >  passwd: compat
> > > 
> > > After migrating to git, I would've expected those to contain
> > > something
> > > else or disappear completely. Is this expected and are there any
> > > plans
> > > to remove them completely?
> > 
> > I believe we might eventually remove them in the future, but doing
> > so
> > right now would introduce a lot of churn and the conversion to git
> > had enough other churn going on.
> > 
> 
> We'd planned on not removing things that might be merged to stable/12
> since
> those releases (12.3 only I think) will be built out of svn. We'll
> likely
> start to
> remove things more widely as the stable/12 branch reaches EOL and
> after.
> 
> Warner

It would be really nice if, instead of just deleting the $FreeBSD$
markers, they could be replaced with the path/filename of the file in
the source tree.  Sometimes it's a real interesting exercise to figure
out where a file on your runtime system comes from in the source world.
All the source tree layout changes that happened for packaged-base
makes it even more interesting.

-- Ian





Re: Files in /etc containing empty VCSId header

2021-06-07 Thread Warner Losh
On Mon, Jun 7, 2021 at 12:26 PM John Baldwin  wrote:

> On 5/20/21 9:37 AM, Michael Gmelin wrote:
> > Hi,
> >
> > After a binary update using freebsd-update, all files in /etc contain
> > "empty" VCS Id headers, e.g.,
> >
> >  $ head  /etc/nsswitch.conf
> >  #
> >  # nsswitch.conf(5) - name service switch configuration file
> >  # $FreeBSD$
> >  #
> >  group: compat
> >  group_compat: nis
> >  hosts: files dns
> >  netgroup: compat
> >  networks: files
> >  passwd: compat
> >
> > After migrating to git, I would've expected those to contain something
> > else or disappear completely. Is this expected and are there any plans
> > to remove them completely?
>
> I believe we might eventually remove them in the future, but doing so
> right now would introduce a lot of churn and the conversion to git
> had enough other churn going on.
>

We'd planned on not removing things that might be merged to stable/12 since
those releases (12.3 only I think) will be built out of svn. We'll likely
start to
remove things more widely as the stable/12 branch reaches EOL and after.

Warner


Re: Files in /etc containing empty VCSId header

2021-06-07 Thread John Baldwin

On 5/20/21 9:37 AM, Michael Gmelin wrote:

Hi,

After a binary update using freebsd-update, all files in /etc contain
"empty" VCS Id headers, e.g.,

 $ head  /etc/nsswitch.conf
 #
 # nsswitch.conf(5) - name service switch configuration file
 # $FreeBSD$
 #
 group: compat
 group_compat: nis
 hosts: files dns
 netgroup: compat
 networks: files
 passwd: compat

After migrating to git, I would've expected those to contain something
else or disappear completely. Is this expected and are there any plans
to remove them completely?


I believe we might eventually remove them in the future, but doing so
right now would introduce a lot of churn and the conversion to git
had enough other churn going on.

--
John Baldwin