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

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: 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 https://list

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 t

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 re

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: android bsd connectivity tools etc ?

"Julian H. Stacey" wrote: Firstly, if you haven't already, I'd recommend 'Android terminal emulator' and 'hackers keyboard' - both free from the Play store. To be able to create startup scripts without reflashing etc. you must have root, and be able to write the file "/system/etc/install_recover

Re: Devops question: unattended installs of FreeBSD?

Craig Rodrigues wrote: > I had a devops person who is familiar with setting up hundreds of > Linux nodes in cloud environment ask me what is the best way > to do unattended installs in a cloud environment. > Linux has kickstart installs, which are quite useful and popular. > > What is the equival

Re: DigitalOcean offers VMs with FreeBSD!

Bernhard Fröhlich wrote: > I had a quick look at it and the result is > quite poor considering the time it took them to get it done. > > They had to install quite a few packages (perl, python27, libX11, avahi > ...) and modified the stock FreeBSD image quite a bit. At startup they send > an arpin

Re: default pager (csh)

"Jeffrey Bouquet" wrote: > PAGER='cat' > alias man='env PAGER=lookat man $1' No need to alias 'man', just set env MANPAGER. >From man man: (so good they named it twice etc.!) -P pager Use specified pager. Defaults to 'less -s' if color support is enabled, or 'more -s'. Over

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

Oliver Pinter wrote: > On 7/8/15, O'Connor, Daniel 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 test passing. See > some previous email

Re: "broken" symbolic links in /usr/lib

Gary Palmer 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 concur. I always make

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

Kevin Oberman 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 ports that I ne

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

Xin Li 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 > to announce

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

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 qui

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 'man -a': -a Disp

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 require a > buildworld... I've n

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_format(7) spec. > > >

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

Re: Change top's notion of idle processes / threads

John, the changes are good. The "'trickling' but still not idle" processes now show up as they should. However, it has exposed one quirk in the display: Sorting is done by WCPU followed by total processor time. Processes which aren't idle (but are using so little cpu it shows as 0.00%) show bel

Re: Change top's notion of idle processes / threads

John Baldwin wrote: > Yes, I actually started by sorting on the raw delta and ended up going back > and fixing > pctcpu instead. However, there is a problem in this case which is that you > still want to fall back to ki_pctcpu if you don't have a valid previous delta > to compare against. It's

Re: freebsd and utf-8 directory names

M&S - Krasznai Andr??s wrote: > xfe display the file and directory names correctly together with creation > date and time (simple 'ls' does not; it shows double question marks in the > place of Hungarian characters. > > ls | od -c > > shows that such characters are represented in ls output a

Re: freebsd and utf-8 directory names

Kevin Lo wrote: > Well, I'm going to close that PR. :-) > [ ... ] I basically replied with the same thing in a followup on the bug itself exactly 24 hours ago! :-) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 cheers, Jamie ___ freebsd-c

Re: android bsd connectivity tools etc ?

Shane Ambler wrote: > da0 at umass-sim1 bus 1 scbus5 target 0 lun 0 > da0: < Android Adapter 0100> Removable Direct Access SCSI-2 device > cd1 at umass-sim1 bus 1 scbus5 target 0 lun 1 > cd1: < Android Adapter 0100> Removable CD-ROM SCSI-2 device > da1 at umass-sim1 bus 1 scbus5 target 0 lun 2 >

Re: android bsd connectivity tools etc ?

"Julian H. Stacey" wrote: > Hi, > Any tips for Android / FreeBSD BSD tools for connectivity etc ? I mainly use nfs / ssh (dropbear) / scp for connectivity over IPv6 to my local FreeBSD server. It works quite well - I even have automated cron rsync deduped backups! NFS is used for mounting my me

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 name

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.

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 d

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 be

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

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 successfu

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

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

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

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 /

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 ?

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 ?

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

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 s

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

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

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 ar

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 sp

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

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 opt

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 d

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 etcupda

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

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

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

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 | # @(#)COPYRIG

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

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 A

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

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 Ech

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

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 ta

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 on

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 r

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.

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 t

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

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 decentralisa

Re: git repo port issues?

g 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

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 as

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 drop

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

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

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

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 use

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

getfsstat / nullsfs / automount bug?

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 debugg

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 continue with ’n’, and

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 solution than telling som

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 were set before the bui

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 differences have crept in, and

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 vote. But anyway, desp

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 work

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 th

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 https://lists.freebsd.org

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 Fre

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 https://lists.freebsd.org/

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

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 trans

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

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

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 i

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 a

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: 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 20f83

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

  1   2   >