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

[Ed Maste]

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_NIS 
> > enabled?
>
> Yes, I do have WITHOUT_NIS=y in src.conf

peterj reported this in PR279270 as well and I've opened a review in
https://reviews.freebsd.org/D45347 to move these symbols to
lib/libc/yp/Symbol.map. Can you give that a try?

I originally proposed augmenting Version.map generation to pass CFLAGS
to CPP in D45346 and adding #ifdef YP in D45345, before finding Peter
PR and discovering that lib/libc/yp/Symbol.map already exists.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

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, regardless of whether you're creating
a plain MBR or a PMBR for GPT.

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

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 warning when they are run,
so that those users will become aware.
https://reviews.freebsd.org/D43585
https://reviews.freebsd.org/D43586

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

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 gpart add -t freebsd-ufs -s 1M md0; done
md0a added
md0b added
..
md0t added
# gpart show md0
=>  0  2097152  md0  BSD  (1.0G)
0 20481  freebsd-ufs  (1.0M)
 2048 20482  freebsd-ufs  (1.0M)
..
36864 2048   20  freebsd-ufs  (1.0M)
38912  2058240   - free -  (1.0G)

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

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 /rescue.  Again I can not stress enough how often
> I turn to these tools in a repair mode situation.

I haven't missed rescue, it is included in the work in progress I
mentioned. Note that rescue has included gpart since 2007.

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

[Ed Maste]

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

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

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/* and comments, old examples, etc.):

contrib/netbsd-tests/sbin/gpt/t_gpt.sh
tests/sys/cddl/zfs/bin/zpool_smi.ksh

For bsdlabel / disklabel:

sbin/growfs/tests/legacy_test.pl
tools/regression/msdosfs/msdosfstest-2.sh
tools/regression/tmpfs/t_vnd
tools/tools/nanobsd/legacy.sh
contrib/netbsd-tests/kernel/t_umount.sh
contrib/netbsd-tests/kernel/t_umountstress.sh
contrib/netbsd-tests/sbin/gpt/t_gpt.sh
sbin/newfs/runtest00.sh
sbin/newfs/runtest01.sh

These will need to be addressed before actually removing any of these
binaries, of course.

> I wouldn't object to making these ports, but both these programs use 'sekret'
> bits from the kernel that might not remain exposed as we clean things up.
> Though the IOCTLs they do (or used to do) may no longer be relevant. It's
> been so long that I've forgotten

If we eventually stop exporting those kernel interfaces the tools
would fail anyway, so IMO we can keep providing the kernel interfaces
along with the headers etc, and keep building from source until/unless
we drop support altogether.

Removing fdisk and bsdlabel (legacy partition tools)

[Ed Maste]

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 bsdlabel. It does not yet have a
deprecation notice - I have proposed a man page addition in
https://reviews.freebsd.org/D43563.

I would like to disconnect these from the build, and subsequently
remove them. This is prompted by a recent bsdlabel bug report which
uncovered a longstanding buffer overflow in that tool. Effort is much
better focused on contemporary, maintained tools rather than
investigating issues in deprecated ones. Removing these tools would
happen in FreeBSD 15 only (no change in 14 or 13).

Code review to disconnect fdisk: https://reviews.freebsd.org/D43575

Note that this effort is limited to these maintenance tools only -
there is no change to kernel or gpart support for MBR or BSD
disklablel partitioning. That said, MBR partitioning and BSD
disklabels are best considered legacy formats and should be avoided
for new installations, if possible.

If anyone is using fdisk and/or bsdlabel rather than gpart I would
appreciate knowing what is preventing you from using the contemporary
tools.

Re: Ventoy support

[Ed Maste]

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 can work with Ventoy: either using stacked
filesystems, or with some sort of block mapping.

For the first case the lower filesystem is typically exFAT, which
contains a variety of OS installer ISO images. We could conceivably
support this mode by using fusefs-exfat to mount the actual storage,
mdconfig, and mounting the ISO image. We can't use reroot here though,
because the underlying filesystem must remain mounted. Maybe we could
chroot and carry on with startup.

The second way is via block mapping, using some service to translate
offsets in the image file within the lower filesystem to physical
offsets in the underlying device. Linux has native support for this
via lvm2/dmsetup, and this is the mode that's used when I tried
booting a Ubuntu ISO via Ventoy. As it turns out NetBSD and
DragonflyBSD have a GPL'd lvm2 port, and presumably work the same way
with Ventoy. Ventoy's geom_ventoy FreeBSD kernel module works
similarly, just in a slightly hackish and Ventoy-specific way.

Ventoy support

[Ed Maste]

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 work.
> >
> > Again, perhaps I do not see this as I am only using ventoy
> > in EFI mode.
>
> There's an accompanying geom module as well, source available[0] for
> every version they support (except 14.x, apparently, despite having a
> built blob in the geom_ventoy_ko dir).  It's a little annoying to try
> and understand the problems they're running into from version to
> version, IMO, since they just publish the entire module again for each
> version rather than maintaining some __FreeBSD_version shims or something.

In particular, the kernel does not use EFI services for the root filesystem.

At one point I did take a quick look at the differences between
Ventoy's 11.x/12.x/13.x kernel module source and my recollection is
that the differences are just typical accommodation for kernel KPI
changes. With where we are in the 14.0 release cycle the only thing to
do is have support appear via a Ventoy update.

Ventoy is a very interesting project though and I would like to look
at consistent and maintainable FreeBSD/Ventoy support in the future.
This could be done either by continuing to use geom_ventoy but
bringing it into our release (via a port or in the base system), or
possibly by having the release images support mounting the cd9660 root
filesystem image from a file in an outer filesystem. This is a
post-14.0 activity either way.

Re: FreeBSD 14.0-BETA5 Now Available

[Ed Maste]

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

At a minimum FreeBSD 14 has a different KBI and the 13.x kernel
modules provided by older Ventoy won't work on 14.0.

Re: FreeBSD 14.0-BETA5 Now Available

[Ed Maste]

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.ventoy.net/showthread.php?tid=1805
https://github.com/ventoy/Ventoy/issues/7#issuecomment-1493237303

Re: FreeBSD 14.0-BETA5 Now Available

[Ed Maste]

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 you mind submitting a PR for this?

Re: FreeBSD 14.0-BETA5 Now Available

[Ed Maste]

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 update to support 14.0.

I am interested in looking for a way to make Ventoy support more
reliable, but that will not happen for 14.0.

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

[Ed Maste]

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.conf(5) now reports "This option has no effect."
> >
> > Will these be removed prior to the final release? Are they staying to be
> > reimplemented?
> AFAIK the plan is to remove them completely, but not before final release.

Yes, the plan is that for 14.x the build will warn that the option has
no effect, so that users are aware. Support will be removed entirely
for FreeBSD 15.

Re: [UPDATE] FreeBSD 14.0-BETA3 Now Available

[Ed Maste]

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 upgrading from 13.2 to BETA4 and it seems that the issue is still
> there. Is there going to be another BETA?

The fix is needed in freebsd-update in 13.2. You can wait for the
upcoming EN and update 13.2, or if you want to try immediately you can
fetch an updated freebsd-update as described in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273661#c12

Re: FreeBSD 14.0-BETA1 Now Available

[Ed Maste]

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 releases.  Note, aarch64 binary updates
> are expected to be available starting with BETA2, due to a configuration
> error.  Systems running earlier FreeBSD releases can upgrade as follows:
>
> # freebsd-update upgrade -r 14.0-BETA1

Upgrading with FreeBSD-update is failing with:

# freebsd-update install
src component not installed, skipped
Creating snapshot of existing boot environment... done.
Installing updates...install: ///usr/include/c++/v1/__string exists
but is not a directory
install: ///usr/include/c++/v1/__string/char_traits.h: Not a directory
install: ///usr/include/c++/v1/__string/extern_template_lists.h: Not a directory

Reported by Vedran Miletic in PR273661. We'll provide an update with
additional information and possible workarounds, when available.

Defaulting serial communication to 115200 bps for FreeBSD 14

[Ed Maste]

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 we make it the default for FreeBSD
14.0.

I have a review open: https://reviews.freebsd.org/D36295. There are a
few minor nits in the review to be addressed still but assuming
there's general agreement I'll iterate on those and commit this in a
few logical chunks.

Heads-up: MAXCPU increasing shortly

[Ed Maste]

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 FreeBSD Foundation is supporting the effort to increase
> MAXCPU, and PR269572[1] is open to track tasks and changes.

I intend to commit the change to increase amd64 MAXCPU to 1024 very
soon. After updating your src tree and building a new kernel you will
need to rebuild kernel modules that come from outside of the src tree
(such as drm-kmod or VirtualBox).

[1] https://bugs.freebsd.org/269572

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

[Ed Maste]

> > > 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 reboot, we see:
>
> g1-48(14.0-C)[1] uname -aUK
> FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #469 
> main-n263782-59833b089e78: Sat Jun 24 16:28:56 UTC 2023 
> r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
> 1400092 1400092
>
>
> So: I believe we have a winner! :-)

Excellent, thanks for checking. I've opened review D40750[1] to have
this cleanup happen automatically.

[1] https://reviews.freebsd.org/D40750

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

[Ed Maste]

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 1400091 1400091
>
> after updating sources to main-n263782-59833b089e78, then starting
> make -j 64 buildworld (in META mode)
>
> ...
> >>> stage 4.2: building libraries
> ...
> Building /common/S4/obj/usr/src/amd64.amd64/cddl/lib/libzfs/os/freebsd/nfs.o
> In file included from 
> /usr/src/sys/contrib/openzfs/lib/libzfs/libzfs_crypto.c:28
> :
> In file included from 
> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl
> /evp.h:14:
> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/macros.h:155:4: 
> error
> : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> #  error "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
>^

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

If so I'll see if we can add a rule to tools/build/depend-cleanup.sh

OpenSSL 3.0 is in the tree

[Ed Maste]

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 this work done so that we can continue moving on with
FreeBSD 14; I apologize for the trouble it might cause in the short
term. Please follow up to report any trouble you encounter.

OpenSSL 3.0 in the base system update

[Ed Maste]

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 assistance from Enji Cooper
(ngie@), and me (emaste@). Thanks to Antoine Brodin (antoine@) and
Muhammad Moinur Rahman (bofh@) for ports exp-runs and
fixes/workarounds and to Dag-Erling (des@) for updating ldns in the
base system.

## Base system compatibility status

Most of the base system is ready for a seamless switch to OpenSSL 3.0.
For several components we've added `-DOPENSSL_API_COMPAT=0x1010L`
to CFLAGS to specify the API version, which avoids deprecation
warnings from OpenSSL 3.0. Changes have also been made to avoid
OpenSSL APIs already deprecated in OpenSSL 1.1. We can continue the
process of updating to contemporary APIs after OpenSSL 3.0 is in the
tree.

Additional changes are still required for libarchive and seven
Kerberos-related libraries or tools. Workarounds are ready to go along
with the OpenSSL 3 import, and proper fixes are in progress in the
upstream projects.

A segfault from `openssl x509` in the i386 ports exp-run is under
investigation and needs to be addressed prior to the merge.

## Ports compatibility

With bofh@'s recent www/node18 and www/node20 patches the ports tree
is in reasonable shape for OpenSSL 3.0 in the base system. The exp-run
(link below) has a list of the failing ports, and I've emailed all of
the maintainers as a heads-up. None of the remaining failures are
responsible for a large number of skipped ports (i.e., the failures
are either leaf ports or are responsible for only a small number of
skipped ports). I expect that some or many of these will need to be
addressed after the change lands in the src tree.

## Call for testing

We welcome feedback from anyone willing to test the work in progress.
Pierre's update can be obtained from the pull request[2] or by
fetching the branch[3]. If desired I will provide a large diff against
main.

## Links

- Base system OpenSSL 3.0 update tracking PR:
  https://bugs.freebsd.org/271615

- Ports exp-run with OpenSSL 3.0 in the base system:
  https://bugs.freebsd.org/271656

[1] https://lists.freebsd.org/archives/freebsd-current/2023-May/003609.html
[2] https://github.com/freebsd/freebsd-src/pull/760
[3] https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0.9

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?

[Ed Maste]

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 want to follow it.
https://bugs.freebsd.org/265980

Support for more than 256 CPU cores

[Ed Maste]

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[1] is open to track tasks and changes.

As a project we have scalability work ahead of us to make best use of
high core count machines, but at a minimum we should be able to boot a
GENERIC kernel on such systems, and have an ABI for the FreeBSD 14
release that supports such a configuration.

Some changes have already been committed in support of increased MAXCPU,
including increasing MAX_APIC_ID (commit c8113dad7ed4) and a number of
changes to reduce bloat (such as commits 42f722e721cd, e72f7ed43eef,
78cfa762ebf2 and 74ac712f72cf).

The next step is to increase the maximum cpuset size for userland.
I have this change open in review D39941[2] and an exp-run request in
PR271213[3].  Following that the kernel change for increasing MAXCPU is
in D36838[4].

Additional work on bloat reduction will continue after this change, and
looking forward FreeBSD is going to need ongoing effort from the
community and the FreeBSD Foundation to continue improving scalability.

[1] https://bugs.freebsd.org/269572
[2] https://reviews.freebsd.org/D39941
[3] https://bugs.freebsd.org/271213
[4] https://reviews.freebsd.org/D36838

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

[Ed Maste]

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: Konstantin Belousov 
> > AuthorDate: 2023-03-25 23:39:02 +
> > Commit: Konstantin Belousov 
> > CommitDate: 2023-03-27 23:39:26 +
> >
> >  Add kqueue1() syscall
> >
> >  It takes the flags argument.  Immediate use is to provide the 
> > KQUEUE_CLOEXEC
> >  flag for kqueue(2).
> >
> This commit series causes x11/libinput to hit an assert (which also
> silently crashes X on launch):
> > Assertion failed: (libinput->refcount > 0), function libinput_unref, file 
> > ../src/libinput.c, line 1957.
>
> devel/libepoll-shim, x11/libinput's prime dependency, has its own
> kqueue1() implementation, which is used when the system does not already
> have one. Reverting this series and rebuilding devel/libepoll-shim to
> use its included implementation allows x11/libinput to work again.

Ah, NetBSD added kqueue1 some time ago, and it uses the already
existing flags (O_CLOEXEC etc.)
If it's easy to test, can you try changing libepoll-shim to call
kqueue1(KQUEUE_CLOEXEC)?

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

[Ed Maste]

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" always confusing. But
> the logic is normally:

Yes, it's confusing -- perhaps we could rewrite it as something like
"Build a cross-compiler during the build bootstrap phase, rather than
opportunistically using the host's compiler."

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

[Ed Maste]

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)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264160
although it was submitted some time ago. I am not sure if it's a real
issue or not.

Re: ns8250: UART FCR is broken

[Ed Maste]

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

In this case it indicates that bhyve has the same bug/missing
functionality as Firecracker -- it doesn't implement the FCR_XMT_RST
or FCR_RCV_RST bits. You can safely ignore the message, and it will
disappear once someone adds the required support to bhyve. We should
probably also have the kernel emit the message only once. I've CC'd
Colin for comment.

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

[Ed Maste]

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, perhaps separate
ones for the kernel and userland parts. Feel free to put me on as a
reviewer or subscriber.

Re: Proposal: remove /usr/bin/minigzip

[Ed Maste]

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 applications where tens of kilobytes is a real concern, something
like Rob Landley's "toybox" is probably a better bet.

I configured it to include only gzip and get:
$ ls -l toybox
-r-xr-xr-x  1 emaste  emaste  36880 Jul 29 11:59 toybox
$ ./toybox
gzip
$
$ ldd ./toybox
./toybox:
libc.so.7 => /lib/libc.so.7 (0x822a42000)

so it's about 25K larger than minigzip, but doesn't depend on libz and
could result in a rather smaller image.

Toybox is at https://landley.net/toybox/

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

[Ed Maste]

On Mon, 2 May 2022 at 20:17, Graham Perrin  wrote:
>
> 
> (line 3028)
>
> How will freebsd-update behave in this case?
>
> > Cannot 'status' sshd. Set sshd_enable to YES in /etc/rc.conf or use
> > 'onestatus' instead of 'status'.

If it's not already running nothing will happen.

Re: Profiled libraries on freebsd-current

[Ed Maste]

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 respectively.  
> If not, see
> (similar to the default, except no -lg, and no -p).  */
>
>  #ifdef FBSD_NO_THREADS

I wonder if we can simplify things now, and remove this
`FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
targets I looked at.

Re: Profiled libraries on freebsd-current

[Ed Maste]

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_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 built and
> > > installed on FreeBSD 14 and later.  Is this correct?
> >
> > FreeBSD 14 is not yet released, of course, but that is indeed the
> > intent. PR256874 reports that a GCC patch (to stop linking against
> > _p.a) is in the works but unfortunately has not had an update for some
> > time.
>
> I see.  It only took me 2+ years to get
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
>
> committed to the GCC repository.  Good luck with
> getting your patch upstream.

Heh, thanks.

I have just now changed the WITH_PROFILE description to state "a
future version of FreeBSD" since it may well not happen for FreeBSD
14.

We could also just install libc_p.a as a symlink to libc.a (and same
for the other _p.a archives).

Re: Profiled libraries on freebsd-current

[Ed Maste]

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 built and
> installed on FreeBSD 14 and later.  Is this correct?

FreeBSD 14 is not yet released, of course, but that is indeed the
intent. PR256874 reports that a GCC patch (to stop linking against
_p.a) is in the works but unfortunately has not had an update for some
time.

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

[Ed Maste]

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 bug in the version of
the patch you tried. I've updated Phabricator again, please try again.

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

[Ed Maste]

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

[Ed Maste]

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-4fc5a607fdf: Fri Apr  1 08:30:10 CEST 2022
> amd64 this is not possible anymore

Could you give this patch a try?

diff --git a/Makefile.inc1 b/Makefile.inc1
index c91034ed42fe..bd58f48a64d2 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1366,6 +1366,9 @@ distributeworld installworld stageworld:
_installcheck_world .PHONY
libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs
2>/dev/null | sort -u | \
while read line; do \
set -- $$line; \
+   if [ "$$1" = "[preloaded]"; then \
+   break; \
+   fi \
if [ "$$2 $$3" != "not found" ]; then \
echo $$2; \
else \

Re: Deprecating ISA sound cards

[Ed Maste]

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 running freebsd that has 2 GUS cards in it running
> simultaneously. Sniff... cést la vié

These drivers will (eventually) need to be updated for Giant locking /
spl* leftovers, or be removed. I assumed that these were all
museum-class hardware and nobody would use them with contemporary
FreeBSD; NYC*BUG dmesgd[1] seemed to concur.

That said, I don't think they have a significant maintenance burden in
the near term. Any of these drivers that will actually be used with
FreeBSD 14 could have their retirement postponed. If this is desired,
please identify the specific driver(s), follow up here with a
confirmation that they work with 12.3/13.0/CURRENT, and ideally send a
dmesg to dmesgd. As far as I can tell there are no GUS cards listed in
dmesgd at all.

(I also had an original GF1 Ultrasound with 1MB on board although I
think it sadly went to e-waste. I never used it with FreeBSD, and it
seems the snd_gusc driver only supports UltraSound MAX and newer
anyhow.)

[1] https://dmesgd.nycbug.org/index.cgi

Re: Deprecating ISA sound cards

[Ed Maste]

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/devices:
> >
> > ...
> You can remove snd_aureal, snd_ds1 and snd_maestro as well while you're at it.
> They've been broken for 10+ years:
> https://lists.freebsd.org/pipermail/freebsd-multimedia/2012-January/012751.html

Thanks for the note. I removed snd_aureal just now as it was not even
connected to the build. I'll take care of the others soon.

Deprecating ISA sound cards

[Ed Maste]

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 Creative Sound Blaster

I have a review open to add deprecation notices:
https://reviews.freebsd.org/D34604

I expect to commit this in the near future, then MFC to stable
branches and remove these drivers from main. Please follow up if
there's a reason we should postpone the removal of any of these
drivers.

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

[Ed Maste]

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

[Ed Maste]

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 feedback
(including some private mail) can be summarised as:

- It works well for the intended use case.
- Documentation (FreeBSD handbook) is missing. I have submitted
https://bugs.freebsd.org/261536 to track this.
- We'd need to address queued mail in some way before it could be the
default (e.g. provide a default cron job).

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

[Ed Maste]

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!

Yes, my mistake - by default WITH_DMAGENT is enabled, and
/usr/libexec/dma is built. What is not done by default is configuring
/etc/mailer.conf to use dma for /usr/sbin/sendmail or /usr/sbin/mailq.

Dragonfly Mail Agent (dma) in the base system

[Ed Maste]

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 functionality as a full MTA like postfix or sendmail.
It is intended for use cases such as delivering cron(8) mail.

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 am interested in determining whether dma is a viable minimal base
system MTA, and if not what gaps remain. 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.

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

[Ed Maste]

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

[Ed Maste]

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 at the
moment; I'll try to take a look at that.

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

[Ed Maste]

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

but also note that this text in README.md is just documenting the
top-level gnu/ subdirectory.

Re: Deprecate and remove publickey(5) stuff

[Ed Maste]

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.
>
>  https://reviews.freebsd.org/D30682
>  https://reviews.freebsd.org/D30683
>
>  I'll commit this in two weeks unless there is some valid argument to
> keep this.

There is also DES support in lib/libc/rpc/ related to this
functionality - I think we have to consider all of this together.

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

[Ed Maste]

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 build the drivers for i386 (and they contain native
> compiled code).
>
>  Anyway, I'd like to remove this from the tree, I really doubt that
> anyone uses this cards nowadays (or even E1) but just in case I send
> this mail.

I posted a similar query to -stable in 2020, at
https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html
and did not get any response.

I have D23928 for a deprecation notice for ce and cp. Gleb commented
there that he'd offer to maintain them (and as part of that, removed
sppp in 6aae3517ed25).

HEADS-UP: options VESA removal from x86 GENERIC

[Ed Maste]

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 no purpose for most users. (vt(4)
supports a loader-set VBE mode via the vt_vbefb driver.)

Thus, I plan to remove[2] options VESA from the x86 kernel config
files. sc(4) users who wish to select alternate VBE modes will still
be able to do so by loading the kernel module.

[1] https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000469.html
[2] https://reviews.freebsd.org/D33141

Re: VDSO on amd64

[Ed Maste]

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, including a plan to follow up with a detailed review that
appears not to have happened. It's unfortunate, and as a project we
definitely have an issue that not all contributions are addressed in a
timely manner.

One of the goals of the Git working group, and Warner's newer
development practices working group, is to make it easier to handle
contributions. Of course contributions can be overlooked regardless of
whether they're patches on a mailing list, attached to a Bugzilla PR,
opened as a Phabricator review, or as a GitHub or Gitlab pull or merge
request. There isn't a technical solution that will fully address
this, but we can reduce friction as much as possible.

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

[Ed Maste]

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..
>
> Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13.

The mkimg failures are indeed fixed by the above commit - it was just
a latent bug in mkimg.

I've opened PR 259968 as a tracking bug for outstanding issues found
as a result of enabling ASLR by default, and submitted a PR for each
of the three outstanding issues.

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

[Ed Maste]

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

[Ed Maste]

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 list (11.x and old 12.x images).

Re: [LIBM] One step closer to C99 conformance

[Ed Maste]

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 a suboptimal way today and should
be redone.)

Re: current now panics when starting VBox VM

[Ed Maste]

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 and obtaining a less-noisy log?

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

[Ed Maste]

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 files and it appears each
file is licensed under only one of 4-clause BSD, APSL, or CDDL,
depending on where it originated.

Files from Boris Popov's original FreeBSD implementation have the
4-clause BSD license, followed by something like:
/*
 * Copyright (c) 2008, 2010, Oracle and/or its affiliates. All rights reserved.
 * Portions Copyright (C) 2001 - 2013 Apple Inc. All rights reserved.
 * Copyright 2018 Nexenta Systems, Inc.  All rights reserved.
 */

There are 28 BSD-licensed kernel files, 5 APSL, and 13 CDDL. I think
that having an smbfs kernel module in the tree using a combination of
those licenses is fine. (This isn't on behalf of core@ and of course
due diligence needs to be done, but from a high level it seems
reasonable.)

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

[Ed Maste]

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 being
used, including by CHERI. Their plan to migrate away from smbfs is
based on moving to 9pfs.

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

[Ed Maste]

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 else
regularly tests it in -CURRENT it will break again, and will end up
broken in a release. That said, since it does seem that several folks
are still currently using i I'll avoid trying to remove it in the near
future.

A caveat for the man pages may instead be something like:

The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
smbfs is unmaintained and may not function correctly in FreeBSD 14 or
later.  Users are advised to evaluate the sysutils/fusefs-smbnetfs port
instead.

Deprecating smbfs(5) and removing it before FreeBSD 14

[Ed Maste]

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 have review D32707 (https://reviews.freebsd.org/D32707) open to add
this deprecation notice to the man page:
 The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
 smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
 present in FreeBSD 14 and above.  Users are advised to evaluate the
 sysutils/fusefs-smbnetfs port instead.

A similar notice would be added to the smbutil and mount_smbfs man
pages, and manu@ suggested having the userland utilities emit a
warning when they are used.

I am interested in comments, objections, or reports that anyone is in
fact using smbfs.

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

[Ed Maste]

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 sorry for the trouble.

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

[Ed Maste]

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

[Ed Maste]

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 issues, but I'd be
much obliged if you can rebuild sshd and try again (once the config.h
commit lands).

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

[Ed Maste]

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

commit 879675e9a0d84880cad9834e2ef98e8724c5532c
Author: Warner Losh 
Date:   Wed Aug 11 10:59:28 2021 -0600

stand: Add MK_PIE=no to defs.mk

There's no need to build both pie and non-pie .o's for stand. There's
some other build thing with MK_BEAR_SSL=yes and/or MK_LOADER_VERIEXEC=yes
that causes the pie build to fail that the 'ar' stage now. Since we don't
need the PIE stuff and the non-PIE stuff, disable PIE for the boot loader.

Reviewed by:emaste
Sponsored by:   Netflix

Re: awk behaviour?

[Ed Maste]

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
happening yet, but I can provoke this behaviour if `${PKG_CMD}
--version` outputs something other than a single line with the version
number.

Can you give this change a try:

diff --git a/Makefile.inc1 b/Makefile.inc1
index 23fb4b5581ac..9ef954e0678c 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1860,7 +1860,7 @@ _pkgbootstrap: .PHONY
 .if make(create-world-packages-jobs) || make(create-kernel-packages*)
|| make(real-update-packages) || make(sign-packages)
 PKG_ABI!=${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/usr/bin/uname config ABI
 .endif
-PKG_BIN_VERSION!=${PKG_CMD} --version | awk -F. '{print $$1 * 1 +
$$2 * 100 + $$3}'
+PKG_BIN_VERSION!=${PKG_CMD} --version | awk -F. '/^[0-9.]+$$/ {print
$$1 * 1 + $$2 * 100 + $$3}'
 .if ${PKG_BIN_VERSION} < 11700
 PKG_EXT=   ${PKG_FORMAT}
 .else

Re: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Ed Maste]

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:
>
> # echo $LANG
> C.UTF-8
>
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently 
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18: 
> invalid start byte

Hmm, interesting - if you don't mind sharing I'd be interested in a
copy of /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh, in order to track
down what appears to be a diffoscope issue.

To investigate the non-reproducibility though we can just manually run
through the same sort of process that Diffoscope uses. I would suggest
cmp -x   to find the offsets of the difference(s), then
use readelf -S  to determine which section(s) have differences.
___
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: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Ed Maste]

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 "A Locality Sensitive Hash"; I presume
diffoscope uses it to infer file renames. I believe the warning
emitted here should have no impact on the output we're looking for.

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.
___
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: FYI: WITH_REPRODUCIBLE_BUILD= problem for some files?

[Ed Maste]

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
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/usr/bin/ntpq and 
> /usr/obj/DESTDIRs/13_0R-CA7-poud/usr/bin/ntpq differ...

This is unexpected. Unfortunately I haven't looked at reproducibility
in a while, and my work was all on x86. This could be a regression or
a longstanding issue with arm64.

If you install the diffoscope package (py37-diffoscope) and run it on
the two directories / files it should give a more convenient view of
the differences. (Or, if you can make a tarball of the differing files
I can take a look.)
___
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'?

[Ed Maste]

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.
___
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/arm64 becoming Tier 1 in FreeBSD 13

[Ed Maste]

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 resolved during the life of FreeBSD 13.

Details

Development efforts on FreeBSD/arm64 (also known as AArch64) started
in 2014, with generous financial and technical support from Arm,
Cavium and the FreeBSD Foundation. FreeBSD 11.0 arrived in October
2016 as the first release with support for the architecture.
Improvements to the kernel, tool chain, userland, and ports and
package infrastructure have been ongoing since that time, with
improvements arriving in each minor and major release.

The FreeBSD base system is ready for the promotion of arm64 to Tier 1,
and the Release Engineering, Security, and Ports teams are prepared to
support the Tier 1 requirements for arm64. Security updates via
freebsd-update now include arm64 support (starting with the FreeBSD
13.0 release candidates).

Required ports infrastructure is in place for arm64 and most ports
build successfully. The project now has several Ampere eMAG systems
acting as package build servers. These machines were obtained through
a combination of FreeBSD Foundation purchases and generous donations
from Ampere.

To support port maintainers who do not have access to arm64 hardware
we will be improving ports CI and testing resources (and this effort
will benefit all architectures). We will also be suggesting one or
more low-cost reference platforms for FreeBSD/arm64.

The guarantees included in Tier 1 status are described in
https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/archs.html

In particular, for Tier 1 architectures the project provides release
images, binary package sets, and binary and source updates for
Security Advisories and Errata Notices.

The AArch64 ecosystem’s maturity ensures follow on generations of
hardware. The diversity of offerings, as well as the multiple
generations of hardware shows that the FreeBSD project will benefit
from adding support for this platform. The growth trajectory suggests
this will be a significant portion of the market in the coming years,
and FreeBSD will benefit from tapping into this market with this Tier
1 platform.

(on behalf of core)
___
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: Rationalizing sed -i/-I (in-place editing) argument handling

[Ed Maste]

 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
> > every other command's options and arguments work.
>
> On the other hand, -i.ext with no space is compatible with FreeBSD
> today and is portable to OpenBSD, NetBSD, macOS, and GNU. -i .ext
> works only with FreeBSD and macOS.

I'd like to go ahead with a man page update shortly. Even if we do not
modify sed, it is valuable to document and describe the compatibility
issues with our -i/-I, including the odd way we specify no backup
file.

On the topic of POLA our -i/-I support was based on perl's in-place
editing, except perl uses the optional argument style (-i / -i.bak).
I'd also argue that our -i "" is a POLA violation compared to how most
other commands work, and has caused significant confusion for folks
interested in cross-OS compatibility.

If anyone has suggestions or improvements to the proposed man page
text I'd appreciate a follow-up here or a comment in the review,
https://reviews.freebsd.org/D29128.
___
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: Rationalizing sed -i/-I (in-place editing) argument handling

[Ed Maste]

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
___
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: Rationalizing sed -i/-I (in-place editing) argument handling

[Ed Maste]

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 compatible with FreeBSD
today and is portable to OpenBSD, NetBSD, macOS, and GNU. -i .ext
works only with FreeBSD and macOS.
___
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"

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

[Ed Maste]

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 argument will not create a backup file.
FreeBSD currently accepts either -I.bak or -I .bak to save a backup
with the given extension, and -I "" (an empty argument) to specify no
backup.

I've been tripped up by this in the past and I know many others have.
Most recently tobik@  filed PR 254091 for this. Now, I think a single
change to make -i/-I to be compatible with other sed implementations
in one step is too much of a POLA violation, but I think it can
reasonably be done in stages:

1. Update the man page to indicate that -i/-I should not have a space
between the flag and the extension. This is compatible with current
FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below.
No backup is still a special case and remains as -I "".

I've opened https://reviews.freebsd.org/D29128 with proposed man page changes.

2. Continue accepting -I .bak, but emit a warning suggesting the use
of -I.bak instead.

3. Change -I/-i to getopt optional arguments, but keep a special case
for -I/-i "". At this point -I .bak becomes invalid as with other
seds, and specifying no backup can be done with either -I "" or -I
with no argument. This relies on an empty argument having no other
sensible interpretation.

4. Continue accepting -I "" to specify no backup, but emit a warning
suggesting the use of -I with no argument.

5. Retire the special case for -I "".

These steps could be done over an extended period of time (such as one
major release to another) - this is most important between steps 2 and
3.

Please let me know what you think, and if there's something I've missed.
___
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: Waiting for bufdaemon

[Ed Maste]

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, size, adj;
>
> -   if ((!smp_tsc && !tsc_is_invariant) || vm_guest)
> +   /*
> +* Misbehavior of TSC under VirtualBox has been observed.  In
> +* particular, threads doing small (~1 second) sleeps may miss their
> +* wakeup and hang around in sleep state, causing hangs on shutdown.
> +*/
> +   if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX)
> return (-100);
> size = (mp_maxid + 1) * 3;
> data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK);

This seems like a sensible change to me. To make it explicilty clear
what the comment/workaround applies to, maybe rewrite it as:

   if (!smp_tsc && !tsc_is_invariant)
   return (-100);
   /*
* Misbehavior of TSC under VirtualBox has been observed.  In
* particular, threads doing small (~1 second) sleeps may miss their
* wakeup and hang around in sleep state, causing hangs on shutdown.
*/
   if (vm_guest == VM_GUEST_VBOX)
   return (-100);
___
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: HEADS-UP: PIE enabled by default on main

[Ed Maste]

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 .o files
left around that are built without PIE enabled (i.e., compiled without
-fPIE), and attempting to link them into a PIE executable will fail
with an error like:

ld: error: can't create dynamic relocation R_X86_64_32 against local
symbol in readonly segment; recompile object files with -fPIC or pass
'-Wl,-z,notext' to allow text relocations in the output

I am not aware of any configuration that would link successfully, but
then have some run-time failure. If it builds it should work.
___
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: HEADS-UP: PIE enabled by default on main

[Ed Maste]

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, and they introduce
no additional constraints on running on older kernels.
___
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"

HEADS-UP: PIE enabled by default on main

[Ed Maste]

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 -CURRENT and normally build WITHOUT_CLEAN you'll need to
do one initial clean build -- either run `make cleanworld` or set
WITH_CLEAN=yes.

No significant user-facing changes are expected from this change, but
there are some minor ones. For example, `file` will indicate that
binaries are PIE by reporting something like `ELF 64-bit LSB pie
executable` rather than `ELF 64-bit LSB executable`. Also, for most
workloads no notable performance impact is expected.

For almost all ports this should result in no change. There are a
small number of ports that use base system /usr/share/mk
infrastructure and thus inherit the base system default, and some of
those initially failed to build. Those found during an exp-run in
PR253275 have been addressed or have patches waiting.

Please watch out for any new issues after you next update the base
system and/or ports, and report issues via a Bugzilla PR or in reply
here.
___
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: git equivalent of 'svn update'

[Ed Maste]

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 you
with staged changes which you can then commit (locally).
___
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: git and the loss of revision numbers

[Ed Maste]

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 final,
non-updating svn revision) and reordered the information. An example
of the new format:

main-c255126-gb81783dc98e6-dirty
 \ \   \\
  \ \   \ local modifications
   \ \hash
\  commit count
  branch
___
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"

Deprecating userland a.out support

[Ed Maste]

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 a.out tools would have to install them from old
FreeBSD releases.

I have opened the following reviews for three tools that still support a.out:

D27478 ldd: Retire a.out support
D27480 gprof: Retire a.out support
D27481 ldconfig: Retire a.out support

If there are no objections I plan to commit these changes before the
end of the month, along with small changes to the mtree file (removing
aout directories) etc.
___
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: Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

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 not already include
> references to installing the gdb port/package I will add those before
> making the change.

The crashinfo man page now references the gdb port/package, and
crashinfo itself emits a message that the port/package should be
installed if kgdb is not found.

GDB's proposed retirement has now been added to
https://wiki.freebsd.org/DeprecationPlan.

I expect to make GDB default to NO next week, and then remove it from
the tree a week or two later, if there is no compelling objection.
___
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: Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

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 done
great work getting it into shape. Their work is in LLVM upstream now,
and they're iterating on fixing issues found by LLDB's test suite.
LLDB 12 should provide a capable userland debugging experience in
FreeBSD 13, although I suspect many users will still install the gdb
port or package for the familiar command line interface.

There's no FreeBSD kernel support in LLDB yet, but it's being investigated.
___
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"

Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

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 it will not perform any analysis,
reporting "Unable to find a kernel debugger."

GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
support all of the architectures that FreeBSD does, and imposes
limitations on the FreeBSD kernel build - the continued use of DWARF2.

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 not already include
references to installing the gdb port/package I will add those before
making the change.

In the fullness of time we may use LLDB to extract the same
information, or provide other tooling to do so, but I do not want to
block GDB 6.1.1's removal on this.

Please let me know of any objections or comments.
___
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: kernel: linux: pid 2867 (java): cannot fill /proc/self/maps; consider bumping PFS_MAXBUFSIZ

[Ed Maste]

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 some small detail to
work out but this should be solved soon.
___
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: Plans for git

[Ed Maste]

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 missing a bunch of merge metadata for
many commits to contrib software. This poses no issue for while the
canonical repository is Subversion and contrib software updates are
done there, but would cause grief for future contrib updates after the
git migration is complete.

There are still a few issues in cgit-beta left to resolve, so the
hashes there will still change before the cutover.
___
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: on moving freebsd from svn to git; would this be of any help?

[Ed Maste]

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

It doesn't solve any of the problems we have now; the actual svn to
git conversion via svn2git works fine. Open issues are with the svn
repository / mirrors, and finishing up process documentation.
> 1) http://catb.org/esr/reposurgeon/
> 2) https://gitlab.com/esr/reposurgeon
>
> FTR I'm unaffiliated with the project. It just looked like it might be of
> interest.
>
> --Chris
> ___
> 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"

Re: Deprecating ftpd in the FreeBSD base system?

[Ed Maste]

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

Deprecating ftpd in the FreeBSD base system?

[Ed Maste]

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 here.
___
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: tracking -current, using poudriere-devel and the switch to git

[Ed Maste]

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 moment, is svn behind git in terms of most recent updates, or the other
> way round?

Today the canonical src, doc, and ports [Subversion] repos are ahead;
GitHub and cgit-beta are behind to varying degrees.
___
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: tracking -current, using poudriere-devel and the switch to git

[Ed Maste]

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 repos are
https://cgit-beta.freebsd.org/doc.git
https://cgit-beta.freebsd.org/src.git
https://cgit-beta.freebsd.org/ports.git
Branch name is "main"

The hashes in these repos will change at least once more to clean up
some broken metadata from the svn mirror process.

If you want to use Git with repos that will remain consistent (hashes
will not change) for the immediate future, use the GitHub mirror
https://github.com/freebsd/freebsd-doc
https://github.com/freebsd/freebsd
https://github.com/freebsd/freebsd-ports
Branch is "master"

> If -current fails to compile, how do we reference it? In svn, I'd point svn
> info at the sources and it would give a revision number. How is this done with
> git?

>From the rev-parse man page:
| Print the object name of the current commit:
|
| $ git rev-parse --verify HEAD

> At the moment, is svn behind git in terms of most recent updates, or the other
> way round?

Today the canonical src, doc, and ports repos are ahead; GitHub and
cgit-beta are behind to varying degrees.
___
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: vfs.zfs.min_auto_ashift and OpenZFS

[Ed Maste]

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.
___
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: vfs.zfs.min_auto_ashift and OpenZFS

[Ed Maste]

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 - I've submitted PR 249157 to track that.
___
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: Please check the current beta git conversions

[Ed Maste]

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.

In fact my clone was larger than it should be, because it had old
leftover objects from earlier iterations of the conversion. After
cleaning those up I see 1.5GB in .git, 2.2GB including the working
tree. My .svn directory has 1.7GB of data.

If you have only one working tree then Git's disk space requirements
should be "about the same." Each additional working tree tips the
scale increasingly in GIt's favour.

If disk space is a concern you can clone with the -depth=1 option,
which avoids fetching history. I tried that just now and have a .git
directory of about 250MB.
___
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: Plans for git (was: Please check the current beta git conversions)

[Ed Maste]

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 by reading the Git Book.

This doc started as a direct translation of the Subversion primer,
which has as its first sentence:
> New committers are assumed to already be familiar with the basic operation of 
> Subversion. If not, start by reading the Subversion Book.

As with the Subversion primer the doc is intended to provide a quick
reference for day-to-day commands, but not act as a reference or
introduction to the entire theory of operation of the associated VCS.
___
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: Plans for git (was: Please check the current beta git conversions)

[Ed Maste]

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/
> > https://git-scm.com/docs/hash-function-transition
>
> "soon now" seems a bit vague, from what I have read on the subject,
> whilst the local repository operations are working with SHA256 hashes,
> it is still lacking remote transport, clones, and such.

Yes, Git will migrate to SHA256 but will not be completely finished
sufficiently soon to matter for our needs. We'll eventually deal with
the migration the same way as everyone else.
___
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: Please check the current beta git conversions

[Ed Maste]

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

If you have only one checkout git will require a bit more disk space
than svn. However, if you have two or more working trees (say, vanilla
FreeBSD and multiple work-in-progress trees, or head and stable
branches, etc.) using "git worktree" will share the .git directory and
in total will occupy less space than the equivalent in svn.

I'd expect clones to take minutes, although cgit-beta is running on a
lower spec jail host and might have trouble if many people are cloning
at the same time.
___
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: Please check the current beta git conversions

[Ed Maste]

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 do let us know how long it took
overall.

We will have mirrors set up, which will be some combination of our own
hosts, GitHub, GitLab, or other third party hosts.

The current GitHub mirror is generated from an old version of svn2git,
which misses a lot of metadata - in particular, merges (for vendor
branch updates and such) are just missing. There are also some
mistakes that originated in our Subversion mirror network that are now
stuck in the current GitHub Mirror (commits authored by "svnmir"
instead of the correct committer, for example). We expect we will
continue to have a mirror on GitHub since many folks consider it "the"
repository of open source projects. There will be a documented process
for folks to migrate from the old to the new version of the mirror
___
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"

Please check the current beta git conversions

[Ed Maste]

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 believes the conversion represents a
high-fidelity translation of the Subversion history, but would
appreciate additional review in case we've missed anything.

I'd ask folks with an interest in the FreeBSD repository to clone the
beta conversion and review the converted history in the specific areas
they are interested in - e.g., specific contrib/ software, device
drivers, etc. This will also present our final opportunity to change
the author map file, if necessary.

The beta src tree can be cloned via:
% git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta

Please follow up this week if you notice any discrepancies or author
entries that require updates.
___
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"