Re: August 2025 stabilization week
- Reply: Konstantin Belousov : "Re: August 2025 stabilization week"
- In reply to: Konstantin Belousov : "Re: August 2025 stabilization week"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 29 Aug 2025 03:21:43 UTC
On 8/28/25 22:07, Konstantin Belousov wrote: > On Thu, Aug 28, 2025 at 06:06:54PM -0500, Kyle Evans wrote: >> On 8/28/25 17:21, Olivier Cochard-Labbé wrote: >>> >>> On Wed, Aug 27, 2025 at 7:26 PM Olivier Cochard-Labbé <olivier@freebsd.org <mailto:olivier@freebsd.org>> wrote: >>> >>> >>> >>> I'm still waiting for our contributions about this stabweek before closing the week. >>> >>> >>> >>> >>> The "August 2025 stabilization week" is now over. >>> >>> This stabweek has been more challenging than usual, so please be aware of the following known issues: >>> >>> 1. OpenSSL 3.5.1: The legacy provider is broken, causing some ports to fail. A temporary fix is to use `env CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1`. Cf an example of regression in PR/273656 >>> >>> 2. MIT Kerberos: The default Kerberos is now MIT. Clients should migrate smoothly, but some scripts may need adjusting. Machines running kdc must continue to use Heimdal by setting WITHOUT_MITKRB5="yes" in /etc/src.conf. >>> >>> 3. Still empty Pkg repo today: The official package repository is currently almost empty. Don't run `make delete-old-libs` unless you're prepared to build packages from source. A bug in the current version of pkg means that running `pkg upgrade` might result in the removal of many packages due to this empty repository state. >>> >>> 4. ABI Breakage: A recent ABI change in `setgroups(2)` and `getgroups(2)` syscalls will cause some packages to crash. These packages must be rebuilt. >>> >> >> At the risk of being both repetitive and pedantic, I note once more that it's important to emphasize that they must be rebuilt >> *if you are not running a kernel with COMPAT_FREEBSD14*. The distinction is quite important because if you're not running >> GENERIC or MINIMAL and you need to rebuild, ok, cool, that's the usual process. If you're running GENERIC or MINIMAL and >> you need to rebuild, I really want to hear about it because that means I broke something that wasn't supposed to break. >> > > To be correct, this is not an ABI breakage. Old binaries which are linked > against setgroups@FBSD_1.0/SYS_freebsd14_setgroups#80, get the old behavior. > The new behavior of setgroups@FBSD_1.8/SYS_setgroups#596 is what hits the > old unaware code _after recompilation and linking_. > I haven't yet seen any reports of problems after recompilation and linking, but I'm interested in those as well, of course. The reports we've seen to-date that I am aware of have been from getting smacked with a SIGSYS or SIGABRT, and I suspect the latter may have been something that fork()ed a child that got hit with a SIGSYS, which effectively asserted in the parent when the child did not exit as expected. We weren't able to collect any debug information from the SIGABRT case to confirm, though. > I.e. while being perfectly ABI compatible there, we get some nuanced new > behavior that is impossible to detect at the compile time. I was assured > that the advantages of this change overcome the inconvinience. > > not assuming egid presence is provided >>> 5. ZFS Kernel Panic: We've identified a 100% reproducible kernel panic when running ZFS regression tests. The bug has been reported on PR/289131. The FreeBSD CI ZFS tests have not been running for about a month, with the latest run also resulting in a panic too [1]. >>> >>> Thanks for your reports, >>> >>> Olivier >>> >>> [1] https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console <https://ci.freebsd.org/job/FreeBSD-main-amd64-test_zfs/14237/console> >> >