From nobody Sun Jan 22 04:41:42 2023 X-Original-To: freebsd-current@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 4P00vB5kbxz2t3f7 for ; Sun, 22 Jan 2023 04:41:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4P00v95DwLz45V0 for ; Sun, 22 Jan 2023 04:41:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NweIPp+j; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 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=1674362515; bh=LXmgXHXAtKaQCCe2p/fbM4sntyZ1xC2xuCLWnc7pMyo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=NweIPp+jWxvtKqjXCXqLmS5mPwkH49sKAEpDBuzjUwI8816U/JNo7AlPi0Ybbwlk0X1Z5oIjnPgCNwGTZ/fxr++ymnYRBM3RD5U/wlSzNUU+U+AKYXNp03n1YiImJ2iAUy1CuBn2Ac9e+xEN6vVT7SS0Cs3w4fFj1kUnUGNy1QILd7RtdfNT/jTfIdmZAsPRN+28dDP8k2ELfSGOjLgk6VXgl9A4KuS3Ps7Ju8FPRYGwEc8/MPE8AnkChajxbPMqcC9RVtQzvn+RqM8b8S5qYpnqFacADTq70fnnw+2NzbAKkbKBHC1wW1TT+6fTIJcF83s8K6DrUk+tSYSiM93fJQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674362515; bh=SNGahnckMm/cN1CnVzb2OZMOmpfFIJ5A7IemFwT5las=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=mJDaaBgG5VN2HHjsFioxKDd7YHtL+YvcgDJ9YOfHhaytd2DVWM7F3M0+3A4k4lJpq/uSlW1vvAN2PgDWLwzpXkfITuvNbLCbUcr0yvqzoIlx5CZnfJoBVpIYMp6lXdy78CxhorDE1DQNegbCQezVRAl9Z95t6gIETaYtUMmsgKFD77wLPHJkt4TW4K17sijQlGuqo6FxohgT+4oor6F1A/QnhsBgpJJYNbl4r0ruQ9tlPLSApIqln7YTfwQJxneSrGLWfqqTwWuR4fcN/F2Vx4YFJA7QhtJhdUsQr9bem6nZFFal0lSXZ8utbULrpXwNIEBACNWg5VKOZM/z11S0zA== X-YMail-OSG: fktGGhUVM1ll04fqFN4864RVhwCn9qPFhCIH98Met.6Myc7rxWqy1MoF8WZkrS_ 5GB2Mr..n_aywMwtietCz_jMjFQZkr.2pSzrA8uYZzZGpbiEpog4p7cpVtcgodrFgc.4g8Hl2Nh9 s7vC1w914nx8tsJdDNCtqTQXlLX82n57PtnC1vnzMly06i1OdfU0bsieV79woaZtmxosYA74BJS8 YSROdvKUgo6rOwwL5F_FKjrY9mjGIvejfEmZIkzR0gI70.kPeM4fNofgOXixFTQQHHp9gobqOtpS TZLFLeAqRX6ZiJOv0n7oj2MaBPu9kD6g42L9MCThZ.aIscuELW2aDTfvG8RPz4hgSMjeRLnQR7z9 Rp_2Qk3FPHirH1ZBIPIgiQG_skukz1tstIiGtHPkXR_umRK5WGUylKmaNDPBHYR8yOkBJ6ZKET7c pkfZgK3wPVlZMkvuHK5kPmDJp8ZVbohqlBONMcjJxiQOFRlF6enO_HkHJnKmX6Fe7.tb8yt8To4K 1I73d4Ug2SR6.1I1ewt_9NiKLDkPYPppSxg7i08I8QFNXNE9D2WRv0Qodl1ib4NGIaMWtDhNHzjj bfsoS7jCygESqoW5WPt944DWXUtFUj6p2b6v2er7Tmo6aK4u1Xka8Lk.b1wYdEN_5cWtL2Ffi2Bo BMHWMJBjUSM6.H196Lh8PvDf3vdKIA.WNr6YKiFbkGfEsvfZdhhynzHWb2.B6H8wtkdZizqNHQC3 bZ356IUqg_L3ybwT.C1Nir6FmnzUvZyChKHOjVAlkVjjwyjUMUtPmfLMyQ2Ivvd7Tu.ae4staiQ9 5xfa3LM09YS8RcIVN31ucCjjUdsbjC_71X8VaDlGdPLXr7FRKTcfoc451umfKft_NGzdXFpLzP3U NIL9zdVARBCFXd_dyBZBrUy5u7Wf6E041DGOyJBpnIrTu_8pFkKuaTp7v9mWheE_5Itw1rbITRYe yfCFavOSBewpxaIBAwXkwqkArw5FN2VhpcRtLnb5JihSihcU4cmwIyK3t._uhPf5DanCtgY92WfK 7MHVSnvbBvuzuIVYL4WB7GWZmJfhy13l38ygxtPKCKmU6MDRvLzBLePSFNBgiAL7TVrf1YGJKqvP 7c_11xZ7kJ603Nqejgd8XKjefJUPzrsYZhW6DhpZ6z7XG_AXFVTCbFNsHPkn5VlEhhRdWZ7OGimM jp6W2bKmXbIZAACKhCeoF1hdkrMg.CSOAFa2vX.fvt2rTgVRA7F1L5PB3N8SckKsvou5PDVtvxvo WjfH2TYJZ1r5RL0e6v5gZrxl5XhitJEqlfIA0sH0i7KJ43aSVqzxxxYbtjbRSrSwe4.djlfoshe9 QdiMoSsz_M4WFFgRKME_49NfnR1qO43DI79qBEOyrOCerw1mz8wYHvfuth.vL5Eb9KW84Sitz9Jr ack8HnJcly_2EMMwV9NyLf.KNHh7.HNIm7XD3RntS7UBsKfq1Jn23pNabFX0irAu7CCnKZ7JaOQ. bokJj004AlVbP2NA6fUE6tcUClpzgpQzJdQsBzWB59xlUfOup75_wrgciYefCGrKA43HlrJASB0J pfghg3fa4X7YIXC6PJUMIBCs3tTp16T7LtxnOQKbIV2ZOL8DgS.TsvWCCwQ2izXIZFxcri0RQpLZ N7On54m5QxtH8RmMhu.QYhDyNPAODHGOH5LK0oQpdpJlkmj.NnxzH4zCScb0p9wym.CcExyA5tLl jljRZbqcCbwq8NvzuTE6XNVjeZVUU3nSel8psLPJpH3dJ0D89iXcAtGrq4NAaNIyayhlrJwuupC8 ScZyrxVSrbnamACNAuge.IPd.DnmeoRvvcDQh30Vihgmh80.PEs0yQTNnRA84TD1M0Zap4TQTYZz MN9qnKVOzM0DNAFhNWqW_tsOfHusauoM_xaj9MZJ.7K4xbXNaBC_9biHpUInfm0Ua7.MkdmKadlH E.4P629zGunpuV9w7KjgmOadIpjJdrg3rY4xE9s79YdfTq1pA3jNQNM3k2cl.Ei0wQ1FiTdsdGAF ATvd5qz26ID2G1tON9_XWj_2ULI0bq6ZIqRIxORf2aviSmU4_ttTlRkI1L4y.G2UXvlulr_SlSJT .4Ah6LECYc195aiYeoihT3516yqDJRLz2keYcS0GS0ic_Zjkac25sjU0qFDs0grOk1ltw9HnZrci oYcXEYyMUI99EVzh5E.ljnhcDvJ5V6MNdFOYc_ooGftZQaD6LPOl3KiNIZFbLr4dSb9FfSjFCM90 nWZgB6e6P4woAQZbD2LoOdTwaebBr.d9.9c16d1gPG4Rx9IMjuhz9luWBc1LV X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 04:41:55 +0000 Received: by hermes--production-gq1-6597fd5bbd-ptc98 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 425b98847bb0eb0db58d880d0e9d16bf; Sun, 22 Jan 2023 04:41:53 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: An idea for swap partition size vs. swap space size in use handling Message-Id: Date: Sat, 21 Jan 2023 20:41:42 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3731.300.101.1.3) References: X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; 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]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4P00v95DwLz45V0 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N I have boot media that are each set up to boot a variety of systems that have widely different RAM sizes, from 1 GiBytes to 64 GiBytes for the aarch64 examples of this. This has lead to having multiple swap partitions of various sizes so that I can have total swap spaces that are somewhat under the recommended maximum sizes for the amount of RAM in each of those systems that a given media can boot. It would be nice if I could have just one swap partition on a given boot media, one that is more than sufficient in size for all but the biggest RAM system --but to then be able to tell the system to just use up to the recommended swap space size and to ignore any extra swap space in the swap partition. If such could be done, I'd no longer use multiple swap partitions at the same time in order to get to a desired total for the system at hand at the time. Of course, that still leaves what to do when multiple swap partitions are enabled if such a "ignore what would be extra" mode was also enabled. As I'd not use such, I've no specific recommendations to make that would make any difference to my use. === Mark Millard marklmi at yahoo.com From nobody Sun Jan 22 07:17:07 2023 X-Original-To: freebsd-current@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 4P04LP6NCHz2v7pS for ; Sun, 22 Jan 2023 07:17:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4P04LP3bj4z4MyD for ; Sun, 22 Jan 2023 07:17:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id E18588928F; Sun, 22 Jan 2023 07:17:08 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.17.1/8.16.1) with ESMTPS id 30M7H8BC022100 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 22 Jan 2023 07:17:08 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.17.1/8.16.1/Submit) id 30M7H7wC022099; Sun, 22 Jan 2023 07:17:07 GMT (envelope-from phk) Message-Id: <202301220717.30M7H7wC022099@critter.freebsd.dk> To: Mark Millard cc: freebsd-current Subject: Re: An idea for swap partition size vs. swap space size in use handling In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22097.1674371827.1@critter.freebsd.dk> Date: Sun, 22 Jan 2023 07:17:07 +0000 X-Rspamd-Queue-Id: 4P04LP3bj4z4MyD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N -------- Mark Millard writes: > It would be nice if I could have just one swap partition > on a given boot media, one that is more than sufficient > in size for all but the biggest RAM system --but to then > be able to tell the system to just use up to the > recommended swap space size and to ignore any extra swap > space in the swap partition. Last I looked at that code, that is precisely what happens if you add a too big swap-device ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Sun Jan 22 08:21:55 2023 X-Original-To: freebsd-current@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 4P05nK6mbWz30yGK for ; Sun, 22 Jan 2023 08:22:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4P05nK4WGfz3FDQ for ; Sun, 22 Jan 2023 08:22:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674375731; bh=Vt+l7Lqz6IOUdbBfV1k+B0C4HPLf9p8tQaLRpp0fAl0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oHbsJdtA/+fP0l9Oxf9QZuyOHYe0hyWdvg24oGY5cZgQgqMz/9HNOTVgxxoE42Y23SF+vwiWjs8iwugB/1aPVqjselAWPAnNoHSD1zYfk86kX5FvP3RUlQCvF9s42Az0u7wSbZ9J+6iSjpLGNdDp+XToGwW8nC+ZmbsKBGTF5PAEsB0mP2Lo8hYsAovGAM0LoSNHDw5r/V88mnryQHy5PCI8lxBdFhdUYdOMqNyhRtEixZEW39a+hUv5+lkvoQnmFQ7xi837KP0UAotrYE7c4YPqfx8EtQT/LWo7zYjsTRgZrS1NUQLtpDjgzR32b4pSqksfctJIuNVATofzIgq/jA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674375731; bh=3BIqEaPvuiCFef1r9vFjftXTCtPy2mo0uP4PQCruqkJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cT1+CJUaMYNTC7tcvwcr407x86pGV3gXd/2S46rqqtTp2G3lRmoNHfyaHM9xdcuAcv2+akXuvGpRpA4QHCDNBUxdyeOyPE2HW3I221fH9sqtQ3J63VLK8Ad+ecibmo8mJDpZWM+EcDFtnkwklHZKmfRhxZkh8fcTqSYGF+Z4FY2LBRiutLop6jTVWp3aGlYU+fDlm1w7dxcsv4MkOb/xbj7yhiN7Y+DlCbDNE1KwneUUSDrOf8L2OLqjcg8FxIJiQXN7iFZWH1PPb/7Way+/1FyDwt2nuK35CMzTP0Vo/BfP+LhX/SB8oIegYgTC2yHpBV/uyKUtQS6lkXtQrIlt/w== X-YMail-OSG: boysenkVM1mo0O.ZrRz4XQuYDq_tywpAYiGSyUzpH5QchKu.H54StShXfJhsau1 Ai_qVFnjzkrNyJS1rhyu5jOrrOzO1qa7xDlQm4C4hDDYlZexfg3a88PWSTwzjPiHJ4MTciZyN2E5 6a61j.P_PDRwmQqzAG7zklOnMtOAUL7Q2MJNxLQDwFiiFnWPwi_2j_V2K.5YJ5tEAeZ2cJJTjZXI BVbBxQfkhTgfQzfOswoRumb71oeNCB6Mn_GGfQJzC4OTBeGkR3bAa_jA_WtHEDrpduUOyQWsdQ6A 6zSa.OZSbLillC3zoOm3Fe3VvZzN1pR.az0BytHNndKpccxnbMNZbkeGPDzrIqFBwKknnNxG_5Us RlW6fV0TywV76D9xymkaCp7G5vuYLe_Nfop9LnPYlE00qIPnxT3n6pfmg_JTNOEXX.2IVA0NOsuH MOWSR2b6XkR_aDQqtKMuhW9Jud87VlmdNDIKUy6sbGPpdyp4ZA3Kri14sfX7_1b8i_lA4RHqDDSJ D0ywthPpSuYW_8yy1qBDYbSuwexIAvY0pVoJa.iN6vfooBxLqvy0JvZSp5HvesfQjXg50IuTbhhM JV.KfkQA4fneDr9OJX5vElWyFIBt.e70qvxWeehz2loeMXRKWbufteLOEM7SD00cNuBwg9i2X8pQ zYnAsrxBXxfsKRt_5gI2W4d8oo9JTjGCZqFxjNfeniz5ThC8Hu4du0UFBOyVBMjOGVDjOFOAlnm6 RA8YAoppOJvqtWKB2gtOK316bVTtsSlFp9u_.ETzoVOyo3ysD4CNv7O_qVhMAGHjfbqIn8EEWA8c jjUjBagu4qU3BeVQduPdURz4hqpCqH_OYMY3vJ28vAE_U.COf_6ZML9jIHOUoVn3SwTjIOjbuvGq 04m2z1gL4Qxbza8iDmxJB_qKoy3i6kT54tzZ4PJPE2st3VWKInfi.yEhJ5hx6GfSSEKTSDDoQlSe 569vIKqUMO8wSqhCETYhb9jlALizeO.1WGG1cj0tnk82jOIr8YA.cq8V6WacklVMuPi.RjYL0Idu pnC3H8v4jponkTgGFI6hsenKah8U6fHkcxNQyHNcW2hjsDfmCPgfn1S0SOppMqmDxqb0Gucgr6Wp yUZ3avRzLfg30OOFKfj76.K3qKraxAov.SC8nSQwy5WCLc.kr1fbxWvC97UTHgZaXZlZCiauDpB9 aoFi_MgBBsRDlNNg0TyMz235iXuHaoGxpo9Sa335S3BUl_h_PEGMuuZZdaYihVNxTuT0pSWsS.Vi Om4s9vCwOWMyDw2t3.DQW61WCoN3HigVARWptndkoK58.tOIWZlMpQbtaljouJJFmhIJ9DEd_yBR A5vjJKTJBCOP7g1ScJV5NuEiGCcjcLUAC0jSgKIfVANivfHHSsB6zbpZXY9mIESJDhwx.TmTG8FZ IrQaLqqLKSAb7GM_zhHDzsROpU.rQjast0maJHc_z4EfoXMvACv35G2th2TC3K2pTKyKicA2LXE5 pWFU2mlQ7Z.RWBhN3Eow9fjozntDpJVNQMi9fdd.SBADaIQIiD6dH7OJQMJQDhnQm6rprwcUHVE8 A3Clhlm8QgvM_5_WPL5ZZQ.MQ1EXQz75qHPXIgKV9uqI2jy.dCFVjQPkZFteVk6xgdwwugbb.qSH f6foDmHWEKDAp0ggDaPuboZyxp4_ykTvjQNGuyZxtSsw5XzHwCSkWLw.216FpDXFLNEv_1yjtWWR 3B8bK_mlCg9DvOnFxleqEcZ5bPaEgs2JQtAJHBUDhdxnc9Zt9yRb0LkH8gNvD.C4FAAF26OA4y2i BZcqzKhCgKnJfX9h_Ntk9b16.aopiAx2dJ4PILtL2qjoMWdw5.jY4YesRwf4KrD99ic.lVdvyda6 thagoAJUnVwq3Usp5G.63sT_FHVbCaJq_sXwy5qEzI.SaE4CIz2TscaCgImc3zbgaarkT7x1ngSl wbNguzLRhA2G.VYVREHyYshvonf1.1w3DiW2Ah9oBZ72LoZcInl7sRvdV9QF3lD.Vz1BoP86OIcf wJ5Uu9YNGDx2zJ_fqHtcu5NE.1ZNvAmYhsAc1gN1A97T0FfZa976tC61lulWEvaxrM41ZYrDCVST PqjyXSRVWBQIJl6H3DLKlp7njKivrqDL11Bv9UXA1zgIzv8HSJVRT53mZ0gcoNV_zvoFKephOuC_ ZXWlpNvAjrJMHZ.Nn4dJZzO_G_3rHawfv3K6NeB8kJC2rlL91k6iQEQmJRbFDFFxjEpI5EGUxFX3 fuuMPwQTvl5yTt7nCGkp_R67gr.2jzkoa4SXAHAFymJZiuuur8ZfhsUQ7N.t3zmgONqf23BvJbKE - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 08:22:11 +0000 Received: by hermes--production-bf1-6bb65c4965-w6w4l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ef0bb40ffd446fb4ea5e900ff0c918a; Sun, 22 Jan 2023 08:22:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard In-Reply-To: <202301220717.30M7H7wC022099@critter.freebsd.dk> Date: Sun, 22 Jan 2023 00:21:55 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> References: <202301220717.30M7H7wC022099@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P05nK4WGfz3FDQ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote: > -------- > Mark Millard writes: >=20 >> It would be nice if I could have just one swap partition >> on a given boot media, one that is more than sufficient >> in size for all but the biggest RAM system --but to then >> be able to tell the system to just use up to the >> recommended swap space size and to ignore any extra swap >> space in the swap partition. >=20 > Last I looked at that code, that is precisely what happens > if you add a too big swap-device ? It produces a notice reporting how much bigger what it is using is than what is recommended, if I understand the message right. Here is an example were the difference was small for an armv7 context: warning: total configured swap (1003519 pages) exceeds maximum = recommended amount (1003072 pages). Another from a context with a much bigger difference: warning: total configured swap (2097152 pages) exceeds maximum = recommended amount (916632 pages). These sort of messages are followed by: warning: increase kern.maxswzone or reduce amount of swap. But, as I understand, increasing kern.maxswzone makes tradoffs with other kernel memory use. man 8 loader reports: kern.maxswzone Limits the amount of KVM to be used to hold swap = metadata, which directly governs the maximum amount of swap the system can support . . . . . . Note that swap metadata can be fragmented, which = means that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken = to not configure more swap than approximately half of the theoretical maximum. (Note: My understanding is that an "approximately half" is the figure shown as the "recommended amount" in the warnings.) Running out of space for swap metadata can leave the = system in an unrecoverable state. Therefore, you should = only change this parameter if you need to greatly extend = the KVM reservation for other resources such as the buffer = cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. The wording in man 8 loader is about decreasing kern.maxswzone in order to make room for other resources. But the implication is that increases leave less room than normal for other resources. I try to avoid getting the warnings as I do not have knowledge/context to make well-guided tradeoffs for the resources. As I understand, the 2097152 pages vs. 916632 pages example means that it was operating with the referenced fragmentation problems being more likely. That would not be true if it was just using more like the 916632 pages and ignoring the rest. (I was not suggesting changes to default behavior. I was only suggesting being able to put it in a mode where it would have used, for example, just around 916632 pages of the swap space.) (Note: Some of the detailed man 8 loader claims that I left out seem to not be general to all platforms, despite the wording giving no hint of that issue.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 22 08:42:49 2023 X-Original-To: freebsd-current@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 4P06FN4FMmz311X8 for ; Sun, 22 Jan 2023 08:43:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4P06FM2HnNz3Gb4 for ; Sun, 22 Jan 2023 08:43:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aoYJgK6z; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 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=1674376981; bh=Iw/J/LOLSbOOOcO0tag/5dguG5H/Y75xmimJ3zgvyt0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aoYJgK6zg3p04GHQ7D7RlFExtUZzPwJBI47zxCgSQudrPNcBawKODUkc2RbhNw9okg7vtS2NF+cD3WafYWsTzIfivwF/JCFrFH7VITMFsEwIfSGeCED/cMKXmvRWy53mVOp9kV1iEhJwXkNNXlAe8xz1x5SHf6JN4QxAlc3ByNR24ev7agIM208uSYl5Nr+3tBQi+WgaaA59YyedI4j2Icld+BcTOzs/P8orOqCtibTWFL0IOLkT9wOUnlohK7Wc0L2UEtiv/hWYJbufCv+30XBWDKlHcS19AabRWQYTDw657ZogETw1LTcLqA2SaQu/6qpJKFO6BfHwTyvMqLU3Ag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674376981; bh=0exGLGqAcG+7qtBahFj8ljBmlIjCNhE66GKO7CdgKnK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kr9xSiNXUznsf5cbv/g4JElnncYG79drrnUV4Dkmypv63iR7wktwnu8P/rfhynpibR9Cj439sHkMdXhO5RxggXZJPrBO7j5InPagjd5PPCIiOukM/zYpblk2w6aIHynAp2zCxlNXLFz3ytOwiqeQMnn21BymgQsJT2GeQ5ggtjbeurMTYossPh3G/t0/fLqMBmR1J/GSqszGCC6Y9N6/4yTwn+TBt57EhqRZ8Yt5+Ibf9ckLmYae1PoFXdJlbjxs8uJHbaXSzxNo5EUNyYZpglQYTen4vwcfMikXZVHoNWoWC/ugwEeGv1ehPwyJ3fxmRpGF9OcJiGBS1K1dvgt22g== X-YMail-OSG: lV6OsCIVM1mtX7t847GExrSnXpMAwnISqA0gz4jGxyCEn7aPbEEq7cRf9qs8tXK gxiCt3alV4MoLNg_FRFrMIj36JuQqgRDoeHwhoD2pN1cDSYsh_JNlAGPCczlObA9ClZUrYC_HZg2 U8yHf79srzhafoXVzbxty.0DjaC2FhMz25Iq4CaGQrtiRKkKLXLJCmFLIQS6fRYMBIxUQVfg2Emw 0uwdlBLXtZ.4VoleGIewfGclDwUn8BWg2h6BSzbMxK0F6cdtXPjei1eHzg.CevajWItZPVwGnh5e xtkuSjFRdiyarcP.Wuc4nEP4GMVmJnzehYOhF4HfrH0dDQSOjptK2IJB7QnOEaySeL8gjGwym6hA 9HwabN_dXnwS8cR.0VdI3DNdW7.DWWufEsyplxAPkZR4dBjalisOon05POesy_r.l2ulOssJwmLg fs41bapqvawN0O7TtqIvU8oBCBuKvFMP2rksg_ZNqyikgP7ghXyf.VU46PfqOQr69a33RQzkz9gk QE2p2ZNmRli.sLOSL4NIZV9BAKQvqUT2Ul8Pm9uimm6P7mBDM9RHokPNHzFDYbqxo5Dhm4JyGoiy uJtIChoXPj_GSoTM1XuWe65.Tmxq6l0lWvwQ4gyR5bnSVLV2x3Y.oZUyKh8oq72MuUurZKBilY2T 4aXgAyHCWDrtmG_auOcjUfiCQWGE9vJtSrdsjCmu56uN1n9ORBWRTw_4CPpCO3ZDd0ZLj_d8Cd1i UTG5LOwQyG0rgcm3OcwvUqDZZPl9yZGnIHpU3LjJK2FTmDPYkFK2LfPRWEYp2PYUH8awojYuOjfu gB20BNGqm5nj9w8TjkryFax7PodXERKDj04rafrWqm928hpQiw8dKd_65W.384NpPDHIYU3mwz8H WfEGvfQeSHNfy5c_BjvF3tElHqWElMA0Zf0XuE4GDIsNuPpQMTXUIzIt9i144nNNOZlfu.CUu5Fr wAKHuCcFXLQ8JYqDNnTMIo7hZLV303Infc8i4pkrKMos7Z5O.twbudYwmMNrFPnf6extTYQn4seF dzq8YhmbyaQ0F8OI6Cdni.KqdDr5oh9.vKzZuBKknxwIKeHcCW._ZEmoAi8Orwx6gmT_X5dL8fqL kd8i.yNAj2Pmewz_B2kRQbDQ85fzEMrX6NBGrim3hO1gf4RMOhwY7ArKWRyDveBao8j2ygbd_y4h BJc3KWgm6ZSjbMBy24Xd0vZOjraYAxdebbz2Pi6xteFjo8NBvTSX9LDlGmwVob3Lx5SCckeyrzrE IsVZ82_ayZiP0k5jVm62F4qlnaW8qjzJaEnaZ80L4p0HWehq_7BgzVXrLqjIRuMIAvDp1y.wt0AN WfwN5qDmvD3Dia7Tb6i_4jGOcGSMPZXrNTvi2N2l0GnGrIrFzctr5lKTshA2C8FvRs_3VlzCpTW5 REhCLEXeimdqUHPLeF8SlPzUkv6CYFflcR6sqog517rMAfwc2Wit9hUyF9bunD67pmh0Hk4oxSox nqHYn.ib8BBtswtv09_gu._WwU4H4WbGJccf2sBGGRCLQpRDCmQMzDYHKmtgDy8WJ.yl6lQUywOy przocSbxE7m1_Nj.JzZ2CDYOvbFYeHlU1CGHVYAzpgxqDDCnviFOBOvqqS2f0Ilnh3OWF4kEfst6 CTZIq8Q9j7DkJYCtut76I5KqM1p21PsJLhTPiRa4BpCRNM8nM1Uqd1XfYDq5QxjZXRuzOwEjV1C6 zyE2vvM.oZGLyBC3HgoTDMoHRalFLbGmEux.nl.Z2ZLoZiwjT6GmTSKWCslYlNINc1gnYciS7FyZ CuONpegylWhG6ku2.0yEIbQr36c9Fl.0f57xIV9xxwjye2_IC8VGLSL_Dr2Zhs1OSQTOcj4j141n iDm9e34xu1P71crBUVIzGXT2bwp70bKu5rVWZdPYYiMnZpwmt8zJVDxWXxnrvTHh3l91Vr6bIbKy tnnUAEFMI6lWtCIYKE4otrvw.IjwkIgwceTpxFWkH5hpij2Dp1R_D4lamkZoX1ZX_0lj0DdI.Y3o K2jCcojA.VdB5Vw08mfxE8a6g5p2L7NTCTKzZ4j8Ox1AcUadVbY75DaOMFpXtUEPHvMzDfABj0Gg YC8ACTXHLbMy7.A91A2JdJu59brEbZPfYoXdi4QNHTt8_xE2yC.Km7xGBgphS6O0HT2DWhTNrhyV K_D0zeMZyUP7TBFNGzgxQLLthNYTQKejrxVIcnIs.TvVXnEvTUcEnMv58_E3SCHaS3EsybAam56M _r30nN_.QygogFcbNjsTnZca26xGR5Wr6XosEB_xguLPXdjSMRil0n3ZUkxjy4F78JWybUnShztF 83Q-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 08:43:01 +0000 Received: by hermes--production-gq1-6597fd5bbd-ww65t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 05e5cac3ace28732c52acad9a713c2ed; Sun, 22 Jan 2023 08:43:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard In-Reply-To: <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> Date: Sun, 22 Jan 2023 00:42:49 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <960C016C-9D43-4F24-8913-363676B5E202@yahoo.com> References: <202301220717.30M7H7wC022099@critter.freebsd.dk> <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-2.84 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.34)[-0.344]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from] X-Rspamd-Queue-Id: 4P06FM2HnNz3Gb4 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Jan 22, 2023, at 00:21, Mark Millard wrote: > On Jan 21, 2023, at 23:17, Poul-Henning Kamp = wrote: >=20 >> -------- >> Mark Millard writes: >>=20 >>> It would be nice if I could have just one swap partition >>> on a given boot media, one that is more than sufficient >>> in size for all but the biggest RAM system --but to then >>> be able to tell the system to just use up to the >>> recommended swap space size and to ignore any extra swap >>> space in the swap partition. >>=20 >> Last I looked at that code, that is precisely what happens >> if you add a too big swap-device ? >=20 > It produces a notice reporting how much bigger what it is > using is than what is recommended, if I understand the > message right. Here is an example were the difference was > small for an armv7 context: >=20 > warning: total configured swap (1003519 pages) exceeds maximum = recommended amount (1003072 pages). >=20 > Another from a context with a much bigger difference: >=20 > warning: total configured swap (2097152 pages) exceeds maximum = recommended amount (916632 pages). >=20 > These sort of messages are followed by: >=20 > warning: increase kern.maxswzone or reduce amount of swap. >=20 > But, as I understand, increasing kern.maxswzone makes > tradoffs with other kernel memory use. man 8 loader > reports: All my references to "man 8 loader" should have been to "man 8 loader_simp" these days. (Old habit, not yet replaced.) > kern.maxswzone > Limits the amount of KVM to be used to hold swap = metadata, > which directly governs the maximum amount of swap = the > system can support . . . > . . . > Note that swap metadata can be fragmented, which = means that > the system can run out of space before it reaches = the > theoretical limit. Therefore, care should be taken = to not > configure more swap than approximately half of the > theoretical maximum. >=20 > (Note: My understanding is that an "approximately half" is the > figure shown as the "recommended amount" in the warnings.) >=20 > Running out of space for swap metadata can leave the = system > in an unrecoverable state. Therefore, you should = only > change this parameter if you need to greatly extend = the KVM > reservation for other resources such as the buffer = cache or > kern.ipc.nmbclusters. Modifies kernel option > VM_SWZONE_SIZE_MAX. >=20 > The wording in man 8 loader is about decreasing kern.maxswzone Again. > in order to make room for other resources. But the implication > is that increases leave less room than normal for other > resources. I try to avoid getting the warnings as I do not have > knowledge/context to make well-guided tradeoffs for the > resources. >=20 > As I understand, the 2097152 pages vs. 916632 pages example means > that it was operating with the referenced fragmentation problems > being more likely. That would not be true if it was just using > more like the 916632 pages and ignoring the rest. >=20 > (I was not suggesting changes to default behavior. I was only > suggesting being able to put it in a mode where it would have > used, for example, just around 916632 pages of the swap space.) >=20 >=20 > (Note: Some of the detailed man 8 loader claims that I left out Again. > seem to not be general to all platforms, despite the wording > giving no hint of that issue.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 22 13:15:14 2023 X-Original-To: freebsd-current@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 4P0DHb3S5Qz2twt6 for ; Sun, 22 Jan 2023 13:15:23 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4P0DHb02Flz3ymg for ; Sun, 22 Jan 2023 13:15:22 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTP id 30MDFFxi029031; Sun, 22 Jan 2023 07:15:15 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([10.0.1.1]) by mail.karels.net with ESMTPSA id hOMZGeM2zWNlcQAA4+wvSQ (envelope-from ); Sun, 22 Jan 2023 07:15:15 -0600 From: Mike Karels To: Mark Millard Cc: Poul-Henning Kamp , freebsd-current Subject: Re: An idea for swap partition size vs. swap space size in use handling Date: Sun, 22 Jan 2023 07:15:14 -0600 X-Mailer: MailMate (1.14r5933) Message-ID: <83FEEEDC-1880-4A7A-B5C9-312FB86D5826@karels.net> In-Reply-To: <960C016C-9D43-4F24-8913-363676B5E202@yahoo.com> References: <202301220717.30M7H7wC022099@critter.freebsd.dk> <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> <960C016C-9D43-4F24-8913-363676B5E202@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4P0DHb02Flz3ymg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 22 Jan 2023, at 2:42, Mark Millard wrote: > On Jan 22, 2023, at 00:21, Mark Millard wrote: > >> On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrot= e: >> >>> -------- >>> Mark Millard writes: >>> >>>> It would be nice if I could have just one swap partition >>>> on a given boot media, one that is more than sufficient >>>> in size for all but the biggest RAM system --but to then >>>> be able to tell the system to just use up to the >>>> recommended swap space size and to ignore any extra swap >>>> space in the swap partition. Why not just reduce the size of the swap partition to the desired size with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual inter= vention. Mike >>> Last I looked at that code, that is precisely what happens >>> if you add a too big swap-device ? >> >> It produces a notice reporting how much bigger what it is >> using is than what is recommended, if I understand the >> message right. Here is an example were the difference was >> small for an armv7 context: >> >> warning: total configured swap (1003519 pages) exceeds maximum recomme= nded amount (1003072 pages). >> >> Another from a context with a much bigger difference: >> >> warning: total configured swap (2097152 pages) exceeds maximum recomme= nded amount (916632 pages). >> >> These sort of messages are followed by: >> >> warning: increase kern.maxswzone or reduce amount of swap. >> >> But, as I understand, increasing kern.maxswzone makes >> tradoffs with other kernel memory use. man 8 loader >> reports: > > All my references to "man 8 loader" should have been to > "man 8 loader_simp" these days. (Old habit, not yet > replaced.) > >> kern.maxswzone >> Limits the amount of KVM to be used to hold swap met= adata, >> which directly governs the maximum amount of swap th= e >> system can support . . . >> . . . >> Note that swap metadata can be fragmented, which mea= ns that >> the system can run out of space before it reaches th= e >> theoretical limit. Therefore, care should be taken = to not >> configure more swap than approximately half of the >> theoretical maximum. >> >> (Note: My understanding is that an "approximately half" is the >> figure shown as the "recommended amount" in the warnings.) >> >> Running out of space for swap metadata can leave the= system >> in an unrecoverable state. Therefore, you should on= ly >> change this parameter if you need to greatly extend = the KVM >> reservation for other resources such as the buffer c= ache or >> kern.ipc.nmbclusters. Modifies kernel option >> VM_SWZONE_SIZE_MAX. >> >> The wording in man 8 loader is about decreasing kern.maxswzone > > Again. > >> in order to make room for other resources. But the implication >> is that increases leave less room than normal for other >> resources. I try to avoid getting the warnings as I do not have >> knowledge/context to make well-guided tradeoffs for the >> resources. >> >> As I understand, the 2097152 pages vs. 916632 pages example means >> that it was operating with the referenced fragmentation problems >> being more likely. That would not be true if it was just using >> more like the 916632 pages and ignoring the rest. >> >> (I was not suggesting changes to default behavior. I was only >> suggesting being able to put it in a mode where it would have >> used, for example, just around 916632 pages of the swap space.) >> >> >> (Note: Some of the detailed man 8 loader claims that I left out > > Again. > >> seem to not be general to all platforms, despite the wording >> giving no hint of that issue.) > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Sun Jan 22 14:11:47 2023 X-Original-To: freebsd-current@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 4P0FXq0pPRz2v3fS for ; Sun, 22 Jan 2023 14:11:55 +0000 (UTC) (envelope-from SRS0=grGQ=5T=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4P0FXp5Vtvz44My for ; Sun, 22 Jan 2023 14:11:54 +0000 (UTC) (envelope-from SRS0=grGQ=5T=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Sun, 22 Jan 2023 15:11:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1674396707; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oQ5QgC+eNiQ3e3yPAQx0bL5KCtPrZ5AQZPjjoZT9MkQ=; b=nVtUIQCHAIhl7uej5qkOByzVN9MxJVBzHPRKJjgktxV7iXf3jND8gafZ3HSmp81Bp1q7ZV YAWEeOwAeImmE+Ctazp40SZaIuhmLdp51l4BZQnSSDXcC8CfTbqfg2BPf4gJlsvUlt5o9m Iv2XXHkL81YQx66mwNkIYAD3CO4BZoVcNyHJpX5lF1dKYiVDynOWk4FzuUs3wGUxaa0dDj 3BceNu8KjsaU2rw0iiWc/z4jGvac06NBJktukBmc/S6dp+hAQUPO+3wf6rwfj8wp4pZNxA Cn0ZtI7AxlmGheLErpLvNbj9KegdZPOOEUicK+VMEb702WiOvNP0Z9LvQ4ikhw== From: Ronald Klop To: Mark Millard Cc: freebsd-current Message-ID: <159467120.7.1674396707299@mailrelay> In-Reply-To: References: Subject: Re: An idea for swap partition size vs. swap space size in use handling List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6_262847912.1674396706881" X-Mailer: Realworks (641.957) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4P0FXp5Vtvz44My X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N ------=_Part_6_262847912.1674396706881 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: Mark Millard Datum: zondag, 22 januari 2023 05:41 Aan: freebsd-current Onderwerp: An idea for swap partition size vs. swap space size in use handl= ing >=20 > I have boot media that are each set up to boot a variety > of systems that have widely different RAM sizes, from > 1 GiBytes to 64 GiBytes for the aarch64 examples of this. >=20 > This has lead to having multiple swap partitions of > various sizes so that I can have total swap spaces that > are somewhat under the recommended maximum sizes for the > amount of RAM in each of those systems that a given media > can boot. >=20 > It would be nice if I could have just one swap partition > on a given boot media, one that is more than sufficient > in size for all but the biggest RAM system --but to then > be able to tell the system to just use up to the > recommended swap space size and to ignore any extra swap > space in the swap partition. >=20 > If such could be done, I'd no longer use multiple swap > partitions at the same time in order to get to a desired > total for the system at hand at the time. >=20 > Of course, that still leaves what to do when multiple > swap partitions are enabled if such a "ignore what > would be extra" mode was also enabled. As I'd not use > such, I've no specific recommendations to make that > would make any difference to my use. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 > =C3=82=20 >=20 >=20 >=20 Hi Mark, Do you mean you would like to be able to add a "size" parameter to the fsta= b swap line? /dev/da0p1 none swap sw,size=3D1g 0 0 Another option I can think of is using the "gnop" geom provider. It has a -= s parameter to set the size. Regards, Ronald. =C3=82=20 ------=_Part_6_262847912.1674396706881 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: Mark Millard <marklmi@yahoo.com>
Datum: zondag, 22 januari 2023 05:41
Aan: freebsd-current <freebsd-current@freebsd.org> Onderwerp: An idea for swap partition size vs. swap space = size in use handling

I have boot media that are each s= et up to boot a variety
of systems that have widely different RAM sizes, from
1 GiBytes to 64 GiBytes for the aarch64 examples of this.

This has lead to having multiple swap partitions of
various sizes so that I can have total swap spaces that
are somewhat under the recommended maximum sizes for the
amount of RAM in each of those systems that a given media
can boot.

It would be nice if I could have just one swap partition
on a given boot media, one that is more than sufficient
in size for all but the biggest RAM system --but to then
be able to tell the system to just use up to the
recommended swap space size and to ignore any extra swap
space in the swap partition.

If such could be done, I'd no longer use multiple swap
partitions at the same time in order to get to a desired
total for the system at hand at the time.

Of course, that still leaves what to do when multiple
swap partitions are enabled if such a "ignore what
would be extra" mode was also enabled. As I'd not use
such, I've no specific recommendations to make that
would make any difference to my use.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com

=C3=82 


Hi Mark,

Do you mean you would like to be able to add a "size" parameter to the fsta= b swap line?

/dev/da0p1      none     =        swap    sw,size=3D1g &n= bsp;            0&nb= sp;      0

Another option I can think of is using the "gnop" geom provider. It has a -= s parameter to set the size.

Regards,
Ronald.
=C3=82  ------=_Part_6_262847912.1674396706881-- From nobody Sun Jan 22 17:46:29 2023 X-Original-To: freebsd-current@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 4P0LJh2cWLz3NGnY for ; Sun, 22 Jan 2023 17:46:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (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 4P0LJg6vJRz3Dkm for ; Sun, 22 Jan 2023 17:46:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674409602; bh=HmQ/TWcA7MpbZCjwu6w2Nb1u+m/T1ntQF9rsPiT4XHM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OWIrRfjbq6xjqJjlCLeRebzTwBn4yl7uWoe5775rnqT6/d5AdUOifwxINr06swKUjLewo9PsEkQyhVvO5MsXGhYHOuuqBFG2U1iSutySdxcIZ5CuW/SoNMeWMVPLGaejamGrmgIVrfscxBmO3ImHWNxmVZx0uOPI+P/tM+zmaDr00HAxVUzg1Tkk6UgbHnUOI+cV/r0dxDNk4CFi8RzRgtlspKT864zc+7mHAzdUjGzHjbesx5xYL4KpiWOPt/eqar10D15tOQhSEDDItWHg45va6r/ONCaplStfGpZ+73hPDDICWo02fHwjccdHQYnhJ14s/4VZjm1p2TJTzf49yw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674409602; bh=EnHecBoCYVttEAENx1xGz5mf2Tpalzipp29+ZmRdAvL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=trQoFlqW8Eq8XGeSmMBnExFUWyxw4soFatMYpJC6pdFyTflwxXGeqXYwt4JVdV5lfLK5TzvGa1frcCBaoqKDFvyQBl0QoomwlDPZhrQ1z4B85KFY6XQF81Y6mLYnHOIm2HFXiswgoGnOOE/FIvKowHMhY8bMGkpKXeKwHlTCZ/HFhlb7Jz3A21jcfA8O8Y6sVJZixPIPX112YNR/Ee71GyftTELr6P3sura6FG8sSB5/iZb+J7e46RlY8gTnx3ZPuE3mppnV93UdsdKpXmToCak1U99wSNNSUnNflxGgf40Qk+gBWm0K9Ra4rJUd+guvSkb/O8A22x9IupNQCQdQ/g== X-YMail-OSG: u41cQpAVM1mcoiF5DOvm80lf_N4W1goNyOHeuvxwo0CA6rqd3o0aHv6UbIFlfOz tIGyFhauQGg60IUvF7U_WqsA3dV.SP7YlChHZGpkxI4iNYCsBAJFR_FK2mqA5wNyPTgYLRLcQc1T xV.oFTo5jJ1cRuCoaVSQPTEnLVihYNcZ5TveJZpG7xjjNaM_oharqw8.f7N3MbwJF6ifCm.cbOzi GIFgXanDpoP3rHf2lhu0LNeaWVDmYPpfRV.H7ToVsR8OQK1tA1AjaePQQE70LztziWms1RBazWl6 T_eJGWOHFkWC1vgd6M3k6A_Y1xb9RMQskCEl8UWU0CHwrM7l3I1e0VWtlRXrUMr2HThu8bZrZA5a 7ksMHkel0OgVdxJ6W0IqD6bDFHMUfzBaVNnVsCMfmMoEJr4bhbO3DcwuRAM4AURSvipA62M.3POY wEnxNnmfkTC3iCm8ygfzEXx02kgfcE2YyTwj83w99XGs3aZwxzC943f_EeFY2egvwWLTgl0feRYD ZZODAt1cErvf67HRG2YzOQy.zYqBB1fmiH3otja1hC1BCuwY5fwELDInuf7gxRo82QoM._wa19KN Q8OigIIWdETSctl8997anQlexfbQVL.lpwdTpJ61fmHSHCIeoXSoKolIdQVhtcBrmVYuVgiZ437A YQzkHDPWeiQ974HiqNKhTN9reFRwg5L0gsjnRCu9.s0ugZSgCVpNDzcfHvPUZqfSSSYp06S8nSu_ 6iRsAG_nji9lO0vhjcaR2C13Dz9tcOh0sJfeObX6loj015QuD.VOkHAtQfhv_Gc8esUb_Dre8aXC FAJ5BV_Cj1.1Ohc4QilrYt2dDpTdlz5_yzgd6dsL0BbunCoyupV9Dv9bD00gSJS3.3z_Q1KFxPg8 qnKb37XjrjR3NXMSW7v0BCIPa6.TkEAzGwctBj91LVNXni3S6TIRJkOtgU3twE.1nNhABNVWn1Vx 6DiiVrsTycHDtiawfK018RMgyN2tNNtAwSIZTDhjKW7gP2PfVNEX5GDiqSKw1nGiu2opJTNY6Z9a _Qpm3aazoqShaVC4azpp81owL.e5PZFrL8pOe56BCeI2qIaPEjdyVOzswtOMjRqf6aKL8NhP08LC NZsn.MJkGb5fe1E1m1JTioBy5JGyPx63fTGc8AATx44KBsDYDlQZkV5VQLBTFkqsSE5RPzG.wqG9 7gPUlQ6eO90YAH.py8P3.BmdoiFqSylqMNzOUUfjZ8p5rS5wZFezsNxr4.1b5AdE4fWnT103O9NX FtkvzviqUc.5qBuSj7f3O8qlqgp9yDdxvJf1KB2rUc8R9_8.OpXFV5t4yjGas6weg7FsTLzGe.8R fWAqbp2Soep4dIuDXc9fd_wAW78ZGNUPox_tgmiSbN2WDVJyZksl3olJCbJs6SNnumzuo7wVpRUc hEXDsZuaR4k_sc9xTX6mhQdohEsWvTNq3J4uJaDlVNioWNkS5uZzdpRF9fGGvqPcVhkXZCk5WeKB N5UNJHneRMb87BrySzF9moaztcgZk23G6MDnZ3zJPA9VVPdyB.mzU2Ccs6GVezFsYq_M_ik0PebC PL3NXRVZ0iQYpVOsMLsg8X1pMTVdbbiBpsttTosT.vkcRvu314McZqe2dO5FQvr48M72JXYvFV7B X5ioPeAygWfEYwds66QgWqhUPKkNKjecVT3sW0etjEGSvXvk02o7gD5P.R2tRYYL9QOSa0ZaEIXM zDWOXHotgEUzOvmEBKb1E2KUOtXTNsR_Fa_pu0cqaauGFnxgFasvtPcGBjBjsJ6il4rwOPFyKLqm QvS2QszyzyuOM0_LuaAB.e7WgcWaMXaMgOxKhkyPNN7D.zaK4RGRaJ48MyOOhIt9z0agcDas17U2 P6Qwm0ioXwKo3vLkaN67gF29gFJQrnJJK_c6f4TwaFVr8Qk9VFHhdhhaJRnsoDP0F_5Y__zHH559 PMSFURZ3J0aXKbi1rFYhusIuqZGV5o.EYFKfD6tY3xt3qBEnhNulnSi5_wgjxWTcWE7.2st0UnYp arimAyYwV48WW.3wZPxTvmfbeUbggDF0.nfTJgEhzGU.wn7jYXavLyejwqUhocKfYcEz5UIQJwk7 CaTrbRZReqWi9QJ1Z_Wf_9cT8K1v73K5i4AXft.B_QZa1uX7IuS9w0PoagAzNIy4A6JBJKXJZRfo _4GUF8wGVf6DhbxcNEMBnpw7fdSf83goqyE8HlfZAmhXS6_33bTXXj_bHTEQRpyMpZGUNvTYEiAu 7vlisCh9oqYhtMqhhXFBBNoMGr3ze90aQRJ0CjANLxm.XW4AnyNX9NBtF0_qJXvHjbTE0J8JrsQv Wrw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 17:46:42 +0000 Received: by hermes--production-ne1-749986b79f-kcqbz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1d8e7e9022777e2a5db5194e1cc09208; Sun, 22 Jan 2023 17:46:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard In-Reply-To: <83FEEEDC-1880-4A7A-B5C9-312FB86D5826@karels.net> Date: Sun, 22 Jan 2023 09:46:29 -0800 Cc: Poul-Henning Kamp , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <202301220717.30M7H7wC022099@critter.freebsd.dk> <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> <960C016C-9D43-4F24-8913-363676B5E202@yahoo.com> <83FEEEDC-1880-4A7A-B5C9-312FB86D5826@karels.net> To: Mike Karels X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P0LJg6vJRz3Dkm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 22, 2023, at 05:15, Mike Karels wrote: > On 22 Jan 2023, at 2:42, Mark Millard wrote: >=20 >> On Jan 22, 2023, at 00:21, Mark Millard wrote: >>=20 >>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp = wrote: >>>=20 >>>> -------- >>>> Mark Millard writes: >>>>=20 >>>>> It would be nice if I could have just one swap partition >>>>> on a given boot media, one that is more than sufficient >>>>> in size for all but the biggest RAM system --but to then >>>>> be able to tell the system to just use up to the >>>>> recommended swap space size and to ignore any extra swap >>>>> space in the swap partition. >=20 > Why not just reduce the size of the swap partition to the desired size > with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual = intervention. Why would I use the size for a 1 GiByte aarch64 system (prior boot) when I'm using the media to boot the 64 GiByte system? So increases too. Manual intervention every time I move the media between systems, going in both directions over time? That gets me into the business of independently calculating a reasonable lower bound for the recommended swap space every time I move the media between systems with differing amounts of RAM. I've noticed that the recommendation varies some across the OS updates. (My guess is variations in the kernel space use is involved in the recommendation.) I'm looking for something avoiding such a redundant calculation, something that just works given the variability across OS updates. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 22 18:20:32 2023 X-Original-To: freebsd-current@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 4P0M4043RTz3NL3j for ; Sun, 22 Jan 2023 18:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4P0M401PFpz3RHs for ; Sun, 22 Jan 2023 18:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674411645; bh=U3qFjLnd6fkBMy8wgRo7iSst+ituVSv5IQwRnT7/++s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SXqEZ14P5utS3e7R0Lxn3zFUei2+ItvjrQR57xLOC51DZDoFVzmPK3s3nvhvuuWGZGznrRJc9O4W1G0Aw4UzU1Sorkje0rcg5DsuW/7e8JsFL4yFbFP02S0sTAxXqRmaxfIfJkDaOsGuZylfhQm44jzIvMy6yh3+GTlZomkPBBCttFC0gVZFT3Kq/9YQuqOUM3Ojl2XaqWJCBV7KZCGRQJWBeAc0LehJJLhMGdPyC8E995VSu3oknF2f2VUvwxBdQZhpOlpdWsfOCpINzKyBJn92FXxoqtBTkK4EH9xVcPe+KYa6zvNjEALk0pa1qprxsd6JjPNWw87Bu1J2WkXmDA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674411645; bh=YSzCGf7kQ0KkAcpq7iwMCFi9k7yYxEzw28yF3HcBSra=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=U9QbfF1CLl1pUzbzLqdFKhp3ugaz9Gghvru9jEqTF75+svpL3kSU0fajyLsf63cjrJeRWUlhLCBtaB+vIh6u267OhuSjXfRhYzk4kSq6suGuObqLCDd0dlYboGa325VvCUzL/Kq4qERRUEiWlWiLY/G+klv4kTuO1dIaO0x3yoiRm5MNcwNxBYBJY4Mb2hBCymhD9Pii6azcAMSQdw9WBD2LYbUO6dIbXxEh07D9Dq9KXVlZCLNZZvpR7UpLJ/hFLPsmlvAWXWkbOj9+uJiqjquIIgKoyZ3xlW3tY1Jp0vyzZuTAlP5kxYjNJg2Wh4pKqXwJIXi3BTQ4IjgybU+k9w== X-YMail-OSG: 1TJdnxgVM1m4HwTcZbb24yIgwZUOQix31ThO0RXZ5sQlXgvtCIweisj5K8LfTNo PZ93rdupDEr20gljd7piOJjzOn88Lgir1TjoPbdVZZfjGecgMi.mUYnPcuW0KhLJZm5M2lJKV95n W_YyP6fYjjvw0LRLjG6uXqXq4SP.VUVzlSFLwIJ_orJiZiQmk9FEuCvwzePIUSLqwD6fSe35qrB3 6Io0KM90cg3vUkuFwSqUM6BAzEKDcfvO8VKlksqcKHeMYZZvyuALWxjRYWl46hj.L325Gqc9caBs N1mhTK69JzByoM97P5a.E9C1GbaYUNRr7ILQXm2vI_HdfVUK_KbrNHZ6OBMEPmNwmyMBAxuFc2RV 2V2.HYxiHWxJ6QXvMMdXZv3PVttLclRNaPgZv0QPvadp1Om8UZeX7ew1.G3U4kqH7LdYj2_IuRW. J23pp0YEyxqhSsH30d4C3rhthVXQNX_BUw8h7XfiNH5OuocFuQb7ZhIcbG.4LYeQnyKV6Wria1l3 63lrvF1o4DfNkkJ_PH9a_gQvwpZj60tXearVmiUs5oiabw3ZH6Ctw5HUmb8Et4tctDudz..UoPxX kSr3js.cYlgOGlqV1ezNY31rbkoWIrTjmaPZiNTHR3dVDHH5JBHIOD3JCB.h4I8OvW7JnxS_wKi4 pG1M83vlmnaup9L2Lch_8DHa9h9vFD.n4qJVFGKj3TwByrn4xPyWO2kW49IeKulOMk8D__GsFUj5 ondQyUVb_twLQTjJsMrh5H8.V1HCkpyzA0QI5G3fbZUQYrqWj8SjUr1QWsUBMylME.qeQtHn_d7S zfanXanfSrDDd63bDUwS0tZUZKV9ltagdpIvakn8KXAmrCYfyj2G4UOgi0sblWi4U2Qyyyb4MPk8 fvyXfACZw0ZfuPB5XCwBFrBnmNPlJggc4mv7BMTSy4Ua8kl6LhW9O3ZCABgR3cbtEFz9wwNQhtQs eBW3jATDEPWWBLInXZkSje5P9NfkXfCSOtVA5Cbvm0gsqGiz4Ol9zcUMhCDHxa2ccm6qWHq4Hfkb GS5X_WKxMS49s1gcFxlitVIVD.9yhJczWWq2cSiuMaiKNgYrzqd1f5Ecbq33RQVn7gSrCMg6uNcc KpNRlOJZQCYhHAh7MXSmQMPDcwh5qbyjZnmM2xmoC3T0p6aI_rlE7NkdYRQ5kV2QD4zSqtDckySL gCx6r381xgBWXsLpkpUrdqa9rnI4Nhxc7a8fRg2ippjqmdreoowFhLl3bgKandzGHpex3ud4Ay4K 8SXQTa01hzKeBx1BL2gEG5HOlnoKfjowxw.2XJ7yx1T0GjlKDsjHmfYO8kW6pvBG8QIcb1YqtOFa _anSgrU.Vhf_o6ANXaQkbzUHOBPHSb5W5DNCKyQgQl7qcikzZpNOoMUSohVi5S2WH6tMEZyjF44b 3j9QlRdfehU10luuIEcfbLfZHY6hLAwsOfM8smuEH4pQ4yX6R_OB2gjLD.WgpcvkvRO_LAyzxsRB ceoL6cWsPi4Dnp2SCa8xaTuKkmkeiHW093AvW.A8Tmr10rmIJU990ANf_2ebyVVSmsdRekMmUd_z eq1U1xHM.l6Z0Eyqc03jQ5.c6NTTO77OeWj1ADR1xuA.AtDesXPQ0FH9bLEpFjIGbfgM6qzRmDAO a.QrjJRzG958zdpMU5fZwJ8PizS2e.tBjaZ55kmt4c7.n1EI24gsROe4mhsoyT0rfuLuSBoBgyfn SobFrVtfaT0PGOPPh5bMR4WxuHqBIo9GYJRd.laAueujtAAw0jyBs9Q3aM_FqXBaQRoY1dQLtN2l 1QM8lyk.pgwbIdzM3VA50Cvz.N9T6ppkfHwInrMnOlPQjlSLTFF9yF.5CgvCRE7tTWstz.5tCpJP Tm4wgPU7QgqgS8x8KUpmUACxu0CCpQmFypOhwgNFkSSYDbX5l6lBgpZf4aKlqBJjAaXTBhv.37_. W5dlgvlcIl1qQpnkz1CDmXRtKsanDz_b_GMrCYOQ2xoIkQeuraABNcoGU8E8JB82cMJRAWW0KugC d5uOetKR2VyqbCm4fgSJ_M3Pkh9u9Dlrp16QXt6vabGoiOVhxtMBmxIHwkRqBfBGc5T8e5seVLhg yZHlMs5No.k4jzT88.eJD7d2wqj028J0hWUNw9LwaDorf_8SHyRZs96O1BLWUs7ezJhbwZAMA0SN TNSaynGucwZjUzp6zvt9v.pmO3J5otdiN45nn_RctKs6Mg2E4mw21yoPkxcACUkSE5Ax_N5yLQ7E Kr6DlFjGNPXxCcidn0Ank70xp5HhmWbWBwapCt.nAoO.uAPoniGRtLG2bZ3w4d1AUNQSBrlIwaNI W X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 18:20:45 +0000 Received: by hermes--production-gq1-6597fd5bbd-mr9bp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0c82a48ded9b52dadad77d8de34e1215; Sun, 22 Jan 2023 18:20:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <159467120.7.1674396707299@mailrelay> Date: Sun, 22 Jan 2023 10:20:32 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <05B1F338-6FE8-444F-AF05-55884FDEB8B3@yahoo.com> References: <159467120.7.1674396707299@mailrelay> To: Ronald Klop X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P0M401PFpz3RHs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 22, 2023, at 06:11, Ronald Klop wrote: >=20 >=20 > Van: Mark Millard > Datum: zondag, 22 januari 2023 05:41 > Aan: freebsd-current > Onderwerp: An idea for swap partition size vs. swap space size in use = handling > I have boot media that are each set up to boot a variety > of systems that have widely different RAM sizes, from > 1 GiBytes to 64 GiBytes for the aarch64 examples of this. >=20 > This has lead to having multiple swap partitions of > various sizes so that I can have total swap spaces that > are somewhat under the recommended maximum sizes for the > amount of RAM in each of those systems that a given media > can boot. >=20 > It would be nice if I could have just one swap partition > on a given boot media, one that is more than sufficient > in size for all but the biggest RAM system --but to then > be able to tell the system to just use up to the > recommended swap space size and to ignore any extra swap > space in the swap partition. >=20 > If such could be done, I'd no longer use multiple swap > partitions at the same time in order to get to a desired > total for the system at hand at the time. >=20 > Of course, that still leaves what to do when multiple > swap partitions are enabled if such a "ignore what > would be extra" mode was also enabled. As I'd not use > such, I've no specific recommendations to make that > would make any difference to my use. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 > =C3=82=20 >=20 >=20 > Hi Mark, >=20 > Do you mean you would like to be able to add a "size" parameter to the = fstab swap line? >=20 > /dev/da0p1 none swap sw,size=3D1g 0 = 0 No. That would use 1g for even the 64 GiByte RAM system when I move the media to that 64 GiByte system and boot it --and similarly as I move the media from system to system in general. For my style of use, I want the swap to be (a lower bound approximation of) the recommended figure for the amount of RAM for the specific system the media is currently use in. That means that the figure changes when I move the media to a system with a different amount of RAM. > Another option I can think of is using the "gnop" geom provider. It = has a -s parameter to set the size. I classically use a label based path to identify the swap partition, not a device name. This fits with the variations in what system I'm booting and what other devices might be around. (Some of the media involved here are USB media.) Labels go at the end of partitions, as I remember. This would appear to make forms of resizing or subranging the partition also mean adjusting the labeling. That is something I'd like to avoid. I'd also like to avoid needing to provide my own lower bound approximation of the recommended figure for the live amount of RAM. For one, it is platform dependent, for example armv7 and aarch64 are very different for the same amount of RAM. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 22 18:37:00 2023 X-Original-To: freebsd-current@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 4P0MQy5M5bz3NMlD for ; Sun, 22 Jan 2023 18:37:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 4P0MQx4rWrz3lQM for ; Sun, 22 Jan 2023 18:37:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UOyiP+n1; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 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=1674412632; bh=b3trekWk83MVGlm7Acj1F9UcuTa2/pvVWAFVkoZelFM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UOyiP+n1fHP4mf9KdiFNTYdP0aYznIsxA7tYYVtyRM1YWSfGa1h0Bug8lMupa1TGbCa1ooAsSYXgTi40fYfiv0VoKizPGpfLVsaIuhrFnulHb0/4+rH4n2Z/c/4t/bRFowa2NaOTLGwwusv8cd8mQyK5Ld5BWOIysTNJAjn34vjEd9ICAvj4Td95dxfhLAdoaNO79Jnxkc9d3E2OfENOB1dV1U1Wokf+nHMl7ZI8ENclZ1yzAiNKmn7OcmkE1Ox8n0o5VsXXRH6xt4msf9/tgh/at0LICIPu8/ZNHZF4JaHJV+CTxaqmiPI7AGSNjr0ZrBDmK0HMYFqLRvxQdk/9/Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674412632; bh=jam46B4CU5J4QwJJM51EiYCCX3RqLwoZjNjnJYP+A7g=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Ki3QMMaGUSGDR4nov+WOaqTzW1llYPlqmLKsNIxHG8ik+zViFPWQkjie+57Z7Rb90waBDlsYK0p1TQbXERoJQqsJB4HVS6tgCCPkEn87zqA6ECdBXLRPAXxtJNAs7sSe4e1p7Rn2CWwbPT6QwAK5ZEAvpHlxeWKzoEeRHeWNphYi/oU2pOVK4HzapmoR4Vw4bl91Uvi4JCQTEl43i7HQ3bGF4gvIp4NB8JTTlSpeRhaob1jHkTZXnq0sNMUwf6SBranqBP/2LSsIHbls272yvq0eEiY/LFsIoHo0KLc4kitBZi/w2N3FV7RQHiJkJzPENkScPk1QKR+1+x1KSYOtig== X-YMail-OSG: d18dqP0VM1mS619tdrCLDQjdyvoGfVsznDvd7UWB2kYJaJj3_2Tit4EeXxBKlKX AQKL_ZRlO_XPlmZWNxn_OqkkY7ccQzjfav6Q0wDz6YyzCq0WWWm_IINSX64z5wLox6MTuCTiqegu TOVoe56oNR7zEdeU71bmgocmM2zdlm3R14ymIdXR46uuRTfW2v0jkL_YPl1peR42XQ5rsVkKx9DY l8punjV3oWeQW61bAHVBvdY.X35FTLquhPZVxOJn1ji2KI9Z9ELGljwUgi0zKgVwNrtWQ6VQjrvh .RScT0hbvL7EFDRjypRhNVcJN5MV0I1q2iva0uP3RTiEhwlWcugTZXiwp8BY6shu7FB2JuijsWWe 31PdGtOAbIdUABGrYMfyieF.SKYzwap7qgDmLxLyjGSdDqKoXEhSZY27.RxllKmBKL8OGlo.HGdI FHH4vix2p3V8uLM46ScUXEfOxEKs4EJMsl6LXcXVCFGirwcC9BXYZi3b7bJht8ctbLJPvUnHsypV gHw5dIq93qCxMmteA00saE2GULxyzY4jmO9Hu.S2Hubk_f_NYvcF.bvKOh4GaDh09DonBGuBXE.p dTEtp.kq6CZWKPqzF00llg7hfUyxQ_5w3R2i0ajpq3QyK5wvUbBw8zbpiVIaxqROaXSGot7eH8Ur 2YQzl7KhoVX1cA3jS2WwPeSva7R51gEFRwQ96G74yky6hDXwhIWa_bmllHk99QakBfZFIyCvjcW9 j1oSMp0cEWxhOtTCSnQHE2NOAP_MGfdqE4gmj3nJ3twZQ_l5pf52FTphN4PX2GEdsDXEl7EOLRks 6C94TH_RXv9UJIQRScBhY3tthVGatf0gmOZUb_wVdS8OzaoM5ThO169ZYLGQtCt0naO9bFs6xhhx YxxNuZ3a1BaAReS8CWllkYIpuv50bC2kdhgFk8uDdT0F2WdfpXBxniwFnVL0PR5Ak0ONic25ghyE RNl2us9R8P39k7jQliuaNB7sUHW8X1uPhIetffFXHp5NUEYeB9XLxAEAORO1vTs0WtAz0tKzX8JC 2uBLIKLkDhpd7yIonPm760xwmnv9LnZepN6oCjNmN7uDVvBaEb.vj6uAvBKzZ2CXmXL06yBlhZE7 azPLyokQeLy23zIen27qJvIf5xxXUa2s1vhxUQesAhW0kK5IWD0_onI7lIKbmY0m4m8OPmk.dLHZ r4z0bOXEFBYZwJJfCieP.tTfX_4VsGX79NryLgB4OKOShFKqo11HysK9597xo92PZWmHQvC5KJJU QkOv2YeoF7TTPKfn3PFDKfo1ZMlqlBLeCb.FBQjbHh7JtY91pPZgBAAMTuVQmo2BDoXgrcFhsMUO nI06FeMpwMQXTu6OrtGT39mpp91jVtS7WltfVr9xdVQtyCCDdDeYMS7.6WYBpabWHQdRE.skrpWd 4pGCZeArN.PH6zwGQ11UXg7mWdYcfv6XuKtxsvM4IQPqF5bZx7BZmr8xkNYJ2KJLoejuV7zMMz19 OV38I8atPWsHhzhZVHTaVg815_fm3SzcmpEfPvdrsZyaxSQpKk0zkEYTvpm2C0qQpOMpyBuPQ7u3 VEILs285wpl6f.Y0vpc.g9_jh0CHnXh7tkVfhNECvfJPCF6owytgdDyrkUaGm9m4cOaHrzZe6RlO tkWCBJlldUl7rIs8Swov2m8083z7HZoza04VLAiOpuo99zEFPoBDRXfdAL6MJEaxyt0Br6V9ohDa GE98.b5kVZ4nafHirWepP65U0BbYhXd_DVSJK5din0Id_hEE3HanEWKjG9z.MdUDd6cZS17aCEVf Khvi.RlWNViJzJwndgScCROEvquHK1poV_etOAcHUZVWgT4k9WJw1oXvZGI.h731cuhizgUv_Eof TqtXoEWEpHBlb6CzzcQ9aJm8UF.Tg_CZ2Vsu7hOP04FS7V0P0Kor_rPjuHP1RjuvcP2gkTW7Qmh5 rY03KLsnVElWOQPc1.bFKVvN4usJz0IFbK.rUQrm3K22EqR3jKWNe1iYCSqfsFNkY4HhIH5IHFuf .oANcodGgQwwE2L6AZMt4Rldtb6ncUXLijHzfe3owlkLKqFp5yalw5PLQ7ZQ1jNc76Rh9LY2cg03 Jk9hYuoLzVk6UvFAA5.BhrYgWWrqHotW1jFC5kCgFUldkx1VaJKx99fEYO0.CeAyYelgEd8RPcwa .eay34MdBoIJ66QyiPwbHIbC5EvloIQ6TOdGVf54fTgRkphVC_ekcvgBy7AUkwhiQq6IlaPf5YIL cy0ZyRySX2FYIWi1y4RU._GHVCySri.ULTCjnEo4cCb4uJOI5g3NHthBwj1BsmMQiy_88o1wKKDd x8w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 18:37:12 +0000 Received: by hermes--production-gq1-6597fd5bbd-ljshm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 05efd5a40f31dc42675d523d6b2a6398; Sun, 22 Jan 2023 18:37:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard In-Reply-To: Date: Sun, 22 Jan 2023 10:37:00 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <202301220717.30M7H7wC022099@critter.freebsd.dk> <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> <960C016C-9D43-4F24-8913-363676B5E202@yahoo.com> <83FEEEDC-1880-4A7A-B5C9-312FB86D5826@karels.net> To: Mike Karels X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-2.75 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.25)[-0.248]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4P0MQx4rWrz3lQM X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Jan 22, 2023, at 09:46, Mark Millard wrote: >=20 >> On Jan 22, 2023, at 05:15, Mike Karels wrote: >>=20 >>> On 22 Jan 2023, at 2:42, Mark Millard wrote: >>>=20 >>>> On Jan 22, 2023, at 00:21, Mark Millard wrote: >>>>=20 >>>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp = wrote: >>>>>=20 >>>>>> -------- >>>>>> Mark Millard writes: >>>>>>=20 >>>>>>> It would be nice if I could have just one swap partition >>>>>>> on a given boot media, one that is more than sufficient >>>>>>> in size for all but the biggest RAM system --but to then >>>>>>> be able to tell the system to just use up to the >>>>>>> recommended swap space size and to ignore any extra swap >>>>>>> space in the swap partition. >>>=20 >>> Why not just reduce the size of the swap partition to the desired = size >>> with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual = intervention. >=20 > On Jan 22, 2023, at 05:15, Mike Karels wrote: >=20 >> On 22 Jan 2023, at 2:42, Mark Millard wrote: >>=20 >>> On Jan 22, 2023, at 00:21, Mark Millard wrote: >>>=20 >>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp = wrote: >>>>=20 >>>>> -------- >>>>> Mark Millard writes: >>>>>=20 >>>>>> It would be nice if I could have just one swap partition >>>>>> on a given boot media, one that is more than sufficient >>>>>> in size for all but the biggest RAM system --but to then >>>>>> be able to tell the system to just use up to the >>>>>> recommended swap space size and to ignore any extra swap >>>>>> space in the swap partition. >>=20 >> Why not just reduce the size of the swap partition to the desired = size >> with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual = intervention. >=20 > Why would I use the size for a 1 GiByte aarch64 system > (prior boot) when I'm using the media to boot the 64 > GiByte system? So increases too. Manual intervention > every time I move the media between systems, going in > both directions over time? >=20 > That gets me into the business of independently > calculating a reasonable lower bound for the recommended > swap space every time I move the media between systems > with differing amounts of RAM. I've noticed that the > recommendation varies some across the OS updates. (My > guess is variations in the kernel space use is involved > in the recommendation.) I'm looking for something > avoiding such a redundant calculation, something that > just works given the variability across OS updates. (And across platforms: armv7 and aarch64 have very different recommendations for the same amount of RAM. And across differing amounts of RAM from system to system.) Took a while for me to think of it, but there is also that I use paths based on labels to identify the swap partition independent of the system it is plugged into and what other devices are present in that system. (Some of the media here are USB media.) Resizing (or subranging) partitions invalidates labeling because the labeling information goes at the end of the (logical) partition, if I understand right. So labeling would have to be re-established for the new size as well. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 23 03:05:17 2023 X-Original-To: freebsd-current@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 4P0ZjP0N0cz3b93q for ; Mon, 23 Jan 2023 03:05:29 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) (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 4P0ZjM6y7gz3RFR for ; Mon, 23 Jan 2023 03:05:27 +0000 (UTC) (envelope-from qroxana@protonmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b="A3/iI2P5"; spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.40.137 as permitted sender) smtp.mailfrom=qroxana@protonmail.com; dmarc=pass (policy=quarantine) header.from=protonmail.com Date: Mon, 23 Jan 2023 03:05:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1674443125; x=1674702325; bh=sVEG5SuyL0l1JvD/TAQejPDr1fSM/XR7wIJfFsudBe8=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=A3/iI2P5ctwvQ+SYIZAUyWjHGRJKFHFTueKxTBN9pSnMW05NsdS10zqTSG+2NB8Fu b4L+oosbCB5WHu2DXB3cTG2Y099xy+WNH8JAx+9Cu8GIs0tn2ov1TwPSq4abspUXXY cNPxcobPFcxUCmWmnbeTsiLg58EcbildDEpvdCI9yO0FvCZ6tStyqdhpvpWIw1FR9R JntSt6/8G29NkJVhZS+MrUQp87xpRaP3Jqns9un41GG/F+l5MxNFfya3q5p8+KquP/ YeCA2Cc+HSpXshYzjyLoDSbHT9DfaDYtiyls7C4YZpCQoOIStK9s1j4BrOI7fK5V8+ 30JhwD5MdZ9Dg== To: "freebsd-current@freebsd.org" From: qroxana Subject: buildworld failed after deleting /usr/obj Message-ID: <7cKQCx9PEwnnJE5MatS6g5KkKh5prIZTrTlqGL2RfM7Z4TDJGCfEATg9ejghBWDhx7WqDtVpxAA6wEisDAP2Y6c8g-ht2KbUW4YN0eek43g=@protonmail.com> Feedback-ID: 29996633:user:proton List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_L9b6AhhVzITajSq0r8cUQbyfbW4aMvE1oteCFiC8wc" X-Spamd-Result: default: False [-2.51 / 15.00]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.61)[-0.605]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.137:from] X-Rspamd-Queue-Id: 4P0ZjM6y7gz3RFR X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_L9b6AhhVzITajSq0r8cUQbyfbW4aMvE1oteCFiC8wc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SXQgc2VlbXMgJHtNQUtFT0JKRElSfSB3YXMgbm90IGNyZWF0ZWQgZm9yIHVzci5iaW4vY2xhbmcv bGx2bS1vYmpjb3B5LgoKLS0tIGFsbF9zdWJkaXJfdXNyLmJpbiAtLS0KLS0tIG9iandhcm4gLS0t Cldhcm5pbmc6IE9iamVjdCBkaXJlY3Rvcnkgbm90IGNoYW5nZWQgZnJvbSBvcmlnaW5hbCAvdXNy L3NyYy91c3IuYmluL2NsYW5nL2xsdm0tb2JqY29weQotLS0gQ09GRi9DT0ZGT2JqY29weS5vIC0t LQpjKysgLXRhcmdldCBhYXJjaDY0LXVua25vd24tZnJlZWJzZDE0LjAgLS1zeXNyb290PS91c3Iv b2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAgLUIvdXNyL29iai91c3Ivc3JjL2FybTY0LmFh cmNoNjQvdG1wL3Vzci9iaW4gLU8yIC1waXBlIC1mbm8tY29tbW9uIC1JL3Vzci9zcmMvdXNyLmJp bi9jbGFuZy9sbHZtLW9iamNvcHkgLUkvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9sbHZt L3Rvb2xzL2xsdm0tb2JqY29weSAtSS91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9saWIv Y2xhbmcvbGlibGx2bSAtSS91c3Ivc3JjL2xpYi9jbGFuZy9pbmNsdWRlIC1JL3Vzci9zcmMvY29u dHJpYi9sbHZtLXByb2plY3QvbGx2bS9pbmNsdWRlIC1EX19TVERDX0NPTlNUQU5UX01BQ1JPUyAt RF9fU1REQ19GT1JNQVRfTUFDUk9TIC1EX19TVERDX0xJTUlUX01BQ1JPUyAtREhBVkVfVkNTX1ZF UlNJT05fSU5DIC1ETExWTV9ERUZBVUxUX1RBUkdFVF9UUklQTEU9XCJhYXJjaDY0LXVua25vd24t ZnJlZWJzZDE0LjBcIiAtRExMVk1fSE9TVF9UUklQTEU9XCJhYXJjaDY0LXVua25vd24tZnJlZWJz ZDE0LjBcIiAtRERFRkFVTFRfU1lTUk9PVD1cIlwiIC1ETExWTV9UQVJHRVRfRU5BQkxFX0FBUkNI NjQgLURMTFZNX1RBUkdFVF9FTkFCTEVfQVJNIC1ETExWTV9UQVJHRVRfRU5BQkxFX1BPV0VSUEMg LURMTFZNX1RBUkdFVF9FTkFCTEVfUklTQ1YgLURMTFZNX1RBUkdFVF9FTkFCTEVfWDg2IC1ETExW TV9OQVRJVkVfQVNNUEFSU0VSPUxMVk1Jbml0aWFsaXplQUFyY2g2NEFzbVBhcnNlciAtRExMVk1f TkFUSVZFX0FTTVBSSU5URVI9TExWTUluaXRpYWxpemVBQXJjaDY0QXNtUHJpbnRlciAtRExMVk1f TkFUSVZFX0RJU0FTU0VNQkxFUj1MTFZNSW5pdGlhbGl6ZUFBcmNoNjREaXNhc3NlbWJsZXIgLURM TFZNX05BVElWRV9UQVJHRVQ9TExWTUluaXRpYWxpemVBQXJjaDY0VGFyZ2V0IC1ETExWTV9OQVRJ VkVfVEFSR0VUSU5GTz1MTFZNSW5pdGlhbGl6ZUFBcmNoNjRUYXJnZXRJbmZvIC1ETExWTV9OQVRJ VkVfVEFSR0VUTUM9TExWTUluaXRpYWxpemVBQXJjaDY0VGFyZ2V0TUMgLWZmdW5jdGlvbi1zZWN0 aW9ucyAtZmRhdGEtc2VjdGlvbnMgLWdsaW5lLXRhYmxlcy1vbmx5IC1NRCAtTUYuZGVwZW5kLkNP RkZfQ09GRk9iamNvcHkubyAtTVRDT0ZGL0NPRkZPYmpjb3B5Lm8gLVduby1mb3JtYXQtemVyby1s ZW5ndGggLWZzdGFjay1wcm90ZWN0b3Itc3Ryb25nIC1XZGF0ZS10aW1lIC1Xbm8tZW1wdHktYm9k eSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXVudXNlZC1jb25zdC12YXJpYWJsZSAtV25vLWVy cm9yPXVudXNlZC1idXQtc2V0LXZhcmlhYmxlIC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVdu by11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5j dGlvbiAtV25vLWVudW0tY29udmVyc2lvbiAtV25vLXVudXNlZC1sb2NhbC10eXBlZGVmIC1Xbm8t YWRkcmVzcy1vZi1wYWNrZWQtbWVtYmVyIC1Xbm8tc3dpdGNoIC1Xbm8tc3dpdGNoLWVudW0gLVdu by1rbnItcHJvbW90ZWQtcGFyYW1ldGVyIC1Xbm8tcGFyZW50aGVzZXMgLVF1bnVzZWQtYXJndW1l bnRzIC1mbm8tZXhjZXB0aW9ucyAtZm5vLXJ0dGkgLXN0ZD1jKysxNCAtc3RkbGliPWxpYmMrKyAt V25vLWMrKzExLWV4dGVuc2lvbnMgLWMgL3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2plY3QvbGx2 bS90b29scy9sbHZtLW9iamNvcHkvQ09GRi9DT0ZGT2JqY29weS5jcHAgLW8gQ09GRi9DT0ZGT2Jq Y29weS5vCi0tLSBhbGxfc3ViZGlyX3Rlc3RzIC0tLQotLS0gb2Jqd2FybiAtLS0KV2FybmluZzog T2JqZWN0IGRpcmVjdG9yeSBub3QgY2hhbmdlZCBmcm9tIG9yaWdpbmFsIC91c3Ivc3JjL3Rlc3Rz L3N5cy9mcy9mdXNlZnMKLS0tIGJtYXAgLS0tCihjZCAvdXNyL3NyYy90ZXN0cy9zeXMvZnMvZnVz ZWZzICYmIERFUEVOREZJTEU9LmRlcGVuZC5ibWFwIE5PX1NVQkRJUj0xIG1ha2UgLWYgTWFrZWZp bGUgX1JFQ1VSU0lOR19QUk9HUz10IFBST0c9Ym1hcCBQUk9HX0NYWD1ibWFwKQotLS0gYWxsX3N1 YmRpcl91c3Iuc2JpbiAtLS0KLS0tIGFsbF9zdWJkaXJfdXNyLnNiaW4vYnNubXBkL21vZHVsZXMv c25tcF9taWJJSSAtLS0KPT09PiB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX21pYklJIChh bGwpCi0tLSBhbGxfc3ViZGlyX3Vzci5iaW4gLS0tCmVycm9yOiB1bmFibGUgdG8gb3BlbiBvdXRw dXQgZmlsZSAnQ09GRi9DT0ZGT2JqY29weS5vJzogJ05vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnkn CjEgZXJyb3IgZ2VuZXJhdGVkLgotLS0gYWxsX3N1YmRpcl90ZXN0cyAtLS0KCm1ha2VbM106IHN0 b3BwZWQgaW4gL3Vzci9zcmMKLS0tIGFsbF9zdWJkaXJfdXNyLnNiaW4gLS0tCgptYWtlWzNdOiBz dG9wcGVkIGluIC91c3Ivc3JjCi0tLSBhbGxfc3ViZGlyX3Vzci5iaW4gLS0tCgptYWtlWzNdOiBz dG9wcGVkIGluIC91c3Ivc3JjCi0tLSBhbGxfc3ViZGlyX2xpYiAtLS0KCm1ha2VbM106IHN0b3Bw ZWQgaW4gL3Vzci9zcmMKMzI5LjMxIHJlYWwgMjQ0LjYyIHVzZXIgNTQuNDkgc3lzCgptYWtlWzJd OiBzdG9wcGVkIGluIC91c3Ivc3JjCgptYWtlWzFdOiBzdG9wcGVkIGluIC91c3Ivc3Jjcg== --b1_L9b6AhhVzITajSq0r8cUQbyfbW4aMvE1oteCFiC8wc Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5JdCBzZWVt cyAkezxzcGFuPk1BS0VPQkpESVI8L3NwYW4+fSB3YXMgbm90IGNyZWF0ZWQgZm9yIHVzci5iaW4v Y2xhbmcvbGx2bS1vYmpjb3B5Ljxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJp YWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj4NCjxkaXYgY2xhc3M9InByb3Rvbm1haWxf c2lnbmF0dXJlX2Jsb2NrIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0 cHg7Ij4NCiAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11c2VyIHBy b3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLWVtcHR5Ij4NCiAgICAgICAgDQogICAgICAgICAgICA8 L2Rpdj4NCiAgICANCiAgICAgICAgICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJl X2Jsb2NrLXByb3RvbiI+PHNwYW4+LS0tIGFsbF9zdWJkaXJfdXNyLmJpbiAtLS08L3NwYW4+PGRp dj48c3Bhbj4tLS0gb2Jqd2FybiAtLS08L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5XYXJuaW5nOiBP YmplY3QgZGlyZWN0b3J5IG5vdCBjaGFuZ2VkIGZyb20gb3JpZ2luYWwgL3Vzci9zcmMvdXNyLmJp bi9jbGFuZy9sbHZtLW9iamNvcHk8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4tLS0gQ09GRi9DT0ZG T2JqY29weS5vIC0tLTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPmMrKyAmbmJzcDstdGFyZ2V0IGFh cmNoNjQtdW5rbm93bi1mcmVlYnNkMTQuMCAtLXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy9hcm02 NC5hYXJjaDY0L3RtcCAtQi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvdXNyL2Jp biAmbmJzcDstTzIgLXBpcGUgLWZuby1jb21tb24gLUkvdXNyL3NyYy91c3IuYmluL2NsYW5nL2xs dm0tb2JqY29weSAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2xsdm0vdG9vbHMvbGx2 bS1vYmpjb3B5IC1JL3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L2xpYi9jbGFuZy9saWJs bHZtIC1JL3Vzci9zcmMvbGliL2NsYW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9jb250cmliL2xsdm0t cHJvamVjdC9sbHZtL2luY2x1ZGUgLURfX1NURENfQ09OU1RBTlRfTUFDUk9TIC1EX19TVERDX0ZP Uk1BVF9NQUNST1MgLURfX1NURENfTElNSVRfTUFDUk9TIC1ESEFWRV9WQ1NfVkVSU0lPTl9JTkMg LURMTFZNX0RFRkFVTFRfVEFSR0VUX1RSSVBMRT1cImFhcmNoNjQtdW5rbm93bi1mcmVlYnNkMTQu MFwiIC1ETExWTV9IT1NUX1RSSVBMRT1cImFhcmNoNjQtdW5rbm93bi1mcmVlYnNkMTQuMFwiIC1E REVGQVVMVF9TWVNST09UPVwiXCIgLURMTFZNX1RBUkdFVF9FTkFCTEVfQUFSQ0g2NCAtRExMVk1f VEFSR0VUX0VOQUJMRV9BUk0gLURMTFZNX1RBUkdFVF9FTkFCTEVfUE9XRVJQQyAtRExMVk1fVEFS R0VUX0VOQUJMRV9SSVNDViAtRExMVk1fVEFSR0VUX0VOQUJMRV9YODYgLURMTFZNX05BVElWRV9B U01QQVJTRVI9TExWTUluaXRpYWxpemVBQXJjaDY0QXNtUGFyc2VyIC1ETExWTV9OQVRJVkVfQVNN UFJJTlRFUj1MTFZNSW5pdGlhbGl6ZUFBcmNoNjRBc21QcmludGVyIC1ETExWTV9OQVRJVkVfRElT QVNTRU1CTEVSPUxMVk1Jbml0aWFsaXplQUFyY2g2NERpc2Fzc2VtYmxlciAtRExMVk1fTkFUSVZF X1RBUkdFVD1MTFZNSW5pdGlhbGl6ZUFBcmNoNjRUYXJnZXQgLURMTFZNX05BVElWRV9UQVJHRVRJ TkZPPUxMVk1Jbml0aWFsaXplQUFyY2g2NFRhcmdldEluZm8gLURMTFZNX05BVElWRV9UQVJHRVRN Qz1MTFZNSW5pdGlhbGl6ZUFBcmNoNjRUYXJnZXRNQyAtZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0 YS1zZWN0aW9ucyAtZ2xpbmUtdGFibGVzLW9ubHkgLU1EIC1NRi5kZXBlbmQuQ09GRl9DT0ZGT2Jq Y29weS5vIC1NVENPRkYvQ09GRk9iamNvcHkubyAtV25vLWZvcm1hdC16ZXJvLWxlbmd0aCAtZnN0 YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdkYXRlLXRpbWUgLVduby1lbXB0eS1ib2R5IC1Xbm8tc3Ry aW5nLXBsdXMtaW50IC1Xbm8tdW51c2VkLWNvbnN0LXZhcmlhYmxlIC1Xbm8tZXJyb3I9dW51c2Vk LWJ1dC1zZXQtdmFyaWFibGUgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12 YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8t ZW51bS1jb252ZXJzaW9uIC1Xbm8tdW51c2VkLWxvY2FsLXR5cGVkZWYgLVduby1hZGRyZXNzLW9m LXBhY2tlZC1tZW1iZXIgLVduby1zd2l0Y2ggLVduby1zd2l0Y2gtZW51bSAtV25vLWtuci1wcm9t b3RlZC1wYXJhbWV0ZXIgLVduby1wYXJlbnRoZXNlcyAtUXVudXNlZC1hcmd1bWVudHMgJm5ic3A7 LWZuby1leGNlcHRpb25zIC1mbm8tcnR0aSAtc3RkPWMrKzE0ICZuYnNwOyAmbmJzcDstc3RkbGli PWxpYmMrKyAtV25vLWMrKzExLWV4dGVuc2lvbnMgJm5ic3A7IC1jIC91c3Ivc3JjL2NvbnRyaWIv bGx2bS1wcm9qZWN0L2xsdm0vdG9vbHMvbGx2bS1vYmpjb3B5L0NPRkYvQ09GRk9iamNvcHkuY3Bw IC1vIENPRkYvQ09GRk9iamNvcHkubzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPi0tLSBhbGxfc3Vi ZGlyX3Rlc3RzIC0tLTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPi0tLSBvYmp3YXJuIC0tLTwvc3Bh bj48L2Rpdj48ZGl2PjxzcGFuPldhcm5pbmc6IE9iamVjdCBkaXJlY3Rvcnkgbm90IGNoYW5nZWQg ZnJvbSBvcmlnaW5hbCAvdXNyL3NyYy90ZXN0cy9zeXMvZnMvZnVzZWZzPC9zcGFuPjwvZGl2Pjxk aXY+PHNwYW4+LS0tIGJtYXAgLS0tPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+KGNkIC91c3Ivc3Jj L3Rlc3RzL3N5cy9mcy9mdXNlZnMgJmFtcDsmYW1wOyAmbmJzcDtERVBFTkRGSUxFPS5kZXBlbmQu Ym1hcCAmbmJzcDtOT19TVUJESVI9MSBtYWtlIC1mIE1ha2VmaWxlIF9SRUNVUlNJTkdfUFJPR1M9 dCAmbmJzcDtQUk9HPWJtYXAgUFJPR19DWFg9Ym1hcCk8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4t LS0gYWxsX3N1YmRpcl91c3Iuc2JpbiAtLS08L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4tLS0gYWxs X3N1YmRpcl91c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX21pYklJIC0tLTwvc3Bhbj48L2Rp dj48ZGl2PjxzcGFuPj09PSZndDsgdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9taWJJSSAo YWxsKTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPi0tLSBhbGxfc3ViZGlyX3Vzci5iaW4gLS0tPC9z cGFuPjwvZGl2PjxkaXY+PHNwYW4+ZXJyb3I6IHVuYWJsZSB0byBvcGVuIG91dHB1dCBmaWxlICdD T0ZGL0NPRkZPYmpjb3B5Lm8nOiAnTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSc8L3NwYW4+PC9k aXY+PGRpdj48c3Bhbj4xIGVycm9yIGdlbmVyYXRlZC48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4t LS0gYWxsX3N1YmRpcl90ZXN0cyAtLS08L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 c3Bhbj5tYWtlWzNdOiBzdG9wcGVkIGluIC91c3Ivc3JjPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+ LS0tIGFsbF9zdWJkaXJfdXNyLnNiaW4gLS0tPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+PHNwYW4+bWFrZVszXTogc3RvcHBlZCBpbiAvdXNyL3NyYzwvc3Bhbj48L2Rpdj48ZGl2Pjxz cGFuPi0tLSBhbGxfc3ViZGlyX3Vzci5iaW4gLS0tPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PHNwYW4+bWFrZVszXTogc3RvcHBlZCBpbiAvdXNyL3NyYzwvc3Bhbj48L2Rpdj48ZGl2 PjxzcGFuPi0tLSBhbGxfc3ViZGlyX2xpYiAtLS08L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj48c3Bhbj5tYWtlWzNdOiBzdG9wcGVkIGluIC91c3Ivc3JjPC9zcGFuPjwvZGl2PjxkaXY+ PHNwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMzI5LjMxIHJlYWwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgMjQ0LjYyIHVzZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7NTQuNDkgc3lzPC9zcGFu PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+bWFrZVsyXTogc3RvcHBlZCBpbiAvdXNy L3NyYzwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPm1ha2VbMV06IHN0b3Bw ZWQgaW4gL3Vzci9zcmM8L3NwYW4+PC9kaXY+PHNwYW4+cjwvc3Bhbj48YnI+PC9kaXY+DQo8L2Rp dj4NCg== --b1_L9b6AhhVzITajSq0r8cUQbyfbW4aMvE1oteCFiC8wc-- From nobody Mon Jan 23 10:02:46 2023 X-Original-To: freebsd-current@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 4P0lzD1y9Zz3b8jT for ; Mon, 23 Jan 2023 10:03:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P0lzD1WWCz4CjZ; Mon, 23 Jan 2023 10:03:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674468184; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m12IrPH54aryP0hrqvyYJP0sceYs3vs1BmHMJ7urqkc=; b=h+t7ahc+mtXOngqTv9i8GTxWSVdfo12YYSSQRF5tsTR2BN66V7FcFGYFXDJeqkEXf6aOj3 Q3dhdBm/Mdw4XMNUXCBjQnpBw1Sfl/wgHBTnFu6y7OsHvnbDDLdltAmW84ELHM7+SPk3t+ O4BmD4d9E6eKv64rgd6lLy1QtDa4AbUexsoYGiUbaA1QuUIRiXj6XMj6mfts+WCwzgqwOD eUtMudhOtlcK4QVIM4F2JWzj/7dSYbF2AQBC/G7wj4Imo6F9//vDGH1DbRLfNEu7xJ7N3f NrW0egwpV+g2eqWTAJqJT3JnTeAsZ3bGYYrdMD+jIigQYAcnhnMipgpsiPG3BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674468184; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m12IrPH54aryP0hrqvyYJP0sceYs3vs1BmHMJ7urqkc=; b=f8ezpHK9oyES3+Jl0hsyfqz15+cCa4IDf5sczCJmYIY0NpvYAWcy/xTnobUQA5mfPxOeJ7 OLInd7DxPhLLNXxiBqg7o3GipSRYVwj25D08q2ZXVuqj9mmIa429XcJBBVGCktX8tWskGU s5+0De/FLHTCSY5fR03323/9l/YId3uWFziMypctscSeTR69h0wVzMitIXi3XKdbpy1/yY sMt8m5Vilvvo1lJlPa2lwrhhF5SpoGR1FXySGLnhuQ2O07aZz2i6xJ6gNye2j6mSNNN+KX fRh2JKRVVbaiXe1aj/ovFVxJ7Ju30uTy+7G1k4hkYc/Y31Pxtx1iqcSzlaUihg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674468184; a=rsa-sha256; cv=none; b=nBFqxbFKxMj9TXXRCTNOchw2zHTM/ormE8bAAH6IYNnUNXm+crFDmaN71URtUrfsb5V1HL YZWTy33ed6xg17kPl5qBqcDmU06IpnW0GG7kEwxiwa5l0JWaMVzyz5y6U1gomcFUKBD1II a9FvSgT7Qvy5iZ6zAOzUdSDF9uAgnlemKnWgsBK6sSI1gGMGWXfWFU36LzfZ/P6oJb6ffm Hf3G70LMwdUbRInkqXJ7x15DgOl5zOWj3FeXi69ogvS44w/6ORvmVhJvZn8IGvLGt9Tmnk murGb62uMM0TEclOWe6EkkESUgjYJX+U9dsMknX2CGcuy8dhAFC39BiKavb83w== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4P0lzC6yQVz1Cmp; Mon, 23 Jan 2023 10:03:03 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AB5946210D; Mon, 23 Jan 2023 11:03:02 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_D319272C-751A-42F5-A738-B1AFBAB46F68"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: buildworld failed after deleting /usr/obj From: Dimitry Andric In-Reply-To: <7cKQCx9PEwnnJE5MatS6g5KkKh5prIZTrTlqGL2RfM7Z4TDJGCfEATg9ejghBWDhx7WqDtVpxAA6wEisDAP2Y6c8g-ht2KbUW4YN0eek43g=@protonmail.com> Date: Mon, 23 Jan 2023 11:02:46 +0100 Cc: "freebsd-current@freebsd.org" Message-Id: <3CCFF1C8-D618-453F-8412-3D65F551C43C@FreeBSD.org> References: <7cKQCx9PEwnnJE5MatS6g5KkKh5prIZTrTlqGL2RfM7Z4TDJGCfEATg9ejghBWDhx7WqDtVpxAA6wEisDAP2Y6c8g-ht2KbUW4YN0eek43g=@protonmail.com> To: qroxana X-Mailer: Apple Mail (2.3731.300.101.1.3) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_D319272C-751A-42F5-A738-B1AFBAB46F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Jan 2023, at 04:05, qroxana wrote: >=20 > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy. >=20 > --- all_subdir_usr.bin --- > --- objwarn --- > Warning: Object directory not changed from original = /usr/src/usr.bin/clang/llvm-objcopy This is usually an indication that your source directory contains object files, e.g. is "dirty". Run "make clean" from the top level, or clean up your source checkout with something like "git clean". -Dimitry --Apple-Mail=_D319272C-751A-42F5-A738-B1AFBAB46F68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCY85bRgAKCRCwXqMKLiCW o0i2AKDa1hnwivYH8fKc1+h4wwQkNTLp6ACfWQQ05o60SBcTKvwszEO5F3yqk1U= =HYCB -----END PGP SIGNATURE----- --Apple-Mail=_D319272C-751A-42F5-A738-B1AFBAB46F68-- From nobody Mon Jan 23 13:44:25 2023 X-Original-To: freebsd-current@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 4P0rts5N4Zz2t3vx for ; Mon, 23 Jan 2023 13:44:37 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) (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 4P0rts2Xkhz3PDx; Mon, 23 Jan 2023 13:44:37 +0000 (UTC) (envelope-from qroxana@protonmail.com) Authentication-Results: mx1.freebsd.org; none Date: Mon, 23 Jan 2023 13:44:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1674481475; x=1674740675; bh=eKyVmRXWmKq5pB3l0fQcuLCS1GX5oGlIcyv2GOHDqGU=; 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=p4svo9FZQeUuEYmn7/tk28tvdd5BAUKHc2M8RAkX1o2a1CQRb7YAry5DyNbU5flPn sqjdChGutgc2MxYa9h9Ru0cme42qr1tmLWrSsEnCXzg7rCr+LA1u49f8+hB6byp54/ oxbBld9f57kTU+R/qJcvtKciOIRTcsO+8Zv62YUQFPcqwmP7vwfCT36VfW6YAHxrO9 JvuehNvUE+GPbdb4sP+3iu0r1R6VR3nD+F1xrIiRSDB6+aAouglvwjnYuJj05vlL1L EHA1ZPsFEEY/dIaYxDcBGsvbDFjkwGE4pFGJsoVM+dAlF0zgzcdr85Qit6Kr3E2g0X z6dMBmcqoclfg== To: Dimitry Andric From: qroxana Cc: "freebsd-current@freebsd.org" Subject: Re: buildworld failed after deleting /usr/obj Message-ID: In-Reply-To: <3CCFF1C8-D618-453F-8412-3D65F551C43C@FreeBSD.org> References: <7cKQCx9PEwnnJE5MatS6g5KkKh5prIZTrTlqGL2RfM7Z4TDJGCfEATg9ejghBWDhx7WqDtVpxAA6wEisDAP2Y6c8g-ht2KbUW4YN0eek43g=@protonmail.com> <3CCFF1C8-D618-453F-8412-3D65F551C43C@FreeBSD.org> Feedback-ID: 29996633:user:proton List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4P0rts2Xkhz3PDx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N ------- Original Message ------- On Monday, January 23rd, 2023 at 10:02 AM, Dimitry Andric = wrote: > On 23 Jan 2023, at 04:05, qroxana qroxana@protonmail.com wrote: >=20 > > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy. > >=20 > > --- all_subdir_usr.bin --- > > --- objwarn --- > > Warning: Object directory not changed from original /usr/src/usr.bin/cl= ang/llvm-objcopy >=20 >=20 > This is usually an indication that your source directory contains object > files, e.g. is "dirty". Run "make clean" from the top level, or clean up > your source checkout with something like "git clean". >=20 > -Dimitry I had tried it with a clean source directory and empty /usr/obj # find /usr/src/usr.bin/clang/llvm-objcopy /usr/src/usr.bin/clang/llvm-objcopy /usr/src/usr.bin/clang/llvm-objcopy/llvm-objcopy.1 /usr/src/usr.bin/clang/llvm-objcopy/Makefile and "make buildworld" still ended with the same error. In /usr/src/Makefile.inc1, the _NO_INCLUDE_COMPILERMK=3Dt option prevents c= reating the obj directories for the stuff in usr.bin/clang/. 1098 _obj: 1099 @echo 1100 @echo "----------------------------------------------------= ----------" 1101 @echo ">>> stage 2.2: rebuilding the object tree" 1102 @echo "----------------------------------------------------= ----------" 1103 ${_+_}cd ${.CURDIR}; ${WMAKE} _NO_INCLUDE_COMPILERMK=3Dt ob= j > --- all_subdir_usr.bin --- > --- objwarn --- > Warning: Object directory not changed from original /usr/src/usr.bin/clan= g/llvm-objcopy This happens in stage 4.4, and there's no ${MAKEOBJDIR} directory created= =20 for usr.bin/clang/llvm-objcopy From nobody Wed Jan 25 23:34:18 2023 X-Original-To: freebsd-current@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 4P2KtL2vDRz3bn2r; Wed, 25 Jan 2023 23:34:18 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P2KtL1xRyz4JXb; Wed, 25 Jan 2023 23:34:18 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674689658; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s+b1IDJwrBhAD/HexYFAHOcN+juSI+cmVtxpKcW9cjQ=; b=CbgDhZ5lNe4U4z0+sQBEhfvZyDq23oMqlG4d3Q30ucj+Smai30aFN9GK6vwut9+USKsJRt qLK4o4TmVOUCfHGR90chbwBjzlojqE4AHQrUlgkH9zCOVQb+iREnVd5zKWapYCk7FMlxTw 7AmGtEwijhOIX98cfEMXFoUmWJVLIZ/AbTgUi1lt26Sd853FNG9QW3a1w3p+HlmJb00rjp y5toaefRi8tObEuUWKncUytz+xSSHx8K74pXQaxswX9VR/BVEAF9JnqyVWKr5qL/4WD6+C BbcV61DW4YCtQ8ooElejJUQpYLT2vgXkxHNGPfBCnqYbKgJZ7OuqTqxjbtkUCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674689658; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s+b1IDJwrBhAD/HexYFAHOcN+juSI+cmVtxpKcW9cjQ=; b=mVeusdtEtNTECdqV9qEMFYrBuqq+UZPwnwjuQmgAC1IC0vFqGQw5wDfXhoWnWoEilLLnnz iBrGUwEc2R8krIuq2sNERRG5YzCl633IgWId8zWffnzOsgwllgqFOxqU+0cWSunHWKksJn sKlsxtrql4A8FpBWr4/5K7JZMMQICvyKsNpQHOQSvSyDBOAm1zNKoQ4RDAD/jPWukzfcp7 bylaSmXu5QXWyvDTQe4lsKdbmmebN0XEfuujxOjie+69uhyY5BB5o8plh43aBOfpsRgpq2 F7tHASF08A+kBVD5URmPma081xyQ+ItBT37qFjBaKVHwsh+Coo5gPRhpnmNNnQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674689658; a=rsa-sha256; cv=none; b=UGR38/LNH44L5fy3YNZEczLvficNeRJugKDaz+ossii6Rv9DBcNPNinAtXWi6a5+R80LXc MYprimCPy8Nj90lrxoiCvgZu1qFoooA6cIZmAU63e6hnQfE66fmfsacG2t5wb9wizdY/I1 9IjwjRczWCqgwqG/zl7ZcQzvsHrIo/JN++cJzlwaD2c8ginfZ8vGhz/gfX7Sq2m1Udmgcj RGJhh7Ux22XYhMwGebasNkqmlJnT+6PKJ94S6GVfE5HcsK1G/SRdYKKWfpw1fhYlS2o9Mj 6uWBtvvKeeSCo42Jpe6l7zDRvi2amHqfrvRtcIIiLVv0FtpTpdRh7x1oCaR73Q== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 22A1E9F3D; Wed, 25 Jan 2023 23:34:18 +0000 (UTC) Date: Wed, 25 Jan 2023 23:34:18 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Fourth Quarter 2022 Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N FreeBSD Status Report Fourth Quarter 2022 The New Year has started and here is the last status report of 2022, including 34 reports. You will also notice that for the first time a new category has been introduced: the Cloud category. As FreeBSD keeps up to date with the latest technologies in IT, projects dealing with the cloud make steady improvements, and thus it has been judged that they deserve their own category in the status reports. The new category is not the only change about status reports. Indeed, the status team is revisiting its own workflow to become more efficient. If you are a report submitter, please ensure to read carefully the report authored by the status team as well as the next Call for Reports emails to keep up with the most recent changes. Have a nice read. Lorenzo Salvadore, on behalf of the status team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2022-10-2022-12/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection □ Status reports: New workflow • Projects □ Console screen reader infrastructure □ Vessel - Integrated Application Containers for FreeBSD □ Enable the NFS server to run in a vnet prison □ Pytest support for the FreeBSD testing framework • Userland □ Base System OpenSSH Update • Kernel □ Enabling Snapshots on Filesystems Using Journaled Soft Updates □ Wireless updates □ Netlink on FreeBSD □ Adding basic CTF support to ddb • Architectures □ CheriBSD 22.12 release □ FreeBSD/riscv64 Improvements □ go on FreeBSD riscv64 □ FreeBSD/ARM64 on Xen • Cloud □ FreeBSD on Microsoft HyperV and Azure □ FreeBSD as a Tier 1 cloud-init Platform □ OpenStack on FreeBSD • Documentation □ Documentation Engineering Team □ FreeBSD Presentations and Papers • Ports □ FreshPorts - help wanted □ PortsDB: Program that imports the ports tree into an SQLite database □ KDE on FreeBSD □ Xfce on FreeBSD □ Pantheon desktop on FreeBSD □ Budgie desktop on FreeBSD □ GCC on FreeBSD □ Another milestone for biology ports • Third Party Projects □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Items Core Team Charter A delegation of the current core team is working together with some members of the previous Core Team to draft a core team charter. There was a face-to-face meeting in the US on December 3 - 4 to discuss the new charter. The delegation will present to the rest of the core team and discuss the details in the first quarter of 2023. The same delegation also had a meeting with the FreeBSD Foundation board on December 5th to discuss the collaboration details. Experimental Matrix IM solution The core team is working on evaluating Matrix as an instant messaging tool for the project. This will make the project’s communication channels less dependant on third parties. The service will be made available to the FreeBSD community to test and evaluate its validity at a later date. Committer’s Guide Deprecate BSD-2-Clause-FreeBSD and use BSD-2-Clause. For more information please refer to the commit. Commit bits • Core approved the src commit bit for Zhenlei Huang (zlei@) • Core approved the src commit bit for Corvin Köhne (corvink@) • Core approved the src commit bit for Sumit Saxon (ssaxena@) • Core approved the restore of the source commit bit for Paweł Jakub Dawidek (pjd@). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://www.freebsdfoundation.org Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://www.freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://www.freebsdfoundation.org/journal/ Foundation News and Events URL: https://www.freebsdfoundation.org/news-and-events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donations from individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to improve and maintain FreeBSD infrastructure, and provide resources to improve security, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilitate collaboration between commercial vendors and FreeBSD developers, and finally, represent the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Fundraising Efforts Thank you to everyone who made a financial contribution in 2022! We’re still tallying up the totals and will have final numbers soon. Unfortunately, we did not meet our fundraising goal, which reinforced our need of having someone who can focus on encouraging organizations to invest in FreeBSD. We will bring someone on board soon to help with that effort. In this Quarterly Status report you’ll read about many of the areas we funded in Q4 to improve FreeBSD and advocate for the Project (the two main areas we spend money on). Check out reports on the internally and externally funded projects like Openstack on FreeBSD, Enabling Snapshots on Filesystems Using Journaled Soft Updates, FreeBSD as a Tier 1 cloud-init Platform, and FreeBSD/ riscv64 Improvements. In addition, we provided tons of community engagement and education opportunities virtually and in-person! If you want to help us continue our efforts, please consider making a donation towards our 2023 fundraising campaign! https://www.freebsdfoundation.org/donate/ We also have a Partnership Program for larger commercial donors. You can read about it at https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/. OS Improvements During the last quarter of 2022, 218 src, 45 ports, and 12 doc tree commits identified the Foundation as a sponsor. Work was committed under Foundation sponsorship to repositories outside of FreeBSD as well, e.g., to the cloud-init project. Some of this sponsored work is described in separate report entries: • FreeBSD as a Tier 1 cloud-init Platform • OpenStack on FreeBSD project update • Wireless Report • Enabling Snapshots on Filesystems Using Journaled Soft Updates Other Foundation work in the src tree included: • a variety of additions and fixes from Konstantin Belousov including commits to the virtual memory system (e.g., ec201dd, cd08669, and d537d1f), and file systems (e.g., 37aea26, 83aff0f, 860399e, and 4d903a1) • work from Andrew Turner on arm64 such as an implementation of per-superpage locks and the addition of support for an array of hwresets • more RISC-V improvements from Mitchell Horne, including improvements to parsing of ISA property strings, optimizations to memory allocation, and various documentation additions and improvements • follow-up commits to Mark Johnston’s work to add ZFS Support to makefs(8) (e.g., work to easily provide ZFS-based VM and cloud images and automation for better defaults from Li-Wen Hsu) • a variety of work from Ed Maste, including an ssh update and a switch to LLVM objdump. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects to improve continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. You can read about the latest activity for that work in a separate report entry. FreeBSD Advocacy and Education Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature and video tutorials, attending events, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We are continuing to attend events both in person and virtual as well as planning the November Vendor Summit. In addition to attending and planning virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: • Sponsored the OpenZFS Developer Summit, October 24-25, 2022 in San Francisco, CA • Sponsored All Things Open, October 30-November 2, 2022 in Raleigh, NC • Sponsored and helped organize the November 2022 FreeBSD Vendor Summit. Videos from the Summit are available. • Held a new FreeBSD Friday: An Introduction to FreeBSD Services by Drew Gurkowski • Published the Fall and Winter Newsletter updates • New Blog Posts □ Meet the 2022 FreeBSD Google Summer of Code Students: Koichi Imai □ Meet the 2022 FreeBSD Google Summer of Code Students: Bojan Novković □ Keeping FreeBSD Secure: Learn the Whys and Hows with the FreeBSD Sec Team □ The FreeBSD Journal is still Free! □ EuroBSDCon 2022 Trip Report: Muhammad Moinur Rahman □ EuroBSDCon 2022 Trip Report: Patrick McEvoy □ Fall Foundation Software Development Update □ Invest in FreeBSD □ 2022 in Review: Advocacy □ Foundation Sponsors Update to WireGuard Kernel Port for FreeBSD □ 2022 in Review: Fundraising Update □ 2022 in Review: Software Development □ 2022 in Review: Continuous Integration and Quality Assurance Update • FreeBSD in the news: □ Ampere: Getting Cloud-Native with FreeBSD on OCI Ampere A1 with Terraform □ FreeBSD is Well Supported on 4th Gen AMD EPYC™ Processors • For a quick review of all the Foundation efforts in 2022, check out our 2022 Thank You Video. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https://www.freebsdfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.freebsdfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://www.freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 12.4-RELEASE schedule URL: https://www.freebsd.org/releases/12.4R/schedule/ FreeBSD 12.4-RELEASE announcement URL: https://www.freebsd.org/releases/12.4R/announce/ FreeBSD 13.2-RELEASE schedule URL: https://www.freebsd.org/releases/13.2R/schedule/ FreeBSD 14.0-RELEASE schedule URL: https://www.freebsd.org/releases/14.0R/schedule/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the fourth quarter of 2022, the Release Engineering Team completed work on the 12.4-RELEASE cycle. This is the final release from the stable/12 branch. During the release cycle, only one BETA build and two RC (release candidate) builds were needed; overall the release cycle went very smoothly and the release took place on December 5th. During the fourth quarter of 2022, the Release Engineering Team continued providing weekly development snapshot builds for the main, stable/13, and stable/12 branches. In the first quarter of 2023, the Release Engineering Team will start work on the upcoming 13.2-RELEASE. Sponsors: Rubicon Communications, LLC ("Netgate") The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications. In this quarter, the team has worked on the following: • Regular cluster-wide software upgrades Two full upgrades to fix and prevent some impacting issues (FreeBSD-EN-22:25.tcp and FreeBSD-EN-22:28.heimdal). • Regular support for FreeBSD.org user accounts • Regular disk and parts support (and replacement) for all physical hosts and mirrors. • Site audit at our primary site □ Inventory of spares and other miscellanea occupying space in our cabinets. □ Inventory of PDUs/power outlet usage and identifying faulty PSUs. • Identify and fix major DNS issue impacting the project The primary DNS servers hosted on HE.net suffered outages for a few days, and new DNS servers were deployed worldwide. We thank our sponsor Metapeer for providing anycast infrastructure. • Deploy a new mirror in Frankfurt, Germany A replacement for our mirror in Amsterdam (site decommissioned). Former and new mirror hosted and sponsored by Equinix. • Reuse parts of three broken CI machines No replacements for these at this moment, awaiting a cluster refresh soon. • Work with the PowerPC team to improve the PowerPC cluster machines □ Parts like mainboard, NVMe and Power 9 CPU bought through the FreeBSD Foundation. □ Former package builder fixed, and re-deployed as powerpc and powerpc64 package builder. □ Former devref machine reinstalled as a new powerpc64le package builder. □ The cluster has now only these two PowerPC machines in operation. • Several rounds to free up disk space usage in the cluster machines • Setup of an experimental search engine for the mailing lists: https://lists.freebsd.org/search • Fix a bug in the mailing lists archiver, which resulted in some broken links All mailing lists archives have been regenerated. Work in progress: • Large-scale network upgrade at our primary site New Juniper switches arrived at our primary site to replace the former ones. We thank Juniper for the donation. • Replace old servers in our primary site and a few mirrors Besides the broken CI servers, we have a few old servers with broken disks and faulty PSUs. This task is in conjunction with the FreeBSD Foundation and donors/sponsors. • Create a new database for the mailing list search engine to allow searching for mail in the archives from mailman’s time FreeBSD Official Mirrors Overview: Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Taiwan, United Kingdom (full mirror site), United States of America (California, New Jersey [the primary site], and Washington). The hardware and network connection have been generously provided by: • Bytemark Hosting • Cloud and SDN Laboratory at BroadBand Tower, Inc • Department of Computer Science, National Yang Ming Chiao Tung University • Equinix • Internet Association of Australia • Internet Systems Consortium • INX-ZA • KDDI Web Communications Inc • Malaysian Research & Education Network • Metapeer • New York Internet • Nic.br • Your.org The Frankfurt single server mirror is now the primary Europe mirror in bandwidth and usage. We are still looking for an additional full mirror site (five servers) in Europe to replace old servers in the United Kingdom full mirror site. We see a good pattern in having single mirrors in Internet Exchange Points worldwide (Australia, Brazil, and South Africa); if you know or work for some of them that could sponsor a single mirror server, please get in touch. United States (West Coast) and Europe (anywhere) are preferable places. See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD Jenkins wiki URL: https://wiki.FreeBSD.org/Jenkins Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI 3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the FreeBSD project. The CI system checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the code or adjust test infrastructure. During the fourth quarter of 2022, we continued working with the contributors and developers in the project to fulfill their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important completed tasks: • FreeBSD-main-amd64-gcc9_build now sends failing reports to the committers whose commits may be related. • FreeBSD-main-amd64-gcc12_build has been added. • FreeBSD-main-powerpc64-images now also builds bootable APM disk image for Apple G5 baremetal and QEMU -M mac99 (by alfredo@) Work in progress tasks: • Designing and implementing pre-commit CI building and testing (to support the workflow working group) • Designing and implementing use of CI cluster to build release artifacts as release engineering does • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Organizing the scripts in freebsd-ci repository to prepare for merging to src repository • Improving the hardware test lab and adding more hardware for testing Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Planning to run ztest tests • Adding more external toolchain related jobs • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don’t hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/ Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages (through its subsidiary pkgmgr), and personnel matters. Below is what happened in the last quarter. Currently we have just over 31,000 ports in the Ports Tree. There are currently close to 2900 open ports PRs of which almost 800 are unassigned. The last quarter saw 8194 commits by 159 committers on the main branch and 657 commits by 53 committers on the 2022Q4 branch. Compared to the quarter before, this means a small increase in the number of available ports but also in the number of open PRs and a decreasing number of commits made. On the personnel front, we welcomed Ronald Klop (ronald@) and said goodbye to bar@ and bhughes@. We welcomed pizzamig@ as a new official member after a successful lurking period. We also welcomed three new lurkers: bofh@, ler@, and ygy@. Portmgr split itself up into portmgr and pkgmgr. The new pkgmgr team, currently consisting of antoine@ and bdrewery@, is responsible for building packages and maintaining the package building cluster. Four new USES were introduced: • llvm to canonicalize ports dependencies on LLVM • luajit to select a LuaJIT runtime • octave to help ports depend on Octave and Octave-Forge • tex to define dependencies on TeX and its various components. The following default versions were bumped: • Firebird to 3.0 • GCC to 12 • Lazarus to 2.2.4 • Lua to 5.4 • PHP to 8.1 • Samba to 4.13 • Varnish to 6 • LuaJIT is new and set at "luajit-openresty" for PowerPC64 and "luajit-devel" for all other architectures. Three new features were introduced, PIE, RELRO, and BIND_NOW. Each port can opt out of them by setting the _UNSAFE variable. Users can activate or deactivate them globally by setting WITH_ or WITHOUT_. The following major ports were updated to new versions: • Chromium 108.0.5359.124 • Electron 18.3.11, 19.0.15, and 21.2.0 • Firefox 108.0.1 • Firefox-ESR 102.6.0 • gcc 12 • KDE Plasma 5.24.7, Frameworks 5.101.0, Applications 22.12.0 • Qt 5.15.7 and 6.4.1 • Rust 1.66.0 • SDL 2.26.1 • Sway 1.8 • wlroots 0.16.1 • Wine 7.0.1. The exp-run reports are available again. During the last quarter, antoine@ ran 38 exp-runs to: • test port updates • change default versions • identify use of IPPROTO_DIVERT in ports • support PF_DIVERT in Python for FreeBSD 14. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Status reports: New workflow Links: FreeBSD status reports URL: https://www.freebsd.org/status/ Status reports GitHub repository URL: https://github.com/freebsd/freebsd-quarterly Contact: Goals of the new workflow This quarter the status team has been discussing with doceng@ some improvements to its workflow. In particular, the team is attempting to merge its GitHub repository into the FreeBSD doc/ repository. Here are the reasons for such a change: • having two independent repositories requires spending some time to make sure that both are in sync, which is being done manually. See for example commits such as https://github.com/freebsd/freebsd-quarterly/commit/4b8255e604dd0513e841aa8f3dce7741e78b999c, which are not immediately clear in their commit messages about what is being done unless more time is invested to copy commit messages properly; • the FreeSD doc/ repository is self-hosted, while the status repository is hosted on GitHub. Since the contents of the self-hosted repository are mirrored, nothing is being lost in visibility with the repository merging. Some inconsistencies about the name of the team have also been found: the team has been referred to as "quarterly", "quarterly status team", "status", "status team", "monthly" etc. So this issue is also being addressed. Please note that we are still working on these changes and that they might not be completed within the next quarter. The status team will take care to keep all information about report submissions up to date so that you always know how to submit your reports. Team naming Since "quarterly" might refer to quarterly reports but also to quarterly branches, using "quarterly" only could cause some confusion in some contexts. "quarterly-status" is likely a bad idea as well, as the frequency of reports publication might need to change in the future. Thus just "status" has been chosen: this is correct as quarterly status reports contain information about the status of the development of FreeBSD, it is frequency-agnostic and consistent with its FreeBSD website section. The following email addresses have been created: • the main contact address for the status team is now . Mails sent to quarterly@FreeBSD.org will still reach the team, but you are encouraged to use the new address; • the email address for the status report submissions is now < status-submissions@FreeBSD.org>. Mails sent to quarterly-submissions@FreeBSD.org will still reach the team, but you are encouraged to use the new address; • the quarterly-calls mailing list has been renamed to status-calls. If you were already subscribed to quarterly-calls, you do not need to resubscribe. Report submission Three different ways to submit reports will be provided: • submitting a review on Phabricator. A new Phabricator group called "status" has been created. If you would like to give a hand to the team by reviewing reports we suggest you add yourself to the group 'watchers'; • submitting a pull request at https://github.com/freebsd/freebsd-doc/pulls; • sending an email to status-submissions@FreeBSD.org. Reviewing processes will proceed as they usually do on each of these channels. Other changes • The repository merging will require reworking some of the existing tools to better integrate with the existent structure of the FreeBSD doc/ repository. • The status reports GitHub repository will be archived once the new workflow implementation is completed. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Console screen reader infrastructure Links: console speaker daemon URL: https://reviews.freebsd.org/D35776 kernel support for console screen reader URL: https://reviews.freebsd.org/D35754 base system accessibility wishlist URL: https://wiki.freebsd.org/Accessibility/Wishlist/Base Contact: Hans Petter Selasky Contact: FreeBSD accessibility discussions This project aims at providing a very basic screen reader usable in console mode (without a GUI) for FreeBSD. This is an important first step for system administrators using speech to access computers, who previously would have needed a second computer running a terminal emulator to install or configure a FreeBSD server or character-based desktop computer. The third and fourth quarters of 2022 saw basic design and some feature testing which looks promising, and a detailed call for testing with installation procedure posted. This project needs help with the following: • Code reviewing • Usability testing • Integrating with the FreeBSD installer. Sponsor: NVIDIA Networking (for the kernel development part) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Vessel - Integrated Application Containers for FreeBSD Links: Vessel URL: https://github.com/ssteidl/vessel Contact: Shane Steidley What is Vessel? The goal of vessel is to expose the many powerful features of FreeBSD to application developers. Vessel accomplishes this goal by: • Providing a "Docker-like" interface familiar to most application developers for building, running, publishing and pulling container images. • Tightly integrating with FreeBSD system level interfaces (kqueue process tracing, signal handling, devd.seqpacket, rctl, cpuset) to manage running jails. How is Vessel different from other jail management systems? There are some awesome jail management systems already. These existing systems do a great job of configuring the jail runtime environment (ZFS dataset, networking, resource control, etc). After the environment is configured though, it is just handed off to the jail program via an exec call. In addition to jail configuration and creation, Vessel aims to take the next step and implement an event loop to manage jails based on system events. An instance of vessel runs alongside each jail to assist with management. This allows "Fat Jails" and single process jails to run in the foreground and be managed by the vessel-supervisor. Why make Vessel? Vessel has been a side project for a few years. I initially started it because it was a fun hobby project and I was surprised something similar did not already exist. It has now become a viable tool that I use for all of my projects. I believe it will be useful to others as well. Is help needed? Help is always appreciated. It’s a fun project to work on because it can touch on so many portions of FreeBSD. • Just using it and reporting any bugs on GitHub would be very useful. • Whatever sounds fun. I’m happy to help get people started. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Enable the NFS server to run in a vnet prison Links: Source patch for main URL: https://people.freebsd.org/~rmacklem/vnet.patch Simple Setup Doc URL: https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.txt Contact: Rick Macklem Several users of FreeBSD identified a need to run the NFS server inside a vnet prison. This turned into a small project, where I now have a patch that does this. It is currently available at the above link for testing or on Phabricator as D37519. Without this patch, the NFS server cannot be run in a prison. Not included in the above patch is the ability to run the rpc.tlsservd(8) and nfsuserd(8) daemons within the vnet prison. I do now have patches that allow these daemons to run in the vnet prison along with mountd(8) and nfsd(8), but I would like to get the above patch into main before adding support for rpc.tlsservd(8) or nfsuserd(8). At this time, the code needs reviewing and testing. Hopefully this can be completed in the next few weeks, so that the patch can be committed to main and possibly also MFC’d to stable/13. To do • Testing the above patch. • Reviewing the above patch. • Doing the same for the rpc.tlsservd(8) and nfsuserd(8) patches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Pytest support for the FreeBSD testing framework Links: Initial review URL: https://reviews.freebsd.org/D31084 Test examples URL: https://cgit.freebsd.org/src/tree/tests/examples/test_examples.py Contact: Alexander Chernikov Native pytest support for atf(7) enhances the capabilities of the FreeBSD test suite. Pytest simplifies test writing by reducing the amount of boiler-plate code. It offers several advantages over the existing atf-c and atf-shell bindings. One of the most important ones is the test parametrization, which allows improving coverage with writing nearly no code. The other is a rich assert system, offering detailed errors description. Python atf(7) support comes with a number of libraries that abstract a number of commonly-used tasks. For example, running a test within a VNET jail with epair(4) requires adding a single line of code. Such helpers are especially handy in the networking area, where tests with complex VNET setups are not uncommon. Current status Python support has been committed to HEAD. Currently, ~80 tests use the Python framework and the number is rising. Example tests have been committed to show the handling of the typical cases. Next steps • Work on increasing the adoption of the framework • Rewrite some of the older Python/shell tests in the netinet[6] to pytest (help is appreciated) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. Base System OpenSSH Update Links: OpenSSH URL: https://www.openssh.com/ OpenSSH 9.1 release notes URL: https://www.openssh.com/txt/release-9.1 Contact: Ed Maste OpenSSH, a suite of remote login and file transfer tools, was updated from version 9.0p1 to 9.1p1 in the FreeBSD base system. It has been merged to the stable branches, is available in FreeBSD 12.4, and will be in the upcoming FreeBSD 13.2. A number of bug fixes and minor improvements have been submitted upstream to OpenSSH, and this process will continue with subsequent updates. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. Enabling Snapshots on Filesystems Using Journaled Soft Updates Links: Milestone 1 Core Changes URL: https://reviews.freebsd.org/D36491 Contact: Kirk McKusick The goal of this project is to make UFS/FFS filesystem snapshots available when running with journaled soft updates. First a bit of background. Soft updates have been available for UFS/FFS since the mid 1990s. They eliminate the need for most synchronous disk writes and keep the state of the filesystem sufficiently consistent that it can be put back online after a crash without the need to run fsck(8). However, it may incorrectly assume that some of its blocks are still in use when in fact they are free. So, eventually it is necessary to take the filesystem offline to run fsck(8) to reclaim these lost blocks. The time to run fsck(8) is a function of the number of files in the filesystem and the size of the filesystem. Large filesystems may take hours to complete an fsck(8). Enabling journaling reduces the time spent by fsck(8) cleaning up a filesystem after a crash to a few seconds. With journaling, the time to recover after a crash is a function of the amount of activity in the filesystem in the minute before the crash. Journaled recovery time is usually only a few seconds and never exceeds a minute. The drawback to using journaling is that the writes to its log add an extra write load to the media containing the filesystem. Thus a write-intensive workload will have reduced throughput on a filesystem running with journaling. Like all journaling filesystems, the journal recovery will only fix issues known to the journal. Specifically if a media error occurs, the journal will not know about it and hence will not fix it. Thus when using journaling, it is still necessary to run a full fsck every few months or after a filesystem panic to check for and fix any errors brought on by media failure. A full fsck(8) is normally done on an offline filesystem. However, it can be done by running fsck(8) on a snapshot of a live filesystem. When running fsck (8) in the background on a live filesystem, the filesystem performance will be about half of normal during the time that the background fsck(8) is running. Running a full fsck on a UFS filesystem is the equivalent of running a scrub on a ZFS filesystem. The first milestone of this project has been completed. It is now possible to take snapshots when running with journaled soft updates and they can be used for doing background dumps on a live filesystem. The second milestone of this project is to extend fsck(8) to be able to do a background check using a snapshot on a filesystem running with journaled soft updates. This milestone is expected by Q3 of 2023. Sponsored by: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wireless updates Links: Bjoern’s Wireless Work In Progress landing page URL: https://people.freebsd.org/~bz/wireless/ Contact: Bjoern A. Zeeb During the quarter not much work was publicly visible and admittedly slightly slow. Behind the scenes wireless work was happening on two fronts: • 11n, 11ac, and wpa, • more drivers and firmware, problems, testing, and filling gaps for these. While the main development for newer standards and the Intel iwlwifi driver is sponsored by the FreeBSD Foundation, I find myself spending a lot of private time with Realtek rtw88 and rtw89, Atheros, and Mediatek mt76 (7921 and 7915) drivers now as well. Testing changes on bare metal and using bhyve VMs using passthru has become more time-consuming, with the amount of supported chipsets increasing, in order not to break other drivers. Even different (generations of) chipsets supported by the same driver, at times, behave differently with the same change. A separate discussion was brought to me about the size of firmware added to the tree for the already existing drivers and the firmware for more drivers coming. The chicken-egg problem to solve is having firmware available on the release media; without firmware, a lot of modern laptops will not have any sort of outside communications available at the time of install in their default configuration. This will be a larger discussion to have to also solve firmware for other drivers, but that discussion will be for another day and place. Slightly belatedly I have started to push LinuxKPI and 802.11 changes into the tree at the end of the year and that work will continue into early 2023 at which point more of the aforementioned remaining drivers will also hit the tree. One of the main remaining problems to solve is the firmware crashes on interface down/up cycles currently experienced with at least two drivers. Thankfully during the last weeks, after my call for help, multiple people have stood up wanting to help with various drivers (especially Realtek and Mediatek). I hope that after me catching up and pushing things out this can accelerate progress again. Thanks again to everyone doing testing, providing debug output, sending in feedback, or using the drivers at this point. For the latest state of the development, please use the freebsd-wireless mailing list, and check the landing page, which has links to all wiki pages for each driver status. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Netlink on FreeBSD Links: Initial review URL: https://reviews.freebsd.org/D36002 Netlink talk URL: https://static.ipfw.ru/files/netlink.pdf Contact: Alexander Chernikov Netlink is a communication protocol defined in RFC 3549. It is an async, TLV-based protocol, providing 1-1 and 1-many communications between kernel and userland. Netlink is currently used in the Linux kernel to modify, read and subscribe for nearly all networking states. Interface state, addresses, routes, firewall, rules, fibs, etc, are controlled via Netlink. Why is Netlink important for FreeBSD? POSIX defines an API for base functions/system calls. There is no such standard for the plethora of protocol/device-level/subsystem-level ioctls. Each subsystem/driver invents its own protocol, handling format and compatibility. Extendability is a notable problem in the networking control plane. For example, it is extremely hard to add properties to the routing socket messages without breaking compatibility. Netlink offers unification by providing a standard communication layer and basic easily-extendable message formatting. It can serve as a "broker", automatically combining requested data from different sources in a single request (example: interface state dump). Netlink APIs lower the bar for application developers to support FreeBSD, while providing the desired extendability. Current status Netlink has been committed to HEAD. The code implements a subset of the NETLINK_ROUTE subsystem and NETLINK_GENERIC framework. NETLINK_ROUTE supports add/delete/replace operations for routes, nexthops and link-level addresses. Partial support exists for the interface addresses and interfaces. Linuxulator support for Netlink has been committed to HEAD. It is possible to use the unmodified ip from iproute2 with routes, nexthops, addresses and interfaces. The simple userland library, snl(3), that provides convenient abstractions on the netlink socket, has been committed to HEAD. The first third-party software, BIRD, added experimental FreeBSD Netlink support. Next steps • Add Netlink to GENERIC • Make netstat/route/arp/ndp/ifconfig use Netlink interfaces (help is appreciated) • Add FreeBSD Netlink support to ports of FreeRangeRouting (FRRouting (FRR)). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Adding basic CTF support to ddb Links: Differential 1 URL: https://reviews.freebsd.org/D37898 Differential 2 URL: https://reviews.freebsd.org/D37899 Contact: Bojan Novković The goal of this project was to extend the ddb kernel debugger to use the kernel’s Compact C Type Format (CTF) data and use the newly added features to implement a pretty-printing command in ddb. Due to a restrictive execution environment (no IO or memory allocation), ddb can not use existing kernel linker methods to retrieve the kernel’s CTF data. Instead, the first patch adds the ability to load the kernel’s CTF data during boot and adds a new kernel linker method used for accessing CTF data from ddb. The second patch adds a basic interface for using CTF data in ddb and a pretty-printing command built using the newly added interfaces. Any feedback, comments, and reviews are welcome and would be greatly appreciated. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for the new hardware platform. CheriBSD 22.12 release Links: CheriBSD URL: https://www.cheribsd.org CheriBSD Announcements list URL: https://lists.cam.ac.uk/sympa/info/cl-cheribsd-announce Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: George Neville-Neil Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction-set extensions. There are two active architectural implementations of the CHERI protection model: CHERI-RISC-V and Arm’s Morello. A sketch of CHERI-x86 is also under development. CheriBSD is a research operating system with a stable baseline implementation into which various new research features have been, or are currently being, merged. We have published the 22.12 release of CheriBSD including: • A general update of the baseline FreeBSD OS to August 2022. • Memory-safe adaptation of Direct Rendering Manager (DRM) and Panfrost device driver, which enable a Morello-based desktop system using on-board GPU and HDMI. These drivers may be used with hybrid or pure-capability kernels. • An initial set of graphics and desktop CheriABI software packages such as Wayland and portions of KDE to get you up and running with a memory-safe desktop environment. These components remain under active development, and we anticipate continuing package updates after the CheriBSD release. • An early research prototype of library-based compartmentalization, which implements an alternative run-time linker running shared objects in libraries. This implementation is very much a work-in-progress, and is provided to enable research at other collaborator institutions needing easy access to the prototype. It is neither complete nor intended to be secure. • Improved pluggability of experimental heap temporal memory-safety support, which is not yet merged into the main development branch, but will now be easier to use by downloading an alternative kernel and heap allocator libraries provided by Microsoft. • An updated version of GDB with support for Morello instructions and inspecting memory tags. • Alpha support for ZFS file systems including support for boot environments. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD/riscv64 Improvements Links: Wiki Homepage URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. This quarter I resumed work on improvements to FreeBSD’s RISC-V architecture support (riscv64). Work was focused primarily on small bug-fixes and improvements, and tooling. A handful of known panics and bug reports were fixed and closed. On the performance tooling side, some issues with the use of DTrace on riscv64 were found and addressed. Specifically, backtraces produced by the stack() function were not being captured correctly. First, a change was made to the compiler flags to ensure that kernel modules always make use of the frame pointer, so that unwinding the kernel stack works as expected. Second, some tweaks were made to machine-dependent DTrace code in the profile and fbt providers, making the correct number of frames appear in each backtrace. Now, DTrace can be used to accurately capture profiling data on this platform, enabling the generation of flamegraphs. I also began porting the hwpmc(4) driver to run on this platform. Unlike other ISAs, RISC-V does not standardize the set of counter events that a CPU must support, nor are the programmable event selection registers accessible to the kernel. To work around this, there is an SBI "Performance Monitoring Unit" extension which provides an abstracted interface for managing such functionality. The new hwpmc(4) class is written to use this interface. Current generation RISC-V hardware supports incrementing performance counters, but lacks the counter overflow interrupts required to enable sampling PMCs. Work is expected to continue next quarter. Aside from the in-progress items mentioned, focus will be given to the following areas: • Support for newer OS-level extensions such as Page-Based Memory Types (Svpbmt) • Profiling system performance. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ go on FreeBSD riscv64 Links: golang Home Page URL: https://github.com/golang/go FreeBSD riscv64 github repo URL: https://github.com/MikaelUrankar/go/tree/freebsd_riscv64 FreeBSD riscv64 golang issue URL: https://github.com/golang/go/issues/53466 Contact: Mikaël Urankar Contact: Dmitri Goutnik The proposal to add support for FreeBSD riscv64 has been accepted and the patches merged. golang on FreeBSD riscv64 will be available in golang v1.20 (to be released in February 2023). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD/ARM64 on Xen Links: Xen Project URL: https://www.xenproject.org/ FreeBSD wiki page on Xen URL: https://wiki.freebsd.org/Xen Contact: Elliott Mitchell Xen is an open source hypervisor. Xen is one of the earliest hypervisors and has support for many OSes. Since FreeBSD 8.0, GENERIC FreeBSD/x86 has been able to run on Xen. Near the time FreeBSD was ported to run on Xen, work was started on running Xen on ARM. For a number of years Linux has run fine on Xen/ARM, but FreeBSD hasn’t been available. Having FreeBSD/ARM64 on Xen means any system capable of having Xen can also have FreeBSD in operation. Of note, the Raspberry PI 4B has hardware (GICv3) which Xen works with. If you’re okay with Linux handling the hardware, you can use all the hardware of a Raspberry PI 4B. In 2014 a proof of concept of running FreeBSD/ARM64 on Xen was done by Julien Grall, but this was never polished for release. During the past 2 years I’ve been working towards having this in FreeBSD’s tree, so released versions of FreeBSD/ARM64 would run on Xen. At this point all changes which need to be shared with the x86 Xen source code have been reviewed (not all reviews are on Phabricator). This now awaits testing by Roger Pau Monné before being committed to FreeBSD’s tree. I now urgently need someone with a high level of familiarity with the interrupt subsystem of FreeBSD on ARM64 to review (and commit) the ARM-specific portions. My builds are functional far more often than they fail, and most failures are temporary problems in FreeBSD’s tree. Some significant issues will need to be addressed regarding FreeBSD’s interrupt subsytem. There is substantial hope of having FreeBSD/ARM64 available for "DomU" (unprivileged) operation for FreeBSD 14.0. There is potential for FreeBSD/ARM and FreeBSD/RISC-V to run on Xen in short order. No plans currently exist for having FreeBSD/ARM64 operating as the controlling VM (someone could try to sponsor this). Thanks Thanks to Julien Grall for the Proof of Concept. Thanks to Roger Pau Monné for reviewing changes involving x86. Thanks to Mitchell Horne for helping with various FreeBSD/ ARM64 issues and addressing a key problem with FreeBSD/ARM64. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Li-Wen Hsu In this quarter, the 12.4-RELEASE image has been published to Azure Marketplace. Work in progress tasks: • Automating the image building and publishing process and merge to src/ release/. • Building and publishing ZFS-based images to Azure Marketplace □ All the required codes are merged to main branch, and can create ZFS-based images by specifying VMFS=zfs. □ Need to make the build process more automatic and collaborating with release engineering to start generating snapshots. • Building and publishing Hyper-V gen2 VM images to Azure Marketplace □ Blocked by https://bugs.freebsd.org/264267 The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft. Wei Hu and his colleagues in Microsoft are working on several tasks sponsored by Microsoft: • Fixing booting issue on Hyper-V gen2 VM in Azure □ https://bugs.freebsd.org/264267 • Porting Hyper-V guest support to aarch64 □ https://bugs.freebsd.org/266248 □ https://bugs.freebsd.org/267654 Open tasks: • Update FreeBSD related doc at https://docs.microsoft.com • Support FreeBSD in Azure Pipelines • Update Azure agent port to the latest version • Upstream local modifications of Azure agent Sponsor: Microsoft for work by Wei Hu and others in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD as a Tier 1 cloud-init Platform Links: cloud-init Website URL: https://cloud-init.io/ cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/ cloud-init ongoing refactorization URL: https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst Contact: Mina Galić cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init support for operating systems other than Linux is rather poor, and the lack of cloud-init support on FreeBSD is a hindrance to cloud providers who want to offer FreeBSD as a Tier 1 platform. To remedy the situation, this project aims to bring FreeBSD cloud-init support on par with Linux support. The broader plan is to lift support across all BSDs. The first milestone has been delivered. Along with many bug fixes, we now have merged an ifconfig(8) parser, which allows us to retrieve all the information of all network devices, similarly to how on Linux this is done by parsing the contents of /sys/class/net//. In the coming weeks, this project will align itself with the Azure developers to do some crucial refactoring. This will move our new parser further into cloud-init’s main execution paths. People interested in helping with the project can help with testing new features and fixes through net/cloud-init-devel, which will be updated whenever we make significant commits. Further, people with access to, and experience with, OpenBSD and NetBSD are also highly welcome to help. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenStack on FreeBSD Links: OpenStack URL: https://www.openstack.org OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd Contact: Chih-Hsin Chang Contact: Li-Wen Hsu OpenStack is an open-source cloud operating system for different resource types like virtual and bare-metal machines. Users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible to run the OpenStack control plane on FreeBSD hosts. This project aims to port key OpenStack components so that FreeBSD can function as an OpenStack host. In 2022 Q4, we have almost completed the porting work regarding the crucial OpenStack components. Most of the components/services composing an essential OpenStack cluster are now able to run on FreeBSD hosts, including: • Keystone (identity service) □ keystone server • Glance (image service) □ glance-api • Placement (resource tracking and inventory service) □ placement-api • Neutron (networking service) □ neutron-server □ neutron-metadata-agent □ neutron-dhcp-agent □ neutron-openvswitch-agent • Nova (compute service) □ nova-api □ nova-conductor □ nova-scheduler □ nova-compute □ nova-novncproxy The step-by-step documents for constructing a POC can be found in the docs repository. In its design, most of the OpenStack components provide an abstraction layer for the underlying implementations. For nova, we choose the combination of the libvirt driver with the bhyve virtualization type enabled. For neutron, it is the openvswitch mechanism driver. We solved several runtime dependencies and porting issues against the Libvirt, bhyve, and Open vSwitch combinations with minimal effort. We still have lots of work to undertake to make the changes back to OpenStack upstream. TODOs include: • Develop a proper alternative execution path in the oslo_privsep module for FreeBSD environments • Develop a new virtualization type, bhyve, for nova-compute’s libvirt driver • Develop the IP library for FreeBSD under neutron/agent/freebsd In the first few weeks of 2023, we will focus on breaking through the last mile of the instance spawn path and wrapping up the documentation regarding POC site construction. We will also try rebasing the porting work to the master branch of OpenStack (now Xena). People interested in helping with the project can first help check the documentation by following the installation guide. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Links: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/ Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter: • crees@ and zeising@ doc bits were taken in for safekeeping. Items pending and in the discussion: • A new document about licensing has been added to the documentation set. Porter’s Handbook: Two new USES knobs have been added to the Handbook: • New USES = luajit. • New USES = llvm. Also: • Erlang facilities have been documented • The new CABAL_REVISON knob has been documented. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate Link: FreeBSD Weblate Instance Q4 2022 Status • 12 languages • 150 registered users Languages • Chinese (Simplified) (zh-cn) (progress: 8%) • Chinese (Traditional) (zh-tw) (progress: 4%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 4%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 3%) • Portuguese (pt-br) (progress: 16%) • Spanish (es) (progress: 19%) • Turkish (tr) (progress: 2%) We want to thank everyone who contributed by translating or reviewing documents. And please, help promote this effort on your local user group; we always need more volunteers. FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work will be divided into four phases: 1. Redesign of the Documentation Portal Create a new design, responsive and with global search. (Complete) 2. Redesign of the Manual Pages on web Scripts to generate the HTML pages using mandoc. (Complete) Public instance on https://man-dev.FreeBSD.org 3. Redesign of the Ports page on web Ports scripts to create an applications portal. (Work in progress) 4. Redesign of the FreeBSD main website New design, responsive and dark theme. (Work in progress) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Presentations and Papers Links: FreeBSD Presentations and Papers URL: https://papers.FreeBSD.org Contact: Allan Jude Contact: Greg White Contact: Li-Wen Hsu Contact: Philip Paeps In this quarter, the presentations and papers from those events have been added: • BSDCan 2022 • EuroBSDCon 2022. Open tasks: • Find and upload missing FreeBSD related presentations and papers • Issues listed at Open Issues. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. FreshPorts - help wanted Links: FreshPorts URL: https://freshports.org/ FreshPorts blog URL: https://news.freshports.org/ Contact: Dan Langille FreshPorts and FreshSource have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port maintainers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of the acme.sh port, back to its creation in May 2017. Converting the backend repository This topic deals with the FreshPorts code repository. The front end (website) was converted from Subversion to Git several years ago. The back end, which processes FreeBSD commits and updates the database, is still on Subversion. I have wanted to convert these repositories to Git for some time. I would like help with this please. I’ll give you a copy of the repositories and you give me back several Git repos (one for each). They will be uploaded to https://github.com/FreshPorts (our project on GitHub). These are the existing Subversion repos: • ingress (code for the back end) • database schema • backend - monitoring code • packaging - scripts for cutting new tarballs - deprecated via Git • daemontools - now misnamed, because the scripts use daemon(8) • periodics - scripts started by periodic(8) • ports - for the FreeBSD packages which install the above. I won’t be running FreshPorts forever It’s been over 22 years and I know others must take over eventually. I’d like to start that process now. There are several aspects to FreshPorts: • FreeBSD admin (updating the OS and packages) • front end code (website - mostly PHP) • back end code (commit processing - Perl, Python, shell) • database design (PostgreSQL). The database does not change very often and requires little maintenance compared to the applications and OS. The website pretty much runs itself. From time to time, a change to the FreeBSD ports infrastructure breaks something or requires a modification, but there is rarely any urgency to fix that. This is not a huge time commitment. There is a lot of learning. While not a complex application, FreshPorts is also not trivial. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PortsDB: Program that imports the ports tree into an SQLite database Links: PortsDB URL: https://github.com/yurivict/freebsd-portsdb/ Contact: Yuri Victorovich I developed the PortsDB project that imports FreeBSD ports into an SQLite database. The port is ports-mgmt/portsdb. The database can be fully rebuilt in around 20 minutes, after which it can be quickly (in seconds) updated with new commits. The database is currently updated hourly: https://people.freebsd.org/~yuri/ports.sqlite. PortsDB can be used to query ports using SQL, as a relational database. External services like Repology, FreshPorts, Portscout, and other similar services can use PortsDB to access information in the ports tree. Users can, for example, easily find their broken ports, or port duplicates, or all ports that they maintain that use gmake, among many other possible queries. Such queries aren’t easy to perform by grepping the ports tree. Cross-DB queries are also easy to do. They can combine PortsDB, /var/db/pkg/ repo-FreeBSD.sqlite, and /var/db/pkg/local.sqlite. All that needs to be done to run PortsDB is ./import.sh, and then ./update.sh after more commits are pulled into the ports repository. The periodic script is provided that can simplify integration with cron. Multiple ready to use SQL queries are also included. One particular immediate problem that PortsDB aims to solve is to fix incorrect FreeBSD port versions displayed by Repology. Repology uses ports INDEX which is missing some required information. This leads to Repology not being able to distinguish between real versions, and intermediate and made-up versions. PortsDB should allow Repology to solve this problem. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ KDE on FreeBSD Links: KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. The notes below describe mostly ports for KDE, but also include items that are important for the entire desktop stack. Infrastructure • CMake ports now share a single version number. Various build-flags have been updated for FreeBSD ports builds: under some circumstances, release-flags were ignored and debug-flags applied, which is undesirable. CMake now also refuses to fetch remote sources during a ports build. • Qt versions are now Qt 5.15.7 (used by KDE) and Qt 6.4.1. Some applications in the ports tree are now "flavored" for Qt5 and Qt6. KDE Stack KDE Gear releases happen every quarter, KDE Plasma updates once a month, and KDE Frameworks have a new release every month as well. These (large) updates land shortly after their upstream release and are not listed separately. • KDE Frameworks 5 is now at version 5.101 (latest monthly release from December 2022). This is likely one of the last "Frameworks 5" releases, as the next major series comes closer. • KDE Gear is now version 22.12.0 (update for December 2022). • KDE Plasma is now version 5.24.7 (update for October 2022). Note that KDE Plasma 5.25 has been released upstream, but is still waiting on fixes before it can land in the ports tree (for example, this KActivityManager bug in KDE’s bug-tracker). Related Ports • graphics/krita is now version 5.1.3. • graphics/poppler was updated multiple times, now at version 22.11. It supports Qt5 and Qt6 through separate ports. • net-im/telegram-desktop was now supports Qt5 and Qt6 through flavors. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Xfce on FreeBSD Links: Xfce 4.18 Upstream Release Announcement URL: https://xfce.org/about/news/?post=1671062400 Xfce meta-port on FreshPorts URL: https://www.freshports.org/x11-wm/xfce4 Contact: Xfce team Contact: Guido Falsi The FreeBSD Xfce team (xfce@) works to ensure the Xfce desktop environment is maintained and fully functional on FreeBSD. This quarter the Xfce team members are pleased to welcome Xfce 4.18 to the FreeBSD ports tree! This new release includes many improvements in various parts of the environment, especially in the Thunar file manager. Also various upstream packages now include patches that were present in the ports tree. For further details, refer to the Xfce 4.18 Upstream Release Announcement. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Pantheon desktop on FreeBSD Links: elementary OS URL: https://elementary.io Development repository URL: https://codeberg.org/olivierd/freebsd-ports-elementary Contact: Olivier Duchateau The Pantheon desktop environment is designed for elementary OS. It builds on GNOME technologies (such as Mutter, GTK 3 and 4) and it is written in Vala. The goal is to have a new desktop for users. 13.1-RELEASE or higher is required, because several core components depend on deskutils/xdg-desktop-portal. The repository contains Mk/Uses framework elementary.mk, official applications, and curated ports which depend on x11-toolkits/granite. Since the previous report, we have been updating its related ports, especially: • deskutils/elementary-calendar update to 6.1.2 • deskutils/iconbrowser • graphics/elementary-photos • math/elementary-calculator • multimedia/elementary-videos • x11/elementary-terminal • x11-themes/gnome-icons-elementary • x11-toolkits/granite7. Power manager plugins for top panel (wingpanel) and control center (switchboard) are finished. A new switchboard plugin is also available, net/switchboard-plug-sharing. Ported Rygel, GNOME UPnP/DLNA services. Submitted other patches for low level libraries such as: • print/cups-pk-helper update to 0.2.7 required by print/ switchboard-plus-printers • devel/libgee update to 0.20.6 heavily used by the desktop • sysutils/polkit update to 122 (D37137) • sysutils/accountsservice update to 22.08.8 (D37679). Open tasks • Improve documentation. • Continue to work on user settings. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Budgie desktop on FreeBSD Links: Buddies of Budgie news URL: https://blog.buddiesofbudgie.org/ Development repository URL: https://codeberg.org/olivierd/freebsd-ports-budgie Contact: Olivier Duchateau Budgie initially developed as the default desktop environment for the former Evolve OS. Since the 10.6.x releases, improvements have been made to be "agnostic". It is built on top of GNOME technologies such as GTK >= 3, GLib, Mutter, libpeas. The goal is to have a new desktop for end users. I have submitted 2 reviews ( D37224 and D37286 for The FreeBSD Porter’s Handbook) so committers can import it. These reviews include: • Mk/Uses framework budgie.mk • new virtual category (budgie) • 6 applications • icon theme x11-themes/tela-icon-theme. During this quarter, I have also submitted several patches (related to this desktop) especially: • x11/gnome-terminal update to 3.44.2 bug #267928 • x11-wm/mutter update to 42.6 bug #267899 • x11-toolkits/libwnck3 update to 40.1 bug #267898. These bugs are also still open: • devel/libpeas bug #267420 • sysutils/gnome-settings-daemon bug #265107. Open task • Add support of LightDM in FreeBSD Handbook ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ Contact: Lorenzo Salvadore Update GCC default version to 12 Thank you very much to antoine@ for running the necessary exp-runs and to all the contributors, maintainers and committers involved in the process. As was noted last quarter, for every major version of GCC, FreeBSD usually awaits the release of the second minor version to update GCC default version. However next time I would like to attempt to update the default version as soon as the first minor version of GCC 13 is out. The rationale for awaiting the second minor release was to wait for other operating systems (in particular Linux distributions) to find, report, and fix bugs, so that FreeBSD could focus mainly on FreeBSD-specific cases. But this also meant that upstream software developers only heard from FreeBSD rarely, and mostly when it concerned FreeBSD only, thus our operating system risks being considered minor and unimportant for them. My hope is that software authors can value supporting FreeBSD more as the number of its contributions to other projects also increases. Of course I understand that this will imply more work for all ports maintainers and I will do my best to help them as much as I can. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2659548 Resolution of a conflict preventing the installation of multiple GCC versions simultaneously Now, lang/gcc11 and lang/gcc12 can be installed at the same time. This was particularly important for the update of the GCC default version, since a few ports have been kept to compile with GCC 11 for now. Note however that at the moment only one -devel GCC port at the time can be installed on your system. This is because I have patched the standard ports only: for the -devel port I expect upstream to fix the issue soon, by using a patch submitted by a FreeBSD user or my own patch, or using some other solution. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060 D language D is now enabled in lang/gcc11 and lang/gcc11-devel, thanks to diizzy. I plan to include D support for higher versions of GCC too, but this cannot be done as easily as for GCC 11 due to bootstrapping issues: starting from GCC 12, the D compiler GDC needs a working GDC to be built. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266825 Crashes with -fsanitize=address Software compiled with GCC using the -fsanitize=address switch has been reported to crash. I have fixed the issue for lang/gcc11, lang/gcc11-devel, lang/gcc12, and lang/gcc12-devel. I am still working on lang/gcc13-devel. Use of the address sanitizer requires ASLR to be disabled. As GCC gets the code that I am modifying from LLVM, and LLVM is also included in the FreeBSD src repository with some patches that improve ASLR detection and automatically re-run programs with ASLR disabled when necessary, I am also merging those patches. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267751 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Another milestone for biology ports Links: Biolibc-tools URL: https://github.com/auerlab/biolibc-tools Fast And Simple Differential Analysis URL: https://github.com/auerlab/fasda Contact: Jason Bacon The biology category in ports continues to grow and mature, and reached another milestone in 2022q4 with the introduction of the rna-seq metaport. The fields of genomics, and more generally, bioinformatics, are often referred to as the "wild west" of computational science. Analyses are typically mired by a lack of clear documentation, and difficulties deploying and using software. Many scientific software developers do not understand the potential of package managers to simplify their lives and the lives of their users. As a result, much scientific software is deployed using ad hoc "caveman" installations involving overly complicated and unreliable build systems that either bundle dependencies or attempt to work with random installations thereof. Work has been ongoing to make FreeBSD ports a model of how easy scientific software deployment should be. It now contains a solid core of many of the most commonly used open source applications in biological research. This quarter saw the completion of a tool chain for one of the most important types of analysis, known as RNA-Seq. RNA-Seq measures the abundance of RNA, and hence gene activity, in tissue samples. All of the tools needed to perform a typical RNA-Seq analysis can now be installed on FreeBSD using: pkg install rna-seq This includes many mature existing tools as well as new tools developed on FreeBSD, such as FASDA and biolibc-tools, easy-to-use replacements for some of the more troublesome tools traditionally used in an RNA-Seq pipeline. Software deployments for RNA-Seq that traditionally have taken weeks or longer can now be performed on FreeBSD in a few minutes with a single command. Scientists can spend their time doing science rather than struggling with IT issues. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on GitHub URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Stephan Lichtenauer (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. During the last quarter, pot 0.15.4 was released. It again contains a number of improvements like signing pot images as well as many bug fixes. Also, we welcome two new pot contributors: @zilti and @reezer. Additionally, there is a new Ansible pot collection available. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: a repository of pot flavours and complete container images for usage with pot and in many cases Nomad. As you can see, we had a busy quarter again, this time including improvements to the Nextcloud as well as Jitsi images. Furthermore, we landed pot-based FreeBSD support for sccache-dist server (the server component for distributed compilation of rust and C++ using sccache) and it will be part of the upcoming sccache 0.4.0, see mozilla/sccache#1184. Once released, this will become available through devel/sccache. This means one can build rust projects on FreeBSD targeting a cluster of machines, something that could potentially be integrated into poudriere as well. Last but not least, Luca’s EuroBSDCon 2022 talk is now available on YouTube. As always, feedback and patches are welcome. From nobody Fri Jan 27 09:50:17 2023 X-Original-To: freebsd-current@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 4P3CVv6rxnz3bBFT for ; Fri, 27 Jan 2023 09:50:31 +0000 (UTC) (envelope-from innocenti.maresin@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 4P3CVv0bywz414b for ; Fri, 27 Jan 2023 09:50:31 +0000 (UTC) (envelope-from innocenti.maresin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=h3PiheDG; spf=pass (mx1.freebsd.org: domain of innocenti.maresin@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=innocenti.maresin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1033.google.com with SMTP id b24-20020a17090a551800b0022beefa7a23so8062419pji.5 for ; Fri, 27 Jan 2023 01:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=oHMVKkg3pH7322WnGK4HkTIX99b4lsQelQS6AjEakYo=; b=h3PiheDGjHeI+zSrysIrQKwHK5v7vV7Vw3AtCLI6cDirMGb8SVw4enTU2c25r2pIeF zDvzy3UHLzn3xVDjYSH4+so1c1u+BtCTK3Ggqt8iayyamiuxUebtiO356G4J5encHr1M LIBvfvD8iIJn83BsAQixNTF+D5AdaxWg78lmdxK9tifmY9XkcF6ExUqhVhaX3cTDuxLU 3Cizf7s4Az7q5CE+DLw2Ns40FMZYEoY65KFmg0XHyDdwTYV0/JxZpAsv1PBd5rO30iHi FjhyF6QcilLRW16nBxwjz8OMxkOUbtG91QAwY5jHa9NfwVEgFdfiFN0BYws5soeIy7It 7V8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oHMVKkg3pH7322WnGK4HkTIX99b4lsQelQS6AjEakYo=; b=BnpmaxRZfAR/FsnMHrJCAhR/OHJT7obfHaxTtqNDelWpxHvwIqd0LA4c2aeCBZ2/lW MoPaiAhCYpI8PAXIRQ19ZqpQeig5+qpZISgFAZyhoVSKYv3nEscwHHzXFQdFM28rUhWg aNS8VnxofNofhJ1RFsZsoy2gVliXn1FYxQ8Hvw13t3NhBlsM+mMeo7Bibll2Gai1RFc/ u4oWoXau2U6n5GRT9ZBQnqk4zygcKCArGoOzbvTNvEmj1+K/7Wvo4IpkqIMpyqxRUdVr 5EqvnV5U6sHKEQAn/9ydkgRExljgVlq/Q94g9k9OJlZwmrwlPB8DlR58VfOyzx1n9CrT I2Kg== X-Gm-Message-State: AO0yUKVlgDLD14S9SC3QMho3uizv36SO0/eYZikdFccoRHs+iql6wMgr 1NhTsF8A/vFMn1+9WIfZkprz47GAdpFhrt0c7fevFo1fuHppCQ== X-Google-Smtp-Source: AK7set8ni+xtc1yovwbAPjL/Xr+QhtTKjhO7YdxsxHQeuSD2jGeroA6k+YV40bmuB3lJhRcM2iQq6DocaMgi2nfugYs= X-Received: by 2002:a17:90a:ea11:b0:22c:3a26:77ea with SMTP id w17-20020a17090aea1100b0022c3a2677eamr628460pjy.166.1674813029556; Fri, 27 Jan 2023 01:50:29 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Innocenti Maresin Date: Fri, 27 Jan 2023 12:50:17 +0300 Message-ID: Subject: 14.0-CURRENT fails Norelsys NS1081 To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-4.00 / 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)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1033:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; 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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P3CVv0bywz414b X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello. FreeBSD-14.0-CURRENT-amd64-20230120-43703bc489ec-260163 failed to attach to Norelsys NS1081 card-reader controller. In short: umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8100 (probe0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed In more details: https://forums.freebsd.org/threads/cam-status-auto-sense-retrieval-failed-with-norelsys-ns1081.87874 If any additional information is required, then please let me know now. Otherwise I will use the memory card (from where I booted the installer) for another software. Regards, --Incnis Mrsi From nobody Fri Jan 27 10:34:10 2023 X-Original-To: freebsd-current@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 4P3DTW5fT0z3bHcK for ; Fri, 27 Jan 2023 10:34:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P3DTV4XvLz45PH for ; Fri, 27 Jan 2023 10:34:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=Ij2TOp0n; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com; dmarc=pass (policy=none) header.from=bidouilliste.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1674815654; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TBNWV6Ben/ryo1IqI08QZ6DjOi8piZX+f7aR4s4ESyw=; b=Ij2TOp0nrpuy13n/Uri/jwkvpFW6fgaGZ1EtlNV1j9v53zU2RLW46AR1hj9KWC1K/fwma+ NxPn23QeWDMKENbw9AykBzTBunR7XhKbqJGbwSwuzM8IMYeFogPCa23yzu/iM//umXycQC urX82kDuEmTQ9/gyJhyzpMdpEhZg/rk= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id cfef8f78 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 27 Jan 2023 10:34:14 +0000 (UTC) Date: Fri, 27 Jan 2023 11:34:10 +0100 From: Emmanuel Vadot To: freebsd-current@freebsd.org Subject: Switching MK_ATM to no by default Message-Id: <20230127113410.4ec56d8e93eb6dd32c122ae1@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.50 / 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)[bidouilliste.com,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[manu]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4P3DTV4XvLz45PH X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello, It's 2023 and I don't think that ATM have any users (but could be wrong hence the mail). Is everyone ok with switching MK_ATF to no by default ? This will stop installed sscop(1) and libngatm (Netgraph support). If no one complain I'll do that for 14-CURRENT mid-february. Cheers, -- Emmanuel Vadot From nobody Fri Jan 27 20:40:27 2023 X-Original-To: freebsd-current@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 4P3Twy06vBz3c30B for ; Fri, 27 Jan 2023 20:40:34 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4P3Twx56Fmz4JFX for ; Fri, 27 Jan 2023 20:40:33 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; none Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 7A29D3C0199; Fri, 27 Jan 2023 20:40:27 +0000 (UTC) Date: Fri, 27 Jan 2023 20:40:27 +0000 From: Brooks Davis To: Emmanuel Vadot Cc: freebsd-current@freebsd.org Subject: Re: Switching MK_ATM to no by default Message-ID: References: <20230127113410.4ec56d8e93eb6dd32c122ae1@bidouilliste.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230127113410.4ec56d8e93eb6dd32c122ae1@bidouilliste.com> X-Rspamd-Queue-Id: 4P3Twx56Fmz4JFX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Fri, Jan 27, 2023 at 11:34:10AM +0100, Emmanuel Vadot wrote: >=20 > Hello, >=20 > It's 2023 and I don't think that ATM have any users (but could be > wrong hence the mail). > Is everyone ok with switching MK_ATF to no by default ? > This will stop installed sscop(1) and libngatm (Netgraph support). >=20 > If no one complain I'll do that for 14-CURRENT mid-february. Please do. We should probably finish removing the last bit of ATM. -- Brooks From nobody Sat Jan 28 04:27:49 2023 X-Original-To: freebsd-current@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 4P3hJM3kfHz3cDmQ for ; Sat, 28 Jan 2023 04:28:03 +0000 (UTC) (envelope-from innocenti.maresin@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 4P3hJL5hcTz48ky for ; Sat, 28 Jan 2023 04:28:02 +0000 (UTC) (envelope-from innocenti.maresin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Bz7xr7+o; spf=pass (mx1.freebsd.org: domain of innocenti.maresin@gmail.com designates 2607:f8b0:4864:20::1036 as permitted sender) smtp.mailfrom=innocenti.maresin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1036.google.com with SMTP id nn18-20020a17090b38d200b0022bfb584987so6528526pjb.2 for ; Fri, 27 Jan 2023 20:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=4roZ/qLUxsC+W3hF9E3HqDZStkvOVORjAgp20qYgZz4=; b=Bz7xr7+oTR2okTb1f5auNEQPz0XlVJgvulON5srsIw3btKfvmt3YcGcZpyKrSX2af8 xYranngQMY1fegoGg4xsqpBMxrUBe6ufeinJBQ7u65Trk7FT0Is53oN4LFrRxCH6AXSW kZT/7Y+lMZtxUfhitBoAGQdcdejXZdOvuhuTsXf20NKPONenWnki3jDGx2RX1aMabT/K Gkh0XRReWB5S28lO+WhYCjmydjUzzQPH6DmKwb7dJxC9rro8S4L33EAuXfaNITBZN7Be TX2AfVFJO3ib7grfmChS/GAsz/w2meOWeIwb+COdIl7nDqs5fFiNQ79Y62jh6ys84JoJ /hlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=4roZ/qLUxsC+W3hF9E3HqDZStkvOVORjAgp20qYgZz4=; b=Q3wJmX0NAkXAqjwTPUUw2xjzbpKz6rXKJZ6aMowlbFrYPoYdAJr4tA/ApCUDe/p2ju O06QAScMj5YKCucbqheKB+n/JE5Q6sgqtUTBaOZPxiyadV4EGOdWXNFDutrLAi1ejdVs PzwP8AIN7z5MJBWl6DgdW65RWsErAB8tzTfJzmf+2jcpmYOKgaqpIJ6bGQInMxLt/RU1 moCrw/8vykoS29bJY9LBjzwEXpiN3LqH0ymMosGF4mK7+2NbDnOgW/hjxX7fbFo2uEE7 1q7xFu4STGBiAYnb/Z0HZawfAv/IHh/SXw65faOOoVM/SHwZJCMqJLc1ajvxzdDxYXit aBUg== X-Gm-Message-State: AO0yUKXM43IwgxKnSx4Y3vZWZSQzJfG3hI4S5McBb1a3pW+GFsTeAd36 0hruZUKL/cmaK7OQ4TojUYbTw1m1cG4DSmGFLsImcQTz/dZW0g== X-Google-Smtp-Source: AK7set9TJf4njMGbm38QN63J8vaiR5z5pWlKfK5E4nMyYJChePG35lli4IeeUVwkEItEwDxQjHxtNRg2lQzF7yBT5d8= X-Received: by 2002:a17:90a:c204:b0:22c:1613:164f with SMTP id e4-20020a17090ac20400b0022c1613164fmr1459048pjt.103.1674880081330; Fri, 27 Jan 2023 20:28:01 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Innocenti Maresin Date: Sat, 28 Jan 2023 07:27:49 +0300 Message-ID: Subject: Re: 14.0-CURRENT fails Norelsys NS1081 To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.80 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.81)[-0.807]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1036:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; 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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P3hJL5hcTz48ky X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N By the way, the same error happened to FreeBSD-13.1-STABLE-amd64-20230120-4a8af507ebe5-253535, hence it does not seem to be specifically a CURRENT issue. --Incnis Mrsi From nobody Sat Jan 28 07:34:14 2023 X-Original-To: freebsd-current@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 4P3mVC2rT2z3bCJg for ; Sat, 28 Jan 2023 07:36:51 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P3mVC1vFPz4Q1y; Sat, 28 Jan 2023 07:36:51 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674891411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Vc4cSVyksjcBbeUL/i+b0noA6MxjdtCeqp/6gexQhg0=; b=czTgJ41sO2a80n19mVWxvZE9qDrucEyoGMrRwybPM0b3ExL8sdLi0PkaLYo5EsjzehKNcp wN2mqK4msimwz5vohnT2i4gngsHjKXn2IC8Lurz6WsrTioqDNZ88UMsldltD9v2wN9Anz/ IKFHc7m9azplXwx9X7vnmp4E6fOumkay7l/6ttQTKCwpV3tXDCzrzfdCUof8rJ7qvtiReS fbEQ5uJ6N2UpDGGhbBO0xc+e8Gge510/nSZTycni6YuKZVtqRvN+HV0nFBo7Yj3qmq2yNB b3sAuU2dLva34pdXjOnF06nTseStgDgi81FZ9ffY9kjvP+qqRF5vFg8WKEJW2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674891411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Vc4cSVyksjcBbeUL/i+b0noA6MxjdtCeqp/6gexQhg0=; b=tIwteQh2FLSVwME/NuUr3LPS10e5FwIESZ3FQZRMNg9tXsRJHvE95F+ns5dMcOMvauXqOZ g2boYH/ctjykj2XVoy9SuZZAfeBnkYOEOGqB/7oIKRSV8+MFxIMG43FmaXnx+3kSPg70NN Rh7dF/jhQOG/mGRfhdnBrWqqpkDxuMcm3a3CGEUcKhWkUVdfOdVpTnPbJx++Ds8fmz9z4K Cz5fKPeWOrBta9a4FnnnHeKlphrLu8VdhVIkIxMHKWE5MIvwHikvN2oC2EvQ3BWXJdVVZK xKpFEv1dHQWdcRXG7zWdMCuSX2vOgF0x40ZWTbIRKzL6bVgIyaWa1D46B2XI2Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674891411; a=rsa-sha256; cv=none; b=rPfGnD/Oo4mwTtbQnjme49jFZJ0UUucQpTsS38rvhuFVevgo/5GQtN4Khcfq7T1UHXsf9g 8RMvuRzOiz4gAwWhJkahzREZYc0TXXxHauoIEapP0OR9wh+2he/jG4uLM+pNvviuRzhiXI aO4e+Q/M2QFg8QexjMa5em1Lr34YSPJURxieP8tFQroaLTemGI91yPjE2AGEpGgwCLXgTd JBsbUq3URIjiJFhOGAsK1IqIqSa6omUAjn5Zee5npE/FgYWmgQDVVN9xUo7InsPQBQCWrn 7zJPy+jQUZakQ6+Kvvk2qhOgo88oYh5I7sm9gt7rqyf8s/Nc3V2krpyOBmAfcw== Received: from localhost (unknown [IPv6:240b:11:220:fe00::174:11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4P3mVB3n7yzQMt; Sat, 28 Jan 2023 07:36:50 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Sat, 28 Jan 2023 16:34:14 +0900 (JST) Message-Id: <20230128.163414.1398367828069957995.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Version of OpenSSL included in upcoming 14.0-RELEASE From: Yasuhiro Kimura X-Mailer: Mew version 6.8 on Emacs 30.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N Dear developers of base system, Though release process of 13.2-RELEASE has just started, please let me talk about one more next one. According to the initial schedule of 14.0-RELEASE, release process will start on April 25 and 14.0-RELEASE will be released on July 17. https://www.freebsd.org/releases/14.0R/schedule/ So it means release process will start about 3 months later and 14.0-RELEASE will be released about 5.5 months later. And I would like to ask a question. Is it planned (or considered, scheduled, etc.) to upgrade version of OpenSSL included in 14-CURRENT from 1.1.1 to 3.0? According to the "Release Strategy" page of upstream (https://www.openssl.org/policies/releasestrat.html), OpenSSL 1.1.1 will reach its EoL on September 11, 2023 and OpenSSL 3.0 will be supported until September 7, 2026. Since EoL of OpenSSL 1.1.1 is only after 2 months of the release of 14.0-RELEASE, it doesn't seems realistic to include OpenSSL 1.1.1 in 14.0-RELEASE and upgrading to OpenSSL 3.0 is inevitable. Though I'm not familiar with the incompatibility between OpenSSL 1.1.1 and 3.0, I believe it is too optimistic to regard that build of 14-CURRENT succeeds without any error just by updating /usr/src/crypto/openssl from 1.1.1 to 3.0. So it will take for a while (a few weeks?) to finish it. And it also affects build of ports. To be honest, it is rather my main concern as ports committer. I checked Bugzilla and found following PR. Bug 258413 [exp-run] OpenSSL 3.0 upgrade https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413 Though it intends to check how many ports fails to be built if security/openssl is updated to 3.0 and 'DEFAULT_VERSIONS+= openssl' is set in /etc/make.conf, it is also applicable to after OpenSSL in 14-CURRENT is updated to 3.0. And according to the result of exp-run, it doesn't seem to be easy job to adapt ports tree to OpenSSL 3.0. So it probably will take longer than updating base system. And considering these points, 3 months are not necessarily so long. So I asked a question as above. Please let me know current status about it. Best Regards. --- Yasuhiro Kimura From nobody Sat Jan 28 15:06:41 2023 X-Original-To: freebsd-current@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 4P3yTq5DR6z3b40W for ; Sat, 28 Jan 2023 15:07:11 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.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 4P3yTq2vHhz3tMY; Sat, 28 Jan 2023 15:07:11 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Authentication-Results: mx1.freebsd.org; none Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.96) (envelope-from ) id 1pLmmv-000HKy-1u; Sat, 28 Jan 2023 08:06:41 -0700 Date: Sat, 28 Jan 2023 08:06:41 -0700 From: The Doctor To: Yasuhiro Kimura Cc: freebsd-current@freebsd.org Subject: Re: Version of OpenSSL included in upcoming 14.0-RELEASE Message-ID: References: <20230128.163414.1398367828069957995.yasu@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230128.163414.1398367828069957995.yasu@FreeBSD.org> X-Rspamd-Queue-Id: 4P3yTq2vHhz3tMY X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, Jan 28, 2023 at 04:34:14PM +0900, Yasuhiro Kimura wrote: > Dear developers of base system, > > Though release process of 13.2-RELEASE has just started, please let me > talk about one more next one. > > According to the initial schedule of 14.0-RELEASE, release process > will start on April 25 and 14.0-RELEASE will be released on July > 17. > > https://www.freebsd.org/releases/14.0R/schedule/ > > So it means release process will start about 3 months later and > 14.0-RELEASE will be released about 5.5 months later. And I would like > to ask a question. > > Is it planned (or considered, scheduled, etc.) to upgrade version of > OpenSSL included in 14-CURRENT from 1.1.1 to 3.0? > > According to the "Release Strategy" page of upstream > (https://www.openssl.org/policies/releasestrat.html), OpenSSL 1.1.1 > will reach its EoL on September 11, 2023 and OpenSSL 3.0 will be > supported until September 7, 2026. Since EoL of OpenSSL 1.1.1 is only > after 2 months of the release of 14.0-RELEASE, it doesn't seems > realistic to include OpenSSL 1.1.1 in 14.0-RELEASE and upgrading to > OpenSSL 3.0 is inevitable. > > Though I'm not familiar with the incompatibility between OpenSSL 1.1.1 > and 3.0, I believe it is too optimistic to regard that build of > 14-CURRENT succeeds without any error just by updating > /usr/src/crypto/openssl from 1.1.1 to 3.0. So it will take for a while > (a few weeks?) to finish it. > > And it also affects build of ports. To be honest, it is rather my main > concern as ports committer. I checked Bugzilla and found following PR. > > Bug 258413 [exp-run] OpenSSL 3.0 upgrade > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413 > > Though it intends to check how many ports fails to be built if > security/openssl is updated to 3.0 and 'DEFAULT_VERSIONS+= openssl' is > set in /etc/make.conf, it is also applicable to after OpenSSL in > 14-CURRENT is updated to 3.0. And according to the result of exp-run, > it doesn't seem to be easy job to adapt ports tree to OpenSSL 3.0. So > it probably will take longer than updating base system. > > And considering these points, 3 months are not necessarily so long. So > I asked a question as above. > > Please let me know current status about it. > I also beleive that FreeBSD should now adopt Openssl 3.0 OPenssl 1.1.1 is about to be defunct. > Best Regards. > > --- > Yasuhiro Kimura > -- Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Birthdate: 29 Jan 1969 Redhill, Surrey, England Beware https://mindspring.com