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

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

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

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

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

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

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

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

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:

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.

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

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

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

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

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

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

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

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

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

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

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:

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"

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)

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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,

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 resul

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

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

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

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

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

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

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

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

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 -

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 >

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

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

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

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

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

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,

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 .

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

On Thu, 25 Feb 2021 at 18:10, Greg 'groggy' Lehey wrote: > > This details worries me. How compatible are PIE executables with > non-PIE executables? Can I run PIE executables on older systems? Can > I run older executables on a PIE system? There is no issue mixing PIE and non-PIE binaries,

HEADS-UP: PIE enabled by default on main

As of 9a227a2fd642 (main-n245052) base system binaries are now built as position-independent executable (PIE) by default, for 64-bit architectures. PIE executables are used in conjunction with address randomization as a mitigation for certain types of security vulnerabilities. If you track

Re: git equivalent of 'svn update'

On Sat, 16 Jan 2021 at 13:35, Steve Kargl wrote: > > In the git world, what is the equivalent of 'svn update' > within a subdirectory of the /usr/src hierarchy. You can use something like % git checkout freebsd/main sys/dev/bge to update just sys/dev/bge to match freebsd/main. This will leave

Re: git and the loss of revision numbers

On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: > > FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 > 3cc0c0d66a0-c255241(main)-dirty: > ^ > This is an incremental counter of commits Also, uqs@ recently fixed an issue in newvers.sh (including the

Deprecating userland a.out support

FreeBSD has used ELF binaries/libraries for decades, but still has support for legacy a.out binaries. Portions of this have been retired over time, and I propose removing the remaining pieces before FreeBSD 13. I'm not proposing making any change to kernel a.out support, but users needing userland

Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

Adding the FreeBSD-stable list to CC for more visibility. On Wed, 2 Dec 2020 at 12:43, Ed Maste wrote: > > I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to > switch the GDB knob to default to NO in the near future. If the > crashinfo utility and related man pages do

Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

On Wed, 2 Dec 2020 at 12:52, Warner Losh wrote: > > even if lldb isn't a complete drop in replacement (I've not used it at all, > so I can't say one way or another). Quick comment on this point - the FreeBSD Foundation has been sponsoring Moritz Systems to improve LLDB on FreeBSD, and they've

Removing obsolete GDB 6.1.1 for FreeBSD 13

We currently have an obsolete version of GDB 6.1 installed as /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts some basic information from a kernel core dump after a crash. If the gdb port is installed crashinfo will use that in preference to /usr/libexec/gdb. If neither exists

Re: kernel: linux: pid 2867 (java): cannot fill /proc/self/maps; consider bumping PFS_MAXBUFSIZ

On Sun, 1 Nov 2020 at 11:15, Oleg V. Nauman wrote: > > It is davmail ( mail/davmail from ports collection ) application that executed > by linux java interpreter ( java/linux-oracle-jdk18 from ports ) If you're set up to test a patch you can give https://reviews.freebsd.org/D27047 a try. There's

Re: Plans for git

On Sat, 19 Sep 2020 at 12:06, Bakul Shah wrote: > > The cgit-beta.FreeBSD.org and github trees are not identical the last > time I looked (mainly in meta data). Any reason for not keeping them > identical? I switched from the github tree to the cgit-beta tree. The current GitHub mirror is

Re: on moving freebsd from svn to git; would this be of any help?

On Fri, 18 Sep 2020 at 15:07, Chris wrote: > > While contemplating a massive re-tooling job ahead to accommodate > any/all changes when freebsd fully lands in git. I ran across this[1][2] > and wondered if it may be of any assistance for the task of those > involved in the migration process

Re: Deprecating ftpd in the FreeBSD base system?

On Wed, 16 Sep 2020 at 16:51, Allan Jude wrote: > > Is the [ftpd] version we have in base unique? That is to say, does it need > to be preserved somehow. I'm not sure if we have functionality that doesn't exist elsewhere, although we definitely have some changes that do not exist in other BSDs.

Deprecating ftpd in the FreeBSD base system?

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

Re: tracking -current, using poudriere-devel and the switch to git

On Thu, 10 Sep 2020 at 07:02, tech-lists wrote: > > On Wed, Sep 09, 2020 at 04:34:20PM -0400, Ed Maste wrote: > > [...lots of stuff explaining...] > > thank you Oh, I see I left a word out of my first reply and it could be confusing - added text in brackets below: > At the

Re: tracking -current, using poudriere-devel and the switch to git

On Wed, 9 Sep 2020 at 15:00, tech-lists wrote: > > Hi, > > What's the repo to use now in order to track -current with a poudriere jail > via git ? i.e. in poudriere.conf, what is GIT_BASEURL ? svn is still the canonical repo. If you want to help test the Git migration work in progress, the

Re: vfs.zfs.min_auto_ashift and OpenZFS

On Sun, 6 Sep 2020 at 22:26, Matthew Macy wrote: > > This long since been fixed. Note that Ryan built working installer images > during the CFT. Yep, thanks for the note and sorry for the false alarm; it was a local issue and I've closed the PR. ___

Re: vfs.zfs.min_auto_ashift and OpenZFS

On Fri, 1 May 2020 at 20:20, Matthew Macy wrote: > > OpenZFS doesn't have the same ashift optimization logic that FreeBSD > has. It's something that needs to be resolved before the code can be > integrated downstream. Note that our installer tries to set the min_auto_ashift when ZFS is selected

Re: Please check the current beta git conversions

On Tue, 1 Sep 2020 at 22:38, Thomas Mueller wrote: > > from Ed Maste: > > > > Any guidance on amount of diskspace and how long it takes to clone the > > > repo ? > > > I see just over 3GB in my clone, including about 2.5GB in the .git > > directory.

Re: Plans for git (was: Please check the current beta git conversions)

On Wed, 2 Sep 2020 at 02:31, Steve Kargl wrote: > > > A short intro on git for svn users: > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view > > > > ROTFL. From the "short intro", 2nd sentence. > > New committers are assumed to already be familiar with the basic > operation of Git. If not, start

Re: Plans for git (was: Please check the current beta git conversions)

On Wed, 2 Sep 2020 at 07:51, Mathieu Arnold wrote: > > > Git also supports sha-256 soon now, adoption should > > be researched from various online article series and > > work product before committing plans... > > https://lwn.net/Articles/823352/ > >

Re: Please check the current beta git conversions

On Tue, 1 Sep 2020 at 13:37, Poul-Henning Kamp wrote: > > > Goran Mekić writes: > > > While I can clone src nicely, it is very slow in Serbia/Europe. The best > > speed I got is 1.45MB/s but it's mostly around 700kB/s (still cloning). > > I was about to ask about that: > > Any guidance

Re: Please check the current beta git conversions

On Tue, 1 Sep 2020 at 13:23, Goran Mekić wrote: > > Hello, > > While I can clone src nicely, it is very slow in Serbia/Europe. Thanks for the report - I wouldn't be surprised if the host is a bit bogged down from folks trying this just after my message went out. Once your clone finishes please

Please check the current beta git conversions

We've been updating the svn-git converter and pushing out a new converted repo every two weeks, and are now approaching the time where we'd like to commit to the tree generated by the exporter, and guarantee that hashes will remain consistent from this point. At this point the Git Working Group

Re: kldref: too many segments on kernel build

On Wed, 19 Aug 2020 at 00:19, Dustin Marquess wrote: > > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: > > > > Any thoughts as to why this is happening when I build a (custom) kernel? > > > > kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried

  1   2   3   4   >