Re: August 2025 stabilization week

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 25 Aug 2025 16:18:01 UTC
On Mon, Aug 25, 2025 at 10:09 AM Kyle Evans <kevans@freebsd.org> wrote:

> On 8/25/25 07:53, Gleb Smirnoff wrote:
> >    Hi,
> >
> > On Mon, Aug 25, 2025 at 01:00:07AM -0700, Gleb Smirnoff wrote:
> > T> This is an automated email to inform you that the August 2025
> stabilization week
> > T> started with FreeBSD/main at main-n279838-6c45a5dad0a0, which was
> tagged as
> > T> main-stabweek-2025-Aug.
> >
> > This stabilization cycle is expected to be more bumpy than usually.
> >
> > 1) We got major upgrade - OpenSSL 3.5.1. One known issue is that the
> legacy
> > provider is broken.
> >
> > 2) The default Kerberos now is MIT.  We have already checked that a
> Kerberized
> > NFS client can migrate from Heimdal to MIT.  We did not check Kerberized
> NFS
> > server, but should be fine.  There is no yet an official way to migrate
> kdc
> > from Heimdal to MIT.  So, if you are upgrading a machine that is kdc,
> you need
> > WITHOUT_MITKRB5="yes" in your src.conf.
> >
> > 3) The official pkg repo is now almost empty, see email from Colin [1].
> So, do
> > not rush with 'make delete-old-libs', unless you are ready to build a
> lot of
> > packages yourself.
> >
> > 4) The unfortunate coincidence with 3) is ABI breakage in the
> > setgroups(2)/getgroups(2) syscalls compared to the July stabilization
> point.
> > Some packages would dump core.  These packages need to be rebuilt.
> >
>
> This should be mitigated if you have COMPAT_FREEBSD14 enabled?  Old
> packages would
> reference the old compat symbol versions in libc, which should use the
> COMPAT_FREEBSD14
> variants of setgroups/getgroups.  If you have a pointer to scenarios where
> that isn't
> the case, that'd be helpful- old packages should be fine in the GENERIC
> case.
>

The packages that have been core dumping have so far all been SIGSYS not
SIGSEGV which means Kyle's analysis is spot on. It's a fundamental use case
that we powered through with even more radical changes like ino64. The only
real problem one might encounter is if you install the new world, it uses
the new system calls, but you have to revert the kernel to a one that only
had the old version. Thankfully, regressions like this these days are are.

I have another:

5) jemalloc was updated to 5.3.0, which in the past have had issues, but so
far the only email has been a variation on thanking me for finally finding
the time to get it in.

Warner