Re: weekly locate error Was: September 2024 stabilization week

[Jamie Landeg-Jones]

Kyle Evans  wrote:

> This is the problem I have with mailing lists; 2/3 responses didn't go 
> back and read the critical bit of context to my stance (but at least you 
> still included it in your quote, the other one trimmed it entirely):

I quoted the part I was referring to. I trimmed the rest, which USED
to be what people did before this list started accepting all sorts of
untrimmed, badly quoted, top posting "/aol" mess.

The bit I trimmed didn't clarify your confusing message the way you
apparently think it did. - Rodneys reply is further proof of that.

Re: weekly locate error Was: September 2024 stabilization week

[Jamie Landeg-Jones]

Kyle Evans  wrote:

> Yes, my proposal is that it stops doing that and we teach updatedb to 
> handle the priv-dropping instead, so that you get the same behavior no 
> matter how you execute it.

Ahhh OK, I get you now. sorry, I musunderstood, I thought you meant the
current "periodic" method runs the filesystem walk as root, but when you
said "if someone really wants to complain that they can't document all
filenames on the system.", i guess you were referring to those who
may call /usr/libexec/locate.updatedb directly as root.

For what it's worth, in addition to the periodic job, I do actually run
a less frequent privileged direct run of
/usr/libexec/locate.updatedb (with the output in a suitably locked
directory!). This proposed change wouldn't be an issue to me, but as a
data point, there may be quite a few others who do so too.

Cheers, Jamie

Re: weekly locate error Was: September 2024 stabilization week

[Jamie Landeg-Jones]

Kyle Evans  wrote:

> It might be that the better long-term approach is to teach updatedb.sh 
> how to drop privileges and push that out of the periodic script to avoid 
> surprises like this from the different execution environments.  This 
> /feels/ like the kind of thing we could take an opinionated stance on, 
> maybe providing an escape hatch of some sort if someone really wants to 
> complain that they can't document all filenames on the system.

This is how it already works. It calls locate.updatedb as "nobody", so
only files readable by "nobody" are indexed:

echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3

termcap.db unused?

[Jamie Landeg-Jones]

I was looking at a ktrace dump file recently (/bin/ls) and noticed that
during initialisation, it attempted to read /etc/termcap.db - as that
failed, it then read the text version pointed to by /etc/termcap

Adding a link: /etc/termcap.db -> /usr/share/misc/termcap.db

caused subsequent runs to use the termcap.db version.

Is there any reason why /etc/termcap is linked, whilst /etc/termcap.db
isn't? And if so, what's the purpose of /usr/share/misc/termcap.db ?

Cheers, Jamie

Re: Reason why "nocache" option is not displayed in "mount"?

[Jamie Landeg-Jones]

Jamie Landeg-Jones  wrote:

> Good catch. I also notice that "hidden" is not shown either.

Sorry, I meant mount option "ignore" not "hidden".

Re: Reason why "nocache" option is not displayed in "mount"?

[Jamie Landeg-Jones]

Alexander Leidinger  wrote:

> Hi,
>
> what is the reason why "nocache" is not displayed in the output of 
> "mount" for nullfs options?

Good catch. I also notice that "hidden" is not shown either.

I guess that as for some time, "nocache" was a "secret" option, no-one
update "mount" to display it?

Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt.

[Jamie Landeg-Jones]

Mario Marietto  wrote:

> After a lot of work I've been able to install FreeBSD 12.04 for armv7 on my
> ARM Chromebook. Now I would like to install some ports. This is what
> happens when I try to get a fresh ports tree :
> files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
> not found -- snapshot corrupt.

I'm not sure why the file isn't there - maybe because 12.X is EOL or portsnap
is deprecated?

Still, the solution is easy:

Download the ports tree snapshot as a tar from https://cgit.freebsd.org/ports/

Choose a tag, and a format. I suggest 12.4-eol so just fetch

https://cgit.freebsd.org/ports/snapshot/ports-12-eol.tar.gz

rm -r /usr/ports
then untar the downloaded tar file into place.

Cheers, Jamie

Re: noatime on ufs2

[Jamie Landeg-Jones]

Olivier Certner  wrote:

> I've mentioned your answer in another response to Lyndon Nerenberg when 
> developing a more general argument that 'atime' is generally flawed for these 
> kinds of use cases (finding the last use, finding files to backup, etc.).  
> It's true that the ability to deactivate 'atime''s implicit updates 
> per-process would cater to more use cases, and it's an interesting idea.  
> Essentially, though, you can't guarantee that some applications, or simply 
> administrators typing commands at the shell, are not going to throw away your 
> precious access times, so can't rely (in a strong sense) on them.

Thanks for the heads-up - I've only now had a chance to catch up with the
thread.

You are of course right - atime can be affected by so many different things
that it can't be relied upon. I just thought a per-process method would be
a good compromise to avoid blanket atime changes across the system - both
for atime usefulness, and I/O, but as you say, as it's unreliable to rely
on anyway, this solution may be making things worse by giving a false sense
of reliability.

And to further bolster your point, whilst I have wished for more granuality
with respect to controlling atime updates, for years I've run everything
with noatime.. Even when I thought it was nice to keep atime relatively
accurate, I soon realised that I simply never used it anyway!

> Sure for backups and snapshots.  I agree you'd better have backup perimeters 
> coinciding with file systems partitions and use snapshots to get the 
> smoothest possible experience.  But snapshots alone do not guarantee the 
> "correctness" of a backup (the ability to restart smoothly from it).

Yeah, it's more like a snapshot at the time of a power failure, but of
course, it's better than running on a live filesystem because a file may
be missed completely if moved whilst the backup is running.

But short of shutting everything down prior to taking the snapshot (I
remember at last job some very old machines without snapshotting or
decent db journalling capabilities being taken down for hours every
night, so that the whole backup ran in a minimal boot environment!),
I don't know of a cleaner solution... (though I'm sure some exist..
after all, live migrations between hosts are a thing these days.. I guess
I need to do some homework on the matter! :-) )

Thanks again, Jamie

Re: noatime on ufs2

[Jamie Landeg-Jones]

Olivier Certner  wrote:

> Both the examples above prompt some straight objections on the current 
> usefulness of "atime".  First, unless you've disabled building the locate 
> database in cron (enabled by default, on a weekly basis), access times on 
> directories lose most of their usefulness.  Second, if using an IDS, I'm 
> afraid it's just game over.  And even if you think you are not, 
> '460.pkg-checksum' at least is readily there to much complicate, or even 
> prevent you from, getting package usage information this way (it is enabled 
> by default, and on a daily basis).

I've often wished there was the ability to set a process to "noatime" - where
all accesses to the filesytem by the process and its children don't alter
atime. It would be handy for those cases you describe above, such as backups
and locate, but these days, where it matters, and is suitable, I instead
create a filesystem snapshot, and run the process on that instead. (which is
how "live" backups should be done anyway!)

Cheers, Jamie

Re: git repo port issues?

[Jamie Landeg-Jones]

Warner Losh  wrote:

> See sys/conf/newvers.sh for the 'n' value we use in uname strings.  It's a
> linear count of commits on the first-parent branch back to the start of the
> repo.
>
> Also, the dates usualy are first order correct and i use them for the stats
> i run. Though I've also just dropped tags on the first commit of each year
> too...

Ahhh brilliant, thanks! I didn't know about that. That looks like just what
I'm after.

Is it safe to assume that all commits in a cloned and then fetched/pulled
repo will have the commits in the same order as the parent?

Also, are "null commits", where there is a commit but no actual files commited
(not sure what those are for!) counted too? 

(example: 
https://cgit.dyslexicfish.net/src/current/commit/?id=cb4ff25c8a40e6811f48f6ad03a0bf882404e9ac
 )

I'll never understand the nuances of operating day to day with git like you
guys, so I'm grateful for the help and patience you have shown, especially
when I come out with an idea that is basically dumb.

Cheers, Jamie

Re: git repo port issues?

[Jamie Landeg-Jones]

Tomoaki AOKI  wrote:

>
> Or create database (key-value store would be sufficient) storing commit
> order (like r* of svn) and commit hash.
> I'm still not certain whether commit order or commit hash should be the
> "key". Possibly store hash as the key fisrt and store assigned MONOTONIC
> order as value, then, add the just-stored order as key and hash as
> value in another database would be neeed. If the database can contain 2
> value for 1 key, it would be suitable for you to store the assigned
> time in UTC as "when it is committed to FreeBSD master repo".

I do miss the incrementing "r" value - it's a nice immediate way to
tell which update is more recent. Actually, to me, that is more important
than the date - I've attempted to base my changes on the date due to the
absense of such a useful field.

Actually, I think I may implement such a thing on my local cgit repo.

https://cgit.dyslexicfish.net/ports/latest/tree/
https://cgit.dyslexicfish.net/src/current/tree/

Cheers, Jamie

Re: git repo port issues?

[Jamie Landeg-Jones]

Brooks Davis  wrote:

> The dates are just strings in the commits.  There's no central commit
> queue to rewrite the commits with new dates.  The project could someday
> implment such a thing, but we deemed anything like that out of scope for
> the first phase of the migration.
>
> I do fine it quite annoying that the project has not implemented a check
> to monotonize CommitDate.  Once upon a time clock drift between commit
> hosts might have been a concern, but hosts that can't stay in sync have
> no business committing directly.  (I'd even be in favor of requiring the same
> for Date, effectively requiring rebase --ignore-date before each push,
> but there's much less concensus for that.)
>
> > Anyway, I think some sanity checking would be good. If nothing else, this
> > sort of thing breaks "git log":
> > 
> > # git log --since=2023-02-02 --format="%cd %s %cn - %cd"
> > Wed Jan 3 17:08:58 2024 -0500 editors/cudatext: Update to 1.206.5 Jose 
> > Alonso Cardenas Marquez - Wed Jan 3 17:08:58 2024 -0500
> > Thu Jan 4 06:59:31 2024 +0900 net/qrcp: update to 0.11.1 Hiroki Tagato - 
> > Thu Jan 4 06:59:31 2024 +0900
> > Wed Jan 3 16:54:47 2024 -0500 lang/fpc-devel: Update to 3.3.1.20240103 Jose 
> > Alonso Cardenas Marquez - Wed Jan 3 16:54:47 2024 -0500
> > Wed Jan 3 16:54:46 2024 -0500 lang/fpc: fix stage-qa fails Jose Alonso 
> > Cardenas Marquez - Wed Jan 3 16:54:46 2024 -0500
> > Wed Jan 3 16:53:33 2024 -0500 sysutils/acpi_call: Check for errors from 
> > copyout() Mark Johnston - Wed Jan 3 16:53:33 2024 -0500
> > Wed Jan 3 15:37:13 2024 -0600 math/octave-forge-statistics-resampling: 
> > Update to 5.5.3. Stephen Montgomery-Smith - Wed Jan 3 15:37:13 2024 -0600
> > Wed Jan 3 23:00:58 2024 +0300 math/z3: Unbreak on i386 Gleb Popov - Wed Jan 
> > 3 23:00:58 2024 +0300
> > Wed Jan 3 20:52:14 2024 +0100 devel/mongo-c-driver: Use USE_GITHUB helper 
> > and always use (lib)utf8proc from ports Daniel Engberg - Wed Jan 3 20:52:14 
> > 2024 +0100
> > Wed Jan 3 22:26:11 2024 +0300 lang/ghc: Unbreak GHC 9.2 on AArch64, refresh 
> > bootstraps. Gleb Popov - Wed Jan 3 22:26:11 2024 +0300
> > 
> > Note how I specified February 2023, yet the output stops as soon as it
> > reaches the recent entry with the rogue date.
> > 
> > That makes the results corrupt, which may affect other things along the 
> > line.
> > 
> > I notice the front page of Freshports doesn't even show the offending 
> > entries
> > in the list of recent commits, for example, whilst the individual port pages
> > shows the commits in the "wrong" order (i.e. the commits are displayed in
> > the perceived chronalogical order)
>
> Any general git tool or workflow that depends on dates being ordered 
> can not work completely reliably.  git log has the --since-as-filter to
> try to work around this, but even that is questionable since the dates
> are just a polite fiction without some sort of server-side enforcement.
>
> It's more stable and reliable to do something commit based like
>
> git log ..HEAD
>
> -- Brooks
>
> From freebsd-current+bounces-5248-freebsd-lists=dyslexicfish@freebsd.org 
> Wed Jan  3 23:26:23 2024
> Date: Wed, 3 Jan 2024 23:26:01 +
> From: Brooks Davis 
> To: Jamie Landeg-Jones 
> Cc: bro...@freebsd.org, d...@freebsd.org, y...@freebsd.org,
> freebsd-current@FreeBSD.org
> Subject: Re: git repo port issues?
> X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 
> (donotpassgo.dyslexicfish.net [209.250.224.51]); Wed, 03 Jan 2024 23:26:23 
> + (GMT)
>
> On Wed, Jan 03, 2024 at 10:52:04PM +, Jamie Landeg-Jones wrote:
> > Brooks Davis  wrote:

> The dates are just strings in the commits.  There's no central commit
> queue to rewrite the commits with new dates.  The project could someday
> implment such a thing, but we deemed anything like that out of scope for
> the first phase of the migration.

Ok, thanks for the clarification.

> I do fine it quite annoying that the project has not implemented a check
> to monotonize CommitDate.  Once upon a time clock drift between commit
> hosts might have been a concern, but hosts that can't stay in sync have
> no business committing directly.  (I'd even be in favor of requiring the same
> for Date, effectively requiring rebase --ignore-date before each push,
> but there's much less concensus for that.)

 [ ... ]

> Any general git tool or workflow that depends on dates being ordered 
> can not work completely reliably.  git log has the --since-as-filter to
> try to work around this, but even that is questionable sinc

Re: git repo port issues?

[Jamie Landeg-Jones]

Brooks Davis  wrote:

> Nothing about dates is centralized in git, but some server side checks
> could be implemented on CommitDate.  IMO we should require that
> CommitDate be >= the previous one and less than "now".

Ah, I realised Linux doesn't like centralised dates, because of the
decentralisation of git, but I thought that as we grabbed from a
master repo, those commit dates would be in sync.

Anyway, I think some sanity checking would be good. If nothing else, this
sort of thing breaks "git log":

# git log --since=2023-02-02 --format="%cd %s %cn - %cd"
Wed Jan 3 17:08:58 2024 -0500 editors/cudatext: Update to 1.206.5 Jose Alonso 
Cardenas Marquez - Wed Jan 3 17:08:58 2024 -0500
Thu Jan 4 06:59:31 2024 +0900 net/qrcp: update to 0.11.1 Hiroki Tagato - Thu 
Jan 4 06:59:31 2024 +0900
Wed Jan 3 16:54:47 2024 -0500 lang/fpc-devel: Update to 3.3.1.20240103 Jose 
Alonso Cardenas Marquez - Wed Jan 3 16:54:47 2024 -0500
Wed Jan 3 16:54:46 2024 -0500 lang/fpc: fix stage-qa fails Jose Alonso Cardenas 
Marquez - Wed Jan 3 16:54:46 2024 -0500
Wed Jan 3 16:53:33 2024 -0500 sysutils/acpi_call: Check for errors from 
copyout() Mark Johnston - Wed Jan 3 16:53:33 2024 -0500
Wed Jan 3 15:37:13 2024 -0600 math/octave-forge-statistics-resampling: Update 
to 5.5.3. Stephen Montgomery-Smith - Wed Jan 3 15:37:13 2024 -0600
Wed Jan 3 23:00:58 2024 +0300 math/z3: Unbreak on i386 Gleb Popov - Wed Jan 3 
23:00:58 2024 +0300
Wed Jan 3 20:52:14 2024 +0100 devel/mongo-c-driver: Use USE_GITHUB helper and 
always use (lib)utf8proc from ports Daniel Engberg - Wed Jan 3 20:52:14 2024 
+0100
Wed Jan 3 22:26:11 2024 +0300 lang/ghc: Unbreak GHC 9.2 on AArch64, refresh 
bootstraps. Gleb Popov - Wed Jan 3 22:26:11 2024 +0300

Note how I specified February 2023, yet the output stops as soon as it
reaches the recent entry with the rogue date.

That makes the results corrupt, which may affect other things along the line.

I notice the front page of Freshports doesn't even show the offending entries
in the list of recent commits, for example, whilst the individual port pages
shows the commits in the "wrong" order (i.e. the commits are displayed in
the perceived chronalogical order)

https://www.freshports.org/misc/py-laspy
https://www.freshports.org/graphics/filament

Re: git repo ports issues?

[Jamie Landeg-Jones]

Yuri  wrote:

> Hi Jamie,
>
>
> This was a faulty script where 2023 wasn't changed to 2024.
>
> Thanks for the notice.

Ahh, ok, I did think it was probably a bit more than coincidence that it
was exactly 1 year to the day!

Cheers for the quick reply, Jamie

git repo port issues?

[Jamie Landeg-Jones]

https://cgit.freebsd.org/ports/

The latest update to "main" is :

authorYuri Victorovich   2023-01-03 14:49:38 +
committer Yuri Victorovich   2023-01-03 14:49:38 +

I.e. A year old. Reading the commit message, it does appear to be a wrong
clock, rather than an old message, but whilst the author date is local to
the author, I thought the commit date was centralised.

If nothing else, this does seem to bugger up "commits since "
within git itself.

Cheers, Jamie

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Jamie Landeg-Jones]

Glen Barber  wrote:

> No.  It merely suggests the release is not officially official yet.

Ok. Thanks for the clarification.

Jamie.

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Jamie Landeg-Jones]

> Ok.  I do not know what exactly is your point, but releases are never
> official until there is a PGP-signed email sent.  The email is intended
> for the general public of consumers of official releases, not "yeah,
> but"s.

Foe a recent new build, I just went to the ftp site to grab the latest rc,
only to see 14.0-release there, so I grabbed and installed that, many
hours before your original mail went out.

No biggy, I generally track stable, but does this mean we can't rely
on the download sites without checking out the lists first? It's not
like I was plaing sneaky by doing "guess the URL" or anything like that.

Jamie

Re: Freebsd 14+ -- tcsh incompatible with terminfo

[Jamie Landeg-Jones]

Steffen Nurpmeso  wrote:

> You know the entire thread is moot as i think bapt@ has thrown
> away the BSD termcap years ago, if i recall correctly (i think
> i spoke up by then).
> I only answered because of the "great it is gone" thing.

Maybe I should have rephrased that as "it's great that we only
now have one to deal with, that is the same as most other
POSIX systems use."

It was not a dig against termcap per se.

Jamie

Re: Freebsd 14+ -- tcsh incompatible with terminfo

[Jamie Landeg-Jones]

Steffen Nurpmeso  wrote:

> Why?
> (That is to say: why -- if it is a *real* termcap?  If it is only
> a translation layer to terminfo, i am with you.  But otherwise
> not, i think a real termcap is much, much smaller, while offering
> anything a (simple) console program needs.)
> That is not to talk small the efforts of Mr. Dickey.  But for
> example the mailer i maintain *can* directly use BSD termcap if so
> desired, and it works just nice.

I agree that termcap does most of what we need already, so my main
reason is that there are 2 different systems in use to do the same
job, which is annoying. (FreeBSD doesn't exist in a vacuum) As terminfo
exists, is supported, and has terminal entries that our termcap doesn't
have, it seems to be better to switch to that. I'm sure it would mean
less maintenance for the FreeBSD committers too.

If terminfo didn't exist, I'd live with termcap.

There are also benefits to terminfo:

https://invisible-island.net/ncurses/ncurses.faq.html#extended_term

We don't even run with a "proper" termcap anyway!

"The base system's terminal database is referred to as “termcap.db”
but is actually an ncurses terminfo hashed database." -  
https://invisible-island.net/ncurses/ncurses.faq.html#what_platforms

So, yeah, despite Mr Dicky's success in making working with both as seamless
as possible ,it would still just be nice to not have to deal with 2 different
standards, that's all.

"setaf or AF, that is the question."

Cheers, Jamie

Re: Freebsd 14+ -- tcsh incompatible with terminfo

[Jamie Landeg-Jones]

Baptiste Daroussin  wrote:

> If you don't install (terminfo-db which nothing should pull in by default), 
> then
> you are on the default behaviour which is termcap, this has been made like 
> this
> on purpose, by default you have the behaviour you have always expected, and if
> you want another behaviour and larger support you install terminfo-db.
>
> The fact that tcsh does not play nicely with terminfo, is nother problem.

Thanks for the clarification. I had mistakingly thought many things pulled in
terminfo-db, but it appears to be only deskutils/arttime that does so, so it's
not as serious as I thought.

As for tcsh, I'll work on getting it fixed upstream.

Cheers, Jamie

Re: Freebsd 14+ -- tcsh incompatible with terminfo

[Jamie Landeg-Jones]

Thomas Dickey  wrote:

> actually it probably does affect "xterm" 
>
> Checking the source, tcsh is expecting a termcap string, while data read
> from the terminfo database is going to be in terminfo format -- even if
> read via tgetent/tgetstr
>
> tcsh is expecting a termcap string, and in its EchoTC function it duplicates
> the termcap version of what's tparm in a terminfo program.
>
> (tcsh could be modified readily to use terminfo for the case you're 
> describing,
>  but supporting $TERMCAP would be work)

Hi Thomas, thanks for the reply... from the ncurses man himself!

I *thought* I'd seen issues with just "xterm" but after posting the first
message, it seemed to start working, and so I doubted myself, but I must
have messed up somewhere!

What threw me about tcsh is it does mention terminfo in the man page and
the source, so I wrongly assumed the problem wasn't there.

Anyway, I'll raise it with the tcsh maintainers.

To the FreeBSD release folk, I think it's great that we're moving off termcap,
but is there a chance that base tcsh could be compiled with a private version
of the terminfo-less ncurses in time for 14.0-RELEASE, if a proper fix to tcsh
is going to take too long?

Thanks again, Thomas.

Cheers, Jamie

Re: Freebsd 14+ -- tcsh incompatible with terminfo

[Jamie Landeg-Jones]

Jamie Landeg-Jones  wrote:

> switch to tcsh, and reinitialise terminal information:
>
> % setenv TERM dumb
> % setenv TERM xterm

% setenv TERM xterm-256color

Apologies, it seems this doesn't affect plain "xterm", but it does at least 
affect xterm-16color and xterm-256color.

Is this, therefore, a terminfo.db issue?

Thanks again, Jamie

Freebsd 14+ -- tcsh incompatible with terminfo

[Jamie Landeg-Jones]

Hi!

The changes to FreeBSD base ncurses to use the terminfo db over termcap if it
exists have caused a few issues with tcsh, which doesn't seem to grok terminfo.

e.g. : install misc-terminfo

switch to tcsh, and reinitialise terminal information:

% setenv TERM dumb
% setenv TERM xterm
% echotc AF 1
echotc: `AF' requires 2 arguments.

Deleting the relevent terminfo entry, and reinitialising the terminal 
information
causes everything to work again.

Tested on stock 14.0-RC3

I have some other locally grown stuff that complains for similar reasons, that
I'll have to fix too, but in the meantime, what's the easiest way to force any
program to use termcap over terminfo rather than the other way around, or is
this the wrong approach?

I considered kludging with environment variables TERMINFO/TERMCAP, but these
are login based rather than program based, and if instead set inside a program,
could cause spawned programs to also be polluted, if not careful, especially
with a shell.

Cheers, Jamie

Re: grep(1) bug - duplicate output lines

[Jamie Landeg-Jones]

Kyle Evans  wrote:

> Alright, fine, be that way. :-) Try this on top of the existing patch:

Sorry! I have this knack of (accidentally) stumbling upon weird-case bugs
that usually don't affect anyone! :-)

> https://people.freebsd.org/~kevans/grep-color-addition.diff

Brilliant That all seems to work now!

I'll try not to break anything else! :-)

Cheers, Jamie

Re: grep(1) bug - duplicate output lines

[Jamie Landeg-Jones]

Jamie Landeg-Jones  wrote:

> Brilliant! Thanks for the quick response and fix. It works fine for me -
> I've not managed to break it again :-)

Famous last words

"grep -v" now produces duplicate lines! e.g. :

 | % grep -v sdjdjdjd /COPYRIGHT|head
 | #   @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
 | #   @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
 | 
 | 
 | The compilation of software known as FreeBSD is distributed under the
 | The compilation of software known as FreeBSD is distributed under the
 | following terms:
 | following terms:

Cheers, Jamie

Re: grep(1) bug - duplicate output lines

[Jamie Landeg-Jones]

Kyle Evans  wrote:

> I think this is what we want:
>
> https://people.freebsd.org/~kevans/grep-color.diff

Brilliant! Thanks for the quick response and fix. It works fine for me -
I've not managed to break it again :-)

> Basically, for --color with . we actually get each individual character 
> reported, and we can't really coalesce that. (Well, we could, but I'll 
> leave that for future improvement). Once you hit 32 matches in the same 
> line, we dump out the first set of matches then check again for any more
> that just didn't fit the first time. Unfortunately, that logic wasn't 
> prepared to avoid terminating the first time in case we have more 
> matches to output, so we'd terminate, then refill our matches with the 
> remainder of the line and output the leading context again + terminate 
> again.

Ahh, hence the 'chunks' of coloured sections, and the fact that the longer
the line, the more times it was repeated.

Will this be MFC'd to 13 and 14?

Thanks again, Jamie.

grep(1) bug - duplicate output lines

[Jamie Landeg-Jones]

When using color=always and a regex of '.' (for example), output lines
are duplicated.

$ grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD

E.G.:

$ grep --color=always . /etc/fstab

Cheers, Jamie

Re: changes to ps -d?

[Jamie Landeg-Jones]

Jamie Landeg-Jones  wrote:

> If you make "-D down" the default (as you suggested in a previous message), 
> then
> we would be back to having the problem.

To expand on that, if a "-D none" option is added, and "-D down" becomes the
default, then from my personal point of view, that would be fine. I can
easily modify my stuff to add that.

It comes down to what Piotr wants to do, and whether you think there is more
disruption going back to pre-12.2-release, than there would be now you're
used to the new behaviour since 12.2-release.

As I was the only person who seems affected by the 12.2-release changes, maybe
the newest breaking change is the more noticable?

What I'm saying is that personally, I don't care, as long as the pre 
12.2-release
mode of operation is available somehow, discussions on which should be the
default today are way beyond my pay grade :-)

Cheers, Jamie

Re: changes to ps -d?

[Jamie Landeg-Jones]

> Curious about the meaning of "would be the best in that -d would go back to 
> what it was" in 
> https://lists.freebsd.org/archives/freebsd-current/2023-August/004277.html.
>
> Currently in "ps -d -p " -d is not back at what it was.

Yes, back to what it was pre-releng/12.2. The functionality you like was new at
that point. It broke some of my things which had been running for years, and
relied on the original behaviour. As it was possible to affect others in similar
ways, it was decided to revert it as a POLA violation.

If you make "-D down" the default (as you suggested in a previous message), then
we would be back to having the problem.

I said I personally didn't mind if the original functionality was added back in
a different way, but Piotr graciously decided it would be best to revert to the
original behavior, and instead enable his new enhancements with a new option.

Cheers, Jamie

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Sulev-Madis Silber  wrote:

> on why removing those, i for example only use /etc/csh.cshrc so i don't need 
> others

Exactly the same here!

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Mike Karels  wrote:

> Both sets have been present since 4.3-Reno in 1990, although they were
> apparently not links.

Well before my time!
>
> > Removing them both is one of the first things I do when I install a new
> > system from install-media.
>
> Why?

Because I don't use them

> > If etcupdate is now removing them, maybe there has been an update to the src
> > distribution / mntree so that this historical weirdness has finally been 
> > removed?
>
> It is not weird.  /.profile and /.cshrc are used in single-user mode, the ones
> in /root are used for root logins.

Ah yeah, that would make sense, I guess. I remember my first unix systems,
the default home for the root login was / so there was no /root duplication of
those files.

> > If you have a /root/.cshrc and /root/.profile, try doing an ls -c on them to
> > see if their changed-date is when you did the etcupdate.
>
> They were modified by the removal of $FreeBSD$ a few days ago at the next
> etcupdate.

A. That idea won't work then!

Cheers

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Graham Perrin  wrote:

> If I recall correctly, a few hours ago etcupdate -B resulted in removal 
> of two files:
>
> /.cshrc
> /.profile
>
> Is this degree of checking/removal a novelty?
>
> (I can't recall the files' contents, or when I created them. I guess 
> that I carelessly created them as dot files months ago without realising 
> that I wasn't at ~, I don't mourn their loss.)

For as long as I can remember, (as far back as FreeBSD 2.2.7 in 1998) all
FreeBSD installs have /.cshrc and /profile as hardlinks to /root/.cshrc and
/root/.profile .

Removing them both is one of the first things I do when I install a new
system from install-media.

If etcupdate is now removing them, maybe there has been an update to the src
distribution / mntree so that this historical weirdness has finally been 
removed?

If you have a /root/.cshrc and /root/.profile, try doing an ls -c on them to
see if their changed-date is when you did the etcupdate.

Jamie

Re: ps(1) bugs and problems

[Jamie Landeg-Jones]

"Piotr P. Stefaniak"  wrote:

> On 2023-08-11 12:32:02, Jamie Landeg-Jones wrote:
> >How about reverting '-d', and adding "-D" for descending, and "-A" for 
> >ascending?
>
> I don't like that, because it would take three option-letters in total
> to implement the same function in different variants.

Yeah, I can see that.

> The old -d and the new -D'$^' would be the best in that -d would go back
> to what it was and -D would provide the much needed feature in two
> variants (possibly more in the future, if needed) while only taking one
> option-letter. The only problem is that it looks ugly.

I see why you chose "$" and "^", but wouldn't it look more friendly if
you instead used "up" and "down" or "A" and "D" or "forwards" and "backwards",
for example?

> For the record, just -d'$^' is impossible, because it would break
> existing command invocations.

Yeah, I can see that.

Cheers, Jamie

Re: ps(1) bugs and problems

[Jamie Landeg-Jones]

"Piotr P. Stefaniak"  wrote:

> I thought about this more and the change I proposed in
> https://reviews.freebsd.org/D41231 seems unnecessarily complicated,
> regardless of which characters will be chosen to denote going up and
> down the process tree. ps -D'^$' suggests there are possibly more
> characters to use and maybe even some kind of DSL is available.
>
> So a simpler option is to keep the new aspect of -d (that it traverses
> the tree down, even if ps is given a list of PIDs) and add a -D that
> would work the same, but the other direction.

That is indeed cleaner, and whilst the new "-D" option would cover the
particular use case I mentioned, the old sorting method with arbitary,
and specific PIDS is still useful.

How about reverting '-d', and adding "-D" for descending, and "-A" for 
ascending?

Cheers, Jamie

ps(1) bugs and problems

[Jamie Landeg-Jones]

I have a program that produces a list of PIDS, that are supplied via '-p'
to /bin/ps and are sorted with '-d'.

After a late upgrade on a particular machine, I've just been bitten
by the modifications to "ps" to unconditionaly add recurive descendancy
PID lookups to the '-d' option when a pid is specified.

There is nothing in the man pages or docs to suggest that this should
be a thing, but there you go.

Rather than just patch it out, Would a patch to allow the previous
behaviour as an option (even if the option isn't default) be accepted?

In addition, there is a bug in that ps now goes into a memory-sucking
endless-loop if you do:

ps -dp0

The manual page is no longer accurate either:

'-d' says "Note that this option has no effect if the “command”
column is not the last column displayed."

That is no longer true, it doesn't matter what column is displayed last,
if you use '-p', '-d' now completely changes the output

title: ps: extend the non-standard option -d (tree view) to work with -p
https://cgit.freebsd.org/src/commit/bin/ps/ps.c?id=ca8c0d5e811048ad67d0955642c5b486e9c0f3d2

author: Piotr Pawel Stefaniak  2020-05-07 16:56:18 +
commit: ca8c0d5e811048ad67d0955642c5b486e9c0f3d2 (patch)
tree:   374be17aead18daf2e3c7477a4573f60ce62d8f0 /bin/ps/ps.c

Cheers, Jamie

BUG: chflags(1) fails to remove uarch flag with hardlinked files (ZFS)

[Jamie Landeg-Jones]

Using chflags to remove "uarch" on more than one file at a time
(but when that file count is an even number) when the files are
hardlinked (have the same inode) and on ZFS doesn't work.

This becomes more problematic when using "find... -exec chflags nouarch {} +"
or "chmod -R".

Further details are in the bug report I just raised:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271925

Cheers, Jamie

Re: MOTD is not created correctly (since 2022/02/18)

[Jamie Landeg-Jones]

Garance A Drosehn  wrote:

> Not that it helps you much, but I did notice it and have an alternate
> version of rc.d/motd on my own systems.  I had no particular attachment
> to the earlier format, so my motd starts out by printing the two lines
> of:
> ```
>  -KU 1302505 1302505 -b 18fa15f83c483db67b818e3a48bbb312908754b1
> FreeBSD 13.2-STABLE (Garance-13x) #0 -- Fri May  5 17:53:55 EDT 2023

I too was actually not all that fussed with the old style, but the
multiple spaces in the output bugged me, so I was going to change it
back, when I stumbled on the issue.

I actually have closer to yours in my ssh-banner:

**  **
 FreeBSD/amd64 13.2-STABLE - Build 1302505 (May 13, 2023)
   23:25 BST  up 1 01:30   0.16,  0.18,  0.16
  -- SOD OFF IF YOU AREN'T AUTHORISED


> But I thought that committing that would trigger a bikeshed debate, so I
> also have an option to produce the output we previously had.  And given
> that no one seemed to be complaining about the "full uname" version, I
> figured I had an option for that too.  And then I thought all these 
> options
> were overkill and would trigger and even longer debate, so I never 
> brought
> the ideas forward.   :)

:-)

Oh yeah, definitely! It would be worse than the fractional seconds in
sleep(1) debate!

Cheers, for the response,
Jamie

Re: MOTD is not created correctly (since 2022/02/18)

[Jamie Landeg-Jones]

Xin Li  wrote:

> Maybe https://reviews.freebsd.org/D40225 ?
>
> (Nice find by the way!  I always feel that something was not right but 
> haven't looked close enough.)

Thanks! What is the best way to report things like this in the future?

I'm happy to create a phabricator report, Enji suggested a PR, and
previously, Warner said he's happy to accept github pull requests for
small changes.

Now, I admit I've not yet looked at how to do github pull requests, so
that omission is entirely my fault.

As for PRs, I've always done that previously, but these days they tend to
go unnoticed.

And I thought Phabricator was for comitters only. If that's not the case,
do I create a review there and add people myself? That has always seemed
a bit presumptuous!

Or is it a case of create PR/review, and then notify the appropriate mailing
list?

If so, when is it appropriate to use phabricator over PR, and vice verca?

I'm an old dog still used to "send-pr", but I'm happy to learn the new tricks! 
:-)

Cheers, Jamie

MOTD is not created correctly (since 2022/02/18)

[Jamie Landeg-Jones]

I've just finally updated to 13-stable, and can't be the first to notice this?!

/etc/rc.d/motd contains the line:

uname -v | sed -e 's,^\([^#]*\) #\(.* [1-2][0-9][0-9][0-9]\).*/\([^\]*\) $,\1 
(\3) #\2,'

Note the space before the "$" - needed because the uname -v output used
to have a trailing space. This was fixed and comitted on 2022/02/18:

https://cgit.freebsd.org/src/commit/usr.bin/uname/uname.c?id=7e05fa3b449007adaa6e588ebb3b8d76f30b355c

Since then, the sed doesn't match, so the uname(1) output is unchanged.

There's no point altering the sed to work with both posibilities, so can
someone commit the fix of removing the ' ' before the '$' in /etc/rc.d/motd ?

Cheers
Jamie

Re: find(1): I18N gone wild ?

[Jamie Landeg-Jones]

Yuri  wrote:

> No, find "-name" works with pattern rules in the first link, please see:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html

Yeah. *blush* Sorry about that. I had thought character classes were
for regular expressions only.

/gets coat

Re: find(1): I18N gone wild ?

[Jamie Landeg-Jones]

My mistake. Character classes are indeed part of glob

https://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html
2.13.3 Patterns Used for Filename Expansion

Sorry for the noise.

Re: find(1): I18N gone wild ?

[Jamie Landeg-Jones]

Yuri  wrote:

> > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13
> > 
> > ...which in turn refers to the following link for bracket expressions:
> > 
> > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
> > 
> > Why we don't support all of that is different story.
>
> A bit more on this; first link applies both to find(1) and fnmatch(3),
> and find uses fnmatch() internally (which is good), but even the
> function that processes bracket expressions is called rangematch() and
> that's really all it does ignoring other bracket expression rules:
>
> https://cgit.freebsd.org/src/tree/lib/libc/gen/fnmatch.c#n234
>
> So to "fix" find we just need to implement the bracket expressions
> properly in fnmatch().

No. find "-name" works with GLOBs not regex.

The functionality you are talking about, and the page you quoted refer to 
regular expressions.

For that, you use find "-regex" - note that the regex is assumed anchored, so:

$ LANG=en_US.UTF-8 find -E /etc/rc.d -regex '.*[[:upper:]]+' -print
/etc/rc.d/NETWORKING
/etc/rc.d/FILESYSTEMS
/etc/rc.d/SERVERS
/etc/rc.d/DAEMON
/etc/rc.d/LOGIN
$

Jamie

Re: find(1): I18N gone wild ?

[Jamie Landeg-Jones]

Jamie Landeg-Jones  wrote:

> When the locale collation first came in, there were numerous issues
> like this, causing POSIX to change it to undefined (My guess is that
> it had been one way for too long for them to specifically redefine it,
> so "undefined" it became.)

I found the official POSIX rational for the change (not this isn't
the same URL that Yuri posted, but a seperate appendex to it)

https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap09.html#tag_21_09_03_05

cheers, Jamie

Re: find(1): I18N gone wild ?

[Jamie Landeg-Jones]

Xin LI  wrote:

> This is expected behavior (in en_US.UTF-8 the ordering is AaBb, not ABab).
> You might want to set LC_COLLATE to C if C behavior is desirable.
>
> On Mon, Apr 17, 2023 at 2:06 PM Poul-Henning Kamp 
> wrote:
>
> > This surprised me:
> >
> > # mkdir /tmp/P
> > # cd /tmp/P
> > # touch FOO
> > # touch bar
> > # env LANG=C.UTF-8 find . -name '[A-Z]*' -print
> > ./FOO
> > # env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
> > ./FOO
> > ./bar
> >
> > Really ?!

TL;DR Fix find(1) so it works as you expected. It's "legal" to do so.

Not quite expected behaviour. It used to be, but now the behaviour is 
officially undefined, (as mentined in the section that Yuri quoted)

When the locale collation first came in, there were numerous issues
like this, causing POSIX to change it to undefined (My guess is that
it had been one way for too long for them to specifically redefine it,
so "undefined" it became.)

However, "undefined" would also cover the original way of doing things,
and as so many things break unexpectedly, many applications now treat
such ranges as they did pre-locales.

There would be nothing wrong in therefore changing find(1) to give the
results you expected. (and in my opinion, I hope that that becomes
the defacto standard)

For further justification, note that "awk" in base (in  newer
versions at least) already gives the results you'd expect, as now
does "gawk".

In fact, a good summary of the situation, and why the gawk owner reverted
the code to treat all character ranges as the tradional pre-locale
situation is here:

https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html

Let's follow suit!

Cheers, Jamie

Re: find(1): I18N gone wild ?

[Jamie Landeg-Jones]

Xin LI  wrote:

> This is expected behavior (in en_US.UTF-8 the ordering is AaBb, not ABab).
> You might want to set LC_COLLATE to C if C behavior is desirable.
>
> On Mon, Apr 17, 2023 at 2:06 PM Poul-Henning Kamp 
> wrote:
>
> > This surprised me:
> >
> > # mkdir /tmp/P
> > # cd /tmp/P
> > # touch FOO
> > # touch bar
> > # env LANG=C.UTF-8 find . -name '[A-Z]*' -print
> > ./FOO
> > # env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
> > ./FOO
> > ./bar
> >
> > Really ?!

TL;DR Fix find(1) so it works as you expected. It's "legal" to do so.

Not quite expected behaviour. It used to be, but now the behaviour is 
officially undefined, (as mentined in the section that Yuri quoted)

When the locale collation first came in, there were numerous issues
like this, causing POSIX to change it to undefined (My guess is that
it had been one way for too long for them to specifically redefine it,
so "undefined" it became.)

However, "undefined" would also cover the original way of doing things,
and as so many things break unexpectedly, many applications now treat
such ranges as they did pre-locales.

There would be nothing wrong in therefore changing find(1) to give the
results you expected. (and in my opinion, I hope that that becomes
the defacto standard)

For further justification, note that "awk" in base (in  newer
versions at least) already gives the results you'd expect, as now
does "gawk".

In fact, a good summary of the situation, and why the gawk owner reverted
the code to treat all character ranges as the tradional pre-locale
situation is here:

https://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html

Let's follow suit!

Cheers, Jamie

[FUSEFS] File close() failures relating to attempted atime update

[Jamie Landeg-Jones]

There is a replicable problem with file closing on fusefs, since
0bade34633f997c22f5e4e0931df0d534f560a38, Alan Somers  
2021-11-29 01:53:31 +

It appears to be related to attempting to update atime on a file you
don't have write-access to.

I've posted much more details, and a potential fix to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270749

Cheers, Jamie

Re: diff(1) goes into cpu-hogging endless loop

[Jamie Landeg-Jones]

Tom Jones  wrote:

> My guess is that you are hitting a worst case in the stone algorithm. I
> have a WIP review to integrate the Myers algorithm from libdiff here:
>
> https://reviews.freebsd.org/D36860

Ahh, thanks, Tom. I'm glad it's being addressed. I'll check out
the review.

Cheers, Jamie

Re: diff(1) goes into cpu-hogging endless loop

[Jamie Landeg-Jones]

Just to add, that whilst the "diff" succeeded with the files
split into 10Mb chunks, the time taken to run was really high, up
to 10 times longer than gnu diff:

+ /usr/bin/time diff 1.aa 2.aa 16.74 real16.70 user 0.03 sys
+ /usr/bin/time diff 1.ab 2.ab 16.53 real16.45 user 0.07 sys
+ /usr/bin/time diff 1.ac 2.ac 21.58 real21.51 user 0.06 sys
+ /usr/bin/time diff 1.ad 2.ad 22.37 real22.25 user 0.11 sys
+ /usr/bin/time diff 1.ae 2.ae 25.93 real25.81 user 0.11 sys
+ /usr/bin/time diff 1.af 2.af 26.63 real26.53 user 0.09 sys
+ /usr/bin/time diff 1.ag 2.ag  0.98 real 0.96 user 0.02 sys

+ /usr/bin/time gdiff 1.aa 2.aa 2.44 real 2.37 user 0.06 sys
+ /usr/bin/time gdiff 1.ab 2.ab 4.09 real 4.06 user 0.03 sys
+ /usr/bin/time gdiff 1.ac 2.ac 2.24 real 2.22 user 0.01 sys
+ /usr/bin/time gdiff 1.ad 2.ad 1.99 real 1.98 user 0.00 sys
+ /usr/bin/time gdiff 1.ae 2.ae 2.63 real 2.60 user 0.02 sys
+ /usr/bin/time gdiff 1.af 2.af 2.62 real 2.59 user 0.03 sys
+ /usr/bin/time gdiff 1.ag 2.ag 0.12 real 0.11 user 0.00 sys

diff(1) goes into cpu-hogging endless loop

[Jamie Landeg-Jones]

Hi, A "diff" of 2 files:

1  77,933,904 bytes
2  63,013,818 bytes

, goes into an endless loop, whilst "gdiff" completes the operation in
about 5 seconds.

I tested using the latest "diff" from current, and get the same result.

Splitting both files into 10Mb chunks, and diffing these was successful.

A ktrace of the "diff" actually stops producing any output after about
5 seconds, whilst the cpu looping continues.

Any ideas on what to do next? Does anyone else get the same result?

The files are just utf-8 freebsd git logs, and are available here if
anyone would like to test:

http://www.catflap.org/jamie/1.xz (13,282,864 bytes)
http://www.catflap.org/jamie/2.xz (12,221,164 bytes)

Cheers, Jamie

Re: An idea for swap partition size vs. swap space size in use handling

[Jamie Landeg-Jones]

Mark Millard  wrote:

> On Jan 21, 2023, at 23:17, Poul-Henning Kamp  wrote:
> > 
> > Last I looked at that code, that is precisely what happens
> > if you add a too big swap-device ?
>
> It produces a notice reporting how much bigger what it is
> using is than what is recommended, if I understand the
> message right. Here is an example were the difference was
> small for an armv7 context:
>
> warning: total configured swap (1003519 pages) exceeds maximum recommended 
> amount (1003072 pages).
>
> Another from a context with a much bigger difference:
>
> warning: total configured swap (2097152 pages) exceeds maximum recommended 
> amount (916632 pages).
>
> These sort of messages are followed by:
>
> warning: increase kern.maxswzone or reduce amount of swap.

I thought the same as phk. And I always thought those messages were
just informational warnings on what to do to stop that excess swap
space being unused and effectively wasted (i.e. suggestions to change
settings, or reduce the swap size!), but you say this isn't correct:

> As I understand, the 2097152 pages vs. 916632 pages example means
> that it was operating with the referenced fragmentation problems
> being more likely. That would not be true if it was just using
> more like the 916632 pages and ignoring the rest.

Are you, phk, or anyone else, able to provide further pointers or
clarification on this?

Cheers, Jamie

Re: 1 year src-patch anniversary!

[Jamie Landeg-Jones]

Warner Losh  wrote:

> Bugzilla is inefficient for small patches.

Yes, I can see that bugzilla is unsuitable for things like that.

> I'm trying an experiment on github: any smallish, almost ready patches will
> be landed, redirected or rejected quickly

Thanks Warner! That sounds great! - I'll be taking you up on that!

Another thing - my last port maintainer update was converted to a phabricator
post, as was the recent patch that delphij committed.

Should I have posted them there instead to save the committers time?
I always thought new phabricator posts were for committers
only, as it seems to me to be a way for committers to get their code
reviewed and passed prior to committing.

Cheers, Jamie

Re: 1 year src-patch anniversary!

[Jamie Landeg-Jones]

"Julian H. Stacey"  wrote:

Firstly, apolgies for the delay in replying.

> I wrote a tool in 1993 I still use
>   http://www.berklix.com/~jhs/bin/.csh/customise
> to apply trees of generic & personal diffs to src & ports, for multi releases
>   http://www.berklix.com/~jhs/src/
> to apply diffs, where some are submitted, some committed
> for some versions, some diffs still needed for older versions, &
> some not submitted or committed.

Thanks, I'll look at that.

> I guess many, especially non-commiters, maintain trees of uncommited
> diffs & there's probably other applicator scripts, numerous
> re-inventing of wheels for decades, 'cos send-pr /
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid
> commiters can't keep up with submissions.

Yep :-( And to the committers: I'm not meaning to complain - I know
it's a volunteer effort, but sometimes it can be frustrating.

This particular bug I've highlighted is laughably trivial and inconsequential,
but as Julian says, there must be many people who end up doing
the same thing, and that all adds up to lots of wasted work that
could be better channeled.

What can we do to help?

> FreeBSD hackers(especially non commiters who must wait for commits
> to reduce their heap of candidate diffs) would benefit from a unified
> set of tools & directory formats to allow individuals to maintain
> & export trees of candidate diffs etc to some common standards.
>
> It wouldnt obviate / replace send-pr &
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would
> be an optional normalied convenience, especially beneficial to those
> who are Not commiters but who have growing heaps of uncommited patches.
>
> Maybe a summer of code or other person might look at Jamie's & my
> applicator scripts, & diff tree shapes, not for our actual current diffs,
> but to design common unified standards to export trees of candidate diffs
> that can be applied by one common applicator tool ?
>
> Hacker who are not committers presumably accumulate an an ever
> growing heap of diffs, a burden best normalised & automated.

That's a good idea. I'm happy to describe/publish my mechanisms - I've been
meaning to publish all my tools in case they help anyone, but time keeps
getting in the way! As for the patches, it's
quite basic: for src, all patch-files in a common directory-tree (synced to
my machines along with other common directories/tools) are applied
after each git sync. The tree contains directories for "all versions"
patches, and then directories for differing FreeBSD versions.

For ports, I have 3 sets of common patch directories:

1) Patches to the port-templates (i.e. the build files under /usr/ports)
2) Patches to the ports source itself.
3) "Overrides" - directories containing the port-templates for a port
   that are installed after a port-sync. These are usually "deleted"
   ports that I actually still use, local-port hacks that no-one else
   would care about, and less-often complete overrides of ports for
   various reasons.

There is glue code to ensure these are all automatically actioned.

I'd love to get involved with anything that can help streamline this,
whether src or ports.

Cheers, Jamie

Re: 1 year src-patch anniversary!

[Jamie Landeg-Jones]

Mateusz Guzik  wrote:

> Well I was not aware of it.

Apologies for the delay in replying. Fair enough you weren't aware, but the
thing is, how do we make people aware?

If bugs.freebsd.org is no longer the way to go, what's the alternative?

> mail me with git format-patch result and I'll commit.

Thanks! However, in this case, "delphij" has already done it.

Cheers, Jamie

1 year src-patch anniversary!

[Jamie Landeg-Jones]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
to an admittedly trivial issue, but it's soon going to hit one year old,
and has not had any feedback. Not even "this is rubbish. close ticket"

| jamie@catwalk:~ % stat 'so good they named it twice'
| stat: so good they named it twice: stat: No such file or directory

As such, it's the oldest of my patches to be completely ignored, but then,
most of my fixes I haven't even submitted, because, what's the point?
I've instead spent time writing something so the patches are automatically
aplied to my src tree, and distributed to all my servers.

I know it's a volunteer effort, but I've been here 25 years, and whilst
I could (and should) take on more port-maintainership, any other offers
of help have fallen on deaf ears.

*shrug* I miss Mark Linimon.

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Jamie Landeg-Jones]

Michael Gmelin  wrote:

> I like the idea of having something like tmpfiles.d, it would also help port 
> maintainers (could also be done as a port).

I use tmpfs for /var/run and already have such a script for this very reason
(although not clamav)

I would have thought each port startup script should ensure it's file/directory
exists before attempting to launch - having "tmpfiles.d" would still require
some changes for the port maintainer to make to their port, but I guess it
may help to keep things centralised.

I'm willing to "standardise" my script if it would help, but as it stands, you
can see it here:

http://freebsd.dyslexicfish.net/src/

15:47 (71) "~/x" jamie@newbie% cat /usr/common/etc/var_run.mtree
# File/DirectoryUser   GroupPerms
#
distccd.pid distcc distcc 640
ntop/   ntop   ntop   750
nsd/nsdnsd750
netdata/netdatanetdata750
screens/root   wheel 1777
sshdbanner/ sshdbanner sshdbanner 755
spamd/  spamd  spamd  750
symon.pid   _symon _symon 640
symux.pid   _symon _symon 640
vnstat/ vnstat vnstat 750
 

Re: FreeBSD is a great operating system!

[Jamie Landeg-Jones]

Hans Petter Selasky  wrote:

> On 7/8/22 05:40, Turritopsis Dohrnii Teo En Ming wrote:
> > Dear Hans Petter Selasky,
> > 
> > Why do you say FreeBSD license is a killer?
>
> Because you can do anything you want with the operating system :-)

"is a killer" could easily have been taken as a negative!

Gotta love our English language!

Re: recover deleted file

[Jamie Landeg-Jones]

Sami Halabi  wrote:

> Hi,
> thanks for your response.
>
> Would someone from the foundation step in and put it in GSOC ideas?
>
> kirk@ - would it be possible for you to do it ? :)
>
How would you handle file modifications? Backup every original too, or
just deal with literal deletions?

If you are just concerned with user accidental deletions, you can easily
modify your view of "rm" to point to something that instead stores the
file somewhere safe..

Jamie

ps(1) with '-ww' / libxo truncating output

[Jamie Landeg-Jones]

I've noticed that ps(1) (even with '-ww') is truncating output if it
exceeds a cerain length.

Further investigation shows that this is due to the libxo module.

The ps(1) man page implies there will be no truncation if "-ww" is used.

Is this a manpage issue, or a libxo issue, or a ps issue in the way it
calls libxo?

Test cases. These commands (run under sh not csh/tcsh) stuff dummy
variables into the environment. Note the truncated responses of test 1 and 2:

1) env -i $(jot 500 | awk '{print "testvar_"$0"=dummydummydummydummy"}') sh -c 
'ps -wwe -p $$'

2) env -i $(jot 500 | awk '{print "testvar_"$0"=dummydummydummydummy"}') sh -c 
'ps -wwe -p $$ --libxo text'

3) env -i $(jot 500 | awk '{print "testvar_"$0"=dummydummydummydummy"}') sh -c 
'ps -wwe -p $$ --libxo xml'
 
Cheers, Jamie

Re: What are the in-kernel functions to print human readable timestamps (bintime)?

[Jamie Landeg-Jones]

Warner Losh  wrote:

> since we already add stuff to what's printed for the priority. We could say
> <3,seconds-since-boot.fracsec> instead of just <3> and hack dmesg
> to print the right thing.

Isn't that what kern.msgbuf_show_timestamp does already?

I use that, along with this script:

17:15 (40.0°C 400) [2] (49) "completions" root@thompson# cat 
/usr/common/bin/dmesg-uptime-to-date
#!/bin/sh -efu
set -efu

boottime="$(sysctl -n kern.boottime | gawk '{printf "%d", gensub ("^.* sec = 
([1-9][0-9]*), .*$", "\\1", 1)}')"

[ -z "$(printf '%s' "$boottime" | egrep '^0$|^[1-9][0-9]*$')" ] && { printf 
'Invalid boottime retrieved.\n' >& 2; exit 1; }

dmesg "$@" | gawk -v boottime="$boottime" '

{
  uptime = gensub ("^\\[([1-9][0-9]*)\\] .*$", "\\1", 1)
  if (uptime == $0) realtime = "??? ?? ??:??;??"
   else realtime = strftime ("%b %d %T", uptime + boottime)

  print realtime " " $0
}'
 

Mar 11 00:41:51 [3568757] Limiting closed port RST response from 313 to 200 
packets/sec
Mar 11 00:41:54 [3568760] Limiting closed port RST response from 308 to 200 
packets/sec
Mar 11 06:23:28 [3589254] icmp redirect from 183.196.23.176: 192.168.2.104 => 
183.196.23.161

etc.

Cheers, Jamie

Re: USB Disk Stalls on -current

[Jamie Landeg-Jones]

grarpamp  wrote:

> Yes, some USB hw is very flaky,
> but ZFS can work great on these...

For what it's worth, I have had for 2.5 years, tracking stable, a NAS hanging
off a single NUC usb port, with 14 hard disks, 12 of which are used for 2 ZFS,
spools, of two 3X2 mirror spools.

Albeit, I'm using USB3

During heavy writes, I often get:

[1429164] (da10:umass-sim10:10:0:0): WRITE(16). CDB: 8a 00 00 00 00 02 04 39 b2 
80 00 00 01 00 00 00
[1429164] (da10:umass-sim10:10:0:0): CAM status: CCB request completed with an 
error
[1429164] (da10:umass-sim10:10:0:0): Retrying command, 14 more tries remain

, but with no errors or timeouts. I scrub regularly etc.

It rarely has to attempt a retry more than once (although I did bump
"kern.cam.da.retry_count" up to 15 a while back while dealing with another
issue, and never changed it back)

I only get about 300MB/s maximum on file reads though, but the current USB
daisychaining I use isn't ideal. (Each raw disk individually give 150MB/s)

The only issue I have is occasionally the main USB hub craps out, and all
the disks disappear for a few seconds. When it recovers, and the OS sees
the disks again, things remain weird until a reboot.

cheers, Jamie

Re: Dragonfly Mail Agent (dma) in the base system

[Jamie Landeg-Jones]

> It was a let's consider all the gotchas before diving in with both feet.

*shrug*

And all I did was suggest one way to deal with it. I didn't disagree with
your analysis. I don't understand the hostility.

> For me personally, maintainer of nmh and heirloom-mailx, I will enable the 
> dma build on my sandbox to give it a little workout.

I use heirloom-mailx all the time. It works fine with DMA.

Ooops, sorry if that comment was too presumptuous of me ;-)

cheers!  ... Jamie

Re: Dragonfly Mail Agent (dma) in the base system

[Jamie Landeg-Jones]

Cy Schubert  wrote:

> In message <202202061553.216fr0yt071...@donotpassgo.dyslexicfish.net>, 
> Jamie La
> ndeg-Jones writes:
> > Cy Schubert  wrote:
> >
> > > dma doesn't support SMTP submission, we may need to review various port 
> > > default options or whether ports even support it.
> >
> > Good catch.
>
> You misquoted me. Read my email again!

Sorry, I read it again, but it still looks to me as "some ports only work via
SMTP submission, so they will need to be looked at."

I suggested an alternative of instead, "emulating" the SMTP submission
functionality (but maybe in a better way that my suggested hack, though)

After all, it isn't just ports - there could be other third party stuff
that only works via submission too.

So, to avoid breaking functionality, smtp submission is something to think
about continuing supporting, hence my use of the phrase "good catch".

Is this not correct?

cheers, Jamie

> > Would a suitable workaround be to parse the dma.conf file for the SMARTHOST
> > address, and then set up a simple tcp proxy on the local submission port to
> > that?
>
> Your comment is based on a false premise.

Re: Dragonfly Mail Agent (dma) in the base system

[Jamie Landeg-Jones]

Cy Schubert  wrote:

> dma doesn't support SMTP submission, we may need to review various port 
> default options or whether ports even support it.

Good catch.

Would a suitable workaround be to parse the dma.conf file for the SMARTHOST
address, and then set up a simple tcp proxy on the local submission port to
that?

Re: Dragonfly Mail Agent (dma) in the base system

[Jamie Landeg-Jones]

Ed Maste  wrote:

> Since 2014 we have a copy of dma in the base system available as an
> optional component, enabled via the WITH_DMAGENT src.conf knob.

I thought it was enabled at default!

> I am interested in determining whether dma is a viable minimal base
> system MTA, and if not what gaps remain. If you have enabled DMA on
> your systems (or are willing to give it a try) and have any feedback
> or are aware of issues please follow up or submit a PR as appropriate.

I use it on my non-mailservers for delivering both local mail and remote
mail (from cron etc. to remote users) via my mailservers as smarthost.

It works perfectly. I've been using it for many years. It doesn't run as
a daemon - if a message can't be delivered (e.g. smarthost temporarily
unavailable), it will be requeued, and the process exits.

Don't forget to add the cron entry to retry requeued entries!

*/30*   *   *   *   root/usr/libexec/dma -q
 
Thus was my only minor "gotcha" - it wasn't obvious from the man pages
to add the cron entry (or maybe I just missed it)

As for the smarthost configuration, I've successfully used ipv4, ipv6,
both on port 25, and non-standard ports. I've also used combinations
of non-encrypted, TLS, and opportunistic TLS, - all work as expected.

I haven't ever used the smtp-login facility.

Cheers, Jamie

[patch] touch(1) enhancement

[Jamie Landeg-Jones]

I've added an option to touch(1) - details here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260871

It adds "-R", which is like "-r", but in the case of a link, refers to
the link itself.

I'm not sure what the protocol is regarding adding "non-standard"
options to standard commands, so please don't flame me if you
think it's useless!

Cheers, Jamie

Re: pkg sqlite database borked ( again ). How to restore?

[Jamie Landeg-Jones]

Dennis Clarke via freebsd-current  wrote:

> Ah well ... that seems to toss a ton of errors and yet works ?

Ooops.

Sorry for the delay, I originally missed your post.

I forgot to mention, this is for rebuilding the db from scratch,
as such, you needed to delete the old db file first - hence the
warnings about tables already existing, and presumably the other
"UNIQUE" errors.

I'd personally be uncomfortable keeping it like this, but I don't
know enought about pkg, but if as you said it works, it seems the
merge went ok!

Cheers, Jamie

Re: pkg sqlite database borked ( again ). How to restore?

[Jamie Landeg-Jones]

Dennis Clarke via freebsd-current  wrote:

> europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump
>
> europa#
> europa# pkg backup -r /var/db/pkg/local.sqlite.dump
> Restoring database:
> Restoring: 100%
> pkg: sqlite error while executing backup step in file backup.c:98: not
> an error

The backup file consists of sql statements, the pkg backup -r I think
requires a binary db file.

I think you need to do this:

pkg shell < /var/db/pkg/local.sqlite.dump

Cheers, Jamie

Re: stat(1) isn't honouring locale

[Jamie Landeg-Jones]

Stefan Esser  wrote:

> > % date +%+
> > Fri 29 Oct 2021 00:15:05 BST
> > 
> > % stat -t%+ -f '%Sm' .
> > Fri Oct 29 00:13:38 BST 2021
> > -

> thank you for reporting this issue and suggesting a fix.
>
> I have committed your proposed fix to -CURRENT as Git commit 20f8331aca892ff8
> and plan to MFC it to 13-STABLE in a few days.
>
> I'm CCing to the release engineer, since this might be a change that we want
> to include in the upcoming 12.3 release (currently in beta).

Thanks, and thanks for the quick response! I wasn't sure if it was an 
oversight, or if there was something I missed.

Cheers, Jamie

P.S. Thanks for not mentioning that when I editted the order of my example 
commands above to appear in a more logical order, I managed to make it look as 
if I'd gone back in time Ooops!

stat(1) isn't honouring locale

[Jamie Landeg-Jones]

stat(1) isn't honouring locale.

The manual page says:

 -t timefmt
  Display timestamps using the specified format.  This format 
is passed directly to strftime(3).

strftime(3) says:

   %+is replaced by national representation of the date and time (the 
format is similar to that produced by date(1)).

However:

-
% date
Fri Oct 29 00:14:12 BST 2021

% date +%+
Fri Oct 29 00:14:19 BST 2021

% stat -t%+ -f '%Sm' .
Fri Oct 29 00:13:38 BST 2021
-

% setenv LANG en_GB.UTF-8

% date
Fri 29 Oct 2021 00:14:57 BST

% date +%+
Fri 29 Oct 2021 00:15:05 BST

% stat -t%+ -f '%Sm' .
Fri Oct 29 00:13:38 BST 2021
-

Including  and adding:

(void) setlocale(LC_TIME, "");

before the call to strftime() in usr.bin/stat/stat.c fixes this

Is there any reason this isn't in place?

Cheers, Jamie

Re: killall, symlinks, and signal delivery?

[Jamie Landeg-Jones]

Steve Kargl  wrote:

> Yes, that's likely.  So, it could be a change in behavior
> for ImageMagick.  Your suggested ps command doesn't provide

I don't know when the change was made, but the pkg for ImageMagik 6.9.12.12
has "display" as a stand-alone binary, whilst the pkg for 7.0.11.12 has it
as a softlink.

So yeah, either an upstream change, or a port change.

Cheers, Jamie

Re: On 14-CURRENT: no ports options anymore?

[Jamie Landeg-Jones]

"Hartmann, O."  wrote:

> On Sat, 13 Mar 2021 15:13:15 -0500
> Michael Butler via freebsd-current  wrote:
>
> > On 3/13/21 3:00 PM, Hartmann, O. wrote:
> > > On Sat, 13 Mar 2021 19:52:47 + (UTC)
> > > Filippo Moretti via freebsd-current  wrote:
> > >   
> > >>   
> > >> I had the same problem in console modeFiippo
> > >>  On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser 
> > >> 
> > >> wrote:
> > >>
> > >>   Am 13.03.21 um 20:17 schrieb Hartmann, O.:  
> > >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when 
> > >>> trying to set
> > >>> options via "make config" or via poudriere accordingly. I always get 
> > >>> "===> Options
> > >>> unchanged" (when options has been already set and I'd expect a dialog 
> > >>> menu).
> > >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is 
> > >>> at FreeBSD
> > >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 
> > >>> 2021 amd64).
> > 
> > I ran into something similar where dialog4ports would dump core after an 
> > upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,
> > 
> > imb
>
> Thanks, recompilig ports-mgmt/dialog4ports solved the problem! I was sure 
> that after some
> ncurses changes in 14-CURRENT I've rebuilt every single port on all 
> 14-CURRENT systems
> after that incident, bad luck.

This bit me a few years ago - in my case, the terminal type wasn't recognised. 
If dialog4ports
doesn't run successfully, the error is ignored by the ports scripts. This was 
on a new
install (hence the reason I hadn't yet installed my termcap), and it meant that 
before I
noticed, quite a number of ports got installed without the options I wanted.

Since then, I've patched bsd.port.mk with:

--- bsd.port.mk.orig2017-06-06 17:38:00.0 +0100
+++ bsd.port.mk 2017-06-08 01:31:36.320294000 +0100
@@ -4729,8 +4729,8 @@
trap "${RM} $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \
${SETENV} ${D4P_ENV} ${SH} ${SCRIPTSDIR}/dialog4ports.sh 
$${TMPOPTIONSFILE} || { \
${RM} $${TMPOPTIONSFILE}; \
-   ${ECHO_MSG} "===> Options unchanged"; \
-   exit 0; \
+   ${ECHO_MSG} "===> ERROR: Options unchanged"; \
+   exit 1; \
}; \
${ECHO_CMD}; \
if [ ! -e $${TMPOPTIONSFILE} ]; then \

I never submitted this patch, because the way it was written seemed 
intentional. Maybe this should be reviewed?

Cheers,
  Jamie

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

/usr/bin/diff - incorrectly says files are identical

[Jamie Landeg-Jones]

When diff hits certain access errors, function diffreg() shows the error 
message, and then returns to the calling function, which calls print_status() 
with the return value.

However, in these cases, the return value isn't changed from the initial 
default value of D_SAME.

Normally, print_status() with a value of D_SAME does nothing, so this works out 
ok, however, if the "-s" flag is set, a message is displayed showing 
identicality:

case D_SAME:
if (sflag)
printf("Files %s%s and %s%s are identical\n",   

path1, entry, path2, entry);
break;

This then produces such results as:

% diff  -s /COPYRIGHT /var/run/rpcbind.sock
diff: /var/run/rpcbind.sock: Operation not supported
Files /COPYRIGHT and /var/run/rpcbind.sock are identical

% diff  -s /COPYRIGHT /etc/master.passwd
diff: /etc/master.passwd: Permission denied
Files /COPYRIGHT and /etc/master.passwd are identical

Further details, and fixing patch here: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252614

Cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Git and complementary web interfaces (some fast but basic, others fuller-featured)

[Jamie Landeg-Jones]

Graham Perrin  wrote:

> Strictly speaking, main site  does still 
> direct developers to the Subversion repository and the Git mirror on GitHub.

Fair enough, but that will change, and timestamps don't appear to be an
option. I'm sure it wouldn't be too painful to add, I'll probably look at
it myself when I switch to FreeBSD-13.

> cgit describes itself as "hyperfast" with 
>  "basic repository browsing" 
> as a feature.
>
> Beyond those basics, I guess that it will be appropriate to ensure 
> awareness of complementary web-based repository browsers including 
> GitHub and  GitLab; these might be 
> described as fuller-featured (without explicitly describing them as 
> relatively slow). Awareness through the Developers menu at 
>  and so on.

I liked svnweb. I like cgit. github is too heavy for browsing (I can't be
the only one who fires up w3m from the command line to do a quick
check on something)

A typical "file/directory" type ui that git has is all I want... but
with absolute timestamps!

:-)

Cheers,
Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Git: timestamps

[Jamie Landeg-Jones]

Graham Perrin  wrote:

> Alongside 'tree', click 'log'

Thanks, but I wanted the file dates, not the log!

> Also/alternatively there's the read-only mirror on GitHub so, for example:
>
> 

I know, which is why I miss it on the FreeBSD main site.

cheers!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Jamie Landeg-Jones]

Warner Losh  wrote:

> > Not having timestamps on files cloned or viewed in cgit.freebsd.org is a
> > nightmare too.
> >
>
> I just clicked through and saw several time stamps quite trivially. Could
> you be more specific in your complaint?
>
> Warner

I wasn't really complaining - If the git transition is better for you guys, I'm 
all for it.

However, this is one such URL: https://cgit.freebsd.org/src/tree/usr.bin/diff

Those files have no dates besides them on my screen..

Cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git non-time-sequential logs

[Jamie Landeg-Jones]

Ryan Libby  wrote:

> On Mon, Jan 4, 2021 at 10:08 AM Warner Losh  wrote:
> ...
> > As for date order, we could also add a commit hook that requires the date
> > to be properly set, but that creates friction for developers. Is that
> > friction worth the benefits? I don't think so, but as you say we could also
> > add notes... but since there's no checkout by date feature, I'm not sure
> > what good it would do.
>
> Not a vote one way or the other, but it would at least make
> git log --since more meaningful.

Not having timestamps on files cloned or viewed in cgit.freebsd.org is a 
nightmare too.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: again this ugly graphic driver sloopy mistake

[Jamie Landeg-Jones]

"Vanbreukelingen Ltd."  wrote:

> No!
>
> No freeBSD on this laptop anymore, sorry. I'm deluded like hell from 
> this sessions; after 30 hours of compiling world I get a "disk full". 
> Trying my luck with openBSD here.

Apologies for not sending you a bigger disk.

> consider this as a divorcing paper.

Don't worry, I'm sure it won't be contested.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 2 reminder

[Jamie Landeg-Jones]

Can anyone using the new vendor openzfs let us know if it fixes
the "mmp_thread_enter" bug recently MFC'ed to STABLE?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247829

Cheers
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic when attempting to create tunnel when a tunnel with the named alias exists

[Jamie Landeg-Jones]

>From the "Why did you do that?" department:

I stumbled across a panic in 12.1-stable and 13-current. If you
attempt to create a tunnel, which would have the same name as
an already existing tunnel "alias" hardlink, you get a panic.

E.G:

# ifconfig tun create name tun1
# ifcondif tun create

FreeBSD 12.1-STABLE:

 | Fatal trap 12: page fault while in kernel mode
 | cpuid = 0; apic id = 00
 | fault virtual address= 0x28
 | fault code   = supervisor read data, page not present
 | instruction pointer  = 0x20:0x80ccbd38
 | stack pointer= 0x28:0xfe56d4e0
 | frame pointer= 0x28:0xfe56d510
 | code segment = base 0x0, limit 0xf, type 0x1b
 |  = DPL 0, pres 1, long 1, def32 0, gran 1
 | processor eflags = interrupt enabled, resume, IOPL = 0
 | current process  = 1434 (cat)
 | trap number  = 12
 | panic: page fault
 | cpuid = 0
 | time = 1589762473
 | KDB: stack backtrace:
 | #0 0x80c1d2f7 at kdb_backtrace+0x67
 | #1 0x80bd062d at vpanic+0x19d
 | #2 0x80bd0483 at panic+0x43
 | #3 0x810a7dcc at trap_fatal+0x39c
 | #4 0x810a7e19 at trap_pfault+0x49
 | #5 0x810a740f at trap+0x29f
 | #6 0x81081bdc at calltrap+0x8
 | #7 0x80cddcdc at tuncreate+0xec
 | #8 0x80cdde32 at tunopen+0x22
 | #9 0x80a85710 at devfs_open+0x120
 | #10 0x81229976 at VOP_OPEN_APV+0x76
 | #11 0x80cb1ba7 at vn_open_vnode+0x1b7
 | #12 0x80cb17e6 at vn_open_cred+0x336
 | #13 0x80ca9d33 at kern_openat+0x213
 | #14 0x810a8984 at amd64_syscall+0x364
 | #15 0x81082500 at fast_syscall_common+0x101
 | Uptime: 12m13s
 | Automatic reboot in 15 seconds - press a key on the console to abort
 | --> Press a key on the console to reboot,

FreeBSD 13-CURRENT:

 | panic: make_dev_sv: bad si_name (error=17, si_name=tun5)
 | cpuid = 0
 | time = 1589763850
 | KDB: stack backtrace:
 | db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe001adf4610
 | vpanic() at vpanic+0x182/frame 0xfe001adf4660
 | panic() at panic+0x43/frame 0xfe001adf46c0
 | make_dev_sv() at make_dev_sv+0x373/frame 0xfe001adf4750
 | make_dev_s() at make_dev_s+0x3b/frame 0xfe001adf47b0
 | tun_create_device() at tun_create_device+0xde/frame 0xfe001adf4830
 | tun_clone_create() at tun_clone_create+0x119/frame 0xfe001adf4880
 | if_clone_createif() at if_clone_createif+0x4a/frame 0xfe001adf48d0
 | ifioctl() at ifioctl+0x6e3/frame 0xfe001adf49a0
 | kern_ioctl() at kern_ioctl+0x27b/frame 0xfe001adf4a00
 | sys_ioctl() at sys_ioctl+0x127/frame 0xfe001adf4ad0
 | amd64_syscall() at amd64_syscall+0x140/frame 0xfe001adf4bf0
 | fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe001adf4bf0
 | --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004933fa, rsp = 
0x7fffe288, rbp = 0x7fffe2d0 ---
 | KDB: enter: panic

 Cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] primes(6) -- remove unnecessary code

[Jamie Landeg-Jones]

Steve Kargl  wrote:

> Hmm, I withdraw the patch.  One can get a negative start 
> value, but one would need to force that condition via
> a subversion via getopt.

Or:

primes -- -1 5
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel module code coverage

[Jamie Landeg-Jones]

Eric Joyner  wrote:

> I'm reviving an ancient thread, but is Bullseye truly dropping FreeBSD
> support? Do you have a link to something that shows that?
>
> I still see a FreeBSD tarball in their download archive page for the newest
> version of their tool, which seems to be 8.16.5.

It appears that the "archive" is for older releases. The latest is 8.16.6 and
isn't listed for FreeBSD:

https://www.bullseye.com/cgi-bin/download

Cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: One True Awk upgrade

[Jamie Landeg-Jones]

Warner Losh  wrote:

> OK. I've resolved all the diffs between the git-tree I had and what made it
> into the tree. the upgrade is now complete, and I've pushed my notion of
> what awk should be to the bsd-ota branch in
> https://github.com/bsdimp/awk.git I'll work on folding them into upstream,
> although some of them are quite old and I'm unsure if they are appropriate
> for upstream...

Great! Thanks Warner.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

[Jamie Landeg-Jones]

rai...@ultra-secure.de wrote:

> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the 
> department who is technically responsible for the service gets around 
> redoing that service.

>From my understanding from reading the bug (though it's not entirely clear
in this thread), this relates to removing the options from the generic (et al.)
kernels, not deleting the code itself.

You'd therefore be able to just keep the options enabled in your own
config..  , or is this just the first stage of full deprecation?

Cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD contrib/one-true-awk now it's own fork?

[Jamie Landeg-Jones]

contrib/one-true-awk hasn't been synced with the official src maintained
by Brian Kernighan for a number of years, though in that time a number
of FreeBSD changes have been made, independently of the official branch.

Is this the official policy now? There are some useful bugfixes and changes
out there! - https://github.com/onetrueawk/awk

cheers

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r3418363: top -opid process list order is rather odd (top -Saopid example shown)

[Jamie Landeg-Jones]

> No wonder, it doesn't seem to have worked ever (?) as the compare_pid is
> simply not defined in compares list.  Try attached patch.

It works on 11-stable without that line being added.

cheers

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Suppose a user on a pilgrimage to /usr/src, modified UPDATING

[Jamie Landeg-Jones]

miltonott  wrote:

>   O great and powerful FreeBSD biome. May I redirect from here to a paste  
> site
> service, a rearrangement of development directory head file /usr/src/UPDATING.

sorry, but left & right justified text is horrible, especially with a 
monospaced font!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

[Jamie Landeg-Jones]

freebsd.curr...@clogic.com.ua wrote:

> Anyway, I think apps from ports need to use openssl from ports.

No. Only if it's installed. If not, it's perfectly normal for a port
to use the base openssl - it's not a private-lib install.

cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

kvm_swap: ksw_devname too short

[Jamie Landeg-Jones]

kvm_swap.ksw_devname is defined in  as 32 characters. It's easy to
exceed this (e.g. /dev/diskid/DISK-4C441001130129435304p2)

I suppose setting an automatic glabel would be the solution, but how much
hassle would bumping this field cause? I notice that swap with such long
names still actually works...

Cheers
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Poll: should man(1)'s default pager change to "less -s"?

[Jamie Landeg-Jones]

Alan Somers  wrote:

> Should man(1)'s default pager change to "less -s"?  Vote and flame at the
> Phabricator link below.
>
> https://reviews.freebsd.org/V7

It's probably too late to suggest a "don't mind either way" option, to at
least give a better idea on who bothers to vote.

But anyway, despite seeming to be "flying the flag" for "more", I actually
don't mind either way.

It's not because the changes won't affect me. I humbly like to think my
responses to such questions are for the overall good.

In this case, "less" is similar enough to "more" (and arguably better) that
it's not a bad change to make.

Old farts like me who prefer the old "more" can continue to set it - those who
don't care, or don't know, will not be negatively effected.

I know I'm just some random guy on the internet, but I thought I'd throw in my
2 cents as there may be others with a similar philosophy on these types of 
changes.

Cheers, Jamie

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange behavior about pattern matching on manual pages [FIXED]

[Jamie Landeg-Jones]

Alan Somers  wrote:

> > Yes, it certainly is.  Are you sure this is actually a bug in less, or is
> > it just weird-but-intended behavior when less is emulating some old version
> > of more?  It would be worth comparing our less sources to upstream's to see
> > what differences have crept in, and svn blaming them to see why.

Firstly, apologies for the delay in replying - I've been away.

I was planning on investigating further, which is why I hadn't yet formally
submitted it. Your info would have been a useful next step to follow, so cheers.

> I finally traced down the origin of this weird behavior.  It dates from
> FreeBSD r60816, which imported NetBSD's r1.6 (from CVS), which fixed NetBSD
> PR 227.  While your patch fixes the problem b...@meetlost.com reported, it
> regresses the problem described by PR 227.  So I don't think we can commit
> it as-is.

Thanks for doing that. Of course, it's fine to not apply the patch as in this 
case.

> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/less/less/Attic/forwback.c.diff?r1=1.5&r2=1.6&only_with_tag=MAIN&f=h
> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=227
>
> For reference, I'll restate a reproduction case for PR 227:
> 1) Size your terminal to 25 lines
> 2) jot 20 > ~/tmp/20lines.txt
> 3) jot 100 120 1 > /tmp/20lines.2.txt
> 4) more /tmp/20lines.*
> 5) At the prompt, press spacebar to display the second file.  The first
> file should remain in the scrollback buffer.

Thanks again. I'll check the PR's, other patches, and your test-case will help 
greatly.
I'll post again when I find a better overall solution.

Cheers! Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Makefile show all flags

[Jamie Landeg-Jones]

blubee blubeeme  wrote:

> When porting software FreeBSD has a lot of internal makefiles that gets
> pulled in that setup the build environment: /usr/ports/Mk/*
>
> Is there a way to print out the env during the make process so that I can
> see what knobs, switches and flags were set before the build is run?

Is this any use?

make -dA 

It's pretty verbose. I'd suggest running it through "script" or redirecting
stderr to a file!

cheers, jamie

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange behavior about pattern matching on manual pages [FIXED]

[Jamie Landeg-Jones]

Alan Somers  wrote:

> How about just setting MANPAGER=less in your environment?

Because some of us prefer "more"?

And as I said, it's related to searching using the more(1) command generally.

I was under the impression that fixing bugs in existing commands was a better
solution than telling someone to simply use something else.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange behavior about pattern matching on manual pages [FIXED]

[Jamie Landeg-Jones]

by  wrote:

> Hi,
>
> I encounter a problem when viewing manuals via man(1) command.
>
> The case is simple, when I try to search something, I press ‘/’, and then 
> input the pattern, If it got something in the page, it will direct me into 
> the specified place, and then, I continue with ’n’, and it goes well.
> But the problem is, after a sequence of ’n’, the screen go to the end of the 
> manual pages, and keeping press ’n’, I got annoying “...skipping...”, the 
> page is full of skipping and parts of the end of the manual page.

Yes. This has been annoying me too - your email prompted me to finally work
on a fix for it!

Firstly, it isn't man(1) itself - man(1) uses more(1) as the pager.
more(1) is in itself actually the program less(1), running in "more
emulation mode".

And less(1) isn't FreeBSD native code - it's imported into the project
from http://www.greenwoodsoftware.com/less/

I noticed the very latest version of less(1) has been checked into
freebsd-current, and the issue still occurs there.

Anyway, the fix is two small patches to less(1), please let me know
if they work for you, and if you see any bad side-effects in man(1) /
more(1) and less(1) and I'll then try and get them applied upstream.

The patches have been tested against FreeBSD 11.1-STABLE and 12-CURRENT

cheers! Jamie

--- contrib/less/forwback.c.orig2017-11-20 08:52:33.978356000 +
+++ contrib/less/forwback.c 2017-12-05 15:53:50.51755 +
@@ -255,7 +255,7 @@
 * start the display after the beginning of the file,
 * and it is not appropriate to squish in that case.
 */
-   if ((first_time || less_is_more) &&
+   if ((first_time) &&
pos == NULL_POSITION && !top_scroll && 
 #if TAGS
tagoption == NULL &&
--- contrib/less/main.c.orig2017-11-20 08:52:33.978356000 +
+++ contrib/less/main.c 2017-12-05 15:53:57.291394000 +
@@ -168,7 +168,10 @@
}
 
if (less_is_more)
+   {
no_init = TRUE;
+   scan_option("--tilde");
+   }
 
 #if EDITOR
editor = lgetenv("VISUAL");
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

getfsstat / nullsfs / automount bug?

[Jamie Landeg-Jones]

There appears to be a bug in the system call related to getmntinfo(3) / 
getfsstat(2)
, when if the "automount" flag is set on "nullfs" mounts, it is not returned on
a getfsstat "WAIT" call. The non-refreshed, non-blocking "MNT_NOWAIT" produces 
the
correct result.

I first noticed this when debugging why my nullfs autofs partitions weren't 
being
automatically unmounted. (FreeBSD current and release)

The somewhat hacked snippet from automount.c in the example below demonstrates 
this -
When called with no parameters, it performs a MNT_WAIT request, otherwise a 
MNT_NOWAIT
request is performed:

Cheers, Jamie

 | #include 
 | #include 
 | #include 
 |
 | int main(int argc, char **argv)
 | {
 |  struct statfs *mntbuf;
 |  int i, nitems;
 |
 |  nitems = getmntinfo(&mntbuf, (argc == 1) ? MNT_WAIT : MNT_NOWAIT);
 |  if (nitems <= 0)
 |  printf ("getmntinfo fail\n");
 |
 |  for (i = 0; i < nitems; i++) {
 |  if (strcmp(mntbuf[i].f_fstypename, "autofs") == 0) {
 |  printf("skipping %s, filesystem type is autofs\n",
 |  mntbuf[i].f_mntonname);
 |  continue;
 |  }
 |
 |  if ((mntbuf[i].f_flags & MNT_AUTOMOUNTED) == 0) {
 |  printf("skipping %s, not automounted\n",
 |  mntbuf[i].f_mntonname);
 |  continue;
 |  }
 |
 |  printf("%s IS automounted!\n",
 |  mntbuf[i].f_mntonname);
 |  }
 | }

 | 14:24 [2] (1) "autofs" root@thompson# df
 | Filesystem1K-blocks Used  Avail Capacity  Mounted on
 | /dev/ada1p2 5061628   707264394943615%/
 | devfs 11  0   100%/dev
 | /dev/ada1p4 5061628   535004412169611%/var
 | /dev/ada1p5   978973296 21689416  878966020 2%/usr
 |
 | 14:24 [2] (2) "autofs" root@thompson# mount
 | /dev/ada1p2 on / (ufs, local)
 | devfs on /dev (devfs, local, multilabel)
 | /dev/ada1p4 on /var (ufs, local, soft-updates)
 | /dev/ada1p5 on /usr (ufs, local, soft-updates)
 |
 | 14:25 [2] (3) "autofs" root@thompson# mkdir /tmp/automounted /tmp/manual
 |
 | 14:25 [2] (4) "autofs" root@thompson# mount -t nullfs -o ro /usr/src 
/tmp/manual
 |
 | 14:25 [2] (5) "autofs" root@thompson# mount -t nullfs -o ro,automounted 
/usr/src /tmp/automounted/
 |
 | 14:26 [2] (6) "autofs" root@thompson# df
 | Filesystem1K-blocks Used  Avail Capacity  Mounted on
 | /dev/ada1p2 5061628   707264394943615%/
 | devfs 11  0   100%/dev
 | /dev/ada1p4 5061628   535004412169611%/var
 | /dev/ada1p5   978973296 21689420  878966016 2%/usr
 | /usr/src  978973296 21689420  878966016 2%/tmp/manual
 | /usr/src  978973296 21689420  878966016 2%/tmp/automounted
 |
 | 14:26 [2] (7) "autofs" root@thompson# mount
 | /dev/ada1p2 on / (ufs, local)
 | devfs on /dev (devfs, local, multilabel)
 | /dev/ada1p4 on /var (ufs, local, soft-updates)
 | /dev/ada1p5 on /usr (ufs, local, soft-updates)
 | /usr/src on /tmp/manual (nullfs, local, read-only)
 | /usr/src on /tmp/automounted (nullfs, local, read-only, automounted)
 |
 | 14:26 [2] (8) "autofs" root@thompson# ./a.out
 | skipping /, not automounted
 | skipping /dev, not automounted
 | skipping /var, not automounted
 | skipping /usr, not automounted
 | skipping /tmp/manual, not automounted
 | skipping /tmp/automounted, not automounted
 |
 | 14:26 [2] (9) "autofs" root@thompson# ./a.out x
 | skipping /, not automounted
 | skipping /dev, not automounted
 | skipping /var, not automounted
 | skipping /usr, not automounted
 | skipping /tmp/manual, not automounted
 | /tmp/automounted IS automounted!

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Recent OBJDIR changes can cause host /etc files to leak into DESTDIR -- Fixed in r325416

[Jamie Landeg-Jones]

Somewhat related, (I think!) "make LINT" in the kernel-config directory
no longer works as expected unless MAKEOBJDIRPREDIX=/ is set, i.e.:

cd /usr/src/sys/ARCH/conf/ && make MAKEOBJDIRPREFIX=/ LINT

cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: swapfile query

[Jamie Landeg-Jones]

> 3. should total swap be 1x 2x or some other multiple of RAM these days?

According to tuning(7) :

| SYSTEM SETUP - DISKLABEL, NEWFS, TUNEFS, SWAP
|   The swap partition should typically be approximately 2x the size of
|   main memory for systems with less than 4GB of RAM, or approximately
|   equal to the size of main memory if you have more. Keep in mind
|   future memory expansion when sizing the swap partition.

cheers, Jamie

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BSD awk bug ?

[Jamie Landeg-Jones]

KIRIYAMA Kazuhiko  wrote:

> Oops. I missed "STANDARDS" section. Thanks for pointed out.
>
> # But as it says in front "awk supports extended regular
> # expressions (EREs).  See re_format(7) for more information
> # on regular expressions.", I'd like to coinside with
> # re_format(7) spec.
>
> > 
> > Someone please correct me if I'm wrong.

I agree. It's a pain in the arse. In these situations, I've had to use gawk 
instead (You can set POSIXLY_CORRECT in gawk if it helps you feel cleaner! :-) )

There is also 'mawk' in ports/lang, but I've never tried that.

Cheers, Jamie

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to SVN regenerate [ man awk ]

[Jamie Landeg-Jones]

"Jeffrey Bouquet"  wrote:

> > If you intend to use "svn up", you should probably review, and
> > follow the instructions in, /usr/src/UPDATING.
>
> but just for one binary?  and one man page update? 
> As in, it is only two files, how to update singly if does not require a 
> buildworld...

I've no idea what is causing your current problem, but it's perfectly fine to 
do:

cd /usr/src/usr.bin/awk (for example)
make
make install
make clean
make cleandepends

I do this kind of thing all the time. Obvious caveats apply:

1) You are no longer tracking a "standard" installation.
2) You may create a problem with mismatched versions of things.
3) Relating to 2), some things may not compile or work as intended due
   to changes elsewhere that would need to also be applied to the system.

But other than that, things should work (to use your example, awk should work 
fine)

Are you doing the 'make install' rather than installing manually?

cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r286615: /usr/libexec/ftpd broken!

[Jamie Landeg-Jones]

Marcel Moolenaar  wrote:

> It would have been so nice if man(1) would have told you that there
> were 2 ftpd manpages and that you need to specify which one you want.
> That should raise an eyebrow right away...

I was bitten by a similar issue in the past. I now alias 'man' to 'man -a':

-a  Display all manual pages instead of just the first found for each
page argument.

cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default

[Jamie Landeg-Jones]

Xin Li  wrote:

> > I was going to suggest this too. Isn't this information available 
> > using /bin/freebsd-version -u ?
>
> Client side: yes.
>
> Server side: someone has to tell the server to start building for new
> - -CURRENT or stop building for old -STABLE.

Ahhh! Gotcha! Thanks for the quick response. I'll stop bike-shedding now!

Cheers,
Jamie
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"