From nobody Sun Oct 8 18:13:16 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S3Vf83h1mz4wmY4 for ; Sun, 8 Oct 2023 18:13:36 +0000 (UTC) (envelope-from jbo@insane.engineer) Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S3Vf64NgLz3fJf for ; Sun, 8 Oct 2023 18:13:33 +0000 (UTC) (envelope-from jbo@insane.engineer) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=insane.engineer header.s=protonmail2 header.b=73jeahQH; spf=pass (mx1.freebsd.org: domain of jbo@insane.engineer designates 185.70.43.17 as permitted sender) smtp.mailfrom=jbo@insane.engineer; dmarc=pass (policy=none) header.from=insane.engineer DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insane.engineer; s=protonmail2; t=1696788810; x=1697048010; bh=KttfZlh1a8x8knHWgN1oZg3M0JeMnIi4xxN6DRj7w68=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=73jeahQHHE2rNoQjw4yYpq+8SiHmbDw+upaubgw3CklaCR3zpk6GqRXDU/r+E5Sz2 /yYskqkh9AZvdQnvDkzxgpwwat/wMYFKuG4YfJqpYAIHoxH+vUypmLI/zji/9lcOAR U7bgYxIk7owYoUbqUMbZXZvJzphevLRs1LSaix0gjYuCuiHDk82+DnzYI68C6MTXyC A4hud8z2aHLOiNm0aRSbRUPPPtSlQYOSFMEFcI0GCa1SPYeFh9DFC+ZXzqlAscU6b9 i+G+qaO5zG33oC1aO+jmk2BnJ8haelmbyQVHRFmPRNVDzCTX+3rWZjkiplfNFECl8x 3WSf5lrIRZ06A== Date: Sun, 08 Oct 2023 18:13:16 +0000 To: FreeBSD-STABLE Mailing List From: jbo@insane.engineer Subject: Re: Base libc++ missing symbol Message-ID: In-Reply-To: <7C16CD19-6974-40A2-BCF2-16BD9924945D@yahoo.com> References: <97AB873D-57E4-48D3-985D-AAD64FB42E65@yahoo.com> <7C16CD19-6974-40A2-BCF2-16BD9924945D@yahoo.com> Feedback-ID: 40997969:user:proton List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[insane.engineer,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[185.70.43.17:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; R_DKIM_ALLOW(-0.20)[insane.engineer:s=protonmail2]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; FREEFALL_USER(0.00)[jbo]; DKIM_TRACE(0.00)[insane.engineer:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4S3Vf64NgLz3fJf > The procedure of seeing if the a.out is produced without complaint > might still be useful. The program compiles & links fine, but then also fails to run: ld-elf.so.1: Undefined symbol "_ZTVNSt3__13pmr25monotonic_buffer_resourceE"= referenced from COPY relocation in /usr/home/jbo/junk/a.out I made no progress on this. I have reinstalled world twice (from different commits) and I re-installed all packages multiple times (also from differen= t ports tree commits). Any other wild ideas on how to fix this? None of my other machines have any issues whatsoever running on the same or similar stable/13 commit and using the same poudriere repository. This is certainly not Qt5 related. I run into the exact same issue with anything that uses Qt6. Furthermore, the test program we built experiences the same issue without any involvement of the Qt libraries. Best regards, ~ jbo ------- Original Message ------- On Tuesday, October 3rd, 2023 at 02:48, Mark Millard wr= ote: >=20 >=20 > On Oct 2, 2023, at 15:56, Mark Millard marklmi@yahoo.com wrote: >=20 > > Joel Bodenmann wrote on > > Date: Mon, 02 Oct 2023 20:00:29 UTC : > >=20 > > > It seems like I finally managed to hose a FreeBSD system. > > > The machine in question is my workstation at home. It has been runnin= g > > > stable/13 without any problems. Yesterday I've updated to > > > ef295f69abbffb3447771a30df6906ca56a5d0c0 and since then I'm getting a= n > > > undefined symbol on anything using Qt: > > >=20 > > > ld-elf.so.1: /usr/local/lib/qt5/libQt5Widgets.so.5: Undefined symbol > > > "_ZTVNSt3__13pmr25monotonic_buffer_resourceE" > > >=20 > > > Unless I'm missing something, it would seem like my base libc++ > > > is missing the pmr::monotonic_buffer_resource symbol. > >=20 > > I do not have a 13.2 context, so you may want to run the > > analogous steps in your context for confirming/denying > > the below applies. > >=20 > > # llvm-cxxfilt _ZTVNSt3__13pmr25monotonic_buffer_resourceE > > vtable for std::__1::pmr::monotonic_buffer_resource > >=20 > > Using the example "Run this code" source from: > >=20 > > https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource > >=20 > > # c++ -std=3Dc++17 -pedantic -O2 monotonic_buffer_resource.cpp > >=20 > > # objdump -x a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE > > 0000000000204160 g O .bss.rel.ro 0000000000000038 _ZTVNSt3__13pmr25mono= tonic_buffer_resourceE > >=20 > > # nm a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE > > 0000000000204160 B _ZTVNSt3__13pmr25monotonic_buffer_resourceE > >=20 > > # ./a.out > > t1 (default std alloc): 0.491 sec; t1/t1: 1.000 > > t2 (default pmr alloc): 0.541 sec; t1/t2: 0.906 > > t3 (pmr alloc no buf): 0.188 sec; t1/t3: 2.616 > > t4 (pmr alloc and buf): 0.155 sec; t1/t4: 3.172 > >=20 > > Note that the vtable is in the a.out instead of being from > > a library. It is global but is in the a.out .bss.rel.ro http://bss.rel.= ro/ in > > the example and is defined. > >=20 > > > At first I thought I might have messed up on installworld but rolling > > > back to the previous boot environment and then performing the same > > > procedure again lead to the same outcome. > >=20 > > If the above works similarly in your context, then I expect > > that the issue is on the qt5 or port side of things, not the > > system libraries/headers. > >=20 > > As I understand, clang++ 16 is the first vintage with this > > directly supported, instead of being just in the experimental > > category/area for libc++. May be tracking that transition is > > at issue. > >=20 > > For reference: > >=20 > > # c++ -v > > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) > > Target: x86_64-unknown-freebsd15.0 > > Thread model: posix > > InstalledDir: /usr/bin > >=20 > > # uname -apKU > > FreeBSD amd64-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #124 main-n265447-e= 5236d25f2c0-dirty: Thu Sep 21 09:06:08 PDT 2023 root@amd64-ZFS:/usr/obj/BUI= LDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64= amd64 1500001 1500001 > >=20 > > > Any ideas or wild guesses? Anything obvious I'm missing here? > > >=20 > > > uname -a > > > FreeBSD beefy02 13.2-STABLE FreeBSD 13.2-STABLE > > > stable/13-n256443-ef295f69abbf GENERIC amd64 > > >=20 > > > freebsd-version -kru > > > 13.2-STABLE > > > 13.2-STABLE > > > 13.2-STABLE > > >=20 > > > clang --version > > > FreeBSD clang version 16.0.6 > > > (https://github.com/llvm/llvm-project.git > > > llvmorg-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd13.2 > > > Thread model: posix > > > InstalledDir: /usr/bin >=20 >=20 > Given Dimitry Andric's notes: >=20 > # objdump -x /lib/libc++.so.1 | grep _ZTVNSt3__13pmr25monotonic_buffer_re= sourceE > 00000000001006d8 g O .data.rel.ro 0000000000000038 _ZTVNSt3__13pmr25monot= onic_buffer_resourceE >=20 > # nm /lib/libc++.so.1 | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE > 00000000001006d8 D _ZTVNSt3__13pmr25monotonic_buffer_resourceE >=20 > So /lib/libc++.so.1 has a global symbol naming initialized data > for this in my context. >=20 > Reminder for the a.out: >=20 > # objdump -x a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE > 0000000000204160 g O .bss.rel.ro 0000000000000038 _ZTVNSt3__13pmr25monoto= nic_buffer_resourceE >=20 > # nm a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE > 0000000000204160 B _ZTVNSt3__13pmr25monotonic_buffer_resourceE >=20 > My original thinking makes no sense for this. Sorry for the noise. >=20 > The procedure of seeing if the a.out is produced without complaint > might still be useful. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Sun Oct 8 23:33:45 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S3dlx56F9z4wF8c for ; Sun, 8 Oct 2023 23:34:05 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from exhmta20.bpe.bigpond.com (exhmta20.bpe.bigpond.com [203.42.40.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S3dlt3tqVz4tdK; Sun, 8 Oct 2023 23:34:01 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bigpond.net.au header.s=202303 header.b="iM/9OLK "; spf=pass (mx1.freebsd.org: domain of areilly@bigpond.net.au designates 203.42.40.164 as permitted sender) smtp.mailfrom=areilly@bigpond.net.au; dmarc=pass (policy=reject) header.from=bigpond.net.au DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bigpond.net.au; s=202303; h=To:Date:Message-Id:Subject:Mime-Version: Content-Type:From; bh=7whN+B+urC6ZoJ7VD70eEeAks7LvwtN4uJlZuaCZ8wo=; b=iM/9OLK CnBrAAWQrrO6GT6L0C2Nd4XPdrp2k/FPE/f4ly7bkL83WMxlCZ8WMkxknNlO6SY35hJ5rkXjUlL5a ZRFVckppnf7cMA02Az35/LAa0BYxvgre7kBAfPAxdCYmm6e7J+fdEvJFJiZx1DaAW/JIo+w7JrVbn gHl1D3sYCLA1TWU15C4qp+KmguPzs0jrkYnYrrMsl+5Jtnh24eyk8DXzp4VSWgi228ojq+WGMXnIi UCFWn3r4NeZv3W27jrwPOYv9Gj/0MtMu2EirrlP6c0GLstTfJ1T4s5CHtXItpzvlF2zq72BSW7N3t cAy6//Zl0Yd2vb0KWc/6lG4MdsA==; Received: from exhprdcmr12 by exhprdomr20 with esmtp (envelope-from ) id 1qpdHZ-0003qe-1H for ; Mon, 09 Oct 2023 10:33:57 +1100 Received: from [121.223.155.16] (helo=smtpclient.apple) by exhprdcmr12 with esmtpa (envelope-from ) id 1qpdHZ-00017P-0f; Mon, 09 Oct 2023 10:33:57 +1100 From: Andrew Reilly Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Change to installation of security/ca_root_nss seems to have broken my mail? Message-Id: <0F710F4D-FE91-4B88-8ADB-8D98379E95B1@bigpond.net.au> Date: Mon, 9 Oct 2023 10:33:45 +1100 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-stable@freebsd.org, security@freebsd.org X-Mailer: Apple Mail (2.3774.100.2.1.4) X-tce-id: areilly@bigpond.net.au X-tce-ares-id: e{03dc23e6-ae76-4ebd-8e05-c0996a6a3031}1 X-tce-spam-action: no action X-tce-spam-score: 0.0 X-Cm-Analysis: v=2.4 cv=GbnR3ybL c=1 sm=1 tr=0 ts=65233c65 a=g7JjhvAvvPZ9ycLFhywHJA==:117 a=g7JjhvAvvPZ9ycLFhywHJA==:17 a=82bfCIg-0F7sWS62:21 a=kj9zAlcOel0A:10 a=bhdUkHdE2iEA:10 a=IzOhgYWHAAAA:8 a=FKY7v4bjAAAA:8 a=6I5d2MoRAAAA:8 a=5luJbs9T8tFAYQKl0CkA:9 a=CjuIK1q_8ugA:10 a=eMKpbHEEDmzIGCaig7Sg:22 a=IjZwj45LgO3ly-622nXo:22 a=wTPEw03mt57gkTNY_DXp:22 X-Cm-Envelope: MS4xfHd+4gvRnDTa811R16M7kvq8MJsN1iOcbuzrIwhv6gLpHg3KgufPNMbS/eY9KLtrk1Zcfak8PBsUUtMp13hX1G5a1NnS2dZD1kmVQM/G4TQtwtLI9w7M PUkxh5b09BT0R0TrPDRUBIzRfN6/NamxOKMuE/OQSQnYWVWD0vbCRu+KLIFp7cM99hg8OAz3qVb1qw== X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.99)[-0.988]; DMARC_POLICY_ALLOW(-0.50)[bigpond.net.au,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[bigpond.net.au:s=202303]; R_SPF_ALLOW(-0.20)[+ip4:203.42.40.128/25]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[203.42.40.164:from]; ARC_NA(0.00)[]; ASN(0.00)[asn:1221, ipnet:203.40.0.0/13, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[bigpond.net.au:+]; FREEMAIL_FROM(0.00)[bigpond.net.au]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[bigpond.net.au]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4S3dlt3tqVz4tdK Hi all, I've had security/openssl31 installed for many months, and all dependent = ports rebuilt against it, (with ssl=3Dopenssl31 in DEFAULT_VERSIONS) so = that I could keep an eye on what might have issues with it, assuming an eventual change to the 3-series in base. And maybe it's more secure, = given that it's had a pile of extra work done to it, while 1.1.1... is = in maintenance. Up to this weekend, everything has been great. One of the applications that I use that depends on openssl is = mail/fetchmail, which I use to retrieve mail from my ISP's IMAP server = at imap.telstra.com:993. Coincident with updating the security/ca_root_nss port, fetchmail = started to complain that the imap server was using a self-signed = certificat in its chain: Oct 7 09:09:52 zen fetchmail[3770]: Server certificate verification = error: self-signed certificate in certificate chain Oct 7 09:09:52 zen fetchmail[3770]: Missing trust anchor certificate: = /C=3DUS/O=3DDigiCert Inc/OU=3Dwww.digicert.com/CN=3DDigiCert Global Root = CA Oct 7 09:09:52 zen fetchmail[3770]: This could mean that the root CA's = signing certificate is not in the trusted CA certificate location, or = that c_rehash needs to be run on the certificate directory. For details, = please see the documentation of --sslcertpath and --sslcertfile in the = manual page. See README.SSL for details. Oct 7 09:09:52 zen fetchmail[3770]: OpenSSL reported: = error:0A000086:SSL routines::certificate verify failed Oct 7 09:09:52 zen fetchmail[3770]: imap.telstra.com: SSL connection = failed. After some head-scratching, I rebuilt fetchmail manually so that it was = configured to use the openssl1.1.1w in base, rather than the port, and = now it works again. I haven't been able to figure out why. I've tried rebuilding openssl31 with all of the optional (deprecated) = pieces turned on, on the suspicion that Telstra must be using something = dodgy, but their certificate does not seem to have changed recently, and = does not look especially dodgy to me: it seems to be signed by the DigiCert = Global CA. Looking at the timing of the failure and what changed at that point, I = can now see that it was not openssl31 as such, but security/ca_root_nss = that changed, and it did not change by upstream version, just by port = version, due to a change in the way that it is installed: = https://reviews.freebsd.org/D42045 Does anyone have any thoughts about why this change would have broken = this very specific thing, and perhaps what I can do about it? Cheers, Andrew From nobody Mon Oct 9 01:07:20 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S3gqt5L5Vz4wW30 for ; Mon, 9 Oct 2023 01:07:38 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from exhmta09.bpe.bigpond.com (exhmta09.bpe.bigpond.com [203.42.40.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S3gqr12zXz3NcJ; Mon, 9 Oct 2023 01:07:35 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bigpond.net.au header.s=202303 header.b=ew+umEi6; spf=pass (mx1.freebsd.org: domain of areilly@bigpond.net.au designates 203.42.40.153 as permitted sender) smtp.mailfrom=areilly@bigpond.net.au; dmarc=pass (policy=reject) header.from=bigpond.net.au DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bigpond.net.au; s=202303; h=To:Date:Subject:Mime-Version:Content-Type: Message-Id:From; bh=G8dIcqlKhX37SJE31HBeJW24jWf0rkZPY/pSPts6wkM=; b=ew+umEi6N uq4F6PfGmVeULO9c1/vhTQU0YNtZxzI1RXYURLuOGucsasJTzyg7rhqwJRSP+qMaWonGUz74/fm2c tc77v2py1kVvZZViCy/cOGWCF6xQBQY/iYG+Mq64N90SvnVnasnv390+d4lMqO68tF+E2+Ix2QTYo NfoTCxg5ATrP0QWf10urF2QYdsTqPZYQGJARHDBWzspQ4muZeniuVGLc9YronsZtDNXdo0iXAx9BV mJmvSMZG17in6XOZbrk9aexktRAwiq6NlYRo06vTDuvLbYHSrJIJiQ3OgVaC21khiTdsaLf8SZg6f vxfn2Tys4+u4+62+bUcVOiJlQ==; Received: from exhprdcmr12 by exhprdomr09 with esmtp (envelope-from ) id 1qpek8-000Dsw-0P for ; Mon, 09 Oct 2023 12:07:32 +1100 Received: from [121.223.155.16] (helo=smtpclient.apple) by exhprdcmr12 with esmtpa (envelope-from ) id 1qpek7-0003sV-39; Mon, 09 Oct 2023 12:07:32 +1100 From: Andrew Reilly Message-Id: <558CB491-D27A-4B3D-80CB-FE3ECBD17167@bigpond.net.au> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E41C694-7252-4CF7-AE72-B19705FB889E" List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Re: Change to installation of security/ca_root_nss seems to have broken my mail? Date: Mon, 9 Oct 2023 12:07:20 +1100 In-Reply-To: <0F710F4D-FE91-4B88-8ADB-8D98379E95B1@bigpond.net.au> Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-stable@freebsd.org, security@freebsd.org References: <0F710F4D-FE91-4B88-8ADB-8D98379E95B1@bigpond.net.au> X-Mailer: Apple Mail (2.3774.100.2.1.4) X-tce-id: areilly@bigpond.net.au X-tce-ares-id: e{fbbe7aca-bb81-4cd2-bff9-5e091ea31fa8}1 X-tce-spam-action: no action X-tce-spam-score: 0.0 X-Cm-Analysis: v=2.4 cv=GbnR3ybL c=1 sm=1 tr=0 ts=65235254 a=g7JjhvAvvPZ9ycLFhywHJA==:117 a=g7JjhvAvvPZ9ycLFhywHJA==:17 a=82bfCIg-0F7sWS62:21 a=bhdUkHdE2iEA:10 a=6I5d2MoRAAAA:8 a=Sv2sojjTAAAA:8 a=IzOhgYWHAAAA:8 a=FKY7v4bjAAAA:8 a=X7RQYMLZx4P74dPfva4A:9 a=CjuIK1q_8ugA:10 a=wJE93UmOUp8IdplB:21 a=_W_S_7VecoQA:10 a=IjZwj45LgO3ly-622nXo:22 a=eMKpbHEEDmzIGCaig7Sg:22 a=wTPEw03mt57gkTNY_DXp:22 X-Cm-Envelope: MS4xfOWqb6KkGK4pc57cZ2ACQK8d+YzodTnIePQ7laXSTtSHumuOIIQ2cCnWybcl45yHYKszf0eX7baMa06E1btNLJ0mQnwhwg7iEC+WFOlTiA3E5AN/pqAE fU2QlHQ27MovqT9l0oZncOflCyw5aXiOVKWBqydlexSET2gIw8t0w8rEzcKbpi+ndd59S4GO0dUwJg== X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.48 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[bigpond.net.au,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:203.42.40.128/25]; R_DKIM_ALLOW(-0.20)[bigpond.net.au:s=202303]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[203.42.40.153:from]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[bigpond.net.au:+]; FREEMAIL_FROM(0.00)[bigpond.net.au]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:1221, ipnet:203.40.0.0/13, country:AU]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[bigpond.net.au]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4S3gqr12zXz3NcJ --Apple-Mail=_4E41C694-7252-4CF7-AE72-B19705FB889E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi again, I just noticed that the bottom of that reviews link includes a reference = to this one: = https://reviews.freebsd.org/R11:52e0c40367d3ebd09ab7169e025c37fbf70b8dee and that restores the symlinks and bumps the port revision up to 2. I've just updated my ports tree to catch that and rebuilt both = security/ca_root_nss and mail/fetchmail and can (happily) confirm that = this has fixed the problem for me. So I guess that security/openssl31 = is one of the ports that relies on the previous symlink. Cheers, Andrew > On 9 Oct 2023, at 10:33, Andrew Reilly wrote: >=20 > Hi all, >=20 > I've had security/openssl31 installed for many months, and all = dependent ports rebuilt against it, (with ssl=3Dopenssl31 in = DEFAULT_VERSIONS) so that I could keep an eye on what might have issues = with it, assuming an > eventual change to the 3-series in base. And maybe it's more secure, = given that it's had a pile of extra work done to it, while 1.1.1... is = in maintenance. Up to this weekend, everything has been great. >=20 > One of the applications that I use that depends on openssl is = mail/fetchmail, which I use to retrieve mail from my ISP's IMAP server = at imap.telstra.com:993. >=20 > Coincident with updating the security/ca_root_nss port, fetchmail = started to complain that the imap server was using a self-signed = certificat in its chain: >=20 > Oct 7 09:09:52 zen fetchmail[3770]: Server certificate verification = error: self-signed certificate in certificate chain > Oct 7 09:09:52 zen fetchmail[3770]: Missing trust anchor certificate: = /C=3DUS/O=3DDigiCert Inc/OU=3Dwww.digicert.com/CN=3DDigiCert Global Root = CA > Oct 7 09:09:52 zen fetchmail[3770]: This could mean that the root = CA's signing certificate is not in the trusted CA certificate location, = or that c_rehash needs to be run on the certificate directory. For = details, please see the documentation of --sslcertpath and --sslcertfile = in the manual page. See README.SSL for details. > Oct 7 09:09:52 zen fetchmail[3770]: OpenSSL reported: = error:0A000086:SSL routines::certificate verify failed > Oct 7 09:09:52 zen fetchmail[3770]: imap.telstra.com: SSL connection = failed. >=20 > After some head-scratching, I rebuilt fetchmail manually so that it = was configured to use the openssl1.1.1w in base, rather than the port, = and now it works again. I haven't been able to figure out why. >=20 > I've tried rebuilding openssl31 with all of the optional (deprecated) = pieces turned on, on the suspicion that Telstra must be using something = dodgy, but their certificate does not seem to have changed recently, and = does > not look especially dodgy to me: it seems to be signed by the DigiCert = Global CA. >=20 > Looking at the timing of the failure and what changed at that point, I = can now see that it was not openssl31 as such, but security/ca_root_nss = that changed, and it did not change by upstream version, just by port = version, > due to a change in the way that it is installed: = https://reviews.freebsd.org/D42045 >=20 > Does anyone have any thoughts about why this change would have broken = this very specific thing, and perhaps what I can do about it? >=20 > Cheers, >=20 > Andrew >=20 --Apple-Mail=_4E41C694-7252-4CF7-AE72-B19705FB889E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = again,

I just noticed that the bottom of that reviews = link includes a reference to this one: https://reviews.freebsd.org/R11:52e0c40367d3ebd09ab7169e025c37fbf7= 0b8dee
and that restores the symlinks and bumps the port = revision up to 2.

I've just updated my ports = tree to catch that and rebuilt both security/ca_root_nss and = mail/fetchmail and can (happily) confirm that this has fixed the problem = for me.  So I guess that security/openssl31 is one of the ports = that relies on the previous = symlink.

Cheers,

Andrew<= /div>



On 9 Oct 2023, at 10:33, Andrew Reilly = <areilly@bigpond.net.au> wrote:

Hi all,

I've had = security/openssl31 installed for many months, and all dependent ports = rebuilt against it, (with ssl=3Dopenssl31 in DEFAULT_VERSIONS) so that I = could keep an eye on what might have issues with it, assuming = an
eventual change to the 3-series in base.  And maybe it's more = secure, given that it's had a pile of extra work done to it, while = 1.1.1... is in maintenance.  Up to this weekend, everything has = been great.

One of the applications that I use that depends on = openssl is mail/fetchmail, which I use to retrieve mail from my ISP's = IMAP server at imap.telstra.com:993.

Coincident with updating the = security/ca_root_nss port, fetchmail started to complain that the imap = server was using a self-signed certificat in its chain:

Oct =  7 09:09:52 zen fetchmail[3770]: Server certificate verification = error: self-signed certificate in certificate chain
Oct  7 = 09:09:52 zen fetchmail[3770]: Missing trust anchor certificate: = /C=3DUS/O=3DDigiCert Inc/OU=3Dwww.digicert.com/CN=3DDigiCert Global Root = CA
Oct  7 09:09:52 zen fetchmail[3770]: This could mean that the = root CA's signing certificate is not in the trusted CA certificate = location, or that c_rehash needs to be run on the certificate directory. = For details, please see the documentation of --sslcertpath and = --sslcertfile in the manual page. See README.SSL for details.
Oct =  7 09:09:52 zen fetchmail[3770]: OpenSSL reported: = error:0A000086:SSL routines::certificate verify failed
Oct  7 = 09:09:52 zen fetchmail[3770]: imap.telstra.com: SSL connection = failed.

After some head-scratching, I rebuilt fetchmail manually = so that it was configured to use the openssl1.1.1w in base, rather than = the port, and now it works again.  I haven't been able to figure = out why.

I've tried rebuilding openssl31 with all of the optional = (deprecated) pieces turned on, on the suspicion that Telstra must be = using something dodgy, but their certificate does not seem to have = changed recently, and does
not look especially dodgy to me: it seems = to be signed by the DigiCert Global CA.

Looking at the timing of = the failure and what changed at that point, I can now see that it was = not openssl31 as such, but security/ca_root_nss that changed, and it did = not change by upstream version, just by port version,
due to a change = in the way that it is installed: = https://reviews.freebsd.org/D42045

Does anyone have any thoughts = about why this change would have broken this very specific thing, and = perhaps what I can do about = it?

Cheers,

Andrew

= --Apple-Mail=_4E41C694-7252-4CF7-AE72-B19705FB889E-- From nobody Mon Oct 9 06:35:27 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S3q6T4VGWz4whxk for ; Mon, 9 Oct 2023 06:35:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S3q6S5HQ7z4bl7 for ; Mon, 9 Oct 2023 06:35:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BDJZXqXx; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1696833341; bh=liZJeFMNMEEX3in7qxbbDN9BqaIMZOTM78dDl35be+w=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=BDJZXqXxETivLi75V2cBrff3PKrpnLbe3krka8Lc2715OqvpE7yfIf9PnhXz+uIWI32VJttqRA2GH0j7RnYtJlHs5CLThp5X82WszW3NkAEOik6xTrrtGXsM1zrnLIH5JIxi30kPNNoYimG9aSlwefmcIijQ32lRsVseTOj5GUG1hjVXHDw/2iWUzNeuc47NYzfcvlXoAb5NmNyHqPCTid+FRJDD6GlFKwsm/MPw07iIYg7QjjIFK0UWvHw8CjQft5zjLiFmMfvszHJhy6d4zcisRrFBEmn0T6XU+XErZQQqx148PfdsCdJuYWncDXdC2Mm/bVjF+190exeW4nZFjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1696833341; bh=YxjdcPQvfUexzuT72ZUOz3b3wqaTyK+QXDqZGhbFHSD=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=s4CavhyvtFihf7/Svfayw+UR2Xlr71CjxN++R2t/5pdIbnjScYqLj33tpusZIGq0/gYIUc5UwKGUkePJB+Aw/mKeVWcylJk15v1JhIKR+8zf70giNUBhbSyig+heqwoqNh3p9KOaDNlN+Ji6wyp10/gNlUKWUaAthg4pdQTor04OVgVJXsuxR8YeGg3Dhx1lb+p7zDIcBau7sF3Iftupg1IkB5HWn2p0d+j2TZXIYTrzxrsl1th5rJJlm4TXyST95bDhuXISJ/I5cstnNDuTfB2CSvREeNJo0bt4bzP/eh0LJ6iM3AvYewQTFP5qmOqXar83nwIq8k9TcqC+EchHTQ== X-YMail-OSG: TLAd5RgVM1kGwcnmA5CkZy_ci.qK.8GKJ3igtErsqdcBVh_DdkbpV9rQ3HYkVKG vgKddpAWeKfjrkiBWN9KH10z5wMykZk04msw.L9QyqYe6qXqtFlB3AGXmB3ZvkaQ04ASiHe2FxUx 2kmXs9kjSuHkYkYkFRf0wWuBrAPOgeSwZiiS9leg8cL1m54QZU83bQFCgV7WfOZFrkDTDmIAZjXC 3Cl489GNlohKOPylVo4bUhRNJF1Pa8_.8bJXSgkMBE2fGcxDi0h.rHuRRtZCODtGNsnFO0lpO9Ak 1l.LDBZk.hgv8CZbadVV6JnNQA0QkWQzH.5KiJDRk94DkMuEi2oIWJ6lG3A6NAMIXKkK37FxyoAB ZPLw8A6nqWP6OJlXNtj4_Tn.Dob0otkW_3x1ZPEVo94W2s9WZ5nfrE82Z_0yAdq8B3XESbMPUOpQ guB5q78rQMvU4DUpxRvmu97gaGuSwapNUS7PGInkYOyqzhRVlPod47_fE1XMb.i70cbYqW20Z4aA N0bzpn_deA5Auw7s2LNC5sD1XWXMtbR2.eXsckfdR0oZRHV5SNHsF9bTxeGNiNG1fvvt9jRMgn5c ZUdVvtWVjjczpIQowqSPxsp.LtHrHSXEU5vbMfqBUqIddOPTN1bcNToBnr3Z4D14SJB4cU3quNvy ZekKP4mKcKa5apiGlXfOoH1OEE7NsdE6ORGuoBD5nQFC.QLvt6eNTmEfbcw5KtBAqoTIkcEGuXl0 kINr4ggahT2em02wTjc1gilFfb3rnbMaEl6CxVYXxetzih9rKYhUZoIA1i7CykhtCfw89OSrdlaN uSl7H8OCL3EZxYHwiIUnwiRxJ.TpUm.Zv9MwoA1JFLirjyeERM5mj7j4OeuLw2c2_Q.zWtuAgZD9 sjGueDvKGlREOtj45dvYpl55ouAXXuXeyvyMBRCIrd2Sd3Bma_T2A4d8aRzLNEPyi32u_aQcaDG8 Dr64KmIzAdFPYgq.EMaX41.1bEefCYlxzWvu9_F0FN4XZM5br.RG5LKJz_HcR1.dIzQWbKsVTHg2 .Qd.uZu2_buvwnh_M3oZXaigxr_FWjz0v4gpsEAwboBePSacPKUISPeF_FfjUvd2mLr9FDzXe7f5 5Om76gXu7.yTVfdRdLO1z.fCGxfeg21YAblhvjMlP3V7JkkFpyK6cgj2EwEnssS3btmndGX8Txm0 3kkTnVa5YzyTRTM90hauaLRxQxYiinoHP7h3YQ06M3RnUUqLSgQuHMv9n5.t86IBPhYREdRfJg9j PcUbJ66nxsBbgaHeRCWTronrup_0iBsdYYpZtP6iu0pw.i5GLz2.sBnYjNT3mHZXh8CPpxAeQhIN PBSjLD40LbyQqtplI22xC6Z4HuwHQoWu5Pg8_mGJCO1DHql8qyd_e3w4y2LNQRT.LSIj8gSAFu4F hqY8KA5V1p70gXWOsVAUyaG9lOieUOc5fbjasMt_3X4TALEEDqUmL6N.EmyizjDL824599wja6zb 2S0j9SXS86anzZDPPuu1Tysfw5LljKrAg_83OJIooJApcIE2SccET6cu06KW2IK_8XGSL0LpA2GB 0Lrtv0U91gVpRSh1.YDeJomvuzeZPf5maZsB5y139amid6R9W_S0q3TZDhYuC7y87DHsocJIa7P4 2lgqGl01dt8nSZWDFdXbxFk3vZRFa2990fZCPkbSDRQg2dPnfr.pvtUZnFbWGx9A2SUAN.I9gH19 _RCg4Zo20N2Ta8FOL22iqOqH9G60Ag7HQJfCR.K7ZjWAZejPfS3f2Y6aX1ir3mg9DYtHgZo2Yv1t bvih9jkkuUkLCUoZ2TXiLcRK5l3PJu9PoQpYBA84T3fuT8G14fDP2awk2s.51LuH65MMZEy_igTd Oa6AON1k.Xv96AOTq.ZX4.me3iKL10c5.2.klC8MQgA.wAa7hdT40yNyDqx_hWkHxcTJYTaudfe3 YO1xHjyPjIFRaQiQUKNms42z32.JC3Zqa4ZEoC5myOw4AaLPs7EKBp.gZBuD.k2R5f2pxpY0bJjV gGuDRYUknc8677n1gXmpsk0Ry.A1yAVmstwZ8DBTu2gqID0kNSsz8DDdnu2Fm2iZ5g3RSLjMsHyG bymbIv8umq.BRDRiH3ZN_4.Q8DxQCWwLMBCwnIvupp8u4NXeL7zxsePRS47vHMTBaxc0TYSO1rXu Bw2_GEmHgimbo6dk8adeV0KRJAP8ICKK3PzrKa963NtpbFxQ3vy3Xu6yrj_OtLI_FDzai0CXTzS1 xQYEf5L47pCkXzjUhpysnTzfMNqF1jmDMzWEXiTLdTYlQHG2iX0u2eP4Pzu0sKGSpeZLoGBI- X-Sonic-MF: X-Sonic-ID: e994fe4b-ad79-4a01-8249-a6a4d3678911 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Oct 2023 06:35:41 +0000 Received: by hermes--production-bf1-74bfc65597-cp6ng (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 702a0dae61f9b86b98adf5828afb6ce9; Mon, 09 Oct 2023 06:35:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Re: Base libc++ missing symbol Message-Id: <4A3F045F-3379-4651-9099-3319E4C326EE@yahoo.com> Date: Sun, 8 Oct 2023 23:35:27 -0700 To: jbo@insane.engineer, FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3774.100.2.1.4) References: <4A3F045F-3379-4651-9099-3319E4C326EE.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.80)[-0.800]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4S3q6S5HQ7z4bl7 wrote on Date: Sun, 08 Oct 2023 18:13:16 UTC : > > The procedure of seeing if the a.out is produced without complaint > > might still be useful. >=20 > The program compiles & links fine, but then also fails to run: >=20 > ld-elf.so.1: Undefined symbol = "_ZTVNSt3__13pmr25monotonic_buffer_resourceE" referenced from COPY = relocation in /usr/home/jbo/junk/a.out Well, for stable/13 's recent snapshot, freshly dd'd to USB3 media, so an official build, not a personal one that might be odd in some way: # uname -apKU FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE = stable/13-n256505-2464d8c5e296 GENERIC arm64 aarch64 1302508 1302508 (So, after 2023-Oct-01's ef295f69abbf that you originally referenced: = 2023-Oct-04's 2464d8c5e296.) # c++ -v FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) Target: aarch64-unknown-freebsd13.2 Thread model: posix InstalledDir: /usr/bin # c++ -std=3Dc++17 -pedantic -O2 monotonic_buffer_resource.cpp # ./a.out t1 (default std alloc): 1.827 sec; t1/t1: 1.000 t2 (default pmr alloc): 1.818 sec; t1/t2: 1.005 t3 (pmr alloc no buf): 0.920 sec; t1/t3: 1.986 t4 (pmr alloc and buf): 0.606 sec; t1/t4: 3.015 The example is from in an aarch64 context. It does not agree with your report. > I made no progress on this. So far I've never reproduced your problem or anything like it. (I prefer testing official builds for problem isolation. If only my personal builds fail, then it is likely my build's problem.) > I have reinstalled world twice (from different > commits) and I re-installed all packages multiple times (also from = different > ports tree commits). I suggest trying the most recent stable/13 snapshot build at the time of the experiment. No packages are used/needed for the monotonic_buffer_resource.cpp test. This fits well with using a snapshot context for such a test. > Any other wild ideas on how to fix this? I've no evidence about your stable/13 build/install. But the official snapshot that I tried worked just fine. > None of my other machines have any > issues whatsoever running on the same or similar stable/13 commit and = using > the same poudriere repository. That, with my results, tends to suggest you have one odd ball context that has a problematical FreeBSD build/install. Again, I've no evidence to work with relative to that build/install. > This is certainly not Qt5 related. I run into the exact same issue = with > anything that uses Qt6. > Furthermore, the test program we built experiences > the same issue without any involvement of the Qt libraries. There was no problem for my testing of monotonic_buffer_resource.cpp via the recent official snapshot build of stable/13 . I've not tried to test Qt5 or Qt6, sticking with the simpler/smaller context that you also report as failing in the odd context. I suggest avoiding Qt5/Qt6 testing until you have a context with the monotonic_buffer_resource.cpp test working. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Oct 10 14:30:56 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S4dcj277jz4wqlH for ; Tue, 10 Oct 2023 14:31:17 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from mail.punkt.de (mail.punkt.de [IPv6:2a00:b580:8000:11:1c6b:7032:35e9:5616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S4dch1Kbnz4Pwf for ; Tue, 10 Oct 2023 14:31:16 +0000 (UTC) (envelope-from hausen@punkt.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 2a00:b580:8000:11:1c6b:7032:35e9:5616 as permitted sender) smtp.mailfrom=hausen@punkt.de; dmarc=none Received: from smtpclient.apple (unknown [IPv6:2a00:b580:a000:0:b8f2:44d3:a00d:5aed]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.punkt.de (Postfix) with ESMTPSA id 03C2159EE1 for ; Tue, 10 Oct 2023 16:31:06 +0200 (CEST) From: "Patrick M. Hausen" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: State of OpenSSL in releng/13.2? Message-Id: <7B2F19E4-BB12-47FC-BBB6-493E301BDFBB@punkt.de> Date: Tue, 10 Oct 2023 16:30:56 +0200 To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:b580::/32]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; ASN(0.00)[asn:16188, ipnet:2a00:b580::/32, country:DE]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[punkt.de]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4S4dch1Kbnz4Pwf Hi all, FreeBSD 13.2-p4 seems to have OpenSSL 1.1.1t released 2023-02. Since then 3 new minor versions have been published: 1.1.1u 2023-03 1.1.1v 2023-08 1.1.1w 2023-09 all of which fix security vulnerabilities according to: https://www.openssl.org/news/vulnerabilities.html 1.1.1w seems to be in releng/13 but not in releng/13.2. Aren't releases supposed to receive security updates? Kind regards, Patrick --=20 punkt.de GmbH Patrick M. Hausen .infrastructure Sophienstr. 187 76185 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de info@punkt.de AG Mannheim 108285 Gesch=C3=A4ftsf=C3=BChrer: Daniel Lienert, Fabian Stein From nobody Tue Oct 10 18:09:04 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S4kSF26Ndz4x6cD for ; Tue, 10 Oct 2023 18:09:17 +0000 (UTC) (envelope-from jbo@insane.engineer) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S4kSC1WBfz3Hkx for ; Tue, 10 Oct 2023 18:09:14 +0000 (UTC) (envelope-from jbo@insane.engineer) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=insane.engineer header.s=protonmail2 header.b="E50V/kbj"; spf=pass (mx1.freebsd.org: domain of jbo@insane.engineer designates 185.70.43.23 as permitted sender) smtp.mailfrom=jbo@insane.engineer; dmarc=pass (policy=none) header.from=insane.engineer DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insane.engineer; s=protonmail2; t=1696961351; x=1697220551; bh=Sl6hgVXKCsZS8RIO13wusDCfUhkWxD58JXMv1GxiCe0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=E50V/kbj8jqxUV9znLWzMLwHSW1vyJ/AXq1YUhyQpE52hycu+uNsImoRLq0mK0Axc IJEJRWowus4malGAhfW25liRag1Ii2U0UJSvXuT0uqnba1/LIp83QCUBesR8N6OqWN eJLMycotSawrOzhxTszMTqIGPKNLNq2YrqIuM1HVb+CLPNQZZxnljjISyQnqmHlRFI Uvd5L+QWBHj72LqrfS50IjWqpl6yX4eZPHuoCyQ9qqUCbIHMx0NEXi9SteQ7vcGkB4 wNkW+WpJ6R/gJPB9FnOo7iUEzaebqT9X3ToeEE1KR1oCC1d7DZousAnooKFeQpqArl 7mkS+52E6/chg== Date: Tue, 10 Oct 2023 18:09:04 +0000 To: Mark Millard From: jbo@insane.engineer Cc: "stable@freebsd.org" Subject: Re: Base libc++ missing symbol Message-ID: In-Reply-To: <4A3F045F-3379-4651-9099-3319E4C326EE@yahoo.com> References: <4A3F045F-3379-4651-9099-3319E4C326EE.ref@yahoo.com> <4A3F045F-3379-4651-9099-3319E4C326EE@yahoo.com> Feedback-ID: 40997969:user:proton List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[insane.engineer,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[185.70.43.23:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; R_DKIM_ALLOW(-0.20)[insane.engineer:s=protonmail2]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_EQ_ADDR_SOME(0.00)[]; DKIM_TRACE(0.00)[insane.engineer:+]; RCPT_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[jbo]; ARC_NA(0.00)[]; FROM_NO_DN(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4S4kSC1WBfz3Hkx I've updated to commit c11f71789d7d8f741243c21add8d7c5f0ecea03e and the problem is still present. > So far I've never reproduced your problem or anything like it. >=20 > (I prefer testing official builds for problem isolation. If > only my personal builds fail, then it is likely my build's > problem.) Yeah, I couldn't reproduce this either. I have no clue what is going on here. I'm honestly a bit lost on this one. I have not encountered anything like this before. None of my other machines are=20 displaying this problem wile running on the same stable/13 branch (and one machine even on the exact same commit). Current system info: # uname -apKU FreeBSD beefy02 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256520-c11f71789= d7d GENERIC amd64 amd64 1302508 1302508 # freebsd-version -kru 13.2-STABLE 13.2-STABLE 13.2-STABLE # c++ --version FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvm= org-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd13.2 Thread model: posix InstalledDir: /usr/bin ------- Original Message ------- On Monday, October 9th, 2023 at 08:35, Mark Millard wro= te: >=20 >=20 > wrote on >=20 > Date: Sun, 08 Oct 2023 18:13:16 UTC : >=20 > > > The procedure of seeing if the a.out is produced without complaint > > > might still be useful. > >=20 > > The program compiles & links fine, but then also fails to run: > >=20 > > ld-elf.so.1: Undefined symbol "_ZTVNSt3__13pmr25monotonic_buffer_resour= ceE" referenced from COPY relocation in /usr/home/jbo/junk/a.out >=20 >=20 > Well, for stable/13 's recent snapshot, freshly dd'd to USB3 media, > so an official build, not a personal one that might be odd in some way: >=20 > # uname -apKU > FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256505-2464d8c= 5e296 GENERIC arm64 aarch64 1302508 1302508 >=20 > (So, after 2023-Oct-01's ef295f69abbf that you originally referenced: 202= 3-Oct-04's 2464d8c5e296.) >=20 > # c++ -v > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git ll= vmorg-16.0.6-0-g7cbf1a259152) > Target: aarch64-unknown-freebsd13.2 > Thread model: posix > InstalledDir: /usr/bin >=20 > # c++ -std=3Dc++17 -pedantic -O2 monotonic_buffer_resource.cpp >=20 > # ./a.out > t1 (default std alloc): 1.827 sec; t1/t1: 1.000 > t2 (default pmr alloc): 1.818 sec; t1/t2: 1.005 > t3 (pmr alloc no buf): 0.920 sec; t1/t3: 1.986 > t4 (pmr alloc and buf): 0.606 sec; t1/t4: 3.015 >=20 > The example is from in an aarch64 context. It does not > agree with your report. >=20 > > I made no progress on this. >=20 >=20 > So far I've never reproduced your problem or anything like it. >=20 > (I prefer testing official builds for problem isolation. If > only my personal builds fail, then it is likely my build's > problem.) >=20 > > I have reinstalled world twice (from different > > commits) and I re-installed all packages multiple times (also from diff= erent > > ports tree commits). >=20 >=20 > I suggest trying the most recent stable/13 snapshot build at > the time of the experiment. >=20 > No packages are used/needed for the monotonic_buffer_resource.cpp > test. This fits well with using a snapshot context for such a > test. >=20 > > Any other wild ideas on how to fix this? >=20 >=20 > I've no evidence about your stable/13 build/install. But the > official snapshot that I tried worked just fine. >=20 > > None of my other machines have any > > issues whatsoever running on the same or similar stable/13 commit and u= sing > > the same poudriere repository. >=20 >=20 > That, with my results, tends to suggest you have one odd ball > context that has a problematical FreeBSD build/install. Again, > I've no evidence to work with relative to that build/install. >=20 > > This is certainly not Qt5 related. I run into the exact same issue with > > anything that uses Qt6. >=20 > > Furthermore, the test program we built experiences > > the same issue without any involvement of the Qt libraries. >=20 >=20 >=20 > There was no problem for my testing of monotonic_buffer_resource.cpp > via the recent official snapshot build of stable/13 . >=20 > I've not tried to test Qt5 or Qt6, sticking with the simpler/smaller > context that you also report as failing in the odd context. I suggest > avoiding Qt5/Qt6 testing until you have a context with the > monotonic_buffer_resource.cpp test working. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Tue Oct 10 18:40:58 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S4l933mwDz4x8Qr for ; Tue, 10 Oct 2023 18:41:11 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S4l931wrdz3MYs for ; Tue, 10 Oct 2023 18:41:11 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-4527d436ddfso2290681137.1 for ; Tue, 10 Oct 2023 11:41:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696963270; x=1697568070; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x5/qPzhZZl1pM/TFQG0vGVnafnoJQZCPS2TiKV6dsCM=; b=HmyBdu2hjDRAiwNUJ3ZKQmmelwxsQiOgPasxzsVL/sJIeI2DehFqHpzrPlXX8VaQsg jcy4y8kmdzvSUWburPXbTlEu4Ol0JDaox8gvsN97AfU1eQPLPS++mDHdv+NwvqMXWaqf sGItos6aYJY1eNKfM94UUhY7jVnSei4vHh8jQkDnPmQ7PMYG6Zw3kdnGwDW+ut5V/PRW wjrC5jFntF3zjLvctUNc3KeYuLQdZ7J65lK0aX7GOV4fK916tUU4wwqVYKor9ooTgo4G hX6BL0samMzWtG9IO5V3SEqQ+/Nfukmw6Dl9NzQJg/PKVEv6FaQ9Eu5O5QvH9i9NbVnx 6oMw== X-Gm-Message-State: AOJu0YxqAPBZ1brJQsj5iwgxJ9pkjylolkzAWXdlFmMb67qZNmoPGmMG iFFAhA4g755HJTz/dgRKUE0qi+42J4KzIQ89MeXLzXt1s0M= X-Google-Smtp-Source: AGHT+IGTsR1YIhHUllV1NTkfz7/HEPx7mlpOMZfUyQ6f5E8ML9yszHBuzGS7KvGF8SXc1VWXIzXLMV7zT/QXigRD2us= X-Received: by 2002:a67:f754:0:b0:452:7f81:1502 with SMTP id w20-20020a67f754000000b004527f811502mr16388016vso.26.1696963270093; Tue, 10 Oct 2023 11:41:10 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <4A3F045F-3379-4651-9099-3319E4C326EE.ref@yahoo.com> <4A3F045F-3379-4651-9099-3319E4C326EE@yahoo.com> In-Reply-To: From: Alan Somers Date: Tue, 10 Oct 2023 11:40:58 -0700 Message-ID: Subject: Re: Base libc++ missing symbol To: jbo@insane.engineer Cc: Mark Millard , "stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4S4l931wrdz3MYs BTW, this same problem is already in bugzilla at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272642 . I too am experiencing it, on a system that I upgraded with freebsd-update from 13.2-RELEASE to 14.0-BETA4. And I'm at a loss to understand what's going on, because elfdump -a /lib/libc++.so _does_ show that symbol as present. -Alan From nobody Tue Oct 10 22:10:09 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S4qpG70r4z4wPRx for ; Tue, 10 Oct 2023 22:10:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S4qpD2qzZz3gcP for ; Tue, 10 Oct 2023 22:10:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-80-101.area1b.commufa.jp [123.1.80.101]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 39AMA9mk067668 for ; Wed, 11 Oct 2023 07:10:09 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 11 Oct 2023 07:10:09 +0900 From: Tomoaki AOKI To: stable@freebsd.org Subject: Re: Base libc++ missing symbol Message-Id: <20231011071009.a9a8f67ea89ab07d7cb8403c@dec.sakura.ne.jp> In-Reply-To: References: <4A3F045F-3379-4651-9099-3319E4C326EE.ref@yahoo.com> <4A3F045F-3379-4651-9099-3319E4C326EE@yahoo.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.47 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.97)[-0.969]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4S4qpD2qzZz3gcP On Tue, 10 Oct 2023 18:09:04 +0000 jbo@insane.engineer wrote: > I've updated to commit c11f71789d7d8f741243c21add8d7c5f0ecea03e > and the problem is still present. > > > So far I've never reproduced your problem or anything like it. > > > > (I prefer testing official builds for problem isolation. If > > only my personal builds fail, then it is likely my build's > > problem.) > > Yeah, I couldn't reproduce this either. I have no clue what is > going on here. > > I'm honestly a bit lost on this one. I have not encountered > anything like this before. None of my other machines are > displaying this problem wile running on the same stable/13 > branch (and one machine even on the exact same commit). > > Current system info: > > # uname -apKU > FreeBSD beefy02 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256520-c11f71789d7d GENERIC amd64 amd64 1302508 1302508 > > # freebsd-version -kru > 13.2-STABLE > 13.2-STABLE > 13.2-STABLE > > # c++ --version > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) > Target: x86_64-unknown-freebsd13.2 > Thread model: posix > InstalledDir: /usr/bin > > ------- Original Message ------- > On Monday, October 9th, 2023 at 08:35, Mark Millard wrote: > > > > > > > > wrote on > > > > Date: Sun, 08 Oct 2023 18:13:16 UTC : > > > > > > The procedure of seeing if the a.out is produced without complaint > > > > might still be useful. > > > > > > The program compiles & links fine, but then also fails to run: > > > > > > ld-elf.so.1: Undefined symbol "_ZTVNSt3__13pmr25monotonic_buffer_resourceE" referenced from COPY relocation in /usr/home/jbo/junk/a.out > > > > > > Well, for stable/13 's recent snapshot, freshly dd'd to USB3 media, > > so an official build, not a personal one that might be odd in some way: > > > > # uname -apKU > > FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256505-2464d8c5e296 GENERIC arm64 aarch64 1302508 1302508 > > > > (So, after 2023-Oct-01's ef295f69abbf that you originally referenced: 2023-Oct-04's 2464d8c5e296.) > > > > # c++ -v > > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) > > Target: aarch64-unknown-freebsd13.2 > > Thread model: posix > > InstalledDir: /usr/bin > > > > # c++ -std=c++17 -pedantic -O2 monotonic_buffer_resource.cpp > > > > # ./a.out > > t1 (default std alloc): 1.827 sec; t1/t1: 1.000 > > t2 (default pmr alloc): 1.818 sec; t1/t2: 1.005 > > t3 (pmr alloc no buf): 0.920 sec; t1/t3: 1.986 > > t4 (pmr alloc and buf): 0.606 sec; t1/t4: 3.015 > > > > The example is from in an aarch64 context. It does not > > agree with your report. > > > > > I made no progress on this. > > > > > > So far I've never reproduced your problem or anything like it. > > > > (I prefer testing official builds for problem isolation. If > > only my personal builds fail, then it is likely my build's > > problem.) > > > > > I have reinstalled world twice (from different > > > commits) and I re-installed all packages multiple times (also from different > > > ports tree commits). > > > > > > I suggest trying the most recent stable/13 snapshot build at > > the time of the experiment. > > > > No packages are used/needed for the monotonic_buffer_resource.cpp > > test. This fits well with using a snapshot context for such a > > test. > > > > > Any other wild ideas on how to fix this? > > > > > > I've no evidence about your stable/13 build/install. But the > > official snapshot that I tried worked just fine. > > > > > None of my other machines have any > > > issues whatsoever running on the same or similar stable/13 commit and using > > > the same poudriere repository. > > > > > > That, with my results, tends to suggest you have one odd ball > > context that has a problematical FreeBSD build/install. Again, > > I've no evidence to work with relative to that build/install. > > > > > This is certainly not Qt5 related. I run into the exact same issue with > > > anything that uses Qt6. > > > > > Furthermore, the test program we built experiences > > > the same issue without any involvement of the Qt libraries. > > > > > > > > There was no problem for my testing of monotonic_buffer_resource.cpp > > via the recent official snapshot build of stable/13 . > > > > I've not tried to test Qt5 or Qt6, sticking with the simpler/smaller > > context that you also report as failing in the odd context. I suggest > > avoiding Qt5/Qt6 testing until you have a context with the > > monotonic_buffer_resource.cpp test working. > > > > === > > Mark Millard > > marklmi at yahoo.com Hi. Do you have anything left under /usr/local/lib/compat/pkg? If any, what happenes if you move the contents to any place outside libraries are searched? For example, # mkdir /usr/local/00preserve ; mv /usr/local/lib/compat/pkg /usr/local/00preserve \ && mkdir /usr/local/lib/compat/pkg as root. I don't recommend deleting them unless confirming the above is safe. Doing so, you can restore them once it does any harm. Regards. -- Tomoaki AOKI From nobody Wed Oct 11 01:53:00 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S4wlZ02tGz4wgGN for ; Wed, 11 Oct 2023 01:53:14 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S4wlY4k7sz4ZSd for ; Wed, 11 Oct 2023 01:53:13 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f45.google.com with SMTP id ada2fe7eead31-45271a44cc4so2450767137.2 for ; Tue, 10 Oct 2023 18:53:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696989192; x=1697593992; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4XE1IEIA3BOJkMdxYEb2pFWsu2kwY2FWASf7gbI6hYo=; b=w+FxS3cZfKYJCTLwBfO9RRD3g/RzNejwhd1acw6LtrHKCMb2ExdLQ7qqkvdiwnSsCe R4RAzO/DC1tYxGAYKf7SdDUQCBuCAjv4GjyAr7gCAAyyiaX7i0fOsbQuSElroN5tRgi6 +izryHmeXIxMXuK8vF/zlIDHpYq8IHX6o3cSc2c+raZmwDoM8zEliHaagD1DDaCjjygY rDdgSFbvQn764lvF3l45tLuvDWzeO3bApwe8HqiFjgkxUIj86izxBH1ly+qbJxVNPCEz 83vngDJF9jacFuro/IXcZykuJshLFWHoOU1bCYpohmJxYPlQEwFAe9LW9zLrvJnDq9J0 Vo4w== X-Gm-Message-State: AOJu0Yx63Y+I9HZ4bCV6yTxiWWAg7ZC3eGSoBh8jIw4Ps3Fkl6PTFqdG Uc7G1TNPMGeC/wUEmufezFSzFPGG730YijzhFeLG1slWlng= X-Google-Smtp-Source: AGHT+IHkLqxyaXUQ7yQxOmWCmFMUbxKJol6h+ZZipnpRg0daadRKZiQPg+VSxoNWIs8SlNbfBNfzNe3aCnBxHbAwUSI= X-Received: by 2002:a05:6102:1593:b0:457:71af:ff09 with SMTP id g19-20020a056102159300b0045771afff09mr8803782vsv.26.1696989192256; Tue, 10 Oct 2023 18:53:12 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <4A3F045F-3379-4651-9099-3319E4C326EE.ref@yahoo.com> <4A3F045F-3379-4651-9099-3319E4C326EE@yahoo.com> <20231011071009.a9a8f67ea89ab07d7cb8403c@dec.sakura.ne.jp> In-Reply-To: <20231011071009.a9a8f67ea89ab07d7cb8403c@dec.sakura.ne.jp> From: Alan Somers Date: Tue, 10 Oct 2023 18:53:00 -0700 Message-ID: Subject: Re: Base libc++ missing symbol To: Tomoaki AOKI Cc: stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4S4wlY4k7sz4ZSd On Tue, Oct 10, 2023 at 3:10=E2=80=AFPM Tomoaki AOKI wrote: > > On Tue, 10 Oct 2023 18:09:04 +0000 > jbo@insane.engineer wrote: > > > I've updated to commit c11f71789d7d8f741243c21add8d7c5f0ecea03e > > and the problem is still present. > > > > > So far I've never reproduced your problem or anything like it. > > > > > > (I prefer testing official builds for problem isolation. If > > > only my personal builds fail, then it is likely my build's > > > problem.) > > > > Yeah, I couldn't reproduce this either. I have no clue what is > > going on here. > > > > I'm honestly a bit lost on this one. I have not encountered > > anything like this before. None of my other machines are > > displaying this problem wile running on the same stable/13 > > branch (and one machine even on the exact same commit). > > > > Current system info: > > > > # uname -apKU > > FreeBSD beefy02 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256520-c11f7= 1789d7d GENERIC amd64 amd64 1302508 1302508 > > > > # freebsd-version -kru > > 13.2-STABLE > > 13.2-STABLE > > 13.2-STABLE > > > > # c++ --version > > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git = llvmorg-16.0.6-0-g7cbf1a259152) > > Target: x86_64-unknown-freebsd13.2 > > Thread model: posix > > InstalledDir: /usr/bin > > > > ------- Original Message ------- > > On Monday, October 9th, 2023 at 08:35, Mark Millard = wrote: > > > > > > > > > > > > > wrote on > > > > > > Date: Sun, 08 Oct 2023 18:13:16 UTC : > > > > > > > > The procedure of seeing if the a.out is produced without complain= t > > > > > might still be useful. > > > > > > > > The program compiles & links fine, but then also fails to run: > > > > > > > > ld-elf.so.1: Undefined symbol "_ZTVNSt3__13pmr25monotonic_buffer_re= sourceE" referenced from COPY relocation in /usr/home/jbo/junk/a.out > > > > > > > > > Well, for stable/13 's recent snapshot, freshly dd'd to USB3 media, > > > so an official build, not a personal one that might be odd in some wa= y: > > > > > > # uname -apKU > > > FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256505-246= 4d8c5e296 GENERIC arm64 aarch64 1302508 1302508 > > > > > > (So, after 2023-Oct-01's ef295f69abbf that you originally referenced:= 2023-Oct-04's 2464d8c5e296.) > > > > > > # c++ -v > > > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.gi= t llvmorg-16.0.6-0-g7cbf1a259152) > > > Target: aarch64-unknown-freebsd13.2 > > > Thread model: posix > > > InstalledDir: /usr/bin > > > > > > # c++ -std=3Dc++17 -pedantic -O2 monotonic_buffer_resource.cpp > > > > > > # ./a.out > > > t1 (default std alloc): 1.827 sec; t1/t1: 1.000 > > > t2 (default pmr alloc): 1.818 sec; t1/t2: 1.005 > > > t3 (pmr alloc no buf): 0.920 sec; t1/t3: 1.986 > > > t4 (pmr alloc and buf): 0.606 sec; t1/t4: 3.015 > > > > > > The example is from in an aarch64 context. It does not > > > agree with your report. > > > > > > > I made no progress on this. > > > > > > > > > So far I've never reproduced your problem or anything like it. > > > > > > (I prefer testing official builds for problem isolation. If > > > only my personal builds fail, then it is likely my build's > > > problem.) > > > > > > > I have reinstalled world twice (from different > > > > commits) and I re-installed all packages multiple times (also from = different > > > > ports tree commits). > > > > > > > > > I suggest trying the most recent stable/13 snapshot build at > > > the time of the experiment. > > > > > > No packages are used/needed for the monotonic_buffer_resource.cpp > > > test. This fits well with using a snapshot context for such a > > > test. > > > > > > > Any other wild ideas on how to fix this? > > > > > > > > > I've no evidence about your stable/13 build/install. But the > > > official snapshot that I tried worked just fine. > > > > > > > None of my other machines have any > > > > issues whatsoever running on the same or similar stable/13 commit a= nd using > > > > the same poudriere repository. > > > > > > > > > That, with my results, tends to suggest you have one odd ball > > > context that has a problematical FreeBSD build/install. Again, > > > I've no evidence to work with relative to that build/install. > > > > > > > This is certainly not Qt5 related. I run into the exact same issue = with > > > > anything that uses Qt6. > > > > > > > Furthermore, the test program we built experiences > > > > the same issue without any involvement of the Qt libraries. > > > > > > > > > > > > There was no problem for my testing of monotonic_buffer_resource.cpp > > > via the recent official snapshot build of stable/13 . > > > > > > I've not tried to test Qt5 or Qt6, sticking with the simpler/smaller > > > context that you also report as failing in the odd context. I suggest > > > avoiding Qt5/Qt6 testing until you have a context with the > > > monotonic_buffer_resource.cpp test working. > > > > > > =3D=3D=3D > > > Mark Millard > > > marklmi at yahoo.com > > Hi. > > Do you have anything left under /usr/local/lib/compat/pkg? No, that directory is empty. From nobody Wed Oct 11 02:40:46 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S4xpp6zsrz4wjpC for ; Wed, 11 Oct 2023 02:41:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S4xpp46fLz4fYb; Wed, 11 Oct 2023 02:41:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 39B2ekjH004653 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 11 Oct 2023 05:40:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 39B2ekjH004653 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 39B2ekG7004652; Wed, 11 Oct 2023 05:40:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Oct 2023 05:40:46 +0300 From: Konstantin Belousov To: Alan Somers Cc: Tomoaki AOKI , stable@freebsd.org Subject: Re: Base libc++ missing symbol Message-ID: References: <4A3F045F-3379-4651-9099-3319E4C326EE.ref@yahoo.com> <4A3F045F-3379-4651-9099-3319E4C326EE@yahoo.com> <20231011071009.a9a8f67ea89ab07d7cb8403c@dec.sakura.ne.jp> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4S4xpp46fLz4fYb On Tue, Oct 10, 2023 at 06:53:00PM -0700, Alan Somers wrote: > On Tue, Oct 10, 2023 at 3:10 PM Tomoaki AOKI wrote: > > > > On Tue, 10 Oct 2023 18:09:04 +0000 > > jbo@insane.engineer wrote: > > > > > I've updated to commit c11f71789d7d8f741243c21add8d7c5f0ecea03e > > > and the problem is still present. > > > > > > > So far I've never reproduced your problem or anything like it. > > > > > > > > (I prefer testing official builds for problem isolation. If > > > > only my personal builds fail, then it is likely my build's > > > > problem.) > > > > > > Yeah, I couldn't reproduce this either. I have no clue what is > > > going on here. > > > > > > I'm honestly a bit lost on this one. I have not encountered > > > anything like this before. None of my other machines are > > > displaying this problem wile running on the same stable/13 > > > branch (and one machine even on the exact same commit). > > > > > > Current system info: > > > > > > # uname -apKU > > > FreeBSD beefy02 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256520-c11f71789d7d GENERIC amd64 amd64 1302508 1302508 > > > > > > # freebsd-version -kru > > > 13.2-STABLE > > > 13.2-STABLE > > > 13.2-STABLE > > > > > > # c++ --version > > > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) > > > Target: x86_64-unknown-freebsd13.2 > > > Thread model: posix > > > InstalledDir: /usr/bin > > > > > > ------- Original Message ------- > > > On Monday, October 9th, 2023 at 08:35, Mark Millard wrote: > > > > > > > > > > > > > > > > > > wrote on > > > > > > > > Date: Sun, 08 Oct 2023 18:13:16 UTC : > > > > > > > > > > The procedure of seeing if the a.out is produced without complaint > > > > > > might still be useful. > > > > > > > > > > The program compiles & links fine, but then also fails to run: > > > > > > > > > > ld-elf.so.1: Undefined symbol "_ZTVNSt3__13pmr25monotonic_buffer_resourceE" referenced from COPY relocation in /usr/home/jbo/junk/a.out > > > > > > > > > > > > Well, for stable/13 's recent snapshot, freshly dd'd to USB3 media, > > > > so an official build, not a personal one that might be odd in some way: > > > > > > > > # uname -apKU > > > > FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256505-2464d8c5e296 GENERIC arm64 aarch64 1302508 1302508 > > > > > > > > (So, after 2023-Oct-01's ef295f69abbf that you originally referenced: 2023-Oct-04's 2464d8c5e296.) > > > > > > > > # c++ -v > > > > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) > > > > Target: aarch64-unknown-freebsd13.2 > > > > Thread model: posix > > > > InstalledDir: /usr/bin > > > > > > > > # c++ -std=c++17 -pedantic -O2 monotonic_buffer_resource.cpp > > > > > > > > # ./a.out > > > > t1 (default std alloc): 1.827 sec; t1/t1: 1.000 > > > > t2 (default pmr alloc): 1.818 sec; t1/t2: 1.005 > > > > t3 (pmr alloc no buf): 0.920 sec; t1/t3: 1.986 > > > > t4 (pmr alloc and buf): 0.606 sec; t1/t4: 3.015 > > > > > > > > The example is from in an aarch64 context. It does not > > > > agree with your report. > > > > > > > > > I made no progress on this. > > > > > > > > > > > > So far I've never reproduced your problem or anything like it. > > > > > > > > (I prefer testing official builds for problem isolation. If > > > > only my personal builds fail, then it is likely my build's > > > > problem.) > > > > > > > > > I have reinstalled world twice (from different > > > > > commits) and I re-installed all packages multiple times (also from different > > > > > ports tree commits). > > > > > > > > > > > > I suggest trying the most recent stable/13 snapshot build at > > > > the time of the experiment. > > > > > > > > No packages are used/needed for the monotonic_buffer_resource.cpp > > > > test. This fits well with using a snapshot context for such a > > > > test. > > > > > > > > > Any other wild ideas on how to fix this? > > > > > > > > > > > > I've no evidence about your stable/13 build/install. But the > > > > official snapshot that I tried worked just fine. > > > > > > > > > None of my other machines have any > > > > > issues whatsoever running on the same or similar stable/13 commit and using > > > > > the same poudriere repository. > > > > > > > > > > > > That, with my results, tends to suggest you have one odd ball > > > > context that has a problematical FreeBSD build/install. Again, > > > > I've no evidence to work with relative to that build/install. > > > > > > > > > This is certainly not Qt5 related. I run into the exact same issue with > > > > > anything that uses Qt6. > > > > > > > > > Furthermore, the test program we built experiences > > > > > the same issue without any involvement of the Qt libraries. > > > > > > > > > > > > > > > > There was no problem for my testing of monotonic_buffer_resource.cpp > > > > via the recent official snapshot build of stable/13 . > > > > > > > > I've not tried to test Qt5 or Qt6, sticking with the simpler/smaller > > > > context that you also report as failing in the odd context. I suggest > > > > avoiding Qt5/Qt6 testing until you have a context with the > > > > monotonic_buffer_resource.cpp test working. > > > > > > > > === > > > > Mark Millard > > > > marklmi at yahoo.com > > > > Hi. > > > > Do you have anything left under /usr/local/lib/compat/pkg? > > No, that directory is empty. Try to use ldd or gdb to see which actual library was loaded. It might be that something else, not /usr/lib/libc++.so.1, was loaded. Or actually worse, both /usr/lib/libc++so.1 and something else, together. From nobody Wed Oct 11 18:26:11 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S5Lnb2YFxz4wW3S for ; Wed, 11 Oct 2023 18:26:27 +0000 (UTC) (envelope-from coruscant0@gmail.com) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S5LnZ1gKHz4ThY for ; Wed, 11 Oct 2023 18:26:26 +0000 (UTC) (envelope-from coruscant0@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=MzBJXes1; spf=pass (mx1.freebsd.org: domain of coruscant0@gmail.com designates 2607:f8b0:4864:20::52e as permitted sender) smtp.mailfrom=coruscant0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-5a1d91a2540so84934a12.1 for ; Wed, 11 Oct 2023 11:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697048783; x=1697653583; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=vmvrKvHGP8yobeK+Bi8H6nkw8kQ5j22UWfx1HecdZU0=; b=MzBJXes1QdI5GDw8GTOhgeLNeHSwog3kKuFEk3Az4k6XVAucoPngbHD+E60VxSIA44 SQxRmJ1eFZGpABGi2+Kxi1L1LKszPCN09QgjWa1kCPnMDlxp1sLxd17Do9dQAEgKklNk 81D/ZOO686/02kmr543+nBG/THO0PTsxSWTddI9AmZIs1507o+/UQjW+mkIcYYLQRHye NnL5Y/MsWQe4zQ5hkLabYmz3i4j99C4yReEe2R8VOPb6nYWxbNbi5OY+tG7oi82wIah1 UA2OGvbRsOPpQNvd7kwNvuxVKHUKo5hNBYzlavU66xhumW5/3NSuFR16imB4/kRJsBk1 WUSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697048783; x=1697653583; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vmvrKvHGP8yobeK+Bi8H6nkw8kQ5j22UWfx1HecdZU0=; b=EubhKdgWq/PRBr0eAuWY2dhGu/lxaFGXeFMfSk3eq7pApg8SAl4BntyP8ToxGlwAJq odUvFh3kv9dx+6x4mR30u+Etn0lv7RaIc1OWlYjIFMqxPYpbFi+D/i957AnMNq+c8lZZ zAzDLoKgY/O19rUIZJUJf5sqi+GVp7Ry8UABkOysO6k20od2+rz3g+136EdL/sH8Nkom dykQa7h6mXAtubbRQRjvFFPfiKat/PK5IGGYItRJS/353l7QM9u0PgdmEFmsK5flaSRl grxv7W1+Ng6GK/7DN4Df3LLs5Nus5+ZfKb29KWm8IdnUxzIixowEbuYyK/p37CwlcMGR uuVg== X-Gm-Message-State: AOJu0YyCKiv+107hoeMV/yd0MsZgCsKh4PnLrXFjooX2IGTc678x7xNn IA/cYAQZjTfMIJckBFqPYOMdr+lSCXTJUqt3LK2aLVlX X-Google-Smtp-Source: AGHT+IHA+IVrMEUjYrFaINWy7yFUw/8jjLhoMlqZ+DDgLF4KLb164UojdtLX/7uiHYya/DLMO/0dPDz33avjL7A8rk4= X-Received: by 2002:a17:902:d50c:b0:1bb:94ed:20a with SMTP id b12-20020a170902d50c00b001bb94ed020amr23774503plg.24.1697048783407; Wed, 11 Oct 2023 11:26:23 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <20231006224150.GF1307@FreeBSD.org> In-Reply-To: From: =?UTF-8?B?R3nDtnJneSBQw6FzenRvcg==?= Date: Wed, 11 Oct 2023 18:26:11 +0000 Message-ID: Subject: Fwd: FreeBSD 14.0-BETA5 Now Available To: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e6ccdf060774f539" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.71 / 15.00]; R_MIXED_CHARSET(1.11)[subject]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.82)[-0.820]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::52e:server fail]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[fbsd]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52e:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org] X-Rspamd-Queue-Id: 4S5LnZ1gKHz4ThY --000000000000e6ccdf060774f539 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Glen, The new betas broke the functionality to boot from ventoy. Earlier 13.X releases were able to boot no matter if I copied the disc1.iso or the memstick.img to the ISO directory of a ventoy thumb drive. I've tested both the disc1.iso and the memstick.img for beta4, and the disc1.iso with beta5. None of them was working. Boot stops at the point, when it tries to mount the root filesystem. I'm not sure what kind of (uefi?) trick ventoy uses to emulate the image from the pendrive's filesystem towards the booted os. But it was working with the previous BSD installers. With 14.0 it's not working anymore. Can you look after that? I guess, I'm not the only one, who rather have one pendrive with a handful of installer images, than having 10 different pendrive with the 10 different image wasted on the first 1-2 gb of the drive, than leaving the rest of the drive unused. Thanks, gyu Glen Barber ezt =C3=ADrta (id=C5=91pont: 2023. okt. 6., P= , 22:42): > The fifth BETA build of the 14.0-RELEASE release cycle is now available. > > --000000000000e6ccdf060774f539 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Glen,<= /div>

The new betas broke the functionality to boot from= ventoy.
Earlier 13.X releases were able to boot no matter if I c= opied the disc1.iso or the memstick.img to the ISO directory of a ventoy th= umb drive.
I've tested both the disc1.iso and the memstick.im= g for beta4, and the disc1.iso with beta5. None of them was working.
<= div>Boot stops at the point, when it tries to mount the root filesystem.
I'm not sure what kind of (uefi?) trick ventoy uses to emulate = the image from the pendrive's filesystem towards the booted os.
But it was working with the previous BSD installers.
With 14.0= it's not working anymore.
Can you look after that? I guess, = I'm not the only one, who rather have one pendrive with a handful of in= staller images, than having 10 different pendrive with the 10 different ima= ge wasted on the first 1-2 gb of the drive, than leaving the rest of the dr= ive unused.

Thanks,
gyu
<= br>
Glen Ba= rber <gjb@freebsd.o= rg> ezt =C3=ADrta (id=C5=91pont: 2023. okt. 6., P, 22:42):
=
The fifth BETA build of t= he 14.0-RELEASE release cycle is now available.

--000000000000e6ccdf060774f539-- From nobody Fri Oct 13 05:57:49 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S6G582Lp8z4wWQb for ; Fri, 13 Oct 2023 05:58:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S6G57247Dz3TmL for ; Fri, 13 Oct 2023 05:58:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PRLhzMLS; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697176681; bh=ziHDvooUrvUH2UNwUukGtkpVl0GdtDEPv3UvQOnYVqQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=PRLhzMLSel1C87kQaILBhd8LSTNU/UEJ2KEPCqj69fNXDkEBNDFHExqLarF7UFVZqS7T84aQTqlM0LA8XAktRk6fDljVFV9hIQ0Hk6FqPLmGej5w8jSwLFrYVXwDn3m1L0WCF5i5F4J41OMKTkTKrBKQjjbapP+1Gt+WcSdmyPo6wf6+nVKVi/Av9Z1q7bsdzO2ON4BIHL4YXP5SBqxuV+Ne9nOgliE4/Oa8LUkyI+4PjUi0UFugnBZWsc8qRgpXQrCQFUY9A0iGlQ+CdJQGqaLs+E58zKxV/ntMCzv85zxLOp2uMDf2csx32cAoTYiU7t1hrMsOwkF9t97sPR8kvA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697176681; bh=aOB6Usv+1oH9BrfOXZLGJN6rybGqmY83vo316w5luKT=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=CZY2HhXuC0kT2gUd10AjscLzgng+BJdZLLfrS9prkSxqz7n4JGEPyRXsmBpmGT15X80XFwxcsAM6jirKvpSCyuCjcVDr8rtRv2jWitMv8JXD7q9fsQGM39EQy4PCKxQ0qLUQhuAFWk/UzrZE25Vz95pX18q6yO21g8BDMJm3NrA+LZ6xs24CSNlmbTgR3rVk3qPteBrGMvJ7JD+Pety/CjDFDpM35FRoWqKmIYRiW843QhodY5nnKHuOt7XlXGxCcFggckFbzIIQ32wR/87Gs8+tuTDRSsQ+Fhc6NmwsolK50vT9mgQIlNxWe3SncLK0R0DUKzGBv5OEBX2BZFdpcw== X-YMail-OSG: zw0oX4AVM1nYDmJHAAdMoPyzt74TsY_HwXZ8LiyFyuq0YAFBM.AB7eIHqiBkmH. od6S1gUxIf3SNk41aNgMgc4WKg4DCZlMtmsvg3GMUAFYOv8lYSTgdh50ovMzupi4kfSqr4.hgNDb g3iqqb6zb5fo1YQ2.UIdcKkwWvOkIE0OzfZmUgLshNcS7IgPBV0dSTWduCO8w7j65VTBM1_GBNOR 7m_2k5Bx3BsjPsOsb_jCIcbgE4tsVCAHJ6SyUaTgz8COjQn6YIi9mXctmVtZrSxFfEqf2DHOVIiU eGKzz311xS718ILagUMALJitvvEllJ2Oa6qFbXWaJRp9z2w0I1Z599QiIlV8uoOh8qNFSdZLIj2. G9u3YOFQswryPZ0NgmKj1lX.lPbH3viAHI0NkjT53KV2aOPbRvf02Ja50CRJLlS6DNGTkvaXyOeV 1t2wpObXHAYKd61vTGNjTJ4CRz6rOQkomP9.4WOzOGWhpew8rZBaVeZyYHo9l4IoBe89BLkI8i3g s9NCuMJU_1xjG2p4as.2pFG4haQqyKMJds0tSfN4USu4fDCPDlqogH.XVzeifybCHywdoFhVG12x dySvYy.G9IUkmVvHqdWmdnTJlQc5a0GmQlP2tuHmN.N75.UZ1ehwHLmQNKZdaHF_A0AFNKMiM3PD iHNy3LDbJ7x7L8ZyTaTlUfnj8KZMq0A6ya0PkNhz51P8w89_P3wEhMFZmqesCf0OgMmmkXNdtIh8 i6eB8f8Ek2DSlHRshvil6E.0i8da15PK0g7qhA1Ry5LBMfnJqKS_F0glrY.rZMHsI4NPIBdRmUGy UtqwPXWHjwr1z2pi9tGWZ3rt4PbWr3Uhr855qpyLo7piHRIwDOOcBbDB65zVwTHBM.z.o0tIYjhL DPPcasY2C1vI2Elf5kB2e231tSrDmzemw7NSRsxaj56J3l4C1HjA2tB4KpINfEnPJOvDtaY6Xdkf 9Q1YEXHqHDPORVc8jWdl5HO2NwtBMuqjXzNDVW3.1sDlu0KGdgZXK.kD9FYR99SgZGUn8CrVFXSF _Rxu3kfqZ5_vKp8hnem7qTPQIBFROKOY8.B2vFGdbheI7hhDxn9ueYKY.KQaO3LtuFvJn1Um7loE 1NupTQW6vE6662HBQVQte2k.0EsL_cGhCj5I9CC.fPjogWi4BJw9q92Ky9x9Domj_Z1Nc5tquI0c nek9gFKoQLedxjR.RaP3eVfJJNKh15xsKg48DshqJT.S9mn8B..YDu3FYz_tZpkU0inV9s5HURto AZVjY3hWLZDOfvnmO.t_64Ni6dIgaIIRckrHyPvpiS2PmtCYYZdr0g5gFvaSozrqjx2aDNm2BAlK 7wMcTBlSq37fAh3bUJLqCtfCLBaRC6YIlCuHxJo1rMkSg3jSHfP0xwCm.2NczIDefc.9lIfregws K0wNDgYbVhzmfGDDKXd.xBV2GoVtP101qBBvCutK5vq8WFSYaYsVUAnQRDFALuTiaYkia8fv.s7V tlcHmux85r6HxEw4BYS8f6UhjaR4KC_qGgy5prbIcFRZfUUjbZ6m_n20wZILzvONc2fH8wWRKbWY uhR0HHBRk21v_7QCHw1ij5DfRFcbi6gWoIMXDTx4UMOaS4bR5Ww6CdHsRI4KuG5VtPdPz05V15_Q dxwQRprvazCOsdESxmsToJA.RtToLEyrJWN3jq5kAcowfYD..OuTXg0ew0yRETGM4ABTxkY7zcag dI2nXOhBInq2VMCb2n936F52VEgFX8f4f6PCnPPzyIiQkqDPkf8891I8GMMCwcKTOiMSPUzZ2uDP TiuumQChaLyMtDz_WWTMPlrj1MXtiwre2Se8Q6P4Z4b1rUfK7D5O1NJZJozb4dKKL.XSTcYstsGT ibBS62KXTA8qFfPqxyFO7golgJhWNHOwXUEuI5IiCffyNCYiCS_NxiXDB4AtQZqCWakLLjiCQRej CcZX_9jU_bc8oXd9sMZ498hNx2uVfgPfk1UpQ4luVnAhO3RsLI1UwlMhDtZ_TvGhMwynemLJKaoE H7G6B3.wDuYBBPHIQ2D2SlL3PtStX51mdsIO0XwHbmQLx3yaf5vZh4_ze4oHX9KD9STImdjRupxp JAM7Hj2JqNrbdLWzLWvap29uHPfy2CRIAPpYOjAkDGYVf8V92hc9fVIILfSiiA_EJvdaLoQUdGBd D.f9gNzeDcVvF9.ezEK9KRiQaQrbOXxUkdVPc2v0eWeIeIoidRqtWKxjij1jNXtvd6ZAhvNKhd0q xD8Btg.KMgm6eprUmxQr_S9X0wbucEETJRDwh1NiJf8N3fDAPpCJIDiz3xXuzVqY0rKDHRhRINTc - X-Sonic-MF: X-Sonic-ID: bb143365-7469-48cf-8047-8f1698386f94 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 13 Oct 2023 05:58:01 +0000 Received: by hermes--production-gq1-59f5fd4df5-qpmv2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f80fa530f1a6d17d66c4c922a0233c77; Fri, 13 Oct 2023 05:58:00 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: RE: git: d2025992ab68 - releng/14.0 - release: update releng/14.0 from BETA to RC Message-Id: <9C561955-AE05-4441-923A-6AE03FC3F6A8@yahoo.com> Date: Thu, 12 Oct 2023 22:57:49 -0700 To: Glen Barber , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3774.100.2.1.4) References: <9C561955-AE05-4441-923A-6AE03FC3F6A8.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4S6G57247Dz3TmL Glen Barber wrote on Date: Fri, 13 Oct 2023 00:00:10 UTC : > The branch releng/14.0 has been updated by gjb: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3Dd2025992ab6852d2a9ace62006e3a3ff= a067364b >=20 > commit d2025992ab6852d2a9ace62006e3a3ffa067364b > Author: Glen Barber > AuthorDate: 2023-10-12 23:55:33 +0000 > Commit: Glen Barber > CommitDate: 2023-10-12 23:55:33 +0000 >=20 > release: update releng/14.0 from BETA to RC I'll note that today's: https://github.com/openzfs/zfs/commit/2bba9fd479f5 is another openzfs data corruption fix, this time involving TRIMs vs. metaslab allocations. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Oct 13 07:14:55 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S6Hnv05stz4wbv4 for ; Fri, 13 Oct 2023 07:14:59 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from www541.your-server.de (www541.your-server.de [213.133.107.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4S6Hnt0gNhz3fhW; Fri, 13 Oct 2023 07:14:58 +0000 (UTC) (envelope-from mm@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 213.133.107.7 is neither permitted nor denied by domain of mm@FreeBSD.org) smtp.mailfrom=mm@FreeBSD.org; dmarc=none Received: from sslproxy06.your-server.de ([78.46.172.3]) by www541.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qrCNs-0008MH-T5; Fri, 13 Oct 2023 09:14:56 +0200 Received: from [188.167.171.2] (helo=[10.0.9.122]) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qrCNs-0008TA-4N; Fri, 13 Oct 2023 09:14:56 +0200 Message-ID: Date: Fri, 13 Oct 2023 09:14:55 +0200 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Martin Matuska Subject: Re: git: d2025992ab68 - releng/14.0 - release: update releng/14.0 from BETA to RC To: Glen Barber , FreeBSD-STABLE Mailing List References: <9C561955-AE05-4441-923A-6AE03FC3F6A8.ref@yahoo.com> Content-Language: en-US In-Reply-To: <9C561955-AE05-4441-923A-6AE03FC3F6A8.ref@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: martin@matuska.de X-Virus-Scanned: Clear (ClamAV 0.103.10/27059/Thu Oct 12 09:41:08 2023) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.08 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:213.133.96.0/19, country:DE]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FREEFALL_USER(0.00)[mm]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; HAS_X_AS(0.00)[] X-Rspamd-Queue-Id: 4S6Hnt0gNhz3fhW I am merging openzfs/master to main and zfs-2.2-release to stable/14 asap Glen Barber wrote on Date: Fri, 13 Oct 2023 00:00:10 UTC : > The branch releng/14.0 has been updated by gjb: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=d2025992ab6852d2a9ace62006e3a3ffa067364b > > commit d2025992ab6852d2a9ace62006e3a3ffa067364b > Author: Glen Barber > AuthorDate: 2023-10-12 23:55:33 +0000 > Commit: Glen Barber > CommitDate: 2023-10-12 23:55:33 +0000 > > release: update releng/14.0 from BETA to RC I'll note that today's: https://github.com/openzfs/zfs/commit/2bba9fd479f5 is another openzfs data corruption fix, this time involving TRIMs vs. metaslab allocations. === Mark Millard marklmi at yahoo.com