termcap.db unused?

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

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

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"?

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

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

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

Re: noatime on ufs2

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

Re: noatime on ufs2

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.

Re: git repo port issues?

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

Re: git repo port issues?

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

Re: git repo port issues?

ork 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 > > g

Re: git repo port issues?

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

Re: git repo ports issues?

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?

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

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

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

> 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

Re: Freebsd 14+ -- tcsh incompatible with terminfo

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

Re: Freebsd 14+ -- tcsh incompatible with terminfo

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

Re: Freebsd 14+ -- tcsh incompatible with terminfo

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

Re: Freebsd 14+ -- tcsh incompatible with terminfo

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

Re: Freebsd 14+ -- tcsh incompatible with terminfo

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-256colo

Freebsd 14+ -- tcsh incompatible with terminfo

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

Re: grep(1) bug - duplicate output lines

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

Re: grep(1) bug - duplicate output lines

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

Re: grep(1) bug - duplicate output lines

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 >

grep(1) bug - duplicate output lines

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 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 per

Re: changes to ps -d?

> 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

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

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

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

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

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

Re: ps(1) bugs and problems

"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

Re: ps(1) bugs and problems

"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 >

ps(1) bugs and problems

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

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

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

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

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

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

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

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

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

Re: find(1): I18N gone wild ?

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 ?

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 ?

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

Re: find(1): I18N gone wild ?

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 fo

Re: find(1): I18N gone wild ?

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

Re: find(1): I18N gone wild ?

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

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

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

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

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

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

diff(1) goes into cpu-hogging endless loop

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

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

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

Re: 1 year src-patch anniversary!

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

Re: 1 year src-patch anniversary!

"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

Re: 1 year src-patch anniversary!

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.

1 year src-patch anniversary!

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

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

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

Re: FreeBSD is a great operating system!

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

Re: recover deleted file

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

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

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

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

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

Re: USB Disk Stalls on -current

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

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

> 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

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

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. > > > >

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

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

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

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

[patch] touch(1) enhancement

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

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

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

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

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 >

Re: stat(1) isn't honouring locale

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

stat(1) isn't honouring locale

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

Re: killall, symlinks, and signal delivery?

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

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

"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

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

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,

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

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,

Re: Git: timestamps

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

Re: git non-time-sequential logs

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

Re: git non-time-sequential logs

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

Re: again this ugly graphic driver sloopy mistake

"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

Re: CFT for vendor openzfs - week 2 reminder

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

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

>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

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

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

Re: kernel module code coverage

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

Re: One True Awk upgrade

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, >

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

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

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

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

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

> 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

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

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!

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

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 ___

kvm_swap: ksw_devname too short

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

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

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

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

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

Re: Makefile show all flags

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

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

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

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

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

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

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

Re: swapfile query

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

Re: BSD awk bug ?

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: how to SVN regenerate [ man awk ]

"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

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

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

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

Xin Li delp...@delphij.net 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

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

Xin Li delp...@delphij.net wrote: On 8/6/15 22:24, Kevin Oberman wrote: Or the code in portsnap could be modified to get the current running version. I thought about this today but it won't work as advertised: someone (currently me) still have to tweak the portsnap builder configuration

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

Kevin Oberman rkober...@gmail.com wrote: Isn't rebuilding the index useful for people running STABLE? I assume that I need a current index to get useful output from pkg version -vL=. I am probably a bit unusual in that I keep a current ports tre on a STABLE system, but there are a couple of

Re: broken symbolic links in /usr/lib

Gary Palmer gpal...@freebsd.org wrote: As best that I can recall, the permissions of the directory underneath the mount point has been causing problems like this for as long as I've been using FreeBSD, which is over 20 years at this point. It's certainly bit me in the distant past. I

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

Oliver Pinter oliver.pin...@hardenedbsd.org wrote: On 7/8/15, O'Connor, Daniel dar...@dons.net.au wrote: In defence of the test, the man page says it can return EFAULT. That's fine, but why changed the behaviour since 2015. May 27.? I have an older FreeBSD/HardenedBSD install, where this

  1   2   >