Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[Baptiste Daroussin]

Le 9 avril 2024 18:06:12 GMT+02:00, FreeBSD User  a 
écrit :
>Am Tue, 9 Apr 2024 17:10:52 +0200
>Rainer Hurling  schrieb:
>
>> Am 09.04.24 um 09:20 schrieb Baptiste Daroussin:
>> > On Sat 06 Apr 09:23, Rainer Hurling wrote:  
>> >> Am 06.04.24 um 09:05 schrieb FreeBSD User:  
>> >>> Hello,
>> >>>
>> >>> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 
>> >>> 1.21.0 on CURRENT
>> >>> and 14-STABLE, I can't update several ports:
>> >>>
>> >>> www/apache24
>> >>> databases/redis
>> >>>
>> >>> pkg core dumps while performing installation. apache24 and redis are 
>> >>> ports I realized
>> >>> this misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants 
>> >>> latest builds,
>> >>> i.e. FreeBSD 15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr  5 
>> >>> 20:30:39 CEST 2024
>> >>> amd64).
>> >>>
>> >>> After some updates on a poudriere builder (CURRENT base host, 
>> >>> 14.0-RELENG jail with
>> >>> poudriere) building packages for 14.0-RELENG, I observed the same 
>> >>> behaviour when
>> >>> updating packages on target hosts where pkg is first updated, on those 
>> >>> hosts,
>> >>> nextcloud-server and icinga2 host utilizing also databases/redis and 
>> >>> www/apache24, pkg
>> >>> fails the same way.
>> >>>
>> >>> I do not dare to update our poudriere hosts since the problem seems to 
>> >>> pop up when pkg
>> >>> 1.21.0 is installed, no matter whether I use poudriere built ports (from 
>> >>> our own builder
>> >>> hosts) or recent source tree with portmaster/make build process.
>> >>>
>> >>> Looks like a serious bug to me and not a site/user specific problem. 
>> >>> Hopefully others do
>> >>> realize the same ...
>> >>>
>> >>> Thanks in advance,
>> >>>
>> >>> oh  
>> >>
>> >>
>> >> Hmm, I just tried to reproduce that. Both ports mentioned, databases/redis
>> >> and www/apache24, can be built and installed with Portmaster. The box is a
>> >> 15.0-CURRENT with pkg-1.21.0.
>> >>
>> >> Maybe 'pkg check -Bn' or 'portmaster --check-depends --check-port-dbdir'
>> >> show some inconsistencies?
>> >>
>> >> Best wishes,
>> >> Rainer
>> >>
>> >>  
>> > using portmaster or not are strictly unlikely to be helpful here.
>> > 
>> > The right way to test if to report running with pkg - and also to 
>> > recommand
>> > testing with default options in pkg.conf.
>> > 
>> > Best regards,
>> > Bapt  
>> 
>> This is correct and certainly better. I was not aware of this.
>> 
>> Fortunately, my less optimal suggestions helped O. Hartmann in this case 
>> to find the missing and outdated dependencies.
>> 
>> In any case, many thanks for this helpfull advice.
>> 
>> Regards,
>> Rainer
>> 
>> 
>
>Hello,
>
>@Babptist : it should be pkg -d, shouldn't it? Or do I miss again something 
>here?

Each d will provide a more verbose level of debug

Bapt

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[Baptiste Daroussin]

On Sat 06 Apr 09:23, Rainer Hurling wrote:
> Am 06.04.24 um 09:05 schrieb FreeBSD User:
> > Hello,
> > 
> > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 
> > 1.21.0 on CURRENT and
> > 14-STABLE, I can't update several ports:
> > 
> > www/apache24
> > databases/redis
> > 
> > pkg core dumps while performing installation. apache24 and redis are ports 
> > I realized this
> > misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants latest 
> > builds, i.e. FreeBSD
> > 15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr  5 20:30:39 CEST 2024 
> > amd64).
> > 
> > After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG 
> > jail with poudriere)
> > building packages for 14.0-RELENG, I observed the same behaviour when 
> > updating packages on
> > target hosts where pkg is first updated, on those hosts, nextcloud-server 
> > and icinga2 host
> > utilizing also databases/redis and www/apache24, pkg fails the same way.
> > 
> > I do not dare to update our poudriere hosts since the problem seems to pop 
> > up when pkg 1.21.0
> > is installed, no matter whether I use poudriere built ports (from our own 
> > builder hosts) or
> > recent source tree with portmaster/make build process.
> > 
> > Looks like a serious bug to me and not a site/user specific problem. 
> > Hopefully others do
> > realize the same ...
> > 
> > Thanks in advance,
> > 
> > oh
> 
> 
> Hmm, I just tried to reproduce that. Both ports mentioned, databases/redis
> and www/apache24, can be built and installed with Portmaster. The box is a
> 15.0-CURRENT with pkg-1.21.0.
> 
> Maybe 'pkg check -Bn' or 'portmaster --check-depends --check-port-dbdir'
> show some inconsistencies?
> 
> Best wishes,
> Rainer
> 
> 
using portmaster or not are strictly unlikely to be helpful here.

The right way to test if to report running with pkg - and also to recommand
testing with default options in pkg.conf.

Best regards,
Bapt

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[Baptiste Daroussin]

On Sat 06 Apr 09:05, FreeBSD User wrote:
> Hello,
> 
> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 
> on CURRENT and
> 14-STABLE, I can't update several ports:
> 
> www/apache24
> databases/redis
> 
> pkg core dumps while performing installation. apache24 and redis are ports I 
> realized this
> misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants latest 
> builds, i.e. FreeBSD
> 15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr  5 20:30:39 CEST 2024 
> amd64).
> 
> After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG 
> jail with poudriere)
> building packages for 14.0-RELENG, I observed the same behaviour when 
> updating packages on
> target hosts where pkg is first updated, on those hosts, nextcloud-server and 
> icinga2 host
> utilizing also databases/redis and www/apache24, pkg fails the same way.
> 
> I do not dare to update our poudriere hosts since the problem seems to pop up 
> when pkg 1.21.0
> is installed, no matter whether I use poudriere built ports (from our own 
> builder hosts) or
> recent source tree with portmaster/make build process.
> 
> Looks like a serious bug to me and not a site/user specific problem. 
> Hopefully others do
> realize the same ...
> 
> Thanks in advance,
> 
> oh 
> 
https://github.com/freebsd/pkg/issues/2270

set HANDLE_RC_SCRIPTS=false in your pkg.conf

a Fix was made last friday, given this is a non default option I waited for the
Week end to pass to see if there were other regressions, but no more reports so
I will issue a pkg 1.21.1 now.

Best regards,
Bapt

Re: Radius challenges in FreeBSD 14.0 Re: FreeBSD 14.0-RC4 Now Available

[Baptiste Daroussin]

On Mon, Nov 06, 2023 at 08:27:34AM -0700, The Doctor wrote:
> On Mon, Nov 06, 2023 at 09:50:18AM +0100, Baptiste Daroussin wrote:
> > On Mon, Nov 06, 2023 at 09:04:15AM +0100, Baptiste Daroussin wrote:
> > > On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote:
> > > > On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote:
> > > > > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> > > > > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote:
> > > > > > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote:
> > > > > > > > The fourth RC build of the 14.0-RELEASE release cycle is now 
> > > > > > > > available.
> > > > > > > > 
> > > > > > > > Installation images are available for:
> > > > > > > > 
> > > > > > > > o 14.0-RC4 amd64 GENERIC
> > > > > > > > 
> > > > > > > >
> > > > > > > 
> > > > > > > I am having a problem witb Freeradius and GNU radius. 
> > > > > > > 
> > > > > > > Anyone else?
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > I found the problem.  Replace /usr/lib/libncursesw.so as a symbolic
> > > > > > link to /lib/libncursesw.so.9
> > > > > 
> > > > > can you provide more inputs here, please where do you get your 
> > > > > freeradious or
> > > > > gnu radius implementation from, what is failing an so on?
> > > > > 
> > > > > Best regards,
> > > > > Bapt
> > > > 
> > > > freeradius looks like a TLS issue with openssl 3
> > > > 
> > > > .
> > > > 
> > > > gnu Radius was biuld by me and not a port.
> > > > 
> > > > Trying to recode is a challenge.
> > > > 
> > > > What is happening is that 
> > > > 
> > > > the so file is not being recognised so
> > > > I have to symlink in order to get GNU radius 1.6.X to work .
> > > > 
> > > > It will work with /lib/libncursesw.so.9 if the so file is found in 
> > > > /usr/lib .
> > > 
> > > OK I will dig into gnu-radius, and fix the port if needed! thank you
> > > 
> > > Best regards,
> > > Bapt
> > 
> > I just checked here, and I built gnu-radius on a vanilla freebsd 14.0 rc4 
> > and a
> > vanilla 15 current, and in both case it perfectly links to libncursesw.so.9 
> > and
> > does not require any change of the .so, at least from all the binary 
> > analysis
> > that I have done, do you have a specific command that will expose the issue?
> > 
> > Can you provide me you gnu-radius package as created by pkg create 
> > gnu-radius ?
> > 
> > Best regards,
> > Bapt
> 
> Try to build from ports, here is what I get
> 
> cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include 
> -I../include/radius -I../include/radius -I../lib -I../gnu -I../gnu 
> -I/usr/local/include/guile/1.8 -I/usr/local/include -isystem 
> /usr/local/include -D_THREAD_SAFE  -DSYSCONFDIR=\"/usr/local/etc\" 
> -DRADPID_DIR=\"/var/run\" -DRADLOG_DIR=\"/var/log\" 
> -DRADIUS_DATADIR=\"/usr/local/share/radius/1.6.1\" 
> -DRADIUS_LIBDIR=\"/usr/local/lib/radius/1.6.1\" -I/usr/local/include/ 
> -I/usr/local/include -fno-strict-aliasing -O2 -pipe  -fstack-protector-strong 
> -fno-strict-aliasing  -MT builddbm.o -MD -MP -MF .deps/builddbm.Tpo -c -o 
> builddbm.o builddbm.c
> builddbm.c:101:13: warning: call to undeclared function 'grad_dbm_insert'; 
> ISO C99 and later do not support implicit function declarations 
> [-Wimplicit-function-declaration]
> if (grad_dbm_insert(closure->dbmfile, named, contentd)) {
>   ^
>   builddbm.c:141:13: warning: call to undeclared function 
> 'grad_dbm_create'; ISO C99 and later do not support implicit function 
> declarations [-Wimplicit-function-declaration]
>   if (grad_dbm_create(db_file, )) {
>   ^
>   builddbm.c:147:39: error: incompatible 
> function pointer types passing 'int (DBM_closure *, User_symbol *)' (aka 'int 
> (DBM_closure *, struct user_symbol *)') to parameter of type 'int (*)(void *, 
> grad_symbol_t *)' (aka 'int (*)(void *, struct symbol *)') 
&g

Re: Radius challenges in FreeBSD 14.0 Re: FreeBSD 14.0-RC4 Now Available

[Baptiste Daroussin]

On Mon, Nov 06, 2023 at 09:04:15AM +0100, Baptiste Daroussin wrote:
> On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote:
> > On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote:
> > > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> > > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote:
> > > > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote:
> > > > > > The fourth RC build of the 14.0-RELEASE release cycle is now 
> > > > > > available.
> > > > > > 
> > > > > > Installation images are available for:
> > > > > > 
> > > > > > o 14.0-RC4 amd64 GENERIC
> > > > > > 
> > > > > >
> > > > > 
> > > > > I am having a problem witb Freeradius and GNU radius. 
> > > > > 
> > > > > Anyone else?
> > > > > 
> > > > > 
> > > > 
> > > > I found the problem.  Replace /usr/lib/libncursesw.so as a symbolic
> > > > link to /lib/libncursesw.so.9
> > > 
> > > can you provide more inputs here, please where do you get your 
> > > freeradious or
> > > gnu radius implementation from, what is failing an so on?
> > > 
> > > Best regards,
> > > Bapt
> > 
> > freeradius looks like a TLS issue with openssl 3
> > 
> > .
> > 
> > gnu Radius was biuld by me and not a port.
> > 
> > Trying to recode is a challenge.
> > 
> > What is happening is that 
> > 
> > the so file is not being recognised so
> > I have to symlink in order to get GNU radius 1.6.X to work .
> > 
> > It will work with /lib/libncursesw.so.9 if the so file is found in 
> > /usr/lib .
> 
> OK I will dig into gnu-radius, and fix the port if needed! thank you
> 
> Best regards,
> Bapt

I just checked here, and I built gnu-radius on a vanilla freebsd 14.0 rc4 and a
vanilla 15 current, and in both case it perfectly links to libncursesw.so.9 and
does not require any change of the .so, at least from all the binary analysis
that I have done, do you have a specific command that will expose the issue?

Can you provide me you gnu-radius package as created by pkg create gnu-radius ?

Best regards,
Bapt

Re: Radius challenges in FreeBSD 14.0 Re: FreeBSD 14.0-RC4 Now Available

[Baptiste Daroussin]

On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote:
> On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote:
> > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote:
> > > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote:
> > > > > The fourth RC build of the 14.0-RELEASE release cycle is now 
> > > > > available.
> > > > > 
> > > > > Installation images are available for:
> > > > > 
> > > > > o 14.0-RC4 amd64 GENERIC
> > > > > 
> > > > >
> > > > 
> > > > I am having a problem witb Freeradius and GNU radius. 
> > > > 
> > > > Anyone else?
> > > > 
> > > > 
> > > 
> > > I found the problem.  Replace /usr/lib/libncursesw.so as a symbolic
> > > link to /lib/libncursesw.so.9
> > 
> > can you provide more inputs here, please where do you get your freeradious 
> > or
> > gnu radius implementation from, what is failing an so on?
> > 
> > Best regards,
> > Bapt
> 
> freeradius looks like a TLS issue with openssl 3
> 
> .
> 
> gnu Radius was biuld by me and not a port.
> 
> Trying to recode is a challenge.
> 
> What is happening is that 
> 
> the so file is not being recognised so
> I have to symlink in order to get GNU radius 1.6.X to work .
> 
> It will work with /lib/libncursesw.so.9 if the so file is found in 
> /usr/lib .

OK I will dig into gnu-radius, and fix the port if needed! thank you

Best regards,
Bapt

Re: FreeBSD 14.0-RC4 Now Available

[Baptiste Daroussin]

On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote:
> > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote:
> > > The fourth RC build of the 14.0-RELEASE release cycle is now available.
> > > 
> > > Installation images are available for:
> > > 
> > > o 14.0-RC4 amd64 GENERIC
> > > o 14.0-RC4 i386 GENERIC
> > > o 14.0-RC4 powerpc GENERIC
> > > o 14.0-RC4 powerpc64 GENERIC64
> > > o 14.0-RC4 powerpc64le GENERIC64LE
> > > o 14.0-RC4 powerpcspe MPC85XXSPE
> > > o 14.0-RC4 armv7 GENERICSD
> > > o 14.0-RC4 aarch64 GENERIC
> > > o 14.0-RC4 aarch64 RPI
> > > o 14.0-RC4 aarch64 PINE64
> > > o 14.0-RC4 aarch64 PINE64-LTS
> > > o 14.0-RC4 aarch64 PINEBOOK
> > > o 14.0-RC4 aarch64 ROCK64
> > > o 14.0-RC4 aarch64 ROCKPRO64
> > > o 14.0-RC4 riscv64 GENERIC
> > > o 14.0-RC4 riscv64 GENERICSD
> > > 
> > > Note regarding arm SD card images: For convenience for those without
> > > console access to the system, a freebsd user with a password of
> > > freebsd is available by default for ssh(1) access.  Additionally,
> > > the root user password is set to root.  It is strongly recommended
> > > to change the password for both users after gaining access to the
> > > system.
> > > 
> > > Installer images and memory stick images are available here:
> > > 
> > > https://download.freebsd.org/releases/ISO-IMAGES/14.0/
> > > 
> > > The image checksums follow at the end of this e-mail.
> > > 
> > > If you notice problems you can report them through the Bugzilla PR
> > > system or on the -stable mailing list.
> > > 
> > > If you would like to use Git to do a source based update of an existing
> > > system, use the "releng/14.0" branch.
> > > 
> > > A summary of changes since 14.0-RC3 includes:
> > > 
> > > o ISA and GIANT-locked driver removal has been delayed to FreeBSD 15,
> > >   and system messages have been updated to reflect such.
> > > 
> > > o An update to OpenZFS correcting block cloning between encrypted and
> > >   unencrypted datasets has been included.
> > > 
> > > o A fix for Hyper-V emulation within QEMU resulting in system crashes
> > >   has been addressed.
> > > 
> > > A list of changes since 13.2-RELEASE is available in the releng/14.0
> > > release notes:
> > > 
> > > https://www.freebsd.org/releases/14.0R/relnotes/
> > > 
> > > Please note, the release notes page is not yet complete, and will be
> > > updated on an ongoing basis as the 14.0-RELEASE cycle progresses.
> > > 
> > > === Virtual Machine Disk Images ===
> > > 
> > > VM disk images are available for the amd64, i386, and aarch64
> > > architectures.  Disk images may be downloaded from the following URL
> > > (or any of the FreeBSD download mirrors):
> > > 
> > > https://download.freebsd.org/releases/VM-IMAGES/14.0-RC4/
> > > 
> > > BASIC-CI images can be found at:
> > > 
> > > https://download.freebsd.org/releases/CI-IMAGES/14.0-RC4/
> > > 
> > > The partition layout is:
> > > 
> > > ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
> > > ~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
> > > ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)
> > > 
> > > The disk images are available in QCOW2, VHD, VMDK, and raw disk image
> > > formats.  The image download size is approximately 135 MB and 165 MB
> > > respectively (amd64/i386), decompressing to a 21 GB sparse image.
> > > 
> > > Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
> > > loader file is needed for qemu-system-aarch64 to be able to boot the
> > > virtual machine images.  See this page for more information:
> > > 
> > > https://wiki.freebsd.org/arm64/QEMU
> > > 
> > > To boot the VM image, run:
> > > 
> > > % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
> > >   -bios QEMU_EFI.fd -serial telnet::,server -nographic \
> > >   -drive if=none,file=VMDISK,id=hd0 \
> > >   -device virtio-blk-device,drive=hd0 \
> > >   -device virtio-net-device,netdev=net0 \
> > >   -netdev user,id=net0
> > > 
> > > Be sure to replace "VMDISK" with the path to the virtual machine image.
> > > 
> > > === Amazon EC2 AMI Images ===
> > > 
> > > FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
> > > Parameter Store in each region using the keys:
> > > 
> > >   /aws/service/freebsd/amd64/base/ufs/14.0/RC4
> > >   /aws/service/freebsd/amd64/base/zfs/14.0/RC4
> > >   /aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC4
> > >   /aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC4
> > > 
> > > FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager
> > > Parameter Store in each region using the keys:
> > > 
> > >   /aws/service/freebsd/aarch64/base/ufs/14.0/RC4
> > >   /aws/service/freebsd/aarch64/base/zfs/14.0/RC4
> > >   /aws/service/freebsd/aarch64/cloud-init/ufs/14.0/RC4
> > >   /aws/service/freebsd/aarch64/cloud-init/zfs/14.0/RC4
> > > 
> > > === Vagrant Images ===
> > > 
> > > FreeBSD/amd64 images are available 

Re: Freebsd 14+ -- tcsh incompatible with terminfo

[Baptiste Daroussin]

On Wed, Nov 01, 2023 at 03:49:33AM +, Jamie Landeg-Jones wrote:
> 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

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.

Best regards,
Bapt

Re: The dma mess

[Baptiste Daroussin]

On Mon, Dec 05, 2022 at 07:42:29AM -0800, Steve Kargl wrote:
> If one has not seen Mike Karel's email, here's the URL.
> 
> https://lists.freebsd.org/archives/dev-commits-src-main/2022-December/011300.html
> 
> The upshot is 
> 
> 1) No entry in src/UPDATING about dma replacing sendmail, and thereby
>breaking a function system on upgrade.

Fixed
> 
> 2) Having sendmail_enable="YES" in /etc/rc.conf no longer works
>after an upgrade, because dma replaces /etc/mail/mailer.conf.
>sendmail appears to start, but exits immediately.  One needs
>to go through a serious of git commits to find out about this
>easter egg.

It does again.
> 
> 3) It seems that now one must also add
> 
>sendmail_submit_enable="YES"
>sendmail_msp_queue_enable="YES"
>sendmail_outbound_enable="YES"
> 
>to rc.conf to recover a functioning sendmail.

Not anymore.

Bapt

Re: Posting netiquette: HTML, attachments etc.

[Baptiste Daroussin]

On Sun, Jun 26, 2022 at 12:32:41PM -0600, Warner Losh wrote:
> On Sun, Jun 26, 2022, 12:20 PM Walter Parker  wrote:
> 
> > So, utf-8 is good, posting to multiple lists is bad (but ok when you do
> > it), what about the original post? He was asking about HTML. UTF-8 != HTML.
> > UTF is a character encoding format. It is supported by most email clients
> > and does not require HTML for support.
> >
> 
> Html is fine as well. Most modern mail platforms generate it for you,
> whether you want them too or not. Most of the advice in appendix c is dated
> and doesn't really match what people do on the lists. Phones and web based
> Gmail are to large a presence to ignore or have policies against. I stopped
> listening to complaints about how Gmail or my phone formatted posts 5 years
> ago... and I'm definitely an old school straggler...
> 
> Warner
> 

Note that the mailing list engine will reject html only email, html is fine as
long at it is created with text/plain alternative.

Note that only the text/plain alternative will be used to construct the archive,
and I will not ever work on trying to render properly an html only formatted
thing via the archiver, it will require too many escaping and madness to be done
safely, I will simply drop the ball to someone else here ;)

bapt

Re: Posting Netiquette [ref: Threads "look definitely like" unreadable mess. Handbook project.]

[Baptiste Daroussin]

Le 24 juin 2022 18:19:49 GMT+02:00, Chris  a écrit :
>On 2022-06-23 01:14, grarpamp wrote:
 the “> ;† and leave empty lines between your text and the original
>> 
>>> Seems there is a charset mismatch.
>>> MUA displaying nonsense
>>> Oh the joy of UTF-8... ;-)
>> 
>> https://unicode-table.com/en/sets/quotation-marks/
>> 
>> The pages ...
>> 
>> https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail
>> https://docs.freebsd.org/en/articles/freebsd-questions/
>> https://docs.freebsd.org/en/articles/mailing-list-faq/
>> 
>> ... are intermixing standard ASCII double quotes with questionably
>> gratuitous choice of using left and right double quotes via UTF-8,
>> which then may get slaughtered by non UTF-8 enabled cut-paste,
>> systems, lists, gui's, desktops, apps, and MUAs along the way.
>> 
>...
>> A proper page would need to add a number of the missing
>> email formatting netiquettes (such as no HTML), and actual
>> photo examples of former bad chaos and new good result, etc...
>> to be considered a good format, subject, and addressing
>> netiquette guide rule page.
>> 
>> Consider if "FreeBSD Articles" is best hier for a page that
>> may becoming more often directly linked or included into
>> prospective list user's signup clickstream, quarterly admin,
>> friendly cluebat hints, etc.
>> 
>What is the possibility of getting the/a "netiquette" link in
>the FreeBSD Mailinglist footer that is already appended to all
>the messages? This would only be a small addition, with a quick/
>easy reference to the subject at hand.
>
>Just my .2¢
>
>Chris

Resending with my address which is subscribed to the lists ;)

The possibility is none it will break dkim signature, we should not alter 
emails beside their headers.

Best regards,
Bapt

Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Baptiste Daroussin]

On Wed, Apr 27, 2022 at 08:47:26PM -0700, Chris wrote:
> On 2022-04-27 20:40, Michael Schuster wrote:
> > Chris,
> > 
> > thx for your response. However 
> > 
> > On Thu, Apr 28, 2022 at 4:19 AM Chris  wrote:
> > > 
> > > On 2022-04-27 12:59, Michael Schuster wrote:
> > > > Hi,
> > > >
> > > > $subject happened to me just now on current. I researched it on the
> > > > internet, the answer to this issue seems to be a universal "uninstall
> > > > and install the package" which seems to have worked in all cases I saw
> > > > it suggested.
> > > >
> > > > I'm trying to embed this command into a script and would like to avoid
> > > > manual intervention (I have to admit, this is the first time I've
> > > > encountered this error in the two years I've been doodling with
> > > > FreeBSD again) ...
> > > > Is anything more known about this error behaviour, and what I can do
> > > > to avoid it?
> > > >
> > > > TIA
> > > > Michael
> > > >
> > > > PS: in case it matters: the full path shown in the error message is
> > > > /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG,
> > > > the package being extracted is grantleetheme-22.04.0
> > > This looks more a case for the Maintainer of the GrantleeTheme than for
> > > current@
> > 
> >  ... maybe. OTOH, the instances I found mentioned on the 'net are all
> > about different packages:
> > 
> > eg:
> > https://forums.freebsd.org/threads/pkg-upgrade-fail-to-create-temporary-file.67923/
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237767
> > 
> > I feel there's something different at work here than just one
> > maintainer's oversight.
> You may well be correct. On the surface, to me it looked like a port problem
> so I thought
> you might get quicker results via it's maintainer. :-)
> 
> Good luck! :-)
> > 
> > Thx
> > Michael

It is 2 things, it is a port problem of maintainers who do not check for
upgradability of their packages, and it can also been seen as something pkg can
deal with, but a complicated case, so I don't know yet how.

The main issue is a file in vX which becomes a directory in vX+1 which goes in
the way pkg does extract files to be as atomic as possible.

Best regards,
Bapt

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

[Baptiste Daroussin]

On Sun, Jan 30, 2022 at 11:25:54PM +0100, Dag-Erling Smørgrav wrote:
> Ed Maste  writes:
> > I am interested in determining whether dma is a viable minimal base
> > system MTA, and if not what gaps remain.
> 
> It cannot.  Ask bapt@ who was the one to import it, and later abandon
> the idea of making it our default MTA.  The reason was that it does not
> have a default domain setting, so it cannot handle email from cron,
> periodic etc. where the recipient is just a user name (usually “root”),
> and the devs were not willing to add that feature.  I have email as far
> back as 2015 on the subject.
> 
This has been fixed since. (not by me)

Bapt

[HEADSUP] Deprecation of the ftp support in pkg

[Baptiste Daroussin]

Hello everyone,

We plan to remove the support for fetching packages over ftp for the next
releases of pkg (probably 1.18) if you have a strong reason to use ftp which
cannot be fixed by switching to any other supported protocols like ssh or http,
please do share.

Best regards,
Bapt

Re: UBSAN reported behaviors in view use: Null pointer use oddities in contrib/nvi/... code

[Baptiste Daroussin]

+ CC upstream

On Fri, Jan 14, 2022 at 05:37:20AM -0800, Mark Millard wrote:
> # env ASAN_OPTIONS=detect_container_overflow=0 lldb view
> (lldb) target create "view"
> Current executable set to 'view' (x86_64).
> (lldb) run /usr/main-src/contrib/nvi/common/log.c
> Process 96507 launched: '/usr/bin/view' (x86_64)
> Process 96507 stopped
> * thread #1, name = 'view', stop reason = Nullptr with nonzero offset
> frame #0: 0x012c8ef0 view`::__ubsan_on_report() at 
> ubsan_monitor.cpp:39
>36 }
>37 
>38 SANITIZER_WEAK_DEFAULT_IMPL
> -> 39 void __ubsan::__ubsan_on_report(void) {}
>40 
>41 void __ubsan::__ubsan_get_current_report_data(const char 
> **OutIssueKind,
>42   const char 
> **OutMessage,
> (lldb) bt
> * thread #1, name = 'view', stop reason = Nullptr with nonzero offset
>   * frame #0: 0x012c8ef0 view`::__ubsan_on_report() at 
> ubsan_monitor.cpp:39
> frame #1: 0x012c36b1 
> view`__ubsan::Diag::~Diag(this=0x7fffb9b0) at ubsan_diag.cpp:354:29
> frame #2: 0x012c85e4 
> view`handlePointerOverflowImpl(Data=, Base=, 
> Result=, Opts=(FromUnrecoverableHandler = false, pc = 21543807, 
> bp = 140737488337936)) at ubsan_diag.h:0:21
> frame #3: 0x012c811a 
> view`::__ubsan_handle_pointer_overflow(Data=, 
> Base=, Result=) at ubsan_handlers.cpp:815:3
> frame #4: 0x0148bb7f view`vs_crel(sp=0x7fffbd20, 
> count=) at v_z.c:138:14
> frame #5: 0x01420d78 view`v_optchange(sp=, 
> offset=, str=, valp=) at 
> v_init.c:117:11 [artificial]
> frame #6: 0x0132d079 view`opts_set(sp=0x61e00080, 
> argv=0x7fffbf00, usage=) at options.c:684:8
> frame #7: 0x01328db4 view`opts_init(sp=, 
> oargs=) at options.c:412:2
> frame #8: 0x013184d3 view`editor(gp=0x62100100, 
> argc=, argv=0x7fffdb10) at main.c:240:6
> frame #9: 0x012d21dd view`main(argc=, 
> argv=) at cl_main.c:115:9
> frame #10: 0x01246c7d view`_start(ap=, 
> cleanup=) at crt1_c.c:73:7
> (lldb) up 4
> frame #4: 0x0148bb7f view`vs_crel(sp=0x7fffbd20, 
> count=) at v_z.c:138:14
>135sp->t_minrows = sp->t_rows = count;
>136if (sp->t_rows > sp->rows - 1)
>137sp->t_minrows = sp->t_rows = sp->rows - 1;
> -> 138TMAP = HMAP + (sp->t_rows - 1);
>139F_SET(sp, SC_SCR_REDRAW);
>140return (0);
>141}
> (lldb) thread info -s
> thread #1: tid = 125915, 0x012c8ef0 view`::__ubsan_on_report() at 
> ubsan_monitor.cpp:39, name = 'view', stop reason = Nullptr with nonzero offset
> 
> {
>   "col": 14,
>   "description": "nullptr-with-nonzero-offset",
>   "filename": "/usr/main-src/contrib/nvi/vi/v_z.c",
>   "instrumentation_class": "UndefinedBehaviorSanitizer",
>   "line": 138,
>   "memory_address": 0,
>   "summary": "Applying non-zero offset 1056 to null pointer",
>   "tid": 125915,
>   "trace": []
> }
> 
>  . . . Later: . . .
> 
> Process 96507 stopped
> * thread #1, name = 'view', stop reason = Null pointer use
> frame #0: 0x012c8ef0 view`::__ubsan_on_report() at 
> ubsan_monitor.cpp:39
>36 }
>37 
>38 SANITIZER_WEAK_DEFAULT_IMPL
> -> 39 void __ubsan::__ubsan_on_report(void) {}
>40 
>41 void __ubsan::__ubsan_get_current_report_data(const char 
> **OutIssueKind,
>42   const char 
> **OutMessage,
> (lldb) bt
> * thread #1, name = 'view', stop reason = Null pointer use
>   * frame #0: 0x012c8ef0 view`::__ubsan_on_report() at 
> ubsan_monitor.cpp:39
> frame #1: 0x012c36b1 
> view`__ubsan::Diag::~Diag(this=0x7fffc3c0) at ubsan_diag.cpp:354:29
> frame #2: 0x012c4aef 
> view`handleTypeMismatchImpl(Data=, Pointer=, 
> Opts=(FromUnrecoverableHandler = false, pc = 19992923, bp = 140737488340592)) 
> at ubsan_handlers.cpp:117:5
> frame #3: 0x012c47aa 
> view`::__ubsan_handle_type_mismatch_v1(Data=, 
> Pointer=) at ubsan_handlers.cpp:142:3
> frame #4: 0x0131115b view`log_line(sp=, 
> lno=, action=) at log.c:261:2
> frame #5: 0x0130cd55 view`db_append(sp=, 
> update=, lno=, p=, len=) 
> at line.c:295:2
> frame #6: 0x0141b582 view`v_ecl_log(sp=, 
> tp=) at v_ex.c:605:10
> frame #7: 0x01419af2 view`v_ex(sp=, 
> vp=) at v_ex.c:372:38
> frame #8: 0x0148da62 view`vi(spp=) at vi.c:226:18
> frame #9: 0x01319704 view`editor(gp=0x62100100, 
> argc=, argv=) at main.c:402:38
> frame #10: 0x012d21dd view`main(argc=, 
> argv=) at cl_main.c:115:9
> frame #11: 0x01246c7d view`_start(ap=, 
> cleanup=) at crt1_c.c:73:7
> (lldb) up 4
> frame #4: 0x0131115b 

Re: Problems in pkg

[Baptiste Daroussin]

On Wed, Nov 10, 2021 at 02:01:09PM -0300, Cristian Cardoso wrote:
> The problem was actually user nobody, which was deleted from the system.
> I recreated and solved the problem.
> 
> Em qua., 10 de nov. de 2021 às 06:36, Baptiste Daroussin
>  escreveu:
> >
> > On Mon, Nov 08, 2021 at 03:48:51PM -0300, Cristian Cardoso wrote:
> > > I'm trying to use pkg to install/update packages, but I'm getting the
> > > following error:
> > >
> > > # pkg update
> > > Updating FreeBSD repository catalogue...
> > > Fetching meta.conf: 100%163 B   0.2kB/s00:01
> > > Fetching packagesite.pkg: 100%6 MiB   6.7MB/s00:01
> > > pkg: Unable to drop privileges: No error: 0
> > > pkg: No signature found
> >
> > This indiquate that probably the nobody user does not exist in your system.
> >
> > btw I would make a better error message
> >
> > Best regards,
> > Bapt

FYI I updated the error message for Unable to drop privileges to make it more
useful: 

https://github.com/freebsd/pkg/commit/ac82ad8481dcbedc83b80899b8486b29bbccee51

Best regards,
Bapt

Re: main changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS but /usr/lib/libdialog.so.? naming was not adjusted? (crashes in releng/13 programs on main [so: 14] can result)

[Baptiste Daroussin]

22 oct. 2021 18:06:56 John Baldwin :

> On 10/22/21 1:08 AM, Mark Millard via freebsd-current wrote:
>> main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +)
>> changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS .
>> These are publicly exposed in (ones that I noticed):
>> /usr/include/dialog.h:extern DIALOG_STATE dialog_state;
>> /usr/include/dialog.h:extern DIALOG_VARS dialog_vars;
>> /usr/include/dialog.h:extern DIALOG_COLORS dlg_color_table[];
>
> Then we need to bump libdialog's so version to 10?  (I don't
> think libdialog has symbol versioning)
>
> --
> John Baldwin

It does not have symbol versionning and yes good catch it needs to be bumped

Bapt

Re: [HEADSUP] the default root shell is now /bin/sh

[Baptiste Daroussin]

On Wed, Oct 20, 2021 at 12:02:23PM -0300, Renato Botelho wrote:
> On 20/10/21 04:40, Baptiste Daroussin wrote:
> > Hello,
> > 
> > Following up on the proposal which happened last month, /bin/sh is now the
> > default shell for the root user.
> > 
> > As claimed during that proposal, I have so far no intention to change 
> > anything
> > more: I won't remove or modify the 'toor' user, neither modify the root 
> > gecos.
> > 
> > By popular demand on the thread about the proposal the following bindings 
> > have
> > been set by default:
> > 
> > navigation through history "ala" csh via the up and down arrow
> > navigation on the command line via ctrl+arrow (left/right) jumps from words 
> > to
> > words
> > An alias on fc -l named "history", so the history command to exist.
> > 
> > etcupdate will silently switch to sh(1) the first time, for people who 
> > wants to
> > keep root on csh, they will have to run:
> >   $ chsh -s csh
> > 
> > The next upgrade will keep that setting
> 
> Will sh config be upgraded to reflect all recent changes as well or we need
> to do it manually?

For root yes, for users you will have to do it manually

Best regards,
Bapt

[HEADSUP] the default root shell is now /bin/sh

[Baptiste Daroussin]

Hello,

Following up on the proposal which happened last month, /bin/sh is now the
default shell for the root user.

As claimed during that proposal, I have so far no intention to change anything
more: I won't remove or modify the 'toor' user, neither modify the root gecos.

By popular demand on the thread about the proposal the following bindings have
been set by default:

navigation through history "ala" csh via the up and down arrow
navigation on the command line via ctrl+arrow (left/right) jumps from words to
words
An alias on fc -l named "history", so the history command to exist.

etcupdate will silently switch to sh(1) the first time, for people who wants to
keep root on csh, they will have to run:
 $ chsh -s csh

The next upgrade will keep that setting

Best regards,
Bapt

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

[Baptiste Daroussin]

10 oct. 2021 16:43:52 Daniel Nebdal :

> On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin  wrote:
>>
>> On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote:
>>> On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans  wrote:
>>>
>>>> On Sun, Oct 10, 2021 at 12:18 AM Warner Losh  wrote:
>>>>>
>>>>> On Sat, Oct 9, 2021 at 10:45 PM Warner Losh  wrote:
>>>>>
>>>>>> …
>>>> d...@freebsd.org>
>>>>>> …
>>>> wrote:
>>>>>> …
>>>>>
>>>>>> …
>>>> the
>>>>>> …
>>>> since
>>>>>> …
>>>> /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
>>>>>> …
>>>> c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
>>>>>> …
>>>> ld:
>>>>>> …
>>>> Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
>>>>>> …
>>>> that
>>>>>> …
>>>> to
>>>>>> …
>>>> got
>>>>>> …
>>>> suitable
>>>>>> …
>>>> in
>>>>>> …
>>>> functions
>>>>>> …
>>>> return
>>>>>> …
>>>> OK; }
>>>>>> …
>>>> might
>>>>>> …
>>>> to
>>>>>> …
>>>> not
>>>>>> …
>>>> messages
>>>>>> …
>>>> protecting
>>>>>> …
>>>> disabled
>>>>>> …
>>>> for a
>>>>>> …
>>>> the
>>>>>> …
>>>> the
>>>>>> …
>>>> first
>>>>>> …
>>>> be to
>>>>>> …
>>>> probably we
>>>>>> …
>>>> having
>>>>>> …
>>>> but
>>>>>> …
>>>>>
>>>>> Though it's still a 'patch the past' path forward... The fix is trivial
>>>> to
>>>>> describe.
>>>>>
>>>>
>>>> It doesn't sound like there's any need to 'patch the past'... the
>>>> status quo is that the static libncursesw is effectively "broken"
>>>> because consumers need to know to link to libtinfow. If the linker
>>>> script idea works (which it seems like it will) then it's a non-issue;
>>>> either we're building on a system that has the all-in-one libncursesw
>>>> or we're building against a linker script that also does the right
>>>> thing.
>>>>
>>>
>>> Yea, the linker script notion is the only thing that's talked about so
>>> far that's something where we don't need to patch the past. The
>>> old tools know how to cope with the linker script and will bring the
>>> right things in. My comments were about removing -DNO_SHARED...
>>>
>>> We should remove -DNO_SHARED as well from the bootstrap tools,
>>> but that's a separate issue if the linker script works.
>>>
>>> Warner
>>
>> This https://reviews.freebsd.org/D32435 should make freebsd stable 12 and 13
>> buildable out of box again on freebsd 14.
>>
>> Best regards,
>> Bapt
>>
>
> I don't know if this is the right place to jump in, but I suspect this
> is a related issue?
> I'm trying to do the opposite - building 14 on a 13-STABLE machine. It
> fails when trying to build ncurses:
>
> root@p14s-bsd:/usr/src # uname -v
> FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10
> 03:25:38 CEST 2021
> root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> root@p14s-bsd:/usr/src # git pull
> Already up to date.
> root@p14s-bsd:/usr/src # git status
> On branch main
> Your branch is up to date with 'origin/main'.
>
> nothing to commit, working tree clean
> root@p14s-bsd:/usr/src # make buildworld > build.log
> (...)
>
> The full log is at http://eurostar.nebdal.no/build.log
> It's all variations over this:
>
> ===> lib/ncurses/ncurses (obj,all,install)
> Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o
> /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error:
> implicit declaration of function '_nc_tiparm' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>     TIPARM_1(set_a_background, bg),
>     ^
> /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from
> macro 'TIPARM_1'
> #define TIPARM_1(s,a) _nc_tiparm(1,s,a)
>   ^
> /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error:
> incompatible integer to pointer conversion passing 'int' to parameter
> of type 'const char *' [-Werror,-Wint-conversion]
>     TIPARM_1(set_a_background, bg),
>     ^~
> /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from
> macro 'TIPARM_1'
> #define TIPARM_1(s,a) _nc_tiparm(1,s,a)
>   ^
>
> -DanielN

It is an entirely different storry that deserves its own investigation!

I will try to find time in the next couple of days.

In the meantile could you provide your make.conf, src.conf and src-env.conf?

Best regards
Bapt

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

[Baptiste Daroussin]

On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans  wrote:
> 
> > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh  wrote:
> > >
> > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh  wrote:
> > >
> > > >
> > > >
> > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin 
> > > > wrote:
> > > >
> > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> > > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote:
> > > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> > > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov <
> > > >> kostik...@gmail.com>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> > > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric <
> > d...@freebsd.org>
> > > >> wrote:
> > > >> > > > > >
> > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh 
> > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric <
> > > >> d...@freebsd.org> wrote:
> > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric  > >
> > > >> wrote:
> > > >> > > > > > > > >
> > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User <
> > > >> free...@walstatt-de.de>
> > > >> > > > > wrote:
> > > >> > > > > > > > >>
> > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2
> > > >> > > > > main-n249971-0525ece3554e:
> > > >> > > > > > > > >> Fri Oct  8 15:17:34 CEST 2021 amd64) building of an
> > > >> 13-STABLE
> > > >> > > > > based
> > > >> > > > > > > > >> appliance failed very early in the build process of
> > the
> > > >> 13-STABLE
> > > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent,
> > since
> > > >> the
> > > >> > > > > sources
> > > >> > > > > > > are
> > > >> > > > > > > > >> fetched every time the build process is triggered.
> > > >> > > > > > > > > ...
> > > >> > > > > > > > >>
> > > >> > > > > > >
> > > >>
> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
> > > >> > > > > > > > >> -s -o root -g wheel -m 555   compile_et
> > > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2
> > > >> > > > > > > > >>
> > > >> > > > > > >
> > > >> > > > >
> > > >>
> > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
> > > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen ---
> > ld:
> > > >> error:
> > > >> > > > > > > undefined
> > > >> > > > > > > > >> symbol: setupterm
> > > >> > > > > > > > >>>>> referenced by Process.cpp
> > > >> > > > > > > > >>>>>
> > > >> > > > > > >
> > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
> > > >> > > > > > > > >
> > > >> > > > > > > > > It is complaining about ncurses functions; it seems
> > that
> > > >> even
> > > >> > > > > though
> > > >> > > > > > > the link step gets -lncursesw added, it still is not able
> > to
> > > >> find the
> > > >> > > > > > >

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

[Baptiste Daroussin]

On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote:
> > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov 
> > > wrote:
> > > 
> > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric  
> > > > > wrote:
> > > > >
> > > > > > On 9 Oct 2021, at 15:40, Warner Losh  wrote:
> > > > > > >
> > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric  
> > > > > > > wrote:
> > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric  wrote:
> > > > > > > >
> > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User 
> > > > wrote:
> > > > > > > >>
> > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2
> > > > main-n249971-0525ece3554e:
> > > > > > > >> Fri Oct  8 15:17:34 CEST 2021 amd64) building of an 13-STABLE
> > > > based
> > > > > > > >> appliance failed very early in the build process of the 
> > > > > > > >> 13-STABLE
> > > > > > > >> sources as shown below. 13-STABLE is most recent, since the
> > > > sources
> > > > > > are
> > > > > > > >> fetched every time the build process is triggered.
> > > > > > > > ...
> > > > > > > >>
> > > > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
> > > > > > > >> -s -o root -g wheel -m 555   compile_et
> > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2
> > > > > > > >>
> > > > > >
> > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
> > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error:
> > > > > > undefined
> > > > > > > >> symbol: setupterm
> > > > > > > >>>>> referenced by Process.cpp
> > > > > > > >>>>>
> > > > > >  Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
> > > > > > > >
> > > > > > > > It is complaining about ncurses functions; it seems that even
> > > > though
> > > > > > the link step gets -lncursesw added, it still is not able to find 
> > > > > > the
> > > > > > symbol:
> > > > > > >
> > > > > > > Okay, this is because recently on -CURRENT, libtinfow got split 
> > > > > > > off
> > > > from
> > > > > > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd
> > > > > > >
> > > > > > > This affects such cross-builds obviously, and manually adding
> > > > -ltinfow
> > > > > > > to the link command line makes it link correctly.
> > > > > > >
> > > > > > > However, the 396851c20aebd commit is probably not suitable for
> > > > MFC'ing
> > > > > > > to stable/13. Maybe we need to put some kind of kludge in
> > > > > > > share/mk/src.libnames.mk for this, or in the top-level
> > > > Makefile.inc1?
> > > > > > >
> > > > > > > Baptiste, any ideas? :)
> > > > > > >
> > > > > > > Add setupterm() to libegacy as a nop.
> > > > > >
> > > > > > That's not enough I think, it requires more ncurses functions than 
> > > > > > just
> > > > > > setupterm. And it actually calls them and checks the return values 
> > > > > > too,
> > > > > > IIRC. :)
> > > > > >
> > > > >
> > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; }
> > > > > int tigetnum(const char *t) { return 0; }
> > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; }
> > > > > int del_curterm(TERMINAL *t) { return OK; }
> > > > >
> > > > > should do the trick. I'

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

[Baptiste Daroussin]

On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote:
> On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov 
> > wrote:
> > 
> > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric  wrote:
> > > >
> > > > > On 9 Oct 2021, at 15:40, Warner Losh  wrote:
> > > > > >
> > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric  
> > > > > > wrote:
> > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric  wrote:
> > > > > > >
> > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User 
> > > wrote:
> > > > > > >>
> > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2
> > > main-n249971-0525ece3554e:
> > > > > > >> Fri Oct  8 15:17:34 CEST 2021 amd64) building of an 13-STABLE
> > > based
> > > > > > >> appliance failed very early in the build process of the 13-STABLE
> > > > > > >> sources as shown below. 13-STABLE is most recent, since the
> > > sources
> > > > > are
> > > > > > >> fetched every time the build process is triggered.
> > > > > > > ...
> > > > > > >>
> > > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh
> > > > > > >> -s -o root -g wheel -m 555   compile_et
> > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2
> > > > > > >>
> > > > >
> > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et
> > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error:
> > > > > undefined
> > > > > > >> symbol: setupterm
> > > > > > > referenced by Process.cpp
> > > > > > >
> > > > >  Process.o:(llvm::sys::Process::FileDescriptorHasColors(int))
> > > > > > >
> > > > > > > It is complaining about ncurses functions; it seems that even
> > > though
> > > > > the link step gets -lncursesw added, it still is not able to find the
> > > > > symbol:
> > > > > >
> > > > > > Okay, this is because recently on -CURRENT, libtinfow got split off
> > > from
> > > > > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd
> > > > > >
> > > > > > This affects such cross-builds obviously, and manually adding
> > > -ltinfow
> > > > > > to the link command line makes it link correctly.
> > > > > >
> > > > > > However, the 396851c20aebd commit is probably not suitable for
> > > MFC'ing
> > > > > > to stable/13. Maybe we need to put some kind of kludge in
> > > > > > share/mk/src.libnames.mk for this, or in the top-level
> > > Makefile.inc1?
> > > > > >
> > > > > > Baptiste, any ideas? :)
> > > > > >
> > > > > > Add setupterm() to libegacy as a nop.
> > > > >
> > > > > That's not enough I think, it requires more ncurses functions than 
> > > > > just
> > > > > setupterm. And it actually calls them and checks the return values 
> > > > > too,
> > > > > IIRC. :)
> > > > >
> > > >
> > > > int setupterm(const char *t, int fd, int *errptr) { return OK; }
> > > > int tigetnum(const char *t) { return 0; }
> > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; }
> > > > int del_curterm(TERMINAL *t) { return OK; }
> > > >
> > > > should do the trick. I'll see just how crazy an idea this might be
> > > > since we're trying to get the first stage tool to work on a -current
> > > > host. the only thing that clang is really using is tigetnum to see
> > > > if the terminal has color. Returning 0 tells it no.
> > > >
> > > > Or we could contrive, during bootstrap, to ensure that
> > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs
> > > > color error messages. They are nice to have, sure, but are not
> > > > strictly needed if the alternative is monochrome error messages
> > > > while building the system. There's already an ifdef protecting it:
> > > >
> > > > /* Define if the setupterm() function is supported this platform. */
> > > > #if defined(__FreeBSD__)
> > > > /*
> > > >  * This is only needed for terminalHasColors(). When disabled LLVM falls
> > > > back
> > > >  * to checking a list of TERM prefixes which is sufficient for a
> > > bootstrap
> > > > tool.
> > > >  */
> > > > #define LLVM_ENABLE_TERMINFO 1
> > > > #endif
> > > >
> > > > It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD)
> > > > or similar.
> > >
> > > I do not quite understand how would it help.
> > > You need to add this to HEAD sources back in time, not to the current
> > > sources.
> > >
> > 
> > Once merged, this would get stable building on current. But not older
> > versions of stable, it is true. It's worth doing for that reason alone
> > unless there's something clever we've not thought of yet with the current
> > host.
> 
> We can put somewhere a patch and add instructions how to use it to patch
> older HEADs and stable.  May be instructions and the reference to the patch
> file should go into UPDATING 20211004 entry.

It fails to link because the bootstrap tools are built statically if they were
linked dynamically that would solve the situation, because 

Re: Bash Static broken with new ncurses update on current

[Baptiste Daroussin]

On Tue, Oct 05, 2021 at 11:46:45AM -0700, Manfred Antar (KN6KBS) wrote:
> After update to current world on 10/5/2021 bash static is broken:
> 
> cc -L./builtins -L/usr/local/lib -L/usr/local/lib -L./lib/glob  -L./lib/tilde 
>  -L./lib/sh  -L/usr/local/lib -fstack-protector-strong -fuse-ld=bfd  -static  
> -O2 -pipe  -DLIBICONV_PLUG -fstack-protector-strong -isystem 
> /usr/local/include -fno-strict-aliasing  -static -o bash shell.o eval.o 
> y.tab.o general.o make_cmd.o print_cmd.o   dispose_cmd.o execute_cmd.o 
> variables.o copy_cmd.o error.o  expr.o flags.o jobs.o subst.o hashcmd.o 
> hashlib.o mailcheck.o  trap.o input.o unwind_prot.o pathexp.o sig.o test.o 
> version.o  alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o 
> bashhist.o  bashline.o  list.o stringlib.o locale.o findcmd.o redir.o  
> pcomplete.o pcomplib.o syntax.o xmalloc.o  -lbuiltins -lglob -lsh -lreadline 
> -lhistory -lncursesw  -ltilde -L/usr/local/lib
> /usr/local/bin/ld.bfd: ./lib/sh/libsh.a(tmpfile.o): in function 
> `sh_mktmpname':
> tmpfile.c:(.text+0x85): warning: warning: mktemp() possibly used unsafely; 
> consider using mkstemp()
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(display.o): in function 
> `update_line':
> display.c:(.text+0x4654): undefined reference to `tgoto'
> /usr/local/bin/ld.bfd: display.c:(.text+0x4664): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: display.c:(.text+0x48e1): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: display.c:(.text+0x48ff): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: display.c:(.text+0x4a62): undefined reference to 
> `tgoto'
> /usr/local/bin/ld.bfd: display.c:(.text+0x4a74): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: display.c:(.text+0x4b5d): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: display.c:(.text+0x4b8f): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: display.c:(.text+0x4bc7): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(display.o): in function 
> `_rl_clear_to_eol':
> display.c:(.text+0x4c15): undefined reference to `tputs'
> /usr/local/bin/ld.bfd: 
> /usr/local/lib/libreadline.a(display.o):display.c:(.text+0x4cf3): more 
> undefined references to `tputs' follow
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function 
> `_rl_get_screen_size':
> terminal.c:(.text+0xd0): undefined reference to `tgetnum'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x108): undefined reference to 
> `tgetnum'
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function 
> `_rl_init_terminal_io':
> terminal.c:(.text+0x36d): undefined reference to `tgetent'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x39b): undefined reference to 
> `tgetstr'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x5b9): undefined reference to `PC'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x5cc): undefined reference to `BC'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x5d7): undefined reference to `UP'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x603): undefined reference to `PC'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x611): undefined reference to `BC'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x61f): undefined reference to `UP'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x63e): undefined reference to 
> `tgetflag'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x64f): undefined reference to 
> `tgetflag'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0x6a3): undefined reference to 
> `tgetflag'
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function 
> `_rl_backspace':
> terminal.c:(.text+0xa43): undefined reference to `tputs'
> /usr/local/bin/ld.bfd: terminal.c:(.text+0xa62): undefined reference to 
> `tputs'
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function 
> `_rl_cr':
> terminal.c:(.text+0xb37): undefined reference to `tputs'
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function 
> `rl_ding':
> terminal.c:(.text+0xb78): undefined reference to `tputs'
> /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function 
> `_rl_standout_on':
> terminal.c:(.text+0xbd6): undefined reference to `tputs'
> /usr/local/bin/ld.bfd: 
> /usr/local/lib/libreadline.a(terminal.o):terminal.c:(.text+0xc06): more 
> undefined references to `tputs' follow
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [bash] Error code 1
> 
> make[2]: stopped in /usr/ports/shells/bash/work/bash-5.1
> 1 error
> 
> make[2]: stopped in /usr/ports/shells/bash/work/bash-5.1
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/shells/bash
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/shells/bash
> 
> 



Fixed, thank you for reporting

Bapt

Re: installworld with NO_ROOT produces paths with .. for man pages

[Baptiste Daroussin]

On Thu, Sep 23, 2021 at 02:38:27PM +0300, Andriy Gapon wrote:
> On 28/08/2021 17:28, Andriy Gapon wrote:
> > 
> > This seems to be related to the recent change to install manual pages
> > for all platforms.
> > 
> > My method of creating a cross-platform installation image is to install
> > with NO_ROOT and then to tar up with @METALOG argument.
> > On the destination I simply untar the archive into a destination
> > directory (typically a fresh ZFS BE).
> > 
> > Today I noticed some complaints when extracting the archive, here is a few:
> > ./usr/share/man/man4/i386/../smapi.4.gz: Path contains '..'
> > ./usr/share/man/man4/i386/../vpd.4.gz: Path contains '..'
> > ./usr/share/man/man4/powerpc/../adb.4.gz: Path contains '..'
> > ./usr/share/man/man4/powerpc/../akbd.4.gz: Path contains '..'
> > 
> > This is a not a big deal but would be nice to "straighten" the
> > installation paths when installing such manual pages.
> > 
> > P.S.
> > NO_ROOT does not seem to be documented outside of the source code.
> > 
> 
> I think that it would be nice to fix that .. issue.
> Any suggestions?


MLINKS+=${_manpage} ../${_manpage}

so install(1) does what it is asked to do and write it do the metalog as such.

First it is a bad idea to have .. in mlink as we are creating hardlinks, so we
could have a cross device issue.

The issue was reported when those links were added: 0a0f7486413c

https://lists.freebsd.org/pipermail/dev-commits-src-all/2021-July/009164.html

imho the right way to do this would be to have a new kind of macros which would
create relative symlinks using ${INSTALL_RSYMLINK} to replace MLINKS

Best regards,
Bapt

Re: [HEADSUP] making /bin/sh the default shell for root

[Baptiste Daroussin]

On Wed, Sep 22, 2021 at 10:03:40PM +0200, Alban Hertroys wrote:
> 
> > On 22 Sep 2021, at 10:36, Baptiste Daroussin  wrote:
> > 
> > Hello,
> > 
> > TL;DR: this is not a proposal to deorbit csh from base!!!
> 
> (…)
> 
> > Recently our sh(1) has receive update to make it more user friendly in
> > interactive mode:
> > * command completion (thanks pstef@)
> > * improvement in the emacs mode, to make it behave by default like other 
> > shells
> > * improvement in the vi mode (in particular the vi edit to respect $EDITOR)
> > * support for history as described by POSIX.
> > 
> > This makes it a usable shell by default, which is why I would like to 
> > propose to
> > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed)
> 
> My one concern is this: what is the impact of these usability improvements to 
> sh on its usage in scripts?

None, those are in a code path with doesn't get executed when in non interactive
mode.

Best regards,
Bapt

Re: [HEADSUP] making /bin/sh the default shell for root

[Baptiste Daroussin]

On Wed, Sep 22, 2021 at 05:19:38AM -0400, Daniel Morante via freebsd-current 
wrote:
> Will history/completion continue to work the same way? (for example typing
> part of the command, pressing UP and having it complete based on history)

No, this is a csh specific behaviour. (not it can probably be doable via
.shrc, but I haven't checked)

Best regards,
Bapt
> 
> On 9/22/2021 4:36 AM, Baptiste Daroussin wrote:
> > Hello,
> > 
> > TL;DR: this is not a proposal to deorbit csh from base!!!
> > 
> > For years now, csh is the default root shell for FreeBSD, csh can be 
> > confusing
> > as a default shell for many as all other unix like settled on a bourne shell
> > compatible interactive shell: zsh, bash, or variant of ksh.
> > 
> > Recently our sh(1) has receive update to make it more user friendly in
> > interactive mode:
> > * command completion (thanks pstef@)
> > * improvement in the emacs mode, to make it behave by default like other 
> > shells
> > * improvement in the vi mode (in particular the vi edit to respect $EDITOR)
> > * support for history as described by POSIX.
> > 
> > This makes it a usable shell by default, which is why I would like to 
> > propose to
> > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed)
> > 
> > If no strong arguments has been raised until October 15th, I will make this
> > proposal happen.
> > 
> > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!
> > 
> > Best regards,
> > Baptiste
> > 
> 

[HEADSUP] making /bin/sh the default shell for root

[Baptiste Daroussin]

Hello,

TL;DR: this is not a proposal to deorbit csh from base!!!

For years now, csh is the default root shell for FreeBSD, csh can be confusing
as a default shell for many as all other unix like settled on a bourne shell
compatible interactive shell: zsh, bash, or variant of ksh.

Recently our sh(1) has receive update to make it more user friendly in
interactive mode:
* command completion (thanks pstef@)
* improvement in the emacs mode, to make it behave by default like other shells
* improvement in the vi mode (in particular the vi edit to respect $EDITOR)
* support for history as described by POSIX.

This makes it a usable shell by default, which is why I would like to propose to
make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed)

If no strong arguments has been raised until October 15th, I will make this
proposal happen.

Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!

Best regards,
Baptiste

Re: fetch -v error output broken?

[Baptiste Daroussin]

On Thu, Sep 09, 2021 at 04:00:39PM +0200, Stefan Esser wrote:
> I have just opened PR 258387 for this issue, which occurred during testing
> of a port with invalid MASTER_SITE.
> 
> The error output of "fetch -v" should be server messages, but it appears that
> the buffer gets overwritten with data of unknown origin (mostly NUL bytes), 
> e.g.:
> 
I figured the same this morning and fixed it in: 635eb7ac799

Best regards,
Bapt

Re: Fwd: Information for freebsd-current@FreeBSD.org

[Baptiste Daroussin]

On Thu, Jul 29, 2021 at 05:39:04PM +0200, Matthias Apitz wrote:
> 
> Is this a phishing attack or did I missed some change in the FBSD
> mailing lists?
> 

This is not phishing attack this is the result of someone requesting help using
freebsd-current@f.o in the from and somehow not catched by our antispam.

Anyway those kind of request are now blocked.

As for the change in FBSD mailing list, it happened for most of the a couple of
month ago. Some are still in migration (the moderated one)

Best regards,
Bapt

Re: What happen to mailing list archives?

[Baptiste Daroussin]

8 juin 2021 13:15:50 Michael Gmelin :

>
>
> On Mon, 7 Jun 2021 22:35:20 +0200
> Baptiste Daroussin  wrote:
>
>> On Mon, Jun 07, 2021 at 12:30:46AM -0700, Mark Millard wrote:
>>> On 2021-Jun-6, at 13:25, Mark Millard  wrote:
>>>  
>>>> Baptiste Daroussin  wrote on
>>>> Date: Sun, 6 Jun 2021 10:53:49 +0200 :
>>>>  
>>>>> What has happended:
>>>>> plan A: we migrated everything off mailman/pipermail seamlessly
>>>>> with redirection and so on. We patched the new archiver to
>>>>> produce the same file names has pipermail
>>>>>
>>>>> Plan A worked fine up to a limit, there was plenty of hand
>>>>> edition in the past, we we decided to move to plan B which is
>>>>> what is happening now.
>>>>>
>>>>> Plan B: We keep a frozen version of the archives up to the
>>>>> migration date under the pipermail directory and have the new
>>>>> archives created in the archives directory.
>>>>>
>>>>> All the pipermail archives have been restored as they were. The
>>>>> new archives receives in their index a new link to point people
>>>>> to the pipermails archive if looking for older archives.
>>>>>
>>>>> this has been done a couple of hours ago (before Steve emails)
>>>>> during a window, of ~ 10 hours, the mailing lists which slow
>>>>> traffic aka the one which didn't received any email since the
>>>>> migration ended up with an empty "archives" directory (aka a
>>>>> 404), a file with explanation and redirection to pipermail has
>>>>> been installed there.
>>>>>
>>>>> Some work is still needed for the mailing lists which has been
>>>>> transformed as readonly, this will be done in the next couple of
>>>>> days 
>>>>
>>>> It is too bad that a reference to a "no examples yet"
>>>> month, such as, (at the time I write this):
>>>>
>>>> https://lists.freebsd.org/archives/freebsd-toolchain/2021-June/date.html
>>>>
>>>> does not show at least (Date view specific example):
>>>>
>>>>   • Other periods:[ Previous, Date view ] [ List of Folders
>>>> ]
>>>>   • Other: [ Actives mailing lists ] [ Archives from
>>>> mailman's time ]
>>>>
>>>> when there are prior months available in
>>>> https://lists.freebsd.org/archives/ or show at least just:
>>>>
>>>>   • Other: [ Actives mailing lists ] [ Archives from
>>>> mailman's time ]
>>>>
>>>> when no prior months are available there.
>>>>  
>>>
>>> Looks like there are missing months.
>>>
>>> Using freebsd-hackers as an example:
>>>
>>> https://lists.freebsd.org/archives/freebsd-hackers/index.html
>>> shows the oldest month being "May 2021".
>>>
>>> But . . .
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-hackers/
>>> shows the most recent month being "September 2020".
>>>
>>> So: 2020-Oct through 2021-Apr are completely missing.
>>>
>>> Then, going for more detail for 2020-Sep and 2021-May . . .
>>>
>>> https://lists.freebsd.org/archives/freebsd-hackers/2021-May/date.html
>>> shows "Starting Tue May 18 2021 - 21:07:44 UTC".
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-hackers/2020-September/date.html
>>> shows "Ending: Tue Sep 15 14:12:20 UTC 2020".
>>>
>>> So there are about 2 more half-months missing.
>>>
>>> Some other lists have other date ranges, some similar,
>>> some not. 
>>
>> This missing month are being populated right now
>
> Will historic links still work though (so that old references work and
> current google results are ok)?
>
> Just stumbled over this one:
> https://lists.freebsd.org/archives/freebsd-jail/2017-March/003360.html
>
Old reference yes, not the one that lived a couple of weeks like this one

Bapt

Re: What happen to mailing list archives?

[Baptiste Daroussin]

On Mon, Jun 07, 2021 at 12:30:46AM -0700, Mark Millard wrote:
> On 2021-Jun-6, at 13:25, Mark Millard  wrote:
> 
> > Baptiste Daroussin  wrote on
> > Date: Sun, 6 Jun 2021 10:53:49 +0200 :
> > 
> >> What has happended:
> >> plan A: we migrated everything off mailman/pipermail seamlessly with 
> >> redirection
> >> and so on. We patched the new archiver to produce the same file names has
> >> pipermail
> >> 
> >> Plan A worked fine up to a limit, there was plenty of hand edition in the 
> >> past,
> >> we we decided to move to plan B which is what is happening now.
> >> 
> >> Plan B: We keep a frozen version of the archives up to the migration date 
> >> under
> >> the pipermail directory and have the new archives created in the archives
> >> directory.
> >> 
> >> All the pipermail archives have been restored as they were. The new 
> >> archives
> >> receives in their index a new link to point people to the pipermails 
> >> archive if
> >> looking for older archives.
> >> 
> >> this has been done a couple of hours ago (before Steve emails) during a 
> >> window,
> >> of ~ 10 hours, the mailing lists which slow traffic aka the one which 
> >> didn't
> >> received any email since the migration ended up with an empty "archives"
> >> directory (aka a 404), a file with explanation and redirection to 
> >> pipermail has
> >> been installed there.
> >> 
> >> Some work is still needed for the mailing lists which has been transformed 
> >> as
> >> readonly, this will be done in the next couple of days
> > 
> > It is too bad that a reference to a "no examples yet"
> > month, such as, (at the time I write this):
> > 
> > https://lists.freebsd.org/archives/freebsd-toolchain/2021-June/date.html
> > 
> > does not show at least (Date view specific example):
> > 
> > • Other periods:[ Previous, Date view ] [ List of Folders ]
> > • Other: [ Actives mailing lists ] [ Archives from mailman's time ]
> > 
> > when there are prior months available in
> > https://lists.freebsd.org/archives/ or show at least just:
> > 
> > • Other: [ Actives mailing lists ] [ Archives from mailman's time ]
> > 
> > when no prior months are available there.
> > 
> 
> Looks like there are missing months.
> 
> Using freebsd-hackers as an example:
> 
> https://lists.freebsd.org/archives/freebsd-hackers/index.html
> shows the oldest month being "May 2021".
> 
> But . . .
> 
> https://lists.freebsd.org/pipermail/freebsd-hackers/
> shows the most recent month being "September 2020".
> 
> So: 2020-Oct through 2021-Apr are completely missing.
> 
> Then, going for more detail for 2020-Sep and 2021-May . . .
> 
> https://lists.freebsd.org/archives/freebsd-hackers/2021-May/date.html
> shows "Starting Tue May 18 2021 - 21:07:44 UTC".
> 
> https://lists.freebsd.org/pipermail/freebsd-hackers/2020-September/date.html
> shows "Ending: Tue Sep 15 14:12:20 UTC 2020".
> 
> So there are about 2 more half-months missing.
> 
> Some other lists have other date ranges, some similar,
> some not.

This missing month are being populated right now

Best regards,
Bapt

Re: What happen to mailing list archives?

[Baptiste Daroussin]

On Sat, Jun 05, 2021 at 05:43:01PM -0600, Warner Losh wrote:
> On Sat, Jun 5, 2021, 5:29 PM Steve Kargl 
> wrote:
> 
> > On Sun, Jun 06, 2021 at 01:04:46AM +0200, Michael Gmelin wrote:
> > >
> > > p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click
> > FreeBSD-net and then "Archives from mailman’s time", you get to a list that
> > brings you to https://lists.freebsd.org/pipermail/freebsd-net/. So the
> > old archives are still reachable that way. (I still find the
> > docs.FreeBSD.org/mail page to be confusing).
> > >
> > >
> >
> > There isn't an "Archives from mailman's time" link on freebsd-numerics.
> >
> > Hundreds of emails from me are now gone or sufficiently hidden that
> > I cannot find them.  More importantly, Bruce Evans often replied
> > with reviews of libm patch's I sent the list.  Those reviews and
> > his detailed analysis of the libm code are now gone or sufficiently
> > hidded that I cannot find them.
> >
> 
> 
> Bapt was working on this stuff today. He said something about the archive
> regenerating with the new software on IRC..
> 
> Warner
> 
What has happended:
plan A: we migrated everything off mailman/pipermail seamlessly with redirection
and so on. We patched the new archiver to produce the same file names has
pipermail

Plan A worked fine up to a limit, there was plenty of hand edition in the past,
we we decided to move to plan B which is what is happening now.

Plan B: We keep a frozen version of the archives up to the migration date under
the pipermail directory and have the new archives created in the archives
directory.

All the pipermail archives have been restored as they were. The new archives
receives in their index a new link to point people to the pipermails archive if
looking for older archives.

this has been done a couple of hours ago (before Steve emails) during a window,
of ~ 10 hours, the mailing lists which slow traffic aka the one which didn't
received any email since the migration ended up with an empty "archives"
directory (aka a 404), a file with explanation and redirection to pipermail has
been installed there.

Some work is still needed for the mailing lists which has been transformed as
readonly, this will be done in the next couple of days

Bapt

Re: Alternate Screen

[Baptiste Daroussin]

On Mon, May 17, 2021 at 09:46:49AM -0500, Eric van Gyzen wrote:
> On 5/17/21 5:19 AM, Gary Jennejohn wrote:
> > On Sun, 16 May 2021 19:03:07 +0200
> > Baptiste Daroussin  wrote:
> > 
> > > On Thu, May 13, 2021 at 09:01:53AM -0500, Eric van Gyzen wrote:
> > > > There was a recent discussion about a terminal database update and the 
> > > > new
> > > > Alternate Screen behavior.  I'm curious about the resolution, but I 
> > > > can't
> > > > find that discussion.  Would someone kindly send a clue-by-four via
> > > > overnight express?
> > > > 
> > > > Ultimately, I'd like to know how to get the old behavior back, with no
> > > > alternate screen, and thereby reduce my blood pressure.
> > > > 
> > > > Alternatively yours,
> > > 
> > > The replies you are receiving are interesting as none of them are right...
> > > 
> > > What has been done, it now ncurses from base reads both terminfo and 
> > > termcap DB.
> > > It is looking up for terminfo db from localbase as well.
> > > 
> > > Base only provides termcap (the old termcap definition, nothing new in 
> > > there).
> > > if one want the terminfo database which supports alternate screen 
> > > definition,
> > > he/shre can just pkg install terminfo-db.
> > > 
> > 
> > But in March terminfo was being built and installed.  Maybe he failed to
> > delete /usr/share/terminfo after the change.  Or was simply not aware that
> > he had to do that.
> 
> Thanks for the help, everyone.  Deleting /usr/share/terminfo fixed the
> problem.  (I don't have the terminfo-db package installed.)
> 
> Bapt, was this intentionally omitted from ObsoleteFiles.inc, or was that an
> oversight?
> 
> Cheers,
> 
> Eric

It is in ObsoleteFiles.inc

# 20210318: remove the terminfo database

Bapt
___
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: Alternate Screen

[Baptiste Daroussin]

On Thu, May 13, 2021 at 09:01:53AM -0500, Eric van Gyzen wrote:
> There was a recent discussion about a terminal database update and the new
> Alternate Screen behavior.  I'm curious about the resolution, but I can't
> find that discussion.  Would someone kindly send a clue-by-four via
> overnight express?
> 
> Ultimately, I'd like to know how to get the old behavior back, with no
> alternate screen, and thereby reduce my blood pressure.
> 
> Alternatively yours,

The replies you are receiving are interesting as none of them are right...

What has been done, it now ncurses from base reads both terminfo and termcap DB.
It is looking up for terminfo db from localbase as well.

Base only provides termcap (the old termcap definition, nothing new in there).
if one want the terminfo database which supports alternate screen definition,
he/shre can just pkg install terminfo-db.

Best regards,
Bapt
___
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"

Incoming changes in the sh(1) default behaviour

[Baptiste Daroussin]

Hello everyone

We have been working implementing the persistent history storage in sh(1).

It will now respect POSIX:
- by default the history will be saved and loaded from ~/.sh_history
- if HISTFILE is set it will use histfile instead of ~/.sh_history
- if HISTFILE is set but empty it will not load or save anything
- if HISTSIZE is set to 0 it will also not load or save anything

The change will be pushed very soon to head and probably not be MFC except if
someone manage to convince me otherwise.

https://reviews.freebsd.org/D29493

Best regards,
Bapt
___
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: sys/sys/param.h: 'main' instead of 'Master'?

[Baptiste Daroussin]

On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> On Fri, 16 Apr 2021 at 16:22, Warner Losh  wrote:
> >
> > > > As well as "Origin".
> > >
> > > (Single) Source of Truth, maybe?
> >
> > s/Master, p/P/ also makes sense.
> 
> IMO instead of lightly rewording the existing comment we could just
> remove it, it doesn't really add any clarity.
> 
> Instead we ought to add an introductory sentence or two to the block
> comment above, explaining what __FreeBSD_version actually is.

fully agreed here! I had to explained many time what __FreeBSD_version actually
was. A clear comment would be great ;)

Bapt
___
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: Poudriere failed to build pkg in 13-stable jail under 12-stable

[Baptiste Daroussin]

On Mon, Jan 25, 2021 at 12:46:43PM +0800, Thomas Legg wrote:
> The build of a 13-stable source and kernel were a success under 12-stable
> (though with some issues on freeze-ups and hard reboots that I suspect
> might be related to the bufdaemon issue and my 0x15 gen AMD cpu).
> 
> Created a 13-stable poudriere jail with the knowledge that there may be
> issues with builds under a 12-stable r369076 kernel. I didn't expect this
> failure on packaging pkg.
> 
> > Compressing man pages (compress-man)
> ===>   Installing ldconfig configuration file
> ===
> ===
> ===>  Building package for pkg-1.16.2
> cp: /wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg/pkg-1.16.2.txz: Function not
> implemented
> *** Error code 1
> 

cp on head and 13 is using copy_file_range(2), introduced in 13-CURRENT
recentish, this is what is failing here.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: git tools for building in base?

[Baptiste Daroussin]

On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote:
> On Tue, Nov 24, 2020 at 2:19 PM tech-lists  wrote:
> 
> > As subject - what will there be in base to interact with the new git repo?
> > I mean, right now, for svn there is svnlite. What for git?
> >
> 
> 'pkg add git' is your choice now.

pkg install not pkg add
> 
> 
> > Shouldn't it be in base before the move to git?
> >
> 
> We will have got (from OpenBSD: Game Of Trees) in the future. It isn't
> quite there yet, however, so it's not in base. When we migrated from CVS to
> Subversion, we didn't grow svnlite in the base for many months after the
> conversion. We hope to have it finished in time for 13.0.
> 
> 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"


signature.asc
Description: PGP signature

Re: Deprecating ftpd in the FreeBSD base system?

[Baptiste Daroussin]

On Thu, Sep 17, 2020 at 07:04:41AM -0700, Cy Schubert wrote:
> In message  om>
> , Ed Maste writes:
> > FTP is (becoming?) a legacy protocol, and I think it may be time to
> > remove the ftp server from the FreeBSD base system - with the recent
> > security advisory for ftpd serving as a reminder.
> >
> > I've proposed adding a deprecation notice to the man page in
> > https://reviews.freebsd.org/D26447 to start this off. There are a
> > number of ftp servers in ports, and if we're going to remove the base
> > system one we can create a port for it first, as well.
> >
> > Any comments or concerns, please follow up in the code review or in email 
> > her
> > e.
> 
> We should also deprecate the FTP client.
> 
> I've been advocating removing FTP (and HTTP) from libfetch as well. People 
> should be using HTTPS only. (libfetch could support a plugin that might be 
> supplied by a port should someone be inclined to write one.)
> 
That that and we can throw away half of the ports tree ;)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Move from termcap(5) to terminfo(5)

[Baptiste Daroussin]

On Thu, May 07, 2020 at 03:22:20PM +0200, Mateusz Piotrowski wrote:
> Hi,
> 
> On 5/7/20 2:41 PM, Baptiste Daroussin wrote:
> > Hello everyone,
> > 
> > I can't find any proper rationale in our history (maybe I missed it) which
> > explains why our ncurses is stuck on using termcap(5) instead of terminfo(5)
> > Except an argument in the Makefile that builds ncurses:
> > "Used instead of the hideous read_termcap.c abomination."
> > 
> > Which I do not find really useful.
> > 
> > I would like to make the move from termcap to terminfo which would give us 
> > the
> > bonus to be able to track terminfo sources from upstream aka ncurses and to
> > add and use tic(1).
> That's great! I've been bitten by termcap not being well understood by the
> open source community many times. I am supporting the move to terminfo
> wholeheartedly.
> > If you have some knowledge you want to share: "be careful about this or 
> > that" I
> > would be more than happy to collect it, to make sure the transition is as 
> > smooth
> > as possible.
> 
> What comes to my mind is that we should probably pay special attention to
> terminal ports, like x11/sterm. We might need to tell those ports to install
> their terminfo files. I don't remember the details though.
> 
All their terminfo files are already in recent ncurses, so we will have nothing
to do with them.

Best regards,
Bapt


signature.asc
Description: PGP signature

Move from termcap(5) to terminfo(5)

[Baptiste Daroussin]

Hello everyone,

I can't find any proper rationale in our history (maybe I missed it) which
explains why our ncurses is stuck on using termcap(5) instead of terminfo(5)
Except an argument in the Makefile that builds ncurses:
"Used instead of the hideous read_termcap.c abomination."

Which I do not find really useful.

I would like to make the move from termcap to terminfo which would give us the
bonus to be able to track terminfo sources from upstream aka ncurses and to
add and use tic(1).

Given the very few people that are actually maintaining the termcap database. I
don't think there is a good rationale at keeping our own format (as far as I
know everyone moved to terminfo(5)) and parser.

Without any strong arguments against it I will start working on that move by
next week.

If you have some knowledge you want to share: "be careful about this or that" I
would be more than happy to collect it, to make sure the transition is as smooth
as possible.

Best regards,
Bapt
___
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: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Tue, May 05, 2020 at 03:24:15PM +0300, Slawa Olhovchenkov wrote:
> On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote:
> 
> > > > This way ports with random termcap info to add would be able to do it 
> > > > witho=
> > > > ut
> > > > the requirement to wait for a commit in base and a MFC.
> > > 
> > > This is probably outside of my scope at the moment but, yes, agreed.
> > > 
> > I will then.
> > I added that to my TODO
> 
> Can you also see at termcap/ncurses related code?
> Latest commit in base do unusable sh/tcsh  w/ emacs
> tramp mode and inside screen.

I am not aware of sh/tcsh being unsable at all. I heard about an emacs thingy
but not being an emacs guy myself I haven't reproduced.

I can have a look but I would need a more specific feedback with examples of
failures.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Mon, May 04, 2020 at 06:35:03AM -0700, Cy Schubert wrote:
> In message <20200504072624.wlyd73pehq25t...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --ma2vde2ykv3k7k6b
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> > > In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --mvhxgm4zl62unzlf
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=3D=
> > 20
> > > > > Daroussin wr
> > > > > ites:
> > > > > >=3D20
> > > > > >
> > > > > > --vwrr5drfobpkyvop
> > > > > > Content-Type: text/plain; charset=3D3Dus-ascii
> > > > > > Content-Disposition: inline
> > > > > > Content-Transfer-Encoding: quoted-printable
> > > > > >
> > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > > > Would people be open to the idea of a sysutils/screen-ncurses por=
> > t th=3D
> > > > at=3D3D
> > > > > > =3D3D20
> > > > > > > depends on devel/ncurses instead of ncureses in base? The reason =
> > for =3D
> > > > this=3D3D
> > > > > > =3D3D20
> > > > > > > is there are screen.* terminfo entries in devel/ncurses that don'=
> > t ex=3D
> > > > ist =3D3D
> > > > > > in=3D3D20
> > > > > > > termcap(5). People who want that extra functionality would be adv=
> > ised=3D
> > > >  to=3D3D
> > > > > > =3D3D20
> > > > > > > install the alternative pkg or build the sysutils/screen port wit=
> > h th=3D
> > > > e=3D3D20
> > > > > > > appropriate option.
> > > > > > >=3D3D20
> > > > > > > Or, simply change the default from whatever ncurses is available =
> > to a=3D
> > > > lway=3D3D
> > > > > > s=3D3D20
> > > > > > > install devel/ncurses. People could always select one of the othe=
> > r op=3D
> > > > tion=3D3D
> > > > > > s.=3D3D20
> > > > > > > Personally, I'm not enamoured with this approach.
> > > > > >
> > > > > > I think it is a terrible idea, and we should fix the initial proble=
> > m in=3D
> > > > stea=3D3D
> > > > > > d of
> > > > > > workarounding it.
> > > > > >
> > > > > > 1/ why those are not in our termcap(5) ? they should be added if th=
> > ey a=3D
> > > > re
> > > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > > > >=3D20
> > > > > I came to this conclusion last night after sending this email thread =
> > oud=3D
> > > > =3D20
> > > > > and will test it some time today.
> > > > >=3D20
> > > > > >
> > > > > > 2/ we should allow our base ncurses to get informations from newer =
> > term=3D
> > > > cap(=3D3D
> > > > > > 5) if
> > > > > > needed.
> > > > > > So far the default TERMCAP is
> > > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,=
> > =2Edb}
> > > > > >
> > > > > > First the user can be advise to point configure the $home/.termcap =
> > this=3D
> > > >  is =3D3D
> > > > > > for
> > > > > > quick now.
> > > >
> > > > that is in your scope via a pkg-message :D
> > > >
> > > > > >
> > > > > > Second for later futur proof mechanism we could modify our termcap =
> > read=3D
> > > > er (=3D3D
> > > > > > we
> > > > > > use our own, not the one in provided by ncurses). to be able to fet=
> > ch t=3D
> > > > ermc=3D3D
> > > > > > ap
> > > &

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote:
> In message <20200430130449.cwsf3x42o6w67...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --mvhxgm4zl62unzlf
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste=20
> > > Daroussin wr
> > > ites:
> > > >=20
> > > >
> > > > --vwrr5drfobpkyvop
> > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > > Would people be open to the idea of a sysutils/screen-ncurses port th=
> > at=3D
> > > > =3D20
> > > > > depends on devel/ncurses instead of ncureses in base? The reason for =
> > this=3D
> > > > =3D20
> > > > > is there are screen.* terminfo entries in devel/ncurses that don't ex=
> > ist =3D
> > > > in=3D20
> > > > > termcap(5). People who want that extra functionality would be advised=
> >  to=3D
> > > > =3D20
> > > > > install the alternative pkg or build the sysutils/screen port with th=
> > e=3D20
> > > > > appropriate option.
> > > > >=3D20
> > > > > Or, simply change the default from whatever ncurses is available to a=
> > lway=3D
> > > > s=3D20
> > > > > install devel/ncurses. People could always select one of the other op=
> > tion=3D
> > > > s.=3D20
> > > > > Personally, I'm not enamoured with this approach.
> > > >
> > > > I think it is a terrible idea, and we should fix the initial problem in=
> > stea=3D
> > > > d of
> > > > workarounding it.
> > > >
> > > > 1/ why those are not in our termcap(5) ? they should be added if they a=
> > re
> > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> > >=20
> > > I came to this conclusion last night after sending this email thread oud=
> > =20
> > > and will test it some time today.
> > >=20
> > > >
> > > > 2/ we should allow our base ncurses to get informations from newer term=
> > cap(=3D
> > > > 5) if
> > > > needed.
> > > > So far the default TERMCAP is
> > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > > >
> > > > First the user can be advise to point configure the $home/.termcap this=
> >  is =3D
> > > > for
> > > > quick now.
> >
> > that is in your scope via a pkg-message :D
> >
> > > >
> > > > Second for later futur proof mechanism we could modify our termcap read=
> > er (=3D
> > > > we
> > > > use our own, not the one in provided by ncurses). to be able to fetch t=
> > ermc=3D
> > > > ap
> > > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > > >
> > > > This way ports with random termcap info to add would be able to do it w=
> > itho=3D
> > > > ut
> > > > the requirement to wait for a commit in base and a MFC.
> > >=20
> > > This is probably outside of my scope at the moment but, yes, agreed.
> > >=20
> > I will then.
> > I added that to my TODO
> 
> There's already a utility in devel/ncurses called infotocap (and its 
> corresponding captoinfo) that already does this. Both are links to tic. Our 
> ncurses import includes tic. Looks like all that's needed is add it to 
> buildworld.
> 
> I can look at it later tonight. Seems like a quick win.
> 
That is not the point, tic won't work here except if create your own version or
use infotocap. Tic is for terminfo databases while we are still using the 
termcap for historical reason

Having both ncurses from ports and ncurses from base installed at the same time
can open a special can of worm so imho that is not really something we want to
look forward.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste 
> Daroussin wr
> ites:
> > 
> >
> > --vwrr5drfobpkyvop
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > Would people be open to the idea of a sysutils/screen-ncurses port that=
> > =20
> > > depends on devel/ncurses instead of ncureses in base? The reason for this=
> > =20
> > > is there are screen.* terminfo entries in devel/ncurses that don't exist =
> > in=20
> > > termcap(5). People who want that extra functionality would be advised to=
> > =20
> > > install the alternative pkg or build the sysutils/screen port with the=20
> > > appropriate option.
> > >=20
> > > Or, simply change the default from whatever ncurses is available to alway=
> > s=20
> > > install devel/ncurses. People could always select one of the other option=
> > s.=20
> > > Personally, I'm not enamoured with this approach.
> >
> > I think it is a terrible idea, and we should fix the initial problem instea=
> > d of
> > workarounding it.
> >
> > 1/ why those are not in our termcap(5) ? they should be added if they are
> > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> 
> I came to this conclusion last night after sending this email thread oud 
> and will test it some time today.
> 
> >
> > 2/ we should allow our base ncurses to get informations from newer termcap(=
> > 5) if
> > needed.
> > So far the default TERMCAP is
> > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> >
> > First the user can be advise to point configure the $home/.termcap this is =
> > for
> > quick now.

that is in your scope via a pkg-message :D

> >
> > Second for later futur proof mechanism we could modify our termcap reader (=
> > we
> > use our own, not the one in provided by ncurses). to be able to fetch termc=
> > ap
> > capabilities from /usr/local/share/misc/termcap/*.conf for example
> >
> > This way ports with random termcap info to add would be able to do it witho=
> > ut
> > the requirement to wait for a commit in base and a MFC.
> 
> This is probably outside of my scope at the moment but, yes, agreed.
> 
I will then.
I added that to my TODO

Bestr regards,
Bapt


signature.asc
Description: PGP signature

Re: sysutils/screen-ncurses port

[Baptiste Daroussin]

On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> Would people be open to the idea of a sysutils/screen-ncurses port that 
> depends on devel/ncurses instead of ncureses in base? The reason for this 
> is there are screen.* terminfo entries in devel/ncurses that don't exist in 
> termcap(5). People who want that extra functionality would be advised to 
> install the alternative pkg or build the sysutils/screen port with the 
> appropriate option.
> 
> Or, simply change the default from whatever ncurses is available to always 
> install devel/ncurses. People could always select one of the other options. 
> Personally, I'm not enamoured with this approach.

I think it is a terrible idea, and we should fix the initial problem instead of
workarounding it.

1/ why those are not in our termcap(5) ? they should be added if they are
missing. and MFC asap (prior 11.4 and 12.2 would be nice)

2/ we should allow our base ncurses to get informations from newer termcap(5) if
needed.
So far the default TERMCAP is
${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}

First the user can be advise to point configure the $home/.termcap this is for
quick now.

Second for later futur proof mechanism we could modify our termcap reader (we
use our own, not the one in provided by ncurses). to be able to fetch termcap
capabilities from /usr/local/share/misc/termcap/*.conf for example

This way ports with random termcap info to add would be able to do it without
the requirement to wait for a commit in base and a MFC.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: r358062(ncurses) breaks installed ports, howto check?

[Baptiste Daroussin]

On Tue, Feb 25, 2020 at 04:19:56AM -0500, Thomas Dickey wrote:
> On Mon, Feb 24, 2020 at 08:28:03PM -0500, Thomas Dickey wrote:
> > On Mon, Feb 24, 2020 at 06:35:16PM -0500, Thomas Dickey wrote:
> > > On Mon, Feb 24, 2020 at 06:25:30PM -0500, Thomas Dickey wrote:
> > > > On Tue, Feb 25, 2020 at 04:37:11AM +0900, Yasuhiro KIMURA wrote:
> > > > > From: "O. Hartmann" 
> > > > > Subject: r358062(ncurses) breaks installed ports, howto check?
> > > > > Date: Mon, 24 Feb 2020 20:19:59 +0100
> > > > > 
> > > > > > After r358062, many installed ports do not work anymore on several 
> > > > > > running systems (CURRENT).
> > > > > > /usr/src/UPDATING states one should reinstall all ncurses depending 
> > > > > > ports, but no hint is
> > > > > > given! Can someone mitigate this lack of information? Is there a 
> > > > > > simple way to check what
> > > > > > ports installed on a system rely on ncurses provided by the system?
> > > > > 
> > > > > Check thread starting with following message.
> > > > > 
> > > > > https://lists.freebsd.org/pipermail/freebsd-ports/2020-February/117710.html
> > > > 
> > > > That's a start, but it gives an overly-broad approach, saying that
> > > > anything linked to the ncurses library has to be recompiled.
> > > > 
> > > > The ABI change is just to the (upper-level) curses interface.
> > > > Most of the programs you'll have in ports use the (lower-level) termcap
> > > > or terminfo interfaces.
> > > > 
> > > > For example gettext uses terminfo (not curses).
> > > > 
> > > > Curses applications use initscr or newterm (nm helps).
> > > > I have a script which uses nm to tell me which interface is used.
> > > > 
> > > > Actually, in my own ports, I don't see any which would be affected,
> > > > since all of the curses applications are the utilities for ncurses
> > > > (or for my testing of ncurses).
> > > > 
> > > > Here's an example of what it tells me
> > > > (n5==ncurses5, tc=termcap, ti=terminfo):
> > > > 
> > > > ti  bison
> > > > n5*+ti  captoinfo
> > > > n5*+ti  captoinfo6
> > > > n5*+ti  clear
> > > > n5*+ti  clear6
> > > > n5+tc   ded
> > > > n5+ti   dialog4ports
> > > 
> > > actually this one isn't one of mine (needs to be recompiled)
> > > 
> > > But for the rest - recompiling would be a waste of time.
> > 
> > ...that's just looking at /usr/local/bin.  I see Millard's list
> > includes /usr/local/lib.  I have some of those:
> > 
> > c3+tc   libXvMCr600.so
> > tc  libedit.so
> > tc  libedit.so.0
> > ti  libgettextsrc.so
> > tc  libreadline.so
> > tc  libslang.so
> > ti  libtextstyle.so
> > c3+tc   libvulkan_radeon.so
> > 
> > that is, mesa-dri uses curses, but libedit and libreadline do not.
> > 
> > I have llvm80, but that doesn't live in either of /usr/local/bin
> > or /usr/local/lib.  It's in its own directory (with a script in
> > the former pointing there).  It uses curses (and is not a quick
> > recompile).
> 
> now... I discussed this briefly with the developer on the 20th of January.
> 
> ncurses can be configured/built to use the old binary interface (ABI 5),
> but he ran into some problem doing that, and decided to use ABI 6.
> 
> At the time, I had supposed that cost would be contained by the system
> builders, not considering the impact on users rebuilding ports.
> 
> Depending on where FreeBSD is along that path, it might be worth
> revisiting, to see exactly why the build with ABI 5 did not work.
> 
I think we should anyway move on on ABI 6, which is why I didn't insist on ABI 5
when I could not find the root cause of it not working. In the futur we will
update ncurses on more regular basis, and ABI 6 is what everyone else is using
so probably what is the most tested.

if I understand correctly upstream build system, staying on ABI 5 disable many
features that are available in ABI 6.

For those interested my current plan with ncurses is the following for freebsd
13.0:
- split terminfo from ncurses (like the upstream build system) so a futur change
  in high level ABI will impact less consumers
- only keep the widechar version of ncurses in base
- add the pkgconf file in base to ease the ports tree.

Again for people who don't want to rebuild everything compat12x package has been
created and can be used to have all binaries working.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [CFT][patch] mandoc: don't segfault on empty tbl(1) continuation blocks

[Baptiste Daroussin]

On Wed, Jul 17, 2019 at 01:39:42PM +0300, Eygene Ryabinkin wrote:
> Baptiste, good day.
> 
> Wed, Jul 17, 2019 at 09:12:02AM +0200, Baptiste Daroussin wrote:
> > On Tue, Jul 16, 2019 at 10:31:24PM +0300, Eygene Ryabinkin wrote:
> > > Attached is the patch that makes built-in tbl(1) processor in
> > > mandoc to avoid dumping core when it renders the table with empty
> > > "T{ T}" block and horizontally-ruled table.
> >
> > Thank you for the patch! Have it been discussed with upstream? I
> > kind of remind something like this being reported to upstream, but I
> > haven't checked the status.
> 
> Was fixed:
>   https://mandoc.bsd.lv/cgi-bin/cvsweb/tbl_term.c.diff?r1=1.69=1.70
>   
> https://github.com/openbsd/src/commit/5f6e3232931ab08da9c8121d568c8207c0c4662c#diff-bc5842dc5d7897de7bdac08f74804c57
> A bit differently: people just check for dpn->string being NULL.
> 
> And there is another one NULL pointer fix,
>   https://mandoc.bsd.lv/cgi-bin/cvsweb/tbl_term.c.diff?r1=1.70=1.71
>   
> https://github.com/openbsd/src/commit/7514a273fe4561e94f1277f4ee5991c9af9cba2e#diff-bc5842dc5d7897de7bdac08f74804c57
> Can't trigger it with upstream's testcase,
>   
> https://mandoc.bsd.lv/cgi-bin/cvsweb/regress/tbl/layout/shortlines.in?rev=1.1=text/x-cvsweb-markup
>   
> https://raw.githubusercontent.com/openbsd/src/7514a273fe4561e94f1277f4ee5991c9af9cba2e/regress/usr.bin/mandoc/tbl/layout/shortlines.in
> since current FreeBSD's mandoc lacks this modification,
>   https://mandoc.bsd.lv/cgi-bin/cvsweb/tbl_term.c.diff?r1=1.68=1.69
>   
> https://github.com/openbsd/src/commit/b3e6a3251dfa92e66aa539518119564bd1945cc0#diff-bc5842dc5d7897de7bdac08f74804c57
> but I believe that 'cpp' still can be NULL and will try to see
> if it is triggerable.
> 
> So, the patch that corresponds to the upstream change is attached.
> 
> Nothing was released after 1.14.5 (yet).  What will be the route?
> Will you
>  - wait for the new release;
>- if yes, will you incorporate the testing part?
>  - if no, I think you will use the closer-to-upstream patch?
> 
> Thanks.

Thank you for the patch and the test case, with mandoc, usually I try to be as
close as upstream as possible (targetting 100% ;).

So my approach in such case is to move to a snapshot of their cvs tree (as soon
as it has the fix incorporated).

As for the test case, the best would be that this test ends up incorporated in
the upstream testsuite (note that I need to plug it into our test framework
one day) I added the tech mailing list of mandoc in CC to give a chance to Ingo
to step on this.

I will be off for a week starting tonight, but I will update to the latest
snapshot of mandoc once back.o
We can still integrate some test case of our own as well, and I will be happy to
integrate yours if not integrated in the upstream testsuite.

Best regards,
Bapt

> -- 
> Eygene Ryabinkin,,,^..^,,,
> [ Life's unfair - but root password helps!   | codelabs.ru ]
> [ 82FE 06BC D497 C0DE 49EC  4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]

> mandoc: fix built-in tbl(1) processing of empty continuation blocks
> 
> Empty "T{ T}" (continuation) blocks produce NULL-valued string
> for their data block: getdata() allocates structure with string
> set to NULL and tbl_cdata() will just return when it sees
> the end ("T}") of the block without any further manipulations
> with dat->string.
> 
> This is completely legal; moreover, tbl.h specifies that for
> 'struct tbl_dat' the 'string' member is NULL when entry type
> is not TBL_DATA_DATA.  This is not so all the time, but one
> shouldn't rely on this.
> 
> The segfault in question was plain NULL pointer dereference
> triggered from tbl_term.c::tbl_hrule().
> 
> Added check for dpn->string not being NULL to be in sync
> with upstream,
>   https://mandoc.bsd.lv/cgi-bin/cvsweb/tbl_term.c.diff?r1=1.69=1.70
> Also added regression test to find such problems in the future.
> 
> The real-world case when manpage was provoking core dump
> is notmuch-config.1 for mail/notmuch port: it is auto-generated
> from reStructuredText, so has empty blocks at the places where
> it would be enough just to specify the empty value.
> 
> Index: usr.bin/mandoc/Makefile
> ===
> --- usr.bin/mandoc/Makefile   (revision 349971)
> +++ usr.bin/mandoc/Makefile   (working copy)
> @@ -101,4 +101,7 @@
>  CFLAGS.gcc+= -Wno-format
>  LIBADD=  openbsd z
>  
> +HAS_TESTS=
> +SUBDIR.${MK_TESTS}+= tests
> +
>  .include 
> Index: usr.bin/mandoc/tests/Makefile
> ===
> --- usr.bin/mandoc/te

Re: [CFT][patch] mandoc: don't segfault on empty tbl(1) continuation blocks

[Baptiste Daroussin]

On Tue, Jul 16, 2019 at 10:31:24PM +0300, Eygene Ryabinkin wrote:
> Good day.
> 
> Attached is the patch that makes built-in tbl(1) processor in mandoc
> to avoid dumping core when it renders the table with empty "T{ T}"
> block and horizontally-ruled table.
> 
> The simplest way to reproduce the issue is to either
>  - run 'man notmuch-config' with mail/notmuch installed;
>  - run 'mandoc tests/empty-table-cdata.1' against the attached
>test-only manpage.
> 
> With the patch applied, one can utilize 'make check': regression
> test was added.  Perhaps an invocation of
> {{{
> mtree -deU -f /usr/src/etc/mtree/BSD.tests.dist -p /usr/tests
> }}}
> will be needed to run 'make check' without remaking/installing
> the world.
> 
> The patch is for the fresh -CURRENT.  Be interested in any results
> of its application and usage.
> 
> Thanks!
> 
> P.S.: please, CC me: I am not subscribed to the list.
> -- 
> Eygene Ryabinkin,,,^..^,,,
> [ Life's unfair - but root password helps!   | codelabs.ru ]
> [ 82FE 06BC D497 C0DE 49EC  4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]

Hello,

Thank you for the patch! Have it been discussed with upstream? I kind of remind
something like this being reported to upstream, but I haven't checked the
status.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg: Cannot open /dev/null:No such file or directory

[Baptiste Daroussin]

On Tue, Jun 11, 2019 at 11:52:31AM -0700, Johannes Lundberg wrote:
> Hi
> 
> This is probably overkill but I've attached a diff that show my patches
> to image.sh. It's just a hack so far to make it do what I want and not
> meant as general purpose. Use the changes you need for your application.
> 
> Changes (only meant to work for building usb images on amd64 and i386)
> 
> - mount devfs so pkg will work properly
> - add "install packages from official repo" option so you won't have to
> build your own packages for each jail
> - downloaded packages from official repo is cached locally to avoid
> excessive downloads
> - hack for i386 so packages are installed properly
> - increase swap space to allow for kernel core dumps (for usb image)
> - execute post-install script "overlay.sh" in the jail if provided in
> the overlay folder
> 
> Bapt: Maybe you'll find some of these changes useful? :)
> 
The first I already committed days ago in poudriere, just I should have added it
as a patch to the poudriere version in ports, I will do it asap.

As for other improvements, sure they sounds like useful, would be happy to
review them if you make pull requests out of them!

Thanks a lot,
Bapt


signature.asc
Description: PGP signature

Re: pkg: Cannot open /dev/null:No such file or directory

[Baptiste Daroussin]

On Tue, Jun 04, 2019 at 07:32:16AM +0200, O. Hartmann wrote:
> Hello List,
> 
> lately I ran into a serious problem installing packages in a nanoBSD
> environment, in which the package repository server is "remotely" on site. The
> issue as documented below occurs on both 12-STABLE r348529 and CURRENT r348600
> and must have been introduced shortly, since the last known good installation
> with the environment of ours was on 21st May 2019.
> 
> As far as I know,, the package installation is performed via "chroot'ed"
> environment and somehow /dev/null is out of a sudden not accessible anymore
> while pkg tries to delegate some output to /dev/null.
> 
> What happened here?
> 
> Kind regards and thanks in advance,
> 
> oh
> 
> [...]
> All repositories are up to date.
> The following 10 package(s) will be affected (of 0 checked):
> 
> New packages to be INSTALLED:
> python3: 3_3 [zeit4]
> sudo: 1.8.27_1 [zeit4]
> devcpu-data: 1.22 [zeit4]
> python36: 3.6.8_2 [zeit4]
> readline: 8.0.0 [zeit4]
> indexinfo: 0.3.1 [zeit4]
> libffi: 3.2.1_3 [zeit4]
> gettext-runtime: 0.19.8.1_2 [zeit4]
> openldap-sasl-client: 2.4.47 [zeit4]
> cyrus-sasl: 2.1.27 [zeit4]
> 
> Number of packages to be installed: 10
> 
What is new is that pkg is using /dev/null as input when running script? this is
new since pkg 1.11 . Somehow this does not seems to be avaalaible in your
environement.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: What is evdev and autoloading?

[Baptiste Daroussin]

On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> > On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> > > On 2/18/19, Vladimir Kondratyev  wrote:
> > >> On 2019-02-17 21:03, Steve Kargl wrote:
> > >>> Anyone have insight into what evdev is?
> > >> evdev.ko is a small in-kernel library that makes all your input events
> > >> like keyboard presses libinput-compatible.
> > > 
> > > And libinput was created by the Freedesktop Wayland team to create
> > > pressure on OS people to make their systems Wayland-compatible.
> > > 
> > >>> I do not need nor what these modules loaded.
> > >> I think removing "option EVDEV_SUPPORT" from your kernel config should
> > >> disable most of evdev.ko dependencies
> > > 
> > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> > > as libinput not be part of the standard packages?
> > > 
> > > The Freedesktop Wayland team consists of people with the Kay Sievers
> > > mentality, which made Linus Torvalds ban his contributions. They do
> > > not care about the bugs they introduce, forcing others to clean up the
> > > mess they create.
> > > 
> > > I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> > 
> > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> > input device handling in X and Wayland.  Not having it means that a lot 
> > of input devices stop working, or work much worse.
> > 
> > We in the FreeBSD Graphics Team are working very hard to improve the 
> > FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> > and make current users use FreeBSD more.
> 
> Sadly your execution on that seems to be missing the mark,
> telling people they have to go get a port now to get drm working
> because it could not be maintained in base, and then telling them,
> oh, you need this new code in base so that it is so much easier
> to use graphical stuff this way.
> 
> These seem to be conflicting stories.
> 
You are missing the point, one does not evolve as fast as the other, meaning
one can be maintained within usual freebsd lifecycle, the other cannot or it
becomes very painful.

Bapt


signature.asc
Description: PGP signature

Re: WITH_CTF breaks CD loader: "File too big"

[Baptiste Daroussin]

On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
> Hi,
> 
> Building disc1.iso using `make release` and having WITH_CTF set in
> src.conf leads to "File too big" displayed when booting the image.
> 
> Would it make sense to build loader and related parts without CTF
> unconditionally as it doesn't look useful there?
> 

Fully agree with you

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: C.UTF-8 as default locale

[Baptiste Daroussin]

On Sun, Nov 04, 2018 at 09:35:48AM +0300, Yuri Pankov wrote:
> Hi,
> 
> Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the
> following entry:
> 
> - Make C.UTF-8 the default locale (conrad, dteske(installer))
> 
> As this sort of change is better done early, I have put togetger a
> simple change introducing C.UTF-8 locale using the same common LC_CTYPE
> map as other UTF-8 locales (and it's now the source of symlinks instead
> of en_US one), and having all other components use C locale:
> 
> https://reviews.freebsd.org/D17833
> 
> With that in place, next step is likely to be updating 'default' entry
> in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and
> changes to installer are likely to be not needed?
> 


Hey I never thought it could be done in such an easy way! don't know why,
I was always looking at it in a complex way, thus never started it.

Thank you very much, this looks fine to me! and that is imho a great addition

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: how to enforce one version of python

[Baptiste Daroussin]

On Tue, Sep 11, 2018 at 03:28:15PM +0100, tech-lists wrote:
> Hi,
> 
> There are a number of ports that seem to have their own preferential flavour
> of python, and some for example want to install python27 and python36 in the
> same place, and it's a pain when using portupgrade or similar tools.
> 
> I have this in my /etc/make.conf:
> 
> DEFAULT_VERSIONS+= python=2.7
> 
> Is this incorrect? I assume it must be, as for example devel/pylint
> (pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1
> 
That is because portupgrade is not flavor aware (or badly if it has been patched
to support flavors)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: IGNORE_OSVERSION=yes -- can't install pkg

[Baptiste Daroussin]

On Sat, May 05, 2018 at 10:47:36AM -0600, Ian Lepore wrote:
> On Sat, 2018-05-05 at 08:26 -0700, Chris H wrote:
> > On Fri, 04 May 2018 22:57:52 -0700  said
> > 
> > > 
> > > I just setup a jail from a 12-CURRENT I built awhile ago. It has no
> > > ports
> > > tree. So I'm attempting
> > > to install svnlite. issuing pkg search svnlite returns
> > > The package management tool is not yet installed on your system.
> > > Do you want to fetch and install it now? [y/N]: y
> > > Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/
> > > latest,
> > > please wait...
> > > Verifying signature with trusted certificate
> > > pkg.freebsd.org.2013102301...
> > > done
> > > [12current.localhost] Installing pkg-1.10.5...
> > > Newer FreeBSD version for package pkg:
> > > To ignore this error set IGNORE_OSVERSION=yes
> > > - package: 1200062
> > > - running kernel: 1200054
> > > Allow missmatch now?[Y/n]:
> > > 
> > > Umm, what? Should I ignore this error? If so, why is there an error
> > > at all?
> > > I answered no. Guess I won't be able to use pkg(8) on this jail(8).
> > > :-(
> > > 
> > > --Chris
> > OK the only reference[1] I can find regarding this, indicates that
> > answering "Y"
> > to Allow missmatch now? resulted in an ABI mismatch that caused
> > pkg(8) to be
> > unusable.
> > This is on an older version of 12, so I don't have anything that
> > might have
> > appeared in UPDATING. I really need this jail to resolve accumulating
> > pr(1)'s
> > on ports(7) I maintain.
> > 
> > Thank you.
> 
> The difference between 1200062 and 1200054 isn't going to affect
> anything except modules which are intimate with kernel internals, such
> as video drivers or virtualbox type stuff.
> 
> IMO, this new version checking done by pkg(8) is just bad Bad BAD. The
> only control you get is a knob that tells you to ignore any version
> mismatch. There appears to be no option to get the historical worked-
> really-well behavior of ignoring mismatches of the minor version for
> people who track -current.
> 

Except you devs are looking at it with a -CURRENT usage in mind.

Most of our users are running releases.

And you end up with en issue when let's say FreeBSD 10.0 is EOLed then the
packages are now built on 10.1, if people continue running 10.0 because for
instance they missed the notice about the 10.0 being EOL, they end up installing
packages that may be broken: new libc symbols for example, new syscalls etc.

This check was one of the number 1 request over the last 3 years...
For all people running -CURRENT they can add IGNORE_OSVERSION=yes.

More over, I received so many false bug report because actually developpers were
reporting "pkg is broken!!!" because they run pkg upgrade on a current system
that was 6+ month old or running pkg upgrade just after an ABI change that I
consider this warning worth it.

The only thing I would accept considering here is an advice on how to make the
tests more smooth for -CURRENT users. I consider an IGNORE_OSVERSION to be good
enough.

I might change in next versions of pkg the runtime OSVERSION detection reading
/bin/ls binary to be replaced by uname(1) to make it more friendly with
incremental rebuild.

Bapt


signature.asc
Description: PGP signature

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

[Baptiste Daroussin]

On Thu, Jan 18, 2018 at 11:32:26AM -0500, Ryan Stone wrote:
> On Wed, Jan 10, 2018 at 1:53 PM, Baptiste Daroussin <b...@freebsd.org> wrote:
> > One has to specify pkg -o OSVERSION=1200055 to allow packages built on 
> > 1200055
> > to install on 1200054.
> 
> This workaround doesn't appear to work for pkg bootstrap:
> 
> # pkg -o OSVERSION=1200055 bootstrap
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from
> pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest, please wait...
> Verifying signature with trusted certificate pkg.freebsd.org.2013102301... 
> done
> Installing pkg-1.10.4...
> pkg-static: Newer FreeBSD version for package pkg:
> - package: 1200055
> - running kernel: 1200054
> 
> Failed to install the following 1 package(s): /tmp//pkg.txz.ngJJEM

The bootstrap does not know about OSVERSION, but setting OSVERSION in your env
should fix it

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

[Baptiste Daroussin]

On Thu, Jan 11, 2018 at 08:57:34AM -0700, Ian Lepore wrote:
> On Wed, 2018-01-10 at 19:53 +0100, Baptiste Daroussin wrote:
> > On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote:
> > > 
> > > Hi All,
> > > 
> > > I use self built base packages. Seems that I have a problem with pkg.
> > > Today I've got this:
> > > ===
> > > % sudo pkg update -f
> > > Updating FreeBSD-base repository catalogue...
> > > Fetching meta.txz: 100%268 B   0.3kB/s00:01
> > > Fetching packagesite.txz: 100%   29 KiB  29.4kB/s00:01
> > > Processing entries:   0%
> > > pkg: Newer FreeBSD version for package FreeBSD-libulog:
> > > - package: 1200055
> > > - running kernel: 1200054
> > > pkg: repository FreeBSD-base contains packages for wrong OS version:
> > > FreeBSD:12:amd64
> > > Processing entries: 100%
> > > Unable to update repository FreeBSD-base
> > > [...]
> > > 
> > > % uname -aKU
> > > FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan
> > >  9 14:32:13 MSK 2018
> > > bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X  amd64
> > > 1200054 1200054
> > > 
> > > % pkg -v
> > > 1.10.4
> > > 
> > hum
> > 
> > pkg now has a mechanism to protect from installing too new package (aka 
> > packages
> > built on a more recent system than the system you are running on.
> > 
> > While this is great for ports this is a bit painful for upgrading base 
> > packages
> > when building on current
> > 
> > One has to specify pkg -o OSVERSION=1200055 to allow packages built on 
> > 1200055
> > to install on 1200054.
> > 
> > I need to figure out a mechanism to make this simpler to handle to upgrade 
> > of
> > base system while keeping this safety belt for users.
> > 
> > Any idea is welcome
> > 
> > Best regards,
> > Bapt
> 
> Is this new mechanism disabled if installing into something other than
> the live system, such as when using -c or -r (and maybe -j)?
> 

The new mechanism grab the information from the files in the userland, meaning,
-c, -r and -j will discover the OSVERSION of the target binaries

Bapt


signature.asc
Description: PGP signature

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

[Baptiste Daroussin]

On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote:
> Hi All,
> 
> I use self built base packages. Seems that I have a problem with pkg.
> Today I've got this:
> ===
> % sudo pkg update -f
> Updating FreeBSD-base repository catalogue...
> Fetching meta.txz: 100%268 B   0.3kB/s00:01
> Fetching packagesite.txz: 100%   29 KiB  29.4kB/s00:01
> Processing entries:   0%
> pkg: Newer FreeBSD version for package FreeBSD-libulog:
> - package: 1200055
> - running kernel: 1200054
> pkg: repository FreeBSD-base contains packages for wrong OS version:
> FreeBSD:12:amd64
> Processing entries: 100%
> Unable to update repository FreeBSD-base
> [...]
> 
> % uname -aKU
> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan
>  9 14:32:13 MSK 2018
> bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X  amd64
> 1200054 1200054
> 
> % pkg -v
> 1.10.4
> 
hum

pkg now has a mechanism to protect from installing too new package (aka packages
built on a more recent system than the system you are running on.

While this is great for ports this is a bit painful for upgrading base packages
when building on current

One has to specify pkg -o OSVERSION=1200055 to allow packages built on 1200055
to install on 1200054.

I need to figure out a mechanism to make this simpler to handle to upgrade of
base system while keeping this safety belt for users.

Any idea is welcome

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: what's changed with newsyslog?

[Baptiste Daroussin]

On Sun, Dec 17, 2017 at 04:41:29PM -0500, Michael Butler wrote:
> On 12/17/17 16:38, Ben Woods wrote:
> > On Mon, 18 Dec 2017 at 3:47 am, Michael Butler
> > > wrote:
> > 
> > In the past week or so I've been getting warnings like this ..
> > 
> > bzip2: Can't open input file /var/log/snmpd.log.0: No such file or
> > directory.
> > newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0
> > /var/log/fwlw_clean_log.0' terminated with a non-zero status (1)
> 
>  [ .. snip .. ]
> 
> > 
> > 
> > Hints?
> > 
> >         imb
> > 
> > Could this be related to bapt’s recent change 11 days ago to allow
> > newsyslog to use different style of compression commands?
> > https://svnweb.freebsd.org/base?view=revision=326617
> 
> Yes - I reverted to r326616 and the issue no longer appears,
> 
>   imb
> 

Should be fixed in r326930, sorry about that

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: RFC: Removing hpt* drivers from GENERIC

[Baptiste Daroussin]

On Thu, Oct 26, 2017 at 03:12:57AM +0100, Andrew Turner wrote:
> 
> > On 25 Oct 2017, at 22:43, Colin Percival  wrote:
> > 
> > Hi developers,
> > 
> > I'd like to remove the hpt* drivers from GENERIC.  These are the drivers
> > for the HighPoint storage hardware -- SATA (hptnr) and RAID (hpt27xx, 
> > hptiop,
> > hptmv, hptrr).
> > 
> > My reason for wanting to remove them is that the hpt27xx and hptnr drivers
> > spend ~150 ms in their DEVICE_PROBE routines every time the system boots.
> > Since they are roughly 1000x slower than the median driver, this is clearly
> > excessive; unfortunately the time is being spent inside a binary blob, so
> > there is no apparent way to fix the drivers.  (The other three drives from
> > the same vendor -- hptiop, hptmv, and hptrr -- don't exhibit this particular
> > bug, but I don't see any strong argument in favour of not removing them 
> > along
> > with the two problem drivers.)
> > 
> > All of these are available via kernel modules, so the impact upon users
> > should be minimal.  Obviously I would not plan on MFCing this change.
> > 
> > Any objections?
GOGOGO
> 
> Why are we building these binary blobs into the kernel? We don’t have the 
> source for these so it’s more difficult to audit them for security issues. If 
> the user wishes to load them as modules they are fine to do that, however I 
> don’t think we shouldn’t be linking any of these blobs in a GENERIC kernel.

I totally agree here!

Bapt


signature.asc
Description: PGP signature

Re: kqueue(2) changes

[Baptiste Daroussin]

On Fri, Jun 02, 2017 at 10:45:16AM +0300, Konstantin Belousov wrote:
> I implemented an option to specify absolute time for kqueue(2) timers,
> and did required type changes to support larger values in struct kevent.
> Please see https://reviews.freebsd.org/D11025 for the patch, including
> man page update, and for some more detailed explanation.
> 
> Please review.

For me that looks good. As one of those requesting for that change (actually
proxying the request from glib people for a appel's kqueue64 compatible
interface). I find this approach more clever.

As far as I remember it perfectly fits glib folks requirements (unfortunatly I
could not reach out any of them to review yet)

Here is a mail describing their requirement at the time:
https://lists.freebsd.org/pipermail/freebsd-hackers/2014-March/044451.html

In any case it opens the doors to be able to use kevent based timers with a
nanonsecond precision useful, so looks good to me.

Thank you,

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

[Baptiste Daroussin]

On Thu, May 25, 2017 at 01:12:51PM +0100, tj wrote:
> On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote:
> > On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote:
> > > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> > > > No the problem left is documentations available in share/doc.
> > > > 
> > > > I would like to push them elsewhere. Those documents are mostly useful 
> > > > for
> > > > historical reason (hence we want to keep them) but not really for daily 
> > > > use of
> > > > modern FreeBSD.
> > > > Another issue with those documentation, they are installed as 
> > > > text/ascii version
> > > > in base, which makes most of them not really readable (as the documents 
> > > > has not
> > > > be written for a ascii/text target but more for a PDF/html view - using 
> > > > pic(1)
> > > > for example)
> > > > 
> > > > A plan was to push as sources in the svn doc repository and continue to 
> > > > build
> > > > them. This approach also have an issue: over the time roff evolved a 
> > > > bit and
> > > > while working on heirloom doctools import I had to fix a bunch of 
> > > > markup to make
> > > > the rendering of those documents clean (also meaning almost noone 
> > > > should read
> > > > them considering some were not really readable).
> > > > 
> > > > What I want to propose now, it to render them as PDF (html?) once and 
> > > > push them
> > > > somewhere (to be defined) as static document on our documentation 
> > > > website.
> > > > Please doceng@ provide me a location where to push them.
> > > > 
> > > 
> > > Unless anyone on doceng@ objects within the next three days, I will
> > > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.
> > > 
> > 
> > Thank you,
> > 
> > For the record I have pushed the generated PDF:
> > https://people.freebsd.org/~bapt/pdfdocs/
> > 
> > The have been built with a modern groff and I forced the embedded fonts for 
> > all
> > fonts used.
> > 
> 
> Multicolumn doesn't render correct in firefox for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf
> 
> but is fine for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf
> 
> - [tj]

Fixed, and reuploaded. because there should be some caching on people.f.o you
cannot yet see the fixed version but I have fixed it. It is supposed to be a
monocolumn as far as I understand it.

Bapt


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

[Baptiste Daroussin]

On Thu, May 25, 2017 at 01:12:51PM +0100, tj wrote:
> On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote:
> > On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote:
> > > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> > > > No the problem left is documentations available in share/doc.
> > > > 
> > > > I would like to push them elsewhere. Those documents are mostly useful 
> > > > for
> > > > historical reason (hence we want to keep them) but not really for daily 
> > > > use of
> > > > modern FreeBSD.
> > > > Another issue with those documentation, they are installed as 
> > > > text/ascii version
> > > > in base, which makes most of them not really readable (as the documents 
> > > > has not
> > > > be written for a ascii/text target but more for a PDF/html view - using 
> > > > pic(1)
> > > > for example)
> > > > 
> > > > A plan was to push as sources in the svn doc repository and continue to 
> > > > build
> > > > them. This approach also have an issue: over the time roff evolved a 
> > > > bit and
> > > > while working on heirloom doctools import I had to fix a bunch of 
> > > > markup to make
> > > > the rendering of those documents clean (also meaning almost noone 
> > > > should read
> > > > them considering some were not really readable).
> > > > 
> > > > What I want to propose now, it to render them as PDF (html?) once and 
> > > > push them
> > > > somewhere (to be defined) as static document on our documentation 
> > > > website.
> > > > Please doceng@ provide me a location where to push them.
> > > > 
> > > 
> > > Unless anyone on doceng@ objects within the next three days, I will
> > > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.
> > > 
> > 
> > Thank you,
> > 
> > For the record I have pushed the generated PDF:
> > https://people.freebsd.org/~bapt/pdfdocs/
> > 
> > The have been built with a modern groff and I forced the embedded fonts for 
> > all
> > fonts used.
> > 
> 
> Multicolumn doesn't render correct in firefox for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf
> 
> but is fine for this:
> 
> https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf
> 
Good catch thanks! I will see what I can do

Bapt


signature.asc
Description: PGP signature

Re: The futur of the roff toolchain

[Baptiste Daroussin]

On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote:
> On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote:
> > No the problem left is documentations available in share/doc.
> > 
> > I would like to push them elsewhere. Those documents are mostly useful for
> > historical reason (hence we want to keep them) but not really for daily use 
> > of
> > modern FreeBSD.
> > Another issue with those documentation, they are installed as text/ascii 
> > version
> > in base, which makes most of them not really readable (as the documents has 
> > not
> > be written for a ascii/text target but more for a PDF/html view - using 
> > pic(1)
> > for example)
> > 
> > A plan was to push as sources in the svn doc repository and continue to 
> > build
> > them. This approach also have an issue: over the time roff evolved a bit and
> > while working on heirloom doctools import I had to fix a bunch of markup to 
> > make
> > the rendering of those documents clean (also meaning almost noone should 
> > read
> > them considering some were not really readable).
> > 
> > What I want to propose now, it to render them as PDF (html?) once and push 
> > them
> > somewhere (to be defined) as static document on our documentation website.
> > Please doceng@ provide me a location where to push them.
> > 
> 
> Unless anyone on doceng@ objects within the next three days, I will
> create a new directory for the PDFs under doc/head/en_US.ISO8859-1/.
> 

Thank you,

For the record I have pushed the generated PDF:
https://people.freebsd.org/~bapt/pdfdocs/

The have been built with a modern groff and I forced the embedded fonts for all
fonts used.

Best regards,
Bapt


signature.asc
Description: PGP signature

The futur of the roff toolchain

[Baptiste Daroussin]

Hi all,

I have been working for a while to try to import a modern roff toolchain into
base.

I didn't like the initial approach that consisted in simply removing all roff
toolchain in base.

Recap of the situation in base:
* We have GNU roff version 1.19.2 in base (latest GPLv2 version). Lots of bug
  fixes has been made upstream in newer version (GPLv3) in particular regarding
  unicode but not only. (and we cannot update it anymore)
* GNU roff is now only used to generate the documentation in share/doc and as a
  fallback for manpages which mandoc does not support.

On the manpages front:
* No manpages in base are not supported by mandoc except groff manpages
  themselves
* man(1) can fallback on ports version of groff if installed (for ports not
  providing manpages not compatible with mandoc)

Alternatives to GNU roff:
* Heirloom doctools (which I tried to import) licensed both CDDL/BSD (in C)
* neartoff http://litcave.rudi.ir/ BSD licensed (in C)

I went the road of using heirloom doctools it is 90% compatible with GNU roff,
good enough for all our base roff based documents.

After getting down that road for a while, including lots of patches sent
upstream (thanks them for being so reactive and integrating them quickly as well
as fixing the issues I wasn't able to fix myself quickly).

The problem is there are lot of corner small corner cases where heirloom is
different from GNU roff and hard to make it compatible. While this is corner
cases, it breaks document generation for some large documents people are
writing. Those users could use (and actually would benefit a lot from it) GNU
roff from the ports tree, but have to be careful about the path of the tool they
call to ensure only calling the one from GNU roff and not the one (with the same
name) from heirloom doctools.

Concerning neatroff it is barely compatible with GNU roff, so not an option
(last I tested at least).

I would like to change this approach and get back to the initial approach taken
by others before I jumped in and I would like just entirely remove the roff
toolchain from base and let people rely on GNU roff from ports.

man(1) is already asking the user to install groff from ports if the manpage
cannot be read with mandoc.

No the problem left is documentations available in share/doc.

I would like to push them elsewhere. Those documents are mostly useful for
historical reason (hence we want to keep them) but not really for daily use of
modern FreeBSD.
Another issue with those documentation, they are installed as text/ascii version
in base, which makes most of them not really readable (as the documents has not
be written for a ascii/text target but more for a PDF/html view - using pic(1)
for example)

A plan was to push as sources in the svn doc repository and continue to build
them. This approach also have an issue: over the time roff evolved a bit and
while working on heirloom doctools import I had to fix a bunch of markup to make
the rendering of those documents clean (also meaning almost noone should read
them considering some were not really readable).

What I want to propose now, it to render them as PDF (html?) once and push them
somewhere (to be defined) as static document on our documentation website.
Please doceng@ provide me a location where to push them.

And then remove bsd.doc.mk from FreeBSD 12.0 along with the removal of groff.
I also want to remove most of roff related tools (the one provided by toolchains
available in ports) for which we kept a BSD version (not really maintained in
base):
namely:
- checknr
- vgrind
- colcrt

Only keeping:
- col (useful in other places than roff)
- soelim (also used for manpages and we have a clean BSD licensed version which
  is also now parts of mandoc)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: make concurrency kit a module

[Baptiste Daroussin]

On Wed, May 17, 2017 at 06:04:09PM -0700, Adrian Chadd wrote:
> https://reviews.freebsd.org/D10778
> 

Except there are plans to use it elsewhere. Many areas may be improved using it.

Having it as a module would mean some devs might refrain from using it because
there is no waranty for it to be there

Areas like VFS and network stack could have a good benefice from using it.

Out of curiousity what size is saved?

Bapt


signature.asc
Description: PGP signature

Re: NFSv2 boot & OLD_NFSV2

[Baptiste Daroussin]

On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote:
> 
> > On 20 Mar 2017, at 23:55, Toomas Soome <tso...@me.com> wrote:
> > 
> >> 
> >> On 20. märts 2017, at 23:53, Rick Macklem <rmack...@uoguelph.ca> wrote:
> >> 
> >> Baptiste Daroussin wrote:
> >>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
> >>>> Hi!
> >>>> 
> >>>> The current boot code is building NFSv3, with preprocessor conditional 
> >>>> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
> >>>> 
> >>>> rgds,
> >>>> toomas
> >>> 
> >>> I vote burn
> >>> 
> >>> Bapt
> >> I would be happy to see NFSv2 go away. However, depending on how people 
> >> configure
> >> their diskless root fs, they do end up using NFSv2 for their root fs.
> >> 
> >> Does booting over NFSv3 affect this?
> >> 
> >> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle 
> >> is the same as
> >> the NFSv3 one, except padded with 0 bytes to 32bytes long).
> >> However, there might be non-FreeBSD NFS servers where the NFSv2 file 
> >> handle is different
> >> than the NFSv3 one and for that case, the user would need NFSv2 boot code 
> >> (or
> >> reconfigure their root fs to use NFSv3).
> >> 
> >> To be honest, I suspect few realize that they are using NFSv2 for their 
> >> root fs.
> >> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
> >> probably
> >> think they are using NFSv3 for their root fs.)
> >> 
> >> rick
> > 
> > if they do not suspect, they most likely use v3 - due to simple fact that 
> > you have to rebuild loader to use NFSv2 - it is compile time option.
> > 
> 
> old systems, 8.x, still use/boot v2, and so do old linux.
> NetApp has discontinued support for v2, so we had to move this machines to 
> use FreeBSD server and the day was
> saved. So, till these machines get upgraded/discontinued we have a problem. 
> There are several solutions
> to this issue, but as long as it's a matter of getting rid for the sake of 
> it, I would vote to keep it a while longer.
> 
> danny
> 
> 
Given you are speaking of 8.x I suppose you are using the loader that comes with
it, meaning you are safe if we remove it from the loader in 12.0 (note as said
by Toomas that is it is already off by default in the 12.0 loader) am I missing
something?

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: NFSv2 boot & OLD_NFSV2

[Baptiste Daroussin]

On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
> Hi!
> 
> The current boot code is building NFSv3, with preprocessor conditional 
> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
> 
> rgds,
> toomas

I vote burn

Bapt


signature.asc
Description: PGP signature

Re: MANPATH not handled correctly

[Baptiste Daroussin]

On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote:
> MANPATH is not handled correctly.  According to the documentation
> in apropos(1) and whatis(1):
> 
>   MANPATH   The standard search path used by man(1) may be changed by
> specifying a path in the MANPATH environment variable.  Invalid
> paths, or paths without manual databases, are ignored.
> Overridden by -M.  If MANPATH begins with a colon, it is
> appended to the default list; if it ends with a colon, it is
> prepended to the default list; or if it contains two adjacent
> colons, the standard search path is inserted between the
> colons.  If none of these conditions are met, it overrides the
> standard search path.
> 
> I have a manpage named mkpic in $HOME/man/man1.  I also have the FreeBSD
> installed manpages, e.g., /usr/share/man/man1/cat.1.gz.  If I have
> 'setenv MANPATH :$HOME/man' in my .cshrc file, then the following occurs:  
> 
> % setenv | grep MANPATH
> MANPATH=:/home/kargl/man
> % apropos mkpic
> (Warning: MANPATH environment variable set)
> mkpic(1) - construct a contour image in MIFF image format
> % apropos cat
> (Warning: MANPATH environment variable set)
> matrix(3) - Array and matrix allocation for FFT library
> 
> So, the above description of MANPATH is incorrect as :/home/kargl/man
> should have been appended to the default MANPATH.
> 
> Interestingly, manpath(1) seems to described what actually happens
> (long lines wrapped):
> 
> % unsetenv MANPATH
> % manpath
> /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\
>/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\
>/usr/local/share/xpdf/man
> % setenv MANPATH :$HOME/sman
> % manpath
> (Warning: MANPATH environment variable set)
> :/home/kargl/man
> 
> The expected result according apropos(1) and whatis(1) for last command is
> 
> % manpath
> /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\
>/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\
>/usr/local/share/xpdf/man:/home/kargl/man

Sorry it took time, but it is now fixed. the issue was we have kept our man(1)
when importing mandoc and I have not noticed that mandoc had that feature.

I implemented it in our man(1)

While here I removed the painful warning

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Problem with pkg

[Baptiste Daroussin]

On Mon, Feb 27, 2017 at 03:37:55PM +0100, Domagoj Stolfa wrote:
> Having the same issues, even after numerous attempts to manually fix it.
> 

This is a problem on the freebsd side a fix has been made, new repository should
be out soon

Only 12-CURRENT is inpacted right now
11.0-RELEASE amd64 was also inpacted but has been worked around

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Problem with x.org

[Baptiste Daroussin]

On Mon, Feb 13, 2017 at 12:40:41PM +, Filippo Moretti wrote:
> root@sting:~ # uname -a
> FreeBSD sting 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r313678M: Sun Feb 12 
> 18:37:07 CET 2017 root@sting:/usr/obj/usr/src/sys/STING_VT  i386After 
> upgrading to the latest x.org server I cannot start X as a normal user but 
> only as a root.I enclose the error in Xorg.0.log.oldFilippops I checked 
> permission of /usr/local/bin/Xorg and are correct

How did you upgrade to newer Xorg stack ?
portmaster? portupgrade?

if yes please rebuild again, those 2 tools are known in this case to pick wrong
decision in the rebuild order that result in this segfault, also depending on
user reports, they might miss some necessary rebuild (don't know why)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: recent change to vim defaults?

[Baptiste Daroussin]

On Wed, Jan 18, 2017 at 10:37:32AM -0700, Adam Weinberger wrote:
> > On 18 Jan, 2017, at 10:35, Julian Elischer <jul...@freebsd.org> wrote:
> > 
> > On 17/01/2017 1:23 AM, Adam Weinberger wrote:
> >>> On 16 Jan, 2017, at 9:25, Baptiste Daroussin <b...@freebsd.org> wrote:
> >>> 
> >>> On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
> >>>> I noticed that suddenly vim is grabbing mouse movements, which makes life
> >>>> really hard.
> >>>> 
> >>>> Was there a specific revision that brought in this change, and can it be
> >>>> removed?
> >>> This change appeared in one of the last patchset of vim 7.4 and was one 
> >>> of the
> >>> "features" of the vim 8.0 release.
> >>> 
> >>> I do agree this is just totally painful :(
> >>> 
> >>> Best regards,
> >>> Bapt
> >> One of the things that I inherited with the Vim port was the DEFAULT_VIMRC 
> >> option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't 
> >> touched it.
> >> 
> >> I have moused disabled in all my boxes so I have no idea about bad mouse 
> >> behaviour in Vim. If there is a bad default that is causing grief, let's 
> >> just fix it in that default vimrc.
> >> 
> >> I'm not really understanding what the unexpected behaviour is so I can't 
> >> make an intelligent recommendation myself, but I'll go with whatever you 
> >> folks suggest.
> >> 
> >> # Adam
> > I'm in iterm on my mac.
> > I ssh to a freebsd machine
> > I use vim on a file.
> > I used to be able to use the mouse on my mac to copy a few lines into the 
> > cut buffer.. slide-shift-click etc..
> > now suddenly if I try highlight some code in vim to copy it vim drags stuff 
> > around, scrolls up and down, deletes stuff and generally makes a mess.
> > if click, instead of starting a copy zone it grabs some of the text.
> > 
> > basically it makes hte mouse useless.
> > I can;t copy and paste from a file I'm ediitng. I end up having to exit vim 
> > and do it in vi.
> 
> There have been a number of recommendations in this thread for you, Julian, 
> including "set mouse=a" and "set mouse=v". Test some of them out and let me 
> know what works for you.

set mouse=
(with nothing) brings back the original behaviour

Bapt


signature.asc
Description: PGP signature

Re: recent change to vim defaults?

[Baptiste Daroussin]

On Mon, Jan 16, 2017 at 07:46:41PM +0300, Slawa Olhovchenkov wrote:
> On Mon, Jan 16, 2017 at 05:25:26PM +0100, Baptiste Daroussin wrote:
> 
> > On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
> > > I noticed that suddenly vim is grabbing mouse movements, which makes life
> > > really hard.
> > > 
> > > Was there a specific revision that brought in this change, and can it be
> > > removed?
> > 
> > This change appeared in one of the last patchset of vim 7.4 and was one of 
> > the
> > "features" of the vim 8.0 release.
> > 
> > I do agree this is just totally painful :(
> 
> Wat about edit 8-bit files in utf-8 locale?
> Still corrupted files?

What are you speaking about I never had this issue with vim

We had this issue with vi in base which is now worked arounded so it just fails
so save instead of corrupting (which is still bad but a bit better :))

Bapt


signature.asc
Description: PGP signature

Re: recent change to vim defaults?

[Baptiste Daroussin]

On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
> I noticed that suddenly vim is grabbing mouse movements, which makes life
> really hard.
> 
> Was there a specific revision that brought in this change, and can it be
> removed?

This change appeared in one of the last patchset of vim 7.4 and was one of the
"features" of the vim 8.0 release.

I do agree this is just totally painful :(

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: MANPATH not handled correctly

[Baptiste Daroussin]

On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote:
> MANPATH is not handled correctly.  According to the documentation
> in apropos(1) and whatis(1):
> 
>   MANPATH   The standard search path used by man(1) may be changed by
> specifying a path in the MANPATH environment variable.  Invalid
> paths, or paths without manual databases, are ignored.
> Overridden by -M.  If MANPATH begins with a colon, it is
> appended to the default list; if it ends with a colon, it is
> prepended to the default list; or if it contains two adjacent
> colons, the standard search path is inserted between the
> colons.  If none of these conditions are met, it overrides the
> standard search path.
> 
> I have a manpage named mkpic in $HOME/man/man1.  I also have the FreeBSD
> installed manpages, e.g., /usr/share/man/man1/cat.1.gz.  If I have
> 'setenv MANPATH :$HOME/man' in my .cshrc file, then the following occurs:  
> 
> % setenv | grep MANPATH
> MANPATH=:/home/kargl/man
> % apropos mkpic
> (Warning: MANPATH environment variable set)
> mkpic(1) - construct a contour image in MIFF image format
> % apropos cat
> (Warning: MANPATH environment variable set)
> matrix(3) - Array and matrix allocation for FFT library
> 
> So, the above description of MANPATH is incorrect as :/home/kargl/man
> should have been appended to the default MANPATH.
> 
> Interestingly, manpath(1) seems to described what actually happens
> (long lines wrapped):
> 
> % unsetenv MANPATH
> % manpath
> /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\
>/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\
>/usr/local/share/xpdf/man
> % setenv MANPATH :$HOME/sman
> % manpath
> (Warning: MANPATH environment variable set)
> :/home/kargl/man
> 
> The expected result according apropos(1) and whatis(1) for last command is
> 
> % manpath
> /home/kargl/man:/usr/local/man:/usr/share/man:/usr/share/openssl/man:\
>/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.20/perl/man:\
>/usr/local/share/xpdf/man:/home/kargl/man
> 
> Instead of (un)fixing the documentation for apropos(1) and whatis(1), it
> would be preferable to fix manpath to match the description in those
> manpages.  In addition, the Warning should be removed or at least an
> option should be available to suppress the (useless/annoying) Warning.
> This would restore man(1), apropros(1), and whatis(1) to its historical
> behavior prior to svn revision 213317.
> 
> If the documentation for apropos(1) and whatis(1) is unfixed, then manpath(1)
> should have HISTORY and BUGS sections.  The BUGS section should explicitly
> not that MANPATH is no longer a changeable environmental variable by a
> user without incurring the Warning.
> 

Sounds like a bug, I will have a look as soon as I can

Thanks for reporting,
Best regards,
Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1736 - Still Failing

[Baptiste Daroussin]

On Mon, Dec 19, 2016 at 12:01:45AM +0800, Li-Wen Hsu wrote:
> On Sun, Dec 18, 2016 at 15:39:50 +0100, Baptiste Daroussin wrote:
> > On Sun, Dec 18, 2016 at 03:18:47PM +0100, Dimitry Andric wrote:
> > > On 18 Dec 2016, at 12:48, jenkins-ad...@freebsd.org wrote:
> > > > 
> > > > FreeBSD_HEAD_amd64_gcc - Build #1736 - Still Failing:
> > > > 
> > > > Build information: 
> > > > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1736/
> > > ...
> > > > --- atf-check.full ---
> > > > /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem 
> > > > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1
> > > >  -std=c++11 -nostdinc++ -isystem 
> > > > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
> > > >  
> > > > -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> > > >  
> > > > -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> > > >  
> > > > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
> > > >  -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DHAVE_CONFIG_H 
> > > > -I/builds/FreeBSD_HEAD_amd64_gcc/contrib/atf -DATF_SHELL='"/bin/sh"' -g 
> > > > -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W 
> > > > -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wformat=2 
> > > > -Wno-format-extra-args -Wno-error=address -Wno-error=array-bounds 
> > > > -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align 
> > > > -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra 
> > > > -Wno-error=inline -Wno-error=logical-not-parentheses 
> > > > -Wno-error=strict-aliasing -Wno-error=uninitialized 
> > > > -Wno-error=unused-but-set-variable -Wno-error=unused-function 
> > > > -Wno-error=unused-value -Wno-error=strict-overflow 
> > > > -Wno-error=misleading-indentation -Wno-error=nonnull-compare 
> > > > -Wno-error=shift-negative-value -Wno-error=tautological-compare 
> > > > -Wno-error=unused-const-variable  -o atf-check.full  atf-check.o 
> > > > -lprivateatf-c++ -lprivateatf-c
> > > > --- all_subdir_lib ---
> > > > --- mulosi4.po ---
> > > > /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem 
> > > > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
> > > >  
> > > > -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> > > >  
> > > > -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> > > >  
> > > > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
> > > >  -B/usr/local/x86_64-freebsd/bin/ -pg  -O2 -pipe   -fpic 
> > > > -fvisibility=hidden -DVISIBILITY_HIDDEN 
> > > > -I/builds/FreeBSD_HEAD_amd64_gcc/contrib/libcxxrt -MD  
> > > > -MF.depend.mulosi4.po -MTmulosi4.po -std=gnu99 -fstack-protector-strong 
> > > > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized 
> > > > -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds 
> > > > -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align 
> > > > -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra 
> > > > -Wno-error=inline -Wno-error=logical-not-parentheses 
> > > > -Wno-error=strict-aliasing -Wno-error=uninitialized 
> > > > -Wno-error=unused-but-set-variable -Wno-error=unused-function 
> > > > -Wno-error=unused-value -Wno-error=strict-overflow 
> > > > -Wno-error=misleading-indentation -Wno-error=nonnull-compare 
> > > > -Wno-error=shift-negative-value -Wno-error=tautological-compare 
> > > > -Wno-error=unused-const-variable -c 
> > > > /builds/FreeBSD_HEAD_amd64_gcc/contrib/compiler-rt/lib/builtins/mulosi4.c
> > > >  -o mulosi4.po
> > > > --- all_subdir_bin ---
> > > > --- dd.1.gz ---
> > > > gzip -cn /builds/FreeBSD_HEAD_amd64_gcc/bin/dd/dd.1 > dd.1.gz
> > > > --- dd.debug ---
> > > > /usr/local/x86_64-freebsd/bin/objcopy --only-keep-debug dd.full dd.debug
> > > > --- dd ---
> > > > /usr/local/x86_64-freebsd/bin/objcopy --strip-debug 
> > > > --add-gnu-debuglink=dd.debug  dd.full dd
> > > > --- all_subdir_bin/df ---
> > > > ===> bin/df (all)
> > > > --- all_subdir_libexec ---
> > > > /usr/local/bin/x86_64-freebsd-ld: atf-check.o: relocation R_X86_64_32 
> > > > against symbol `_ZTIN3atf12system_errorE' can not be used when making a 
> > > > shared object; recompile with -fPIC
> > > > /usr/local/bin/x86_64-freebsd-ld: final link failed: Nonrepresentable 
> > > > section on output
> > > > collect2: error: ld returned 1 exit status
> > > > *** [atf-check.full] Error code 1
> > > 
> > > Baptiste, is this the problem again with -lstdc++ being linked in 
> > > accidentally again?
> > 
> > Should not be, is the object directory always cleaned before building? by
> > cleaned I mean rm -rf
> 

There was another mistake in amd64-gcc which I have just fixed and would make
updating to 6.2.0 wait another round of package build

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1736 - Still Failing

[Baptiste Daroussin]

On Sun, Dec 18, 2016 at 03:18:47PM +0100, Dimitry Andric wrote:
> On 18 Dec 2016, at 12:48, jenkins-ad...@freebsd.org wrote:
> > 
> > FreeBSD_HEAD_amd64_gcc - Build #1736 - Still Failing:
> > 
> > Build information: 
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1736/
> ...
> > --- atf-check.full ---
> > /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem 
> > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1
> >  -std=c++11 -nostdinc++ -isystem 
> > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
> >  
> > -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >  
> > -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >  
> > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
> >  -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DHAVE_CONFIG_H 
> > -I/builds/FreeBSD_HEAD_amd64_gcc/contrib/atf -DATF_SHELL='"/bin/sh"' -g 
> > -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W 
> > -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wformat=2 
> > -Wno-format-extra-args -Wno-error=address -Wno-error=array-bounds 
> > -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align 
> > -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra 
> > -Wno-error=inline -Wno-error=logical-not-parentheses 
> > -Wno-error=strict-aliasing -Wno-error=uninitialized 
> > -Wno-error=unused-but-set-variable -Wno-error=unused-function 
> > -Wno-error=unused-value -Wno-error=strict-overflow 
> > -Wno-error=misleading-indentation -Wno-error=nonnull-compare 
> > -Wno-error=shift-negative-value -Wno-error=tautological-compare 
> > -Wno-error=unused-const-variable  -o atf-check.full  atf-check.o 
> > -lprivateatf-c++ -lprivateatf-c
> > --- all_subdir_lib ---
> > --- mulosi4.po ---
> > /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem 
> > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
> >  
> > -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >  
> > -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >  
> > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
> >  -B/usr/local/x86_64-freebsd/bin/ -pg  -O2 -pipe   -fpic 
> > -fvisibility=hidden -DVISIBILITY_HIDDEN 
> > -I/builds/FreeBSD_HEAD_amd64_gcc/contrib/libcxxrt -MD  
> > -MF.depend.mulosi4.po -MTmulosi4.po -std=gnu99 -fstack-protector-strong 
> > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign 
> > -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes 
> > -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered 
> > -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline 
> > -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing 
> > -Wno-error=uninitialized -Wno-error=unused-but-set-variable 
> > -Wno-error=unused-function -Wno-error=unused-value 
> > -Wno-error=strict-overflow -Wno-error=misleading-indentation 
> > -Wno-error=nonnull-compare -Wno-error=shift-negative-value 
> > -Wno-error=tautological-compare -Wno-error=unused-const-variable -c 
> > /builds/FreeBSD_HEAD_amd64_gcc/contrib/compiler-rt/lib/builtins/mulosi4.c 
> > -o mulosi4.po
> > --- all_subdir_bin ---
> > --- dd.1.gz ---
> > gzip -cn /builds/FreeBSD_HEAD_amd64_gcc/bin/dd/dd.1 > dd.1.gz
> > --- dd.debug ---
> > /usr/local/x86_64-freebsd/bin/objcopy --only-keep-debug dd.full dd.debug
> > --- dd ---
> > /usr/local/x86_64-freebsd/bin/objcopy --strip-debug 
> > --add-gnu-debuglink=dd.debug  dd.full dd
> > --- all_subdir_bin/df ---
> > ===> bin/df (all)
> > --- all_subdir_libexec ---
> > /usr/local/bin/x86_64-freebsd-ld: atf-check.o: relocation R_X86_64_32 
> > against symbol `_ZTIN3atf12system_errorE' can not be used when making a 
> > shared object; recompile with -fPIC
> > /usr/local/bin/x86_64-freebsd-ld: final link failed: Nonrepresentable 
> > section on output
> > collect2: error: ld returned 1 exit status
> > *** [atf-check.full] Error code 1
> 
> Baptiste, is this the problem again with -lstdc++ being linked in 
> accidentally again?

Should not be, is the object directory always cleaned before building? by
cleaned I mean rm -rf

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing

[Baptiste Daroussin]

On Sat, Dec 17, 2016 at 06:29:09PM +0100, Dimitry Andric wrote:
> On 15 Dec 2016, at 18:56, Li-Wen Hsu  wrote:
> > 
> > On Thu, Dec 15, 2016 at 12:42:00 +0100, Dimitry Andric wrote:
> >> On 15 Dec 2016, at 12:03, jenkins-ad...@freebsd.org wrote:
> >>> 
> >>> FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing:
> >>> 
> >>> Build information: 
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/
> >>> Full change log: 
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/changes
> >>> Full build log: 
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/console
> >> ...
> >>> building shared library libprivatedevdctl.so.0
> >>> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem 
> >>> /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1
> >>>  -std=c++11 -nostdinc++ -isystem 
> >>> /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
> >>>  
> >>> -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >>>  
> >>> -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >>>  
> >>> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
> >>>  -B/usr/local/x86_64-freebsd/bin/ -fstack-protector-strong -shared -Wl,-x 
> >>> -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o 
> >>> libprivatedevdctl.so.0.full -Wl,-soname,libprivatedevdctl.so.0  
> >>> `NM='/usr/local/x86_64-freebsd/bin/nm' NMFLAGS='' lorder consumer.pico 
> >>> event.pico event_factory.pico exception.pico guid.pico |  tsort -q`
> >>> /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++
> >> 
> >> Dear Jenkins admins, can you please install a more recent version of
> >> amd64-xtoolchain-gcc on the slave?  This is required to avoid the above
> >> error about not being able to find libstdc++.
> > 
> > Also from the console log:
> > 
> > + sudo pkg install -y devel/amd64-xtoolchain-gcc
> > Updating FreeBSD repository catalogue...
> > FreeBSD repository is up-to-date.
> > All repositories are up-to-date.
> > Checking integrity... done (0 conflicting)
> > The most recent version of packages are already installed
> > 
> > The build script install/update the latest devel/amd64-xtoolchain-gcc
> > package.  I think the problem is we did not upgrade the dependencies.  I
> > cannot think of a elegant way to upgrade all amd64-xtoolchain-gcc's
> > dependencies, so I added a line to build script to upgrade everything
> > before build.
> > 
> > Let see if this works.
> 
> See https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/1735/, it
> doesn't seem to be able to find the correct package:
> 
> + sudo pkg install -y devel/amd64-xtoolchain-gcc
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> pkg: No packages available to install matching 'devel/amd64-xtoolchain-gcc' 
> have been found in the repositories
> 
yes it was broken, I have fixed it since, so would be in the next update of the
reposirory

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: CURRENT: pkg broken on r309320

[Baptiste Daroussin]

On Wed, Nov 30, 2016 at 12:10:31PM +, Matthew Seaman wrote:
> On 2016/11/30 10:14, Baptiste Daroussin wrote:
> > revert r309314 the issue is there:
> > 
> > The ports tree defines PKG_CMD as pkg register but now bsd.own.mk 
> > predefines it
> > to simply pkg.
> > 
> > There is a collision there.
> > 
> 
> Pointy hat to me.  I'll revert that commit.
> 
>   Matthew
> 

I have proposed https://reviews.freebsd.org/D8677 instead which make sense and
does not require your to modify bsd.own.mk

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: CURRENT: pkg broken on r309320

[Baptiste Daroussin]

On Wed, Nov 30, 2016 at 10:22:28AM +0100, O. Hartmann wrote:
> Running CURRENT, r309320 and try to update ports. After the port has been 
> build, pkg
> fails to install the port quitting with:
> 
> pkg: illegal option -- i
> DBG(1)[67562]> pkg initialized
> pkg: unknown command: /usr/ports/www/libwww/work/stage
> 
> For more information on available commands and options see 'pkg help'.
> *** Error code 64
> 
> Stop.
> make: stopped in /usr/ports/www/libwww
> 
> Seems there has been introduced a bug since rr309298
> 
> Kind regards,
> Oliver

revert r309314 the issue is there:

The ports tree defines PKG_CMD as pkg register but now bsd.own.mk predefines it
to simply pkg.

There is a collision there.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: r308432: Capsicumized `basename` make zsh prompt broken

[Baptiste Daroussin]

On Mon, Nov 28, 2016 at 02:05:49AM -0500, Allan Jude wrote:
> On 2016-11-27 23:55, Conrad Meyer wrote:
> > Hi Iblis,
> > 
> > I see no such problem running 'basename $HOME' in a normal shell 
> > environment:
> > 
> >> $ basename $HOME
> >> cmeyer
> > 
> > I suppose in your use, perhaps stdin is already closed?  I think this
> > is a limitation of caph_limit_stdio() in general.
> > 
> > Can you try instead:
> > 
> > function set_prompt {
> > prompt="$(basename $HOME < /dev/null) >"
> > }
> > 
> > And see if it resolves the issue?
> > 
> > Thanks,
> > Conrad
> > 
> > On Sun, Nov 27, 2016 at 8:33 PM, iblis  wrote:
> >> Hi,
> >> Here is a minimal config of zsh prompt invoking `basename`:
> >> ```
> >> └─[iblis@abeing]% cat /home/ib-test/.zshenv
> >>
> >> function set_prompt {
> >> prompt="$(basename $HOME) >"
> >> }
> >>
> >> function zle-line-init zle-keymap-select {
> >> set_prompt
> >> zle reset-prompt
> >> }
> >>
> >> zle -N zle-line-init
> >> zle -N zle-keymap-select
> >>
> >> set_prompt
> >> ```
> >>
> >> and launching zsh will get something like this:
> >>
> >> ```
> >> └─[iblis@abeing]% sudo su ib-test
> >>
> >> ib-test >basename: capsicum: Bad file descriptor
> >>>
> >>> basename: capsicum: Bad file descriptor
> >>>
> >> ```
> >>
> >>
> >> To be honest, I have no idea about what casper/caspicum is. I just changed
> >> the `basename.c` and zsh work again.
> >>
> >> Index: basename.c
> >> ===
> >> --- basename.c (revision 309213)
> >> +++ basename.c (working copy)
> >> @@ -65,7 +65,7 @@
> >>
> >> setlocale(LC_ALL, "");
> >>
> >> - if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
> >> + if (cap_enter() < 0 && errno != ENOSYS)
> >> err(1, "capsicum");
> >>
> >> aflag = 0;
> >>
> >>
> >> Any idea?
> >>
> >> --
> >> Iblis Lin
> >> ___
> >> 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-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> 
> IIRC, bapt@ specifically mentioned this case in the review for
> caph_limit_stdio() or one of the reviews that lead to the creation of
> the helpers.

I mention this is the review of the cap_helpers themselves. I still think
caph_limit_stdio should grow a flag for testing that. I figured out the issue
based on one of the conversion to capsicum by Conrad on I don't remember which
tool.

Bapt


signature.asc
Description: PGP signature

Re: installworld fails on missing tzsetup when WITHOUT_DIALOG is set

[Baptiste Daroussin]

On Sun, Oct 23, 2016 at 11:41:23AM +0300, Guy Yur wrote:
> On Sat, Oct 22, 2016 at 7:23 PM, Baptiste Daroussin <b...@freebsd.org> wrote:
> > On Sat, Oct 22, 2016 at 06:51:28PM +0300, Guy Yur wrote:
> >> Hi,
> >> ...
> >
> > My proposal is a bit different: build tzsetup without dialog support :)
> >
> > https://reviews.freebsd.org/D8325
> >
> > Best regards,
> > Bapt
> 
> Thanks.

FYI it is in

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: installworld fails on missing tzsetup when WITHOUT_DIALOG is set

[Baptiste Daroussin]

On Sat, Oct 22, 2016 at 06:51:28PM +0300, Guy Yur wrote:
> Hi,
> 
> installworld fails on missing tzsetup when src.conf has WITHOUT_DIALOG=
> and delete-old was previously run to remove tzsetup from the system.
> 
> mkdir -p /tmp/install.8gNIwAFV
> progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp
> date echo egrep find grep id install   ln make mkdir mtree mv pwd_mkdb
>  rm sed services_mkdb sh strip sysctl test true uname wc zic tzsetup
> makewhatis; do  if progpath=`which $prog`; then  echo $progpath;  else
>  echo "Required tool $prog not found in PATH." >&2;  exit 1;  fi;
> done);  libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort
> -u |  while read line; do  set -- $line;  if [ "$2 $3" != "not found"
> ]; then  echo $2;  else  echo "Required library $1 not found." >&2;
> exit 1;  fi;  done);  cp $libs $progs /tmp/install.8gNIwAFV
> Required tool tzsetup not found in PATH.
> *** Error code 1
> 
> tzsetup is used in share/zoneinfo/Makefile when ${DESTDIR}/var/db/zoneinfo
> exists and some other conditions.
> 
> In my case, I don't have /var/db/zoneinfo since I manually created a symlink
> from /usr/share/zoneinfo/... to /etc/localtime instead of using tzsetup.
> 
> A possible fix is to add a WITHOUT_TZSETUP knob and not use
> tzsetup when the knob is enabled.
> 
> https://github.com/guyyur/freebsd-src_patches/blob/master/without_tzsetup_knob.patch
> (patch doesn't include regenerating src.conf.5)
> 
> Thanks,
> Guy
> ___

My proposal is a bit different: build tzsetup without dialog support :)

https://reviews.freebsd.org/D8325

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] remove GNU rcs from FreeBSD 12

[Baptiste Daroussin]

On Sun, Sep 11, 2016 at 10:17:26AM -0600, Warner Losh wrote:
> On Sun, Sep 11, 2016 at 7:38 AM, Baptiste Daroussin <b...@freebsd.org> wrote:
> > hi,
> >
> > For long we are planning to remove GNU rcs from base, after a failed attempt
> > before FreeBSD 10.0. Let see where we are to be able to remove it from 
> > FreeBSD
> > 12.
> >
> > GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
> > updates/fixes.
> >
> > From previous discussions there were issues that has been raised in previous
> > attempts:
> > - ident(1) is still useful given we still have Keywords in our sources. It 
> > has
> >   been replaced by a BSD Licensed version (enhanced to improve compatibility
> >   with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
> >   after removal of GNU rcs.
> 
> So no affect.
> 
> > - etc-update uses merge(1) from GNU rcs, this has been changed in head to 
> > use
> >   diff3 instead.
> 
> Also no effect. Is our diff3 still the gpl'd one, or has bsd-diff
> finally grown that functionality?

Not yet bsd diff and bsd diff3 are very far from mature, however the sdiff(1)
part has landed as I have finished it. I still have plans for other diff
components.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] remove GNU rcs from FreeBSD 12

[Baptiste Daroussin]

On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote:
> hi,
> 
> For long we are planning to remove GNU rcs from base, after a failed attempt
> before FreeBSD 10.0. Let see where we are to be able to remove it from FreeBSD
> 12.
> 
> GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
> updates/fixes.
> 
> From previous discussions there were issues that has been raised in previous
> attempts:
> - ident(1) is still useful given we still have Keywords in our sources. It has
>   been replaced by a BSD Licensed version (enhanced to improve compatibility
>   with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
>   after removal of GNU rcs.
> - etc-update uses merge(1) from GNU rcs, this has been changed in head to use
>   diff3 instead.
> - rc.subr allows to use rcs for the backup file functionality. This
>   functionality is off by default as such I plan to make a warning if rcs is 
> not
>   installed and recommand to install rcs from base (or if noone claim using 
> the
>   feature I will just remove the functionality and only keep the default
>   behaviour aka keep one backup copy).
> - people uses rcs to handle configuration files in /etc for example. for those
>   multiple compatible alternatives are available in ports:
>   * rcs57: a copy of the latest version of GNU rcs in base before removal
> (GPLv2)
>   * rcs: latest GNU rcs version (GPLv3)
> 
> I haven't gone the direction of importing OpenRCS (BSD licensed version from
> OpenBSD) as it needs way more work to be 100% compatible with latest version 
> of
> GNU rcs.
> 
> How to proceed:
> - First turn off GNU rcs by default for a couple of month.
> - Totally remove GNU rcs if no blockers has been raised.
> 
> Best regards,
> Bapt

I forgot to say freebsd-update uses merge(1) and which I will replaced with
diff3(1).

Best regards,
Bapt


signature.asc
Description: PGP signature

[RFC] remove GNU rcs from FreeBSD 12

[Baptiste Daroussin]

hi,

For long we are planning to remove GNU rcs from base, after a failed attempt
before FreeBSD 10.0. Let see where we are to be able to remove it from FreeBSD
12.

GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
updates/fixes.

From previous discussions there were issues that has been raised in previous
attempts:
- ident(1) is still useful given we still have Keywords in our sources. It has
  been replaced by a BSD Licensed version (enhanced to improve compatibility
  with Subversion Keyword) for FreeBSD 11. So that tool will remain in base
  after removal of GNU rcs.
- etc-update uses merge(1) from GNU rcs, this has been changed in head to use
  diff3 instead.
- rc.subr allows to use rcs for the backup file functionality. This
  functionality is off by default as such I plan to make a warning if rcs is not
  installed and recommand to install rcs from base (or if noone claim using the
  feature I will just remove the functionality and only keep the default
  behaviour aka keep one backup copy).
- people uses rcs to handle configuration files in /etc for example. for those
  multiple compatible alternatives are available in ports:
  * rcs57: a copy of the latest version of GNU rcs in base before removal
(GPLv2)
  * rcs: latest GNU rcs version (GPLv3)

I haven't gone the direction of importing OpenRCS (BSD licensed version from
OpenBSD) as it needs way more work to be 100% compatible with latest version of
GNU rcs.

How to proceed:
- First turn off GNU rcs by default for a couple of month.
- Totally remove GNU rcs if no blockers has been raised.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: date(1) default format changed between 10.3 and 11.0-BETA3

[Baptiste Daroussin]

On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote:
> On Friday,  5 August 2016 at 18:56:33 +0300, Andrey A. Chernov wrote:
> > On 05.08.2016 18:44, Mark Martinec wrote:
> >> On 2016-08-05 17:23, Andrey Chernov wrote:
> >>> On 05.08.2016 17:47, Mark Martinec wrote:
>  [Bug 211598]
>    date(1) default format in en_EN locale breaks compatibility with 10.3
>  and violates POSIX
> 
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211598
> >>>
> >>> It breaks compatibility but not violates POSIX. POSIX care of only its
> >>> own POSIX (or C) locale.
> >>
> >> POSIX does say that the default format should be the same
> >> as with "+%a %b %e %H:%M:%S %Z %Y".
> >> It also says that %a and %b are locale's abbreviated names.
> >
> > It is true for _POSIX_ locale only, as I already say. en_US.* is not
> > POSIX or C locale.
> 
> It still violates POLA.
> 
I really do not think that it violates POLA fiven that the behaviour you are
expecting is still available in the default configurtion that is still POSIX.

Set LC_TIME to C and then you are back on your behaviour (and this is the
default when you install FreeBSD).

locales should be seen as tzdata for exemple, they are a moving target
complicated to handle for every locale we do support: 78 for 11.0-RELEASE and
193 if we do count the encoding variants. locales are updated very often (for
exemple cldr unicode make a new release of the data every 8 month or so)

No locales defines the same date format and that was already the case before the
change we did

Now if people have strong arguments for a specific locale I'm inclined to add
some hacks in our tool that generates our locales to make sure we fix the
upstream data (http://cldr.unicode.org) we already committed some and I'm
planning to report upstream (cldr) all the issues we have faced to improve.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: IWM(7260), no connect

[Baptiste Daroussin]

On Thu, Jul 28, 2016 at 06:10:26PM -0500, Larry Rosenman wrote:
> negative.  no reponse (except for this one) at all.
> :(
> 
He did reply:

https://lists.freebsd.org/pipermail/freebsd-wireless/2016-July/006897.html

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Weekday missing in date(1) output

[Baptiste Daroussin]

On Mon, Jul 04, 2016 at 01:45:11PM +0200, Trond Endrestøl wrote:
> On Mon, 4 Jul 2016 08:34+0200, Baptiste Daroussin wrote:
> 
> > On Sun, Jul 03, 2016 at 10:17:54PM +0200, Thomas Eberhardt wrote:
> > > % uname -a
> > > FreeBSD clarence.ocp.lan 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #0 r302324: Sun 
> > > Jul  3 21:27:41 CEST 2016 
> > > tho...@clarence.ocp.lan:/usr/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > > % env LANG=en_US.UTF-8 date
> > > Sunday, July  3, 2016 at 10:14:21 PM CEST
> > > % env LANG=de_DE.UTF-8 date
> > >  3. Juli 2016 um 22:14:22 CEST
> > > 
> > > stable10 gives:
> > > % env LANG=de_DE.UTF-8 date
> > > So  3 Jul 2016 19:34:18 CEST
> > > 
> > > Is this intentional?
> > > 
> > I have readded the weekday in most locales, I will recheck all of them to 
> > ensure
> > the weekday is readded everywhere it was expected
> 
> nb_NO.UTF-8 and nb_NO.ISO8859-1 are also affected.
> 
Sorry it took long, but done: r303219

I will merge it on 11 tomorrow

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: UTF-8 by default?

[Baptiste Daroussin]

On Wed, Jul 20, 2016 at 10:36:13PM +0200, Herbert J. Skuhra wrote:
> Baptiste Daroussin skrev:
> > 
> > On Wed, Jul 20, 2016 at 10:47:45AM -0230, Jonathan Anderson wrote:
> >> On 20 Jul 2016, at 9:13, Tim Čas wrote:
> >> 
> >> > So, without further ado:
> >> > 1) What are the reasons that UTF-8 isn't the default yet?
> >> > 2) Would it be possible to make this the default in 11.0? What about
> >> > 12.0?
> >> > 3) Assuming an effort is started towards making UTF-8 the default,
> >> > what changes would be required?
> >> 
> >> At least according to one of my students (who makes more extensive use of
> >> i18n than I do), enabling UTF-8 by default is pretty straightforward:
> >> 
> >> https://github.com/musec/freebsd/wiki/Common-setup#utf-8-support
> > 
> > the LC_COLLATE=C is not needed anymore with freebsd 11+
> 
> Weird, when I set LC_ALL or LC_COLLATE to nb_NO.UTF-8 I can no longer
> run ls in $HOME. It hangs until I kill it. Same happens with
> da_DK.UTF-8; no problem with sv_SE.UTF-8 or en_GB.UTF-8.
> 
> I am running FreeBSD 11.0-BETA1 i386 (r302984) and I think someone
> else reported a similiar issue earlier.

This has been fixed in stable/11 just a few minutes ago

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: UTF-8 by default?

[Baptiste Daroussin]

On Wed, Jul 20, 2016 at 09:22:23PM +0200, Tim Čas wrote:
> On 20 July 2016 at 20:33, Don Lewis  wrote:
> > wc(1) has problems with its multibyte support pointed out by Coverity
> > as I recall.
> 
> Not sure how critical that issue is (e.g. byte counts [`-c`], line
> counts [`-l`], and such should still work as intended; whether word
> counts work or not depends on whether we should count Unicode
> whitespace as, well, whitespace). I do wonder if everyone agrees that
> an effort should be made towards UTF-8 default, though?
> 
> I'm willing to contribute some of my time to fixing these bugs, but I
> don't think I can fix *all* of this by myself. I guess wc(1) is as
> good a start as any, but I'd first like to talk to whoever is the
> maintainer for that bit of code, as I've never done any work in base
> before (only in ports).

good I would recommand to have a look at work done in OpenBSD in that regards,
since about a year Ingo Schwarze is atting UTF-8 support to all the tool in
their base system, including wc(1) not sure how theirs differs from our.

If working on that do not hesitate to push the changes you do propose in
phabricator:
https://reviews.freebsd.org and add me as a reviewer

https://wiki.freebsd.org/CodeReview might be useful to determine how to simply
use phabricator.

Do not hesitate to mail me if you need any help in that area.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: UTF-8 by default?

[Baptiste Daroussin]

On Wed, Jul 20, 2016 at 08:38:14PM +0200, Joel Dahl wrote:
> On Wed, Jul 20, 2016 at 04:07:41PM +0200, Baptiste Daroussin wrote:
> > On Wed, Jul 20, 2016 at 10:47:45AM -0230, Jonathan Anderson wrote:
> > > On 20 Jul 2016, at 9:13, Tim Čas wrote:
> > > 
> > > > So, without further ado:
> > > > 1) What are the reasons that UTF-8 isn't the default yet?
> > > > 2) Would it be possible to make this the default in 11.0? What about
> > > > 12.0?
> > > > 3) Assuming an effort is started towards making UTF-8 the default,
> > > > what changes would be required?
> > > 
> > > At least according to one of my students (who makes more extensive use of
> > > i18n than I do), enabling UTF-8 by default is pretty straightforward:
> > > 
> > > https://github.com/musec/freebsd/wiki/Common-setup#utf-8-support
> > 
> > the LC_COLLATE=C is not needed anymore with freebsd 11+
> > > 
> > > If there's anything missing there, I'd love to hear about it.
> > > 
> >   - unicode support in our old groff is pretty bad, I plan to replace it 
> > with
> > heirloom-doctools which does handle unicode propertly (as far I have 
> > tested
> > at least)
> 
> I haven't really been paying attention lately so things might have changed,
> but why can't we just remove groff now? We have mdocml, and for people that
> really need the groff functionality can just install it or heirloom-doctools
> from ports. The initial plan was to remove groff after we imported mdocml, but
> it was never removed and I lost interest, so again, things might have changed
> since then.

We have roff documentation in based, plus a lot of people argues that not havin
a roff toolchain in base is an issue for them.

heirloom doctools upstream is friendly, they fixed all the bugs I reported or
merged my fixes if needed, they have a good compatibility so the fallback in
man(1) could be done on something in base if mandoc cannot render properly some
manpages.

Upstream is CDDL but all new code is BSD licensed.

Importing is not hard, just need some motivation to finish all the required
makefiles :)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: UTF-8 by default?

[Baptiste Daroussin]

On Wed, Jul 20, 2016 at 10:47:45AM -0230, Jonathan Anderson wrote:
> On 20 Jul 2016, at 9:13, Tim Čas wrote:
> 
> > So, without further ado:
> > 1) What are the reasons that UTF-8 isn't the default yet?
> > 2) Would it be possible to make this the default in 11.0? What about
> > 12.0?
> > 3) Assuming an effort is started towards making UTF-8 the default,
> > what changes would be required?
> 
> At least according to one of my students (who makes more extensive use of
> i18n than I do), enabling UTF-8 by default is pretty straightforward:
> 
> https://github.com/musec/freebsd/wiki/Common-setup#utf-8-support

the LC_COLLATE=C is not needed anymore with freebsd 11+
> 
> If there's anything missing there, I'd love to hear about it.
> 

Lot of work has been done during the 11.0 development the following issues were
fixed:

/bin/sh not able to handle utf-8 (fixed by fixing the bug in libedit)
no unicode collation: fixed but still very fresh code
vi: there was a potential corruption when opening a file in an encoding which is
not unicode in a unicode env, now is does not corrupt anything anymore but still
says it is unhappy
finger(1) has been fixed for multibytes names (I know noone care about that one
:))

On the list of still known issues:
* important:
  - csh does not handle unicode
  - regex in libc: it does not handle unicode right (except if I have missed
something) and needs to be either fixed either switch to libtre + custom
patches (there was a summer of code about it long ago and dfly went that
way)
  - unicode support in our old groff is pretty bad, I plan to replace it with
heirloom-doctools which does handle unicode propertly (as far I have tested
at least)
  - edit(1) does not handle multibyte

* medium (minor?)
  - login(1) does not handle unicode properly

* minor:
  - lots of base tools (minor one like nl and friends are not multibyte
aware in lot of cases, probably merging the work done by Ingo Schwarze on
those tools on OpenBSD might be useful, but I have no plan to do it)
  - vi needs improvement in multiencoding support I haven't checked the latest
modification on vi upstream about that

There might be more, but that is all that comes out of my head right now

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

[Baptiste Daroussin]

On Sun, Jul 10, 2016 at 04:23:03PM +0800, Huang Wen Hui wrote:
> I can reproduce it on a clean 11.0-BETA1 VM.
> 

fixed in r302916.

Will merge in 2 days in stable/11

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

[Baptiste Daroussin]

On Sun, Jul 10, 2016 at 04:23:03PM +0800, Huang Wen Hui wrote:
> I can reproduce it on a clean 11.0-BETA1 VM.
> 
> 
> 2016-07-09 9:03 GMT+08:00 Huang Wen Hui :
> 
> > For some reasons, r302324 seems not include in 11.0-ALPHA6?
> >
> > 2016-07-09 8:52 GMT+08:00 Huang Wen Hui :
> >
> >> Revert back r302324, Chinese locale problem is gone.
> >>
> >> Cheers
> >> Huang Wen Hui
> >>
Thanks, I can reproduce now, I'm looking into it.

Bapt


signature.asc
Description: PGP signature

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

[Baptiste Daroussin]

On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote:
> These 2 files can make ls suck:
> 
> touch 火灾1
> touch 火灾2
> 
> 2 files start with 2 same Chinese chars.
> 
I cannot reproduce on my head laptop, neither on a clean 11.0-ALPHA6 jail.

I'll try on a clean 11.0-ALPHA6 VM

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

[Baptiste Daroussin]

On Mon, Jul 04, 2016 at 02:51:46PM +0800, Huang Wen Hui wrote:
> 2016-07-04 14:41 GMT+08:00 Baptiste Daroussin <b...@freebsd.org>:
> 
> > On Mon, Jul 04, 2016 at 02:36:11PM +0800, Huang Wen Hui wrote:
> > > 2016-07-04 14:20 GMT+08:00 Baptiste Daroussin <b...@freebsd.org>:
> > >
> > > > On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote:
> > > > > Hi,
> > > > > On very recent CURRENT, ls can eat high CPU time when
> > LANG=zh_CN.UTF-8
> > > > and
> > > > > LC_ALL=zh_CN.UTF-8:
> > > > >
> > > > > % uname -a
> > > > > FreeBSD mbp.gddsn.org.cn 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #121
> > r302331M:
> > > > Mon
> > > > > Jul  4 10:47:27 CST 2016 r...@mbp.gddsn.org.cn:
> > > > /usr/obj/usr/src/sys/MACBOOK
> > > > >  amd64
> > > > >
> > > > > top show:
> > > > > 4457 hwh   1 1000 16784K  4416K CPU44   0:22  98.86%
> > ls
> > > > >
> > > > > any ideas?
> > > > >
> > > > Is it in all directories or only in directories with files in chinese
> > > > characters?
> > > >
> > > Yes, the  directory contain Chinese characters.
> > >
> > > >
> > > > Is it only happening when you run ls with some arguments (in particular
> > > > -l) or
> > > > with any arguments?
> > > >
> > > I use  ls -wGl
> > >
> > > >
> > > > Do you see the same if you force any other locale like en_US.UTF-8?
> > > >
> > > There is no problem if set  en_US.UTF-8.
> > >
> > >
> > > > Best regards,
> > > > Bapt
> > > >
> >
> > Can you try:
> > env -i LANG=zh_CN.UTF-8 LC_COLLATE=C ls -l
> >
> > And tell me if it still happen?
> >
> No problem with this command.
> 

Ok so there might be an very inefficient code in the new chinese collation code
I will look into it thanks a lot for reporting.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: ls eat high CPU time when LANG=zh_CN.UTF-8 and LC_ALL=zh_CN.UTF-8

[Baptiste Daroussin]

On Mon, Jul 04, 2016 at 02:36:11PM +0800, Huang Wen Hui wrote:
> 2016-07-04 14:20 GMT+08:00 Baptiste Daroussin <b...@freebsd.org>:
> 
> > On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote:
> > > Hi,
> > > On very recent CURRENT, ls can eat high CPU time when LANG=zh_CN.UTF-8
> > and
> > > LC_ALL=zh_CN.UTF-8:
> > >
> > > % uname -a
> > > FreeBSD mbp.gddsn.org.cn 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #121 r302331M:
> > Mon
> > > Jul  4 10:47:27 CST 2016 r...@mbp.gddsn.org.cn:
> > /usr/obj/usr/src/sys/MACBOOK
> > >  amd64
> > >
> > > top show:
> > > 4457 hwh   1 1000 16784K  4416K CPU44   0:22  98.86% ls
> > >
> > > any ideas?
> > >
> > Is it in all directories or only in directories with files in chinese
> > characters?
> >
> Yes, the  directory contain Chinese characters.
> 
> >
> > Is it only happening when you run ls with some arguments (in particular
> > -l) or
> > with any arguments?
> >
> I use  ls -wGl
> 
> >
> > Do you see the same if you force any other locale like en_US.UTF-8?
> >
> There is no problem if set  en_US.UTF-8.
> 
> 
> > Best regards,
> > Bapt
> >

Can you try:
env -i LANG=zh_CN.UTF-8 LC_COLLATE=C ls -l

And tell me if it still happen?

Best regards,
Bapt


signature.asc
Description: PGP signature