Re: Installer, before exit: /bin/tcsh for pkg (was: CFT: pkgbase support in 15.0)

On Wed, 7 May 2025 at 23:32, Graham Perrin wrote: > > Re: > > > has > two screenshots that compare the 14.2-RELEASE experience (good) with the > 15.0-CURRE

Re: pkg: invalid option --, and pkg: illegal option --

On Sun, 4 May 2025 at 02:13, Kevin Oberman wrote: > > It is definitely be61deae0aa2 and it is cosmetic. be61deae0aa2 changes the > parser in the base system. It results in all options generating the error, > but they are passed to the sub-program (info, version, delete, etc), so they > are jus

Re: elfcopy: not found

On Wed, 9 Apr 2025 at 15:13, Sulev-Madis Silber wrote: > > oh, i think WITHOUT_CROSS_COMPILER does it, it also turns > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP on. i might have overlooked what all those > "compiler" options actually do. what i wanted is to exclude compilers from > resulting build target.

Re: elfcopy: not found

k for those cases too. > i might have optimized myself into hellhole here but what happened within > last month that caused this, which change is it? This is the change that will have introduced the breakage: commit b885643b63e4df51cc6c74c4ddd4d0b640075678 Author: Ed Maste Date: Fri

Re: elfcopy: not found

On Mon, 7 Apr 2025 at 21:50, Sulev-Madis Silber wrote: > > --- boot1.efi --- > SOURCE_DATE_EPOCH=1704067200 elfcopy -j .peheader -j .text -j .sdata -j > .data -j . > dynamic -j .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame > --output-target > =binary boot1.sym boot1.efi > sh: elfco

Re: Reply: ISO build broken?

On Tue, 18 Mar 2025 at 22:39, Michael Butler wrote: > > Ah .. thanks for the hint .. trying with WITHOUT_LLVM_BINUTILS set now, Thanks for the report - I've opened https://reviews.freebsd.org/D49425 to address this.

Heads-up: Kernel module symbol resolution changing

Our in-kernel module linker currently performs symbol resolution against local symbols from other modules, which is a bug. In commits 95c20faf11a1 and ecd8245e0d77 kib introduced support to have the kernel linker stop resolving local symbols from other files, but did not change it by default to av

Heads-up: DSA key support being removed from OpenSSH

Upstream OpenSSH has been working on deprecating DSA keys for some time, and I intend to follow suit in FreeBSD. >From the OpenSSH 9.8p1 release notes: === OpenSSH has disabled DSA keys by default since 2015 but has retained run-time optional support for them. DSA was the only mandatory-to- imple

Re: Switching release media dist sets to .tzst (tar + zstd)?

On Fri, 13 Dec 2024 at 16:47, Shawn Webb wrote: > > Hey Ed, > > Thanks for providing the opportunity to discuss this before landing > it. To be clear, this was just intended to explore the idea. I was looking at some release artifact build infrastructure and was curious about how extensive the ch

Re: Switching release media dist sets to .tzst (tar + zstd)?

On Sat, 14 Dec 2024 at 14:02, Simon J. Gerraty wrote: > > Ed Maste wrote: > > Pros of zstd: > > - Faster compression and decompression speeds. > > - Aligns with the compression method used for FreeBSD packages. > > FWIW this should also allow the sets to be mount

Re: Switching release media dist sets to .tzst (tar + zstd)?

On Fri, 13 Dec 2024 at 19:42, Mark Millard wrote: > > I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz > for crude bisecting without needing to do builds. > > Are you saying that such will no longer be a possibility? (This is > not a which-compression-style question.) With pkg

Switching release media dist sets to .tzst (tar + zstd)?

I have been reviewing parts of the release artifact build process, including ISO and memstick images, and came across the distribution sets (e.g., base.txz, src.txz) used by the installer to populate new file systems. I’d like to discuss switching these to .tzst (tar + zstd) compression. While I h

Re: IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information

On Tue, 26 Nov 2024 at 14:59, Søren Schmidt wrote: > > I have several Dell servers (R640/R740) running 14-stable using mrsas and > RAID10 volumes, UFS on FreeBSD, and I have experienced corrupted filesystems > on reboot on 3 out of 14 servers so its not consistent, its the same servers > that a

IBM ServeRAID M5110e and other mfi/mrsas users - call for testing / request for information

I have a review open to switch to mrsas(4) by default, for devices supported by both it and mfi(4). mrsas(4) should be better supported and more functional. The review: https://reviews.freebsd.org/D45476 mfi: default to using mrsas(4) for newer cards However, we have a report of volume corruption

Re: buildworld error ld: error: version script assignment of 'FBSD_1.5' to symbol 'getentropy' failed: symbol not defined

On Fri, 22 Nov 2024 at 12:48, Ed Maste wrote: > > On Fri, 22 Nov 2024 at 09:32, Alexander Leidinger > wrote: > > > > FORTIFY_SOURCE=2 ## <--- maybe this? if yes: regression! > > Yes this is very likely -- looking So

Re: buildworld error ld: error: version script assignment of 'FBSD_1.5' to symbol 'getentropy' failed: symbol not defined

On Fri, 22 Nov 2024 at 09:32, Alexander Leidinger wrote: > > FORTIFY_SOURCE=2 ## <--- maybe this? if yes: regression! Yes this is very likely -- looking

Re: buildworld error ld: error: version script assignment of 'FBSD_1.5' to symbol 'getentropy' failed: symbol not defined

On Thu, 21 Nov 2024 at 04:43, Alexander Leidinger wrote: > > Hi, > > I get: > ld: error: version script assignment of 'FBSD_1.5' to symbol > 'getentropy' failed: symbol not defined > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > > This is with src from 2024-11-20

Re: upgrade llvm19 broke drm-6.1 kmod

On Thu, 24 Oct 2024 at 14:26, Michael Butler wrote: > > It seems there are some additional constraints about non-existent > directories that now count as errors .. I ran into this as well, in my work tree that has drm-kmod 6.6 as a submodule. I think these include paths are just leftover from so

Re: build failure: clang.full

On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote: > > I'm getting the following on an up2date checkout: > Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full > ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: > archive member 'FaultMaps.o' is neither ET_REL

Re: Heads-up: ifconfig address without a mask/width to become an error

On Mon, 17 Jun 2024 at 11:16, Michael Gmelin wrote: > > Hi Ed, > > In case there is no EN, what is the process to add information about > issues like this to the release notes? Something like "known issues", > which those of us who read the release notes can stumble over and check? Great question

Heads-up: ifconfig address without a mask/width to become an error

It is currently possible to specify an IPv4 address without a netmask/width to ifconfig or in rc.conf, e.g.: ifconfig_igb0="192.168.0.2" phk recently discovered[1] that ifconfig chose a poor netmask/width when none was specified. This was not an intentional change in defaults but rather a bug

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

On Wed, 12 Jun 2024 at 14:08, Ed Maste wrote: > > As for the path forward, what do folks think about changing the > warning into an error in main in the near future (prior to 15.0)? That > would provide about four years of releases that emit the warning, > hopefully enough ti

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

On Wed, 12 Jun 2024 at 12:16, Michael Gmelin wrote: > > So this is simply a bug. > > I opened a code review request to fix this: > https://reviews.freebsd.org/D45570 Thank you. An EN for 14.0 and 14.1 (as suggested in your review) is certainly warranted. As for the path forward, what do folks th

Re: build of main broken? (ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_...' failed: symbol not defined)

On Fri, 24 May 2024 at 11:28, Matteo Riondato wrote: > > > In lib/libc/rpc/Symbol.map there is: > > > >/* From yp_xdr.c (generated by rpcgen - include/rpcsvc/yp.x) */ > >xdr_domainname; > >xdr_keydat; > > > > so maybe the rpcgen step went wrong somehow? Do you have WITHOUT_

Re: Removing fdisk and bsdlabel (legacy partition tools)

On Fri, 26 Jan 2024 at 16:10, Rodney W. Grimes wrote: > > You yet again seem to ignore what it was I said, UEFI/CSM != UEFI, and > there are many buggy CSM's that roach on zeros in the CHS area. I'm not sure what "zeros in the CHS area" is referring to -- gpart writes values in the CHS fields, re

Re: Removing fdisk and bsdlabel (legacy partition tools)

On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote: > > Probably many do, clueless there's a proposal to remove them, > as many wont be tracking lists (I havent been tracking lately, > focused on moving home, other will have other distractions) As Rod suggested I'll have the tools emit a warnin

Re: Removing fdisk and bsdlabel (legacy partition tools)

On Thu, 25 Jan 2024 at 17:26, Robert R. Russell wrote: > > FYI gpart doesn't allow you to create disklabel with more than 8 items > either. Specify the number of partitions at `gpart create` time: # mdconfig -s 1G -t swap md0 # gpart create -s bsd -n 20 md0 md0 created # for i in $(jot 19); do g

Re: Removing fdisk and bsdlabel (legacy partition tools)

On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes wrote: > > > These will need to be addressed before actually removing any of these > > binaries, of course. > > You seem to have missed /rescue. Now think about that long > and hard, these tools classified as so important that they > are part of /res

Re: Re: Removing fdisk and bsdlabel (legacy partition tools)

On Thu, 25 Jan 2024 at 10:50, Mina Galić wrote: > > i was looking at cd(4) today, and to my surprise, it was full of disklabel > references. Oh, indeed - as with the old references in ccd(4) that should go. The last reference to `struct disklabel` in the CAM SCSI cd driver was removed over two d

Re: Removing fdisk and bsdlabel (legacy partition tools)

On Wed, 24 Jan 2024 at 12:30, Warner Losh wrote: > > Those are the only users in the tree, but not for long :) I have some reviews open to remove some old fdisk / diskabel / bsdlabel invocations from the tree. With those applied, for fdisk I see the following references (excluding sbin/fdisk/* a

Removing fdisk and bsdlabel (legacy partition tools)

MBR (PC BIOS) partition tables were historically maintained with fdisk(8), but gpart(8) has long been the preferred method for working with partition tables of all types. fdisk has been declared as obsolete in the man page since 2015. Similarly BSD disklabels were historically maintained with bsdla

Re: Ventoy support

On Thu, 26 Oct 2023 at 14:39, Warner Losh wrote: > > I've looked to pass the root filesystem into FreeBSD via a UEFI file path, > which FreeBSD has most, but not quite all, of the infrastructure to do. I'm not sure that is any direct help for the issues with Ventoy. There are two ways that an OS

Ventoy support

On Tue, 24 Oct 2023 at 21:24, Kyle Evans wrote: > > On 10/24/23 20:03, Rodney W. Grimes wrote: > > > > What "modules" are being provied by Ventoy, I do not know > > of any FreeBSD modules being provided by Ventoy, it is an > > EFI shim that loads the FreeBSD loader, and the loader > > does all the

Re: FreeBSD 14.0-BETA5 Now Available

On Mon, 23 Oct 2023 at 11:06, Rodney W. Grimes wrote: > > This is a regression of forms... I have been using ventoy to boot FreeBSD > since 12 or so and this is the first I have heard of a failure to boot > FreeBSD with Ventoy, so my ask is, what changed in FreeBSD that broke > it booting in Vento

Re: FreeBSD 14.0-BETA5 Now Available

On Mon, 16 Oct 2023 at 13:46, György Pásztor wrote: > >> I am interested in looking for a way to make Ventoy support more >> reliable, but that will not happen for 14.0. > > Is it depending on Ventoy? Yes, Ventoy needs to be updated for newer FreeBSD releases. For more info, see: https://forums.v

Re: FreeBSD 14.0-BETA5 Now Available

On Thu, 12 Oct 2023 at 00:11, Cameron Katri wrote: > > The FreeBSD-14.0-BETA5-arm64-aarch64-zfs.raw.xz (maybe others, I didn't > check) has a rc.conf with a ton of repeated lines. I tried looking at > why this would be, but the release scripts to create this image went > right over my head. Would

Re: FreeBSD 14.0-BETA5 Now Available

On Sat, 7 Oct 2023 at 13:35, György Pásztor wrote: > > Hi Glen, > > The new betas broke the functionality to boot from ventoy. Unfortunately the way Ventoy handles FreeBSD booting is somewhat fragile and this sort of breakage is not surprising. I suspect the Ventoy authors will have to release an

Re: WITHOUT_CAPSICUM|CASPER option ignored: it is no longer supported

On Wed, 4 Oct 2023 at 05:42, Mariusz Zaborski wrote: > > On Tue, Oct 03, 2023 at 09:43:41PM -0700, Michael Dexter wrote: > > In exercising the build options on 14.0-BETA4, WITHOUT_CAPSICUM and > > WITHOUT_CASPER appear to be in an ambiguous state: They are present but > > ignored. Fortunately src.

Re: [UPDATE] FreeBSD 14.0-BETA3 Now Available

On Sat, 30 Sept 2023 at 14:24, Philip Homburg wrote: > > >Note, releases from 13.2 and earlier are > >still problematic due to a file name being replaced with a directory of > >the same name. A patch is being tested currently, and we hope to have > >this resolved for 14.0-BETA4. > > I tried upgra

Re: FreeBSD 14.0-BETA1 Now Available

On Fri, 8 Sept 2023 at 19:33, Glen Barber wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > The first BETA build of the 14.0-RELEASE release cycle is now available. > ... > The freebsd-update(8) utility supports binary upgrades of amd64 and i386 > systems running earlier FreeBSD rel

Defaulting serial communication to 115200 bps for FreeBSD 14

FreeBSD currently uses 9600 bps as the default for serial communication -- in the boot loader, kernel serial console, /etc/ttys, and so on. This was consistent with most equipment in the 90s, when these defaults were established. Today 115200 bps seems to be much more common, and I'm proposing that

Heads-up: MAXCPU increasing shortly

On Fri, 5 May 2023 at 09:38, Ed Maste wrote: > > FreeBSD supports up to 256 CPU cores in the default kernel configuration > (on Tier-1 architectures). Systems with more than 256 cores are > available now, and will become increasingly common over FreeBSD 14’s > lifetime. The Fre

Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

> > > This could be a dependency issue; would you check if removing the > > > following $OBJTOP subdirs addresses the issue: > > > > > > secure/lib/libcrypto > > > secure/lib/libssl > > > obj-lib32/secure/lib/libcrypto > > > obj-lib32/secure/lib/libssl > > > > The build was successful; after the re

Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

On Sat, 24 Jun 2023 at 07:11, David Wolfskill wrote: > > Running: > FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #405 > main-n263767-764464af4968: Fri Jun 23 11:42:14 UTC 2023 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 140009

OpenSSL 3.0 is in the tree

Last night I merged OpenSSL 3.0 to main. This, along with the update to Clang 16 and other recent changes may result in some challenges over the next few days or weeks for folks following -CURRENT, such as ports that need to be updated or unanticipated issues in the base system. We need to get thi

OpenSSL 3.0 in the base system update

As previously mentioned[1] FreeBSD 14.0 will include OpenSSL 3.0. We expect to merge the update to main in the near future (within the next week or two) and are ready for wider testing. Supported by the FreeBSD Foundation, Pierre Pronchery has been working on the update in the src tree, with assi

Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?

On Fri, 12 May 2023 at 09:26, Oleg Lelchuk wrote: > > I don't want to go through the hassle of filling a bug with my vendor. I will > just wait for you, guys, to update the stand implementation. Thank you for > explaining to me what causes this issue. This issue is tracked in PR 265980 if you w

Support for more than 256 CPU cores

FreeBSD supports up to 256 CPU cores in the default kernel configuration (on Tier-1 architectures). Systems with more than 256 cores are available now, and will become increasingly common over FreeBSD 14’s lifetime. The FreeBSD Foundation is supporting the effort to increase MAXCPU, and PR269572[

Re: git: 61194e9852e6 - main - Add kqueue1() syscall

On Fri, 31 Mar 2023 at 12:38, Charlie Li wrote: > > Konstantin Belousov wrote: > > The branch main has been updated by kib: > > > > URL: > > https://cgit.FreeBSD.org/src/commit/?id=61194e9852e641d1533cd04a5679d6042ff975d3 > > > > commit 61194e9852e641d1533cd04a5679d6042ff975d3 > > Author: Kon

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

On Thu, 2 Mar 2023 at 05:14, Dimitry Andric wrote: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently ... > I find the double negative phrasing "do not skip" alw

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

On Thu, 16 Dec 2021 at 11:49, Gleb Smirnoff wrote: > > So I'm fine with removal [of ce, cp drivers] if anybody demonstrates > me a non-zero cost of leaving the drivers in. I just found PR264160: likely heap overflow in driver for Cronyx [ce(4), cp(4)] adapters (others also possibly affected) http

Re: ns8250: UART FCR is broken

On Mon, 24 Oct 2022 at 22:11, void wrote: > > hello freebsd-current@, > > this started appearing in dmesg > > ns8250: UART FCR is broken > ns8250: UART FCR is broken This message was added as part of Colin's work to support FreeBSD in the Firecracker VMM https://cgit.freebsd.org/src/commit/?id=c4

Re: MegaCLI port is ports-only -- how would you deploy it?

On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko wrote: > | > | > I'd have to put in -current first then look at MFC later on. If looks > | > | > good for you then I'll put it up for review. I just don't use this > | > | > stuff day to day anymore. I think it would be good to put this into review, p

Re: Proposal: remove /usr/bin/minigzip

On Fri, 29 Jul 2022 at 03:52, Xin Li wrote: > But for applications that really want to have smaller footprint, bzip2 > might be a better alternative -- the binary is bigger than minigzip, but > library was smaller than zlib so the total size is actually a little bit > smaller: ... For application

Re: (263489) (D35109) freebsd-update: restart sshd after upgrade

On Mon, 2 May 2022 at 20:17, Graham Perrin wrote: > > > (line 3028) > > How will freebsd-update behave in this case? > > > Cannot 'sta

Re: Profiled libraries on freebsd-current

On Sun, 1 May 2022 at 11:54, Steve Kargl wrote: > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h > index 594487829b5..1e8ab2e1827 100644 > --- a/gcc/config/freebsd-spec.h > +++ b/gcc/config/freebsd-spec.h > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respec

Re: Profiled libraries on freebsd-current

On Sat, 30 Apr 2022 at 11:34, Steve Kargl wrote: > > On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote: > > On Fri, 29 Apr 2022 at 01:58, Steve Kargl > > wrote: > > > > > > If one looks at src.conf(5), one finds > > > > > >WITH_P

Re: Profiled libraries on freebsd-current

On Fri, 29 Apr 2022 at 01:58, Steve Kargl wrote: > > If one looks at src.conf(5), one finds > >WITH_PROFILE > Build profiled libraries for use with gprof(8). This option is > deprecated and is not present in FreeBSD 14. > > I assume that the *_p.a libraries will no longer be

Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error

On Fri, 1 Apr 2022 at 12:04, FreeBSD User wrote: > > I tried the patch given at the URL above (Phabricator). Patch applied on > recent CURRENT and > trying to "make installworld" leaves me with this error, see bewlo. What I'm > doing weong here? You're not doing anything wrong, I had another bu

Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error

On Fri, 1 Apr 2022 at 10:00, Jens Schweikhardt wrote: > > Hello *, > Looks like a semicolon is missing after the "fi". Indeed, and there was a close bracket missing as well. I've put a (hopefully) fixed version in review at https://reviews.freebsd.org/D34734.

Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error

On Fri, 1 Apr 2022 at 08:54, FreeBSD User wrote: > > On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 > amd64, it is without any problem possible to build most recent 13-STABLE > sources as of today (stable/13-n250195-26e8bb3a4e1). > > On 14.0-CURRENT #18 main-n254160-4f

Re: Deprecating ISA sound cards

On Sat, 19 Mar 2022 at 15:30, Eirik Øverby wrote: > > I won't be arguing hard > for keeping these drivers (seeing as I'm clearly the oddball for having > FreeBSD running on hardware which has 1) ISA bus and 2) ISA sound > cards..) On Sat, 19 Mar 2022 at 17:24, Chris wrote: > > I have a board run

Re: Deprecating ISA sound cards

On Fri, 18 Mar 2022 at 16:06, Joel Dahl wrote: > > On Fri, Mar 18, 2022 at 12:08:02PM -0400, Ed Maste wrote: > > ISA sound cards have been obsolete for more than a decade, and it is > > (past) time to retire their drivers. This includes the following > > drivers/device

Deprecating ISA sound cards

ISA sound cards have been obsolete for more than a decade, and it is (past) time to retire their drivers. This includes the following drivers/devices: snd_ad1816 Analog Devices AD1816 SoundPort snd_ess Ensoniq ESS snd_guscGravis UltraSound snd_mss Microsoft Sound System snd_sbc Cr

Re: man elfctl vs. elfctl -l : man has +aslr example but elfctl -l lists onlt naslr style for ASLR control

On Fri, 4 Feb 2022 at 20:24, Mark Millard wrote: > > EXAMPLES > The following is an example of a typical usage of the elfctl command: > >elfctl file >elfctl -e +aslr file Fixed in dbc7364b1840ef3f36994952d085add5d161775d

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

On Thu, 27 Jan 2022 at 16:34, Ed Maste wrote: > > If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. Thanks everyone for the feedback so far. I think the feedbac

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

On Thu, 27 Jan 2022 at 20:10, Jamie Landeg-Jones wrote: > > Ed Maste wrote: > > > Since 2014 we have a copy of dma in the base system available as an > > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I thought it was enabled at default! Y

Dragonfly Mail Agent (dma) in the base system

The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) which accepts mail from a local Mail User Agent (MUA) and delivers it locally or to a smarthost for delivery. dma does not accept inbound mail (i.e., it does not listen on port 25) and is not intended to provide the same functiona

Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?]

On Fri, 31 Dec 2021 at 18:04, John Baldwin wrote: > > However, your point about libcxxrt.so.1 is valid. It needs to also be moved > to /lib if libc++.so.1 is moved to /lib. libcxxrt.so.1 has always been in /lib.

Re: recent commit breaks buildkernel

On Thu, 30 Dec 2021 at 02:41, Gary Jennejohn wrote: > > commit ff3a85d32411cdd7894f932b1d3d7ce01ec7a648 breaks buildkernel > if options INET6 is not in the kernel config file. Thanks for the report, this should be fixed by 818952c638a7. A build without INET appears to be broken for other reasons

Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion

On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: > > I'm confused, beyond just LGPL claims in the (fairly > current) source code, but GPL more generally: > > # grep -rl "SPDX.*GPL" /usr/main-src/ You need to exclude the ones with SPDX tags like: SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0

Re: Deprecate and remove publickey(5) stuff

On Wed, 15 Dec 2021 at 11:56, Emmanuel Vadot wrote: > > > Hello, it's me again, > > I've posted some review some time ago but didn't follow up with some > mail so users might see it. > I'd like to remove publickey(5) related programs, those are the only > DES users iirc and likely unused. > >

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

On Wed, 15 Dec 2021 at 10:27, Emmanuel Vadot wrote: > > > Hello all, > > I've noticed this /sbin/sconfig binary and after looking it's for > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't > supported. > We currently only

HEADS-UP: options VESA removal from x86 GENERIC

As reported by Stefan Blachmann in a reply on freebsd-hackers[1], having `options VESA` compiled into the kernel or loaded as a module breaks suspend-resume with the nvidia driver. See PR 253733. The default console is provided by vt(4), which does not use the `options VESA` driver, which serves n

Re: VDSO on amd64

On Thu, 25 Nov 2021 at 00:36, Kurt Jaeger wrote: > > Eleven years ago Giuseppe Cocomazzi posted this: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031553.html > > vdso and shared page patch I see the patch generated a couple of responses on the list when it was posted, includ

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

On Sat, 20 Nov 2021 at 20:00, Ed Maste wrote: > > On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu wrote: > > > > The mkimg ones are a bit tricky, it seems the output is changed in > > each run. We may need a way to generate reproducible results.

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu wrote: > > The mkimg ones are a bit tricky, it seems the output is changed in > each run. We may need a way to generate reproducible results.. Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13.

Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine

On Tue, 16 Nov 2021 at 23:22, Li-Wen Hsu wrote: > > You can use this command to list all the images built by re: > > gcloud compute images list --no-standard-images > --project=freebsd-org-cloud-dev Aside, it looks like we have many EOL images that are not marked as deprecated in the gcloud l

Re: [LIBM] One step closer to C99 conformance

On Thu, 4 Nov 2021 at 21:09, Steve Kargl wrote: > > A patch has been attached to > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862 > > which implements cexpl(). Great, thank you Steve. Do you have a list of what else is left for full C99? (Including anything that may be implemented in

Re: current now panics when starting VBox VM

On Tue, 2 Nov 2021 at 18:32, Michael Butler via freebsd-emulation wrote: > > Before reporting this, I rebuilt world including kernel, all kmods and > virtualbox itself to no avail :-( Thanks for confirming. Now that the WARN_ON noise is disabled by default would you mind rebuilding a new kernel

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

On Mon, 1 Nov 2021 at 11:56, Rick Macklem wrote: > > Did they stick APSLs on the files? (If so, I think it could still be ok, > since the APSL > is a lot like the CDDL. However, I'm not sure if the APSL has ever been > blessed > by FreeBSD as of yet?) I had a quick look at the Illumos kernel fi

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

On Thu, 28 Oct 2021 at 11:26, Shawn Webb wrote: > > It seems that smbfs might be used with some level of frequency in > virtualized environments. I wonder if providing a 9pfs client would be > a good step in helping deprecate smbfs. Indeed, that addresses one of the primary reasons it is still be

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

On Thu, 28 Oct 2021 at 11:05, Eugene Grosbein wrote: > > Please do not remove what is not broken. That is exactly the problem though: it was broken. It was fixed only because the CHERI folks found that it wasn't working and fixed it, and they are not going to be using it much longer. If nobody el

Deprecating smbfs(5) and removing it before FreeBSD 14

The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and I propose removing it for FreeBSD 14. I know the CHERI folks have been using it but they plan to migrate away from it. It was broken for months before they fixed it, so I suspect nobody is using it on contemporary releases. I h

Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

On Fri, 17 Sept 2021 at 09:30, FreeBSD User wrote: > > Hello out there, > > Just for clarification: after the last patches to the tree regarding openssh > and recompilation > of the base system, it seemed that everything turned to normal afterwards - > in my case. Thank you for the update, and

Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

On Fri, 10 Sept 2021 at 04:29, Gary Jennejohn wrote: > > Was the config.h in the patch the same as the one you committed? No it wasn't - USE_PAM was #defined in config.h after applying the patch, while the committed version accidentally did not.

Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden

On Thu, 9 Sept 2021 at 15:18, FreeBSD User wrote: > > /etc/ssh/sshd_config line 89: Unsupported option UsePAM Sorry, it turns out I had the wrong version of config.h in my commit. I'm running a build now and will commit it once a test with that change passes. I will look into all of the reported

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote: > > Hallo, > > latest upgrade of CURRENT sources renders buildworld into failure, box is > running > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST > 2021 amd64: Assuming this was with BEARSSL enabled, it should be fi

Re: awk behaviour?

On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current wrote: > > What prompted the question was my (obviously poor) attempt to debug and > resolve this failure when attempting to build a release for i386 on an > amd64 .. This will be due to my 4e224e4be7c3. I'm not sure exactly what's

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

On Tue, 4 May 2021 at 11:52, Mark Millard wrote: > > > As far as the utf-8 issues go, diffoscope requires a utf-8 locale and > > I suspect that is the issue. If you don't have LANG set already, try > > setting LANG=C.UTF-8 in your environment. > > That is not the issue for the UnicodeDecodeError:

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

On Mon, 3 May 2021 at 22:26, Mark Millard wrote: > > But I'll note that I've built and stalled py37-diffoscope > (new to me). A basic quick test showed that it reports: > > W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module > is unavailable. I just looked up tlsh - its

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current wrote: > > Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and > /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ > Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and > /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ > Fi

Re: sys/sys/param.h: 'main' instead of 'Master'?

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

FreeBSD/arm64 becoming Tier 1 in FreeBSD 13

Summary FreeBSD will promote arm64 to a Tier 1 architecture in FreeBSD 13. This means we will provide release images, binary packages, and security and errata updates. While we anticipate there will be minor issues with this first release, we believe the port is mature enough that they can be reso

Re: Rationalizing sed -i/-I (in-place editing) argument handling

On Mon, 8 Mar 2021 at 16:41, Ed Maste wrote: > > On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote: > > > > I also hate the idea of requiring no space between -I and its related > > value. That seems like a huge POLA violation compared to how virtually > > eve

Re: Rationalizing sed -i/-I (in-place editing) argument handling

On Mon, 8 Mar 2021 at 17:00, John-Mark Gurney wrote: > > How is the program suppose to tell when the extension is "-e", or -e > is a different option and not the argument to -I? -i-e is an in-place edit with extension "-e" -i -e is an in-place edit with no extension __

Re: Rationalizing sed -i/-I (in-place editing) argument handling

On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote: > > I also hate the idea of requiring no space between -I and its related > value. That seems like a huge POLA violation compared to how virtually > every other command's options and arguments work. On the other hand, -i.ext with no space is compati

Rationalizing sed -i/-I (in-place editing) argument handling

A relatively minor but longstanding incompatibility between FreeBSD and many other systems is the way sed handles backup files for in-place editing -- sed's -I and -i options. GNU sed and other BSDs accept an optional argument: -I.bak will save a backup file with a .bak extension, and -I with no ar

Re: Waiting for bufdaemon

On Mon, 8 Mar 2021 at 12:07, Kyle Evans wrote: > > diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c > index 68fc57e6ea7..6f25360a67c 100644 > --- a/sys/x86/x86/tsc.c > +++ b/sys/x86/x86/tsc.c > @@ -501,7 +501,12 @@ test_tsc(int adj_max_count) > uint64_t *data, *tsc; > u_int i, si

Re: HEADS-UP: PIE enabled by default on main

On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote: > > Not sure if Ed Maste just wants to make sure that all the executables > are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that > he knows about. The issue is that without a clean build you may have some .

  1   2   3   4   >