From nobody Mon Apr 7 02:29:08 2025 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 4ZWCpF44Mrz5sSsQ for ; Mon, 07 Apr 2025 02:29:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4ZWCpC6yg5z4GVZ for ; Mon, 07 Apr 2025 02:29:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=RqYT2Nt6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743992961; bh=9oDbbyxdHd+/e8W8So5+vfRPRyxe6HWDCnQUNejtfX8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=RqYT2Nt67gkHw3nSdDzftAIt8SqbLRER4aIi8NCYensWAuorwlbl9r3wmz/aJRWxnjh6o0gB5vP/CMHL0Pj6lsTP4yByQLMnN+/ny9J05PqRZVV+PJJ98xV1vFxhuX/OFT0Q9OfLGPoiHdzTcuNO1Qnc5PKQa9fWFlKB/XuFr23OawgL7JepDt4qfd6vOb4VU97HDOPNG772jGJkwCufMJIZSz5RQvysu3wxXATPTS/hY9bZgW8RGKm/HVGn75orH5sqXU/mLJ8nbB2hEprcfDnR3XAKqCqRrMt1cHzZ9EoFhwH/iOJmGp4HaygEDnHQhPwzhQlMs0YUZezk3z6/NQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743992961; bh=0svYFS4R58UXMq5oqoGkIK0XrY59yQ02zUy7ijJKFLk=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=V7gUyKamoJ2o8A/ZPAfvcbTMZ/qgvoz4f4njxiFCZX3xn0HCQyyH4+ZKAsBi9h67L8gY3HmRLquzlZnlhYFwNM6F181/HI5PpYlRcmxk+aJ4oFha9s/oH9UiUPLDnhOUqF12iTZhZZDkHnGhGLEr7+C9FP2fxuCKlaoxFwzR0REb63O0zDYOPu1ieQVzBI0VXyxHWysaRRojkssbIOLyNVEVicPAjA0nV46cQ8IQJ1wuZ6BbYH7viAdiEpJxyO4b+iXRG+8MG2LtD9gXmo3bJqe1EZWfFI/xEuCUwni1QCuxvzGcyBhrWokwQITlsO1nwHwSSjI9oVd0KNoJz8GzDw== X-YMail-OSG: ZCXJ.SsVM1mE_XFAFEzI_.NF8NtTRk6OrA7J70Hal5Bak6N.dQZZs11R7k2sOxZ vsoX9EZiX7K2oNdJC50gPPBV74igW4_gMnNqiLixGLVjAKNvwJUmBitCAo7V7c8EK8e.ExIvxNxK Q1ot7dVhoPnTmLGU9ksPVHg1_QofFy3omXFU0lCJKhVip2UPlTWQUbAlFlWk8UcRaRHRL9p6Borw FOmyUJtsjF5xrZv7dY2DOJ.UyyMBX1v2Vbzp5GPKRty2sapXEfuJoRRYOZDJD6elFSp98JmOzEZv ap6MfV6cbz21smY2KhLroPyF27AI5tGmhVVWkmjlk166nRnWAd9NPSYRpr5MeKLfd4HTTsmS.yYD pEKlo7tNzD.4PBJ1tim2GS2_6kVc2OoDhEw4KFYOwIZ1SeZWEqr80Rf.4Az3PCjlCuwYlTwYOcI3 Rorp8OHH.lNhHD7wxyu9ssy8MABrRvVRN0qX.ygWSrL_YttblVf3rjKBO0CrwkTBmsObsxA6ubsD FXDLylmKRxTh6BowSbXOWNxlkzXg.FU2PBQX0WrOkvl4e6okIFCbK4_r5s5SZ__BvElbyUA_shO6 CNzKfrujdjNQy_9uUDbZ3d9YXM0pS1sfDq1Fxjre3_YbFQC7fW.RYFpG1.1DvsZVr_o0IWeSKudy .S1f.3m7k3W.8jqtdt4ZikNSDOyaJF46dcQFyPE7zedXFnwKejEOkvVPQKm4eZ2W6CDYyEWb7Gch X_GaqqGY3lAHvV.Tu5Rp0YNvHK8hpfceWv.g9R78Nq.nPei5rlKTi0eZ_f8E5BgFprOA2.uiJlRx 2000rB1AK5X57ozhgDjULnCIBFFydzrHwf8JL1PLxPxRSxVaIlavrrnB7ebI7lfok0W.SlK7qLIm 3Ax0.WxeR9EfjihudTiKCxiH2HWeKwlneF_7cWik3x1e0uU8Z3NU0VbDAa8U4RpTcdBEYt3x25Er zpR5aKS0uoDbe.FhX8vDBf.ZPwBRwL18R9BtAY3eMRA1YalsP8OMbDRYsD2Ree3ofTj_5gZJ_vST _U0Itq0FEXTc.Cta43f9GDoxmtljbAZJthKty2qehpWZZsCiGIsFPtPRdOEUDMxAgRwTmqQuxh02 .HDrtx_aeZ4fo0FaHLWaV3KvUuO9_OEvesji2ALDJgwVsIszr10q_D6pR1hmcmbH3WMfgfGLwEyW 3MtTC6Npd8FiBWORnfbNA0KaaAa.64hD3NDb1HjUgpFfYICTQ3mBfCnaLz3XBYd1rvcfFtj7VZCE cJXOQfFIOwW05gYzvTM5KY9hGI3uAjm50MmOOkz_gPXZFk2yjOMM1.XFYcO5aJ7INx.oUOW5mBAl nqZdQJzIB5mFaACLDRHAGKd.Pyiyn9BM0HD1wjzdcvqqy_6hwKCM66zIaPO1JgFQxozceH3r8_9K ojsDkQkElRo6UpND7Z44bAPmVoLOTymsxfKY.pNbsa8sktAaRCnk2dpD4M3gJEdMpEN_Oh5CLP4r MVLvtMNCTScg5OGYumbgROxYe_BvwMlIJmgufV___GXPN_GlqGOyi._MlqXq8I81YhmXdok_UltM gGLYSE7R4WraORPxdQ1XNcRbtnJ0CAnkEZAbf53mJQ58YcpmGSrqMct1G4nM23Rhq2qW9pzQj.op 7j3A692QlN6j8P1EXXMc0B_Cqt4qH4A.0fR.TQqttGbW0fIhdU_zH3osytsJaeylpuOmjlLX1z.u yGpj9dQnWBkj4K6R5sv.tkZrNUCYx9.JmAD3WkbrUwTnjVtSYo04Xn.f5nKHegR.SfZlynR7RH1E vnCMWv_1CfAnoFbze3k82XIrEUehY57IowkSG90KpoNNwECeb3wypYkJNGma.zlu3ujYGqMGcTwQ _yx1ZuWEMUrTHHhdSmumJ02UUO1Q26DpvnJvuQob.KUfu97MuGK45dyfGqW5Thav..A1PGe04gyM 3S_070wY_SxwmhAXIkPGB8kX4QfT2Q9Qqk6Iynqmp496ggcgeKZnYnJfGrNB3naLEUwwo_dwuh4H B5OoN6hqJfDdbb0kLuXnUUUlt43svwSBzUEqfF6c3OxkSpwnsPT2EQaJ2laOh2MLPDMTY649forz ntcplbZ_aJINTC6E90853utEwjIvTayJn2gELDB7W8sODw0CK1vcldgWezHAMCJ0o0UcPXr.kglt 5UV1CZuj2PuLlhDIT3RFgqZiZOkjhIjlO1hl84nIUM0wqW7xQoDBTD0chTJRRZx.PusBfimwuHoE dg9VwF8QzsRcizg4- X-Sonic-MF: X-Sonic-ID: 2d8c848f-eddd-49ab-bb6b-91ca71336a26 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Apr 2025 02:29:21 +0000 Received: by hermes--production-gq1-5c477bf655-9clht (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1dae2de0ef9f73d22316f750e91e8b4c; Mon, 07 Apr 2025 02:29:19 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3826.500.181.1.5\)) Subject: =?utf-8?Q?VNASSERT_failed=3A_vp-=E2=80=BAv=5Fholdent_=E2=80=BA_0_?= =?utf-8?Q?not_true_at_/home/pkgbuild/worktrees/main/sys/kern/vfs=5Fsubr?= =?utf-8?Q?=2Ec=3A3391_=28vget=5Ffinish=5Fref=29?= Message-Id: <267C2D6F-5E2C-4482-9CDE-7EF6522EAF29@yahoo.com> Date: Sun, 6 Apr 2025 19:29:08 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <267C2D6F-5E2C-4482-9CDE-7EF6522EAF29.ref@yahoo.com> X-Spamd-Result: default: False [-3.10 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.84:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.85)[-0.849]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_SPAM_MEDIUM(0.25)[0.252]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZWCpC6yg5z4GVZ X-Spamd-Bar: --- [Somewhat hand corrected "OCR" conversion of some console image = content.] VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) 0xffffa006e11e6a50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 hold count flags () flags () lock type ufs: SHARED (count 1) vp=3D0xffffa006e11e6a50, lowervp=3D0xffffa004b074adc0 panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) cpuid =3D 8 time =3D 1743988125 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x38 vpanic() at vpanic+0x1a0 panic() at panic+0x48 vget_finish_ref() at vget_finish_ref+0x1a4 null_hashget() at null_hashget+0xe4 null_nodeget() at null_nodeget+0x34 null_lookup() at null_lookup+0x118 vfs_lookup() at vfs_lookup+0x3e0 namei() at namei+0x298 vn_open_cred() at vn_open_cred+0x450 openatfp() at openatfp+0x238 do_el0_sync() at do_el0_sync+0x608 handle_el0_sync() at handle_el0_sync+0x4c --- exception, esr 0x56000000 KDB: enter: panic [ thread pid 8113 tid 163110 ] stopped at kdb_enter+0x48: str xzr, [x19, #2048] db>=20 An issue may be that I'd not yet updated the world yet after updating and booting the kernel (but no ipfw usage involved): # uname -apKU FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 1500034 (That kernel is from installing an official PkgBase set of kernels, not a personal build.) # poudriere jail -l JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 . . . The FreeBSD context is Apple Silicon M4 MAX under Parallels on macOS. FreeBSD had been doing a poudriere-devel based bulk build. I've no known way to reproduce the panic on demand. Core dumps under Parallels always seem to have backtraces that are like: #0 0xffff0000004b9e48 in doadump (textdump=3D0) at /home/pkgbuild/worktrees/main/sys/kern/kern_shutdown.c:404 #1 0x6fa60000000e9d98 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt = stack?) and the rest of the cores are like: #0 0xffff0000008703b0 in ipi_stop (dummy=3D) at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342 #1 0xd2e9000000866b68 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt = stack?) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 7 04:11:51 2025 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 4ZWG503wDxz5sbrs; Mon, 07 Apr 2025 04:12:20 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWG4z66Hdz3Pvh; Mon, 07 Apr 2025 04:12:19 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-e60aef2711fso2628909276.2; Sun, 06 Apr 2025 21:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743999138; x=1744603938; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F31X8zORrNL/03tzgEubKak+OevOW2RWpE29N3+XOmk=; b=UnkD/DS5f4VRsUYrbi2mPW4JuIfvGJZUlmMlLyteGAU6FYBkXRkbWdUUSbiZkeClrM +xOuwKAkOhkXrcrNE0cNHYZoCsnxPi5PPYphXwYKkQRBL/q48dcf/5NgxEpgMxZnrRQh yR9/26WJnEquCNvmUViKYueoJztj/We/HIc6UA57qaQGUJgkXdTTe8evOEurlc+Q9xr2 a9MOwyD5VIEGNiFX6HVzp+pNJibG5zcq9fWxSAOlukiSD6gyogtFif72WH9cueTyY6Nb 3IlEEUNG8AACEdmCFOisOOOcxd3+f7Xs0R7/MGKhRs1jZFjJo5BWzqOJ+ceAKfdKostW xvgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743999138; x=1744603938; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F31X8zORrNL/03tzgEubKak+OevOW2RWpE29N3+XOmk=; b=nxtpsz5VX4zyoxVqy02JAUH45vD95uo/pKqtj9CrxrktO1RhT6J4rF/nF4/bAFtjx0 fiBi8lEvcqpbPXzLNiKzGnrid8yzpNRhGQbix2FNeDmBd3IX+dE0xCpAddnI+N+PWrX7 y9EK4ZK/N8Ph+QRcP7B7MWeVH2uq7zCQJQA3WfrgwwBN47kgMC8mk2mh0occxHmH5fdT 2KKI3Ddqrse7EkO3dz5YU6KNzNf1oaOaD00GHpp6iI6XXpna3NzyEta5WerCarDLztII mrK7JykPIwBJEcz80j8c/qzHHCccoEHYy3vJV+683GruzlnZmqaV9l8tnEfWnZYw8m3E p3Ug== X-Forwarded-Encrypted: i=1; AJvYcCVLjQz1e/CBe+U0HuYXPd597VQ0Qsfs8pYVf4imYNEH/CF5n0DsXJBeyjV+78c6B1copE9EP+4CguJx4ZAm@freebsd.org X-Gm-Message-State: AOJu0YzNixHZlI4Dkne7S+EbnN5woGyrAHC42bYyxZCGemjtwszOpj27 NXx//vkQNjmWHoRFub2XbdrfRHTT7o07sx3aAYZvKDjjK6bcIoxTkPrVj651jmBIDtG9sn3mWFa TSiu7duPqAmbCxA9qDRteqiERZol7+1op X-Gm-Gg: ASbGncs7qRdv20RBGWJfubRU38DtlzI/Xvoz7BgSa4GWIuh/ertm1I8PS8PZsLklkx1 FfG7XzEbmLKZPSHEv+8x7I8wLGLtITH2vUguMvQqKZl0LRjUoWpWd/go6eKn+HYlGrfrHWNm7fY dtjV9d3tUxbCWUUd9T34hp9uIC X-Google-Smtp-Source: AGHT+IHN1tUmg666EoK6xBNdyHam39AVir0mZs+375tzDTl62aziFKkw8sCjn/M6ppRttw+woy5NRxRyHnzZIIvRL28= X-Received: by 2002:a05:6902:1b01:b0:e6b:81a8:bf8a with SMTP id 3f1490d57ef6-e6e1f9de421mr16928544276.24.1743999138538; Sun, 06 Apr 2025 21:12:18 -0700 (PDT) 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: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> In-Reply-To: <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> From: Gleb Popov <6yearold@gmail.com> Date: Mon, 7 Apr 2025 07:11:51 +0300 X-Gm-Features: ATxdqUFiaEW7hT20IDGe52jIj9fqEQMH-DXGDeyJS0TusOlULdwDw5PGDwE8Ctw Message-ID: Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [it is more complicated then that for aarch64] To: Mark Millard Cc: FreeBSD Current , FreeBSD Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZWG4z66Hdz3Pvh X-Spamd-Bar: ---- On Mon, Apr 7, 2025 at 2:44=E2=80=AFAM Mark Millard wro= te: > > So: 2 min 31 sec or so difference for overall somewhat over an > hour, i.e., 151 sec or so. That is under 1 sec per package > built. If the slowdown comes from handling shlib provides/requires, then this obviously depends on the amount of dependencies of a given package. It might be as fast as before for a package with just handful of required shlibs, but get exponentially worse for giant ports with a lot of deps. From nobody Mon Apr 7 08:11:14 2025 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 4ZWMNj3MX8z5sv90; Mon, 07 Apr 2025 08:11:17 +0000 (UTC) (envelope-from bapt@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWMNh5tLKz3DdL; Mon, 07 Apr 2025 08:11:16 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744013476; 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: in-reply-to:in-reply-to:references:references; bh=odEVlZQ3wYARohaN701skVMpU2H2M1Uo/k+zYvGKfz4=; b=JOq5ZlSRsMIXV2uFyr5h+AtQxh21miQotDJfIrfGHlwebzYg9b0o7we3MgVVanmlWvi/q9 wOZ+FnFGjhmS8rvM656shsgYUAT3D8wXGGlewNChay2y6+snZ0umUAOyTGP75C86OhSY8B eZuXioSozMKqx5VjClj1iAyuxXQUDsenD7Qe0UW6nPQohCCeGstbg8/0Z57xAzjRbheSXX rc9p4B9N8sVqYKQv5qcyBcAzEclYM1FP0w9aBEBxqtvemzVQGJBYDu5n0fxL+t2RNqziuQ YmaNMnd2DXz6Rf/U0OpbvkN3X3SzdLFTGXV46Zv3w55CHvIQltc+ygCr1Vfhjw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744013476; a=rsa-sha256; cv=none; b=AAhhpNl5n4GADPxWoxBzl7eOEHjutEGkja2LoR9s/XWE6T2MiDQilb1Cr9BaX6GKTvMSH0 VbrCdZGEanqfPDyB69fUb6+knkd4zbNKas8q0cGkrl0OCVHHCdgNH01WlTM2uffJGDumn0 lKYGfNu6JzPQTJtw/sadv4zspJtLHkw5mebj0UdkSoGMGGeC10uUaIuKDpjV6d/qmdzz4K rwJqE+jkPcbZAH6GUNRdVTD/KkXx2vvlrUCTC+lFbL27Hv/5NGUQU4KLAXe31K94aOalmw 9v6YvK8nZIOYZmJBGUjYRj5u56vMLisEm6urxiXI8ZstZHpxz7xDW7JVPmc++g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744013476; 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: in-reply-to:in-reply-to:references:references; bh=odEVlZQ3wYARohaN701skVMpU2H2M1Uo/k+zYvGKfz4=; b=hypFKFsBLMJivF2MDD1xvCUVgaldqumgTaL8XZ9I6b+ZUGvWSSf047pgzBhcXqzC4QhftG zSpqmeJr0W8x0kkUrDxQS5z5qjjYKdNgqkH+jKUfVA20TgiNdTtEtvtdLlB/MxhJLWi+0G 0wh5ZM22wP9XUXSg9gBJRZCph8k4cycsOFohrOtUu58jwvShY1pL26b9KoI+UlzZqmDerS 0aav73rVTVQvaWjygCO48qzFqptxcZt2xLciGYCWBT5U11+dgM2nWdbb/nssHYkLHqjQfI iAESIz5gYdxdJhUjOkCP3jms5y4kYTbDbrEGzIL/1IdZThIDP41BgM1LGyYrsQ== Received: from b.nours.eu (b.nours.eu [IPv6:2001:41d0:303:5e39::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) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZWMNh2kKwz1hM; Mon, 07 Apr 2025 08:11:16 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by b.nours.eu (Postfix, from userid 1001) id 3C07281A6; Mon, 07 Apr 2025 10:11:14 +0200 (CEST) Date: Mon, 7 Apr 2025 10:11:14 +0200 From: Baptiste Daroussin To: Mark Millard Cc: FreeBSD Current , FreeBSD Mailing List Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer Message-ID: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sun 06 Apr 13:27, Mark Millard wrote: > [I thought of another question.] > > On Apr 6, 2025, at 10:53, Mark Millard wrote: > > > On Apr 6, 2025, at 08:39, Baptiste Daroussin wrote: > > > >> Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a écrit : > >>> [This is an update of earlier notes, now that I've noticed what > >>> is different for the contexts that not seeing larger time frames > >>> in the Mar-29/Apr-01 bulk build starts of official package builds.] > >>> > >>> The context here is the official bulk builds started > >>> 2025-Mar-29 (beefy 17 and beefy18) or 2025-Apr-01 . > >>> > >>> pkg 1.21.3 was in use on beefy 19 and beefy20. These did not get the > >>> significantly longer time frames. > >>> > >>> pkg 2.1.0 was(/is) in use on: > >>> (beefy17 and beefy18 are significantly slower hardware than beefy21 > >>> and beefy22) > >>> > >>> beefy17 main-i386 168:11:08 vs. prior maximum 74:19:29 > >>> beefy18 main-amd64 168:11:10+ (so far) vs. prior maximum 96:28:10 > >>> (beefy18 still has 9338 Remaining and still has status parallel_build:) > >>> > >>> beefy21 142i386 50:40:16 vs. prior maximum 40:22:44 [141i386] > >>> beefy22 142amd64 58:51:19 vs. prior maximum 49:37:29 [141amd64] > >>> > >>> Note that beefy17 took around 94 hrs longer, more than doubling the time. > >>> > >>> ampere2 main-arm64 is somewhat over 1/3 of the way along but also looks > >>> to likely have a much longer overall time frame. > >>> > >>> > >>> Note that beefy17 and beefy18 had/has: > >>> (has large time changes) > >>> > >>> Host OSVERSION: 1500028 > >>> Jail OSVERSION: 1500035 > >>> > >>> beefy19, beefy20, beefy21, and beefy22 had: > >>> (mix of little vs. large time changes) > >>> > >>> Host OSVERSION: 1500035 > >>> Jail OSVERSION: 1402000 > >>> > >>> ampere2's main-arm64 has: > >>> (has large time changes) > >>> > >>> Host OSVERSION: 1500035 > >>> Jail OSVERSION: 1500035 > >>> > >>> So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 . > >>> > >>> === > >>> Mark Millard > >>> marklmi at yahoo.com > >>> > >> > >> > >> yes this is known and expected, because ofnthe support of provide/requires in a way the ports tree can use it (pkg add) we added some code which introduce performance penalty, we expect to be able to improve performance again by using those features in the ports tree for real (right now the work is in poudriere, then the features will be added to the ports tree) > > > > Good to know. You might want to send out a HEADS UP style notice for folks > > that build their own packages. A lot of these folks do so in order to > > get security updates quicker as far as I can tell. A known large change to > > their build time frames could be important to their planning. > > > > It might be appropriate to suggest temporarily manually controlling the > > version of ports-mgmt/pkg used to be 2.0.6 (or before) for those for which > > time to build is the most important in the interim. > > > > It looks like ports-mgmt/poudreire* would not need to be controlled (yet?): > > > > It looks like ports-mgmt/poudreire has not been updated since 2024-08-25 . > > It looks like ports-mgmt/poudreire-devel has not been updated since 2025-02-09 . > > > > > > The notes may be of use to some others. For me, the likely implication > > is to stop updating my ports tree builds except on the fastest amd64 > > system and fastest aarch64 system and to stop building for armv7 for > > now. (The fastest aarch64 system does not support AArch32/armv7 > > and the fastest that does support such takes over 5 times as long > > compared to fastest aarch64 system.) > > > > > > Going in another direction of questions for folks that do their own > > bulk builds of packages: > > > > > > Context for the next paragraph: Already "using those features in the > > ports tree for real" for someone doing their own package builds: > > > > Will bulk -c builds (for example) always suffer the longer build > > times by not having prior information for reference (because of > > the -c)? What sorts of activities would destroy the information > > for the next build attempt if that is an issue, making the next > > build take the new, much-longer overall build time? For example, > > updating the poudriere jail's world? > > > > > > Context for the next paragraph: Just before "using those features in > > the ports tree for real" for someone doing their own package builds: > > > > How will one get to the point of "using those features in the ports > > tree for real"? How will a self-builder of packages get to the point > > of being able to test the build times in the "for real" context as > > well? > > > > > >> bapt > > > > > > Just for reference for official main-arm64-default bulk -c -a (from > > scratch) builds: > > > > > > p25bf3a3260c7_s680d34896c3 queued 36447 > > and has built 15523 and has 19479 remaining, 134:23:16 so far > > (will have built up to 15523+19479 == 35002 when done, if it finishes) > > > > So: 12 to 13 days (around 300 hrs) as an estimate. > > > > > > The prior longest main-arm64-default official build that completed: > > p02dd5021d6f9_s717adecbbb5 queued 36466 > > and had built 34853 and had 0 remaining, 163:20:35 > > > > So: 6.8 days or so. > > > > Overall: very roughly doubling the overall time when the "for > > real" context does not apply. > > Additional question . . . > > Which of the following are the stage(s) that take the extra > time for an active builder? : > > check-sanity > pkg-depends > fetch-depends > fetch > checksum > extract-depends > extract > patch-depends > patch > build-depends > lib-depends > configure > build > run-depends > stage > package > All the -depends. Best regards, Bapt From nobody Mon Apr 7 15:07:32 2025 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 4ZWXdR3cFGz5rQVy for ; Mon, 07 Apr 2025 15:07:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWXdR2Kp7z3fcm for ; Mon, 07 Apr 2025 15:07:55 +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=1744038469; bh=VCTpFUkEAgoUez6OVytXHpXzlDybbDBAF/yL5GH2UMQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dK41BfoM1swnvyn0ng34tRE5GYEPABSFGkbWwSh3a4bbdDS6VVIuUW/fUC34IReqo8R+jKoxsd/QVuvUILP2rzKKeP9RWgNoZnp+IVfUsvbbtPXmGGWRBlZVBkwZvW3P3/O5sN7BVDy/lLcQiDcVcUjKXbTO3y5OXDIVekua+iyTPq7uRVtejWHZtmBeM0HqAasWwmjJHGYRp0bNcH+r6VMHSDuGNkgrJm9VTeo/KL17b1+cHg2gQyJF6mGDX20/I2O9zRPRMoocN+vjRq7q3Fk0BeL9cP9veEq0eBtCyXhESQcnHyXlNgd3Gn9hj8hanZpjSLS5HyUECVzf1oyRIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744038469; bh=+Zu23KFc6as07CesfAZ5j2P9wX7q5lf9F98WoVMa5SM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l2UQQEsZqFRC4toEG7K6qrFPgFtON9elkY6BJlbwyWFxFAjFH9hZba7lbjM6lVO44Hqn1eX0SiiG2pq7Es6K0yd5lbpI/DV9t1DTzZaChpdvZBfaXVhPX8X+lShBVqhuV6ix5HJJ2y1wVx6gv+H7M3s6fnaOOzj40uULV//dborHLwvE5+7pMDmSAlRwXJq6w7aCiVv/3Ao5KbnYdGGbJe42EhO9PZMomG/Vso+LUiPw6rhiMhh0KSzBT1n0AGVMcFhtwZQizrZdGN7xLvWpr5OKh/rEAGrbSuJ8qHNYPZSjA/Laed68iA8nROgg9+8gnhC9D8veYSpatfrTAjxwSg== X-YMail-OSG: aZ5.2IoVM1nxjIVH4_PCmJ6EKPE2gk47a7nl9Apn2f6.NlvLad8FP.FNkP0UodN sZRpNW7qR9NJmivcHBfPEnovbPMIBuO38FEsXw_L2dEeYRK2DqaNXZlDZv2sopGpwr8QtXts._CB ptCse_wxbDzA.KAYusYvsuzEEZH_8OyBJAz_5aeMAT059Cnlit4zss3IpWobxQcMRAEzJlvVw9Cn FsE73x9kQKpgD8DQ2jXEr8pIb92w80fPNurSsr3ZjAww9RpGCHbtyCUFS0fHdrAioyYyKzYOb4l1 .i2eOSITt4CMfZE2Tb0dya9W.m2nH47WFEeUgRyww_IId.1Z74f842Pj8TrbnNWdQL9l4sX2Buxk G94AV4Q6kZ3ixenDVJg.omrg41Z8uZuMe3IR3_fhY5q90fa7o1udrMvctCU_c042seOrRHuR9GE7 d424HN2r.Y7CIwwXDQmiltlMHL7tJhvFXg3V1.cZgbcjnZ853GC1FIaXLX0ezw.836wakQX.JWw_ ItoroSrUOfO9x9gKssEPRke_bGEbIE.PvH33OWJ60_i5XCT2u_wqoTO.xmQpkMghBLkBrqPsz95K OkqMFypmTJB1f3F.NWxeTwlpVeTyS0GUT0YPz.cAc_LFVFvjy4vy3psDJ5suFmW.WsJ0GwnYi8sX Q6r9HB4Gc6SaQCrzMdurOf.ac4TgrgerYCAYBz09f2uWK8tN3_Wdc4SF_AEwA56suOVoYoNSpTkR IwaMi8SG.YemsvfPWhDy6CcEdgETF_KEyOERCFHWh2vwGDHIyz8jXTWuay58SUZJaIEdcNdpO.S_ nMjzYNXRUws3RfQHQYrd0utm9WbbCGAGAWpxIlHhykLtvST6FlkCdbjyGU0pvqgCwX4PfkEXUZpv xIq4e.uv8waBpAmgDf1pgcILTFncPFE7_cXd_LGLCHRqjHdWRPGZ90GIRyw36gNVT3skM58odii7 xaXn1l26mk6I.Logkz2s.FG8On56Ct3AiPkVWWdHZ1MkZKQA.bTAq9vc5ihj.a4n8Wo6wsF8l3CN WrdQMBATcKYTZnLZSHNc7nZxN9v5BefYWnibGL7K2m1J_fxnWvilDjxk6vi_Hykrg4KdflmiEPGC XgTzSNmeAU_9s2ClqTGLjMoX7Lsm9_M9rCJNgk86swDAKsqqbxS.gcFVLrPApST9NkLRdH0RZpY3 TN0_GIMsf4z6eLSOjGl2MyKWoECnIY_Y88d3_Uc01vKuKrVh9lW.Ap1OuKGJsTm908Q5lFaCtZlq YBlGcPE_wJkXXnIkRuJbNa8yHiWKggeKkbFfk0WCcgSrc5GvbMyBbYOBiWnF6084gujS20.6doVG yvNW3RIZYJi96RXpp5sbyAFtZdHQC2vZ1cZHDhuY_3i__mEDveNMHUMg2BXfq7rVdjqeOE_7KtZa VwqZqVrhUG0O9WF8mlb1I3N8YkF7.Kh1sK5dJ8Q8de.rTbPYSrnkwOOI_ET.YVtz_i5X5KcQXv.r r5cngZFwcl6ENZi0L261NVRXPuKIW2nMPGTaZpbSL9Z_wNrKl2VzfPrVuK39K6X6nVCHhcLZkKvq rzoAEqygNGoNXfMNLM9P83wRwZJzPWf1ddbiV6XY.bf28XNBtn6vxI.rmcj1CluBv144Ur71OkL9 O3DerLEVogaDl_TIOyXoHnQmRYyV7TJahuTZv_v7sY6v6qKORPC8bjk3adbQTfUZRcLpc.MgmS7M Os3HtHosDlzNwPoloswXXldMEsZBD2NP2ztbwO_2DWNVs5As86iBjMrvstxw.wwYOw_Ja6dldsGZ HKJ53qHdH3VMEzf3tQOqrdNv4jeLX.aYt8EVxCn6tamxCBWYMixLzVQZNAnuaYiZZACJdfeFj2it .XohbVKAehXHcSHgo4vAvijWu3IUWnVRGjuzhvwfT3GtUXjJ51NVuTKfIOcEiDyODHLnZGmK9UcU kr13.4t8m_yLnmvFZkemk2NmG.ogolRm.yKhoQ2SK02l0yj4aoGrh1x7RRUmK_7Rmgn9F1mivKbf OKhQlHrvxildgHzMTk_w4IIWDJyLqEW3.RLMVBs.uMrr1WpsxOvIouojGEUABR.lGU10XJ0elTC7 ARSlRPjA97qspViQWuIm3bUdqmEdjmj.lGcVu6xTABfWRP9q33FN2ld_QOReRfGwk.GvNt4U_7eq .RZr6FMuxZGx7rAkm8N1gLnH258a.Vsf.VsFGTjsY_WYEdG1OEfpxYxKbtwzNgzv_v34zMyhWlO_ RvAYBKQQx.IP9xx7ufUO3aDtdYzU4Kw-- X-Sonic-MF: X-Sonic-ID: a2facfd1-f904-480a-b10d-75417a94eaca Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Apr 2025 15:07:49 +0000 Received: by hermes--production-gq1-5c477bf655-fdl68 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0d0c30374b4e1b1b819c3f20d44fd5ea; Mon, 07 Apr 2025 15:07:43 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] From: Mark Millard In-Reply-To: Date: Mon, 7 Apr 2025 08:07:32 -0700 Cc: FreeBSD Current , FreeBSD Mailing List , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> To: Gleb Popov <6yearold@gmail.com> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4ZWXdR2Kp7z3fcm X-Spamd-Bar: ---- On Apr 6, 2025, at 21:11, Gleb Popov <6yearold@gmail.com> wrote: > On Mon, Apr 7, 2025 at 2:44=E2=80=AFAM Mark Millard = wrote: >>=20 >> So: 2 min 31 sec or so difference for overall somewhat over an >> hour, i.e., 151 sec or so. That is under 1 sec per package >> built. >=20 > If the slowdown comes from handling shlib provides/requires, then this > obviously depends on the amount of dependencies of a given package. It > might be as fast as before for a package with just handful of required > shlibs, but get exponentially worse for giant ports with a lot of > deps. Looks like a good example of a large factor in the overall time taken (a factor of around 8 here) for a specific package is beefy17's recently finished: build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon = Apr 7 13:58:19 UTC 2025 build time: 00:45:07 from log: = https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pad39cc94161= 7_s7a490725045/logs/gnome-metronome-1.3.0_16.log I saw this showing lib-depends as the stage with a large time figure but it had finished when I later went to looks at the log file. Compare that to, say, the 2025-Mar-10 : = https://pkg-status.freebsd.org/beefy17/data/main-i386-default/p9229caa5b2a= c_s780a4667bbd/logs/gnome-metronome-1.3.0_16.log reporting just: build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon = Mar 10 17:46:22 UTC 2025 build time: 00:05:36 There is also (beefy18 instead): = https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/pad39cc9416= 17_s7a490725045/logs/gnome-metronome-1.3.0_16.log with: build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon = Apr 7 11:49:09 UTC 2025 build time: 00:36:13 = https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/p9229caa5b2= ac_s780a4667bbd/logs/gnome-metronome-1.3.0_16.log shows: build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Tue = Mar 11 12:36:53 UTC 2025 build time: 00:04:10 That is a little over a factor of 8.6 . For reference: beefy17: Queued 36539 Built 29757 Remaining 4657 Elapsed 222:10:58 vs. = 74:19:29 beefy18: Queued 36539 Built 31255 Remaining 4685 Elapsed 222:11:05 vs. = 96:28:10 ("vs. ???" shows maximum-Elapsed for a completed build not involving pkg = 2.1.0) beefy17 looks to have an overall Elapsed-factor of slightly under 3.0 so = far. beefy18 looks to have an overall Elapsed-factor of slightly over 2.3 so = far. Looks like these 2 will be the first ones to complete a from-scratch = build based on use of pkg 2.1.0 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 7 15:14:55 2025 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 4ZWXnY5XFdz5rQtH; Mon, 07 Apr 2025 15:14:57 +0000 (UTC) (envelope-from bapt@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWXnY4yrKz3kL1; Mon, 07 Apr 2025 15:14:57 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744038897; 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: in-reply-to:in-reply-to:references:references; bh=SZWWA2dHKBfAFJMPQuZhbQEUK/7EY17tuebAGNh7daY=; b=sU9qh5FfZngbsMpwp8ZYcxy9HMfSTENWWsN+XOJSYJd/Ls+SgIvfp5KlYdPovqMPRx4XTO 7p6vWOJlmSyFQOzH/4lyICfZFujtz4VnMOMwwk3xY1y1e/y0aWIohkQpHETjZ5Zi1iLKHt ZDs1C3xhgQLllEJY3XZHwN98LB3rsoIeTz8vJlnEQ06xjsQBR+0sHafgMbnUZmPOd48Y6k WGNZjocDQwpj70AJ8wzVBwgqibgRi4s/j9I+1WkYKKwPNQ2YH96Q7hK89L3vn6UcQd5zHl xKyz0XuEUfg7mliYhZlgW7rztOoKSshs4M8FNX2QAHW5gWQyiPCO4+BXq6fa+Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744038897; a=rsa-sha256; cv=none; b=fBTKxTwBhQgfHYeBOBX4CUy9oOOtLtR4jFmPYGZ3BqO1+Hv7CdQwkyI2x+eUESZD+rpQJg Y/zFqqShpZduKSZFFIsElPJLyzOghwaKsMT53N8Bcw3qlu3rVfKG4T+IiIseMFWbtajhH8 xKaZ0mUYVVYny/RLReeVVLsgxnm3Uf3vyDGoVEuIJ3SHvGSVu9enUlgOyvfy2Pykg7G1zS EBdQFrvjLydhrzC4zzFMojjoMWmbCg6T3mjNuwfOAee0t8f5SoIjFXqzv34Y03EZKb6RBl 6zcqZjUiCOmW98jqhzwUSfZ6eQomLobeYne3MucsV9sdq+H2WedAxPUojPydjw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744038897; 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: in-reply-to:in-reply-to:references:references; bh=SZWWA2dHKBfAFJMPQuZhbQEUK/7EY17tuebAGNh7daY=; b=jqi+dA8Uc5c5Isd1i5CGyWl7OI6bJJzWd9IldGVksCIp3kuxEvJ7wofcO/PCLOxZgm5d/h ypSovqV/PexhQCFku4huBbHodTs5zJYTyZOVxvRt9FHkzcO6NAhLadI2NO2qtXTOZZ2V96 R8ThV/CKCZYx5Gan4/1cuhV52AnFHwT17AwOygB6qBONNUTt6aS4PfoRUJ9AHX5+4hBhZ6 eGrXUxVI3O+48mv6Xbev0vT3yD+vHQa9Ug3Irv0wW5HjeeyDl/vUEX3VXC/4vQdRAjwtxn 2L5RaZMoLU0Q1uiepHl8AHPb7/mEP2PgERgnaTqmpl0UhNVWRYp0mBNvK+VpIA== Received: from b.nours.eu (b.nours.eu [54.38.177.57]) (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) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZWXnY3yn4zBh0; Mon, 07 Apr 2025 15:14:57 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by b.nours.eu (Postfix, from userid 1001) id B1AC785A0; Mon, 07 Apr 2025 17:14:55 +0200 (CEST) Date: Mon, 7 Apr 2025 17:14:55 +0200 From: Baptiste Daroussin To: Mark Millard Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] Message-ID: <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon 07 Apr 08:07, Mark Millard wrote: > On Apr 6, 2025, at 21:11, Gleb Popov <6yearold@gmail.com> wrote: > > > On Mon, Apr 7, 2025 at 2:44 AM Mark Millard wrote: > >> > >> So: 2 min 31 sec or so difference for overall somewhat over an > >> hour, i.e., 151 sec or so. That is under 1 sec per package > >> built. > > > > If the slowdown comes from handling shlib provides/requires, then this > > obviously depends on the amount of dependencies of a given package. It > > might be as fast as before for a package with just handful of required > > shlibs, but get exponentially worse for giant ports with a lot of > > deps. > > Looks like a good example of a large factor in the overall time taken > (a factor of around 8 here) for a specific package is beefy17's > recently finished: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon Apr 7 13:58:19 UTC 2025 > build time: 00:45:07 > > from log: > > https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pad39cc941617_s7a490725045/logs/gnome-metronome-1.3.0_16.log > > I saw this showing lib-depends as the stage with a large time figure > but it had finished when I later went to looks at the log file. > > Compare that to, say, the 2025-Mar-10 : > > https://pkg-status.freebsd.org/beefy17/data/main-i386-default/p9229caa5b2ac_s780a4667bbd/logs/gnome-metronome-1.3.0_16.log > > reporting just: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon Mar 10 17:46:22 UTC 2025 > build time: 00:05:36 > > There is also (beefy18 instead): > > https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/pad39cc941617_s7a490725045/logs/gnome-metronome-1.3.0_16.log > > with: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Mon Apr 7 11:49:09 UTC 2025 > build time: 00:36:13 > > https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/p9229caa5b2ac_s780a4667bbd/logs/gnome-metronome-1.3.0_16.log > > shows: > > build of audio/gnome-metronome | gnome-metronome-1.3.0_16 ended at Tue Mar 11 12:36:53 UTC 2025 > build time: 00:04:10 > > That is a little over a factor of 8.6 . > > For reference: > > beefy17: Queued 36539 Built 29757 Remaining 4657 Elapsed 222:10:58 vs. 74:19:29 > beefy18: Queued 36539 Built 31255 Remaining 4685 Elapsed 222:11:05 vs. 96:28:10 > > ("vs. ???" shows maximum-Elapsed for a completed build not involving pkg 2.1.0) > > beefy17 looks to have an overall Elapsed-factor of slightly under 3.0 so far. > beefy18 looks to have an overall Elapsed-factor of slightly over 2.3 so far. > > Looks like these 2 will be the first ones to complete a from-scratch build > based on use of pkg 2.1.0 . Listing like this is clearly not any useful, the problem we have is the performance changes depending on what is happening in parallel on the machines. which makes the performance issues invisible on local poudriere if you want to test it on port A or port B, if we want to reduce the performance penalty we need to be able to make a reproducible case which can then be profiled, to know where to optimize if needed. I have tried to reproduce each individual case which happen in the ports tree and I am not able to reproduce them, so impossible to know where to look at exactly. I know what is new and what causes the performance penalty, but not which part is causing the super extra penalty on the cluster. Bapt From nobody Mon Apr 7 15:59:01 2025 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 4ZWYmZ1vSxz5rVMK; Mon, 07 Apr 2025 15:59:10 +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 4ZWYmY6Ctzz3tJs; Mon, 07 Apr 2025 15:59:09 +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 AF4578928F; Mon, 07 Apr 2025 15:59:01 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 537Fx1JY002835; Mon, 7 Apr 2025 15:59:01 GMT (envelope-from phk) Message-Id: <202504071559.537Fx1JY002835@critter.freebsd.dk> To: Baptiste Daroussin cc: Mark Millard , Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] In-reply-to: <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> From: "Poul-Henning Kamp" References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> 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: <2833.1744041541.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 07 Apr 2025 15:59:01 +0000 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4ZWYmY6Ctzz3tJs X-Spamd-Bar: ---- -------- Baptiste Daroussin writes: > Listing like this is clearly not any useful, the problem we have is the > performance changes depending on what is happening in parallel on the ma= chines. Sounds like increased memory footprint to me ? -- = 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 Mon Apr 7 16:05:48 2025 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 4ZWYwF751Vz5rW4p; Mon, 07 Apr 2025 16:05:49 +0000 (UTC) (envelope-from bapt@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWYwF4zjrz3w5s; Mon, 07 Apr 2025 16:05:49 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744041949; 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=qewJ3X47av7wlASuwGYGmUIo5Mmik2EhSzt7rTI2vJw=; b=m+M6ANwLOJ8nzWtkbTEtlXQs/oo/x9lqjNXGtqKthkFKSNIL4OOGA4ayvo+cyXyT//b5Ih XCRCQt0hHhlx6hlu2tjnu5f/l+jTNIVOa/0ruwO/bj/rqxBJgmXR0n+OsX/qxkZe9eESI3 VouXcUi3cTmaWqZhVg0HP90J0LgAdsQjaGQcBJkRVs/ZnKTkxk96QE24rpIQstqbVVLUOd rMdYtxku2PYCc6v0K86jNEOZ8AA+pJDjhKxuF/Q5Pr6zu1RYzC+6hiFMI7ulyBc69VBJhM fztBfr81bgNje3zrUcjAEBcLY0lO1q0rfkCed7huJa421U5tZwEqv3dF4vHaiQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744041949; a=rsa-sha256; cv=none; b=UB3+oqTNOqlFsA9ETtgIfm54tvQfv5N5O4szOfM16G5pSr878i2ykEeZFOEEXVCqYmvQ6d P7c405/Eb1fzd+XCIJ9AJRT/dcdutF9cYgRLh5m6IK0eJMV/e3oca/5lQO6Jv7WbKIokoZ wHhKsTfIhaMYzvHsM16+PUl3tGzdrmUwJOdCFNXBF7GyBE/dZoOoU/0ZnT6m02DZ3xlZV5 aCKZ2vkpKJ53Dgr2+rz3Qxw/9cmVxO2xvL+bdafEsYM2YpPoK261Nyh64fo2eYFYQO/mX6 mXN2YweZ5mI1htWZHXFRoypZGh6nKFrBeUF/aOBzuCzaxnvjn+bq7q5VyTGNqQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744041949; 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=qewJ3X47av7wlASuwGYGmUIo5Mmik2EhSzt7rTI2vJw=; b=GJzCPq4TT95tLMkfqeySbDWcvoSjZY4pKKQ8KBpFFVVTumNhrTTfIBc+VHvAr2SEzUrxTD olfLe0Dor7jYam45Dh7ROgp2dcqhtW2+czOblw1basR/hWSs6cCufBqPt2xP7IQg87WtLu iZnJDZLp4CXAaOFHMPpaNKWvBVWXPn7QkaQcSW4CECgha0YlK5H+uiSItcC44hMPsV/cPW CLdDgAa0u0gt0c7ykF9xQrMaFK+F0xF1skK3VCMPMJ31o2qdVAOab+1FrWzkfZyGz9GkGk FBBhtHoFjMZOPkXG+hkOf80Vkt0bf+YvNIJjXfuD5gYu0+hGd4VOFjMWTYBIew== Received: from b.nours.eu (b.nours.eu [54.38.177.57]) (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) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZWYwF35lFzBFf; Mon, 07 Apr 2025 16:05:49 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by b.nours.eu (Postfix, from userid 1001) id 3E2D68614; Mon, 07 Apr 2025 18:05:48 +0200 (CEST) Date: Mon, 7 Apr 2025 18:05:48 +0200 From: Baptiste Daroussin To: Poul-Henning Kamp Cc: Mark Millard , Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] Message-ID: References: <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <202504071559.537Fx1JY002835@critter.freebsd.dk> 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: <202504071559.537Fx1JY002835@critter.freebsd.dk> On Mon 07 Apr 15:59, Poul-Henning Kamp wrote: > -------- > Baptiste Daroussin writes: > > > Listing like this is clearly not any useful, the problem we have is the > > performance changes depending on what is happening in parallel on the machines. > > Sounds like increased memory footprint to me ? The memory footprint should not be that significant, but for sure we allocated/deallocate way more things. so clearly this is where I am looking at first, I have an idea in mind to improve reduce a bit more this, but I need time to implement. Best regards, Bapt From nobody Mon Apr 7 16:44:42 2025 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 4ZWZnX3YZVz5rZDg for ; Mon, 07 Apr 2025 16:45:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 4ZWZnX1JkHz4767 for ; Mon, 07 Apr 2025 16:45:04 +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=1744044297; bh=CDbTS01qpohfnfM8Q4kphETdEvhrt1bD6wQEXRI17P0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=giUlaReTFKAX+UJ1fQ1Uoglzi7SgRNGimRfUsQgL1E+Nsf+053oQiWSzs7hC/aeLEudk4Mutz2/PkAPEFU6yv/JAi0MfOuhWWRuuuZRbd9uwh2FcV7iODxg+O0N1/mCwcEX5vtbSSt+Gacww/W0LQGhpGcAriYrqK1Dt6srC9JYRURzR7Vj3u82ms/W4SgHDhcJMoW40sEmhLXYE+cBBJ48KBEY85X4GT8v+dKHUsW/S6yJIfiRQGXnw9V1YEYDF+bUwkqpOmeZxwNQN/joIh5bhrTEcteU1eWFqLG4czWXQKKovq9Vr5mFl9S6w1XM3TzqLsiG8FR8LHTnld43F4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744044297; bh=albLPdcu2GLeNrzxrAo8PCYdqFhVBuH+fM6A2NB7hAn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DVfgQD0Kc9b965BgSsGqddqCCS1vQZxM0f68nl6Fq7Nm3Hrs7KxswVdjFXz0JLncKmr5Dc4PAtdNS/SULnZkq9D1sHjMWjH9sDXqjyxH7lZo4fh2Tk5dF9UZqIyRYiHK1N3MV4Kg6KUKVBQtgrcKbvt8gNhV/Ufd0Bn2BaIEO01yT8EwyMdCX0XIilgtFayn55l9Hkf4F7H0kYnX9PUMWzmaRJSelPSN8wF/RmSbnY2QIiLLXZ9kQfvpF12YrLW2XOBFjY0KfolQ8WYyx1bjFxb3s+xie1GrNfvfTZCL3zG2TbXiHdDJuRD2E6A68gkJvoY1mkHRFBGu1mAFI31IxA== X-YMail-OSG: AncgcqAVM1mm8EQprGXg.H1FlYGAbSur85JAQLhrcqkUv9z6g9u_F.55Wm0VxS8 IdTFW6nSDGIlAkkuBR7yze9m58zgSGpMV2Lj5JFyNRo9cyRz4izTkgOigCG60.oqrvZjm2YcCzlV ggyBjSn6lIKg7PHqL2TYbx0WXU0brlOYazUWZDbayW96YrAWxkVGECgIdhD40Jf3BNnk_GPVtcJk 9GJdKYMXSNuZ46lA4yDBWfiml2PO9rgnx.G5TNVUeng.lLFOvNwb6Sux7DrhhJTTINoLbENaj6VD gHFVeEr_1ZHNb1LqY2vTqxaVGqVUxfBh.dri8Z46eOQVMHXjiCHN.XK6DOTK.GQwtkLfll_SBUPB DNtgZt5.lZzC9NfigcFoOZXTEq0qeqEbWD1PY_mrOfQoPcviwaTSfhcToNMnIRmdDNWUMNCduWeW O.neT4zykf58u8nYd_vI5kny0CXZfEM0mg7HwyfWCy89UtA1xlbC1Ag2NjXbBdOXELsCbYshZF7y omi0LiB7xRbb4cxkR5r.xueFCF6.MKy.itthl6T_JWtug2fQmCD8RpjfWVIDums.hZCgka15SjCh wGNk8WGzsCNTilEqOsvkrFubg7fmyoUUGxpLtj6ll6POG6pMV2SXxKlcvlslg_s2WKfj4WIGfsYU 9xxBKd.7YobZ__DIH.2L9wn5W96WRjcaFPqxBc3gRV3peSMVf3tjUKfsTLpSrhKweUH_7WcmzzP9 Vr1jczGL7M_QdB5Bf5SXmRQ.fXCdOchrY6azAR8MNKQlWvdvUmxQSGsz.oLYApqVxPM4d8ZJKeo9 qkomQUOoO_bELxs5x5KdZ4hjvMXfVXlkDmitI6uUKc0HFU8tXhtfTvAdTdj4KPlxPmTBz33WTWCO eWeUJCySj.daurkIGeCs8VCnnitToT8u8L_7vyWc.jggoMs0lRP4ukwn0vGJqgug27T5ZKVOsNeb YYeSRhUxDmm6ZesGFEs5Sf2L.jIligDrstp3QROvlk56vAEZg4DHOF0QoHyiDYo1m2CSRA7QXXTl cEb3LUeUFkdv_FtBcxldtnWyQXRm7Q0GQaz_iWYOezOqecLVbO7D8tSrqcR2MZ0395JJH7ki9ys4 TF6RiZKnFeXwjBK_5M0R8O1V2A0nO4GInDR4MltzWQW3TBJmMrOaeSMT1x__U1oYodSnkRohxV8O XyIEFW9cMnCI2eq8Sno3L5.hP9P_bJoWauq1h2VHEfUze_hYEtVw7dn6QJnMvVap2ap1pOeiSogl 8VjLneQazafzHY7x34IY9eNkbyBSxr3GgsCE7l5rGYsyo_E9Ft5Ak2TuNdIPJIK8EfBwH6snASMk OwfOAOzllKUuPVFJlAFUZDzR1VhA.sW8LYEArH9nRVa6_g6KdFpmgMbVtYN.s1OkotREc33bkO_O saiKS1AXu03ioLQcjN00cN0QM8f61auPyEMJAZijS0.alixc.kIaM3RQkZyOTCyFkcaafe_vDXwP .ajX5jZvnBCfME..CFQK0cATcqf37qv4vg29aP4eXfzRh3oaYal1EICgmG2_za5b4DREaMV_iA_C usb1WjkBW0VCVz.xq2Qtr_jINkXis0f1v3jtRJ.c9laMd8C3t0LyJ6nxxfLBgZuBFsoj9xqQDKbX HYO96ze0sE7LkZ.5VhjENjoP3NZRWm_0E_H3VtV87IjVmOmxjoSemob9GU3hO9_MJbA6zt14dz6F BxKM7V550MC61u_Nwj5QeYb1bYAL_Ctq2sRZZFKewMhSq4zlsqtiqp5rwGfzv1ct2nDCqhEhMB3e GgQ8o2TfLVMenymhi0jsy4S06vPNsJOl00rdyyUlZr1Caq7TvD5YkUTibA5tPhYL6X1L1pE7skZm QsrwWXPkve8JyHxr0DMKW8tt0TrMSIWIhNBdhQLtH9qVnsqT_.aC5ixNuK9B_4b63b3.qKqLU9SF RSRv0g3bYywPfUEkq.O.A5MvrCIVsl2vlB2AxF5VitF2eJkGkPG4fFLVHqo5EymttqmRB4t.Kziz rLvpDbPmAuuTGb01cMe0y1046yjdqrEO5DxRHL7P2wRG4BoV4l3Z90kMBxJPvlS7I_HsQBpFUMwX Rer0sG3oomy4k0jOfyZ7E9CsZc.YAAbPqaYP2YP3ElHNU4nqA7YjxBBRMbvu5TVPT.WfQQNn7EfT gr8lNjvcUwQRbWRpbgoL7OctVGdkEupQD9cb4hsL4Rck6eIUrtj3M35UKFBBwpoY.LZZBCA0F3Nr Whvt0Ft.4aAfA2HiKs4_iIusAtNZLzrKOSI6Q3awxbxDIPWBowe5Lt1oYTR7Mdue_3MClbY6Qn.V xCdw- X-Sonic-MF: X-Sonic-ID: 19697dfd-c176-4c57-85d5-742e5c25fcb1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Apr 2025 16:44:57 +0000 Received: by hermes--production-gq1-5c477bf655-fdl68 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9e7bccd7b090af4b235397afeb50e73c; Mon, 07 Apr 2025 16:44:53 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] From: Mark Millard In-Reply-To: <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> Date: Mon, 7 Apr 2025 09:44:42 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4ZWZnX1JkHz4767 X-Spamd-Bar: ---- On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote: > On Mon 07 Apr 08:07, Mark Millard wrote: >> . . . >=20 > Listing like this is clearly not any useful, the problem we have is = the > performance changes depending on what is happening in parallel on the = machines. I've been exploring looking for an example that reproduces the timing issue via commands like: # poudriere bulk -jrelease-aarch64 -v -p default -c www/gitlab@ee vs. # poudriere bulk -jrelease-aarch64 -v -p alt -c www/gitlab@ee so that prior builds are not involved in creating such a context. Also, when www/gitlab@ee itself is building, no other builder will be active. I've started such a build based on a pkg 2.0.6 /usr/ports/ context and will try one based on a pkg 2.1.0 /usr/ports-alt/ context. I'm trying www/gitlab@ee because, on beefy17, it went from: 00:09:01 (pre pkg 2.1.0 example) to: 05:35:01 (pkg 23.1.0 example) (so somewhat over 37 times longer) and when I looked it up it has a huge number of dependencies: # pkg rquery -U -r FreeBSD "%#d : %n %o" www/gitlab@ee 298 : gitlab-ee www/gitlab The factor of 37 is large enough to be unlikely to have only load averages on beefy17 as a major contributor. Given the evidence about the count of dependencies, I will see. what I get. The test environment is a Apple Silicon M4 MAX system with FreeBSD running under Parallels in macOS. [00:00:07] Building 943 packages using up to 14 builders OOPS (via checking ampere2 logs): Looks like aarch64 might end up blocked for a rubygem-redis-actionpack-rails70 "Phase: stage" failure. I may have to set up a amd64 context for such experiments. > which makes the performance issues invisible on local poudriere if you = want to > test it on port A or port B, if we want to reduce the performance = penalty we > need to be able to make a reproducible case which can then be = profiled, to know > where to optimize if needed. >=20 > I have tried to reproduce each individual case which happen in the = ports tree > and I am not able to reproduce them, so impossible to know where to = look at > exactly. I'm hoping to supply reproducible steps. > I know what is new and what causes the performance penalty, but not > which part is causing the super extra penalty on the cluster. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 7 17:15:07 2025 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 4ZWbSg1Vnrz5rcLd for ; Mon, 07 Apr 2025 17:15:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4ZWbSf4glvz3GPH for ; Mon, 07 Apr 2025 17:15:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MHSTMFqZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744046124; bh=NWL9TZ9UKpM1Ijzgw/xUg+cv+1CCFEKaHg7eBgWTam0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MHSTMFqZJjNKv5V3xs3Zw7qJLXr7y9QenUWPWm0og0Mb9GkUzEY4GAbf3By4MYNfXFa9HocUn8z4iQ8qrJtErKIRSiDfFRfOzo4hg2JTCGGD1a3Vd6+hER1fm18Gar4LTxX/wjV216KHx8NOdQ32Vt7Y1+iQqR3OKC8VHDFnIg24EstzutsjPHHMY27g5KWx2Yzdx0zfB45txJkMRxCat1WNEHD2s8gs6+7LYXft2KgfsqsuNpylaw+Sa1YUlNfdRQRNEq9CUHm3nPAIq2ndWIOsFm3/2RQj/OfgptUZmtM/UVfi/ldN2xPavux05ex76xshqH0jnqBw6BmrU/fCHg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744046124; bh=5Ab74orTwcbb574c5nhXIeMKbR8c5XqI8C1LodXPDlm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WU3Zt81/M9bCMtxOY6EcIHtoK4Gty+k8cH2+MATVMjtZ2z5JCYUxrobNGQhMpIui5strEJaOjmkyOLaQlohgzkH1c8Qa/1wcLLNFn203F+cC9v2Ys7HMkCj98fHUDl0K4tF0KzH3/LD8NYxEs29+efw27fgk0/4hTSfVtI3SL/tHThkw/hba2DntzqUVbS74KTKFv/2bMTv40gVsuDGo2aNE0ebQqtrbccF7dxL5NaIVJwcY+O3ubPEGMOx6ReWdXXPdgi0zThSd0tAX0k29bAxMLUdQy7Q3QhT33D8O7PmPh0gR8PL/qLAllFbiFDP6aTiE7Ipipztc5ZTrSzyVHg== X-YMail-OSG: QdDs5lEVM1n9xozsSMZ0n_az1NGa1ksB2xK8Mb3cwpS7_NgI0SM3.x6RolCAE46 6qJpz25c0adIu4Tgaob6taOD3UVwMfnq1SXFnPGzNWWhl_IYIguQLmQw7NivNJ98_rZWc79R3Z4c V9l96xE_GIzCXSls7FhwZsrfa0.TZImdyAxb50uSlvalV..cePwNqiCSAOQDZsWnG92eEFldMZGu .FbrsfCFSxBc50nlf2IxExk6FH_Se6oSBr3ErBSsh5CLoNds.b8KJhtUkFQeaWqsmjFr2wqHyOgS scWRJ85YDBonyeRMZ0qcPx6h1Em4rdFy9frc.n2NVeqkELfXDnM6alWAxtA7NxCYuUNPWWzxKFiU 56KDrEpr0ZxhsNaqQmdECkUxxfNt6dDhyYerrB8fy5c_NBafNTLNmDYi2dOjkwxcMiZcM1CyJ7tj MoHWPPzC25ZMLWNl5wS69jUPRt9S42Xwf43c.fbJ.4V7Itx6T5Xp1kJEksA.AHbUcTRnj.D8APP0 p9bWTpz9QF7ELRfNjTb8esDiOCC3tVxuh3wW8Yx8gb6_ePcJFo9vyR0EFpEgSPQfQ0.MjDhXQYhE LOncaQATMviBqfow_etf4SoiWljiYdX7tbfldYLTS9UMAmlv_bv.ediLZndB2LvSNercR1uQhzeT 48roXuiA00JTKw2b8C6rAxm4JIbLBp2NX0uSZraIGJbV1UacnC8aTWUSoS2O4XgGZp98pNhJM4r3 YgyyQqJq5.CvuFQGDGt40fhqprw5fpvWt6UziRHmlc75L6akjo0PlcduiasBqhal.e8uDcOIGJpx l.jLpFvb8glRnaRKcmDS5Pc3MhLTtqgPvop6DJQbPVIsb2j4b60suM6lUlM.NyufNKbFfqLjE9S8 2pM0JdP1GMrgVopSRoHKl3hHWFG0wxGRzcsXfk31adUsBNQDVq3XuTb5pUAf93THJsdrnNFwdgOO QjM0y4WRsfhAteXFZ78WrRaSWAz388J7_20WzDw.gjxJcdqFJpp0snrCroXFQcp.bAF_db5GyHml g6aaWKsv3sYDjC9RA3n.qGT2EdfFS8pEs5LtnAItumrF4EB4Ed7D8OzSYl9UkpbtN33uZMyumepK zuFK1J4VxHE7yGA8j6088QE3VezU2yOwEUrFFdOwyF2Xr9nmK_RHkK9__8AQYclvGE8HY53U39Yy QCE5nN6hr5ZUPaUFfKKJFFErhMBC5uNym5c9SyPgssgIG8Rgg.7pvX1WvASNclBPfcfnRXg7gbd. Srp0YV9uM6oyqje5UsPoM5Qp4IZJz1WFO2070O_yaUBQ0Ig7sG5CQDm6noaSe45WNp9yU1l4rn6s PbFuxxiIopnr70AK2qD9I.cEd.hBIBnDKJqcjXOpKOh2.aB7JkGyQt0OcBf5Ml1JFedLKXvi7ouf RwixOSVw4Bv_xWBtIesTKa3ZNr9OowMxa0rmuLh97JCFVPLdeSL5ODab985tTrPFVs1hyR1rLLQ5 PMKj8lA7hJFyoHtHQvFULLVBOm6YxY8ixI2vKNAZc5_qiFeJHjlPwN7vxBVmV4NExwtJJCEHONjr zPN6we4q4u4XptaVhR3VJLHzjkdOCRPAQL5AzExZentN7Pp9zHAOiaGgHyoL17mavYXM1OOWSgRm hiOzO_L3vJe1rNdNecm0RtE8mPoc2s1MtSOni8JWOQoVDMfQdhV5DPqjm.yLBPOWYalaUx6mtWn1 lA62FQaCk9PCZo5JuvNJJrdgUNDa2F8GZtFXj9OusW4d6UaUyDnQtG6sBtvEBiJT_it73WK5hafw Wj0Yv2Z4eoDUhtuz0T9ExWIgP1VPpb9GGu9P80L08UHkFMaZkFhb3lKeu82fKyZTvt3QT.NSWQeJ F12qcmJk1NZ7nqVS8V2HefqZ5pwGpoMaT5e9VtVSXA7CxIl78llN46Sv4k_FjGXDD3ydnJ6lslB_ V4WNd8eoyhA6XjnkbXSQQX1uuBz3nb8K_G2ZMz2YQWj_Afxi5nKG9SHHU8B7ri90sDG5aJs.N9P8 UtTbKClUvKrbBJ_yV.Z4I1yM76mZ6K2yGYBpzbzdQ4nAesKX2zkFow.VZc2RogONT2yv9xwX8SC5 hfR6.FUR2sH3mfH2LGF4QCh3ciS42gOkbTNQBMEfyrFdy3zWdh1RngowAY619Ygeu.IQlPgad6LE DPgsxAtqmb5tueXAjgLJTZ1zgFZrCcXI.TZKmUEilxaf74bq6mPJz6Yi8Kr6hjFchVJOMxLTPc7X dAeGuWCkfVrtHaLmEcQfqVZ5kiiln X-Sonic-MF: X-Sonic-ID: 4e2e1eaa-f17c-4ec5-94f4-82beb273c498 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Apr 2025 17:15:24 +0000 Received: by hermes--production-gq1-5c477bf655-pf5cp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c7dce3d65c4c384637c4d818d1708b89; Mon, 07 Apr 2025 17:15:18 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] From: Mark Millard In-Reply-To: <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> Date: Mon, 7 Apr 2025 10:15:07 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-3.25 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.83:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.912]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_SPAM_LONG(0.16)[0.162]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZWbSf4glvz3GPH X-Spamd-Bar: --- On Apr 7, 2025, at 09:44, Mark Millard wrote: > On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote: >=20 >> On Mon 07 Apr 08:07, Mark Millard wrote: >>> . . . >>=20 >> Listing like this is clearly not any useful, the problem we have is = the >> performance changes depending on what is happening in parallel on the = machines. >=20 > I've been exploring looking for an example that reproduces the > timing issue via commands like: >=20 > # poudriere bulk -jrelease-aarch64 -v -p default -c www/gitlab@ee > vs. > # poudriere bulk -jrelease-aarch64 -v -p alt -c www/gitlab@ee >=20 > so that prior builds are not involved in creating such a context. > Also, when www/gitlab@ee itself is building, no other builder will > be active. >=20 > I've started such a build based on a pkg 2.0.6 /usr/ports/ context > and will try one based on a pkg 2.1.0 /usr/ports-alt/ context. >=20 > I'm trying www/gitlab@ee because, on beefy17, it went from: >=20 > 00:09:01 (pre pkg 2.1.0 example) I must have clicked on the wrong thing for the above. Looking again: build of www/gitlab@ee | gitlab-ee-17.10.0 ended at Wed Mar 26 10:27:22 = UTC 2025 build time: 00:13:50 > to: > 05:35:01 (pkg 23.1.0 example) >=20 > (so somewhat over 37 times longer) and when I looked it up > it has a huge number of dependencies: >=20 > # pkg rquery -U -r FreeBSD "%#d : %n %o" www/gitlab@ee > 298 : gitlab-ee www/gitlab >=20 > The factor of 37 is large enough to be unlikely to have only > load averages on beefy17 as a major contributor. Given the > evidence about the count of dependencies, I will see. what > I get. >=20 > The test environment is a Apple Silicon M4 MAX system with > FreeBSD running under Parallels in macOS. >=20 > [00:00:07] Building 943 packages using up to 14 builders >=20 >=20 > OOPS (via checking ampere2 logs): >=20 > Looks like aarch64 might end up blocked for a > rubygem-redis-actionpack-rails70 "Phase: stage" failure. I > may have to set up a amd64 context for such experiments. The above looks to be another example of looking at that wrong thing. But, as I'm using 2 different vintages of ports tree, there could be an issue for 1 even if there is not for the other. >> which makes the performance issues invisible on local poudriere if = you want to >> test it on port A or port B, if we want to reduce the performance = penalty we >> need to be able to make a reproducible case which can then be = profiled, to know >> where to optimize if needed. >>=20 >> I have tried to reproduce each individual case which happen in the = ports tree >> and I am not able to reproduce them, so impossible to know where to = look at >> exactly. >=20 > I'm hoping to supply reproducible steps. >=20 >> I know what is new and what causes the performance penalty, but not >> which part is causing the super extra penalty on the cluster. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 7 20:15:42 2025 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 4ZWgSy3XH4z5s6M0 for ; Mon, 07 Apr 2025 20:16:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4ZWgSy1VDsz44Vg for ; Mon, 07 Apr 2025 20:16:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qdzB2SoX; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744056955; bh=W9QOVogsxHtkt7GvaOzwWUts4IX/vfLLkdo3X+0nUjU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qdzB2SoXFQbT/PrpITTiWeFZjC51Q/1BJ6WJdsR+avqtg34QLboc04qmkY37licKpvtXACrlXFrHXoLDfPL7RCvA/41o5Spdb18ltxDCJ5Ek3IF+R9VXjBckzcfHhShWu1n2a7p/EijlHNgknoI8cm2i5Cf86WAKc8BabG0frNkNrWoLQQwuOCR2+wzEYp+TaVH2yI8xQiJ+GXUCP3PLsp6FHY/YS65YtRQqDgV0V+BDzxibyOnMFCgxjcawJ2PrOHCI8xLMI0jF5WzaDySM3tVcqmkMEB7GRH7iZ9evJgaoG5/XCBpqYODJc8BsbnuGhiSDVkn2Uc7cFeYsdSbIzA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744056955; bh=ZGEyxkN+Rz3cNLUV1OLHM/dQmOMHI7fCEvlW1S6L4Ot=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DfeYFGMFzBA5iD8rFIq7ujmgiDu5YDci93gtVohjZ71NbKKCuFqwON2UtEzTmkNDNt8FB+fBVMPF5rVPMMOItVLChCIy4KBf/85jaTojs/6aAVzQhaCBXBiRzPlA4VKDJ7+9gyHpPyImPqc9mG4N1HtmpzJHUZ1E3EkQJFvWoeYjZxlaeckMsaK4px00OKJLHeLXeFRkeNCpfiIf3/ntxgdpg0rTIbLHnp6uG2WHGWo0KGzxaC9eLRwkdwGMcjmGp8S4XCTp+sptAmFjyCoSRTSTi0E/avAn1p86gzG4olrcj4P7CLhglkhGGDLV6IdkdatIf8WDdRu0gxpv/xZdWg== X-YMail-OSG: 5VX6Tl4VM1lYlpjmiTjBHPiF4w.k8WVDewar.LmpP9DjGHa2WlegYlx5.wmc615 nH7MzjWWKcq5inh4tNA.qq5WkHSME62IooBqkdOvzu2NSDVfdpWzZeKg8I5_rYTjdfMSiX9IC_pr iESwwtu0FfeXVjgiyj7JVai84inTTPtr2ncIHRlAqaIMn7XWe0.8MAAp7DufyVVsdYHnjtRayLHr m4rwOFZESQnC1Yiq30GFeDY2yD39aCcFWw1h_Za2EYJ.ikYz.3jAQcArQTO2ZTdW49d9NYFj3Osz 5YWCmdtV9pCZYIUn1suv1WGnu45boioBK.nLU8szWAhm6dXV3o6lzvTbYbRPwDLjscWXaP6yUPjg ..9E5KdB3n38MiEK3nLQo.fNmcYqIiOjplo7By3e3O.Dqr2T5FwGrCnVYQ6rtjIa7h3WyVniVKGn r6bnheVyqv4nDg9vE91D8KGeU_.MFS6MTWCoJ1Ww9jwbeKImyOcYGRP6VR_uJwaS4R4LqqQR2PDX rEiTVVractBsDp2Li6IOfzoX1nKD0ak6rADzIeoyIxsCkfOs0TlIGOrgIl5zr8lIfRkuGIPeMHzF 0jMOcxfyx9EeCE1DNsNDO_U.0kn2FtD6D1g3nLxZRTqOGGiI3pD.45W0HiUNRg4.KVosTVYirEwS KhrmfHqUGq7OkJaO9ViKGDLJYRNooui_WwkEwSsandzZLEqUWG.A23iucRaAPRZM7pz8oI05_C0K paRmfalPRrAHj4y1HWnOt4y6GOKaawut8TV07q5CeheV23cb9EAyWwrNeE_uCdDRVM.6_dGuimY2 0XFiK5pwyxTpm9TD5f2sywSHqyyC5fLXKdxFDONfMxIARhwr5I6gSFgzZJrQyWVF7j26bad_GJhU oj7ruGdY6SHofSLKfgIZgtdNisWzwr.JRfOqMjlneLNdKpslZW7ruSmljhpK2_edlFdzv5Mg6rrZ GsIKzgRUZh7Jig65B5ucBN4u6MlbK3RHRtDrWvoop4gjib1ZUFCo7C2gEBzUzcWap4aVtgXfABq0 L0X4GPMZEzJ.Mzm5nTCLhGGV6pB42WKk_diCm9Y9vg04yr1m6MWs8fEtGt9i7BFCwA9OBWse1Onx r_Uq.je9DZL7brlTIri5qYaQSYZM848_pHQT7464lCtKFyYgGFDczMWQwjqSc37rAS2A07kZCjXi lCidd6E2jkNbCGzQ8CLDx3YwHt8uGP_qjUrA6oy9QPtZNhiKT8bDSEoDrpAXgJK.FlQbaXcgWN_f gT5s_LGayrm7rV1Rwd_vJC_KotGashew_Dj6p.xPQ7SiODpnrGR_KzBeom1zLa_5yaEIR4XQUyY8 QbZtrvA3VXQq..PjU51IC.3CjexK.jj7IVchrmmiRNz.8MBFmRb9Mx7OgpLh3Q.NsAkMg4Y_T8kz NI6B.PN8CJMKp8R.ZMZbgsH5nvyon2v00K_pFPsuR_JYB_0aCuxMwecx_gZVW.9r7sQTo9EA1AMZ zrtwwYovr3IKWBJv3DJAb.El721OELniy.DgCPygsv_S_4Q32UGZEE8WXgo.1kfNwlpCsySS0uCe DjWmB1Q5VjovRKgWS6ms_i7BrgwhIutfDG9cDTxoz7tID7INZ7KpUbrRvLZGg87NubWLk.68NIWi Q6Af5pnI8pq86AR7eWpbOsJpApzHATS9YH0wvcRm_k_rIqRpEoVYsNkBsJS62ZKcU2954TuCBXTP kAv9tG23bai4BE6_RDxVOX6eQnt3TAgVepF2B7.nFYW0CawqG4IoSEIsNdt7C1tVrKO0o1cp_.XB vjqCrQSDOcem61hGRnTA66HMY6.0jfkH6ZWJFaROQLrgKdTPHV_jNCxqnqWD8AuQLm69BqekAppi KzIdBXQua309s5fLJoDvGfxGJaz5WKg31KLqqMJtBSBD8ORXRrKCzaDKEBMVdKpoQdSJtE6TXu2C UUHEZkozTK2Ta3YGSmhWSepJ5ifL1eJ_YL9PAbmWLyAliwd4.d_Wy77UB8V_scyuCiGFncR0kibs a4dmkZLi.6gdAyoB.HUUs3gJR419Gt1rTesjola869VREcdj3bkDZeHfo.xcxFGufAsmbpPFtFb4 ITIeFIRaaH3IL4CJrVRUFciGgB.QI0Apjc4ylriSGkDA0QxxOICBqklpLDmpwTe2baXBkFc87Bfj W5pDmR93tSMk7o0safDRgR0RrCigIJbGdYVOeVrfwbyETW9J7z.EoD2xbQ85bmJHpKGKvSgrSYkE hnl177BhtM3lpgfFsN9O.CxGHOnUfdTRhpdEY856msW5KneT31EAWj0IXF_E.nuQtEBpJLWyR0w6 y4mY9.38- X-Sonic-MF: X-Sonic-ID: 7bfaea4d-da0b-4d89-8b16-861af5758c3d Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Apr 2025 20:15:55 +0000 Received: by hermes--production-gq1-5c477bf655-pmr4h (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 06735517be0eb9e79ee2bd30e7713c81; Mon, 07 Apr 2025 20:15:53 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] From: Mark Millard In-Reply-To: <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> Date: Mon, 7 Apr 2025 13:15:42 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.50 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.205:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZWgSy1VDsz44Vg X-Spamd-Bar: ---- On Apr 7, 2025, at 10:15, Mark Millard wrote: > On Apr 7, 2025, at 09:44, Mark Millard wrote: >=20 >> On Apr 7, 2025, at 08:14, Baptiste Daroussin = wrote: >>=20 >>> On Mon 07 Apr 08:07, Mark Millard wrote: >>>> . . . >>>=20 >>> Listing like this is clearly not any useful, the problem we have is = the >>> performance changes depending on what is happening in parallel on = the machines. >>=20 >> I've been exploring looking for an example that reproduces the >> timing issue via commands like: >>=20 >> # poudriere bulk -jrelease-aarch64 -v -p default -c www/gitlab@ee >> vs. >> # poudriere bulk -jrelease-aarch64 -v -p alt -c www/gitlab@ee >>=20 >> so that prior builds are not involved in creating such a context. >> Also, when www/gitlab@ee itself is building, no other builder will >> be active. >>=20 >> I've started such a build based on a pkg 2.0.6 /usr/ports/ context >> and will try one based on a pkg 2.1.0 /usr/ports-alt/ context. >>=20 >> I'm trying www/gitlab@ee because, on beefy17, it went from: >>=20 >> 00:09:01 (pre pkg 2.1.0 example) >=20 > I must have clicked on the wrong thing for the above. Looking again: >=20 > build of www/gitlab@ee | gitlab-ee-17.10.0 ended at Wed Mar 26 = 10:27:22 UTC 2025 > build time: 00:13:50 >=20 >> to: >> 05:35:01 (pkg 23.1.0 example) >>=20 >> (so somewhat over 37 times longer) Make that "somewhat over 24 times". >> and when I looked it up >> it has a huge number of dependencies: >>=20 >> # pkg rquery -U -r FreeBSD "%#d : %n %o" www/gitlab@ee >> 298 : gitlab-ee www/gitlab >>=20 >> The factor of 37 24 instead >> is large enough to be unlikely to have only >> load averages on beefy17 as a major contributor. It is still unlikely that beefy17 had load averages of anywhere in the ballpark of 20 times the number of FreeBSD cpus. >> Given the >> evidence about the count of dependencies, I will see. what >> I get. >>=20 >> The test environment is a Apple Silicon M4 MAX system with >> FreeBSD running under Parallels in macOS. >>=20 >> [00:00:07] Building 943 packages using up to 14 builders >>=20 >>=20 >> OOPS (via checking ampere2 logs): >>=20 >> Looks like aarch64 might end up blocked for a >> rubygem-redis-actionpack-rails70 "Phase: stage" failure. I >> may have to set up a amd64 context for such experiments. >=20 > The above looks to be another example of looking at > that wrong thing. >=20 > But, as I'm using 2 different vintages of ports tree, > there could be an issue for 1 even if there is not for > the other. >=20 >>> which makes the performance issues invisible on local poudriere if = you want to >>> test it on port A or port B, if we want to reduce the performance = penalty we >>> need to be able to make a reproducible case which can then be = profiled, to know >>> where to optimize if needed. >>>=20 >>> I have tried to reproduce each individual case which happen in the = ports tree >>> and I am not able to reproduce them, so impossible to know where to = look at >>> exactly. >>=20 >> I'm hoping to supply reproducible steps. >>=20 >>> I know what is new and what causes the performance penalty, but not >>> which part is causing the super extra penalty on the cluster. >=20 I'll note that both beefy17/18 and ampere2 get the time multipler effect. It it likely more noticable on ampere2 because ampere2 is likely a slower system generally. As for reproduction of the issue (in a much faster context), I also got more like about 26 sec in build-depends instead of about 12 sec. The overall time for building the 943 packages about about 10 min longer. The pkg 2.0.6 vintage /usr/ports/ context got: (Note: There no "Allowing MAKE_JOBS for" notice for www/gitlab@ee .) [01:29:05] [01] [00:00:00] Building www/gitlab@ee | gitlab-ee-17.9.2_1 [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: check-sanity [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: pkg-depends [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch-depends [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch [01:29:46] [01] [00:00:41] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: checksum [01:29:46] [01] [00:00:41] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract-depends [01:29:47] [01] [00:00:42] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract [01:29:56] [01] [00:00:51] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch-depends [01:29:56] [01] [00:00:51] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch [01:29:56] [01] [00:00:51] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build-depends [01:30:08] [01] [00:01:03] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: lib-depends [01:30:08] [01] [00:01:03] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: configure [01:30:09] [01] [00:01:04] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build [01:30:09] [01] [00:01:04] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: run-depends [01:30:09] [01] [00:01:04] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: stage [01:30:16] [01] [00:01:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: package [01:31:47] [01] [00:02:42] Finished www/gitlab@ee | = gitlab-ee-17.9.2_1: Success . . . [01:31:50] [release-aarch64-default] [2025-04-07_09h06m32s] [committing] = Time: 01:31:48 Queued: 943 Inspected: 0 Ignored: 0 Built: 943 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 . . . The pkg 2.1.0 vintage /usr/ports-alt/ context: (Note: There was no "Allowing MAKE_JOBS for" notice for www/gitlab@ee .) [01:39:03] [01] [00:00:00] Building www/gitlab@ee | gitlab-ee-17.10.3 [01:39:04] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = check-sanity [01:39:04] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = pkg-depends [01:39:04] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch-depends [01:39:04] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch [01:39:46] [01] [00:00:43] Status www/gitlab@ee | gitlab-ee-17.10.3: = checksum [01:39:46] [01] [00:00:43] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract-depends [01:39:47] [01] [00:00:44] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract [01:39:57] [01] [00:00:54] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch-depends [01:39:57] [01] [00:00:54] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch [01:39:57] [01] [00:00:54] Status www/gitlab@ee | gitlab-ee-17.10.3: = build-depends [01:40:23] [01] [00:01:20] Status www/gitlab@ee | gitlab-ee-17.10.3: = lib-depends [01:40:23] [01] [00:01:20] Status www/gitlab@ee | gitlab-ee-17.10.3: = configure [01:40:23] [01] [00:01:20] Status www/gitlab@ee | gitlab-ee-17.10.3: = build [01:40:23] [01] [00:01:20] Status www/gitlab@ee | gitlab-ee-17.10.3: = run-depends [01:40:24] [01] [00:01:21] Status www/gitlab@ee | gitlab-ee-17.10.3: = stage [01:40:30] [01] [00:01:27] Status www/gitlab@ee | gitlab-ee-17.10.3: = package [01:42:17] [01] [00:03:14] Finished www/gitlab@ee | gitlab-ee-17.10.3: = Success . . . [01:42:20] [release-aarch64-alt] [2025-04-07_10h44m17s] [committing] = Time: 01:42:08 Queued: 943 Inspected: 0 Ignored: 0 Built: 943 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 . . . This sort of reminds me of an old issue I had on the PowerMac's back when I had access to working ones: poudriere had a contention issue with cpdup activity that made for long delays in the initial, parallel cpdup activity. I modified poudriere to stagger the activity in time to avoid it and cut the time greatly. (Not that such is known to be involved here.) Others did not necessarily see the same on other types of hardware. (I did not have access to a aarch64 or armv7 context at the time.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 7 22:36:32 2025 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 4ZWkbD5V5Yz5sJ3f; Mon, 07 Apr 2025 22:36:40 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Received: from YT3PR01CU008.outbound.protection.outlook.com (mail-canadacentralazlp170100000.outbound.protection.outlook.com [IPv6:2a01:111:f403:c103::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWkbD01y7z3Wc6; Mon, 07 Apr 2025 22:36:40 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=willowglensystems.com header.s=selector1 header.b=UG9pjF4T; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=willowglensystems.com; spf=pass (mx1.freebsd.org: domain of robert.austen@willowglensystems.com designates 2a01:111:f403:c103:: as permitted sender) smtp.mailfrom=robert.austen@willowglensystems.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=taAX7XIahpklFPZNb7VI8DkKQsxWAvtLhLVW/a3Ow9PsGcbVLw6s0MyAjV6xXCBSjgAGYsc4zX+bIridDTsUXrYDxlGmoZJ9NmUOg3ZX4xndwkMpjv2Io9ffJVF8VBO7K4+VhoHiIPLpXIiqRPsWX2EOUywbhgiWQsOqpKh8FfgoExLEPqFOy61VJrpDvGzp3+qp3XATG7sOJT5GXh7GL/zcTXNACRRj0e6yTr2Y9GogtwhEFw+aMKyjj2i4VSWv3I6a/FSAxRl9FlwtsklGOkcKC7Vym3JjcLnpwpmt9TNVPhgp7OfbwkSd05GOvp0sorA2YnH4jgyvKerX+SzIQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mKA2YZpye/L17Jc/kRlwjgkWwZd6+tIIT1UPV+kTTUg=; b=nYWE9D/j085ycss/3zV0dQ95Nuv38VFVB/PeNPfi62BWjASUUvcC+H6yaCYKGj3s/VImZgaSv5h201S56JiNfVqtYVu0OMjDVxhcBBiw0p5o4hhSzzfK9EQ4broosxQCIjcHY77SUeoc/j4jCgzTc5N+9r9sXLuLMln7FoCLpDMYtjR/6OwIwNWxTqdsheWsZu3Yx/C+ZaNiGPpHRPRmRGNUyl6Y526+HGaJcaTvjv5fOwZ6C1E2puW6kVtjqOthsXLECs3jEHwz/U6/7pJmb20P4SfCdgvBl3BYMUnfUBYf3vrWhYPpf6Wey5bj7GvugvsZ0rsAH3gpyyQsiCGchg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=willowglensystems.com; dmarc=pass action=none header.from=willowglensystems.com; dkim=pass header.d=willowglensystems.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willowglensystems.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mKA2YZpye/L17Jc/kRlwjgkWwZd6+tIIT1UPV+kTTUg=; b=UG9pjF4TYmz8WWVgMTRF5xipvCRKXKLQA4379baYJU8i9quDRlmW7fSmO2G2Z9YSlYcJAS1Lc3fX1eKLciPw4h31hRcHRBX6OoVR4eMNVTmNUrnzoi+KBMVDy5jkaOb5UvOaP0mNAm3cY2A1YKW2UqDP541EGNXZAcZetqg7hWY= Received: from YT2PPFD8040D4DA.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b08::48f) by YT2PR01MB8230.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:b1::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8606.34; Mon, 7 Apr 2025 22:36:32 +0000 Received: from YT2PPFD8040D4DA.CANPRD01.PROD.OUTLOOK.COM ([fe80::5599:33c9:6953:d09]) by YT2PPFD8040D4DA.CANPRD01.PROD.OUTLOOK.COM ([fe80::5599:33c9:6953:d09%3]) with mapi id 15.20.8606.033; Mon, 7 Apr 2025 22:36:32 +0000 From: Robert Austen To: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" Subject: Fw: pfil_default_to_drop Thread-Topic: pfil_default_to_drop Thread-Index: AQHbqAfyk4Z18yjsM0yECEK2f5QGrrOYyea/gAAA4zE= Date: Mon, 7 Apr 2025 22:36:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: YT2PPFD8040D4DA:EE_|YT2PR01MB8230:EE_ x-ms-office365-filtering-correlation-id: 5a4b2d8c-680e-45b7-0c2d-08dd7624a590 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|4013099003|4053099003|7053199007|8096899003|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?J5d/uduYyac5PI2FpBR3hZZSz9aBLCcRoogEHXABxs3C+1Nt5gGBvQoNBR?= =?iso-8859-1?Q?lM3PH3SBTx/4EffnxlTOtOuZ4VYOiBdDiKOkMfRoKXAnhOiDq+QhsoQlGw?= =?iso-8859-1?Q?/pCuhGY282byFWRav2imu+G0Oq147uej4stDXYbXtHFMotF4/Q7633kfVo?= =?iso-8859-1?Q?T5etmg0R2JLSM1TxMDFeqzu0L3YqwpOoIw+D3U6mkC8/9jeq4qjaWeayPr?= =?iso-8859-1?Q?EJbu45uyshYsk2SHPaxP2bc9KqbV1sPIAuyaEcdFSzXtTLcbIjPMO9/tHD?= =?iso-8859-1?Q?M5qTQpyu160TonX20WNbh4lhDhxbmq+6tho/8JrNF76jkRaojKscp3/Yb1?= =?iso-8859-1?Q?jZ4jy+yRS38iQ1X9HEaWgBTgiankSbelF6/JyFs/1LCOsQdsk04JBUQoVy?= =?iso-8859-1?Q?odcmTGOrTuzMAbPtOzbtKOUMYVmgImu6DTbHP6T7UmyX0FJqwPYX1A+4GF?= =?iso-8859-1?Q?9wxW1hjMHdoxEzAhc+LajUxzqyBt/tr1Hgl3jcrE+nPc1tIaPFQnVz+lgq?= =?iso-8859-1?Q?Io7JwWclXkmO70BxwWaEwrkUOyrlF30tInXY/z1O5N7q/BEDFpB7DxskZb?= =?iso-8859-1?Q?r6dwL0pga1BzhPq/IYY/KhrtvZUecXprw8TO/ZraOwc94aViAqmtVRuPOM?= =?iso-8859-1?Q?GEKPKsKmPvuuyMMmgLxDLpm+RSnGwA5Ap5bqr3CKQMQ6+YnyAjZNcSkquT?= =?iso-8859-1?Q?hKISqW+YFCq9oVLNgblygCdyvlMCoY+1dSCJ5rbGV1QnZ+FkSDOn92oAK5?= =?iso-8859-1?Q?O49Dgk0rOrU3K7kjm4V4i3JqAnn79ZdPgJ4g6rSrcUS9JoZ6kZX0VWUM/9?= =?iso-8859-1?Q?1f1QQAIxKXEhhhi69ekFiQAoq+0XtH+rUjfps+T6i9BRpiJd0YZdG0LnpJ?= =?iso-8859-1?Q?zzRSVkur4918bgcyuVPCuPk5Oo0CzXUgXVnmGA4SugI96Rq5TdN3Kv37G/?= =?iso-8859-1?Q?ckLkjG0NtMVr169TSGv0ymtCX15LAzwIg7C6BPq6ZIVDMOStSIrOU2JhUd?= =?iso-8859-1?Q?vCOIt/6s5oms+Q89ftDyyktrqDUg3ZUK0Z6GGw5Nn4JYjCTmq/vYnYUXEb?= =?iso-8859-1?Q?2owyOLG5Xia5Wx9VrnQOepCs7/izGH1+NxMDR9rqg2yuqT/NoTPSijlDbf?= =?iso-8859-1?Q?YvaIgqn463TKvOzJdGLkdUn/ZIFwffGiRoqv70C0LtMAQrEzCkDtZiNhGo?= =?iso-8859-1?Q?5H63K34McfGfau3IYGWyLD7J/QXJG28Qs4qzTGv5vnPikiUjwGyDa1eo8E?= =?iso-8859-1?Q?0BM0XJOqXuwYG8XeUf/Q2TMo6SgibeItGHoTZXyM06ntkFN+ZAPS9LKv84?= =?iso-8859-1?Q?2SnC9PrEZ7TZqb5xerxXHgP2U2I8VqpmCOFGa5HnW8lLYeEeIKV275u+g8?= =?iso-8859-1?Q?fHmfmGWLQfveeGQru6kyPNwoSRYdm4wAnX9zdG7NbFPgxyBIa0VBxVY3YQ?= =?iso-8859-1?Q?g/Rd0cHuV+ohFnci?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PPFD8040D4DA.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(4013099003)(4053099003)(7053199007)(8096899003)(38070700018);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?A4v/ipqPtXz0yRE0Ix/3PKqy92pIbmJeZ8ydnqUEONqgSEkAiCOSdopHag?= =?iso-8859-1?Q?lnWSrlcKfCQOV7CtqQ2piPwVcIzLPeOymQ+qtxZ61lO5+RbVXPDoHOOseQ?= =?iso-8859-1?Q?nDR1BvJhi7kWTdXQPUF/RQ7Ru6sIzPgpQSv1+UREKqIPtxwnjmToiZGKUT?= =?iso-8859-1?Q?J44N6hk5gVdeDD+VzgoETBvQQFW6lGA2xvGIgHKxK77AgjENAaj7CTq/IM?= =?iso-8859-1?Q?DMV2SuMVSq98yYb03YEfyCNgjT72oSGKV3Uai8QSXOdOO+t3Cjqjhh+2mI?= =?iso-8859-1?Q?d6hm5pO1AV9FGsZhY55hgXTEHxIBzE2UrP+4SU8qTmqWU/1mLx3PNUtGX4?= =?iso-8859-1?Q?1vSeN8ZfQBh35Z1CJsYNUBvWimLQsFbnJhASvQqmlQBziDnlpc7BmyajNG?= =?iso-8859-1?Q?/+i+VF5HjE43VtOB4z/c7UVk+x+3VqmxnyPYkKkm6yLbQYznD+9cHEZhQg?= =?iso-8859-1?Q?MD5IQ9DNmiRAdUIHiXV/6zOBzrfYi/iKqKnMQ05UgEEu82zdYyMunEuVKL?= =?iso-8859-1?Q?3k1n4fkSAqpOsvRnwv8Pb2NocpV8kEH+gzeDOh6X0saRC6OovYBlqsznNw?= =?iso-8859-1?Q?xAOZLTDy/i5b7ZXhSimIRFxvT/R3/Kgj+rvRPOUp5+ey33eimFXUZbUt+7?= =?iso-8859-1?Q?eF3z4fgY3iiiM7FzrMRQ9dZXSC+1uYBUO6DIVyd+zha0paouy8JG0CUfqG?= =?iso-8859-1?Q?VmEucXruoaRtpUHkNZjhTdVouijdT0pgGdV8AIM4vhsU4wr4cgCjhN6LbN?= =?iso-8859-1?Q?Q40WnFRoccrUid6lDP63Cgih8KVZsd83NfDK7S7llaGdjG+4VvP0YXnPyp?= =?iso-8859-1?Q?2wuShGsl1Fv2KMG9hIpZVzdopPuxYeIGvEI/Dib33Oiu7u9WZsKhyPmD1e?= =?iso-8859-1?Q?gCRfo/o8tL6s4EDPIwhY4ZDhuahetJt5QpAq3INCgQEp2TzRKTseDUPpy6?= =?iso-8859-1?Q?RctrvrH2WHnbq0y1jyG2bg5OKfNMWtSclbJ+Dc7EXEdmvetumSIs21kDOH?= =?iso-8859-1?Q?UKlTDw1b/jUPjWhcvM4Zjw/cNoefs+ZOpaijyshxWpFB7aAbDrjkAkvRkt?= =?iso-8859-1?Q?kSYZKCYgtdvCP46wW/PPzoWr62OAgedPmSz2UAuvLFU3//DIGOE/n5p/WC?= =?iso-8859-1?Q?ng5+KtPBN2XUQT4spEHAlnvcMDAJZSl2Yy3TH8c7ds6lGluKPbgAP6Nuh/?= =?iso-8859-1?Q?VQIv3vI37WiOrIMs47rOAt/4BP6U7tJdnKR9cb502Kw5HA4FD6LRfQ35Gd?= =?iso-8859-1?Q?CSwTutFfAgZakIb2a6KobJGZugFEVh79pl3M+DgjQ3QWgKuR4s3wxkwyjD?= =?iso-8859-1?Q?iz3pOLHadWzPxxvFvSzrFIOQimwArji48FeVwLgrIdM/88bmv9d6tQx0S5?= =?iso-8859-1?Q?SS+hdEh9bzucs/GpIZDSCp3eq7Lh8ODC/YY4HygCsEyKI7Vh4ty6upWMYK?= =?iso-8859-1?Q?SGWT/qxn21TgW7QX9Bff3bDE/QoOaCyMxlnePWZaZx7/RNBfM5QqHd2bBJ?= =?iso-8859-1?Q?dsA7mRY2Nq6jRugeIVTXfgn3OU0ReSdz1Iqd4ydRie+sE59TxcJaxj6CMM?= =?iso-8859-1?Q?dpZbeWErflkkq7tbkDBoxqyFkyfWuLsWs+0GRgzwpZ2Goce+X1zEwgl4c5?= =?iso-8859-1?Q?SByCapPZYtbCmQwoNO6WogR4mn8x7R87qfPX87/FVA7Jy/eobx0v+yXxVE?= =?iso-8859-1?Q?pdXTGBb4bCFwoNjO6G8=3D?= Content-Type: multipart/mixed; boundary="_004_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_" 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 X-OriginatorOrg: willowglensystems.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PPFD8040D4DA.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5a4b2d8c-680e-45b7-0c2d-08dd7624a590 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2025 22:36:32.4570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c7bca0fa-9d0c-460d-8770-da688c84194e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Nnp/o7qRt3Fp6N/X+7e7nwc1dFM1vepsh3zQ6F6Wo5Gqlj49oIytRH0ZeHPBVeB2hpMjmcn7NuWNmvg0IOjOUoEJDMKwo8jGFWxNwOOw4qeFWzBVE1yVF1x1Dx4IFpDp X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB8230 X-Spamd-Result: default: False [-4.89 / 15.00]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector10001:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.90)[-0.897]; DMARC_POLICY_ALLOW(-0.50)[willowglensystems.com,reject]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f403:c000::/51:c]; R_DKIM_ALLOW(-0.20)[willowglensystems.com:s=selector1]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; MISSING_XM_UA(0.00)[]; HAS_ATTACHMENT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-net@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a01:111:f403:c103:::from]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[willowglensystems.com:+] X-Rspamd-Queue-Id: 4ZWkbD01y7z3Wc6 X-Spamd-Bar: ---- --_004_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_ Content-Type: multipart/alternative; boundary="_000_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_" --_000_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ From: Robert Austen Sent: April 7, 2025 4:33 PM To: freebsd-current@freebsd.org ; freebsd-net@= freebsd.org Subject: Fw: pfil_default_to_drop ________________________________ From: Robert Austen Sent: April 7, 2025 4:21 PM To: freebsd-current@freebsd.org Subject: pfil_default_to_drop Hello, I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point. I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no filter is loaded, i.e. if the heads are unhooked, then PFIL sends everythin= g thru to its destination. So my thought was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the hooks are unhooked. [No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them, maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.] Normally I'm an embedded linux kernel basher. I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes, so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her if I could... I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch= "... I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64, but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version. But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along. thanks! Robert --_000_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


From: Robert= Austen <robert.austen@willowglensystems.com>
Sent: April 7, 2025 4:33 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org= >; freebsd-net@freebsd.org <freebsd-net@freebsd.org>
Subject: Fw: pfil_default_to_drop
 

From: Robe= rt Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org= >
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point.

I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard
to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. 

After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc
or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL sends everyt= hing thru to its destination. So my thought 
was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the
IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the 
hooks are  unhooked. 

[No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them,
maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.]

Normally I'm an embedded linux kernel basher.
I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes,
so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her 
if I could...

I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"...
I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version.

But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along.

thanks!


Robert




--_000_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_-- --_004_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_ Content-Type: application/x-zip-compressed; name="FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip" Content-Description: FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip Content-Disposition: attachment; filename="FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip"; size=3361; creation-date="Mon, 07 Apr 2025 22:17:42 GMT"; modification-date="Mon, 07 Apr 2025 22:35:54 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAFl9h1o5P+nyMQwAAC4yAAA1AAAARnJlZUJTRC0xNC4xLVJFTEVBU0UtYW1kNjQt cGZpbF9kZWZhdWx0X3RvX2Ryb3AucGF0Y2jdWntv4kYQ/5uT7jtse1IEIRBsjAlJLypJ4EKPAAqk vVaVLGMWbMXYrtdcmr4+e2cftgHbYNJcVTVKAt6dnd2dnd+81jNrPkcVf+YNHlADfevas9MV8U+J b5ySZ3JquM78dDCcdMboWwc/ZfS9fVOpVHYNLsg1uVGpKZVaE0mNc6V2LqtVRW5IUuusVkOVmlqr vX1TLpfZLHmYKOeN+rmkVmVFkRrKGpNvv0UVqVZTTqQaKvMvMoLGGf5sGbhQeFq8fYPeIU83HnFA 0JMVmO4qQIG7MkzLWaDAxGgy6ZeqCE1MiyBDd9AUoxXB85UNZMi0ZhjNLR8/6bZNGLO57y5R4OsG 9oEXRrozQ8RaWrbuwwjXJlVKxkhHXe2m020/9CfaZKjd3A9HMAMwJ3RiWORcX9kB8uZFpYT8lY1h PLQ6zwh/xv5zQJcomJUps14/HzvLRvAXYD+dX5kvbnI9Gl23Rwg7+tQGHoYLW30yLcNEjxh7nKmt kwA5kQAJdgK2YR8b2PqMZ4yT6yCdskPEpWTR/mmbdtVvX3+8Gn4K54FPU3cMPKO9sDDK0XYXi3Cv 4aHKZ+JQ67UTSaKH6nqB5ToEFXpUFJPOfaHwzvLETsnK81w/AA4JMq0//LBGGs6WQTr8+DBap/bo kabRhmcBOxxefyy8m9qwewRqEklr+hweyub48aTT7k9uYRaxajR3YQcB1u3ApN+fdH+2tcKkKhXe zXzXWzvajfnK0Ui63MPGxrMKHdlsis90u/32FsS33ng/fJh0tLtRe3ILzW/f5DFAYjAzDpm9sRHK JMkwQ00wQ608ZkiwyTBEraQhUpoyU1n4FBp7d/XQ1Ub3QziB3uDD2ze8YTy574zHGhi5CW2iMoLe QgEm1JbUplAomNA16I6pat3Qr50JsPhY4FQL253qNqNJ6gWj8Oa0txydfbLf4uPXTojzZkYt7pq0 r/qd8XZXt3eltfsfhokhYyDlbYSwlnG/N9J63a42HE0EG2JbXtXcqwwODk6tuTb1rdkCVw12SrsI mErsZbOlFfWzc1mpKoosKfKmc9o7X6piSDL1UM1NxWg2mV7AB1MLkAo6PoX/8PvOcgx7BYb3G6Z3 AEEQ2+V6x9dUZBbMXTW/Tm1XWUc57ojP9+u0STzd15fxJHEHs8UmWHcb+2n9y+lqntqu22D6oEeY 7oaw3I3WSb3J90vHwN5guQVuj6ih6NxovYGmqIXiVlMPtF1Ff/yBUtpLWaxAWWNecVvMLK2jxNd2 egwCRMfoTjd8l1CvycWAiIcNa24ZsMNn5g/1KcHgvJA7Bzf4LNwsYaNP2SHMYW2IzQmPmwt9GGxt MdFc/J6fKDs+zcT6rJTJJd5csj2DD7YJzrGquQ50eeaNCLEDWIYvmxLYO1XW/g/afubuX7L5vHvf sfVUf5vBMUbAVygBi9173xoVt+bbrJLrmJX0Mz49ZiYMja3fKBIYMHgsbOrERAGN8yCivluRgEbT OsRQT9hnlE9uNTJ/IC+H6srVfe/mQ0e7n9y2x7fauPdTZw3jyc5CAYJDBUj4krjRkaWGyqyOLJ1B EqBQ78sNtTZbLZfPoA9FEvgrI0DUjKHj5QkSzxawKhSsOSryAUxvikeUwKhcEkOz5t4Jov+YtKlg Suir96hWYgMLPg5WvnMRcVmi9+/R4KHfT/b/CcIr0LNBlDBN3iX0O6UpLLW5j/GyuCxd0OeYSZky QZSZWC12flnhFS4SQyySDUF/hpZNyEdpKFw+yhkIqr4mHxFvCvGErcSdBwY6plwz5COmIz6VkJBN b/AlRNMbrElm4YJ5ptHrhjDooBkJYCXhFEBPO0IxTX1XnxmQzYCg4kXDJiQmrs21hDI7EzrVkKVX lRlf6b+pT5HUdqtQuLRQi9Ymg186/lzIRj2TuGyaUmsTb5bjrUKwwboAeeiY7TrEH+WbKhy2Sy4i IPiZ0yH42dAt6suXa6ccUYrFoiLruCjEPP6EP/FEH6KnciGW3vfcX9guOHvNM58JOjpC6XoYjt2A acgycyHltamjwy1acygksI1NYd+lte5CZ3ILWeYVRPh3k/aIU7KDESTxPLxNNLNZ4qfoQRxcsykM wZmkioPbhkiWWucylHTPr63Z/sqhkRY9kX9oNK8/av3eeKJ1h/ed9vVtcTalyn4UbcC2SHBCj0Jz 8K9BaENCy4IoeeUS/tG9RhuJLY8wLGI/kEZCLrfCF0L0Z7IqRN+UXyL6FNkbXOB7TEq8kpjP0gil n0rET+DgI9g+g41DiE5hp+ExSlwDQrO+IlArei82szFBrhSSZ0JxNpfsY4njrsHpOSMASJFrOXJG ziR/uii1aidNVKYf0hlVEqETcUDL1dJyggJ90hzTdR8JBGDM8V/E0dNWrlX0SmBxikl2xyXoKlUu 17hZDroEkW/zig/9EGawtJAbyOmVs619AbdQ100pfJWQTCk5ZGuzXyUlEAXbe+brtvvjzs4JYqI4 1I5iXAjjkPaxcz/o9GHnm82QjWh8YRr05YGExQoZnjYHezN/monSyl4qBpN8DNMBAxcASr2+HzA7 2cUlODmlBKdyAwsfcaUF3VHdoYWNR6ps8BgEUO13lzqhijXAwdX4hlVgpzqxDIG2lc/Uji7Ddp+q Bq+Mc4YWgbQGinQwyIZOME8m9nE1T10nvUyTrOt4ohp8aA0H/oLUjkfsO9iOijR1cWdSrzX4lQnd aeA/i8B2K1dilteFI6oSTZ/NfPQeyCuXMCRuuxC2/fSY/gcp3a8ckDrkhQsTUbdKxRlV1ZlZYEJn 4WJYMqdDObaZ6d9fHyhtRbfcaYRY3T0Q8YEwNwFzR4eGoxkZ3TuMSgw9QTTkWVYul5r3GJgzv+ob n8FzsbXDD3WpzPuyJYza43FJyLylcpm3WlzmYuZzFmgHM0yCWL7xU1Ky4wB7qHGOwKwuXNDD6IJK iBF5vmtgynqxJdActZJcEoWRe0UKq0uXKXRkCNUxK5eOSWOrXdI8xMYx7RIWbidNHvvGCDOtmwzW Tclv3RizLNtWT7nnrAvEKty25S8eT1038MCQ5K8qh9YnoxMb0JHblrHKUGoHIWnNxAi8vWaPGXuJ S0SVhA2j16/EhPu0cwEU+KEXW4P2BAFAfIverNC73h9MTG0T2HFT9zzskBMUYNteG2V5YY7P7lBd XuOyFmaA+DWqAFYETfTdaukhFy7U6BUg09Y1GEIILUyeDn7FceES1Qjg/rT6UmM31WevYOtcCLpj Ww4PFwdYQIrSCJ6HYBL0YT8ogSgnKoFyFyzrh8ESuB2KS5njUn79251DoUadvBbYabDihwluHRRS C8C5pCJSBxjAqwzBi3DMMNmqc0y2wlcxCA1VOSItD5RtGbizYlx9hbZjnvCZNnZiZTRt9M03SL7Y CHbh6rxz/SVRB34tN+z2+0NRPSDw2gm8VFGMtGurGji39QWB7w6vDAK65tbUWS2ZD2RO8Aj7vutH DA0dknLpnEqkazkWMfGMC6UQOm7XwbmyY3ZLBGqv5kgGGF3edGCDOAubqiLBCz35sJlkmIRnjcGz sQlPOax7r6cEk9veGI2H3ckP7fvOCep83xmgXhe1b77vjTs3aNgFig4aDcfj3hXc3U9+pE3jh+tb dNO+a3/o5Ir1D7+r/dJJALUBa/e0LX5Pq9aiFEDdkwOAelYBWWqcBaiVSzoMOhJhas8x3CXAUESl cZQaI7SaL+BXs+NTy9njB9VdjnCXv1O3HR4L82OXJyLUjcAUbazsUAgyueeAIKPLC0FGnA3BJkBQ PgiCjGE2BFsUgq8Uue5/7SHNY+7HUk4A5opEc2Nv8y2JutTgQpFUgT59oYtcUBhzijPDxrpPDNfD xaMIbHAupYt0ihiOpYt/wUuq+93kdt64H5br0em2jWEbSq8txCUFoaJ4FpYVqgdUxpiW780bGVW+ zHGNNBOFjUMdIWN3iBtURa4kMHiw53ohDHMibW9s+RJkslevxGukTTmsuUTSS/i3OPsr4uqimjNz jIexHJLy/6+kjoeiM7/PzIDnQe40WUE7DKJ700hGljORjGh3oVQ91FcCv/8VTMP88vVzx3R8h++C S/xdA/giCxQ7rmOqNsBi5Z0zBWXaxDIpdPQe/XVH3+QeXdAU6dOnT2F2lFA5xG9A+YXjFwPkF/aX tND6T10m19RNf/k3UEsBAj8AFAAAAAgAWX2HWjk/6fIxDAAALjIAADUAJAAAAAAAAAAgAAAAAAAA AEZyZWVCU0QtMTQuMS1SRUxFQVNFLWFtZDY0LXBmaWxfZGVmYXVsdF90b19kcm9wLnBhdGNoCgAg AAAAAAABABgATcmsAQao2wH5SqcBBqjbAflKpwEGqNsBUEsFBgAAAAABAAEAhwAAAIQMAAAAAA== --_004_YT2PPFD8040D4DADEDA66317A6B3E7928C9EFAA2YT2PPFD8040D4DA_-- From nobody Tue Apr 8 01:50:01 2025 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 4ZWptd5G7fz5sXSR for ; Tue, 08 Apr 2025 01:50:17 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4ZWptc3CkJz3VKJ for ; Tue, 08 Apr 2025 01:50:16 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=IqEITSqk; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1744077002; bh=jtg/Y1JVZ/BJCjoo5z9+h65kKidBf+fXv1vwrBcq9U0=; h=Date:From:To:Subject; b=IqEITSqkhJ1z8Xj0o5k+Zo2DxMy2UM0vN2usqCJPVo+zSMhrq7OnZv15eZqlu9bBe K3fV8bAUstrDApJ8+cytdv3Vm2iEiV0nlQZsU9e4LJpnrXE1ziu2/b+5y8+Mn5Vejv aoCF1rRK1brYEksmoHg6qW1ag5dW9Axyr7yda2Ls5XyiTAZIFBG9x8Rw1lV/dDXVQs UkZ/C1dNy0Ca/Z8YS68JzWszy1BDmi8H5mHqtRciCCfjddSI4cvdUyS9W9K+6rbssb FbN5+o6JXZx3AsDc6sGcQE3DOd/ZN1goAv2dm4afxVA7V9b5WAV56BIBcw2fru9yoG ratI46EJaY60dbopkmxTwYUfdVWgxrctjCGZu0rHqOX2Wc9EBD1WSX0aQCD8xTESxk 3q4bZiPhJ46NVVcX1XJbGVn2PLjY0gO01dBNHKdWRfLDDWCmKDzcmvPkJSEbqn10bU QcMA54HzUTjsB+t3DqJiX4LnK3Jvk66MJ2hD8W/9bMA7UIU4iGLDF6n4mxtb4MM/00 BFX0O0Voz/aMDFGdhSdc4t3f3Fzf5izY9zes0jhwnarf2MtEo8m0OHxzl4kMUsuDzL TTD39agGBCqGXC323KxKlTC7K6Qn26I9UNpp4mlRxZeFmPlOj1qsrvrEoMIh0ccAVN Awg06J6115AKsSCTG71gBBVY= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 486425B13C3 for ; Tue, 08 Apr 2025 04:50:02 +0300 (EEST) Date: Tue, 08 Apr 2025 04:50:01 +0300 From: Sulev-Madis Silber To: "freebsd-current@freebsd.org" Subject: elfcopy: not found User-Agent: K-9 Mail for Android 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-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [1.11 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.977]; NEURAL_SPAM_MEDIUM(0.88)[0.885]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4ZWptc3CkJz3VKJ X-Spamd-Bar: + --- boot1=2Eefi --- SOURCE_DATE_EPOCH=3D1704067200 elfcopy -j =2Epeheader -j =2Etext -j =2Esd= ata -j =2Edata -j =2E dynamic -j =2Edynsym -j =2Erel=2Edyn -j =2Erela=2Edyn -j =2Ereloc -j =2Ee= h_frame --output-target =3Dbinary boot1=2Esym boot1=2Eefi sh: elfcopy: not found 313=2E12 real 432=2E90 user 44=2E54 sys make[1]: stopped in /root/files/fbsd/current/src make: stopped in /root/files/fbsd/current/src 29m18=2E50s real 43m6=2E42s user 5m47=2E07s sys host is 13=2E unsure what that is? there's entry, 20250314, in updating bu= t i can't figure out what that is and how to fix it=2E WITH_LLVM_TARGET_X86= =3Dyes maybe? unsure how to fix this on my own From nobody Tue Apr 8 01:55:01 2025 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 4ZWq0G62Dkz5sXth; Tue, 08 Apr 2025 01:55:10 +0000 (UTC) (envelope-from zlei@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWq0G5ptJz3XDb; Tue, 08 Apr 2025 01:55:10 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744077310; 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=H4T0C3CGLETbC4JPJMsXzgJ/5dB76TwQBXxdzlqwvRs=; b=mDUoaXab7t+BvI8Yozq70e4hyKjrR/ZHx2tP34uCKNQZbJk4cCY2NEGFuAsbrSLciw0heK 91QheVii1+e5sYOcTMnqYzVv2+LixJ1iyU2ieaIxobUPvSyUBYS51J4u2ssKbltXAHmmOc 0Qa6mfPqlg+GBpoFPtv833TFEvfEXmddiSI8jdwl2xd7oQCotV0aWnh6yllrWSrBGC75Jk xqeI+eT/SgZFKYgKopJV0A1rKeF5UNIg1a6GJ2maInAw8qb64rR4+JNGurQtlzAeMBPq95 UIZI5yYyFcxKsE3VsteCG7utf1U8jdCheaaDU/bwtWGKAoST4/bglwoYYkmckg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744077310; a=rsa-sha256; cv=none; b=HpqCPA2gjmLP38PudGZsdq8bsgG5g3cnC2ZnZYoh+VJyIEI9VC51IyO1+OcXbMI2r8/TkN zyJOvwYV73tGOpEZwnxDplT/SxSXmeQNx4BYKpOhvqXotNTI08VhgjM8RcfkZaK4ATYJSa sityzDuURShQpTtPKOwYFoF+GgBVnP2kGLBz1AfdeaEELFGithuyLpyC6C10X38VcjCjCk EUKinWIF2zCdKYkmrZXncNznxaUKW6MEuYEjaY6/PS2JOhQIh5dwrd+DpVsfPIRGpnnu3N Asd5qDQyNhIqpoNUp+9jXOwdSWdKk5o3L3pZdnrmKlCtD9QZFxkuRYpzOUjPgA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744077310; 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=H4T0C3CGLETbC4JPJMsXzgJ/5dB76TwQBXxdzlqwvRs=; b=u3LObqdviW/taseLRw8WtNip+OJtkVAa4kolq1Makr1LB+AwflXmdPbAgKyDPlWy1VQU9Y Jv/Ixif61I+oTwBX82ahDbpU1E8zOy2unXb+GGijuU1Yt00bF1LDANwIZGELD0N+FKxKh2 o3ASSIn17YtZA+z+kC25mc7oSzVr+NgNZ/9uee/xGLyFdQNPSNTAUYkjegwHLaYITynhkC B554IPh+ilGORXyw9LI9ywL+r90Ce8iS/rS3lNx4zcYfArigUTUtlGOwIIbkpikH6UBvT6 8f9izj5jRFO/8KKzNdcW8qLzZXbbvbFnTiHT8LFM0vceyT6fPkqCCZLnWTwzMg== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZWq0C6qm2zNt9; Tue, 08 Apr 2025 01:55:07 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD" 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 \(3696.120.41.1.10\)) Subject: Re: pfil_default_to_drop Date: Tue, 8 Apr 2025 09:55:01 +0800 In-Reply-To: Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost To: Robert Austen References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 8, 2025, at 6:36 AM, Robert Austen = wrote: >=20 >=20 >=20 > From: Robert Austen > > Sent: April 7, 2025 4:33 PM > To: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = > > Subject: Fw: pfil_default_to_drop > =20 >=20 > From: Robert Austen > Sent: April 7, 2025 4:21 PM > To: freebsd-current@freebsd.org = > > Subject: pfil_default_to_drop > =20 > Hello, > I've been playing with FreeBSD and PF to build myself a new firewall, = as Open/FreeBSD + PF seems to be a common starting point. >=20 > I've noticed a number of people asking questions about = PF_DEFAULT_TO_DROP and the like, with the observations that it's hard > to ensure that packets all default to drop if the rule file(s) for = whatever reason fail to load.=20 Hi Robert, So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = pf.ko ( via the loader(8), /boot/loader.conf ) ? With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = ), you can turn the loader tunable net.pf.default_to_drop to 1, and = preload pf.ko. See also = https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f991322680= 1f3073bd = . >=20 > After looking thru the online documentation, forums and scripts, I = came to the conclusion that it's not a PF problem or IPFW etc > or really a problem with any of the filters or scripts, the problem is = at the level of PFIL, the kernel packet filtering code: If no > filter is loaded, i.e. if the heads are unhooked, then PFIL sends = everything thru to its destination. So my thought=20 > was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version = of PF_DEFAULT_TO_DROP) that drops all the > IPv4 and IPv6 packets that would otherwise go thru the = yet-to-be-loaded chosen filter (PF or whatever) at any given time the=20 > hooks are unhooked.=20 If no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your case. >=20 > [No one filters on local loopback nor the link layer, so I've left = those hooks untouched. I suppose one could add them, > maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I = doubt there's much demand for it.] >=20 > Normally I'm an embedded linux kernel basher. > I'm not entirely sure where to send this patch. Most of the threads = asking the above PF questions are closed to changes, > so that doesn't seem a good place. Sir Dice seems to be a common = answerer of questions; I would have sent it to him/her=20 > if I could... >=20 > I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"... > I've simply diff -rdpNU 5 a copy of the @old folder with a copy of = @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > but I suspect the kernel code in the networking core doesn't change = much from platform to platform, or version to version. >=20 > But it works, it's pretty simple, pretty small and so just in case it = might be useful, I'm passing it along. >=20 > thanks! >=20 >=20 > Robert >=20 >=20 >=20 >=20 > --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@willowglensystems.com> wrote:



From: Robert Austen <robert.austen@willowglensystems.com>
Sent: April 7, 2025 4:33 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>
Subject: Fw: pfil_default_to_drop
 

From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD and PF to = build myself a new firewall, as Open/FreeBSD + PF seems to be a common = starting point.

I've noticed a = number of people asking questions about PF_DEFAULT_TO_DROP and the like, = with the observations that it's hard
to ensure that packets all default to drop = if the rule file(s) for whatever reason fail to = load. 

Hi = Robert,

So why not defining the = compile option PF_DEFAULT_TO_DROP, and preload pf.ko= ( via the loader(8), /boot/loader.conf ) = ?

With 13.5, or upcoming 14.3 ( you can = also experiment latest stable/14 ), you can turn = the loader tunable net.pf.default_to_drop to 1, = and preload pf.ko.


After looking thru = the online documentation, forums and scripts, I came to the conclusion = that it's not a PF problem or IPFW etc
or really a problem with any of the filters = or scripts, the problem is at the level of PFIL, the kernel packet = filtering code: If no
filter is loaded, i.e. if the heads are = unhooked, then PFIL sends everything thru to its destination. So my = thought 
was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL = version of PF_DEFAULT_TO_DROP) that drops all the
IPv4 and IPv6 = packets that would otherwise go thru the yet-to-be-loaded chosen filter = (PF or whatever) at any given time the 
hooks are  = unhooked. 

If = no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your = case.


[No one filters on local loopback nor the = link layer, so I've left those hooks untouched. I suppose one could add = them,
maybe PFIL_DEFAULT_LOCAL_TO_DROP or = PFIL_DEFAULT_LINK_TO_DROP, but I doubt there's much demand for = it.]

Normally I'm an embedded linux kernel = basher.
I'm not entirely sure where to send this patch. Most of the = threads asking the above PF questions are closed to changes,
so that doesn't seem = a good place. Sir Dice seems to be a common answerer of questions; I = would have sent it to him/her 
if I could...

I'm not a user of = GIT, so I'm not sure how to submit a "GIT formatted patch"...
I've simply diff = -rdpNU 5 a copy of the @old folder with a copy of @new folder. The code = was written against FreeBSD-14.1-RELEASE-amd64,
but I suspect the = kernel code in the networking core doesn't change much from platform to = platform, or version to version.

But it works, it's = pretty simple, pretty small and so just in case it might be useful, I'm = passing it along.

thanks!


Robert




<FreeBSD-14.1-RELEASE-a= md64-pfil_default_to_drop.patch.zip>


= --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD-- From nobody Tue Apr 8 02:13:31 2025 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 4ZWqPc0QCpz5sYsQ for ; Tue, 08 Apr 2025 02:13:40 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-106101.protonmail.ch (mail-106101.protonmail.ch [79.135.106.101]) (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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWqPb58Fdz3dkr for ; Tue, 08 Apr 2025 02:13:39 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1744078417; x=1744337617; bh=5JvXbNrz8CdBM9eICjoocuu7rSebe+/lQ1vyh1xm1io=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=RbpEPmAk2rbq8CGuMCvG04vnqBc6TmRo/2OqKP7KWBOyANGOFD1XxdykzVhfH0BvQ S8MocYWOXDNp60X23a5nUP4jHJuxTrtv8Lsy/J0EgjIAWlEJGNitsHQ3SPloQ2DDiJ GYCA1W6V1mXWyAkwwDeezrNPdxRYCe6WGx4TL0lrkWTyHYtjj1LmpAHklLvmi/NmfI uhvqpYaKZfo2ooki9yUvrlUmPlVLLhgghWA6ndlcIb6X89+1XoJfm5cizq6L9q8RIy wVUMhkfcYHOsGxxpOU9pV1O1ttUoKY4Kt1FgieNjYh1bqmQkpUjBXrVwuyzHKfmTin hBMiPiT3RHShQ== Date: Tue, 08 Apr 2025 02:13:31 +0000 To: Sulev-Madis Silber From: Minsoo Choo Cc: "freebsd-current@freebsd.org" Subject: Re: elfcopy: not found Message-ID: In-Reply-To: References: Feedback-ID: 45891198:user:proton X-Pm-Message-ID: a6b7f1e76a9f07a02df225d9e0ae29d8e1f34dcf 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Queue-Id: 4ZWqPb58Fdz3dkr X-Spamd-Bar: ---- Sent with Proton Mail secure email. On Monday, April 7th, 2025 at 9:50 PM, Sulev-Madis Silber wrote: > --- boot1.efi --- > SOURCE_DATE_EPOCH=3D1704067200 elfcopy -j .peheader -j .text -j .sdata -j= .data -j . > dynamic -j .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame --outp= ut-target > =3Dbinary boot1.sym boot1.efi > sh: elfcopy: not found > 313.12 real 432.90 user 44.54 sys >=20 > make[1]: stopped in /root/files/fbsd/current/src >=20 > make: stopped in /root/files/fbsd/current/src > 29m18.50s real 43m6.42s user 5m47.07s sys >=20 >=20 > host is 13. unsure what that is? there's entry, 20250314, in updating but= i can't figure out what that is and how to fix it. WITH_LLVM_TARGET_X86=3D= yes maybe? unsure how to fix this on my own I had the same problem. Back up your src-env.conf and create a new one eith= er empty or only with WITH_META_MODE=3Dyes. Recompile and restore src-env.conf From nobody Tue Apr 8 08:06:09 2025 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 4ZWzDd351Mz5s0Gw for ; Tue, 08 Apr 2025 08:06:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4ZWzDb54Dcz46Lf for ; Tue, 08 Apr 2025 08:06:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=RaSVvcKk; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744099581; bh=s8OKFLGVuqXvgBVNqvlM7D8vdgO45t3D+JivAS7+MgI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RaSVvcKkMdTIChIbzwKkxdT019HmshnhIQf75ovicEM5uT+DqJdQoSn0FZhXXQ51Sm46xWQYCQEN2/FpD9njturY4cjcCHbj0K0IlrYmB4W38c9NNn3OLhU0DVnQ6LPfUsVMwmBt+JjDmc2IEFnCV2MgJ0mm4x6qobMHKFtF88ILl/cpFuwqCzocZqU/0Rx8HT9Y4OE24S+ryzgoZSiQrdFCGRu22mxyeM/TSLfnOn24Af8miQecx5kPRRaoafN6IdE6iaSRjQ1umAWZtjVrVmJ1GDtkiSClyZRvZwHNUEvY1pCbb65cf12nH9Q5ZVHy2DBUPscP/dhud8A5F17qTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744099581; bh=q3PYCxabfC5hGO4PkICefFGFNRNzIQ3H8EoCIYrB2Eh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BW8Nb/MezBNEVh5VcWwVEYJYcSXyN1DHT6nEdEO8QYE6VPoAqiVLhte73uky4NejQS/JY+pHX+xpN39qCKLvFRuxgFMNaSX6WoICexBYSH6DSDUfe0a64ehl5416nBfN0N3j1QFJ2n60xGpmbnnPXdAdzCzy77nUvBnHLO1eCFt0t+nthUcHmN3ybQ3qDQgA3aED7Y2bInx2F4Gfvw2BzFugrehqQOw4BQwm1fJuQhKZ7Sv4KAEihODLth0JfcuxtOOvSrUnbdgTzsVwDspu43gH5h+YrQ7AQ/W5jmiUZLwdonV9qEpFasS4yE/fDWx+TFZ00a5iE2Nzihl4dUq9kQ== X-YMail-OSG: NBUmfzQVM1nEwxkyzGS._B2WSFrpWKGcdyLJGeYFGhLKifxHf5ckWV2hjuwvCe_ 2S1L22I6VCFUrTyxnU8_jEli98WKxUPPHkAFzuJb4BNzjw.Cqde9X10728wx0p4Ly8UkmMyCnIrA S5fsh7zAcLyeIZm_7qkkOuTAlMi0y._6KHlKz6RShkEXdggQjDjcugL6nvj.onNOSqpbuV7p.Vum bGMHhwqZo1Tfs6.tIQkAyCZZl6MUkbawpnOxHBNNdPqqOfEsv98hKjgvcEYsB0bzezpF3ldCSc_a Pritg3l8tOnD9CNQczw8idfc9p8oZ2HtGXmbrwb86T3a75RAd_7yipXNErSlNwvCDWaKX3hsdvJ7 JUiq9hUML1BwPDCuYmHuVHdnEF5rcPpaVaUm_gEdRnSuHixTVDnNPfyTAI8oJhD.v6B6SmAdPQiX SlWrk4xMBFy.pwVQc_4hlvQP12qen3DhlIe_erU_ekYHrn484vYXVPRMFEE65pFxwKd1hsMEcHzi dKQ7eCBKHdiNip29lxuhoKskSXP.TZn3JrNzP_CKEpYHw33muj3Os_EWFwxbzB2gM24L7Hr5_IyN bWCsDsOUr6AeeDyeQIPVsW_v5R79IzsuYF1Xmc7h5oma8nq1gRs.DdDcesHfsEz9qaVpSCmlXtX0 dbk._g5l67m4EqJ5T_XvWqn5HSkHtExxEob9Bw54yM5VCaIJMD4gmVYASVabqgOHGiF0Bb6TPxza hQMOExXpyC2gyvntUbb6CNVF9FxvacnevN1J8s.5RTKjun2G6rbaTWTOxjb4NgIy31kRLhoSqau6 o7j03oJ3b16T4_DKYwHjrnkpob.0.wNm8TRStCXuweseRMzL1IbIrl_Qj1XtRMk3JoA19fN72XlD _WzDrrMRSbPEp04tg9X2OYF2L4U6OLT7twmW2VIy0wk0ZjGAf1vgXs2qsXCD54W8jtJgEkzLWf51 AR1zYT11OKhJLs6q24LIdmma_r1.nQ2RpRotquH0KlhAQ8hZ4iRmRkE13vPJ8QlsTGCDgMC752vk _mNBkjwA2l70NEc_KfsEmD4sFgoKitxOD1jyQ5CSiwISc8hWuERsXSc2l1wEIciqWH6fKepcA7Bk f3KKk3fv_Xl9plpGEeChWew1Ql5LGAzaEw5C4X6pTSp37mwTyhYjdpqOvZMDsH.jUvlj6Xz7yVNU _1JrO.u04LUTcsDJhY9aaEzhEClvnqcAJKTcamKGYRUBptONDBLsZkJq45gDj0PMjZcgYpyoJUgm KC3_DXF.YCIjwor4jJRgyUSri702xtzR6wozbw9XP93F7nhDG1tgDjvAOnDRikvS8laGVTFwxtua WIsovihYRMSxwinWBoHfPAG41JO52oQVIkfn9IB.wJ3Xw4PQGxXtzqgiRe9N9aCIJiEU57Er.fTh Oqk3iSzQjTXpH2hRjE8j1rerSACseMT29vs5AdYRR1cKx0qHiyKQx8YdE3FupZBbL5.4hoGZ5y83 PtN1KyVUmgsEAnpakOCfZxY0jIIprXfu2QBfEx53SAs_cLFyckTKhF0QqfYTY6N1qo6btk2scra5 TMmF23JjeqWz7vfDLZbpkSb4jI5Tz..RBHFlbIbK2obxt3R1g7mp.rhIsFWb2vcaDM5f7hDxAZHW JM5.ENYrYiQCEqczbAJJmCla5RIbfT87YEvb7oNWn5lJYcI137dDE0QD.9Swv6l4bc_yyHPR2KkF JRTpcjPAIS21LoLzE5.50SAcg8hkJag_u4l.8UWozsmOW6NdoLnrvW6o8lF3moVtMiUMakEn2kIm 6b96yABdj3JNUDByr733.1zqbV3UlUUn6UJzY4ifOSR5miyJgNOdHlE61rem1RNArPc6XA_m1BLT CSfGigjHBSxi8.nuUCPssR7Mt.ZPbMxYECl94eHnELE3Xjj6dsaWichPj_oajPB1y0oNakqdnmAn pY2uLlPxJEUAeCt8M_HZXUJ82kbc5fJhYhuzlq5vpAu93Q2LRhq8Vtgs5fvnCn8IKsbKh_fZUV8i hbXVp0CqGzFF_EpKW1uT9Q2s9w9JD9EOpspRQ5f9KqT4RtSRUSHZhVOIR5kYrBlmLzrhfuWqg1BA qX_8zpxDLs39u_._4wDGqv8cb08YC_lNLC0PksQgL6H7X1eDZvVmws31aYNoHO8zF5LH1KO1Cvdh .R.3axU7RiN3MsOh_p5JLUKu0ZgCwP8.oD5Ac.zDNNZ3goh44WvWpyQq7eYn6yb4YNuiWjYmukMQ .KHyyUkiYUQesSsJS9IWwQ8npjM45VCt3B22MDFZfsoCehhiJVhYgpANbD.dpYU9yWls2iJkXaT8 MW_0- X-Sonic-MF: X-Sonic-ID: 0aeaf6b8-21be-4450-b56c-cca1a9c73c5f Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Apr 2025 08:06:21 +0000 Received: by hermes--production-gq1-5c477bf655-s8xr7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef422ca36da125a76d6c798a906c8738; Tue, 08 Apr 2025 08:06:20 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [a specific package with large time factor] From: Mark Millard In-Reply-To: <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> Date: Tue, 8 Apr 2025 01:06:09 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-3.41 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.84:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.09)[0.086]; TO_DN_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from] X-Rspamd-Queue-Id: 4ZWzDb54Dcz46Lf X-Spamd-Bar: --- On Apr 7, 2025, at 13:15, Mark Millard wrote: > On Apr 7, 2025, at 10:15, Mark Millard wrote: >=20 >> On Apr 7, 2025, at 09:44, Mark Millard wrote: >>=20 >>> On Apr 7, 2025, at 08:14, Baptiste Daroussin = wrote: >>>=20 >>>> On Mon 07 Apr 08:07, Mark Millard wrote: >>>>> . . . >>>>=20 >>>> Listing like this is clearly not any useful, the problem we have is = the >>>> performance changes depending on what is happening in parallel on = the machines. >>>=20 >>> I've been exploring looking for an example that reproduces the >>> timing issue via commands like: >>>=20 >>> # poudriere bulk -jrelease-aarch64 -v -p default -c www/gitlab@ee >>> vs. >>> # poudriere bulk -jrelease-aarch64 -v -p alt -c www/gitlab@ee >>>=20 >>> so that prior builds are not involved in creating such a context. >>> Also, when www/gitlab@ee itself is building, no other builder will >>> be active. >>>=20 >>> I've started such a build based on a pkg 2.0.6 /usr/ports/ context >>> and will try one based on a pkg 2.1.0 /usr/ports-alt/ context. >>>=20 >>> I'm trying www/gitlab@ee because, on beefy17, it went from: >>>=20 >>> 00:09:01 (pre pkg 2.1.0 example) >>=20 >> I must have clicked on the wrong thing for the above. Looking again: >>=20 >> build of www/gitlab@ee | gitlab-ee-17.10.0 ended at Wed Mar 26 = 10:27:22 UTC 2025 >> build time: 00:13:50 >>=20 >>> to: >>> 05:35:01 (pkg 23.1.0 example) >>>=20 >>> (so somewhat over 37 times longer) >=20 > Make that "somewhat over 24 times". >=20 >>> and when I looked it up >>> it has a huge number of dependencies: >>>=20 >>> # pkg rquery -U -r FreeBSD "%#d : %n %o" www/gitlab@ee >>> 298 : gitlab-ee www/gitlab >>>=20 >>> The factor of 37 >=20 > 24 instead >=20 >>> is large enough to be unlikely to have only >>> load averages on beefy17 as a major contributor. >=20 > It is still unlikely that beefy17 had load averages > of anywhere in the ballpark of 20 times the number > of FreeBSD cpus. >=20 >>> Given the >>> evidence about the count of dependencies, I will see. what >>> I get. >>>=20 >>> The test environment is a Apple Silicon M4 MAX system with >>> FreeBSD running under Parallels in macOS. >>>=20 >>> [00:00:07] Building 943 packages using up to 14 builders >>>=20 >>>=20 >>> OOPS (via checking ampere2 logs): >>>=20 >>> Looks like aarch64 might end up blocked for a >>> rubygem-redis-actionpack-rails70 "Phase: stage" failure. I >>> may have to set up a amd64 context for such experiments. >>=20 >> The above looks to be another example of looking at >> that wrong thing. >>=20 >> But, as I'm using 2 different vintages of ports tree, >> there could be an issue for 1 even if there is not for >> the other. >>=20 >>>> which makes the performance issues invisible on local poudriere if = you want to >>>> test it on port A or port B, if we want to reduce the performance = penalty we >>>> need to be able to make a reproducible case which can then be = profiled, to know >>>> where to optimize if needed. >>>>=20 >>>> I have tried to reproduce each individual case which happen in the = ports tree >>>> and I am not able to reproduce them, so impossible to know where to = look at >>>> exactly. >>>=20 >>> I'm hoping to supply reproducible steps. >>>=20 >>>> I know what is new and what causes the performance penalty, but not >>>> which part is causing the super extra penalty on the cluster. >>=20 >=20 > I'll note that both beefy17/18 and ampere2 get the > time multipler effect. It it likely more noticable > on ampere2 because ampere2 is likely a slower system > generally. >=20 > As for reproduction of the issue (in a much faster > context), I also got more like about 26 sec in > build-depends instead of about 12 sec. The overall > time for building the 943 packages about about 10 > min longer. >=20 > The pkg 2.0.6 vintage /usr/ports/ context got: > (Note: There no "Allowing MAKE_JOBS for" notice for www/gitlab@ee .) >=20 > [01:29:05] [01] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.9.2_1 > [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: check-sanity > [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: pkg-depends > [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch-depends > [01:29:06] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch > [01:29:46] [01] [00:00:41] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: checksum > [01:29:46] [01] [00:00:41] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract-depends > [01:29:47] [01] [00:00:42] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract > [01:29:56] [01] [00:00:51] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch-depends > [01:29:56] [01] [00:00:51] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch > [01:29:56] [01] [00:00:51] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build-depends > [01:30:08] [01] [00:01:03] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: lib-depends > [01:30:08] [01] [00:01:03] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: configure > [01:30:09] [01] [00:01:04] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build > [01:30:09] [01] [00:01:04] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: run-depends > [01:30:09] [01] [00:01:04] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: stage > [01:30:16] [01] [00:01:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: package > [01:31:47] [01] [00:02:42] Finished www/gitlab@ee | = gitlab-ee-17.9.2_1: Success > . . . > [01:31:50] [release-aarch64-default] [2025-04-07_09h06m32s] = [committing] Time: 01:31:48 > Queued: 943 Inspected: 0 Ignored: 0 Built: 943 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 > . . . >=20 >=20 > The pkg 2.1.0 vintage /usr/ports-alt/ context: > (Note: There was no "Allowing MAKE_JOBS for" notice for www/gitlab@ee = .) >=20 > [01:39:03] [01] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.10.3 > [01:39:04] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: check-sanity > [01:39:04] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: pkg-depends > [01:39:04] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch-depends > [01:39:04] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch > [01:39:46] [01] [00:00:43] Status www/gitlab@ee | = gitlab-ee-17.10.3: checksum > [01:39:46] [01] [00:00:43] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract-depends > [01:39:47] [01] [00:00:44] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract > [01:39:57] [01] [00:00:54] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch-depends > [01:39:57] [01] [00:00:54] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch > [01:39:57] [01] [00:00:54] Status www/gitlab@ee | = gitlab-ee-17.10.3: build-depends > [01:40:23] [01] [00:01:20] Status www/gitlab@ee | = gitlab-ee-17.10.3: lib-depends > [01:40:23] [01] [00:01:20] Status www/gitlab@ee | = gitlab-ee-17.10.3: configure > [01:40:23] [01] [00:01:20] Status www/gitlab@ee | = gitlab-ee-17.10.3: build > [01:40:23] [01] [00:01:20] Status www/gitlab@ee | = gitlab-ee-17.10.3: run-depends > [01:40:24] [01] [00:01:21] Status www/gitlab@ee | = gitlab-ee-17.10.3: stage > [01:40:30] [01] [00:01:27] Status www/gitlab@ee | = gitlab-ee-17.10.3: package > [01:42:17] [01] [00:03:14] Finished www/gitlab@ee | = gitlab-ee-17.10.3: Success > . . . > [01:42:20] [release-aarch64-alt] [2025-04-07_10h44m17s] [committing] = Time: 01:42:08 > Queued: 943 Inspected: 0 Ignored: 0 Built: 943 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 > . . . >=20 >=20 > This sort of reminds me of an old issue I had on the PowerMac's > back when I had access to working ones: poudriere had a contention > issue with cpdup activity that made for long delays in the initial, > parallel cpdup activity. I modified poudriere to stagger the > activity in time to avoid it and cut the time greatly. (Not that > such is known to be involved here.) Others did not necessarily see > the same on other types of hardware. (I did not have access to a > aarch64 or armv7 context at the time.) I tried the www/gitlab@ee build step while using the boot media on an older, 16-core Cortex-A72 system (a HoneyComb): . . . [00:02:04] [01] [00:00:00] Building www/gitlab@ee | gitlab-ee-17.10.3 [00:02:05] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = check-sanity [00:02:05] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = pkg-depends [00:02:05] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch-depends [00:02:05] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch [00:02:10] [01] [00:00:06] Status www/gitlab@ee | gitlab-ee-17.10.3: = checksum [00:02:11] [01] [00:00:07] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract-depends [00:02:14] [01] [00:00:10] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract [00:02:53] [01] [00:00:49] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch-depends [00:02:53] [01] [00:00:49] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch [00:02:53] [01] [00:00:49] Status www/gitlab@ee | gitlab-ee-17.10.3: = build-depends [00:04:54] [01] [00:02:50] Status www/gitlab@ee | gitlab-ee-17.10.3: = lib-depends [00:04:54] [01] [00:02:50] Status www/gitlab@ee | gitlab-ee-17.10.3: = configure [00:04:55] [01] [00:02:51] Status www/gitlab@ee | gitlab-ee-17.10.3: = build [00:04:55] [01] [00:02:51] Status www/gitlab@ee | gitlab-ee-17.10.3: = run-depends [00:04:58] [01] [00:02:54] Status www/gitlab@ee | gitlab-ee-17.10.3: = stage [00:05:46] [01] [00:03:42] Status www/gitlab@ee | gitlab-ee-17.10.3: = package [00:12:24] [01] [00:10:20] Finished www/gitlab@ee | gitlab-ee-17.10.3: = Success . . . [00:12:35] [release-aarch64-alt] [2025-04-07_23h46m01s] [committing] = Time: 00:12:29 Queued: 285 Inspected: 284 Ignored: 0 Built: 1 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 . . . So: about 2 min for build-depends and 6+ min for package. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Apr 8 17:01:27 2025 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 4ZXC6950y2z5sff6; Tue, 08 Apr 2025 17:01:37 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Received: from YT6PR01CU002.outbound.protection.outlook.com (mail-canadacentralazon11022126.outbound.protection.outlook.com [40.107.193.126]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXC6934Bvz48tq; Tue, 08 Apr 2025 17:01:37 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OXBNCyW4FvBg/oyDvZTpf5tHfAJlX5gTHAShrnLLUFQS8MNEg0cmDuh2rf4OJRvQdRoTXFvSL7RDwBVPjgljKZPCKMRlF8kbltGAIzeiHHfAC9q+oGbv539E80O+8zLzX7eUEq2F6CDyhzAooTUVe/2sdmCWiaApfClmxO0pBwee4ZQ9o0w7Kl2W0ax8HZ35JwbthTiV4jon/7Va4n7vRXZAure3bkbnNXXbknqh/XTykDDgXHplUNCIbU2F8xKvlgA0NC75SNNFXiaRQ3NYicz0H6nTUV0Q7ZQJsL37cAzSc4htvcW8eTEEO2o+S5aRnGXQ9gVYuOf6Q7rCjZJvXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7SXwlLo+rOn/bLupqlAKcDlYYyEtAHtOOosl2GhiDic=; b=y2fdIBBarG7tEfJvetz+iFc2zzcLqw5stk0bVhKxmJ5daQ4LiN1j9ZgsmwIeuMYCgKkp5dU9qd72vCnMbvep8neN7m+GP6ijmUFKSIKZB5Udw3YLZYrE/OXwCiPXX9hn9ngjLcNYSK+pmiOUKg9yb3z6Lb5e1DNPuFvHmSXq+CoQXKva6wYAa8h46Pel7Gcso7sTpaI4ngGeEycRi60HPp5NPUQK/89afpKRbjB1LV78KdifraSz867d2nWwcTzGeuwIo6SMWGqPMIapv7qAoQmXtbONB47kwVyzh+sV2MYQy6/Tl7KlYGAqubz68eVKhTknT4cUBUM3T/+9ep55Og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=willowglensystems.com; dmarc=pass action=none header.from=willowglensystems.com; dkim=pass header.d=willowglensystems.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willowglensystems.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7SXwlLo+rOn/bLupqlAKcDlYYyEtAHtOOosl2GhiDic=; b=b4ZIT9ZKMe+Tm8n2HCdUWgzojvHwP1LOlwucZ5346krioXBOiLN48ov6uqxk2xIWt/DDT13jDb0I+LxrAp1vfm1t+r/M7FqPfDPvCXpYjKyYYdD+qpvlmg6GMjWSBR7Q2Pd0IzWrkgYSFZ0/vPQBXNqA9+45nY2LvtQRa9d20PI= Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c08::23a) by YT2PR01MB9046.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8606.34; Tue, 8 Apr 2025 17:01:28 +0000 Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d]) by QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d%4]) with mapi id 15.20.8606.033; Tue, 8 Apr 2025 17:01:28 +0000 From: Robert Austen To: Zhenlei Huang CC: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost Subject: Re: pfil_default_to_drop Thread-Topic: pfil_default_to_drop Thread-Index: AQHbqAfyk4Z18yjsM0yECEK2f5QGrrOYyea/gAAA4zGAADehgIAA+tGK Date: Tue, 8 Apr 2025 17:01:27 +0000 Message-ID: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> In-Reply-To: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: QB1PPF4C719E46A:EE_|YT2PR01MB9046:EE_ x-ms-office365-filtering-correlation-id: 6adaafb1-2cdd-4a26-95e5-08dd76bf00c4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|13003099007|7053199007|8096899003|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?3P6siqLdtG3hcoll6eQK6ANLoIN3/t59SDxduJuwlqe8b6HZNaAGNXkQrRTi?= =?us-ascii?Q?EQ7UUDjOYVvfbQdR+SFI02bFLF54ZbAFiLbSqB3K553cOGd6Dho+033YpZ/r?= =?us-ascii?Q?Hsl0uLCVpxh3SUZk8BUXEEeU9LJuK3ve8s9jZ1XhsK9YHtAZ/Js2+N3OZeM5?= =?us-ascii?Q?AKWHsHgCvHNalIJH7sijiIQJZQ5lY1zXBwBBtbMlludV5avwbzG3KfbAy1or?= =?us-ascii?Q?2wvUkLGvyZQXE67L8QIfAtTgCjl6eybgGqZRU6kqHQAgvJsBPIHeJXRAq0tP?= =?us-ascii?Q?mHujs0NqUe0hygxWzfRYKWLwCOEB9a7hG3TRrC7ZfkEVyCNJfe7Epyko7Imh?= =?us-ascii?Q?7IcDnnBWPr5JT/RMgnpTQi0ug6gsiCXZBaXcqM8yMpuggbpysxbB2rTjMrgL?= =?us-ascii?Q?ig4+75QRrlPG4qoIQ1ybA7xBWa7wTYuRlHGTBkOh2I01ogbupB81cneQaziz?= =?us-ascii?Q?DNQYsyUYSyBMybUf4T9emUp0nGalLOtRr/E+6TLQXxj+14Xexg6CYsi2GCWs?= =?us-ascii?Q?ft3erlpfw93W1TnEuLQRZ/fY/5pej2hlCr59v49HDlISoZuv/GZxqBU8AwB6?= =?us-ascii?Q?uOc+69NWk7r2gN9tW2/2G8s/02lo+wu9DkGKcLUHZE+S98l0aJQp17yHu70D?= =?us-ascii?Q?a8CBqAsgd18c7eSd34x1Yms04yMuCjRlVrU4Ba6f5/JV+nFZgPhgZR1n+S5X?= =?us-ascii?Q?mncvbhIk5mhp/dY5p7kLPv99MsS6WNdy1T6QR3EcHS8eijLKqHfvYlCRV+YM?= =?us-ascii?Q?sgGnUw7ABgGCthT4o06o7fgxaiB4skZJ0VMfbEjH3CpoSnkcIzi14ks+hO3i?= =?us-ascii?Q?Tpjsa1VQBkIkRj0aDTXySID+0OkgBQeMNRhPeXPyLWUFVOYhyBBkLGiu8cnO?= =?us-ascii?Q?5Af7GT9pZW9faep43qLG/PBJP/r/FC+EnomqeuPF/LZZ1Ih6oQQ8tghObmJm?= =?us-ascii?Q?g7WcMYHAHMQgG1rEexDf1aWY4GDCA8jZ0KZIaUudVsngj4cow9s7xCrZql2Y?= =?us-ascii?Q?HjwZXUEEPo/n0e/LMmg0q2rZIoWLd3MyEINWlTU+5BqPjuSCcGPSKH543EbE?= =?us-ascii?Q?ha/Ncu+KUYs7hZPJR7rxzrGWLVECPFo1hNlrFaiihovrteGVFcw/2fGTnIZp?= =?us-ascii?Q?pD3W32hDfzhtBsDAT9aNOVZ5YyFMRVt5GXgG2rvEDZyNsvBmJPHAjXPaZo/L?= =?us-ascii?Q?Z3+TR0YeGY52dA3YxOtY+taLZs35u9CQPpNgtO6nzCub7sS2MAZ3ObaOzw+r?= =?us-ascii?Q?MExK6PsvOyB9GB1EvpuoPrZYbk0yqNn4qYgnwvvmtg4rMnKdMC30mYJpavaV?= =?us-ascii?Q?Ce1dTqAv/yOHtny9BgttN6WmBFnhIp+MDboAX6Dw+R2g4FC3uJ3K5CS08r9k?= =?us-ascii?Q?k9V1Gb0LUFUWLVyhu6AWV7BDmUk//xX+qNy9+s1XG+6/OgZVcpdu/hLFybZ+?= =?us-ascii?Q?qiQ96BMQVUtV3y7+lONFcbjF1wm979ik39kJn98Ftv/kDd9po8rSxvpt59d3?= =?us-ascii?Q?e/8nqL8ThzVzHjk=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(13003099007)(7053199007)(8096899003)(38070700018);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FYuVT5wPcim6tDy0MyIDzAFiGMfRAbW4qEgGMkDjfb8fXq5YsgEZs0TAn9Mk?= =?us-ascii?Q?ChzdUnGVmnj+OdNaSRgIGKL1SToCFpQ/vMhU5r2Xk9zve7v1+33Ek6skM68W?= =?us-ascii?Q?j0epvKNGu3/ggrQT4uP1cymAjlI97ZhoHM3K7PBnUh8B57xMh73SN+gZY6Bd?= =?us-ascii?Q?havBC4PPxrmsYgRRaSf2w8N08YjwovsmlQlSQypv3CCO3IQ6Uw0ry6Xx1UiN?= =?us-ascii?Q?6fKfKWzjNSEztgHBNbAO3o4ijNyQD9wF8Cu+SrI9y5pHHtEgBS9KDIFXnHbz?= =?us-ascii?Q?ET0R68z+7yPqwOTivtw/Iq4T50SaeurXSFSCl2ev3az5LQf5gA98LVOQ9D2M?= =?us-ascii?Q?iCd9vomGScdTi13P8WhIqc9oraw8aT/fWnH9D18iNsPm0YzoKzf6ZRiKtfdH?= =?us-ascii?Q?h7F98ySCOtFZhYVfs1MH0/S29NbgbgOCYqqqzKttjJZe0VKSRBSBwNnxW9Wj?= =?us-ascii?Q?fwhc8trKiNBS2B+nOeKuZakb/r7GHlgoUVvuHlgZ/xSr6c2hBG0mahpuS8cy?= =?us-ascii?Q?H/xqXOeQquGQ20w0QqKxr3TYShfMgAWvjz/cfW4HHg0lf0mbpnnlEgYTIKvO?= =?us-ascii?Q?OGvL1esjt8xKOymB82ft5eWj/5TYGBc866Sxm7i0oISRdA6gQPI3ern4URwf?= =?us-ascii?Q?bBexn0LRo0Y9D4k+kYCcw7gjfGbtv3Icg+kNmCYNuxSM5NdzKXKuvLnnMEGL?= =?us-ascii?Q?+EfmsMum2b6BA4XAFs+gDbMXUHq7xjoxSyZzZ6GGLXpnpl2rI3EAQV0e0Lkn?= =?us-ascii?Q?jMpAqymCJk6XomoR9TPzfEZn5rxnrQFKpP6L7cJudzce/ot/jz1X5s4/1zCB?= =?us-ascii?Q?ivo9TpIkQuwVm8qm48Xx1RKHYPUQdTgTdaiAFWJEyfCR63PrVU/jtwbg0SPi?= =?us-ascii?Q?z8dskM8zzmZIRd4UUs8f6QEOLR+R4F1llXv7rG8ffkolXzZtLCsGhm3lmtmQ?= =?us-ascii?Q?4aVC5lAMhbXbSsAzTtkbrsp0v9CQv9H+pDCGcQiL0YkTDqMT2Q42R0L2JRXo?= =?us-ascii?Q?fBtrB8Et8XfvJgdNxN7rD6WIIE1Q10cURN3F339FPLpncrOcvUmkTlK0ds99?= =?us-ascii?Q?IXjgLmxzdHxnENQ3hQ7GM9Y6CoC6qEG8+zjdmVVXE+dhCpzMQY6q9xAMHzZa?= =?us-ascii?Q?lixEfVVfPIo7t/j2PklqVq6291FNiHK+OsvfP38/5fnOto57SlST5kKPakaV?= =?us-ascii?Q?J5HNHlefWFsqYSERij3u17WinJztuZ6pf6ttWHV3Cj7h+GvnusLhlQ1YQdTK?= =?us-ascii?Q?hBNyMeCcUOwbDXPOyRgg6/xIKZqqFi1Qs8OCLn5166/Akf0ggXKTTIIMFbhG?= =?us-ascii?Q?iRsJtv4YYzNsuZlXawxLJM8JErielWN/YrRcjqnKybwIvjU4LzNApKGxXXxA?= =?us-ascii?Q?oJ+dwe4QxBid7V8zbV96781ivV7nMR8KjHALUOmTSEzq6QHFCSTwOtcF3H8R?= =?us-ascii?Q?O05yKuOfVTq7QEhzDZFMc+JLMhFCRfnhMQ93cQrFUagqKDTzK56gsJ/cPaaT?= =?us-ascii?Q?f+H2JM/f5w+S9ixo+0yWrAz6ot8B7GaPkcoII2662imrKD9YKXjtHDEYng5n?= =?us-ascii?Q?FSU6SOr+LElDC4n81vdzz64G9jS9ENhqzy7l6sCIe5S4ZyYMNV/7U/pwqzA1?= =?us-ascii?Q?FS1WTwrTks1hxCNwTt0CsIw=3D?= Content-Type: multipart/alternative; boundary="_000_QB1PPF4C719E46A03770B2C7622042A91B6EFB52QB1PPF4C719E46A_" 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 X-OriginatorOrg: willowglensystems.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6adaafb1-2cdd-4a26-95e5-08dd76bf00c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2025 17:01:27.9911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c7bca0fa-9d0c-460d-8770-da688c84194e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Xa7I/n4xGLHdN6+mBOhCwkwYMhqE8gthPOP8/juKmIUfucb+he//LmfHzwJAxVQ+rhu4rgyT8+/YsQDhOO17hKxrAzUBIB3kvXzgQOxNy0nG4t4xsLKOLB/LYMo/bp8H X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB9046 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US] X-Rspamd-Queue-Id: 4ZXC6934Bvz48tq X-Spamd-Bar: ---- --_000_QB1PPF4C719E46A03770B2C7622042A91B6EFB52QB1PPF4C719E46A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I respectfully disagree. PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks. if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= . consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= he pfil layer in the kernel has no idea what the filter will be, assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and l= ikewise the equivalents from the other filters). as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP, because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= all, so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= can ever provide. thanks! ________________________________ From: Zhenlei Huang Sent: April 7, 2025 7:55 PM To: Robert Austen Cc: freebsd-current@freebsd.org ; freebsd-net@= freebsd.org ; Kristof Provost Subject: Re: pfil_default_to_drop You don't often get email from zlei@freebsd.org. Learn why this is importan= t On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: ________________________________ From: Robert Austen > Sent: April 7, 2025 4:33 PM To: freebsd-current@freebsd.org >; freebsd-net@fre= ebsd.org > Subject: Fw: pfil_default_to_drop ________________________________ From: Robert Austen Sent: April 7, 2025 4:21 PM To: freebsd-current@freebsd.org > Subject: pfil_default_to_drop Hello, I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point. I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. Hi Robert, So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.k= o ( via the loader(8), /boot/loader.conf ) ? With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), y= ou can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.= ko. See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9= 913226801f3073bd . After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no filter is loaded, i.e. if the heads are unhooked, then PFIL sends everythin= g thru to its destination. So my thought was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the hooks are unhooked. If no firewalls loaded, then the system should behave as is. I do not think= PFIL_DEFAULT_TO_DROP is the right way to handle your case. [No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them, maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.] Normally I'm an embedded linux kernel basher. I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes, so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her if I could... I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch= "... I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64, but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version. But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along. thanks! Robert --_000_QB1PPF4C719E46A03770B2C7622042A91B6EFB52QB1PPF4C719E46A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I respectfully disagree.

PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks.
if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= .

consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= he pfil layer in the kernel has no idea what the filter will be,
assuming there even is one. thus PF_DEFAULT_TO_DROP  has zero effect (= and likewise the equivalents from the other filters).

as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP,
because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= all,
so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= can ever provide.

thanks!
From: Zhenlei Huang <zle= i@FreeBSD.org>
Sent: April 7, 2025 7:55 PM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>;= freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost &= lt;kp@FreeBSD.org>
Subject: Re: pfil_default_to_drop
 
You don't often get email from zlei@freebsd.org. Learn why this is important


On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@willowgl= ensystems.com> wrote:




<= b class=3D"">From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point.

I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard
to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. 

Hi Robert,

So why not defining the compile option PF_DEFAULT_TO_DROP, and pr= eload pf.ko ( via the load= er(8), /boot/loader= .conf ) ?

With 13.5, or upcoming 14.3 ( you c= an also experiment latest stable/14 ), you can turn the loader tunable&= nbsp;net.pf.default_to_drop to 1, and preload pf.ko.


After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc
or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL sends everything&nbs= p;thru to its destination. So my thought 
was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the
IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the 
hooks are  unhooked. 

If no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your case.


[No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them,
maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.]

Normally I'm an embedded linux kernel basher.
I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes,
so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her 
if I could...

I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"...
I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version.

But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along.

thanks!


Robert




<FreeBSD-14.1-RE= LEASE-amd64-pfil_default_to_drop.patch.zip>



--_000_QB1PPF4C719E46A03770B2C7622042A91B6EFB52QB1PPF4C719E46A_-- From nobody Tue Apr 8 19:06:22 2025 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 4ZXFtX1Rjpz5snTh for ; Tue, 08 Apr 2025 19:06:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4ZXFtV6fW4z3m1T for ; Tue, 08 Apr 2025 19:06:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=QrhEsOUy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744139196; bh=sLZ/IXobYuU2CcBNUywl0D/OZorR/q0GcgQ1KV1V1w0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QrhEsOUybxJLp6XvLwAH0FyJicFccMM+1UPT9xylmipsN9WJLVBcCTB5V1qt+bPYmPllqxrWTCXXxjy4DBPASNA75FnX1AuyiSCGaKz9L+eLDQDUOJeQphvLE+CY7Uz/w7xDDLWF7aMUH3j+m8rvm0eoxM9kHhzycce5D/fIKwibxr+zpfA8om9mmguqXEFmHyJzdXBKJj3F6H8HIPpYA294wV02Q9zgUxguQ4DZWzT1x1WSalfxOm0eC15UxuVW63Azia1B5MmEkivXScwQcOPvF7LmelLdHFIPI/bVZeorYAJvDRkqA4gJimWcynPGzjV9c8lP4KHgVnZR2yqVhA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744139196; bh=tRzKWydn7undFAPjrOSEiSj2Feoq/5dMQktRFrNkzkX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e4O1Yn/IsLV0Hj2njX+z6tKdHP4kXUSqqv3jpp61YoeRBRURFuRUYp7Kn3C9KwNXhIh43K7Yq+uNAxLYItj5US3SxKA1XjSgaTD0qE22iaQHo64LND9h23aft92qGSOrJWtPPUs0it70mNGqdbkhFJo2ydqpXSACCFY8DWN7Ora3i7iGkPYizlh+G51S0mOXGUyQQX/ByP/aFC1TvAMPnpG/K08lkBz8fYdNm0f3wPSELgAwHg2yyFzjzoYGjyQK5Ylfwr1N/m4h3X9EwdhcfFevPErOaE+3q5J+i4gl3mU5V4gRFBQeSuT2ZFTsXgLGkMqQYicGyOA7BFTns8cLGg== X-YMail-OSG: NUTwzUMVM1mhCpTvI8zez6V5325SIBfUysf86I7qQef73VkMSAymvOhJC2kxZg8 aNQ1vkSYbV48Q86NiHM_SX_ppLzDEGMIgijQXYfDrvtMUKBQzKh1BMZpa4BpZRuDntm_LzF5ErAL j0IdeMAlbG04NVv_xvImuIBnQoJ5zS6fKcfnhsoZ9EcbXrN9SvD27OYPVhX2YbCJIJnaSQiLVj5q 1bW1icW6gUrAjKoa4u0SAzxW3ioibhbNnZvBqMfcbkCqqICfETw.CZrvV42qdbk539JA_XBGbaHL 5gxvsuiU3r2z9sxDiwrOMXg0cgm7IanGylFpT2_6S8vI5iQM7IqpA9hJgfr1TzO8m5PZQybbTaOW tEEd18v1QDEBVj.x3mV_likngDLIuA03boGiqYSEkZVG1GjSSWsfEvcda.uucfNw99.z6j3Q50Q8 6rtiB2LSl.S.0NZ6JeF5jSr0eQJ8VoFcSR_.SK8ODf6JF1ujeJhPb8u9zV4gxhzKq7ln3uSTuAUV 892sgNVvlZDbGqSIMvofx0Vu06VlRddtpT3EUzn9kvd.Wrt2U_XvLbZlqxj6AwVP.0wRdQKz_ubu gTtJzNJl6JMw.9CTQ3VYl_cGDRroxU8WqDqI1TLB5w1uSQThRRzB6H6gNcEudg7KFSy6Yel58YsS d5XmzrZzKYobMuYKFjySor1p7oUEeyTdgY2nCF6tgT3YuNgz6u7c4ub652qsZgMq.BjVLQyMssYS XRiQDQ7V4vgi24VAhKle8wdnjskt3IMVr_TcL9p822Ql5GLGaqYgZEEREhUnb_zgnCi_lE8PZkAn ..lOZxgB.ynE8_V68o5xtXKsCqLysxZwRpoTQn_BBLW3LEkUnRaZ9d4t4AVziCk1qrgrSUUlSEAU EPKC82I2Tfr61M.Y0V1xMYEJaF5XG7I7Xfaub2ArKp_wfeI70TU5aYzcewR2TQlZlt7oIn0Va0vY JcOyKIm9UZDgTVJWtAPwX1g5mcioPMa4mhm4__EooyVJ21qm4yZlI9qeuE7SimRrYXOgeWgoPXlj jLxKzRN6tfUZCr04jpcUGuyxwvKtHAYkh5ksaEH1LvbycEG8XuY1JBunNfGkqPeRmG_Qs6AqFctJ 6mj9WI8kf2HK_Q_WvJy3J7sIi0oTZbf47X5n9lSKeYn56s4gy3hv.v1E5yA3nRUxkNjbZeKR3ne3 0roLgp._cW8l1KMAucdi7lzlqC6tK8H0e5UEug_uPjqVfZTOChrjg1RmVMo.nwbLrSfNO.a3wx0C USr.8IovVBxgB6.VphHTP0SqVy79aroR7e6LbzVR22Vuwaa7eKF1xTpptl8WOUY3JJAeHCZhWwrv .6JLKlqB1GCXNaLGbBDJ3XbNq3L6Hs_Ox5Hgzie9l0mET28DbIY.JqP07ZUNHIF2dT8a.yEUQyY8 UJme.L5PNPQIMogEMq.Cbu8XGeYMw7vknE_oqrcn7euaErK9fx8zLyPw7YGhDhJJURM80jTDwY3Q 1GxnHbK8mDfQV8bjRvebpq8eZ414ZjnsjBg8SEXWzk0PQCdidsfC0SyK5vIghG5CAqKvOCvH6T7Q B6MZcC2Dir7pxB3zlbfLEXmKr2Y6ck8IEB2oLsbWsxSoZr7mb1qVDyVb.rjs2cY3UJD5ngf8I1QQ 2RFOK83Zj8vE8362PvSnnp9jRy9_q7MSk5EbsI0gU04x.Lx0LH2umIOV29Zg3Upms.k2gkdmFuor vw0YCY819sP38Dget.LWFRAlQq.U9sZ4cx75IEjHe.2zXQ907rM1I2Nw2MIg99LGw7lYLVJFwlTP bP9UDEPEay.2ay28me32yVJf5pIgjMpNKpTlym3pgGbNTXc8kg19ZF9lIISBvtpbuJstAE9CWcd4 Y_tNCq_MCsSYeJbXxCNtycGpHvxEfdJYxlTGd7WRgz.G80aS5EHjLCWkH3RWvxw.sXxzuohSPA4f DOJ5ahnyHjhOCvt40l6G2_n6GJawqieg2F4E1TgmPfOfFQ_gRUem3G2bbGkvYMZ6daBIpMf4DXaC eNAUpDMOY01B6.BLc_.QSAOlvYG_dH9iC33h.Tq4_UiaPUa.mspXcw2EjmUpMW5RXhOwXdvOvUHp atQSKnxK1LS_5iWrG63FVpAkzTaH_SwENEIVfB.vmNTnZ8Cf8UJVO9iQ84Gzd57sjrCjxb8IEckh qBYbFPdT.hhXETvSW5faSUp_sRFjTq3.gdjA73RxgutVI3P6azki4Xp4RO0YOFtNEHaBT5HjCIBp 0rcSyFQ3sQgciHkOCZZYOs3BY1LFSTTffkcEFf19vCQ2bqx2pB1rqJA0bZ_At.E1OFOc9t2o979A X_Z7Wy__J X-Sonic-MF: X-Sonic-ID: a1fb684f-d8ed-4b66-be26-d2232d8a8650 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Apr 2025 19:06:36 +0000 Received: by hermes--production-gq1-6f8bfcd964-2cf6n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dd30d9c380f444576be1fd3cd50a1003; Tue, 08 Apr 2025 19:06:33 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Just notes based on various official www/gitlab@ee and @ce build times] From: Mark Millard In-Reply-To: <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> Date: Tue, 8 Apr 2025 12:06:22 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> To: Baptiste Daroussin , Konstantin Belousov X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.06 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.205:from]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.95)[-0.954]; NEURAL_HAM_SHORT(-0.61)[-0.606]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4ZXFtV6fW4z3m1T X-Spamd-Bar: ---- The below indicates that whatever is taking the extra time is not strongly tied to processor performance. www/gitlab@ee and www/gitlab@ce turn out to be good for seeing larger scale elapsed time multiplication factors. That allows seeing this. I'll note that when, for example, www/gitlab@ee is built with no other builders active, the large multiplication factor has not happened in my experiments. Based on pkg 2.1.0 use on official package builder machines (so longer than normal times but noting pre-2.1.0 example times as well): ....... @ee @ce @ee @ce beefy13: 01:54:17 01:26:19 (pre: 00:07:36 00:06:24) beefy14: 02:01:45 01:17:36 (pre: 00:07:59 00:06:48) beefy15: ??:??:?? 02:00:48 beefy15: 02:28:31 02:18:46 (pre: 00:09:23 00:07:43) (yes: 2nd 2.1.0 run = on 15) beefy16: 02:35:53 03:00:42 (pre: 00:08:49 00:06:55) beefy17: 05:35:01 03:32:05 (pre: 00:09:40 00:07:24) beefy18: 04:18:07 02:33:34 (pre: 00:08:01 00:06:48) beefy19: 01:02:46 00:38:10 (pre: 00:08:21 00:05:53) New, much faster machines: beefy20: ??:??:?? ??:??:?? (pre: 00:04:52 00:04:19) beefy21: 01:56:01 01:31:49 beefy21: 01:39:27 00:38:49 beefy21: 02:02:59 01:50:03 (pre: 00:08:27 00:06:43) (yes: 3rd 2.1.0 run = on 21) beefy22: 02:15:04 02:14:47 (pre: 00:06:47 00:05:38) aarch64, slower machines (Also: no armv7 examples): ampere1: ??:??:?? ??:??:?? (pre: 00:13:38 00:12:24) ampere2: ??:??:?? ??:??:?? (pre: 00:13:47 00:16:49) ampere3: ??:??:?? 03:34:43 (pre: 00:23:32 00:09:41) Some beefy21 examples are rather similar to some for beefy13 and beefy19 examples. But there is also wide variability in how large the large timings are, even for more more similar machines --or so I would guess since I do not have information about the machines beyond beefy20 and beefy21 and beefy22 being rather new and much faster. That also points to something not tracking processor performance or the like. It also does not track the number of cpus: beefy20, beefy21, and beefy22 having far more. Near live-lock conditions or contention issues? Something else? I do not know which official build machines run debug kernels vs. non-debug ones (15000??). Any idea how someone with access could find out what the issue is during official builds? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Apr 8 19:10:19 2025 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 4ZXFym2zqwz5snX8 for ; Tue, 08 Apr 2025 19:10:24 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4ZXFyl21ZSz3nhB for ; Tue, 08 Apr 2025 19:10:23 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=NjBmJLHR; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1744139420; bh=iFKVc3NfsVuPBdL6mOCMxQvAkMfcK/4ifju+YykL1uE=; h=Date:From:To:Subject:In-Reply-To:References; b=NjBmJLHRF5DE6BlF+LJ/GigF2/BRoE0Dww6xZ3UCf9VPzj92/RLEfi+wcWTiWahWR G2eOkWpzgl6aUz1EUoN9dtAQKeiZUn0vkxXzqsOXpDWHQTpqshDo2RSGUw3bIMnrLt NRXmkG623is33R0E3A+w+MUAQVgNksDi460Ln3cJ1Jhc/ex4dLgs8JaQ09NYAIrAXY OWJ2oZR9xdHUKRyKAYDZfRH9lxcyOzn8P9tsYyq36an8DdZG2DRO8QoOcJVELFqRHA 29fIDfOuLKPblZpgMGrr9YscylSy0NOFhTHesWiU3KZGgnkBIb5rk8DA7EQ1UYsQNh ByM7cxICvt6JbU/h2y9E4f3nn80BBQVCzLDjbSbfKampfhPdsveZprkUT8QxT7r/D3 aT5x+5Psn05gBnw3mrsXOwsiQMX1Cvrx6dmudm/8ZU1ireTqsl4i495uy2O6hn/UQe g9nLL0SXFzGHul0MUGpTGOtnblvcsK3QY5XB0CQJW5CsLgmKNZ9xKph3QpzInY/jv3 nmeuDl6W5s5h4jxXPmPw8ZeO5AxrlV//9bQxdxvE5FYZzFIhPtdNIc1towTSPupHr3 BPxAKOCInQgs5GEe7iv5cnY2qvHIkAnr8w9xfFkgx6c2Xb9tdT6jSLqT9PNFVtS5T8 UjwtKCeMnHfRDIlu0bL5IDnk= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id B6AA35B4A18 for ; Tue, 08 Apr 2025 22:10:20 +0300 (EEST) Date: Tue, 08 Apr 2025 22:10:19 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: elfcopy: not found User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <91799056-ED1D-4D9D-ADF0-C5F4E776EA15@ketas.si.pri.ee> 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-Spamd-Result: default: False [1.30 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_SHORT(-0.97)[-0.975]; NEURAL_SPAM_LONG(0.83)[0.832]; NEURAL_HAM_MEDIUM(-0.76)[-0.760]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4ZXFyl21ZSz3nhB X-Spamd-Bar: + why meta mode would be important here? wasn't that just a cache to make inc= remental builds faster maybe ln -svi /usr/bin/{obj,elf}copy rather? unsure if it fixed it fully=2E it did build=2E i hope that efi loader actu= ally works too now it likes to override path i guess (for clean env?) so it didn't take that = symlink from /root/bin either=2E=2E=2E irc said this: 04:50:59 < ketas-> hmm 04:51:01 < ketas-> elfcopy: not found 04:51:38 < ketas-> i haven't built current for a while 04:53:15 < ketas-> if that's that updating entry 04:53:28 < ketas-> i don't know what's the fix 04:54:55 < fbsdslack> What are you trying to build? I think you will need elfcopy for stand in which case you may need to build kernel-toolchain first 04:58:53 < ketas-> my mini variant of world+kernel, on 13, i didn't change any config recently, it must be change in current 04:59:12 < ketas-> what is that change? 05:00:57 < ketas-> something in src=2Econf bite me? 05:02:53 < fbsdslack> Unconditionally installing elftools objcopy as elfcopy and using it for EFI because llvm-objcopy doesn=E2=80=99t support PECOFF 05:27:10 < ketas-> hmm =2E=2E=2E 06:36:46 < ketas-> where does one even get that, usr=2Ebin/objcopy ? 06:40:50 < fbsdslack> yes (it was installed as elfcopy long ago) 06:40:56 < fbsdslack> :q 07:21:06 < ketas-> meh, i sleep first i guess 07:21:13 < ketas-> what has it, 14? 07:21:25 < ketas-> 13=2E5? unsure about this all=2E when and where was elfcopy installed? forum has this topic too surely it doesn't exist in 13=2E4 also if it doesn't exist in host (or under that name) and is only needed f= or building=2E why doesn't it come from build itself? unless it exists in 1= 4 and all people build 15 on 14 what to think of all this? it's pretty regular 13=2E4 too=2E i would be al= l alone if i would have custom system=2E but it's pretty stock=2E my only f= ault was to try build 15 on 13 On April 8, 2025 5:13:31 AM GMT+03:00, Minsoo Choo wrote: > > > > > >Sent with Proton Mail secure email=2E > >On Monday, April 7th, 2025 at 9:50 PM, Sulev-Madis Silber wrote: > >> --- boot1=2Eefi --- >> SOURCE_DATE_EPOCH=3D1704067200 elfcopy -j =2Epeheader -j =2Etext -j =2E= sdata -j =2Edata -j =2E >> dynamic -j =2Edynsym -j =2Erel=2Edyn -j =2Erela=2Edyn -j =2Ereloc -j = =2Eeh_frame --output-target >> =3Dbinary boot1=2Esym boot1=2Eefi >> sh: elfcopy: not found >> 313=2E12 real 432=2E90 user 44=2E54 sys >>=20 >> make[1]: stopped in /root/files/fbsd/current/src >>=20 >> make: stopped in /root/files/fbsd/current/src >> 29m18=2E50s real 43m6=2E42s user 5m47=2E07s sys >>=20 >>=20 >> host is 13=2E unsure what that is? there's entry, 20250314, in updating= but i can't figure out what that is and how to fix it=2E WITH_LLVM_TARGET_= X86=3Dyes maybe? unsure how to fix this on my own > >I had the same problem=2E Back up your src-env=2Econf and create a new on= e either empty or only with WITH_META_MODE=3Dyes=2E > >Recompile and restore src-env=2Econf > From nobody Wed Apr 9 02:08:31 2025 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 4ZXRFT3YVdz5sKwd for ; Wed, 09 Apr 2025 02:08:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXRFS675yz3mh0 for ; Wed, 09 Apr 2025 02:08:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-il1-f182.google.com with SMTP id e9e14a558f8ab-3ce886a2d5bso60582245ab.1 for ; Tue, 08 Apr 2025 19:08:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744164523; x=1744769323; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AxV3uDgOnvYw2BZvYwtxmUyceuYpjtMXVWuUSKftCGc=; b=K3bVdFW0zfppymAxQQdHwk38aUjWF2XUuNXdYUedlvrz1CHc4+FP6CHC07ljiKMiyq JIAB4lD1vZGkSWzgwEAs5/LXdh5sw/VEIqGqezYfox3h3wevKiCqDVrBMj5d4MLDbhuI sGo+lIlVExYByTddR7d28/T++FK8iGzoispawjUd+UCwHKou8Narul8DWp622X6/a2HE 70s3UdpypgGQ+dKJ6VhkurYh0jC0BbalD2mgpXp/l4dYHECo+9eLTTHIQhORRlYrR1Xi wwshFEe649hTQf4tp1uaE/OwlfKVgdffEBzABbmqM7geOE0N7Sz+gJue7E+OJXQ8OxUp 12ng== X-Gm-Message-State: AOJu0YzUZ31z7vdqzdzfGsYBPcRmtqV8ed7Z6zTVKGcy3CwOvdiQkn8N qV0B6DSnygqk3EEepANSd+kaMc80FlrbTUGDRArGEGnPhCVEBVXFJdZiP+mlqK6XKvpwloDy47u Td7TV2hpaLclmu3TEllRDwT3WdiXWrzCZ X-Gm-Gg: ASbGnctaYjZQtZg36/hIi7tUG62+ijE8fxUa0GZK8Pk3CfpK3nGYl/rHC1mW/2KSPim qnC4Qo6PyD1wP5mnT9bv2ZfGxum/oM7PHdOtUOltNoI7Jldk9Fp3SRIAv6l6xZFbWwKlM3MyCjt dB3+zlGfl7pbmqZRiyskPEt81LZw== X-Google-Smtp-Source: AGHT+IGGeU5Uv/p2E+VypaxXqmEFzTDUr5G4OUH66y8fNhrCjzghbBqUrLozKg39sEARQvUuPeRTwYzqwzqiiZKLV8I= X-Received: by 2002:a05:6e02:3304:b0:3d6:d145:3002 with SMTP id e9e14a558f8ab-3d77c2cd3e7mr16567585ab.20.1744164523432; Tue, 08 Apr 2025 19:08:43 -0700 (PDT) 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: Ed Maste Date: Tue, 8 Apr 2025 22:08:31 -0400 X-Gm-Features: ATxdqUGrEi18NJjZURPL7b3GGlh-8t3Zz7AlHQiDKcjVS9YEdfifvQft21H1_W4 Message-ID: Subject: Re: elfcopy: not found To: Sulev-Madis Silber Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-0.81 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; NEURAL_HAM_SHORT(-0.93)[-0.926]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[carpeddiem]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.182:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RBL_SENDERSCORE_REPUT_8(0.00)[209.85.166.182:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.182:from] X-Rspamd-Queue-Id: 4ZXRFS675yz3mh0 X-Spamd-Bar: / On Mon, 7 Apr 2025 at 21:50, Sulev-Madis Silber wrote: > > --- boot1.efi --- > SOURCE_DATE_EPOCH=1704067200 elfcopy -j .peheader -j .text -j .sdata -j .data -j . > dynamic -j .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame --output-target > =binary boot1.sym boot1.efi > sh: elfcopy: not found > 313.12 real 432.90 user 44.54 sys > > make[1]: stopped in /root/files/fbsd/current/src > > make: stopped in /root/files/fbsd/current/src > 29m18.50s real 43m6.42s user 5m47.07s sys > > > host is 13. unsure what that is? there's entry, 20250314, in updating but i can't figure out what that is and how to fix it. WITH_LLVM_TARGET_X86=yes maybe? unsure how to fix this on my own Do you have anything in /etc/src.conf? Also, from the top of your src tree try: $ make -VMK_ELFTOOLCHAIN_BOOTSTRAP TARGET=amd64 TARGET_ARCH=amd64 -f Makefile.inc1 From nobody Wed Apr 9 07:48:11 2025 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 4ZXZnG74qXz5shdp; Wed, 09 Apr 2025 07:48:18 +0000 (UTC) (envelope-from zlei@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXZnG6SPlz3RDn; Wed, 09 Apr 2025 07:48:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744184898; 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=Bve4yGyu1TEMucTKSXCLe+oUkHpkIsJ6geY6aVTZJOU=; b=qLc7VHSQaqMzzuw0rgG/ZuZWtwNnGcuhZQu+XkEHKKq6KJVlH+NerftE5e5hyDv7O/toTs Wq8x7d0XmLBDP7/kXqTBGBRI1tdBMCI+Wx7p03SBF7i+OO77wE8GVyDU8nit4uZ8KBxlyy b6de3ZujSmLQinC4TLcMmCZAfrEIOwNdPGGiNKfPVju/YB7XxJF7NFliXFC9aIiy+dtulF 30iRbrrySMvgPjbGVlmp3y4XIV0aGo3MA85CfP7jMtMFAsSLn9uFkFbharoGCNTZfMQInp 1iRikEIJ5Fe6a8w9SoZUoJWDeocENiha5kpgxm6br/dIy/HfgEOfRiqYmaZ9Bg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744184898; a=rsa-sha256; cv=none; b=XaoUtN0cXUoD0tqqOOJKZ61uayd7OVJIHUxxyNTlPGZwloYx+wmKz7oZmHDevuPl8o/mcD vo9EAYaptB5s1wp1TMD8XVrK87BEIsXdutTTQLw1Idln/kCID4i86ZrEyZfLh9nFD1riDy fqgllBgf575OIfm4Wsg+7mkLPAscikg+dmVrMK10E2m77GeZ209nFhXW0wWBIfCA5qr+MQ N/9FXXtEOFurcq1M/3eXykhoUCRdpUmzqhqRCtKISB4+elM5BRY8OSozzqBPY47mps7iOc vVag6KHmEn1TPkriCiwjqm/sSuhiSwGWeyTWpwKO7unCl+41WV7CA8EVkwUaMg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744184898; 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=Bve4yGyu1TEMucTKSXCLe+oUkHpkIsJ6geY6aVTZJOU=; b=AWtokODFPtxgp+r+4SU4rcMkwngcNDvxkRepCTml+SLJaUionrhJ40WXOmn3K/WpfGT6kB psGhuv8PeWCUrY9G62OJ87JK9peVFHjtqtjq2GXNyPdK3ilUedblbgqJTQ50FWHuvyQ0XZ qI+oGjU0Kh4MPHFVlCRHXcj8FX0Bbhuqdvf9sES41nkHDFhksQzPp+yGukeHllsBzT8yxx uchcwlLK/sEYffTjmEp5EvDgRoITpm/v/LMAtNMazS6IOzTODlvDmOudGZL2vuuq0uu8n0 ChUdjKeDZPhIs+OLNzYriAoaBfgIbIkBJp56CwAyM9bB685mLnB6W0czt/YZ4g== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXZnD5CwFz53k; Wed, 09 Apr 2025 07:48:16 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE" 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 \(3696.120.41.1.10\)) Subject: Re: pfil_default_to_drop Date: Wed, 9 Apr 2025 15:48:11 +0800 In-Reply-To: Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert To: Robert Austen References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 9, 2025, at 1:01 AM, Robert Austen = wrote: >=20 > I respectfully disagree. >=20 > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl = call to enable itself, ie. to apply any hooks. > if pfctl fails, then the hooks are left unhooked, and EVERYTHING = defaults to PASS, which is not what most people would intend using = PF_DEFAULT_TO_DROP. Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( = DIOCSTART ) or netlink command to enable it. @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? >=20 > consider this: until pf or ipf or ipfw makes an ioctl to hook = themselves, the pfil layer in the kernel has no idea what the filter = will be, > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect = (and likewise the equivalents from the other filters). As for ipfw(4), by default it enables filtering on load, unless you = disable it via loader tunable `net.inet.ip.fw.enable`, = `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`. The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable = `net.inet.ip.fw.default_to_accept` controls the default behavior to drop = or accept. See also = https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60e598498d= f6f9e2bd = . >=20 > as I said, this is because there's no mechanism within PFIL to drop by = default, which is why I proposed (and am using on my system) the = PFIL_DEFAULT_TO_DROP, > because it handles ALL of the 'no filter installed (yet)' cases. if = PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no = effect at all, > so it's a simple mechanism for those that want more than = PF_DEFAULT_TO_DROP can ever provide. It appears ipf(4) unconditionally enable filtering on load, and does not = have any tunables to control that. CC @Cy who is more familiar with = ipf(4). >=20 > thanks! > From: Zhenlei Huang > > Sent: April 7, 2025 7:55 PM > To: Robert Austen > > Cc: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = >; Kristof = Provost > > Subject: Re: pfil_default_to_drop > =20 > You don't often get email from zlei@freebsd.org = . Learn why this is important = =09 >=20 >=20 >> On Apr 8, 2025, at 6:36 AM, Robert Austen = > wrote: >>=20 >>=20 >>=20 >> From: Robert Austen > >> Sent: April 7, 2025 4:33 PM >> To: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = > >> Subject: Fw: pfil_default_to_drop >> =20 >>=20 >> From: Robert Austen >> Sent: April 7, 2025 4:21 PM >> To: freebsd-current@freebsd.org = > >> Subject: pfil_default_to_drop >> =20 >> Hello, >> I've been playing with FreeBSD and PF to build myself a new firewall, = as Open/FreeBSD + PF seems to be a common starting point. >>=20 >> I've noticed a number of people asking questions about = PF_DEFAULT_TO_DROP and the like, with the observations that it's hard >> to ensure that packets all default to drop if the rule file(s) for = whatever reason fail to load.=20 >=20 > Hi Robert, >=20 > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = pf.ko ( via the loader(8), /boot/loader.conf ) ? >=20 > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = ), you can turn the loader tunable net.pf.default_to_drop to 1, and = preload pf.ko. > See also = https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f991322680= 1f3073bd = . >=20 >>=20 >> After looking thru the online documentation, forums and scripts, I = came to the conclusion that it's not a PF problem or IPFW etc >> or really a problem with any of the filters or scripts, the problem = is at the level of PFIL, the kernel packet filtering code: If no >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends = everything thru to its destination. So my thought=20 >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version = of PF_DEFAULT_TO_DROP) that drops all the >> IPv4 and IPv6 packets that would otherwise go thru the = yet-to-be-loaded chosen filter (PF or whatever) at any given time the=20 >> hooks are unhooked.=20 >=20 > If no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your case. >=20 >>=20 >> [No one filters on local loopback nor the link layer, so I've left = those hooks untouched. I suppose one could add them, >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I = doubt there's much demand for it.] >>=20 >> Normally I'm an embedded linux kernel basher. >> I'm not entirely sure where to send this patch. Most of the threads = asking the above PF questions are closed to changes, >> so that doesn't seem a good place. Sir Dice seems to be a common = answerer of questions; I would have sent it to him/her=20 >> if I could... >>=20 >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"... >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of = @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, >> but I suspect the kernel code in the networking core doesn't change = much from platform to platform, or version to version. >>=20 >> But it works, it's pretty simple, pretty small and so just in case it = might be useful, I'm passing it along. >>=20 >> thanks! >>=20 >>=20 >> Robert >>=20 >>=20 >>=20 >>=20 >> --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willowglensystems.com> wrote:

I respectfully disagree.

PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its = ioctl call to enable itself, ie. to apply any hooks.
if pfctl fails, then = the hooks are left unhooked, and EVERYTHING defaults to PASS, which is = not what most people would intend using = PF_DEFAULT_TO_DROP.

Ahh, I see your problem. Yes, you're right. pf(4) = requires ioctl ( DIOCSTART ) or netlink command to enable = it.

@Kristof Maybe we also want a = loader tunable to enable pf(4) on load ?


consider this: until = pf or ipf or ipfw makes an ioctl to hook themselves, the pfil layer in = the kernel has no idea what the filter will be,
assuming there even is = one. thus PF_DEFAULT_TO_DROP  has zero effect (and likewise the = equivalents from the other filters).

As for ipfw(4), by default it enables filtering on = load, unless you disable it via loader tunable `net.inet.ip.fw.enable`, = `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`.

The compile = option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable = `net.inet.ip.fw.default_to_accept` controls the default behavior to drop = or accept.


as I said, this is = because there's no mechanism within PFIL to drop by default, which is = why I proposed (and am using on my system) the = PFIL_DEFAULT_TO_DROP,
because it handles ALL of the 'no filter = installed (yet)' cases. if PFIL_DEFAULT_TO_DROP isn't in the kernel = config file, my patches have no effect at all,
so it's a simple = mechanism for those that want more than PF_DEFAULT_TO_DROP can ever = provide.

It = appears ipf(4) unconditionally enable filtering on load, and does not = have any tunables to control that. CC @Cy who is more familiar with = ipf(4).


thanks!
From: Zhenlei Huang <zlei@FreeBSD.org>
Sent: April 7, 2025 7:55 PM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBSD.org>
Subject: Re: = pfil_default_to_drop
 
You don't often get email from zlei@freebsd.org. Learn why this is important


On Apr 8, 2025, at 6:36 AM, = Robert Austen <robert.austen@willowglensystems.com> wrote:



From: Robert Austen <robert.austen@willowglensystems.com>
Sent: April 7, 2025 4:33 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>
Subject: Fw: pfil_default_to_drop
 

From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD = and PF to build myself a new firewall, as Open/FreeBSD + PF seems to be = a common starting point.

I've noticed a number of people = asking questions about PF_DEFAULT_TO_DROP and the like, with the = observations that it's hard
to ensure that packets all default to drop if the rule file(s) = for whatever reason fail to load. 

Hi Robert,

So why not defining the = compile option PF_DEFAULT_TO_DROP, and preload pf.ko ( via the loader(8), /boot/loader.conf ) ?

With 13.5, or upcoming 14.3 ( you can also experiment = latest stable/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, = and preload pf.ko.
See = also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de= 4f9913226801f3073bd .


After looking thru the online documentation, forums = and scripts, I came to the conclusion that it's not a PF problem or IPFW = etc
or really a problem with any of the = filters or scripts, the problem is at the level of PFIL, the kernel = packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL = sends everything thru to its destination. So my = thought 
was to add an option = PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_DEFAULT_TO_DROP) = that drops all the
IPv4 and IPv6 packets that = would otherwise go thru the yet-to-be-loaded chosen filter (PF or = whatever) at any given time the 
hooks are  = unhooked. 

If no firewalls loaded, then the system = should behave as is. I do not think PFIL_DEFAULT_TO_DROP is the = right way to handle your case.


[No one filters on local loopback nor the link layer, = so I've left those hooks untouched. I suppose one could add = them,
maybe = PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.]

Normally I'm an embedded linux = kernel basher.
I'm not entirely sure where to send this patch. Most of the = threads asking the above PF questions are closed to changes,
so that doesn't seem a good = place. Sir Dice seems to be a common answerer of questions; I would have = sent it to him/her 
if I could...

I'm not a user of GIT, so I'm = not sure how to submit a "GIT formatted patch"...
I've simply diff -rdpNU 5 a copy of the @old folder = with a copy of @new folder. The code was written against = FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't = change much from platform to platform, or version to version.

But it works, it's pretty = simple, pretty small and so just in case it might be useful, I'm passing = it along.

thanks!


Robert




<FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip&g= t;


= --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE-- From nobody Wed Apr 9 10:17:14 2025 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 4ZXf595ndYz5srnk; Wed, 09 Apr 2025 10:17:17 +0000 (UTC) (envelope-from madpilot@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXf593phDz45Sy; Wed, 09 Apr 2025 10:17:17 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744193837; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=F0y52mw6PvNIVwhytfp5RRDdyqKgbY14pQ2zSV8ob0c=; b=skj72Pltyihp7edIxK4wpuzTw4Pbw77t7xAgUkMecswmj4mb1mYvZs2AToH+FkT7LsyK3V rRxthSWTq2P3OFuZROZthO6XN0cyFqWiAoEvK7C8Kclf5/bfrC4Dnan4z/ejApExBukMnK Eigt9jm144LhcvGOHvuTve77oP5wd/DIeWzvM52Y6IV8p38Fk1DKBkGmVPDzqjPbF6o1UO d6h3kwuzLAfIYmy5uOPY35VunCCT3tjy1cx9Ep8pYhVNrAkoXIhM5HMfYjkvGcZQvcH4rS gnuFl7E8O7PhgkEtntU7QzNOH4rMTmDtZ/iUnK0eCNP2zsWhK7ltLLimLe3WpA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744193837; a=rsa-sha256; cv=none; b=aCvUfdER8wBFlxc2x7stasQua9kq4/nGpAl2GhkENI0c+y8FdfORVjaAKDq3Izo5vCfOcG HUdpoajViNd3A0dIV+9al1SJzliAM5NuqY8Jdzj5dpuzoPlOHtTpniGlh8PPhCh9QqlL1a VJlIPE7St1TMVMX3u9Tu3blTVdi09jDFl+GFAmCGHfoxFsjPv0mekQg83koxSx22o/vK0Y vksUyuRZhpZ5MHD01JdE0ft7rOfFkxb05w4s8seQAlWBCylqTLmXmSjWkAhEH4RRBJz9Cb dHySacc1W/zI85L1fgOQx3Pu2F2+fbGe//kB1PnfbZJSmPPnju7+33gKyj2WcQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744193837; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=F0y52mw6PvNIVwhytfp5RRDdyqKgbY14pQ2zSV8ob0c=; b=tMo3GXufJ3K6/mt8bjlgIMqbYegwFc/ODgHAODXAKpI5v06cudkPeyeX+EAcB5kIaIAlas 8TtpcHXk9WHp5XLZZNnVLkTejtw7kCiT9+ffOZJ73IxJlbMOElN0j8obsvFeudMFF8HM7r 90uR0oGKetfLGL2kMXFaH98wafMz5SD4dJEhsJ4/mO1wg/ULJzxl+W+u8r67q9GoO8GG8d atpRLfggeyeMZe57q3JBJ2vONLnkIqJQN+RpvSfI8SIB8DotQzCoUJwk0XSyrIeL2mn4kK wI7ZmAZsRTVlwWUu31fiD5qfhO2omoAGmjDQhstRv6JuH6U1oAejgO/uLWAoTA== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (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) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXf5906xtz8KY; Wed, 09 Apr 2025 10:17:16 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> Date: Wed, 9 Apr 2025 12:17:14 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] To: Marek Zarychta , FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> Content-Language: en-US, it, en-GB From: Guido Falsi Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/6/25 23:38, Marek Zarychta wrote: > W dniu 6.04.2025 o 16:49, Guido Falsi pisze: >> Hi! >> >> I have recently implemented and tested the patch at [1], which >> implements RFC 7217, about generating IPv6 addresses that are constant >> through reboots, but do not expose the MAC address of the machine, not >> being in any way derived by those. >> >> I'd like to get comments, testing and review for this patch, with the >> objective of getting approval to commit it to head once it is >> streamlined enough. >> >> BTW I'd like to thank cognet for his suggestions and help with the >> patch, in particular his help in finding the correct way to implement >> the dad_failures counter. >> >> >> And thanks in advance to anyone willing to give feedback! >> >> >> [1] https://reviews.freebsd.org/D49681 >> > This is great news for the community ! > > I've already started testing it on both a desktop and a laptop - which > is probably even more valuable, especially since the laptop will be > connecting to various networks. If I encounter any issues, I will post > comments in the review. I posted an updated patch, addressing feedback and containing some more improvements. If testing this new patch, the flag needs to be activated per interface with ifconfig(8) now, or via tunable in loader.conf. Should generate the same addresses it was generating before, with the only exception of the (relatively improbable) case that the previous patch was generating a reserved IPv6 address, which is now checked for and another one generated in such a case. -- Guido Falsi From nobody Wed Apr 9 10:51:26 2025 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 4ZXfrm2rQDz5stYg; Wed, 09 Apr 2025 10:51:36 +0000 (UTC) (envelope-from SRS0=NHG6=W3=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4ZXfrm0k6xz3GQp; Wed, 09 Apr 2025 10:51:36 +0000 (UTC) (envelope-from SRS0=NHG6=W3=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmlive3.colo2.realworks.nl [10.2.52.23]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4ZXfrb2cDRz1M6; Wed, 9 Apr 2025 12:51:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1744195887; 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=h1UpUvlmWYJBK5VTD+Djh7eUoMlc/cieTmia4j9K1N0=; b=UhdBjXRxO5DC5p5mT7uwHoAVBLzH+SlKzhNbRXnzllEekMkCmcd4ydCDbTSb89QZveQNuQ LvQ61ribQPsbmFo7NgwiVDaaLfsJccGzLmaXdXF1K3CJn9v7tfgl/0C3nZ29X0v7qfrz2i nz7adFiqttoGIXe6+4OC0JuZI1cX4FFRLkmImE6opSCbfIvsBsLvjTp2dmanzR7JG2k9zv 9BHZn62oGcoijNCgYolU8iAAROinWrDBThhIGcSRLVKudYMUw8bgs6bRetyCaO6UhtPfKT SXUbn/Ml0PeXeIvc+031A/3qArBwUqUr6lCQ+NTz3rlQE46XLMoEMnWJsUMhcw== Received: from crmlive3.colo2.realworks.nl (localhost [127.0.0.1]) by crmlive3.colo2.realworks.nl (Postfix) with ESMTP id 453E52A0716; Wed, 9 Apr 2025 12:51:26 +0200 (CEST) Date: Wed, 9 Apr 2025 12:51:26 +0200 (CEST) From: Ronald Klop To: Guido Falsi Cc: Marek Zarychta , FreeBSD Current , net@FreeBSD.org Message-ID: <1699210246.52160.1744195886991@localhost> In-Reply-To: <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> Subject: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] 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_52159_965958018.1744195886988" X-Mailer: Realworks (744.6) X-Originating-Host: from (89-20-164-210.static.ef-service.nl [89.20.164.210]) by crmlive3 [10.2.52.23] with HTTP; Wed, 09 Apr 2025 12:51:26 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:137.0) Gecko/20100101 Firefox/137.0 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL] X-Rspamd-Queue-Id: 4ZXfrm0k6xz3GQp X-Spamd-Bar: ---- ------=_Part_52159_965958018.1744195886988 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Next to hostuuid you could add a jailname in the mix. That is what ether_gen_addr(9) does to make it easier to prevent collisions while copying jails around or run a jail on a readonly shared base filesystem. Regards, Ronald. Van: Guido Falsi Datum: woensdag, 9 april 2025 12:17 Aan: Marek Zarychta , FreeBSD Current , net@FreeBSD.org Onderwerp: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] > > On 4/6/25 23:38, Marek Zarychta wrote: > > W dniu 6.04.2025 o 16:49, Guido Falsi pisze: > >> Hi! > >> > >> I have recently implemented and tested the patch at [1], which >> implements RFC 7217, about generating IPv6 addresses that are constant >> through reboots, but do not expose the MAC address of the machine, not >> being in any way derived by those. > >> > >> I'd like to get comments, testing and review for this patch, with the >> objective of getting approval to commit it to head once it is >> streamlined enough. > >> > >> BTW I'd like to thank cognet for his suggestions and help with the >> patch, in particular his help in finding the correct way to implement >> the dad_failures counter. > >> > >> > >> And thanks in advance to anyone willing to give feedback! > >> > >> > >> [1] https://reviews.freebsd.org/D49681 > >> > > This is great news for the community ! > > > > I've already started testing it on both a desktop and a laptop - which > is probably even more valuable, especially since the laptop will be > connecting to various networks. If I encounter any issues, I will post > comments in the review. > > I posted an updated patch, addressing feedback and containing some more improvements. > > If testing this new patch, the flag needs to be activated per interface with ifconfig(8) now, or via tunable in loader.conf. > > Should generate the same addresses it was generating before, with the only exception of the (relatively improbable) case that the previous patch was generating a reserved IPv6 address, which is now checked for and another one generated in such a case. > > -- > Guido Falsi > > > > ------=_Part_52159_965958018.1744195886988 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Next to hostuuid you could add a jailname in the mix.

That is what ether_gen_addr(9) does to make it easier to prevent collisions while copying jails around or run a jail on a readonly shared base filesystem.

Regards,
Ronald.

 

Van: Guido Falsi <madpilot@FreeBSD.org>
Datum: woensdag, 9 april 2025 12:17
Aan: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>, FreeBSD Current <freebsd-current@freebsd.org>, net@FreeBSD.org
Onderwerp: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)]

On 4/6/25 23:38, Marek Zarychta wrote:
> W dniu 6.04.2025 o 16:49, Guido Falsi pisze:
>> Hi!
>>
>> I have recently implemented and tested the patch at [1], which >> implements RFC 7217, about generating IPv6 addresses that are constant >> through reboots, but do not expose the MAC address of the machine, not >> being in any way derived by those.
>>
>> I'd like to get comments, testing and review for this patch, with the >> objective of getting approval to commit it to head once it is >> streamlined enough.
>>
>> BTW I'd like to thank cognet for his suggestions and help with the >> patch, in particular his help in finding the correct way to implement >> the dad_failures counter.
>>
>>
>> And thanks in advance to anyone willing to give feedback!
>>
>>
>> [1] https://reviews.freebsd.org/D49681
>>
> This is great news for the community !
>
> I've already started testing it on both a desktop and a laptop - which > is probably even more valuable, especially since the laptop will be > connecting to various networks. If I encounter any issues, I will post > comments in the review.

I posted an updated patch, addressing feedback and containing some more improvements.

If testing this new patch, the flag needs to be activated per interface with ifconfig(8) now, or via tunable in loader.conf.

Should generate the same addresses it was generating before, with the only exception of the (relatively improbable) case that the previous patch was generating a reserved IPv6 address, which is now checked for and another one generated in such a case.

-- 
Guido Falsi <madpilot@FreeBSD.org>
 

  ------=_Part_52159_965958018.1744195886988-- From nobody Wed Apr 9 11:10:47 2025 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 4ZXgGy2TQTz5svRr; Wed, 09 Apr 2025 11:10:50 +0000 (UTC) (envelope-from madpilot@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXgGx6WdYz3NND; Wed, 09 Apr 2025 11:10:49 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744197049; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Q/t52UBMYqQH+uJC42Gh7+dlz+EODIHiSLLWTk9BW5Y=; b=d90svDCPakkfSK46N8FUs4h/45Q0f55bVcS72PpzCtM8leexBgKGXbibDavVO0OwtTjPId +tsq1W/vqAGAZPgNuZQvyOvYbHwf1W/WUMxS7KbHPh5ii6hCmyMJ+npnOc0aqaaK2fubIq TzqI6Igr8MuIrjjJPA/RzMoEOLCRSlRugUqKwlgGKA06L3o/nOSqL3lVz0xsbEBP0vKd8P n2oC4/mtw1sxg8mOjBojNJztZHR5XNSmMFc3flu30WGyIqV7j6UZalXc7tXOEdkmMlQaNy rYlA7DMxw73qc3sNWViWhVEo0lgmeAYF1tarxZnBRMA8NLGJbXIR0jWzlgnBIw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744197049; a=rsa-sha256; cv=none; b=tSypkZ0TA4IL8n+4LrQOdl7OE0N7NmbJDe8wixknivE12JRxsDjxXRBVApTX3KVSFiipxM lq5KtwJ2TFYQ14N2o7/VAa/CnXbf1YBufkClEu0yklGBjsuLdyBFOP3HSq+Ha2pJ2bUSve tbocpoDsx0ZIZOW7W1JO21hOUMv4/gYr9Y8gAD5lJQyBz/SXKCnW8zUYgrhyhta3D1UOC6 ej6xdJU7fV9Dxr9vTyHU5HVhjtmHF8CKPY3GbJXhCIHhvPFbJc05I6GmMkItShAm/K554D tBnS/NfPOVEcZ0fGdSh668mP84f9HtzAxGs27vYp+e0Q5uQbbA6L9sJKBMnaJw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744197049; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Q/t52UBMYqQH+uJC42Gh7+dlz+EODIHiSLLWTk9BW5Y=; b=ByofJQ5P3S2cpO9rmJmJW7HeA2fKhegDF1HuwEHhSHV9P9Kq9GZfEmiTClqGbcGGLEQNuE x/LkWWh+qOCQ6Ffh/9Car+E2IA7XbpIeeJB5Vvk2z/1x/6+n2GTuO5yNMMdjipiEk1ErpM IeLImf8lnc7B7ISO+h3cPLddQ4Asa2t12+a/bus0+tHsxINZi5ZVyGEgiw0XXD18JoKtFj yZoFlwI8aPr6smgPaHfnaM7lpI3+R0jRgpy0ZcCoCBUBihyZOAgr+riFTheLFja8JOffEL B4A8CxAdgUqQYlCUjogL5D8p2kmovUjgOwa7x0AjBuX4z0Qp+JbC0yx8V8+PJA== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (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) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXgGx20qBz969; Wed, 09 Apr 2025 11:10:49 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <6e3dd061-f377-4f20-bcd1-f1a5afeaa36f@FreeBSD.org> Date: Wed, 9 Apr 2025 13:10:47 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] To: Ronald Klop Cc: Marek Zarychta , FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> <1699210246.52160.1744195886991@localhost> Content-Language: en-US, it, en-GB From: Guido Falsi Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <1699210246.52160.1744195886991@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/9/25 12:51, Ronald Klop wrote: > Hi, > > Next to hostuuid you could add a jailname in the mix. > > That is what ether_gen_addr(9) does to make it easier to prevent > collisions while copying jails around or run a jail on a readonly shared > base filesystem. The RFC is very clear on what should be used to derive the address, so I'm not very keen on adding things around. The UUID should be changed when copying jails that run in parallel, they ARE different machines. although I am also at fault here. But the jailname is the correct parameter? This would change the address if the name is changed, which could be ok I guess. I'd also add this parameter only if actually jailed, skipping it for the host. My real issue with this approach is, the RFC is quite detailed on hash parameters. Will the implementation still be conforming if adding local ones? -- Guido Falsi From nobody Wed Apr 9 11:19:30 2025 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 4ZXgT16yFMz5svT5; Wed, 09 Apr 2025 11:19:33 +0000 (UTC) (envelope-from madpilot@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXgT160Q4z3RRm; Wed, 09 Apr 2025 11:19:33 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744197573; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=RLE4Mth0RyFPrADRLz+MQ8izEShd+xcxwv7hgwoR6RU=; b=p75GqcLfEEUXfIvmmadMgilvzuCUQmNXXZjraXbwgdYeWHU2VDEVHme3dBM3RthTW7q2k3 rWh+bU42fTePcLzWIKKrxQpRFUceZbVseH0Drf0aufsGtm5haLhdYm+3oV33RHFGs+xnTv 7sh/RgQEKWz5XfJEMXIgUp2R6ZVus8eVgXAndzzz4K2xgTkOXEDEPwxQDA5Me0YWbnBMLc FCTV6axKuWLg9/uRySP8c04y96eUNVWve5KvfwfDvxRqwW4QCkUj0D+dlhlOLhoezBxZWP twYGzpzij/X4PJeDm3/IoBQPv/751PacwizUwz7IG4FU4scTV6FN88MNdexPYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744197573; a=rsa-sha256; cv=none; b=KozEPYLl0wCrif2+xG0e1W8vXMEdK/T0cRwr3kmEsR4taCOQFaKwnsWkR5EcNyxD5KS+Jz IEkQn5jRAIArCOC9/kgrVVkjT74U/yJXqrKsyxwk81d1b/0qyimj/+Yw1ZLXsifzSfz0ZW slmAgVLRuFz7cNl1hTLCmhNG1puykm/z3rdBBIpTW9S3nT57aXIzWAwqUsAFI7I7KjSUxw GlV43d6faJPd1FGUNakoI9C396n3i+HSxtT0PnBMekl6mmBT8d20nPucRQkhEwyi7ySaL/ 9SnMnm+rCqVDbRcGQeUlq/dOVwt2CnATKcT45KQpSByIxQfd4tDO7w1FDCVEzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744197573; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=RLE4Mth0RyFPrADRLz+MQ8izEShd+xcxwv7hgwoR6RU=; b=RNGcl2BXWk0angfWV8LzoCWJNRqw8bnCAU0YNRhTgUqCdg4/MMPxIo2jpQ39205ZuvSAlb gXHMEkiGBUplrd71IUlM21rShoIvKlebtJo7ervKGtNfZZwFOhB7da1qYCU/CAjEdjCadt vBQBWv8mGNAQr0UaXUXhIZUIpTg8zsGtef+A2mREMopjYo7LmyYDTIr+jeWrlPvia7yEuH gca6wlx2IRjnqvbtOf9IgYDv2z+uQdlzYPPvTjQrgmXlwMtGugVtgUyCQffbGDBcCjZ89O 3W91k8Z4VgPHUUMBC7iHrLUFve1qGplhJpiNFCOxnVT5NB05v+IzOceHu9iwmA== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (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) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXgT11ksvz9Tb; Wed, 09 Apr 2025 11:19:33 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <0a6709f8-275c-4c18-b195-1333a44fd1a7@FreeBSD.org> Date: Wed, 9 Apr 2025 13:19:30 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] From: Guido Falsi To: Ronald Klop Cc: Marek Zarychta , FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> <1699210246.52160.1744195886991@localhost> <6e3dd061-f377-4f20-bcd1-f1a5afeaa36f@FreeBSD.org> Content-Language: en-US, it, en-GB Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <6e3dd061-f377-4f20-bcd1-f1a5afeaa36f@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/9/25 13:10, Guido Falsi wrote: > On 4/9/25 12:51, Ronald Klop wrote: >> Hi, >> >> Next to hostuuid you could add a jailname in the mix. >> >> That is what ether_gen_addr(9) does to make it easier to prevent >> collisions while copying jails around or run a jail on a readonly >> shared base filesystem. > > The RFC is very clear on what should be used to derive the address, so > I'm not very keen on adding things around. > > The UUID should be changed when copying jails that run in parallel, they > ARE different machines. although I am also at fault here. > > But the jailname is the correct parameter? This would change the address > if the name is changed, which could be ok I guess. > > I'd also add this parameter only if actually jailed, skipping it for the > host. > > My real issue with this approach is, the RFC is quite detailed on hash > parameters. Will the implementation still be conforming if adding local > ones? > > BTW, this is easy to add and also add conditionally on being jailed or not, I'd just like some consensus on this before adding, especially the RFC compliance issue. -- Guido Falsi From nobody Wed Apr 9 12:05:50 2025 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 4ZXhVp3sBZz5sxhN for ; Wed, 09 Apr 2025 12:06:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4ZXhVm3MLrz3hH2 for ; Wed, 09 Apr 2025 12:06:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jPcVdavt; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744200366; bh=0oYx/+729tpUprt/71Z4pJdmVFbCMUu74ayvb4FWNQA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jPcVdavtjE7M7/L2Yd5enynjIFzHmAJm2veRtslMopjD4CubW02W3Ngq1cO0iLOh+eExMNcoNPK8ZdOhDIEJ3/QvkPyhPGVX6zA4KOZIFNG6B5CW4j6UmVZ7+GzN9J0xWi9341Zeyfu9NjrI7z8BcPekLhzL8iWydTxsOHeJuWi86PyQkRvdgK2Gcn3/ZW3vaPURzB4MIESC1gzH/+ffAFDVwlKOjgePwhx0/wfZMmKomaXg2M4/tIWpWaua7LKP9DHbgHS80irvZelNyxeqUkEHyR7Z9Eywax3QpE3KSQSz5Cqc38Sog4eneCIVbJ+ErQSxt078ZnvC8q9AJ1qTfQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744200366; bh=JNjYPBsEAaWNVIn0hvqK2ekoWyEU2VMXcd3fUp654Lm=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OcebZDlyM4OXz+ZBempG78F0uTxvdP4HTCgiCWFOOmmmdg6HJAXeF793O5xi7Go9xFKwrFgD6sN5nDDpTQ0INqz6ncHCpsZyFO25nuAN5rm2OBWMPEY04NK98vHFWp10in2lmve2XfHVCQcl/+0pMhDyuqfBimKRE77TVoIkmYvVC/CXumkdpIOiVRaQ2G1WK16ELwR67PAoqrzlItj60kHJ7lMvuMeqgt09Jebpv54Mqj3qchuWZEfUMxxWgmStKzwMx7oBQAmsMDoJ2L3v1iTIly12v3Qi+dJLp6+N35HYStBJ89x+p5VORPDt0hlk4uIl30MZ7aOwbYCe/nPFfA== X-YMail-OSG: hW0ZWK4VM1mlSLgu7xo26SeEv1yXPUj898deMwJbKRaZla3qDQBOw4qXrDhzQLS b8jbDm28N6O44gIRZ3hBCF5ftDQdIsum5fVbA6sJ9TZIIk3pqjGkMjZf144atxhZqsC3AqeRAXTM llGXi7fgiyBkyxEJsr0WpH2ThPfCskRkelyupLIitaEz43cVEqflaf.Gogjg3Jhq3hb6aE2CLqcl W26ImZT3uL1W4U4KV8hE1OrNeVHQt14uA9Gp2xw_N5dpTXVxnrSKCAuoNAJSABIj4KqXYozCoqM4 8FiFbyDNmGZkQ7OaHyJHMtvTPzBk3joHeJEeY8rST7kGdTEvPhOk1.uj7wDWg7zvly736HsMAfDX umJHUyrnM_PU_4KwgvN1QJzHlwDNlxiyDVe3MKfh_bwJh_bq_cq87H4w7TUI3N5pTBAGncCgttlU DNxIdcHp.hOZgbQ6OdWtNuUHJJqN1jmR44OjY.b47jU.JDkwS3I55XYPLKiu.vzJ1VuuXhCtD7FQ Qax0fYmDwRdttT2dBJ.tQji_guG2epzBO2frmVbqWmxseNV_7Hmc3bGHz2OFdlEa31vAJD51wQfs VhbRb8ZUcSUUASchBR.PtuizDBHw7zJT4_VnXrxB3Am9BoYT519.j_EFKM6PBRruKzCeGplu.fIV 5EjcG4YSCYJNHcq_fTAbIsKwMMrriV58PLzr3NmltSDc2jCXUVKBhwBDb3s5XhHGFLd34y0MFmVU Dluc9NwTkFaL4EO2CF3ufcn_ZGh1GOPIX_vfM8tA62YG5kIdFdv0qKqnwotv1VQV9Lo3KiXLVkRO itVdyn_0wanH8u.iWj7TdEgtpyeq2CR0G_AoefXWPRIV8cnKqBZTO6fNFfGUD.N5ub_2BQoqpd6h 6SPm0C4yT8UL6vh5c8QgtmbjlhF4T0Fo0Ckgs8iJ6RVevUKG6CZ_m._Inl7i.I4iVRbg0VC8OaPm U_m6vmbireUGRy5QxH9UfXsXEnIK6DlDXxbaFKsEDUtvsqrNhc4Nax_NBejmackq0B7wxWp9CHMW OR74b8iq7jZb3g0kTWLRb0I79H4t6BcQKTVKRa5uYNFW7ySEmPVSPnwQtc..M86yNBnbhNwyEcfL vdkP3oqVuUZVWAB_6tQi4XXxCJCRXg_BTz50Dzeo7C8sQTr9I4g5J6n6sEzhutCWOH9w8mTPdnfF U.kDSq7XZtc0J6WE8qsluGjRmDjKavwyVjchax8crOb.f1NnN6bWrP7wJIMJxccSsS_TS0x2wfvY MjBuZFKIGqY0s1LChPVn5hsJvZDqbV6aJ65KB4QZFOyEcIYYBzfU9Pxkx9qjKEJvUin5g9IBTx9d _0dlcPbZwDSrkGREANmxAq4pYYwvRjrSqgse7TkUEgx3vVHfAq34IG3O.nXe_CE1mL6rpwQi4Sg9 oPb2BieY0RxhvNrkQDHV3fp6PCIAnYWs0yaavcQJuu22poIGhlKKrBD4lSSBd_P5kFF_clybCvqb wsJncAjz0qPm8k8LuIJ4PXm9oa6tLADy4nawxZpySnKh6f2ASwiDb9NouVwbPBwGzsXdNbIHlEmu 6XwGAYvO02xuHPsJ6KNggnVUKSEOZKOvulcoTFaScIVY8whiYqT_KZqCr2dEt7Ta1_U__Wlt77Jo H4OmTDLa4hMnCf2sGOiFXUTgH6LutWLWIJD3F2OC2q0QHIPop0w1fqnsmB3xAOEHZMM.gFDP8_SW 25YMbYfazbk9AGM29ETIkukmWlJiQvLdT0KJetLy5Y2AR9mh.21zXMp5ZLmlQcT6An3L2ZTZ_aoM tUoX9J7dFLBL3J4ugT.pwAnLddK_5_.IfYb1A74gsnKgfEnxV5J9hEbGySFiwg2GunB6TM3dXW29 8uWQtO4dFCNlRyVMLPQwKYka94lbPIcHeaOEomlNMxSJ8rnbkuZX8M0pQxpfXTCZPvX_yd87YRNI wo5C2d_IAMbK2uheeergoW86XZc1trt3q6fHYfsh41O7h4gSWSjN828XT0Pk_q6X2j_GJHJmMs9L omb5JsDZir73EC4yhWYHHuc84Ntt3FKu89K090YFHaJt.JUmHp9W53jwf3Gz8Hp8lZWWfv5se1ln 99F.6qeVGgYmS5jhoDUy9XYPcKllYWBIWTukagyK1TALm0_pJj4Iy2odizKxFmqJQTomGZh6qIXy wjny23Uo0VuxsEa1f8i9fouovcsRA1AQQ2P.wAtiaEjsf2JIrhLezPp3DTgBuhq7FIIkqHqGUkLc DDSIEC4DaGE58Yn6M3PDJzjvgaNQgvQ11bXOZKo2Lv2VT4kLscge1HkjUyRCZ X-Sonic-MF: X-Sonic-ID: 204cb6d2-ef76-4c03-b734-c87a308d0147 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Apr 2025 12:06:06 +0000 Received: by hermes--production-gq1-6f8bfcd964-rzxs5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4d05f575b321e0c6122e745339cb0bc2; Wed, 09 Apr 2025 12:06:01 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3826.500.181.1.5\)) Subject: =?utf-8?Q?Re=3A_VNASSERT_failed=3A_vp-=E2=80=BAv=5Fholdent_?= =?utf-8?Q?=E2=80=BA_0_not_true_at_/home/pkgbuild/worktrees/main/sys/kern/?= =?utf-8?Q?vfs=5Fsubr=2Ec=3A3391_=28vget=5Ffinish=5Fref=29_=5B2nd_example?= =?utf-8?Q?=2C_namei=28=29=2E=2Evget=5Ffinish=5Fref=28=29_is_common=5D?= Date: Wed, 9 Apr 2025 05:05:50 -0700 References: <267C2D6F-5E2C-4482-9CDE-7EF6522EAF29@yahoo.com> To: FreeBSD Current In-Reply-To: <267C2D6F-5E2C-4482-9CDE-7EF6522EAF29@yahoo.com> Message-Id: <87EF0A66-14B8-4978-B48F-F4DE8EE115C9@yahoo.com> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.42 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.82:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from] X-Rspamd-Queue-Id: 4ZXhVm3MLrz3hH2 X-Spamd-Bar: ---- On Apr 6, 2025, at 19:29, Mark Millard wrote: > [Somewhat hand corrected "OCR" conversion of some console image = content.] >=20 > VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) > 0xffffa006e11e6a50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 > usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 > hold count flags () > flags () > lock type ufs: SHARED (count 1) > vp=3D0xffffa006e11e6a50, lowervp=3D0xffffa004b074adc0 > panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) > cpuid =3D 8 > time =3D 1743988125 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x38 > vpanic() at vpanic+0x1a0 > panic() at panic+0x48 > vget_finish_ref() at vget_finish_ref+0x1a4 > null_hashget() at null_hashget+0xe4 > null_nodeget() at null_nodeget+0x34 > null_lookup() at null_lookup+0x118 > vfs_lookup() at vfs_lookup+0x3e0 > namei() at namei+0x298 > vn_open_cred() at vn_open_cred+0x450 > openatfp() at openatfp+0x238 > do_el0_sync() at do_el0_sync+0x608 > handle_el0_sync() at handle_el0_sync+0x4c > --- exception, esr 0x56000000 > KDB: enter: panic > [ thread pid 8113 tid 163110 ] > stopped at > kdb_enter+0x48: str xzr, [x19, #2048] > db>=20 >=20 > An issue may be that I'd not yet updated the world yet after > updating and booting the kernel (but no ipfw usage involved): >=20 > # uname -apKU > FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 1500034 >=20 > (That kernel is from installing an official PkgBase set of > kernels, not a personal build.) >=20 > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH > release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 > . . . >=20 > The FreeBSD context is Apple Silicon M4 MAX under Parallels > on macOS. FreeBSD had been doing a poudriere-devel based bulk > build. >=20 >=20 > I've no known way to reproduce the panic on demand. >=20 >=20 > Core dumps under Parallels always seem to have backtraces > that are like: >=20 > #0 0xffff0000004b9e48 in doadump (textdump=3D0) > at /home/pkgbuild/worktrees/main/sys/kern/kern_shutdown.c:404 > #1 0x6fa60000000e9d98 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >=20 > and the rest of the cores are like: >=20 > #0 0xffff0000008703b0 in ipi_stop (dummy=3D) > at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342 > #1 0xd2e9000000866b68 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt = stack?) Again during a poudriere bulk run: VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) 0xffffa001e559fa50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cd80f0 usecount 3, writecount 0, refcount 1 seqc users 0 mountedhere 0 hold count flags () flags () v_object 0xffffa00875bbe210 ref 0 pages 1 cleanbuf 0 dirtybuf 0 lock type ufs: SHARED (count 2) vp=3D0xffffa001e559fa50, lowervp=3D0xffffa0031f0b2a50 panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) cpuid =3D 2 time =3D 1744180482 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x38 vpanic() at vpanic+0x1a0 panic() at panic+0x48 vget_finish_ref() at vget_finish_ref+0x1a4 null_hashget() at null_hashget+0xe4 null_nodeget() at null_nodeget+0x34 null_lookup() at null_lookup+0x118 vfs_lookup() at vfs_lookup+0x3e0 namei() at namei+0x298 sys___realpathat() at sys___realpathat+0xb0 do_el0_sync() at do_el0_sync+0x608 handle_el0_sync() at handle_el0_sync+0x4c --- exception, esr 0x56000000 KDB: enter: panic Here: namei() at namei+0x298 sys___realpathat() at sys___realpathat+0xb0 do_el0_sync() at do_el0_sync+0x608 Previously:=20 namei() at namei+0x298 vn_open_cred() at vn_open_cred+0x450 openatfp() at openatfp+0x238 do_el0_sync() at do_el0_sync+0x608 So it looks like what is common is: namei()..vget_finish_ref() vget_finish_ref() at vget_finish_ref+0x1a4 null_hashget() at null_hashget+0xe4 null_nodeget() at null_nodeget+0x34 null_lookup() at null_lookup+0x118 vfs_lookup() at vfs_lookup+0x3e0 namei() at namei+0x298 This one had a v_object output line, the prior one did not. Some counts vary. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 9 13:41:11 2025 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 4ZXkcp0mstz5t3k9 for ; Wed, 09 Apr 2025 13:41:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (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 4ZXkcm0vdkz48rR for ; Wed, 09 Apr 2025 13:41:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jsM7pknI; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744206086; bh=e7rJRwIkbSAr+yZ0yQqZyjiWJ4rASgov93Lm86kPWGs=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jsM7pknIl5vknXyPUGfZM3Sd3ZHTU8+z4fQIiXUvV+GIO8fQrhzRRdGrSplbVM4vrgFsTK/bflG7jOjQ8KnZz9yyigBrJHva1/7zExWQlKHwxyi9HDKhBGqKd69cOPXGMk/qpTDZV72WLcijjD+C2kQxduNXFXK6gqcC2vmvHrUGFXcgXC9QfqOu7eqyAqQgfNJnv6vcsab12gkciexzOecoalIFos81xQMUUXb0KPlUaFt89FT3tGv2vggw0Xw+BX+hBbMASIqB2VcG+j+5194jaZjhQFtRYk4t3nLXg5qJPt3f374w2vHdX0BLkUlbSPWcEtoKZBzSjlhxvSriTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744206086; bh=1wmHRC8QJUJpUFD0kVGB6e3MwN3QT4YWVBhAorlw8RH=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=pbiaqWb5k55zRmhHoWby6KKVXSWlraZozUAIslDC7yMaeuZL5LUaM6yWeHr5qfrP0KoxNVFJ/Y4UWjS09TTWtQobUBnMbniH1tbMTWdyioe7JbIebh7p7uceu4cb2oVafu15xJFGxeY4lY77U9urGlE7tTMKo3obHtJGxz/aw7zLNp7MJaRU2WtX5qbm83WC37d6cpSwzddI6HQnsVF0dhiZFWxhXLuNPCEnJjVoK6xefhs71Sy4lYtvVGoPaeNAYJvXk94g/TY6MPupLPmlBJCabWINeWNpHSgeZxG773I/tJOP4SWKCdHr7sTx5uZO2EYHT15HyJ661UqdNJGFjQ== X-YMail-OSG: 95i0DCAVM1kQp.wElkIm_0mXl3R76vtTaIwdOvt6pe3GjuvCzWzoDIOrGUfufZq 8Kr_9OhyJemrLBnEI05TnTn_xRCYwMQ7GSIo4SknmcdhgvCQxj.sBPkVFM7.voBcGzz93q7YfhHn bvxqEwLW2hETH8IjUSUtmucdPQRtBX009NA1.dzMLe_BP_izx3qHBvmGXxuJExOXGELxgiXvGkzf eDb22Gyj3FxLkzKQCaqRTXX99dXLVlXInhrVKtAyJuMR0Vhvn816br6hWQuwLlEFg8e2Djuldu4O 5Tja4QYIziuRy.zckAlzhGDyIvyhS17eGweWKqy2QtMkSd.CoZuOF7WsNhk1_Ajf2FIpSrnk3.uj 9DV2gRnFu1jYgt48HeQVu18_wVL_fieBTEQ34vLqv4iC4VYjpncjiwUyGgvB0RGFKoVcZI5maDv3 tGWJyN7n38Yc4r0hZu8rFVXWbj1Kjxn_TKtVyP7gZQrq2WJwDeDXV.7BLXCwQ9K96uAJvCxwcTAd wuZYvOLIe_rxASQnrC4UNStGIrwRQ4vutc9leMSG9ZahDRxb_ThMNwMvzf1dL3QUljdD1cbef_Ml KVuP090tmDj7MN4gc_JirU5k4OjNEumrHWvAELMbios4AUJWdvm4aH55UFtu.YM.dcpl.4Kp5Xp9 eWSCovjgf_TnsV8OfM17W6bAVarA7ppvHTitX6OluMXF56qJzaqVhhW58agcnkNTMtlknC32r5di zY16B543ct.fVR32KOt6r4SgLRw3tcYH9fZH3u7ISH7rAAwtwWXo3eUTwx6oiYg9h8DqEAjyY54n 5J5cJJkipp_ik3xspVWR.Ng6gBe9IVClJzkWiMS1zlrK2XmdHxgGdKYbkidBBudgtYZgnW06TApr DvhM3baAPKFkvf038vzy5K8gbjXvm76h1KUXMjlETA_s9AybB.qoHdnkmStjXYtVXfGWBivlcKJU uMgiM7_Cxv5bkgIPiZAbPdbsbuDZmoWmBqoLryrtzP.NlpBZJ_H1J3XIUrGRPI6NqVi.TZ0X0GIV pvqomM8Rd8JfPErlVmkLWv6.1OxNYh1iGC6NOSRMrOx4cy53AiiXj9zJMm1kMerY7EjcGbWd9AWN oEY914.PJxR5.Shvw4g8iWMJLcQpPrIcvc21EJ3dikz.TfaLhutRC7GEwIiiufwxZ9F4NZvMJolE OVW0Q09cCNM9O8dAGZodCiYTtaOOWd5v11rvbxHgeVzp.00SqaKWkJX.E_TX0VIX4tc4NyhZNrzx bp63i96RZVuyss1UZc8SJY633Tm.h_Z4SYgELOYmIQhOodStcuNNuhLqrUd4PqyEzxuG7FRe1gHs 6YAKk3KtO9awXD8vYOchO1L9U4zR54heRx2bOu_VZVXR4ks4KiZQV74LNaHAsS..CpH1ECYlUrfB wOJIsNw7ksQUjkcx.V.CdzzXdEkGUyRo0fQb5h0pVsQqowqc5F0IPYC6kisJhUTceRtMA31ba6cS yPH3TFziAdBRO2H4qS_RMXIqRkToWq0jsVbvcEm5ol05TbeVz3tkcOPL9UjneQvjic39DevzOgeM 2n5Ty0d2bLNctyswfGJXH2VMLPWfMhAmcCrGM8MbZjD7xZipTXcoJo5Oq2YEpO5lvvJrVhF_CFT9 4qIu10G.zCRnVdkuF5eN0Ezu8yzURej5gZ.pzKYMUOvipV2NI8BBHGgptcW0NcFZlYdZ1H5Fp18n sIBkwR9DPIEqXdBZCmifGsbL.aokDalbDZlMPwr9w4nDeL35rzwrOqBtc2s4oXBrTl6C3Scm9PIr KHjiPn2jH9co.hotFN.DJwVm9agsQL34MBeEErr7__v07S2uNIELgqja1F9MjZoAveX2xKp7J02T 7z28NIuziQ_JfI13gjH2ab41js6tyAifPEDUHbf_Q08JMCNFgfXKfym.PEQuU6gAFPWoORqiDWur bsrvT5AcQG2NGZyN1xjpaFEXWz_jHmQBNbTaPTXXZMWi85h1waXMncAlgfNzAE_opCGcdTqq.Z37 DJIhZNP7MSr3ElHM3xF4x.ga.gFLgK2x875l2gEUm2VNy9mxXN2v1akCE8y4P3815B5uE_KLxzVk 8rhpHsGrqxdQrLFIDToIO5x2cHifTxoz96CK90sS5cenm3GFzhf.Bdi8.WTZiuIhomi42QD5AAgI mV49Dx6lxV1cvNH55l_a4WZeMkqmluqvu0X2LQSlLF7UOK2Pqnyox7fFt12V2yRoKmqzuSi0OuYj hjatE1WX9 X-Sonic-MF: X-Sonic-ID: 3da9a219-fa33-4731-a6e9-05e10bb18ac4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Apr 2025 13:41:26 +0000 Received: by hermes--production-gq1-6f8bfcd964-6qnmt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ab06bdfa62d34237e1d1417fc555f98b; Wed, 09 Apr 2025 13:41:22 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3826.500.181.1.5\)) Subject: =?utf-8?Q?Re=3A_VNASSERT_failed=3A_vp-=E2=80=BAv=5Fholdent_?= =?utf-8?Q?=E2=80=BA_0_not_true_at_/home/pkgbuild/worktrees/main/sys/kern/?= =?utf-8?Q?vfs=5Fsubr=2Ec=3A3391_=28vget=5Ffinish=5Fref=29_=5B3rd_example?= =?utf-8?Q?=2C_namei=28=29=2E=2Evget=5Ffinish=5Fref=28=29_is_common=5D?= Date: Wed, 9 Apr 2025 06:41:11 -0700 References: <267C2D6F-5E2C-4482-9CDE-7EF6522EAF29@yahoo.com> <87EF0A66-14B8-4978-B48F-F4DE8EE115C9@yahoo.com> To: FreeBSD Current In-Reply-To: <87EF0A66-14B8-4978-B48F-F4DE8EE115C9@yahoo.com> Message-Id: <4DFF9B48-90EA-47DE-8A91-59C1AB30F3C9@yahoo.com> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-3.65 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.147:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.93)[-0.932]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.22)[-0.220]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from] X-Rspamd-Queue-Id: 4ZXkcm0vdkz48rR X-Spamd-Bar: --- On Apr 9, 2025, at 05:05, Mark Millard wrote: > On Apr 6, 2025, at 19:29, Mark Millard wrote: >=20 >> [Somewhat hand corrected "OCR" conversion of some console image = content.] >>=20 >> VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> 0xffffa006e11e6a50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 >> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 >> hold count flags () >> flags () >> lock type ufs: SHARED (count 1) >> vp=3D0xffffa006e11e6a50, lowervp=3D0xffffa004b074adc0 >> panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> cpuid =3D 8 >> time =3D 1743988125 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >> vpanic() at vpanic+0x1a0 >> panic() at panic+0x48 >> vget_finish_ref() at vget_finish_ref+0x1a4 >> null_hashget() at null_hashget+0xe4 >> null_nodeget() at null_nodeget+0x34 >> null_lookup() at null_lookup+0x118 >> vfs_lookup() at vfs_lookup+0x3e0 >> namei() at namei+0x298 >> vn_open_cred() at vn_open_cred+0x450 >> openatfp() at openatfp+0x238 >> do_el0_sync() at do_el0_sync+0x608 >> handle_el0_sync() at handle_el0_sync+0x4c >> --- exception, esr 0x56000000 >> KDB: enter: panic >> [ thread pid 8113 tid 163110 ] >> stopped at >> kdb_enter+0x48: str xzr, [x19, #2048] >> db>=20 >>=20 >> An issue may be that I'd not yet updated the world yet after >> updating and booting the kernel (but no ipfw usage involved): >>=20 >> # uname -apKU >> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 1500034 >>=20 >> (That kernel is from installing an official PkgBase set of >> kernels, not a personal build.) >>=20 >> # poudriere jail -l >> JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH >> release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 >> . . . >>=20 >> The FreeBSD context is Apple Silicon M4 MAX under Parallels >> on macOS. FreeBSD had been doing a poudriere-devel based bulk >> build. >>=20 >>=20 >> I've no known way to reproduce the panic on demand. >>=20 >>=20 >> Core dumps under Parallels always seem to have backtraces >> that are like: >>=20 >> #0 0xffff0000004b9e48 in doadump (textdump=3D0) >> at /home/pkgbuild/worktrees/main/sys/kern/kern_shutdown.c:404 >> #1 0x6fa60000000e9d98 in ?? () >> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >>=20 >> and the rest of the cores are like: >>=20 >> #0 0xffff0000008703b0 in ipi_stop (dummy=3D) >> at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342 >> #1 0xd2e9000000866b68 in ?? () >> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >=20 > Again during a poudriere bulk run: >=20 > VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) > 0xffffa001e559fa50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cd80f0 > usecount 3, writecount 0, refcount 1 seqc users 0 mountedhere 0 > hold count flags () > flags () > v_object 0xffffa00875bbe210 ref 0 pages 1 cleanbuf 0 dirtybuf 0 > lock type ufs: SHARED (count 2) > vp=3D0xffffa001e559fa50, lowervp=3D0xffffa0031f0b2a50 > panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) > cpuid =3D 2 > time =3D 1744180482 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x38 > vpanic() at vpanic+0x1a0 > panic() at panic+0x48 > vget_finish_ref() at vget_finish_ref+0x1a4 > null_hashget() at null_hashget+0xe4 > null_nodeget() at null_nodeget+0x34 > null_lookup() at null_lookup+0x118 > vfs_lookup() at vfs_lookup+0x3e0 > namei() at namei+0x298 > sys___realpathat() at sys___realpathat+0xb0 > do_el0_sync() at do_el0_sync+0x608 > handle_el0_sync() at handle_el0_sync+0x4c > --- exception, esr 0x56000000 > KDB: enter: panic >=20 > Here: > namei() at namei+0x298 > sys___realpathat() at sys___realpathat+0xb0 > do_el0_sync() at do_el0_sync+0x608 >=20 > Previously:=20 > namei() at namei+0x298 > vn_open_cred() at vn_open_cred+0x450 > openatfp() at openatfp+0x238 > do_el0_sync() at do_el0_sync+0x608 >=20 > So it looks like what is common is: namei()..vget_finish_ref() >=20 > vget_finish_ref() at vget_finish_ref+0x1a4 > null_hashget() at null_hashget+0xe4 > null_nodeget() at null_nodeget+0x34 > null_lookup() at null_lookup+0x118 > vfs_lookup() at vfs_lookup+0x3e0 > namei() at namei+0x298 >=20 > This one had a v_object output line, the prior one did not. > Some counts vary. VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) 0xffffa00a2a17ec08: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 hold count flags () flags () v_object 0xffffa00a40b73000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type ufs: SHARED (count 2) vp=3D0xffffa00a2a17ec08, lowervp=3D0xffffa00a2a21f6e0 panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) cpuid =3D 7 time =3D 1744203937 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x38 vpanic() at vpanic+0x1a0 panic() at panic+0x48 vget_finish_ref() at vget_finish_ref+0x1a4 null_hashget() at null_hashget+0xe4 null_nodeget() at null_nodeget+0x34 null_lookup() at null_lookup+0x118 vfs_lookup() at vfs_lookup+0x3e0 namei() at namei+0x298 kern_statat() at kern_statat+0xf4 sys_fstatat() at sys_fstatat+0x2c do_el0_sync() at do_el0_sync+0x608 handle_el0_sync() at handle_el0_sync+0x4c --- exception, esr 0x56000000 KDB: enter: panic Here: namei() at namei+0x298 kern_statat() at kern_statat+0xf4 sys_fstatat() at sys_fstatat+0x2c do_el0_sync() at do_el0_sync+0x608 The *statat() are distinct from the prior examples. Again the common part is: vget_finish_ref() at vget_finish_ref+0x1a4 null_hashget() at null_hashget+0xe4 null_nodeget() at null_nodeget+0x34 null_lookup() at null_lookup+0x118 vfs_lookup() at vfs_lookup+0x3e0 namei() at namei+0x298 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 9 14:38:12 2025 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 4ZXltc2LpQz5rtHg for ; Wed, 09 Apr 2025 14:38:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4ZXltZ1jxPz3Kvp for ; Wed, 09 Apr 2025 14:38:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="ldeG/Pd3"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744209508; bh=LqieShcJGtP3aEanaB0PWCpFtQBxKRzHDsf+4+cmp5k=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=ldeG/Pd38LqxcTm3aOISMbKO3lTt5I6OrZ29oxKLngPcJ3AoGRowB8/akMdiP+rL/mbySwESYr+/WOWYRgzo0OSkM4O2UeNBL8bqsCfOw4BkZomO6BTU3GcK8PEoX11HKfsdbneoSQfwD+deBHaSWGghRT87pleagQtQGbLKCrlfGB4An6JM8Djoa1qtJrNt1mE2sDaJiKE5ssUJeZkk5npbfvzWotUCIQ32fXx2/i7BGqUY7n5JAelLsRTkKbyyJqFDoyCkWRZv6fKpbK+TgssCHXt1eCoXjHOU4zJKHURQXCk4ePqQMtTbBTZ5t9cGPYR1nr/22bNm7UffOoMQjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744209508; bh=2M9nMAdCb1jMIo8GqBjHQNH/olm2KqQQwhvGdB/kZOh=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ppsixkBXmxYoen7S8rl+I7JAKC8Oyt/sit+bRT5ryj6dtpMLlgeGQ4x+VYIfWpBVLTNMpZ7mYc4FnHE8JHI13GVIyeIEh9bVUI5MZ9L5tH14dhdCG7047uCu02YEc9IqFRjQhbhAZuv9lUYTkkaBQbU5SIjt+JxoWCqoNiG4NJDzOdyRSn0I+eCJejzEvW+Zct7qboyZdYuEMsTRigkEhUNNda5z+kOfNmaPowkTn1GaLOfXPRPFSyFCg8iOCujTFXRVOtAaXhvjjAclUF+mnvf8nE/3iVPy5+f5dSYjOGsTZgEm9xnwDquDz1ax3Rp7c8hHauun1pgVDQTKd8NdeQ== X-YMail-OSG: 8YQXEa4VM1murxK36udmgv1k0hX3Kbi2IE6mkbA_RP3lA92JHbZSpZZPgw3J6GY JwEokb26kEEYEarGH20ZPcJsuIc1bo44O9KmysudYrl8swnSlz90NCYHeVKHdM6KSIU6qHBpoc_c 95PZM1DzBmO6ysnDOiWUXFOYwJp4Jv29bw_A9VU8tlOBttn_vhqzrpWBXbdVVtiH0fY.Zkaqfqdu z78MPa148J45Erk4bCJLjowxp07bsHNMExdPS9zK0.Z94ahReRlPTmZghmNuhHsxrVamqphsL0fK 5EW5pLjWGTkV2wSX_3vQw_4ngh6hqlqYVXYvuOchUklWJ5kLTfQE59PV90Ewk7XuX8MKSToMPuo2 LYmdaHJa4t.PBbUVeEclp.YPD7Jb11CMBenHZyNNUck.VpFbSA.DJc.3MMm7uy6oUul6OBG_ZH2z 3pXcMDE_KFAea97nS0aF6bXCJOp3yGa3TJPU7q.g1NARXHsgQh_DFGctGJOGUENek8G_2dLrXEBX OMZE0YSNhdKwq4CDi0ZJkZAZX6UkEX8f6jyVj3lQYz3.speKvYE_70o_e0f7nnOjrJ96zg.X83rZ mHi99JTj4aKfq1C8FZLfBohmHWGOw2MhTyjBGRwg.3K06hDfafhNu8aU148JjyvQi3bEcGGY_orP mAbsDGJ67QEPmQYYYWbASQh99yyrg2l0rAKq2tNlZYwOJMjwblCJYld27W5DvqXbg7uBwNZO.sG1 Fo3qggBILVkLxMupgPXJjxzXkZ274uOrZO3HHCz.lMjm3xJdWvf316KfbjO45LWgwiyCjP3cB2xW AiAy3ZGAG57J_wJVyaENDVP4yXt6wfRJiUB4Na7oe1V6p45SkvHVuaypAAdNal1aJrpw76qdvHTI s48VHkYCm5P1zb8Ds7uot.9qqRVDJDjzqN1nJrelGOKX0QsXVhaHawXv2vitPDUUWEdlCjaQRE9V BKlju12oXNYXIc8qOoDf9ZSE3T3NMYXQFd9.YuVqDcQj3ESIPN3DpCVXeWMAN1ZUJ5vcQpbhzEC9 WaqHMVqW1R_iRdxnxF2KJ0hkK8Nw509KuMSOE8qASBluUOGqTKCxigv3Y6LtyWdBli3H9kllV4MG QVgK.OJepTmh_AwuUpHCmkpBQcPObiAoIUSu9NTCVBOOJtWZofSPM.zYe0LHkzUucfM8skvDeMq5 xCz8i1ME.8YWm.IAW2WGNw8HMcZYgUoEAQaJbtUbYI7shZaJlNGVMZSLI4HgMBMEK3dkjTWXJPTW ujZLV9t5CVN72zN28lilwvnjU7iyBi36GB1KNcw95KZzXrk_1j50BiJpm0NVZn1CaJ0YYrRGNK_l 7SaRqZWaVE8t4VkO4DNHt67yaWwCHc8S_0HPwc2g1xwq.bHXCEgfFlvIvMjL7HUBspUGJee3v0pX YcwHCgCxdhN_p2MK.bYoh2pJT8ZqBdqsda1uv3iBFVL3Ifn0psgl.9rkz5sVlZvAW8VvyYSB7w2A ws46NUgIADhiJmgLVC8GDi1rKY0URlv8ieTFX9UQqxe4v7W8cbaynLQzpIog2O3QDVCxf4xqNmGe pnatjaDgzbMq4wvV6Q0xhH3Kuo5rQ8VFmABu.3I.JVfLxXfGRkDzXwK4pvpVJJmU3DsRd9S54cNB Hwr7BfG8Vj9AOWA0nwE.NA0QWHZ0MVQXgVsrZmbKRCG3yiKDVGdE1EHQmsO9dKBCLwBQ9sRgZTIY bByDLqtc4A8A0dSMkzuvBQeCSzV1OFanyP7X6dmqGTUrCYOj66KWc3eoNnVEXEns5JFgc3sBlEQ8 eSdlShx.IrMFpeTxqi78i8kPNk4WlkPEL1RWAYiIQHDb88m9jpTC98Ud7Bh9aC.LcPYS_WtZIWmN LiHd7RWxmKf4CDaBtkH2892vGqi.dAZWdVWno4ffeiV3uLLZM8f3mkUrLojgHJ0aDBED.W5rjZbt 4s_iSYb2futB.1f8qk3d0bsOQUYMWlKR0fspRnAkL57Fyt3ug7t9QOkuQN0pujb6GvHv13wvaSu7 kMgQlrauUlZ70.9EWvRVsat_sy9foXpSlCnhpQKnWUEr7HPSPZ4GiMa4Kcxjvm2JxBVcedGPzP48 SLIN1doHWSRNC0PrM93Hal1Pk9s3g3Cic.pYBVwdGyKApP0MV5EOo2xsuE2UDuTbCPyg08F5_3HT Cza78eKwjLhwQ1gPcuJ_o36eAGVoKmFC5q8cGMdaFmy9CFzts24zOcAcfZEUbzJMScOjKAzgneYz _nMmf36cxaWCTwCb.GCj4LxYLWD3ABVZvdH8PY2wdg3StvwpRnEWZydIV6g08qnWc X-Sonic-MF: X-Sonic-ID: 80ded54a-6af7-4141-bd4b-584756195b17 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Apr 2025 14:38:28 +0000 Received: by hermes--production-gq1-6f8bfcd964-558ll (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 276f7c24e7561dfd68c4c4c9ab31ae3c; Wed, 09 Apr 2025 14:38:23 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3826.500.181.1.5\)) Subject: =?utf-8?Q?Re=3A_VNASSERT_failed=3A_vp-=E2=80=BAv=5Fholdent_?= =?utf-8?Q?=E2=80=BA_0_not_true_at_/home/pkgbuild/worktrees/main/sys/kern/?= =?utf-8?Q?vfs=5Fsubr=2Ec=3A3391_=28vget=5Ffinish=5Fref=29_=5B4th_example?= =?utf-8?Q?=2C_namei=28=29=2E=2Evget=5Ffinish=5Fref=28=29_is_common=5D?= Date: Wed, 9 Apr 2025 07:38:12 -0700 References: <267C2D6F-5E2C-4482-9CDE-7EF6522EAF29@yahoo.com> <87EF0A66-14B8-4978-B48F-F4DE8EE115C9@yahoo.com> <4DFF9B48-90EA-47DE-8A91-59C1AB30F3C9@yahoo.com> To: FreeBSD Current In-Reply-To: <4DFF9B48-90EA-47DE-8A91-59C1AB30F3C9@yahoo.com> Message-Id: <19A813BA-A9EF-4336-B2C9-E6B4C12178F1@yahoo.com> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.43 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.68.83:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.93)[-0.930]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from] X-Rspamd-Queue-Id: 4ZXltZ1jxPz3Kvp X-Spamd-Bar: ---- On Apr 9, 2025, at 06:41, Mark Millard wrote: > On Apr 9, 2025, at 05:05, Mark Millard wrote: >=20 >> On Apr 6, 2025, at 19:29, Mark Millard wrote: >>=20 >>> [Somewhat hand corrected "OCR" conversion of some console image = content.] >>>=20 >>> VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>> 0xffffa006e11e6a50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 >>> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 >>> hold count flags () >>> flags () >>> lock type ufs: SHARED (count 1) >>> vp=3D0xffffa006e11e6a50, lowervp=3D0xffffa004b074adc0 >>> panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>> cpuid =3D 8 >>> time =3D 1743988125 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >>> vpanic() at vpanic+0x1a0 >>> panic() at panic+0x48 >>> vget_finish_ref() at vget_finish_ref+0x1a4 >>> null_hashget() at null_hashget+0xe4 >>> null_nodeget() at null_nodeget+0x34 >>> null_lookup() at null_lookup+0x118 >>> vfs_lookup() at vfs_lookup+0x3e0 >>> namei() at namei+0x298 >>> vn_open_cred() at vn_open_cred+0x450 >>> openatfp() at openatfp+0x238 >>> do_el0_sync() at do_el0_sync+0x608 >>> handle_el0_sync() at handle_el0_sync+0x4c >>> --- exception, esr 0x56000000 >>> KDB: enter: panic >>> [ thread pid 8113 tid 163110 ] >>> stopped at >>> kdb_enter+0x48: str xzr, [x19, #2048] >>> db>=20 >>>=20 >>> An issue may be that I'd not yet updated the world yet after >>> updating and booting the kernel (but no ipfw usage involved): >>>=20 >>> # uname -apKU >>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 1500034 >>>=20 >>> (That kernel is from installing an official PkgBase set of >>> kernels, not a personal build.) >>>=20 >>> # poudriere jail -l >>> JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH >>> release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 >>> . . . >>>=20 >>> The FreeBSD context is Apple Silicon M4 MAX under Parallels >>> on macOS. FreeBSD had been doing a poudriere-devel based bulk >>> build. >>>=20 >>>=20 >>> I've no known way to reproduce the panic on demand. >>>=20 >>>=20 >>> Core dumps under Parallels always seem to have backtraces >>> that are like: >>>=20 >>> #0 0xffff0000004b9e48 in doadump (textdump=3D0) >>> at /home/pkgbuild/worktrees/main/sys/kern/kern_shutdown.c:404 >>> #1 0x6fa60000000e9d98 in ?? () >>> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >>>=20 >>> and the rest of the cores are like: >>>=20 >>> #0 0xffff0000008703b0 in ipi_stop (dummy=3D) >>> at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342 >>> #1 0xd2e9000000866b68 in ?? () >>> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >>=20 >> Again during a poudriere bulk run: >>=20 >> VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> 0xffffa001e559fa50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cd80f0 >> usecount 3, writecount 0, refcount 1 seqc users 0 mountedhere 0 >> hold count flags () >> flags () >> v_object 0xffffa00875bbe210 ref 0 pages 1 cleanbuf 0 dirtybuf 0 >> lock type ufs: SHARED (count 2) >> vp=3D0xffffa001e559fa50, lowervp=3D0xffffa0031f0b2a50 >> panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> cpuid =3D 2 >> time =3D 1744180482 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >> vpanic() at vpanic+0x1a0 >> panic() at panic+0x48 >> vget_finish_ref() at vget_finish_ref+0x1a4 >> null_hashget() at null_hashget+0xe4 >> null_nodeget() at null_nodeget+0x34 >> null_lookup() at null_lookup+0x118 >> vfs_lookup() at vfs_lookup+0x3e0 >> namei() at namei+0x298 >> sys___realpathat() at sys___realpathat+0xb0 >> do_el0_sync() at do_el0_sync+0x608 >> handle_el0_sync() at handle_el0_sync+0x4c >> --- exception, esr 0x56000000 >> KDB: enter: panic >>=20 >> Here: >> namei() at namei+0x298 >> sys___realpathat() at sys___realpathat+0xb0 >> do_el0_sync() at do_el0_sync+0x608 >>=20 >> Previously:=20 >> namei() at namei+0x298 >> vn_open_cred() at vn_open_cred+0x450 >> openatfp() at openatfp+0x238 >> do_el0_sync() at do_el0_sync+0x608 >>=20 >> So it looks like what is common is: namei()..vget_finish_ref() >>=20 >> vget_finish_ref() at vget_finish_ref+0x1a4 >> null_hashget() at null_hashget+0xe4 >> null_nodeget() at null_nodeget+0x34 >> null_lookup() at null_lookup+0x118 >> vfs_lookup() at vfs_lookup+0x3e0 >> namei() at namei+0x298 >>=20 >> This one had a v_object output line, the prior one did not. >> Some counts vary. >=20 > VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) > 0xffffa00a2a17ec08: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 > usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 > hold count flags () > flags () > v_object 0xffffa00a40b73000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > lock type ufs: SHARED (count 2) > vp=3D0xffffa00a2a17ec08, lowervp=3D0xffffa00a2a21f6e0 > panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) > cpuid =3D 7 > time =3D 1744203937 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x38 > vpanic() at vpanic+0x1a0 > panic() at panic+0x48 > vget_finish_ref() at vget_finish_ref+0x1a4 > null_hashget() at null_hashget+0xe4 > null_nodeget() at null_nodeget+0x34 > null_lookup() at null_lookup+0x118 > vfs_lookup() at vfs_lookup+0x3e0 > namei() at namei+0x298 > kern_statat() at kern_statat+0xf4 > sys_fstatat() at sys_fstatat+0x2c > do_el0_sync() at do_el0_sync+0x608 > handle_el0_sync() at handle_el0_sync+0x4c > --- exception, esr 0x56000000 > KDB: enter: panic >=20 > Here: > namei() at namei+0x298 > kern_statat() at kern_statat+0xf4 > sys_fstatat() at sys_fstatat+0x2c > do_el0_sync() at do_el0_sync+0x608 >=20 > The *statat() are distinct from the prior examples. >=20 > Again the common part is: >=20 > vget_finish_ref() at vget_finish_ref+0x1a4 > null_hashget() at null_hashget+0xe4 > null_nodeget() at null_nodeget+0x34 > null_lookup() at null_lookup+0x118 > vfs_lookup() at vfs_lookup+0x3e0 > namei() at namei+0x298 The 4th one is another one with: Here: namei() at namei+0x298 kern_statat() at kern_statat+0xf4 sys_fstatat() at sys_fstatat+0x2c do_el0_sync() at do_el0_sync+0x608 like the prior one. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 9 14:39:06 2025 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 4ZXlvM06Hkz5rt9X; Wed, 09 Apr 2025 14:39:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXlvL3J9wz3LM7; Wed, 09 Apr 2025 14:39:10 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id 2VhiuklXK5Mqy2Wa5us5lf; Wed, 09 Apr 2025 14:39:09 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2Wa3uqVlol5eG2Wa4uhI6L; Wed, 09 Apr 2025 14:39:09 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=EO6l0EZC c=1 sm=1 tr=0 ts=67f6868d a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=_EeEMxcBAAAA:8 a=EkcXrb_YAAAA:8 a=HIpOd3htAAAA:8 a=YxBL1-UpAAAA:8 a=K8lFCU26Szz-7fEI1asA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=kmlo3kNSEkcePd_NiW6t:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 468B4C24; Wed, 09 Apr 2025 07:39:07 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (Postfix) with ESMTP id 1E7831A1; Wed, 09 Apr 2025 07:39:07 -0700 (PDT) Date: Wed, 9 Apr 2025 07:39:06 -0700 From: Cy Schubert To: Zhenlei Huang Cc: Robert Austen , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop Message-ID: <20250409073906.43e4282e@slippy> In-Reply-To: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Organization: KOMQUATS X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.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-CMAE-Envelope: MS4xfAeSq7tWLzZDNBPYzHzF+ULcPpAwc0DFFGXHGMjKg6oda+iV2O77EgacdS4CIEyb7f6Hmq7eSN7Yop5RLN1RQlne6edbUeNnrLsDpexYZjO3Kd3yTmph 5q2tHHYTAww1V+om7uW8ckLxhqCQiSBtoJ+IqcSpUHZo6F5QBIY1Stkb3E68SLV//0TKYlsHNyZT5mGzu8bjza94h1AWY9IteeYUsAMTvPkxKPYCPC+u/ShI aEmm1uxmvz3JuMEI0u0nPJCX+JDregJbnMkf16nmJFaB1OoRyAq5uAQ7d/zLQmRfzEpb9BSiAkVjGTXV2MTOtC/y+mZ7nqiGABatahRUFedN1YnoNUQVxlH9 tB//G1PGv9CifLXhA8OeFL2zRm/Dxg== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXlvL3J9wz3LM7 X-Spamd-Bar: ---- On Wed, 9 Apr 2025 15:48:11 +0800 Zhenlei Huang wrote: > > On Apr 9, 2025, at 1:01 AM, Robert Austen wrote: > > > > I respectfully disagree. > > > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call to enable itself, ie. to apply any hooks. > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults to PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP. > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCSTART ) or netlink command to enable it. > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, the pfil layer in the kernel has no idea what the filter will be, > > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and likewise the equivalents from the other filters). > > As for ipfw(4), by default it enables filtering on load, unless you disable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`. > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.inet.ip.fw.default_to_accept` controls the default behavior to drop or accept. > See also https://cgit.freebsd.org/src/commit/?id=5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd . > > > > > as I said, this is because there's no mechanism within PFIL to drop by default, which is why I proposed (and am using on my system) the PFIL_DEFAULT_TO_DROP, > > because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no effect at all, > > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP can ever provide. I don't know whether it should default drop or not. In the case of ipfilter, default drop will drop with or without a log message depending whether IPFILTER_LOG is defined in the kernel config or in the module's Makefile -- both are default. There's something to be said about default block in that there is absolutely no chance any packets will get through without a rule permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled and loaded before any interfaces are brought up so the point is mostly moot. However in unattended situations there is a better chance you could be able to remotely log in to fix any brokenness whereas with a default block you'd have to travel, possibly thousands of kilometres, to fix any problem. Both scenarios should be considered before making the decision whether to default block or default open. Then again, a badly conceived firewall rule, regardless of the default block setting, can make for a very bad day. IIRC -- it's been a couple of decades since I used IPFW -- IPFW is default block while IPFILTER is default open (unless otherwise configured). Considering that firewall rules are loaded before interfaces are brought up -- just run rcorder(8) to see the startup order for yourself -- this argument is moot. > > It appears ipf(4) unconditionally enable filtering on load, and does not have any tunables to control that. CC @Cy who is more familiar with ipf(4). This is not entirely correct. If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default. Otherwise by default it will not block by default. This can be adjusted at runtime in two ways. First through the sysctl net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass. The value is not intuitive. It's a hex value representing internal flags. If the hex value contains 0x2, ipfilter operates in default pass mode. If the hex value contains 0x1, it operates in default block mode. It will tell you at boot which mode is default: stinky# dmesg | grep IP\ Filter IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled stinky# Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T default_pass to adjust the flag is preferred. Setting the default_block or ipf_pass is not entirely intuitive. > > > > > thanks! > > From: Zhenlei Huang > > > Sent: April 7, 2025 7:55 PM > > To: Robert Austen > > > Cc: freebsd-current@freebsd.org >; freebsd-net@freebsd.org >; Kristof Provost > > > Subject: Re: pfil_default_to_drop > > > > You don't often get email from zlei@freebsd.org . Learn why this is important > > > > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: > >> > >> > >> > >> From: Robert Austen > > >> Sent: April 7, 2025 4:33 PM > >> To: freebsd-current@freebsd.org >; freebsd-net@freebsd.org > > >> Subject: Fw: pfil_default_to_drop > >> > >> > >> From: Robert Austen > >> Sent: April 7, 2025 4:21 PM > >> To: freebsd-current@freebsd.org > > >> Subject: pfil_default_to_drop > >> > >> Hello, > >> I've been playing with FreeBSD and PF to build myself a new firewall, as Open/FreeBSD + PF seems to be a common starting point. > >> > >> I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP and the like, with the observations that it's hard > >> to ensure that packets all default to drop if the rule file(s) for whatever reason fail to load. > > > > Hi Robert, > > > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.ko ( via the loader(8), /boot/loader.conf ) ? > > > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.ko. > > See also https://cgit.freebsd.org/src/commit/?id=c531c1d1462c45f7ce5de4f9913226801f3073bd . > > > >> > >> After looking thru the online documentation, forums and scripts, I came to the conclusion that it's not a PF problem or IPFW etc > >> or really a problem with any of the filters or scripts, the problem is at the level of PFIL, the kernel packet filtering code: If no > >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends everything thru to its destination. So my thought > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_DEFAULT_TO_DROP) that drops all the > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded chosen filter (PF or whatever) at any given time the > >> hooks are unhooked. > > > > If no firewalls loaded, then the system should behave as is. I do not think PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > >> > >> [No one filters on local loopback nor the link layer, so I've left those hooks untouched. I suppose one could add them, > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt there's much demand for it.] > >> > >> Normally I'm an embedded linux kernel basher. > >> I'm not entirely sure where to send this patch. Most of the threads asking the above PF questions are closed to changes, > >> so that doesn't seem a good place. Sir Dice seems to be a common answerer of questions; I would have sent it to him/her > >> if I could... > >> > >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch"... > >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > >> but I suspect the kernel code in the networking core doesn't change much from platform to platform, or version to version. > >> > >> But it works, it's pretty simple, pretty small and so just in case it might be useful, I'm passing it along. > >> > >> thanks! > >> > >> > >> Robert > >> > >> > >> > >> > >> > > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Wed Apr 9 14:57:37 2025 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 4ZXmJt2nFXz5rvJH for ; Wed, 09 Apr 2025 14:57:50 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4ZXmJr3cZ7z3SGQ for ; Wed, 09 Apr 2025 14:57:47 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b="Bse59/h3"; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1744210658; bh=VMfh0e6kaX1cw+6AwD/vlhZr2U+SQbOX2VY7RnXqNxw=; h=Date:From:To:Subject:In-Reply-To:References; b=Bse59/h3EHik5now0RZyP6ubKcqsWs47ayTbMl1AA8+M1SQ+DIibxKMgXQNssHoX9 gKOlBBJnTFx5dGP5tR9uuyONut9ghKbFBZMcDk++J+QKqUPv5WLjYC11Z0/r8onwUW fGemB7NrsbsmECcq2RBNfu3CGtRVI5VAnlhvO2EwW/7hcKOng0dGU5AW1jkWFyAr0c JjKQTQxmt5aa0JFbDMJjkAEgg2vdAsFKCao1EeDih+jufIi/sAFfGXRdT+VhU+e9K5 RuopOY/PZh6XFAIe2Tb5oery4r9WuqIOYBC8d7WC8S0obwo0EOt2wyYdO4WO+mijxP NzpBzDyNkDrD5PMKlW4SkPfp8xChFeY8ysjWoZTEkAB4M1reoUdZndEBZuafLK3Xkn qLf9Uq00fjhGBIx60fjeaMmtEzTsQ/mJQcl6+oRiky9PBCa45MRTjdMpNGG9ubGZah SkJI/4L+qExSpJw+WbqxzzC2DpoRblG3scxMOe4xwMh0BXNVcLdZv/tgXD97njyZq5 c0h2nwXAzBhMH+tk+ixdcHYa+6jRrgmtl17xv8BR9c03MuRMxx8AUsHGwhfbtSGqJP WgFVZxU5EHxukG7vXr0BJpZCMKaGmtTUdP3gqFrO62AkwTFSJ7Yr55RhrUvW9WeXiY ov1vq4LVlbdmbRWMpgRUGyiI= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 1BA55598669 for ; Wed, 09 Apr 2025 17:57:38 +0300 (EEST) Date: Wed, 09 Apr 2025 17:57:37 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: elfcopy: not found User-Agent: K-9 Mail for Android In-Reply-To: References: 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-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [0.51 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_SHORT(-0.43)[-0.432]; NEURAL_HAM_LONG(-0.26)[-0.263]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4ZXmJr3cZ7z3SGQ X-Spamd-Bar: / On April 9, 2025 5:08:31 AM GMT+03:00, Ed Maste wro= te: >On Mon, 7 Apr 2025 at 21:50, Sulev-Madis Silber > wrote: >> >> --- boot1=2Eefi --- >> SOURCE_DATE_EPOCH=3D1704067200 elfcopy -j =2Epeheader -j =2Etext -j = =2Esdata -j =2Edata -j =2E >> dynamic -j =2Edynsym -j =2Erel=2Edyn -j =2Erela=2Edyn -j =2Ereloc -j = =2Eeh_frame --output-target >> =3Dbinary boot1=2Esym boot1=2Eefi >> sh: elfcopy: not found >> 313=2E12 real 432=2E90 user 44=2E54 sys >> >> make[1]: stopped in /root/files/fbsd/current/src >> >> make: stopped in /root/files/fbsd/current/src >> 29m18=2E50s real 43m6=2E42s user 5m47=2E07s = sys >> >> >> host is 13=2E unsure what that is? there's entry, 20250314, in updating= but i can't figure out what that is and how to fix it=2E WITH_LLVM_TARGET_= X86=3Dyes maybe? unsure how to fix this on my own > >Do you have anything in /etc/src=2Econf? >Also, from the top of your src tree try: >$ make -VMK_ELFTOOLCHAIN_BOOTSTRAP TARGET=3Damd64 TARGET_ARCH=3Damd64 -f >Makefile=2Einc1 > yes, this: WITH_MALLOC_PRODUCTION=3Dyes WITHOUT_ACCT=3Dyes WITHOUT_ACPI=3Dyes WITHOUT_APM=3Dyes WITHOUT_ASSERT_DEBUG=3Dyes WITHOUT_AT=3Dyes WITHOUT_ATM=3Dyes WITHOUT_AUDIT=3Dyes WITHOUT_AUTHPF=3Dyes #WITHOUT_AUTO_OBJ=3Dyes WITHOUT_AUTOFS=3Dyes WITHOUT_BHYVE=3Dyes WITHOUT_BLACKLIST=3Dyes WITHOUT_BLACKLIST_SUPPORT=3Dyes WITHOUT_BLUETOOTH=3Dyes #WITHOUT_BOOT=3Dyes WITHOUT_BOOTPARAMD=3Dyes WITHOUT_BOOTPD=3Dyes WITHOUT_BSD_CPIO=3Dyes WITHOUT_BSDINSTALL=3Dyes WITHOUT_BSNMP=3Dyes WITHOUT_BZIP2=3Dyes WITHOUT_BZIP2_SUPPORT=3Dyes WITHOUT_CALENDAR=3Dyes #WITHOUT_CAPSICUM=3Dyes WITHOUT_CAROOT=3Dyes #WITHOUT_CASPER=3Dyes WITHOUT_CCD=3Dyes WITHOUT_CDDL=3Dyes WITHOUT_CLANG=3Dyes WITHOUT_CLANG_BOOTSTRAP=3Dyes WITHOUT_CLANG_EXTRAS=3Dyes WITHOUT_CLANG_FORMAT=3Dyes WITHOUT_CLANG_FULL=3Dyes #WITHOUT_CLEAN=3Dyes WITHOUT_CPP=3Dyes WITHOUT_CROSS_COMPILER=3Dyes #WITHOUT_CRYPT=3Dyes WITHOUT_CTF=3Dyes WITHOUT_CUSE=3Dyes WITHOUT_CXGBETOOL=3Dyes #WITHOUT_CXX=3Dyes WITHOUT_DEBUG_FILES=3Dyes WITHOUT_DIALOG=3Dyes WITHOUT_DICT=3Dyes WITHOUT_DMAGENT=3Dyes WITHOUT_DOCCOMPRESS=3Dyes WITHOUT_DTRACE=3Dyes WITHOUT_DTRACE_TESTS=3Dyes #WITHOUT_DYNAMICROOT=3Dyes #WITHOUT_EE=3Dyes #WITHOUT_EFI=3Dyes #WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3Dyes WITHOUT_EXAMPLES=3Dyes WITHOUT_FILE=3Dyes WITHOUT_FINGER=3Dyes WITHOUT_FLOPPY=3Dyes #WITHOUT_FORMAT_EXTENSIONS=3Dyes #WITHOUT_FORTH=3Dyes #WITHOUT_FP_LIBC=3Dyes WITHOUT_FREEBSD_UPDATE=3Dyes WITHOUT_FTP=3Dyes WITHOUT_GAMES=3Dyes #WITHOUT_GH_BC=3Dyes WITHOUT_GNU_DIFF=3Dyes WITHOUT_GOOGLETEST=3Dyes #WITHOUT_GPIO=3Dyes WITHOUT_GSSAPI=3Dyes WITHOUT_HAST=3Dyes WITHOUT_HTML=3Dyes WITHOUT_HYPERV=3Dyes WITHOUT_ICONV=3Dyes WITHOUT_INCLUDES=3Dyes #WITHOUT_INET=3Dyes #WITHOUT_INET_SUPPORT=3Dyes #WITHOUT_INET6=3Dyes #WITHOUT_INET6_SUPPORT=3Dyes WITHOUT_INETD=3Dyes #WITHOUT_INSTALLLIB=3Dyes WITHOUT_IPFILTER=3Dyes WITHOUT_IPFW=3Dyes WITHOUT_IPSEC_SUPPORT=3Dyes WITHOUT_ISCSI=3Dyes WITHOUT_JAIL=3Dyes WITHOUT_KDUMP=3Dyes WITHOUT_KERBEROS=3Dyes WITHOUT_KERBEROS_SUPPORT=3Dyes WITHOUT_KERNEL_SYMBOLS=3Dyes WITHOUT_KVM=3Dyes WITHOUT_KVM_SUPPORT=3Dyes WITHOUT_LDNS=3Dyes WITHOUT_LDNS_UTILS=3Dyes WITHOUT_LEGACY_CONSOLE=3Dyes WITHOUT_LIB32=3Dyes WITHOUT_LLD=3Dyes #WITHOUT_LLD_BOOTSTRAP=3Dyes #WITHOUT_LLD_IS_LD=3Dyes WITHOUT_LLDB=3Dyes WITHOUT_LLVM_ASSERTIONS=3Dyes WITHOUT_LLVM_COV=3Dyes #WITHOUT_LLVM_CXXFILT=3Dyes WITHOUT_LLVM_TARGET_AARCH64=3Dyes WITHOUT_LLVM_TARGET_ALL=3Dyes WITHOUT_LLVM_TARGET_ARM=3Dyes WITHOUT_LLVM_TARGET_POWERPC=3Dyes WITHOUT_LLVM_TARGET_RISCV=3Dyes WITHOUT_LLVM_TARGET_X86=3Dyes WITHOUT_LOADER_EFI_SECUREBOOT=3Dyes WITHOUT_LOADER_GELI=3Dyes WITHOUT_LOADER_KBOOT=3Dyes #WITHOUT_LOADER_LUA=3Dyes WITHOUT_LOADER_OFW=3Dyes WITHOUT_LOADER_UBOOT=3Dyes WITHOUT_LOADER_VERIEXEC=3Dyes WITHOUT_LOADER_VERIEXEC_VECTX=3Dyes WITHOUT_LOADER_ZFS=3Dyes #WITHOUT_LOCALES=3Dyes WITHOUT_LOCATE=3Dyes WITHOUT_LPR=3Dyes #WITHOUT_LS_COLORS=3Dyes #WITHOUT_MACHDEP_OPTIMIZATIONS=3Dyes WITHOUT_MAIL=3Dyes WITHOUT_MAILWRAPPER=3Dyes WITHOUT_MAKE=3Dyes #WITHOUT_MAKE_CHECK_USE_SANDBOX=3Dyes WITHOUT_MAN=3Dyes WITHOUT_MAN_UTILS=3Dyes WITHOUT_MANCOMPRESS=3Dyes #WITHOUT_META_MODE=3Dyes WITHOUT_MLX5TOOL=3Dyes #WITHOUT_NETCAT=3Dyes WITHOUT_NETGRAPH=3Dyes WITHOUT_NETGRAPH_SUPPORT=3Dyes WITHOUT_NIS=3Dyes WITHOUT_NLS=3Dyes WITHOUT_NLS_CATALOGS=3Dyes WITHOUT_NS_CACHING=3Dyes #WITHOUT_NTP=3Dyes WITHOUT_NVME=3Dyes WITHOUT_OFED=3Dyes WITHOUT_OFED_EXTRA=3Dyes WITHOUT_OPENMP=3Dyes #WITHOUT_OPENSSH=3Dyes #WITHOUT_OPENSSL=3Dyes #WITHOUT_OPENSSL_KTLS=3Dyes #WITHOUT_PAM=3Dyes WITHOUT_PAM_SUPPORT=3Dyes WITHOUT_PF=3Dyes #WITHOUT_PIE=3Dyes WITHOUT_PKGBOOTSTRAP=3Dyes WITHOUT_PMC=3Dyes WITHOUT_PORTSNAP=3Dyes WITHOUT_PPP=3Dyes WITHOUT_QUOTAS=3Dyes WITHOUT_RADIUS_SUPPORT=3Dyes WITHOUT_RBOOTD=3Dyes #WITHOUT_RELRO=3Dyes #WITHOUT_RESCUE=3Dyes WITHOUT_ROUTED=3Dyes WITHOUT_SENDMAIL=3Dyes WITHOUT_SERVICESDB=3Dyes #WITHOUT_SETUID_LOGIN=3Dyes #WITHOUT_SHARED_TOOLCHAIN=3Dyes WITHOUT_SHAREDOCS=3Dyes #WITHOUT_SOURCELESS=3Dyes #WITHOUT_SOURCELESS_HOST=3Dyes #WITHOUT_SOURCELESS_UCODE=3Dyes WITHOUT_SPLIT_KERNEL_DEBUG=3Dyes #WITHOUT_SSP=3Dyes #WITHOUT_STAGING=3Dyes #WITHOUT_STAGING_MAN=3Dyes #WITHOUT_STAGING_PROG=3Dyes WITHOUT_STATS=3Dyes WITHOUT_SYSCONS=3Dyes #WITHOUT_SYSROOT=3Dyes #WITHOUT_SYSTEM_COMPILER=3Dyes #WITHOUT_SYSTEM_LINKER=3Dyes WITHOUT_TALK=3Dyes WITHOUT_TCP_WRAPPERS=3Dyes #WITHOUT_TCSH=3Dyes WITHOUT_TELNET=3Dyes WITHOUT_TESTS=3Dyes WITHOUT_TESTS_SUPPORT=3Dyes #WITHOUT_TEXTPROC=3Dyes WITHOUT_TFTP=3Dyes WITHOUT_TOOLCHAIN=3Dyes WITHOUT_UNBOUND=3Dyes #WITHOUT_UNIFIED_OBJDIR=3Dyes #WITHOUT_USB=3Dyes #WITHOUT_USB_GADGET_EXAMPLES=3Dyes WITHOUT_UTMPX=3Dyes WITHOUT_VERIEXEC=3Dyes #WITHOUT_VI=3Dyes WITHOUT_VT=3Dyes #WITHOUT_WARNS=3Dyes #WITHOUT_WERROR=3Dyes #WITHOUT_WIRELESS=3Dyes #WITHOUT_WIRELESS_SUPPORT=3Dyes #WITHOUT_WPA_SUPPLICANT_EAPOL=3Dyes WITHOUT_ZFS=3Dyes WITHOUT_ZONEINFO=3Dyes WITHOUT_ZONEINFO_LEAPSECONDS_SUPPORT=3Dyes see any footshootings? but it does indeed turn MK_ELFTOOLCHAIN_BOOTSTRAP to "no" value i might have optimized myself into hellhole here but what happened within = last month that caused this, which change is it? my idea was to optimize resulting armv7 build size, not any local crossbui= ld toolchains=2E many options are decade old in that config=2E altho i chec= ked them recently From nobody Wed Apr 9 16:29:16 2025 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 4ZXpLd1kzRz5s2CX; Wed, 09 Apr 2025 16:29:29 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Received: from YT5PR01CU002.outbound.protection.outlook.com (mail-canadacentralazon11021117.outbound.protection.outlook.com [40.107.192.117]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXpLc6V01z3pNk; Wed, 09 Apr 2025 16:29:28 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mgm0zgbwF56A4zydQY1lbzrsXii9iAgOfb3xHDI0aV7I1tVUbBnJnf9UAKoFyzwAjEZCWdU71aaRs8DnaqTLtWVLAoo6+9EJkv88UlZXjIv5BQIjbNpcRTesd7t9w0zmWwu8U1Mw1LoNzYXNtsGSDoJnjIX4UfkHJi1BJcPi3CCcGKDcLkFar2ZP0NI8OCejy/vQVNdkd4Uv5nkOgmF816uri/wZJ4ilibLdbREXIOdy2GlKEvT5pn7rUW4/yGJJQGAVTCZhqC4wKi7aVGf6O1qjXH52ipdrR8TsHg5ALfhYqW/Rr5E/YAHGAvMiXoVkMDcLodMbd9c/F7YjqnbQDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Yd0J+HAacvI+42EY0VXuZMirTzdJO+yl47qMFhl08yA=; b=ePc3ynKNGUrwM7VbKtvpBrojxmx5ekRsMbdycrtjeEFSH48SYGZBGWahW4DHFDKh7mSsybzvQ+cPdcmT2QMXQZInnS+8PAt7yBvhI2fUiAvFW4VuPn8EIEAcworxvzH581+aIB8zos2/KStmNldC6w5vjse04niMI/5fdk0Xd9Y9Y7LHMoXQWK/8xln7vdxNUYYsR4zAi2CDe2jG1ZrXVVZmvsJpAjxPNSaPdWsAs+f1+LZcCrmY2jF8WaOfoaXFDDtCUocCjnFVQCMNOoLOjPHinLHbEdmCv/bgXP3YzZ67iDZLPzNF+RfoqeEptraChlRrRXwJ8Rso7jbjbml1Dw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=willowglensystems.com; dmarc=pass action=none header.from=willowglensystems.com; dkim=pass header.d=willowglensystems.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willowglensystems.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yd0J+HAacvI+42EY0VXuZMirTzdJO+yl47qMFhl08yA=; b=kHkGhDs+3zURJOiCQfxtZ/iKtJNmuuSMHKTiUbfksf3KqyX/KhnM1C4E2Vuz+5qIJkTGXe7+CHGBjI5xkMhUkZdTSjc7qBKqrjML0caTdQn8p94rPCSaEI8FbcdSRZ4AHqI8GX/rLVykTAIy77krqV+a41rTnPDc+D18UfJolKI= Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c08::23a) by YT2PR01MB5408.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:53::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8606.35; Wed, 9 Apr 2025 16:29:18 +0000 Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d]) by QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d%4]) with mapi id 15.20.8632.021; Wed, 9 Apr 2025 16:29:17 +0000 From: Robert Austen To: Cy Schubert , Zhenlei Huang CC: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop Thread-Topic: pfil_default_to_drop Thread-Index: AQHbqAfyk4Z18yjsM0yECEK2f5QGrrOYyea/gAAA4zGAADehgIAA+tGKgAD6MICAAHLPAIAAHNT9 Date: Wed, 9 Apr 2025 16:29:16 +0000 Message-ID: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> <20250409073906.43e4282e@slippy> In-Reply-To: <20250409073906.43e4282e@slippy> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: QB1PPF4C719E46A:EE_|YT2PR01MB5408:EE_ x-ms-office365-filtering-correlation-id: 9ec0dfe8-e268-4de6-be0f-08dd7783ac12 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018|13003099007|8096899003|7053199007; x-microsoft-antispam-message-info: =?us-ascii?Q?c6dtqw5fArfblCVNMmOvKhnAbuApzOi2w6+Lo6GY7vgrJeYZ/sQBZ3uyOF05?= =?us-ascii?Q?kH63QwLVU2xpsiuDLrzjDZKisOrKkSosWC1W7yuKg7GQH99A3PQek3wVz75Y?= =?us-ascii?Q?4KXAUtkJkam5fY/35z0lzyWdcZNQ0OqBdLrEWhPv8r8fvYU21beL7ASXVrQ8?= =?us-ascii?Q?BRP1N7Kkhix7mK4jZ7W+egyE1WZgdSHCalICzJBR5x4sCn4+welOiDbIeQdY?= =?us-ascii?Q?iWv7EsEWa0aqNCGlsAI53VJSbeRUWaLdVZS7FeYwhn9dkgUGZ01cJCnMcY4A?= =?us-ascii?Q?CxRxezNwQMKUddpJz6uA1yAtg7KbuTQ40DZuFLpDIi9wazQDiBT7s4+/psRO?= =?us-ascii?Q?68qrnNe+agDivz0Q+FNRW+dMPGk7ICveEQ1Sw3Q5E/rZ11WUtsUdFPjYfR4Q?= =?us-ascii?Q?HmLhZVW4NSUej4kw/daYTYW/NTMQuBMyriNVWcC1NkyJKrUJa6FwEE0ePqM7?= =?us-ascii?Q?02O5RShoK7ZiFRA8IMetOEaPoJtiFm9nVk7xwhrfdIKuspDr1hLaKqLE6OVp?= =?us-ascii?Q?a8iPSVaob3uoVUgvSBnRFf+teKt/B/pDqrWIy6CddsCp9RgcNrMPX5/zyYPd?= =?us-ascii?Q?fmHMFTcU+Lbd9WDWz9aSdocVF1yQyqDGB1ktyjv5d+Kay/V4sGFOZk6AceAz?= =?us-ascii?Q?ge8VTzajM/QpeNQa0byq3mLOpz+uzuQJHRvPJ1LFizr27dznhFT00wsCY9Lr?= =?us-ascii?Q?ITig1bnIW0ojiKkcf4l7dIQqbffHLfRfvtmVt3vRQWXp+259fzLlAENym1nb?= =?us-ascii?Q?V0l5UMLkXoAiDMdTHpiSUqngdVx8jalQXt3v5e80cYXU7LpTrqTFw+ibhOn1?= =?us-ascii?Q?5Zrvtqg10p2ttt8KoB59sdeOXnHfzIpiRQ/OFA5H3Fmxk3fOLv/UNC8VWeYr?= =?us-ascii?Q?WdcKlGz+vARiisUMjxkXJ3F+RPnWrDuWeG+pSyh2Ks4aiXO2GuZ/1zcQOTV7?= =?us-ascii?Q?MA7pjjbxLWHwpXakmtfyBIGicNxkwI9qbETifO1ANT7Zj+vgxwAMtBJbXt2A?= =?us-ascii?Q?I4oWw25Lkkt57ftDQGPqi+BFRn8eCGQ/PoU/DuP1SRJzsFTzAeLcdwwzv1d8?= =?us-ascii?Q?1LWakkKJFaCcSkLEawefc92c/4eV3Jf6E9iqUahv8btATzzQLAEtU/Iv4VAj?= =?us-ascii?Q?1inAkR6cFVhHG1IrRSzMDgAZe6Q1OlOL9TPbzi5llyssAoecNdnqaQo80uMy?= =?us-ascii?Q?W/RCTodG62phy5K5KYd6A9JJQ3urJnnPWKHi6ScFWiptteJWeRLWL5nkhr3a?= =?us-ascii?Q?LwpEgWIPHM8EtCzS/emDddSp8q+ZjLiv5Lx0ts+uf9j4TnjP0EF0NNDWO24A?= =?us-ascii?Q?MpViKaepOnDV8grPUl64qBkoEdcTm/SL2n9kvt+AEpJo+LHqMsS7ExeiN0nO?= =?us-ascii?Q?gsQf8hHV7vieeDEJ2GteC9teSERbdSsE3IlWIX/OsafCsExwCx5yoG+OsG8G?= =?us-ascii?Q?pXg7+ZNvva4=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018)(13003099007)(8096899003)(7053199007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rU5uzytlpnw5TyGDl+TwF6Alf48g4iAwbzLbRvW5PvFwIVnqs0Glrv/cIKL9?= =?us-ascii?Q?SwtmsuFGSvUOyLbwOoxGof7Izd1RnPYaBMyLkxbVmrggdCvColBavSXBWYFj?= =?us-ascii?Q?sn5QhNYR3X5Ps9SUy51A7WdkXzwtF0Y4/hkqzYIpfPjz9+3fO9hWLRJ4Tjv6?= =?us-ascii?Q?g3tUmC02qDvS5n0Rk9ckV2+9Q3yzElCjw8KBQzzUUQwFt2/ckdQxFlZtzvAJ?= =?us-ascii?Q?BP156D+BMhuSvsJjKPpO1DWg4802337MRyHZjKxKJKS9g0/tbLfWEWJtCMIl?= =?us-ascii?Q?l/ddEdVesACOsw5JAtVnVamPoU7i/no1iMaFyXhkT9HdeEyFwQeKc3GqtB7D?= =?us-ascii?Q?7AesK30WCnuMJtcnr63Yg/NxyedvY7syuQfa0yDFON/vbcKBaP9mtqIBemWx?= =?us-ascii?Q?9CIi8fiMMLvdPZFLszgbM0JuF8E/A5+9SbpR/17A4GA7rUHTZ+hpkPjaP41Q?= =?us-ascii?Q?XjInCxS3vAiGLZZUCF+IP9Jvv2P32U8RON45QqwuqGCnglho6pDyczjnRAOU?= =?us-ascii?Q?mPpX9ZUhUD2h5Wqqz0kXaeg1E17LMOpGAuoiw/LdhQr9GFY1A9aJNnjT6aEw?= =?us-ascii?Q?sZh3tVUcEQ7RMLy86hZMdjB95I7kqEOF2pZ5+n0paeVtEAlg15TAdyHX8eLl?= =?us-ascii?Q?37fh2WOmtwEU6K2ytX/B8VbxaP4SmnNWMGpBln7VCYVOT5I0AX/fI6WCe0mF?= =?us-ascii?Q?sizjm2gJ/GfzP4FtSz9+Ybk+zJ3VWP88nKcAP5TiCYzkRv7i8mtFpYkPceZj?= =?us-ascii?Q?DvcLz6scKZFJNQkuPTEWA0Inya/TRYBePnexy6ihyzaqdS5inEonWi/5jHMf?= =?us-ascii?Q?i5WBiY4tjzO/7D08dvjBdGIa0b5qMrPHZsvxtCOrqJA3at7EOapgdsxYkaKw?= =?us-ascii?Q?uhPMPNzdrpehdufNqIMAuf0R0BhmPf2lXe1eZW4SJc2Jao4WVVqgC8vhTQO3?= =?us-ascii?Q?GdOXPiaQn4CVWIvNBiqXQPw9nHyGJXlMP0JKGj5BIXT1hNRnNdX3PSRpjlGZ?= =?us-ascii?Q?SSGy4m8cL2iD+nvKugXU/4mNVrOUFGlN7lJg8166vsA0j4wP0u6r18cBCcG8?= =?us-ascii?Q?M8c9UGtOV4MvMjoxFzruahPs44GJV8O0GBjb/VctwH9Wjw3SLU50sJyCyttN?= =?us-ascii?Q?zyYQmTzJvh+r/NcfptpwyVQNlbLQeC/sqjFLnxS0CLLNaVYhf2KRUM8VBURg?= =?us-ascii?Q?RUAvhVVLGoR2PDV/qnjliub28RAMtC+jBNm60rDXd1ZrMT+AInMo4x9wVdEo?= =?us-ascii?Q?er4IgFKzT/FJpfx/juT4d5OfhBII+bsozqHO00nMiKhXLGO6qRUd7G61JSQv?= =?us-ascii?Q?qqlGLHeE+oWF5lxhr9w+FG1vcbgEe7qZNVchhx12iAGUiv07fHVccUmMk9Pi?= =?us-ascii?Q?ijsAIx59zxs+94DwYK0gCpWOYy9c7fRbIKm16HugIcphib1nvuLs8JT8omFQ?= =?us-ascii?Q?v0w+Z53IWeVFEepJW62fpYS2c9wrSqvC0ELcP8OU4NeIuYa1TZ6TfOw8d/Oc?= =?us-ascii?Q?9LWjkM7Mg7sr+mIREmSr7Zt3KNr4AQRwW5pbf5yGAdAjfzJ+LvLz5raRC9Ye?= =?us-ascii?Q?7dkelTR3E/XLBB25N10TTX4OcfZFmNx7dv55brPRgbRQPIPTeinr67rS247h?= =?us-ascii?Q?0ZQ0GLFDmxkbUuO1Po99Wf0=3D?= Content-Type: multipart/alternative; boundary="_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_" 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 X-OriginatorOrg: willowglensystems.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9ec0dfe8-e268-4de6-be0f-08dd7783ac12 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2025 16:29:16.7539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c7bca0fa-9d0c-460d-8770-da688c84194e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cD0oHHxpZP9tZpyNmDS7j18Z4bu/HF6JTsOnPyugmsk2GpSFEb4+Hb+B6P534DU8pPRGcaWe581qSpxNejl/Ijh4GLCkoX83yc1RS5z6HRZUFxlltdnaGgUKkt2j5unB X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB5408 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US] X-Rspamd-Queue-Id: 4ZXpLc6V01z3pNk X-Spamd-Bar: ---- --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Considering that firewall rules are loaded before interfaces" I don't believe that's true. I used rcorder, and played around with things, because I noted that the int= erfaces (esp if static) came up first, then the forwarding, then pf log, and finally pf was last. There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "rdr = pass" rules. Anyways, rather than debating what might work better in situation A vs B, a= nd dictating what users of freeBSD can or cannot do, why not give options? isn't that the whole point of options and conf files? let sysadmin use whatever option they see fit? they shouldn't have to write something to get the result they want (or need= ), like I had to.. ________________________________ From: Cy Schubert Sent: April 9, 2025 8:39 AM To: Zhenlei Huang Cc: Robert Austen ; freebsd-current@fr= eebsd.org ; freebsd-net@freebsd.org ; Kristof Provost ; Cy Schubert Subject: Re: pfil_default_to_drop [You don't often get email from cy.schubert@cschubert.com. Learn why this i= s important at https://aka.ms/LearnAboutSenderIdentification ] On Wed, 9 Apr 2025 15:48:11 +0800 Zhenlei Huang wrote: > > On Apr 9, 2025, at 1:01 AM, Robert Austen wrote: > > > > I respectfully disagree. > > > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl ca= ll to enable itself, ie. to apply any hooks. > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaul= ts to PASS, which is not what most people would intend using PF_DEFAULT_TO_= DROP. > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCST= ART ) or netlink command to enable it. > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselve= s, the pfil layer in the kernel has no idea what the filter will be, > > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (a= nd likewise the equivalents from the other filters). > > As for ipfw(4), by default it enables filtering on load, unless you disab= le it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable`= and `net.link.ether.ipfw`. > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.in= et.ip.fw.default_to_accept` controls the default behavior to drop or accept= . > See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff= 60e598498df6f9e2bd . > > > > > as I said, this is because there's no mechanism within PFIL to drop by = default, which is why I proposed (and am using on my system) the PFIL_DEFAU= LT_TO_DROP, > > because it handles ALL of the 'no filter installed (yet)' cases. if PFI= L_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no effec= t at all, > > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_= DROP can ever provide. I don't know whether it should default drop or not. In the case of ipfilter, default drop will drop with or without a log message depending whether IPFILTER_LOG is defined in the kernel config or in the module's Makefile -- both are default. There's something to be said about default block in that there is absolutely no chance any packets will get through without a rule permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled and loaded before any interfaces are brought up so the point is mostly moot. However in unattended situations there is a better chance you could be able to remotely log in to fix any brokenness whereas with a default block you'd have to travel, possibly thousands of kilometres, to fix any problem. Both scenarios should be considered before making the decision whether to default block or default open. Then again, a badly conceived firewall rule, regardless of the default block setting, can make for a very bad day. IIRC -- it's been a couple of decades since I used IPFW -- IPFW is default block while IPFILTER is default open (unless otherwise configured). Considering that firewall rules are loaded before interfaces are brought up -- just run rcorder(8) to see the startup order for yourself -- this argument is moot. > > It appears ipf(4) unconditionally enable filtering on load, and does not = have any tunables to control that. CC @Cy who is more familiar with ipf(4). This is not entirely correct. If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default. Otherwise by default it will not block by default. This can be adjusted at runtime in two ways. First through the sysctl net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass. The value is not intuitive. It's a hex value representing internal flags. If the hex value contains 0x2, ipfilter operates in default pass mode. If the hex value contains 0x1, it operates in default block mode. It will tell you at boot which mode is default: stinky# dmesg | grep IP\ Filter IP Filter: v5.1.2 initialized. Default =3D pass all, Logging =3D enabled IP Filter: v5.1.2 initialized. Default =3D pass all, Logging =3D enabled stinky# Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T default_pass to adjust the flag is preferred. Setting the default_block or ipf_pass is not entirely intuitive. > > > > > thanks! > > From: Zhenlei Huang > > > Sent: April 7, 2025 7:55 PM > > To: Robert Austen > > > Cc: freebsd-current@freebsd.org >; freebsd-n= et@freebsd.org >; Kristof Provost > > > Subject: Re: pfil_default_to_drop > > > > You don't often get email from zlei@freebsd.org . Learn why this is important > > > > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: > >> > >> > >> > >> From: Robert Austen > > >> Sent: April 7, 2025 4:33 PM > >> To: freebsd-current@freebsd.org <= freebsd-current@freebsd.org >; freebsd-= net@freebsd.org > > >> Subject: Fw: pfil_default_to_drop > >> > >> > >> From: Robert Austen > >> Sent: April 7, 2025 4:21 PM > >> To: freebsd-current@freebsd.org <= freebsd-current@freebsd.org > > >> Subject: pfil_default_to_drop > >> > >> Hello, > >> I've been playing with FreeBSD and PF to build myself a new firewall, = as Open/FreeBSD + PF seems to be a common starting point. > >> > >> I've noticed a number of people asking questions about PF_DEFAULT_TO_D= ROP and the like, with the observations that it's hard > >> to ensure that packets all default to drop if the rule file(s) for wha= tever reason fail to load. > > > > Hi Robert, > > > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = pf.ko ( via the loader(8), /boot/loader.conf ) ? > > > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = ), you can turn the loader tunable net.pf.default_to_drop to 1, and preload= pf.ko. > > See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5d= e4f9913226801f3073bd . > > > >> > >> After looking thru the online documentation, forums and scripts, I cam= e to the conclusion that it's not a PF problem or IPFW etc > >> or really a problem with any of the filters or scripts, the problem is= at the level of PFIL, the kernel packet filtering code: If no > >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends ever= ything thru to its destination. So my thought > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version o= f PF_DEFAULT_TO_DROP) that drops all the > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loade= d chosen filter (PF or whatever) at any given time the > >> hooks are unhooked. > > > > If no firewalls loaded, then the system should behave as is. I do not t= hink PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > >> > >> [No one filters on local loopback nor the link layer, so I've left tho= se hooks untouched. I suppose one could add them, > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I d= oubt there's much demand for it.] > >> > >> Normally I'm an embedded linux kernel basher. > >> I'm not entirely sure where to send this patch. Most of the threads as= king the above PF questions are closed to changes, > >> so that doesn't seem a good place. Sir Dice seems to be a common answe= rer of questions; I would have sent it to him/her > >> if I could... > >> > >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"... > >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @ne= w folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > >> but I suspect the kernel code in the networking core doesn't change mu= ch from platform to platform, or version to version. > >> > >> But it works, it's pretty simple, pretty small and so just in case it = might be useful, I'm passing it along. > >> > >> thanks! > >> > >> > >> Robert > >> > >> > >> > >> > >> > > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0 --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
"Considering that firewall rules are loaded before interfaces"

I don't believe that's true.

I used rcorder, and played around with things, because I noted that the int= erfaces (esp if static)
came up first, then the forwarding, then pf log, and finally pf was last.&n= bsp;

There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "= ;rdr pass" rules.

Anyways, rather than debating what might work better in situation A vs B, a= nd dictating what
users of freeBSD can or cannot do, why not give options? 

isn't that the whole point of options and conf files?
let sysadmin use whatever option they see fit?

they shouldn't have to write something to get the result they want (or need= ), like I had to..

From: Cy Schubert <Cy.Sc= hubert@cschubert.com>
Sent: April 9, 2025 8:39 AM
To: Zhenlei Huang <zlei@FreeBSD.org>
Cc: Robert Austen <robert.austen@willowglensystems.com>; freeb= sd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@fre= ebsd.org <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBSD.or= g>; Cy Schubert <cy@freebsd.org>
Subject: Re: pfil_default_to_drop
 
[You don't often get email from cy.schubert@cschub= ert.com. Learn why this is important at https://aka.ms/Le= arnAboutSenderIdentification ]

On Wed, 9 Apr 2025 15:48:11 +0800
Zhenlei Huang <zlei@FreeBSD.org> wrote:

> > On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willo= wglensystems.com> wrote:
> >
> > I respectfully disagree.
> >
> > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its io= ctl call to enable itself, ie. to apply any hooks.
> > if pfctl fails, then the hooks are left unhooked, and EVERYTHING = defaults to PASS, which is not what most people would intend using PF_DEFAU= LT_TO_DROP.
>
> Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIO= CSTART ) or netlink command to enable it.
>
> @Kristof Maybe we also want a loader tunable to enable pf(4) on load ?=
>
> >
> > consider this: until pf or ipf or ipfw makes an ioctl to hook the= mselves, the pfil layer in the kernel has no idea what the filter will be,<= br> > > assuming there even is one. thus PF_DEFAULT_TO_DROP  has zer= o effect (and likewise the equivalents from the other filters).
>
> As for ipfw(4), by default it enables filtering on load, unless you di= sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= le` and `net.link.ether.ipfw`.
>
> The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net= .inet.ip.fw.default_to_accept` controls the default behavior to drop or acc= ept.
> See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60e598498df= 6f9e2bd <https://cgit.freebsd.org/src/commit/?id= =3D5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd> .
>
> >
> > as I said, this is because there's no mechanism within PFIL to dr= op by default, which is why I proposed (and am using on my system) the PFIL= _DEFAULT_TO_DROP,
> > because it handles ALL of the 'no filter installed (yet)' cases. = if PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no= effect at all,
> > so it's a simple mechanism for those that want more than PF_DEFAU= LT_TO_DROP can ever provide.

I don't know whether it should default drop or not. In the case of
ipfilter, default drop will drop with or without a log message
depending whether IPFILTER_LOG is defined in the kernel config or in
the module's Makefile -- both are default.

There's something to be said about default block in that there is
absolutely no chance any packets will get through without a rule
permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled
and loaded before any interfaces are brought up so the point is mostly
moot. However in unattended situations there is a better chance you
could be able to remotely log in to fix any brokenness whereas with a
default block you'd have to travel, possibly thousands of kilometres,
to fix any problem. Both scenarios should be considered before making
the decision whether to default block or default open.

Then again, a badly conceived firewall rule, regardless of the default
block setting, can make for a very bad day.

IIRC -- it's been a couple of decades since I used IPFW -- IPFW is
default block while IPFILTER is default open (unless otherwise
configured).

Considering that firewall rules are loaded before interfaces are
brought up -- just run rcorder(8) to see the startup order for yourself
-- this argument is moot.

>
> It appears ipf(4) unconditionally enable filtering on load, and does n= ot have any tunables to control that. CC @Cy who is more familiar with ipf(= 4).

This is not entirely correct.

If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default.
Otherwise by default it will not block by default.

This can be adjusted at runtime in two ways. First through the sysctl
net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass.
The value is not intuitive. It's a hex value representing internal
flags. If the hex value contains 0x2, ipfilter operates in default pass
mode. If the hex value contains 0x1, it operates in default block mode.
It will tell you at boot which mode is default:

stinky# dmesg | grep IP\ Filter
IP Filter: v5.1.2 initialized.  Default =3D pass all, Logging =3D enab= led
IP Filter: v5.1.2 initialized.  Default =3D pass all, Logging =3D enab= led
stinky#

Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T
default_pass to adjust the flag is preferred. Setting the default_block
or ipf_pass is not entirely intuitive.
>
> >
> > thanks!
> > From: Zhenlei Huang <zlei@FreeBSD.org <mailto:zlei@FreeBSD.org>>
> > Sent: April 7, 2025 7:55 PM
> > To: Robert Austen <robert.austen@willowglensystems.com <mailto:robert.austen@wi= llowglensystems.com>>
> > Cc: freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> <freebsd-cu= rrent@freebsd.org <mailto= :freebsd-current@freebsd.org>>; freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.= org> <freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.org>>; Kristof Provost <= ;kp@FreeBSD.org <mailto:kp@FreeBSD.org= >>
> > Subject: Re: pfil_default_to_drop
> >
> > You don't often get email from zlei@freebsd.org <mailto:zlei@freebsd.org>. Learn why this is i= mportant <http= s://aka.ms/LearnAboutSenderIdentification>
> >
> >
> >> On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@w= illowglensystems.com <mailto:robert.austen@willowglensystems.com>> wrote:
> >>
> >>
> >>
> >> From: Robert Austen <robert.austen@willowglensystems.com &= lt;mailto:robert.aus= ten@willowglensystems.com>>
> >> Sent: April 7, 2025 4:33 PM
> >> To: freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> <freebs= d-current@freebsd.org <ma= ilto:freebsd-current@freebsd.org>>; freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.= org> <freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.org>>
> >> Subject: Fw: pfil_default_to_drop
> >>
> >>
> >> From: Robert Austen
> >> Sent: April 7, 2025 4:21 PM
> >> To: freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> <freebs= d-current@freebsd.org <ma= ilto:freebsd-current@freebsd.org>>
> >> Subject: pfil_default_to_drop
> >>
> >> Hello,
> >> I've been playing with FreeBSD and PF to build myself a new f= irewall, as Open/FreeBSD + PF seems to be a common starting point.
> >>
> >> I've noticed a number of people asking questions about PF_DEF= AULT_TO_DROP and the like, with the observations that it's hard
> >> to ensure that packets all default to drop if the rule file(s= ) for whatever reason fail to load.
> >
> > Hi Robert,
> >
> > So why not defining the compile option PF_DEFAULT_TO_DROP, and pr= eload pf.ko ( via the loader(8), /boot/loader.conf ) ?
> >
> > With 13.5, or upcoming 14.3 ( you can also experiment latest stab= le/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, and p= reload pf.ko.
> > See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801= f3073bd <https://cgit.freebsd.org/src/commit/?id= =3Dc531c1d1462c45f7ce5de4f9913226801f3073bd> .
> >
> >>
> >> After looking thru the online documentation, forums and scrip= ts, I came to the conclusion that it's not a PF problem or IPFW etc
> >> or really a problem with any of the filters or scripts, the p= roblem is at the level of PFIL, the kernel packet filtering code: If no
> >> filter is loaded, i.e. if the heads are unhooked, then PFIL s= ends everything thru to its destination. So my thought
> >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL = version of PF_DEFAULT_TO_DROP) that drops all the
> >> IPv4 and IPv6 packets that would otherwise go thru the yet-to= -be-loaded chosen filter (PF or whatever) at any given time the
> >> hooks are  unhooked.
> >
> > If no firewalls loaded, then the system should behave as is. I do= not think PFIL_DEFAULT_TO_DROP is the right way to handle your case.
> >
> >>
> >> [No one filters on local loopback nor the link layer, so I've= left those hooks untouched. I suppose one could add them,
> >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP= , but I doubt there's much demand for it.]
> >>
> >> Normally I'm an embedded linux kernel basher.
> >> I'm not entirely sure where to send this patch. Most of the t= hreads asking the above PF questions are closed to changes,
> >> so that doesn't seem a good place. Sir Dice seems to be a com= mon answerer of questions; I would have sent it to him/her
> >> if I could...
> >>
> >> I'm not a user of GIT, so I'm not sure how to submit a "= GIT formatted patch"...
> >> I've simply diff -rdpNU 5 a copy of the @old folder with a co= py of @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64,=
> >> but I suspect the kernel code in the networking core doesn't = change much from platform to platform, or version to version.
> >>
> >> But it works, it's pretty simple, pretty small and so just in= case it might be useful, I'm passing it along.
> >>
> >> thanks!
> >>
> >>
> >> Robert
> >>
> >>
> >>
> >>
> >> <FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip= >
>
>
>

--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwt= ime.org>    Web:  htt= ps://nwtime.org

            &nb= sp;           e^(i*pi)+1= =3D0
--_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_-- From nobody Wed Apr 9 16:43:25 2025 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 4ZXpfp6252z5s2yc for ; Wed, 09 Apr 2025 16:43:30 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXpfn7464z3tF1 for ; Wed, 09 Apr 2025 16:43:29 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b="hFCd/ctK"; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2a as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2a.google.com with SMTP id ca18e2360f4ac-8616b7ad03bso8221439f.0 for ; Wed, 09 Apr 2025 09:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1744217009; x=1744821809; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SNB6CTKAY3XhkZJa+eZ9kZUe2ROYXKWjkBISk1COs9I=; b=hFCd/ctKzS3bo7ZdrD/d3nXt8qBD4fbLFsZVUXrwn8WkY0dJ9ERS6gxUquGyfDA0bu AaQk9oeWihwaAndigDNFWvWG63PB60mL0TpKJjU4FaQsGIvAiPaRQJ3kt6beYJ2i5eG8 7QzfApgXRbUyRWghtH75s3yL4C2Uwxl08YerB6PMLKEL0HgQVzMT0/oJVZK1njeKoCA8 5Yg6QQ64t8pcFygaxGPXo0pn/UoKZA/rdWzRRzSZhG1nhJ3q2Zb8W+XUT7tvsSKEi7Sy ZjiQWqbW7cW5E3yVr77P+Gyi1xWN3UuFA/HlYLXviba0oALp0OGArgZ4J3Ez1ru+SxS9 4ESg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744217009; x=1744821809; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SNB6CTKAY3XhkZJa+eZ9kZUe2ROYXKWjkBISk1COs9I=; b=r9BGZ2ZHnWvdTeb2B4fncf9THeO8VTbUAledweeU5KI8A1N1F++8FO+p/GUV7j56bw P7WGrvYe6cmO0Nc2lWVsQi4hk+SRFJ0HBff+sAQeekJDN8vSSYb2jfhvlLP2rTpRhOyx k/cV/HZwz+pnjusn+crOd4ql4lCBbjg1TWzIBGdwpXlMFBj+Fm125eTxqsA+W7ZEJKON sVHlsoq4CYvDKYdKWHrqsjJQigUf8pZzZgE4UJXi3ia0OITYc6kXq4zEABsS6N01zmf+ 21kTo5JdXA5DrmafLTqLBp7Cso38mVoD/3Q/UvO0zHvjZjaAmoAd8uRyrRfu9FeL0By8 pUfg== X-Gm-Message-State: AOJu0Yw5LZjkaJMLaQ8S/ookPDpZFnjYLRPeSkYkTwOpPs6c/QyXlrq1 SUhFvOek3saUJxQg5kufBRrl7mQacj4XszwhpHXKISp0/QjGRhjHY2+Jwv2ceLE= X-Gm-Gg: ASbGncunLCjZoOOjmByV9XXnM5IPznzJcwD0WUqn8vVKYIyfhlK08iBLb17U/Bpawa4 XuYJ9rBZoFxbiyiyjegfUqiOQcaWjnh0xIFhH1Vm2h1OwJnd0v6Gv31P+Q7Wuw2zQdJAKkIAgT8 KRxsQpvXtX4qLLzIIAV+hAD6S7iM+ilcfNtVutd/MSul8ttVFVwB46gK9FMC32NyBNnrv21vFWr wElcR+JPfbAMGHw0hnMIyf9oB083LfyWshY96+L3fZ4VPrdpwTO1C/9XskUXKULpgn02ZhbXwea ByniWJe4pLJSwtfbgKt0Avk= X-Google-Smtp-Source: AGHT+IHix857xsPh6mZ29TPSjY1kDzcDwQBEwuZMXHHWhVf5SBO9QydpCLbmM3LKyUg+qtpw4C3+jA== X-Received: by 2002:a05:6602:4c05:b0:85b:3885:159e with SMTP id ca18e2360f4ac-861627bb9afmr327316739f.3.1744217007525; Wed, 09 Apr 2025 09:43:27 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-861656e176csm24851039f.42.2025.04.09.09.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 09:43:26 -0700 (PDT) Date: Wed, 9 Apr 2025 16:43:25 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ggmycmozaswce6z3" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-3.92 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_SHORT(0.18)[0.179]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DMARC_NA(0.00)[hardenedbsd.org]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2a:from] X-Rspamd-Queue-Id: 4ZXpfn7464z3tF1 X-Spamd-Bar: --- --ggmycmozaswce6z3 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Sun, Apr 06, 2025 at 02:52:28PM -0700, Rick Macklem wrote: > On Sat, Apr 5, 2025 at 5:45=E2=80=AFPM Shawn Webb wrote: > > > > On Sat, Apr 05, 2025 at 05:36:07PM -0700, Rick Macklem wrote: > > > On Sat, Apr 5, 2025 at 4:43=E2=80=AFPM Shawn Webb wrote: > > > > > > > > On Sat, Apr 05, 2025 at 04:12:15PM -0700, Rick Macklem wrote: > > > > > On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > > > > > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrot= e: > > > > > > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem = wrote: > > > > > > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Mack= lem wrote: > > > > > > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb= wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick = Macklem wrote: > > > > > > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do = not think it will > > > > > > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate com= mits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to = ZFS itself to support > > > > > > > > > > > > > > named attributes. Is that patch available somew= here? > > > > > > > > > > > > > The ZFS patch is currently in phabricator as D496= 54. > > > > > > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.pa= tch > > > > > > > > > > > > > (this is a smaller diff which can be applied to a= n up-to-date main src > > > > > > > > > > > > > tree easily) > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on= a file on a ZFS > > > > > > > > > > > > dataset with xattr=3Don (which seems to be the defa= ult) returns 0. Am I > > > > > > > > > > > > doing something wrong? > > > > > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtes= t xattrtest > > > > > > > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs li= st /usr/home/shawn > > > > > > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xa= ttr rpool/usr/home > > > > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > > > > rpool/usr/home xattr on default > > > > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > > > > > > No idea. It works for me. You used up-to-date kernel = sources? > > > > > > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnod= e.h.) > > > > > > > > > > > Oh, and one more thing to check. zfs_xattr_compat nee= ds to be non-zero. > > > > > > > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/= zfs/zfs_vnops_os.c. > > > > > > > > > > > It's initialized to 1 and I don't see anything that s= ets it to 0?) > > > > > > > > > > > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xatt= r to on, you need to > > > > > > > > > > > reboot (or at least remount) to get it to take effect. > > > > > > > > > > > (Maybe try setting it to "dir" and then reboot/remoun= t. Maybe there is > > > > > > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr = defaults to > > > > > > > > > > "on" in FreeBSD by default. My src tree is synced up to= FreeBSD commit > > > > > > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in = the ZFS patch > > > > > > > > > > you linked to. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part = of a kernel build? > > > > > > > > > > > (It needs the patched .h files in the kernel sources,= not something in > > > > > > > > > > > /usr/include/sys > > > > > > > > > > > that has not yet been updated.) > > > > > > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS requi= res the sources > > > > > > > > > > > build for older kernels. (Basically #ifdef'd on that = VIRF_NAMEDATTR mentioned > > > > > > > > > > > above.) > > > > > > > > > > > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and r= eport back. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.k= o by doing a "make" in > > > > > > > > > > > the module directory. > > > > > > > > > > > > > > > > > > > > > > You can try the attached trivial patch and see if it = spits out "pathconf ret=3D1" > > > > > > > > > > > on the console. > > > > > > > > > > > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > > > > > > > > > > > Clean rebuild didn't resolve it. However, I made some pro= gress. > > > > > > > > > > > > > > > > > > I created a dataset specifically for this since I can't r= eally unmount > > > > > > > > > my /usr/home dataset, so my example down below is a bit d= ifferent than > > > > > > > > > the previous example I gave. > > > > > > > > > > > > > > > > > > The xattr property is set to "on" for the dataset. Howeve= r, it's not > > > > > > > > > mounted with the xattr property. In order to get it to wo= rk, I had to > > > > > > > > > run the following commands: > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > $ sudo zfs umount rpool/scratch/xattr > > > > > > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch= /xattr > > > > > > > > > $ zfs get xattr rpool/scratch/xattr > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > rpool/scratch/xattr xattr on local > > > > > > > > > $ mount | grep xattr > > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatim= e, nfsv4acls, named attributes) > > > > > > > > > $ mount | grep named > > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatim= e, nfsv4acls, named attributes) > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs pro= perty, > > > > > > > > > otherwise you would see a whole bunch of datasets mounted= with the > > > > > > > > > "named attributes" flag in that last `mount | grep` comma= nd. > > > > > > > > I've looked at this a little more... > > > > > > > > There is a function xattr_changed_cb() that updates the xat= tr property > > > > > > > > information. > > > > > > > > It gets called when "zfs set xattr=3DXX " is d= one or when > > > > > > > > the mount option "xattr" is set. > > > > > > > > > > > > > > > > The question seems to be "Why was the stuff not correctly s= et for your file > > > > > > > > systems, although they show xattr=3Don?" > > > > > > > > > > > > This is indeed what I was inferring. xattr has been set to "on"= since > > > > > > the pool's creation as far as I can tell. Until experimenting w= ith > > > > > > your patch, I didn't really even know the xattr property even e= xisted. > > > > > I was able to reproduce this with a fresh zpool. > > > > > Although it reported "xattr on", that is not really accurate. > > > > > > > > > > I stuck a printf() in here (line#853-861 of > > > > > sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) > > > > > > > > > > /* should either have both of these objects or none */ > > > > > error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, > > > > > &sa_obj); > > > > > if (error !=3D 0) > > > > > return (error); > > > > > > > > > > error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); > > > > > --> The printf here shows that error =3D=3D ENOENT. > > > > > if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) > > > > > zfsvfs->z_xattr_sa =3D B_TRUE; > > > > > > > > > > The printf() of error showed ENOENT. So, "xattr" actually does not > > > > > exist. "zfs get xattr " calls it "on" but that's not= accurate. > > > > > > > > > > As root, I did: > > > > > # zfs set xattr=3Ddir > > > > > - reboot > > > > > > > > > > This makes it work, although the above call still returns ENOENT. > > > > > It looks to me like zfsvfs_init() gets called from zfsvfs_create() > > > > > right at the beginning of zfs_domount(). > > > > > Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_call= backs(), > > > > > which now finds the property (because of the "zfs set xattr=3Ddir= ") > > > > > and registers it via dsl_prop_register(). > > > > > > > > > > I don't know if the above is correct? > > > > > Personally, I would prefer to see "zfs get xattr " r= eply "not set" > > > > > instead of "on". > > > > > > > > > > rick > > > > > > > > > > > > > > > Setting the property makes it work, but only after rebooting > > > > > (a umount/mount would probably have the same effect, I think?). > > > > > > > > So I wonder why neither an unmount/mount nor a reboot causes `mount= | > > > > grep "named attribute"` to fail for me. HardenedBSD doesn't have any > > > > changes to ZFS that would cause that kind of behavior. I have to > > > > unmount, but manually mount with `mount -t zfs -o xattr ...` in ord= er > > > > to access the new feature you wrote. Weird. > > > So, you have done > > > # zfs set xattr=3Ddir > > > followed by a reboot and it still doesn't work? > > > > Correct, even a reboot does not work. > No idea. If you apply the atteched little patch (just printf's) and post > what gets printed out (when a mount that doesn't work is done), > it might help explain it. Turns out this was a big case of PEBCAK. I had misunderstood which value the xattr property should have been set to. After setting it to "dir" and rebooting, the ZFS datasets are now mounted with named attributes support. Thanks for your patience and I apologize for the noise. Now it's time to figure out how best to prevent fdlopen(extattrfd). :-) --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --ggmycmozaswce6z3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmf2o6cACgkQ/y5nonf4 4foHJBAAh3/EpGGRE5f4ifKHlkIk39XAC7LWEHZCKwis1mzcZnRm9IyhqXTjfGMA 8W4wxSvuLhSjPzveekyfN8Kbj+5Ac0fEBIANAJBPC6CDvgb8R8OxCXmWcd3OM0mb r4D/zHqMKvxSJcxjFEjNJ8blmib286XnoSbUxJH2HnK2S+VGp0w+YBmZoKX55gtV gfhPYcjEyzXzWLUyI5DR3NT10vJA3p/QyvybBagUnV7Zkv3Sis+Tofjd6ke5fMgY CmKfDH9OqFmKVtjHy7EKCFST5/PfP10iaSwNpz77n0JmISWOjk9cViRWivwyFfDC 4X+SUDu6ZVcyKGFfv1dwV8b1+OBev3CA+uvmcvEfPFfeJeYM9F1lKIcj3qsgCrjn yNg/jBEFezDJAtryQPqjcsH4+6P01WyfqgttAK+AREvkjU1IIe+Z3pgcQGvDx0cG P47uwfpST92cCbjppNzCNUzryNIxUzd+HeDGF6WQwObI0gsaEiT/IN2OFQqfWi8B mQUtFTGywNWOiKKgS4avxkUPaclLgqMpl79q8UX7TpZoRkmb882m4fUIf4dh/72V vhvl7QaXEoW6xV+NuPYf2YnAzriwOnY+LXHr+Rgcff/edy59Iv11j11EtLzQ4JRS HEKf5mmoEcvdv1NGyCU04WXGwFzkJ8zaMLL1fmmoIPu+yy8DzwM= =QulT -----END PGP SIGNATURE----- --ggmycmozaswce6z3-- From nobody Wed Apr 9 16:44:17 2025 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 4ZXpgw30s2z5s3CK; Wed, 09 Apr 2025 16:44:28 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Received: from YT5PR01CU002.outbound.protection.outlook.com (mail-canadacentralazon11021081.outbound.protection.outlook.com [40.107.192.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXpgv5LQ5z3vCD; Wed, 09 Apr 2025 16:44:27 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s3JKPUPYAgQyWFgmJsqCWyANaQ63SCmbLmUx+4KXv+HFSQPCg9UeSdat8w8tUMLDRuQp/ZguiZknvTJwjaEGnFjtGQeIOoCLerQhYMJgq115mV+zf68znlrSYnlHoBlsYuijyl7bi6MUW8ZjkbBNLjNiZ/W0ooYjO5o9W9lZV09UP1we+MgLEFg0ezEbOuNy+r/oE08p5uXCXchc6lHrMxvrW1Vth11X+xdiv/LWUNE8aXnwq8PQfuwmx94EsTTJdeKNsh+GOFIpR0Dro06ub0MWBEVKwvgr7hXbKgw/MKHTUnUFrEWOJ4wWDkt82Pcao0kem3VL89ZSCFeqaDJQ8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KjxL44mRjYwy39XSbisW0rm3bJJv4eJ9/xA6l5X9rRc=; b=JRQPmv5Y+JGkr6ZyQrL/yC5EjHTkn+8yHbbsG9hJnOmspjUQ+zL7DF0JFNzuVgqufdxNVj0xARkWZITdAgGGxMICniHueFTj3boP6AUrsGYFWJXhq2Tmx2Tmz5nkRXxFruSwiqAXE54TD7ulbnFspQNUtnPfAqRa8dQvoptgv5PIpv1++N8DP6vcxNLGKEIlxHHRrME3c8atPzxFYApq4kZteQRzhj47Tjvoxq8a/DY9+XLBPmrqjkJZ2jLkRzseV0zoj0t0RCxQSdV9sz8g+N2cxJaVfd5rpuWU8KZrt7H0JaYrIdrLB9fcQTc98z5SMcReg2DkdK5/M6+b9O+1Cg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=willowglensystems.com; dmarc=pass action=none header.from=willowglensystems.com; dkim=pass header.d=willowglensystems.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willowglensystems.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KjxL44mRjYwy39XSbisW0rm3bJJv4eJ9/xA6l5X9rRc=; b=m6EmaGOimS06se5v/K5y/TMEQodprywTqVe13sq0i7F7KeoczVqqQ2SAeloyypCoeZds3pn1NXCxmAc5XgHO177CAM86/ABa+w+lrKcDKzseUGgSvyYPrge4PMrYAVPueFmfoScTFDmP8nGY3cfMwr2EDR5iegRIhi2jd1VDIKI= Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c08::23a) by YT2PR01MB8422.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:b1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8606.35; Wed, 9 Apr 2025 16:44:17 +0000 Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d]) by QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d%4]) with mapi id 15.20.8632.021; Wed, 9 Apr 2025 16:44:17 +0000 From: Robert Austen To: Zhenlei Huang CC: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop Thread-Topic: pfil_default_to_drop Thread-Index: AQHbqAfyk4Z18yjsM0yECEK2f5QGrrOYyea/gAAA4zGAADehgIAA+tGKgAD6MICAAJOZqA== Date: Wed, 9 Apr 2025 16:44:17 +0000 Message-ID: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: QB1PPF4C719E46A:EE_|YT2PR01MB8422:EE_ x-ms-office365-filtering-correlation-id: 240c3ff2-81a9-4d24-fcee-08dd7785c501 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018|13003099007|8096899003|7053199007; x-microsoft-antispam-message-info: =?us-ascii?Q?kvLsAKCN9raip0Johxw53FI7HnKkLOep1jJyBTzIEchng/U2Wqu8pV8u0B8p?= =?us-ascii?Q?78LcFU63V8sgwPgsgzKmxaIqV81WXDZSDdvp8cfUyBPSXuAr0DaOC9BFS/vu?= =?us-ascii?Q?lOh0Axp43lAp3HtVCm7Kwoe6wQ50A99xT/c6f8Fv2iHt3CUwan3lzMsmd730?= =?us-ascii?Q?bIhQMVSj6RcBXrzVj52svPTzusd++Pd2IscZXeWJxTG/pUk2IrOFqSrXxiAK?= =?us-ascii?Q?keswKIzd8N1+B7SQ40VJTSlHIqa/YohkkLiHxb1igxZBPSCPxXNw3uXGr+7h?= =?us-ascii?Q?wJQonROH2fKEPaBdP1QZW17RbWowlBqOF+3Zx6+BpFgJdAOnoZ1gLsCcOiFe?= =?us-ascii?Q?ChVl8coiyYYvk3KbP6GAv3wqLSMrXoZho6h3Srn2366OHvT003nDByeYKqSm?= =?us-ascii?Q?kL8FVd8qxLv+2NEBJLsn+oH+fPbrqzPM4AJ5ZiL+XHNi6oMyvFhFUzogMa6h?= =?us-ascii?Q?WC7hnkcwslX/h6gW+0DKCy/3a/aQvEtM/WRSN3mSK/jyXTUMGcFQ4e8naJGu?= =?us-ascii?Q?3kxXz2MT4tWiOv2rL9cSq61ELxhdc6AULvRH4ostkPlOzBCrPHyIgv+vNYMZ?= =?us-ascii?Q?sM16/HKkfJRDrFZm8+1v/LiQVbI2+mqviYF2o2FVj2K0y+3Q0RwqyfKIsbPj?= =?us-ascii?Q?0kOxC2Yggn0KhhUGYeGVrAbYFLt6VWwq3J/JBMmjA+75ynkJWj0koMvhoIwR?= =?us-ascii?Q?KJyL4MZExBmwFMid/5qh27Yb8DOquVB/Rmr9KX4vFX2TCnW9rxWEQZWdZnL8?= =?us-ascii?Q?hkzmxElJDGQ//4JA9gYkayahBoNIjYwHhUVqVdkCcIh3bImcGPe8s7LjPmKX?= =?us-ascii?Q?gvHObuZxkYjDUQzbqcEUKCDLoQSwOs4X0RYcGaWOEHdzpJYHuGFBdE2nJReB?= =?us-ascii?Q?RojkZkLe8m0wggZD8ipZf4Yw0MuDxWdwf3epsRJll3YeNFNb6OB/KvvREacu?= =?us-ascii?Q?Agqlab9gJApgVWZv6Vr2YCUV8Y1Tp4vDsz/zbJ/QAabZDWmnWSqmo7oAcCeb?= =?us-ascii?Q?4tjhAO/uu1ZboXsqknlAGGkpKfhcSSctPRj2E223tmCGZkSPHsIGifXvtwHv?= =?us-ascii?Q?L89+Ikvp79/OH/5yt8ELT/Ss56WUFPyFpzXt7KtBXFxdDphJCBghStzfz0Dg?= =?us-ascii?Q?L7TMzAsc7oxgWvs9uDe1egOjcEsMLNx25vWF3X4gkx3jPENQLHx2u1HVH0ne?= =?us-ascii?Q?s4ESO5c0olHhjLdEWpyNFLLRVWUh45HJ7YKVCpfwCfhePtyyabhdWvXRJWif?= =?us-ascii?Q?QTdEG76YEUG8g748gxlWChH1vdV0mh+T5/ndGMVT5LBLsmat29XFlr1GMalb?= =?us-ascii?Q?XRqYrMR1iLDjGEJQ4gU1ReXvfo3l+YYC1Ygm4EOcWXxoXCi0B2oPrIE9MhUt?= =?us-ascii?Q?X5rVW5vslnh74CAzyMtUm8tJsbp+DWkna4woU+eDdz/vIJyfbR9MUCxtykaV?= =?us-ascii?Q?1wURtQEGGz8uiUkibSS4zww/4SZ5DKNNb7r6E9xdf7zZSGqoXwK5vx80jCDG?= =?us-ascii?Q?IwSWcwkx401RKtU=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018)(13003099007)(8096899003)(7053199007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?t/3BQ7Te4hkQPiIiCWfoHGk1YZwrfW70N3Y4uWvvKPKhnHDAbcfClc03HdRu?= =?us-ascii?Q?NXiRfJb9DlqOySKpQZ+X+MDbicUBNlRJ5omGaiKoIolAxfTeP7lIx+9jEVFI?= =?us-ascii?Q?KabhU31MpgxGYu3cya0Ht2/syQpcVIrMEG5sf97sClyYNyddA7VowfdAeZ14?= =?us-ascii?Q?/25yWJEqPHdY6fvwABwIx2b2cUecwlrQs1QABcf1CZXTHLnjv4FBaCtXLPNX?= =?us-ascii?Q?YIpX2en4zp2a0VzJawVMFdEvfwiBuuBR0zcW0Mj0wx3HetT/EKhTM/ZYSYqx?= =?us-ascii?Q?SvpsbrfxuHS0ONsjUeqs0WmX0wp6SwFPmxI1k0okUp0FfIBBDy2rSKy8T6Y9?= =?us-ascii?Q?jzJGeWTAUGTbJqLX5ju7DbU+jDhGr7BPSVAmGdMUVR9487yaangUa3F+2ihl?= =?us-ascii?Q?KvFwLw06iXlb1HpKx1JsNJ1YpePUJqz6dLRTCX7Akzw/Bn0zPbuVmazZNLiu?= =?us-ascii?Q?/25XyeCd94dbYXSl5ONtGu9YgN+k4jgCTDlTanYMxIH38e7EvShOVP7gV0D/?= =?us-ascii?Q?zqrJTCIRIvo4HVsE3Qgvpl/prB8v6oqnAlSoFR0x23nT1t6M3U0Jlbj3IRPg?= =?us-ascii?Q?+eGENJgTWWKf5W1wL6t1s2iYfT3nIO1QWbI27QiP3s2kQBBisRt6/Xr8jRhv?= =?us-ascii?Q?8UTv6LerJ+J3ahTrnwqqThdO1J8nD3uQuhJG+YrlTk4VujbH297Ulu29U4CO?= =?us-ascii?Q?HcyPfQaRt1xiiJOv3ZOOrQMJcIfo9+DwQ9ZwlN1PB5xaWtFZPqyXkT0cYP8D?= =?us-ascii?Q?COQ2tPKpWbEYqupxSvz5Ty228WVADkzW9WaCLY2fqtP9TfmZtD3j2DD8zHUj?= =?us-ascii?Q?v28qptTMIToz/8mg3dwyJJbUoWvJHtLHw8HOPNhGUje928TB03kpwHLrvwpk?= =?us-ascii?Q?8T5f8V1sR30wXcVjfCIEfrr1haYgQl/uEC0PAtaqdsDxb5MO2CtImz1gHvAA?= =?us-ascii?Q?n972VZ/wmzcwbzQIrbGADexQgcLpDcVnB+0fM6Wz0D8UwP8X3OP2gJ7x7IAD?= =?us-ascii?Q?zsn6owMf7sxOKbXoOkWN+bp5OufvS/z9/la6j0XNK22Q+p0XI+X1btYttLbT?= =?us-ascii?Q?APjTcvVUs0cgL5aVrM0pCuVz+ZuQ6simj1PjdXLoRp77lWK4rFb9cDBOYSDP?= =?us-ascii?Q?JVyPGIGt6iO49PrlhkAykeNap6PhchI/U4Ge1/Fjl4inITL9X4UfrQPYBLYE?= =?us-ascii?Q?1LOjuZkUkefDOwayY6rAdrS4jdfAzCQHTQ+l1qaKL5q6kWD7k3rcb9SwiYym?= =?us-ascii?Q?8wmy/GXB2WxAWNXMJsCcJ5DhM//V/Hu5f+I4G9KNyQ7+CTiExEQcu53/dt7Q?= =?us-ascii?Q?YIzVvFdUQc/vpy2R6GuYS3GClXsll4K+skRgWO+Bh/M6B3OHs9g16UY4C5Jz?= =?us-ascii?Q?SMQ782brYBRKcOHTGXu3OFonh+xWfCufHDLNsYC/QhfZz8Iq1TTPb4gYV3cW?= =?us-ascii?Q?XSakJLeARujVmDZt5Ln8jSzi6tHELRWOc2GIV12AF0uQ9fOXRJcxeaSHciLX?= =?us-ascii?Q?un7B52/D2pPyFyK6zKNcwoi91/93X4F2hRNzV8yMlOqWMn127NJjv9Zd/oXh?= =?us-ascii?Q?Ho5VA6KbFuE6Om2YKtnAlKKfyR6yH/A61MWy9BVurpahMhMhpfT1pnFzuc6i?= =?us-ascii?Q?tA4m0+lda6L5mGJZqee2Up0=3D?= Content-Type: multipart/alternative; boundary="_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_" 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 X-OriginatorOrg: willowglensystems.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 240c3ff2-81a9-4d24-fcee-08dd7785c501 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2025 16:44:17.5653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c7bca0fa-9d0c-460d-8770-da688c84194e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U8cw9U3udcujxv/gcFMkttEAbQsEcn0XUMq592HRIc8gtlwjq+TCFmpunoQIa7rbgrIEi4uDZG1TCA8jxpBQfYnC07YLKydLqHVtYUaa8wwk007Cw/DR+VcvcQu6DA6G X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB8422 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US] X-Rspamd-Queue-Id: 4ZXpgv5LQ5z3vCD X-Spamd-Bar: ---- --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Maybe we also want a loader tunable to enable pf(4) on load" Seems a complicated way to do a simple thing. imho. Did you happen to look at my tiny patch? There are already a bunch of macros (PFIL_HOOKED_IN, PFIL_HOOKED_OUT) defi= ned depending on the inclusion of INET v4 or 6. I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the HOOK= ED_ one, or FALSE when INET v4 or 6 is excluded or if PFIL_DEFAULT_TO_DROP isn't defined. Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= calling the filter hook, I just inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = 'goto passin/out' for the 7 occurances in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= d) and the 4 in the NETINET6 code (same as netinet4 plus ip6_foward). easy peasy. I spend 10x more time messing with the kernel Makefile + CONF structure tha= n with my changes lol. ________________________________ From: Zhenlei Huang Sent: April 9, 2025 1:48 AM To: Robert Austen Cc: freebsd-current@freebsd.org ; freebsd-net@= freebsd.org ; Kristof Provost ; Cy= Schubert Subject: Re: pfil_default_to_drop You don't often get email from zlei@freebsd.org. Learn why this is importan= t On Apr 9, 2025, at 1:01 AM, Robert Austen > wrote: I respectfully disagree. PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks. if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= . Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCSTAR= T ) or netlink command to enable it. @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= he pfil layer in the kernel has no idea what the filter will be, assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and l= ikewise the equivalents from the other filters). As for ipfw(4), by default it enables filtering on load, unless you disable= it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable` a= nd `net.link.ether.ipfw`. The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.inet= .ip.fw.default_to_accept` controls the default behavior to drop or accept. See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60= e598498df6f9e2bd . as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP, because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= all, so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= can ever provide. It appears ipf(4) unconditionally enable filtering on load, and does not ha= ve any tunables to control that. CC @Cy who is more familiar with ipf(4). thanks! ________________________________ From: Zhenlei Huang > Sent: April 7, 2025 7:55 PM To: Robert Austen > Cc: freebsd-current@freebsd.org >; freebsd-net@fre= ebsd.org >; Kristof Provost > Subject: Re: pfil_default_to_drop You don't often get email from zlei@freebsd.org. L= earn why this is important On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: ________________________________ From: Robert Austen > Sent: April 7, 2025 4:33 PM To: freebsd-current@freebsd.org >; freebsd-net@fre= ebsd.org > Subject: Fw: pfil_default_to_drop ________________________________ From: Robert Austen Sent: April 7, 2025 4:21 PM To: freebsd-current@freebsd.org > Subject: pfil_default_to_drop Hello, I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point. I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. Hi Robert, So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.k= o ( via the loader(8), /boot/loader.conf ) ? With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), y= ou can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.= ko. See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9= 913226801f3073bd . After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no filter is loaded, i.e. if the heads are unhooked, then PFIL sends everythin= g thru to its destination. So my thought was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the hooks are unhooked. If no firewalls loaded, then the system should behave as is. I do not think= PFIL_DEFAULT_TO_DROP is the right way to handle your case. [No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them, maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.] Normally I'm an embedded linux kernel basher. I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes, so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her if I could... I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch= "... I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64, but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version. But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along. thanks! Robert --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
"Maybe we also want a loader tunable to enable pf(4) on load"

Seems a complicated way to do a simple thing. imho.

Did you happen to look at my tiny patch?
There are already a bunch of macros  (PFIL_HOOKED_IN, PFIL_HOOKED_OUT)= defined depending on the inclusion of INET v4 or 6.
I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the H= OOKED_ one, or FALSE when INET v4 or 6 is excluded 
or if PFIL_DEFAULT_TO_DROP isn't defined. 

Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= calling the filter hook, I just
inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = 'goto passin/out' for the 7 occurances
in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= d) and the 4 in the NETINET6 code (same as netinet4 plus  ip6_foward).=

easy peasy.
I spend 10x more time messing with the kernel Makefile + CONF structure tha= n with my changes lol.


From: Zhenlei Huang <zle= i@FreeBSD.org>
Sent: April 9, 2025 1:48 AM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>;= freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost &= lt;kp@FreeBSD.org>; Cy Schubert <cy@freebsd.org>
Subject: Re: pfil_default_to_drop
 
You don't often get email from zlei@freebsd.org. Learn why this is important


On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willowgl= ensystems.com> wrote:

I respectfully disagree.

PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks.
if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= .

Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl (&nbs= p;DIOCSTART ) or netlink command to enable it.

@Kristof Maybe we also want a loader tunable to enable pf(4) on load ?=


consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= he pfil layer in the kernel has no idea what the filter will be,
assuming there even is one. thus PF_DEFAULT_TO_DROP  has zero effect (= and likewise the equivalents from the other filters).

As for ipfw(4), by default it enables filtering on load, unless you di= sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= le` and `net.link.ether.ipfw`.

The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable= `net.inet.ip.fw.default_to_accept` controls the default behavior to drop o= r accept.


as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP,
because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= all,
so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= can ever provide.

It appears ipf(4) unconditionally enable filtering on load, and does n= ot have any tunables to control that. CC @Cy who is more familiar with ipf(= 4).


thanks!
From: Zhe= nlei Huang <zlei@FreeBSD.= org>
Sent: April 7, 2025 7:55 PM
To: R= obert Austen <robert.austen@willowglensystems.com>
Cc: <= a href=3D"mailto:freebsd-current@freebsd.org" class=3D"">freebsd-current@fr= eebsd.org <freebsd-current@freebs= d.org>; freebsd-net@freebsd.org<= span class=3D"x_Apple-converted-space"> <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBS= D.org>
Subject: Re: pfil_default_to_drop
 
You don't often get email from = ;zlei@freebsd.org= . Learn why this is important


On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@willowgl= ensystems.com> wrote:




<= b class=3D"">From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point.

I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard
to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. 

Hi Robert,

So why not defining the compile option PF_DEFAULT_TO_D= ROP, and preload pf.ko ( via the loader(8)= , /boot/loader.conf ) ?

With 13.5, or upcoming 14.3 ( you can also=  experiment latest stable/14 ), you can turn the loader tu= nable net.pf.default_to_drop to 1, and preload pf.ko.
See also https://cgit.f= reebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801f3073bd&nb= sp;.


After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc
or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL sends everything&n= bsp;thru to its destination. So my thought 
was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the
IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the 
hooks are  unhooked. 

If no firewalls loaded, then the system should behave as is= . I do not think PFIL_DEFAULT_TO_DROP is the right way to handle your = case.


[No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them,
maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.]

Normally I'm an embedded linux kernel basher.
I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes,
so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her 
if I could...

I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"...
I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version.

But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along.

thanks!


Robert




<Fr= eeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip>



--_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_-- From nobody Wed Apr 9 16:50:24 2025 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 4ZXppr5F2Xz5s3HK; Wed, 09 Apr 2025 16:50:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXppr0SCKz3xwM; Wed, 09 Apr 2025 16:50:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id 2VE7ukkCS5Mqy2Yd8ux14M; Wed, 09 Apr 2025 16:50:26 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2Yd6u15p3QwcX2Yd7uzCS7; Wed, 09 Apr 2025 16:50:26 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=DaW0qetW c=1 sm=1 tr=0 ts=67f6a552 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=_EeEMxcBAAAA:8 a=UqCG9HQmAAAA:8 a=YxBL1-UpAAAA:8 a=HIpOd3htAAAA:8 a=kUCByv9wAAAA:8 a=HewfmIXYAAAA:8 a=jiAvY12EAAAA:8 a=NMM7OKYrAAAA:8 a=wdBCWTejAAAA:8 a=7deo3vJLAAAA:8 a=SxfSXtOaAAAA:8 a=0VOg8hKvAAAA:8 a=EG9UZMYjAAAA:8 a=Ds8RGfT2AAAA:8 a=E2BN4GkIBzMGMZPVlf4A:9 a=VPyG4jiE2XtzpiXk:21 a=CjuIK1q_8ugA:10 a=iss7NtdUcmcA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=kmlo3kNSEkcePd_NiW6t:22 a=bu_5hG6eGWxBxPYBRUjp:22 a=viMdiLGMexgI2yRc-QGl:22 a=vH9twmSOgBVYSauSXlDl:22 a=isrg6BwTYk6I_F0B0DtW:22 a=E6RPhFkzuBHyj9NHzc04:22 a=N19YUjM5w2xS2h45dEdy:22 a=WO70gR-9rc0EB5-JkeQN:22 a=I-efbNKAaAt4Mg394dr-:22 a=amkjWIeD4s3-_WS3cuQ1:22 a=0afPCejbyZHll-xH3H2j:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 130C7E5; Wed, 09 Apr 2025 09:50:24 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 0C165304; Wed, 09 Apr 2025 09:50:24 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Robert Austen cc: Cy Schubert , Zhenlei Huang , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop In-reply-to: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> <20250409073906.43e4282e@slippy> Comments: In-reply-to Robert Austen message dated "Wed, 09 Apr 2025 16:29:16 -0000." 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 Date: Wed, 09 Apr 2025 09:50:24 -0700 Message-Id: <20250409165024.0C165304@slippy.cwsent.com> X-CMAE-Envelope: MS4xfDC7iwedH6RyvdvsCpiZ0BWPvdsQEjXjDBqGnD8P8NgIvXxpKH/q584fG5w6E9eNsy2GlwNplFEzxIQsEe2j6RIlnfHX3uGNqTCoWxpThpPjyqPJrjqB RmQlWFVA5vrByWNitHGbwgVR00cnBV6bv+9QuDG/mEKvYkZWjX8PiyQ2Dad3vKLdbGuiF63Ob7hrlDN9xRc5dUqZA3lifb7hdAW+fGnjm3WfhK+pxV5kKzqn hsWXthsac82aoFRvKOYojgppTeZxONfiOQt71dYkSnNhrwzcstOsPNcYUTrh3Sb0dtTVaukSiW9vUFRi1Fa138F3pJiwwRDcGtsXZJMbv7a/pUA0d0srLl7X eMMdBhEGseFE43Ygar0rwObXcANZoA== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXppr0SCKz3xwM X-Spamd-Bar: ---- In message , Robert Austen writes: > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > "Considering that firewall rules are loaded before interfaces" > > I don't believe that's true. > > I used rcorder, and played around with things, because I noted that the int= > erfaces (esp if static) > came up first, then the forwarding, then pf log, and finally pf was last. Interfaces are started by the netif rc script. I use ipfilter here. netif is started after ipfilter. I had assumed all were the same but apparently not. slippy$ rcorder /etc/rc.d/* | egrep 'ipfilter|netif|pf|ipfw' /etc/rc.d/ipfilter /etc/rc.d/ipfs /etc/rc.d/netif /etc/rc.d/pflog /etc/rc.d/pfsync /etc/rc.d/ipfw /etc/rc.d/ipfw_netflow /etc/rc.d/pf slippy$ We should probably look at moving netif after pf's start. > > There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "rdr = > pass" rules. > > Anyways, rather than debating what might work better in situation A vs B, a= > nd dictating what > users of freeBSD can or cannot do, why not give options? > > isn't that the whole point of options and conf files? > let sysadmin use whatever option they see fit? Agreed. There should always be options. But, what should the default be? Personally, I don't care what the default is. I will set my own options. But most people don't configure their systems as much. Most use the defaults. What works for most people? If default block, then lets do that. > > they shouldn't have to write something to get the result they want (or need= > ), like I had to.. Give people the default and let them change it. I think default block might be preferable. It avoids most people shooting themselves in the foot by not reviewing and changing the default if necessary. Consider most consumers don't change the passwords for their network appliances. Professionals I've worked with do but I'm sure there are many companies where defaults are not reviewed. What offers the average end-user the best protection? Also, what avoids a POLA violation. Balance these two and you will have your answer. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 > > ________________________________ > From: Cy Schubert > Sent: April 9, 2025 8:39 AM > To: Zhenlei Huang > Cc: Robert Austen ; freebsd-current@fr= > eebsd.org ; freebsd-net@freebsd.org et@freebsd.org>; Kristof Provost ; Cy Schubert org> > Subject: Re: pfil_default_to_drop > > [You don't often get email from cy.schubert@cschubert.com. Learn why this i= > s important at https://aka.ms/LearnAboutSenderIdentification ] > > On Wed, 9 Apr 2025 15:48:11 +0800 > Zhenlei Huang wrote: > > > > On Apr 9, 2025, at 1:01 AM, Robert Austen ems.com> wrote: > > > > > > I respectfully disagree. > > > > > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl ca= > ll to enable itself, ie. to apply any hooks. > > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaul= > ts to PASS, which is not what most people would intend using PF_DEFAULT_TO_= > DROP. > > > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCST= > ART ) or netlink command to enable it. > > > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > > > > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselve= > s, the pfil layer in the kernel has no idea what the filter will be, > > > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (a= > nd likewise the equivalents from the other filters). > > > > As for ipfw(4), by default it enables filtering on load, unless you disab= > le it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable`= > and `net.link.ether.ipfw`. > > > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.in= > et.ip.fw.default_to_accept` controls the default behavior to drop or accept= > . > > See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff= > 60e598498df6f9e2bd bbc7fdcff60e598498df6f9e2bd> . > > > > > > > > as I said, this is because there's no mechanism within PFIL to drop by = > default, which is why I proposed (and am using on my system) the PFIL_DEFAU= > LT_TO_DROP, > > > because it handles ALL of the 'no filter installed (yet)' cases. if PFI= > L_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no effec= > t at all, > > > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_= > DROP can ever provide. > > I don't know whether it should default drop or not. In the case of > ipfilter, default drop will drop with or without a log message > depending whether IPFILTER_LOG is defined in the kernel config or in > the module's Makefile -- both are default. > > There's something to be said about default block in that there is > absolutely no chance any packets will get through without a rule > permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled > and loaded before any interfaces are brought up so the point is mostly > moot. However in unattended situations there is a better chance you > could be able to remotely log in to fix any brokenness whereas with a > default block you'd have to travel, possibly thousands of kilometres, > to fix any problem. Both scenarios should be considered before making > the decision whether to default block or default open. > > Then again, a badly conceived firewall rule, regardless of the default > block setting, can make for a very bad day. > > IIRC -- it's been a couple of decades since I used IPFW -- IPFW is > default block while IPFILTER is default open (unless otherwise > configured). > > Considering that firewall rules are loaded before interfaces are > brought up -- just run rcorder(8) to see the startup order for yourself > -- this argument is moot. > > > > > It appears ipf(4) unconditionally enable filtering on load, and does not = > have any tunables to control that. CC @Cy who is more familiar with ipf(4). > > This is not entirely correct. > > If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default. > Otherwise by default it will not block by default. > > This can be adjusted at runtime in two ways. First through the sysctl > net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass. > The value is not intuitive. It's a hex value representing internal > flags. If the hex value contains 0x2, ipfilter operates in default pass > mode. If the hex value contains 0x1, it operates in default block mode. > It will tell you at boot which mode is default: > > stinky# dmesg | grep IP\ Filter > IP Filter: v5.1.2 initialized. Default =3D pass all, Logging =3D enabled > IP Filter: v5.1.2 initialized. Default =3D pass all, Logging =3D enabled > stinky# > > Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T > default_pass to adjust the flag is preferred. Setting the default_block > or ipf_pass is not entirely intuitive. > > > > > > > > thanks! > > > From: Zhenlei Huang > > > > Sent: April 7, 2025 7:55 PM > > > To: Robert Austen usten@willowglensystems.com>> > > > Cc: freebsd-current@freebsd.org reebsd-current@freebsd.org >; freebsd-n= > et@freebsd.org ailto:freebsd-net@freebsd.org>>; Kristof Provost @FreeBSD.org>> > > > Subject: Re: pfil_default_to_drop > > > > > > You don't often get email from zlei@freebsd.org g>. Learn why this is important ion> > > > > > > > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen tems.com > wrote: > > >> > > >> > > >> > > >> From: Robert Austen t.austen@willowglensystems.com>> > > >> Sent: April 7, 2025 4:33 PM > > >> To: freebsd-current@freebsd.org <= > freebsd-current@freebsd.org >; freebsd-= > net@freebsd.org mailto:freebsd-net@freebsd.org>> > > >> Subject: Fw: pfil_default_to_drop > > >> > > >> > > >> From: Robert Austen > > >> Sent: April 7, 2025 4:21 PM > > >> To: freebsd-current@freebsd.org <= > freebsd-current@freebsd.org > > > >> Subject: pfil_default_to_drop > > >> > > >> Hello, > > >> I've been playing with FreeBSD and PF to build myself a new firewall, = > as Open/FreeBSD + PF seems to be a common starting point. > > >> > > >> I've noticed a number of people asking questions about PF_DEFAULT_TO_D= > ROP and the like, with the observations that it's hard > > >> to ensure that packets all default to drop if the rule file(s) for wha= > tever reason fail to load. > > > > > > Hi Robert, > > > > > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = > pf.ko ( via the loader(8), /boot/loader.conf ) ? > > > > > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = > ), you can turn the loader tunable net.pf.default_to_drop to 1, and preload= > pf.ko. > > > See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5d= > e4f9913226801f3073bd c45f7ce5de4f9913226801f3073bd> . > > > > > >> > > >> After looking thru the online documentation, forums and scripts, I cam= > e to the conclusion that it's not a PF problem or IPFW etc > > >> or really a problem with any of the filters or scripts, the problem is= > at the level of PFIL, the kernel packet filtering code: If no > > >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends ever= > ything thru to its destination. So my thought > > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version o= > f PF_DEFAULT_TO_DROP) that drops all the > > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loade= > d chosen filter (PF or whatever) at any given time the > > >> hooks are unhooked. > > > > > > If no firewalls loaded, then the system should behave as is. I do not t= > hink PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > > > >> > > >> [No one filters on local loopback nor the link layer, so I've left tho= > se hooks untouched. I suppose one could add them, > > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I d= > oubt there's much demand for it.] > > >> > > >> Normally I'm an embedded linux kernel basher. > > >> I'm not entirely sure where to send this patch. Most of the threads as= > king the above PF questions are closed to changes, > > >> so that doesn't seem a good place. Sir Dice seems to be a common answe= > rer of questions; I would have sent it to him/her > > >> if I could... > > >> > > >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = > patch"... > > >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @ne= > w folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > > >> but I suspect the kernel code in the networking core doesn't change mu= > ch from platform to platform, or version to version. > > >> > > >> But it works, it's pretty simple, pretty small and so just in case it = > might be useful, I'm passing it along. > > >> > > >> thanks! > > >> > > >> > > >> Robert > > >> > > >> > > >> > > >> > > >> > > > > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > > > > >
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; color: rgb(0, 0, 0= > );"> > " t;">Considering that firewall rules are loaded before interfaces" n>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > I don't believe that's true.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > I used rcorder, and played around with things, because I noted that the int= > erfaces (esp if static)
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > came up first, then the forwarding, then pf log, and finally pf was last.&n= > bsp;
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "= > ;rdr pass" rules.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > Anyways, rather than debating what might work better in situation A vs B, a= > nd dictating what
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > users of freeBSD can or cannot do, why not give options? 
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > isn't that the whole point of options and conf files?
>
margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= > alibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"> > let sysadmin use whatever option they see fit?
>
margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= > alibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > they shouldn't have to write something to get the result they want (or need= > ), like I had to..
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
>
>
yle=3D"font-size:11pt" color=3D"#000000">From: Cy Schubert <Cy.Sc= > hubert@cschubert.com>
> Sent: April 9, 2025 8:39 AM
> To: Zhenlei Huang <zlei@FreeBSD.org>
> Cc: Robert Austen <robert.austen@willowglensystems.com>; freeb= > sd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@fre= > ebsd.org <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBSD.or= > g>; Cy Schubert <cy@freebsd.org>
> Subject: Re: pfil_default_to_drop >
 
>
>
"> >
[You don't often get email from cy.schubert@cschub= > ert.com. Learn why this is important at > https://aka.ms/Le= > arnAboutSenderIdentification ]
>
> On Wed, 9 Apr 2025 15:48:11 +0800
> Zhenlei Huang <zlei@FreeBSD.org> wrote:
>
> > > On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willo= > wglensystems.com> wrote:
> > >
> > > I respectfully disagree.
> > >
> > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its io= > ctl call to enable itself, ie. to apply any hooks.
> > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING = > defaults to PASS, which is not what most people would intend using PF_DEFAU= > LT_TO_DROP.
> >
> > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIO= > CSTART ) or netlink command to enable it.
> >
> > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ?= >
> >
> > >
> > > consider this: until pf or ipf or ipfw makes an ioctl to hook the= > mselves, the pfil layer in the kernel has no idea what the filter will be,<= > br> > > > assuming there even is one. thus PF_DEFAULT_TO_DROP  has zer= > o effect (and likewise the equivalents from the other filters).
> >
> > As for ipfw(4), by default it enables filtering on load, unless you di= > sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= > le` and `net.link.ether.ipfw`.
> >
> > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net= > .inet.ip.fw.default_to_accept` controls the default behavior to drop or acc= > ept.
> > See also 4db5ebbc7fdcff60e598498df6f9e2bd"> > https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60e598498df= > 6f9e2bd < f94db5ebbc7fdcff60e598498df6f9e2bd">https://cgit.freebsd.org/src/commit/?id= > =3D5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd> > .
> >
> > >
> > > as I said, this is because there's no mechanism within PFIL to dr= > op by default, which is why I proposed (and am using on my system) the PFIL= > _DEFAULT_TO_DROP,
> > > because it handles ALL of the 'no filter installed (yet)' cases. = > if PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no= > effect at all,
> > > so it's a simple mechanism for those that want more than PF_DEFAU= > LT_TO_DROP can ever provide.
>
> I don't know whether it should default drop or not. In the case of
> ipfilter, default drop will drop with or without a log message
> depending whether IPFILTER_LOG is defined in the kernel config or in
> the module's Makefile -- both are default.
>
> There's something to be said about default block in that there is
> absolutely no chance any packets will get through without a rule
> permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled
> and loaded before any interfaces are brought up so the point is mostly
> moot. However in unattended situations there is a better chance you
> could be able to remotely log in to fix any brokenness whereas with a
> default block you'd have to travel, possibly thousands of kilometres,
> to fix any problem. Both scenarios should be considered before making
> the decision whether to default block or default open.
>
> Then again, a badly conceived firewall rule, regardless of the default
> block setting, can make for a very bad day.
>
> IIRC -- it's been a couple of decades since I used IPFW -- IPFW is
> default block while IPFILTER is default open (unless otherwise
> configured).
>
> Considering that firewall rules are loaded before interfaces are
> brought up -- just run rcorder(8) to see the startup order for yourself
> -- this argument is moot.
>
> >
> > It appears ipf(4) unconditionally enable filtering on load, and does n= > ot have any tunables to control that. CC @Cy who is more familiar with ipf(= > 4).
>
> This is not entirely correct.
>
> If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default.
> Otherwise by default it will not block by default.
>
> This can be adjusted at runtime in two ways. First through the sysctl
> net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass.
> The value is not intuitive. It's a hex value representing internal
> flags. If the hex value contains 0x2, ipfilter operates in default pass
> mode. If the hex value contains 0x1, it operates in default block mode.
> It will tell you at boot which mode is default:
>
> stinky# dmesg | grep IP\ Filter
> IP Filter: v5.1.2 initialized.  Default =3D pass all, Logging =3D enab= > led
> IP Filter: v5.1.2 initialized.  Default =3D pass all, Logging =3D enab= > led
> stinky#
>
> Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T
> default_pass to adjust the flag is preferred. Setting the default_block
> or ipf_pass is not entirely intuitive.
> >
> > >
> > > thanks!
> > > From: Zhenlei Huang <zlei@FreeBSD.org < ei@FreeBSD.org">mailto:zlei@FreeBSD.org>>
> > > Sent: April 7, 2025 7:55 PM
> > > To: Robert Austen <robert.austen@willowglensystems.com < href=3D"mailto:robert.austen@willowglensystems.com">mailto:robert.austen@wi= > llowglensystems.com>>
> > > Cc: freebsd-current@freebsd.org < rent@freebsd.org">mailto:freebsd-current@freebsd.org> <freebsd-cu= > rrent@freebsd.org <mailto= > :freebsd-current@freebsd.org>>; freebsd-net@freebsd.org > <mailto:freebsd-net@freebsd.= > org> <freebsd-net@freebsd.org < reebsd.org">mailto:freebsd-net@freebsd.org>>; Kristof Provost <= > ;kp@FreeBSD.org <mailto:kp@FreeBSD.org= > >>
> > > Subject: Re: pfil_default_to_drop
> > >
> > > You don't often get email from zlei@freebsd.org < ilto:zlei@freebsd.org">mailto:zlei@freebsd.org>. Learn why this is i= > mportant <http= > s://aka.ms/LearnAboutSenderIdentification>
> > >
> > >
> > >> On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@w= > illowglensystems.com < com">mailto:robert.austen@willowglensystems.com>> wrote:
> > >>
> > >>
> > >>
> > >> From: Robert Austen <robert.austen@willowglensystems.com &= > lt;mailto:robert.aus= > ten@willowglensystems.com>>
> > >> Sent: April 7, 2025 4:33 PM
> > >> To: freebsd-current@freebsd.org < -current@freebsd.org">mailto:freebsd-current@freebsd.org> <freebs= > d-current@freebsd.org <ma= > ilto:freebsd-current@freebsd.org>>; freebsd-net@freebsd.org > <mailto:freebsd-net@freebsd.= > org> <freebsd-net@freebsd.org < reebsd.org">mailto:freebsd-net@freebsd.org>>
> > >> Subject: Fw: pfil_default_to_drop
> > >>
> > >>
> > >> From: Robert Austen
> > >> Sent: April 7, 2025 4:21 PM
> > >> To: freebsd-current@freebsd.org < -current@freebsd.org">mailto:freebsd-current@freebsd.org> <freebs= > d-current@freebsd.org <ma= > ilto:freebsd-current@freebsd.org>>
> > >> Subject: pfil_default_to_drop
> > >>
> > >> Hello,
> > >> I've been playing with FreeBSD and PF to build myself a new f= > irewall, as Open/FreeBSD + PF seems to be a common starting point.
> > >>
> > >> I've noticed a number of people asking questions about PF_DEF= > AULT_TO_DROP and the like, with the observations that it's hard
> > >> to ensure that packets all default to drop if the rule file(s= > ) for whatever reason fail to load.
> > >
> > > Hi Robert,
> > >
> > > So why not defining the compile option PF_DEFAULT_TO_DROP, and pr= > eload pf.ko ( via the loader(8), /boot/loader.conf ) ?
> > >
> > > With 13.5, or upcoming 14.3 ( you can also experiment latest stab= > le/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, and p= > reload pf.ko.
> > > See also 1c1d1462c45f7ce5de4f9913226801f3073bd"> > https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801= > f3073bd < d1462c45f7ce5de4f9913226801f3073bd">https://cgit.freebsd.org/src/commit/?id= > =3Dc531c1d1462c45f7ce5de4f9913226801f3073bd> > .
> > >
> > >>
> > >> After looking thru the online documentation, forums and scrip= > ts, I came to the conclusion that it's not a PF problem or IPFW etc
> > >> or really a problem with any of the filters or scripts, the p= > roblem is at the level of PFIL, the kernel packet filtering code: If no
> > >> filter is loaded, i.e. if the heads are unhooked, then PFIL s= > ends everything thru to its destination. So my thought
> > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL = > version of PF_DEFAULT_TO_DROP) that drops all the
> > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to= > -be-loaded chosen filter (PF or whatever) at any given time the
> > >> hooks are  unhooked.
> > >
> > > If no firewalls loaded, then the system should behave as is. I do= > not think PFIL_DEFAULT_TO_DROP is the right way to handle your case.
> > >
> > >>
> > >> [No one filters on local loopback nor the link layer, so I've= > left those hooks untouched. I suppose one could add them,
> > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP= > , but I doubt there's much demand for it.]
> > >>
> > >> Normally I'm an embedded linux kernel basher.
> > >> I'm not entirely sure where to send this patch. Most of the t= > hreads asking the above PF questions are closed to changes,
> > >> so that doesn't seem a good place. Sir Dice seems to be a com= > mon answerer of questions; I would have sent it to him/her
> > >> if I could...
> > >>
> > >> I'm not a user of GIT, so I'm not sure how to submit a "= > GIT formatted patch"...
> > >> I've simply diff -rdpNU 5 a copy of the @old folder with a co= > py of @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64,= >
> > >> but I suspect the kernel code in the networking core doesn't = > change much from platform to platform, or version to version.
> > >>
> > >> But it works, it's pretty simple, pretty small and so just in= > case it might be useful, I'm passing it along.
> > >>
> > >> thanks!
> > >>
> > >>
> > >> Robert
> > >>
> > >>
> > >>
> > >>
> > >> <FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip= > >
> >
> >
> >
>
> --
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  =3D"https://FreeBSD.org">https://FreeBSD.org
> NTP:           <cy@nwt= > ime.org>    Web:  htt= > ps://nwtime.org
>
>             &nb= > sp;           e^(i*pi)+1= > =3D0
>
>
> > > > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_-- From nobody Wed Apr 9 16:51:18 2025 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 4ZXpqs67Ylz5s3SP; Wed, 09 Apr 2025 16:51:21 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXpqr4d6Jz40fd; Wed, 09 Apr 2025 16:51:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id 2G6dukAjb5Mqy2Ye0ux36k; Wed, 09 Apr 2025 16:51:20 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2YdyuvZs5WbOa2YdzuYATt; Wed, 09 Apr 2025 16:51:20 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Q5lx4J2a c=1 sm=1 tr=0 ts=67f6a588 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=_EeEMxcBAAAA:8 a=UqCG9HQmAAAA:8 a=YxBL1-UpAAAA:8 a=HIpOd3htAAAA:8 a=NMM7OKYrAAAA:8 a=wwbO4EBcAAAA:8 a=kUCByv9wAAAA:8 a=vUPWEWiMAAAA:8 a=0VOg8hKvAAAA:8 a=sDLHkD9wShOpoRjQhgoA:9 a=XqS8QqoS1rPLgu61:21 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=kmlo3kNSEkcePd_NiW6t:22 a=isrg6BwTYk6I_F0B0DtW:22 a=jx9uv8QTLkEiLr58aJp2:22 a=bu_5hG6eGWxBxPYBRUjp:22 a=s3Yi14Of9AgBIP63TAoC:22 a=I-efbNKAaAt4Mg394dr-:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 97DF713E; Wed, 09 Apr 2025 09:51:18 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 93B072B; Wed, 09 Apr 2025 09:51:18 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Robert Austen cc: Zhenlei Huang , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop In-reply-to: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Comments: In-reply-to Robert Austen message dated "Wed, 09 Apr 2025 16:44:17 -0000." 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 Date: Wed, 09 Apr 2025 09:51:18 -0700 Message-Id: <20250409165118.93B072B@slippy.cwsent.com> X-CMAE-Envelope: MS4xfNyUJHtugA92F84EfVxm351CwUvtssOlzzWlmUtW9HaVRe0UXN024joHO0RuY1U5Ih/kcbegeum1ZOptNYxQu7ugfYhmSVcBwslanfk0b581Jrippx1B +1D2YAPgwj7sm0eRsp3wmUxYqGOzDXKhLWYqWVUvcbT1MxFd9u5qDvzozvBh4VctplBi8OWHsm6w1++3GFv+M2kmZjo2SA7NzvXPr60c6VSNipvsiPpWyX1l 5SG2L0GtHUWiFfU7p3uGOrkRFU2QwJ/iFlqZwtpvpgSaXdj4r/qF17/7PQWb4kD4fFtnU0tjEHLjziEVpS1If8xcohxf8M7vEIaeJJRTlaAC8J0IO02fiWoE 5xNxsHMBEYpd1cF1huckuNCHB0kyyA== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXpqr4d6Jz40fd X-Spamd-Bar: ---- In message , Robert Austen writes: > --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > "Maybe we also want a loader tunable to enable pf(4) on load" > > Seems a complicated way to do a simple thing. imho. > > Did you happen to look at my tiny patch? > There are already a bunch of macros (PFIL_HOOKED_IN, PFIL_HOOKED_OUT) defi= > ned depending on the inclusion of INET v4 or 6. > I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the HOOK= > ED_ one, or FALSE when INET v4 or 6 is excluded > or if PFIL_DEFAULT_TO_DROP isn't defined. > > Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= > calling the filter hook, I just > inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = > 'goto passin/out' for the 7 occurances > in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= > d) and the 4 in the NETINET6 code (same as netinet4 plus ip6_foward). > > easy peasy. Easy? Patches please. > I spend 10x more time messing with the kernel Makefile + CONF structure tha= > n with my changes lol. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 > > > ________________________________ > From: Zhenlei Huang > Sent: April 9, 2025 1:48 AM > To: Robert Austen > Cc: freebsd-current@freebsd.org ; freebsd-net@= > freebsd.org ; Kristof Provost ; Cy= > Schubert > Subject: Re: pfil_default_to_drop > > You don't often get email from zlei@freebsd.org. Learn why this is importan= > t > > > On Apr 9, 2025, at 1:01 AM, Robert Austen com> wrote: > > I respectfully disagree. > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= > o enable itself, ie. to apply any hooks. > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= > o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= > . > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCSTAR= > T ) or netlink command to enable it. > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= > he pfil layer in the kernel has no idea what the filter will be, > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and l= > ikewise the equivalents from the other filters). > > As for ipfw(4), by default it enables filtering on load, unless you disable= > it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable` a= > nd `net.link.ether.ipfw`. > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.inet= > .ip.fw.default_to_accept` controls the default behavior to drop or accept. > See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60= > e598498df6f9e2bd . > > > as I said, this is because there's no mechanism within PFIL to drop by defa= > ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= > O_DROP, > because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= > FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= > all, > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= > can ever provide. > > It appears ipf(4) unconditionally enable filtering on load, and does not ha= > ve any tunables to control that. CC @Cy who is more familiar with ipf(4). > > > thanks! > ________________________________ > From: Zhenlei Huang > > Sent: April 7, 2025 7:55 PM > To: Robert Austen @willowglensystems.com>> > Cc: freebsd-current@freebsd.org d-current@freebsd.org>; freebsd-net@fre= > ebsd.org eebsd-net@freebsd.org>>; Kristof Provost org>> > Subject: Re: pfil_default_to_drop > > You don't often get email from zlei@freebsd.org. L= > earn why this is important > > > On Apr 8, 2025, at 6:36 AM, Robert Austen com> wrote: > > > > ________________________________ > From: Robert Austen en@willowglensystems.com>> > Sent: April 7, 2025 4:33 PM > To: freebsd-current@freebsd.org d-current@freebsd.org>; freebsd-net@fre= > ebsd.org eebsd-net@freebsd.org>> > Subject: Fw: pfil_default_to_drop > > > ________________________________ > From: Robert Austen > Sent: April 7, 2025 4:21 PM > To: freebsd-current@freebsd.org d-current@freebsd.org> > Subject: pfil_default_to_drop > > Hello, > I've been playing with FreeBSD and PF to build myself a new firewall, as Op= > en/FreeBSD + PF seems to be a common starting point. > > I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= > nd the like, with the observations that it's hard > to ensure that packets all default to drop if the rule file(s) for whatever= > reason fail to load. > > Hi Robert, > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.k= > o ( via the loader(8), /boot/loader.conf ) ? > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), y= > ou can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.= > ko. > See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9= > 913226801f3073bd . > > > After looking thru the online documentation, forums and scripts, I came to = > the conclusion that it's not a PF problem or IPFW etc > or really a problem with any of the filters or scripts, the problem is at t= > he level of PFIL, the kernel packet filtering code: If no > filter is loaded, i.e. if the heads are unhooked, then PFIL sends everythin= > g thru to its destination. So my thought > was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= > DEFAULT_TO_DROP) that drops all the > IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= > sen filter (PF or whatever) at any given time the > hooks are unhooked. > > If no firewalls loaded, then the system should behave as is. I do not think= > PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > [No one filters on local loopback nor the link layer, so I've left those ho= > oks untouched. I suppose one could add them, > maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = > there's much demand for it.] > > Normally I'm an embedded linux kernel basher. > I'm not entirely sure where to send this patch. Most of the threads asking = > the above PF questions are closed to changes, > so that doesn't seem a good place. Sir Dice seems to be a common answerer o= > f questions; I would have sent it to him/her > if I could... > > I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch= > "... > I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= > der. The code was written against FreeBSD-14.1-RELEASE-amd64, > but I suspect the kernel code in the networking core doesn't change much fr= > om platform to platform, or version to version. > > But it works, it's pretty simple, pretty small and so just in case it might= > be useful, I'm passing it along. > > thanks! > > > Robert > > > > > > > > > > --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > > > > >
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > "Maybe we also want a loader tunable to enable pf(4) on load" v> >
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > Seems a complicated way to do a simple thing. imho.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > Did you happen to look at my tiny patch?
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > There are already a bunch of macros  (PFIL_HOOKED_IN, PFIL_HOOKED_OUT)= > defined depending on the inclusion of INET v4 or 6.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the H= > OOKED_ one, or FALSE when INET v4 or 6 is excluded 
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > or if PFIL_DEFAULT_TO_DROP isn't defined. 
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= > calling the filter hook, I just
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = > 'goto passin/out' for the 7 occurances
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= > d) and the 4 in the NETINET6 code (same as netinet4 plus  ip6_foward).= >
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > easy peasy.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > I spend 10x more time messing with the kernel Makefile + CONF structure tha= > n with my changes lol.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
>
>
yle=3D"font-size:11pt" color=3D"#000000">From: Zhenlei Huang <zle= > i@FreeBSD.org>
> Sent: April 9, 2025 1:48 AM
> To: Robert Austen <robert.austen@willowglensystems.com>
> Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>;= > freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost &= > lt;kp@FreeBSD.org>; Cy Schubert <cy@freebsd.org>
> Subject: Re: pfil_default_to_drop >
 
>
>
"> > n=3D"left" style=3D"background:revert!important; border:revert!important; b= > ottom:revert!important; color:revert!important; direction:revert!important;= > display:revert!important; font-size:revert!important; height:revert!import= > ant; letter-spacing:revert!important; line-height:revert!important; margin:= > revert!important; opacity:revert!important; order:revert!important; outline= > :revert!important; overflow:revert!important; padding:revert!important; pos= > ition:revert!important; tab-size:revert!important; table-layout:revert!impo= > rtant; text-align:revert!important; text-indent:revert!important; text-orie= > ntation:revert!important; text-overflow:revert!important; text-transform:re= > vert!important; top:revert!important; vertical-align:revert!important; visi= > bility:revert!important; white-space:revert!important; width:revert!importa= > nt; word-break:revert!important; word-spacing:revert!important; writing-mod= > e:revert!important; zoom:revert!important; border:0!important; display:tabl= > e!important; width:100%!important; table-layout:fixed!important; border-col= > lapse:seperate!important; float:none!important; border-spacing:0px 0px!impo= > rtant"> > m:revert!important; color:revert!important; direction:revert!important; dis= > play:revert!important; font-size:revert!important; height:revert!important;= > letter-spacing:revert!important; line-height:revert!important; margin:reve= > rt!important; opacity:revert!important; order:revert!important; outline:rev= > ert!important; overflow:revert!important; padding:revert!important; positio= > n:revert!important; tab-size:revert!important; table-layout:revert!importan= > t; text-align:revert!important; text-indent:revert!important; text-orientat= > ion:revert!important; text-overflow:revert!important; text-transform:revert= > !important; top:revert!important; vertical-align:revert!important; visibili= > ty:revert!important; white-space:revert!important; width:revert!important; = > word-break:revert!important; word-spacing:revert!important; writing-mode:re= > vert!important; zoom:revert!important; display:block!important"> > evert!important; color:revert!important; direction:revert!important; displa= > y:revert!important; font-size:revert!important; height:revert!important; le= > tter-spacing:revert!important; line-height:revert!important; margin:revert!= > important; opacity:revert!important; order:revert!important; outline:revert= > !important; overflow:revert!important; padding:revert!important; position:r= > evert!important; tab-size:revert!important; table-layout:revert!important; = > text-align:revert!important; text-indent:revert!important; text-orientation= > :revert!important; text-overflow:revert!important; text-transform:revert!im= > portant; top:revert!important; vertical-align:revert!important; visibility:= > revert!important; white-space:revert!important; width:revert!important; wor= > d-break:revert!important; word-spacing:revert!important; writing-mode:rever= > t!important; zoom:revert!important"> > > > > > >
2px 7px 2px" style=3D"background:revert!important; border:revert!important;= > bottom:revert!important; color:revert!important; direction:revert!importan= > t; display:revert!important; font-size:revert!important; height:revert!impo= > rtant; letter-spacing:revert!important; line-height:revert!important; margi= > n:revert!important; opacity:revert!important; order:revert!important; outli= > ne:revert!important; overflow:revert!important; padding:revert!important; p= > osition:revert!important; tab-size:revert!important; table-layout:revert!im= > portant; text-align:revert!important; text-indent:revert!important; text-or= > ientation:revert!important; text-overflow:revert!important; text-transform:= > revert!important; top:revert!important; vertical-align:revert!important; vi= > sibility:revert!important; white-space:revert!important; width:revert!impor= > tant; word-break:revert!important; word-spacing:revert!important; writing-m= > ode:revert!important; zoom:revert!important; padding:7px 2px 7px 2px!import= > ant; background-color:#A6A6A6!important; width:0px!important"> > 5px 7px 15px" color=3D"#212121" style=3D"background:revert!important; bord= > er:revert!important; bottom:revert!important; color:revert!important; direc= > tion:revert!important; display:revert!important; font-size:revert!important= > ; height:revert!important; letter-spacing:revert!important; line-height:rev= > ert!important; margin:revert!important; opacity:revert!important; order:rev= > ert!important; outline:revert!important; overflow:revert!important; padding= > :revert!important; position:revert!important; tab-size:revert!important; ta= > ble-layout:revert!important; text-align:revert!important; text-indent:rever= > t!important; text-orientation:revert!important; text-overflow:revert!import= > ant; text-transform:revert!important; top:revert!important; vertical-align:= > revert!important; visibility:revert!important; white-space:revert!important= > ; width:revert!important; word-break:revert!important; word-spacing:revert!= > important; writing-mode:revert!important; zoom:revert!important; width:100%= > !important; background-color:#EAEAEA!important; padding:7px 5px 7px 15px!im= > portant; font-family:wf_segoe-ui_normal,Segoe UI,Segoe WP,Tahoma,Arial,sans= > -serif!important; font-size:12px!important; font-weight:normal!important; c= > olor:#212121!important; text-align:left!important; word-wrap:break-word!imp= > ortant"> >
revert!important; color:revert!important; direction:revert!important; displ= > ay:revert!important; font-size:revert!important; height:revert!important; l= > etter-spacing:revert!important; line-height:revert!important; margin:revert= > !important; opacity:revert!important; order:revert!important; outline:rever= > t!important; overflow:revert!important; padding:revert!important; position:= > revert!important; tab-size:revert!important; table-layout:revert!important;= > text-align:revert!important; text-indent:revert!important; text-orientatio= > n:revert!important; text-overflow:revert!important; text-transform:revert!i= > mportant; top:revert!important; vertical-align:revert!important; visibility= > :revert!important; white-space:revert!important; width:revert!important; wo= > rd-break:revert!important; word-spacing:revert!important; writing-mode:reve= > rt!important; zoom:revert!important"> > You don't often get email from zlei@freebsd.org. LearnAboutSenderIdentification" style=3D"background:revert!important; color= > :revert!important; direction:revert!important; display:revert!important; fo= > nt-size:revert!important; opacity:revert!important; visibility:revert!impor= > tant"> > Learn why this is important
> 		lpadding=3D"7px 5px 7px 5px" color=3D"#212121" style=3D"background:revert!i= > mportant; border:revert!important; bottom:revert!important; color:revert!im= > portant; direction:revert!important; display:revert!important; font-size:re= > vert!important; height:revert!important; letter-spacing:revert!important; l= > ine-height:revert!important; margin:revert!important; opacity:revert!import= > ant; order:revert!important; outline:revert!important; overflow:revert!impo= > rtant; padding:revert!important; position:revert!important; tab-size:revert= > !important; table-layout:revert!important; text-align:revert!important; tex= > t-indent:revert!important; text-orientation:revert!important; text-overflow= > :revert!important; text-transform:revert!important; top:revert!important; v= > ertical-align:revert!important; visibility:revert!important; white-space:re= > vert!important; width:revert!important; word-break:revert!important; word-s= > pacing:revert!important; writing-mode:revert!important; zoom:revert!importa= > nt; width:75px!important; background-color:#EAEAEA!important; padding:7px 5= > px 7px 5px!important; font-family:wf_segoe-ui_normal,Segoe UI,Segoe WP,Taho= > ma,Arial,sans-serif!important; font-size:12px!important; font-weight:normal= > !important; color:#212121!important; text-align:left!important; word-wrap:b= > reak-word!important"> >
>

>

>
>
On Apr 9, 2025, at 1:01 AM, Robert Austen < ilto:robert.austen@willowglensystems.com" class=3D"">robert.austen@willowgl= > ensystems.com> wrote:
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > I respectfully disagree.
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= > o enable itself, ie. to apply any hooks.
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= > o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= > .
>
>
>

>
>
Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl (&nbs= > p;DIOCSTART ) or netlink command to enable it.
>

>
>
@Kristof Maybe we also want a loader tunable to enable pf(4) on load ?= >
>
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= > he pfil layer in the kernel has no idea what the filter will be,
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > assuming there even is one. thus PF_DEFAULT_TO_DROP  has zero effect (= > and likewise the equivalents from the other filters).
>
>
>

>
>
As for ipfw(4), by default it enables filtering on load, unless you di= > sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= > le` and `net.link.ether.ipfw`.
>

>
>
The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable= > `net.inet.ip.fw.default_to_accept` controls the default behavior to drop o= > r accept.
> >
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > as I said, this is because there's no mechanism within PFIL to drop by defa= > ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= > O_DROP,
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= > FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= > all,
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= > can ever provide.
>
>
>

>
>
It appears ipf(4) unconditionally enable filtering on load, and does n= > ot have any tunables to control that. CC @Cy who is more familiar with ipf(= > 4).
>
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > thanks!
>
size:13px; font-style:normal; font-variant-caps:normal; font-weight:400; le= > tter-spacing:normal; text-align:start; text-indent:0px; text-transform:none= > ; white-space:normal; word-spacing:0px; text-decoration:none"> >
>
px; font-style:normal; font-variant-caps:normal; font-weight:400; letter-sp= > acing:normal; text-align:start; text-indent:0px; text-transform:none; white= > -space:normal; word-spacing:0px; text-decoration:none; display:inline-block= > ; width:563.5px"> > :normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; = > text-align:start; text-indent:0px; text-transform:none; white-space:normal;= > word-spacing:0px; text-decoration:none; float:none; display:inline!importa= > nt"> >
vetica; font-size:13px; font-style:normal; font-variant-caps:normal; font-w= > eight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-t= > ransform:none; white-space:normal; word-spacing:0px; text-decoration:none"> > lass=3D"">From: Zhe= > nlei Huang <zlei@FreeBSD.= > org>
> Sent:  >April 7, 2025 7:55 PM
> To: R= > obert Austen < ss=3D"">robert.austen@willowglensystems.com>
> Cc: <= > a href=3D"mailto:freebsd-current@freebsd.org" class=3D"">freebsd-current@fr= > eebsd.org < ef=3D"mailto:freebsd-current@freebsd.org" class=3D"">freebsd-current@freebs= > d.org>;  =3D"mailto:freebsd-net@freebsd.org" class=3D"">freebsd-net@freebsd.org<= > span class=3D"x_Apple-converted-space"> < reebsd-net@freebsd.org" class=3D"">freebsd-net@freebsd.org>; > Kristof Provost <kp@FreeBS= > D.org>
> Subject:  pan>Re: pfil_default_to_drop >
 
>
>
normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; t= > ext-align:start; text-indent:0px; text-transform:none; white-space:normal; = > word-spacing:0px; text-decoration:none; word-wrap:break-word; line-break:af= > ter-white-space"> > n=3D"left" class=3D"" style=3D"background-image:revert!important; backgroun= > d-size:revert!important; background-attachment:revert!important; background= > -origin:revert!important; background-clip:revert!important; background-colo= > r:revert!important; bottom:revert!important; color:revert!important; direct= > ion:revert!important; font-size:revert!important; height:revert!important; = > letter-spacing:revert!important; line-height:revert!important; margin:rever= > t!important; opacity:revert!important; order:revert!important; outline:reve= > rt!important; overflow:revert!important; padding:revert!important; position= > :revert!important; tab-size:revert!important; text-align:revert!important; = > text-indent:revert!important; text-orientation:revert!important; text-overf= > low:revert!important; text-transform:revert!important; top:revert!important= > ; vertical-align:revert!important; visibility:revert!important; white-space= > :revert!important; word-break:revert!important; word-spacing:revert!importa= > nt; writing-mode:revert!important; zoom:revert!important; border:0px!import= > ant; display:table!important; width:575px; table-layout:fixed!important; fl= > oat:none!important; border-spacing:0px!important; background-position:rever= > t!important; background-repeat:revert!important"> > ze:revert!important; background-attachment:revert!important; background-ori= > gin:revert!important; background-clip:revert!important; background-color:re= > vert!important; border:revert!important; bottom:revert!important; color:rev= > ert!important; direction:revert!important; font-size:revert!important; heig= > ht:revert!important; letter-spacing:revert!important; line-height:revert!im= > portant; margin:revert!important; opacity:revert!important; order:revert!im= > portant; outline:revert!important; overflow:revert!important; padding:rever= > t!important; position:revert!important; tab-size:revert!important; table-la= > yout:revert!important; text-align:revert!important; text-indent:revert!impo= > rtant; text-orientation:revert!important; text-overflow:revert!important; t= > ext-transform:revert!important; top:revert!important; vertical-align:revert= > !important; visibility:revert!important; white-space:revert!important; widt= > h:revert!important; word-break:revert!important; word-spacing:revert!import= > ant; writing-mode:revert!important; zoom:revert!important; display:block!im= > portant; background-position:revert!important; background-repeat:revert!imp= > ortant"> > revert!important; background-attachment:revert!important; background-origin= > :revert!important; background-clip:revert!important; background-color:rever= > t!important; border:revert!important; bottom:revert!important; color:revert= > !important; direction:revert!important; display:revert!important; font-size= > :revert!important; height:revert!important; letter-spacing:revert!important= > ; line-height:revert!important; margin:revert!important; opacity:revert!imp= > ortant; order:revert!important; outline:revert!important; overflow:revert!i= > mportant; padding:revert!important; position:revert!important; tab-size:rev= > ert!important; table-layout:revert!important; text-align:revert!important; = > text-indent:revert!important; text-orientation:revert!important; text-overf= > low:revert!important; text-transform:revert!important; top:revert!important= > ; vertical-align:revert!important; visibility:revert!important; white-space= > :revert!important; width:revert!important; word-break:revert!important; wor= > d-spacing:revert!important; writing-mode:revert!important; zoom:revert!impo= > rtant; background-position:revert!important; background-repeat:revert!impor= > tant"> > > > > > >
2px 7px 2px" class=3D"" style=3D"background-image:revert!important; backgro= > und-size:revert!important; background-attachment:revert!important; backgrou= > nd-origin:revert!important; background-clip:revert!important; border:revert= > !important; bottom:revert!important; color:revert!important; direction:reve= > rt!important; display:revert!important; font-size:revert!important; height:= > revert!important; letter-spacing:revert!important; line-height:revert!impor= > tant; margin:revert!important; opacity:revert!important; order:revert!impor= > tant; outline:revert!important; overflow:revert!important; position:revert!= > important; tab-size:revert!important; table-layout:revert!important; text-a= > lign:revert!important; text-indent:revert!important; text-orientation:rever= > t!important; text-overflow:revert!important; text-transform:revert!importan= > t; top:revert!important; vertical-align:revert!important; visibility:revert= > !important; white-space:revert!important; word-break:revert!important; word= > -spacing:revert!important; writing-mode:revert!important; zoom:revert!impor= > tant; padding:7px 2px!important; background-color:rgb(166,166,166)!importan= > t; width:0px!important; background-position:revert!important; background-re= > peat:revert!important"> > 5px 7px 15px" class=3D"" style=3D"background-image:revert!important; backg= > round-size:revert!important; background-attachment:revert!important; backgr= > ound-origin:revert!important; background-clip:revert!important; border:reve= > rt!important; bottom:revert!important; direction:revert!important; display:= > revert!important; height:revert!important; letter-spacing:revert!important;= > line-height:revert!important; margin:revert!important; opacity:revert!impo= > rtant; order:revert!important; outline:revert!important; overflow:revert!im= > portant; position:revert!important; tab-size:revert!important; table-layout= > :revert!important; text-indent:revert!important; text-orientation:revert!im= > portant; text-overflow:revert!important; text-transform:revert!important; t= > op:revert!important; vertical-align:revert!important; visibility:revert!imp= > ortant; white-space:revert!important; word-break:revert!important; word-spa= > cing:revert!important; writing-mode:revert!important; zoom:revert!important= > ; width:541px; background-color:rgb(234,234,234)!important; padding:7px 5px= > 7px 15px!important; font-family:wf_segoe-ui_normal,"Segoe UI",&q= > uot;Segoe WP",Tahoma,Arial,sans-serif!important; font-size:12px!import= > ant; font-weight:normal!important; color:rgb(33,33,33)!important; text-alig= > n:left!important; word-wrap:break-word!important; background-position:rever= > t!important; background-repeat:revert!important"> >
:revert!important; background-attachment:revert!important; background-origi= > n:revert!important; background-clip:revert!important; background-color:reve= > rt!important; border:revert!important; bottom:revert!important; color:rever= > t!important; direction:revert!important; display:revert!important; font-siz= > e:revert!important; height:revert!important; letter-spacing:revert!importan= > t; line-height:revert!important; margin:revert!important; opacity:revert!im= > portant; order:revert!important; outline:revert!important; overflow:revert!= > important; padding:revert!important; position:revert!important; tab-size:re= > vert!important; table-layout:revert!important; text-align:revert!important;= > text-indent:revert!important; text-orientation:revert!important; text-over= > flow:revert!important; text-transform:revert!important; top:revert!importan= > t; vertical-align:revert!important; visibility:revert!important; white-spac= > e:revert!important; width:revert!important; word-break:revert!important; wo= > rd-spacing:revert!important; writing-mode:revert!important; zoom:revert!imp= > ortant; background-position:revert!important; background-repeat:revert!impo= > rtant"> > You don't often get email from = > ;zlei@freebsd.org= > .  a.ms/LearnAboutSenderIdentification" class=3D"" style=3D"background-image:r= > evert!important; background-size:revert!important; background-attachment:re= > vert!important; background-origin:revert!important; background-clip:revert!= > important; background-color:revert!important; color:revert!important; direc= > tion:revert!important; display:revert!important; font-size:revert!important= > ; opacity:revert!important; visibility:revert!important; background-positio= > n:revert!important; background-repeat:revert!important">Learn > why this is important
> 		lpadding=3D"7px 5px 7px 5px" class=3D"" style=3D"background-image:revert!im= > portant; background-size:revert!important; background-attachment:revert!imp= > ortant; background-origin:revert!important; background-clip:revert!importan= > t; border:revert!important; bottom:revert!important; direction:revert!impor= > tant; display:revert!important; height:revert!important; letter-spacing:rev= > ert!important; line-height:revert!important; margin:revert!important; opaci= > ty:revert!important; order:revert!important; outline:revert!important; over= > flow:revert!important; position:revert!important; tab-size:revert!important= > ; table-layout:revert!important; text-indent:revert!important; text-orienta= > tion:revert!important; text-overflow:revert!important; text-transform:rever= > t!important; top:revert!important; vertical-align:revert!important; visibil= > ity:revert!important; white-space:revert!important; word-break:revert!impor= > tant; word-spacing:revert!important; writing-mode:revert!important; zoom:re= > vert!important; width:75px!important; background-color:rgb(234,234,234)!imp= > ortant; padding:7px 5px!important; font-family:wf_segoe-ui_normal,"Seg= > oe UI","Segoe WP",Tahoma,Arial,sans-serif!important; font-si= > ze:12px!important; font-weight:normal!important; color:rgb(33,33,33)!import= > ant; text-align:left!important; word-wrap:break-word!important; background-= > position:revert!important; background-repeat:revert!important"> >
>

>

>
>
On Apr 8, 2025, at 6:36 AM, Robert Austen < ilto:robert.austen@willowglensystems.com" class=3D"">robert.austen@willowgl= > ensystems.com> wrote:
>
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica= > ,sans-serif; font-size:12pt"> >
>
>
>
t-size:13px; font-style:normal; font-variant-caps:normal; font-weight:400; = > letter-spacing:normal; text-align:start; text-indent:0px; text-transform:no= > ne; white-space:normal; word-spacing:0px; text-decoration:none"> >
>
ormal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; te= > xt-align:start; text-indent:0px; text-transform:none; white-space:normal; w= > ord-spacing:0px; text-decoration:none; display:inline-block; width:576.2343= > 75px"> > :normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; = > text-align:start; text-indent:0px; text-transform:none; white-space:normal;= > word-spacing:0px; text-decoration:none; float:none; display:inline!importa= > nt"> >
elvetica; font-size:13px; font-style:normal; font-variant-caps:normal; font= > -weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text= > -transform:none; white-space:normal; word-spacing:0px; text-decoration:none= > "> > <= > b class=3D"">From: Robert Austen < en@willowglensystems.com" class=3D"">robert.austen@willowglensystems.com >>
> Sent: April 7, 2025 4:33 PM
> To:  lass=3D"">freebsd-current@freebsd.org -space"> < ss=3D"">freebsd-current@freebsd.org>; ted-space">  "">freebsd-net@freebsd.org&nb= > sp;<freebsd= > -net@freebsd.org>
> Subject: Fw: pfil_default_to_drop >
 
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ont-size:13px; font-style:normal; font-variant-caps:normal; font-weight:400= > ; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:= > none; white-space:normal; word-spacing:0px; text-decoration:none"> >
>
ormal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; te= > xt-align:start; text-indent:0px; text-transform:none; white-space:normal; w= > ord-spacing:0px; text-decoration:none; direction:ltr; display:inline-block;= > width:576.234375px"> > :normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; = > text-align:start; text-indent:0px; text-transform:none; white-space:normal;= > word-spacing:0px; text-decoration:none; float:none; display:inline!importa= > nt"> >
:Helvetica; font-size:13px; font-style:normal; font-variant-caps:normal; fo= > nt-weight:400; letter-spacing:normal; text-align:start; text-indent:0px; te= > xt-transform:none; white-space:normal; word-spacing:0px; text-decoration:no= > ne"> > <= > b class=3D"">From: Robert Austen
> Sent: April 7, 2025 4:21 PM
> To:  lass=3D"">freebsd-current@freebsd.org -space"> < ss=3D"">freebsd-current@freebsd.org>
> Subject: pfil_default_to_drop >
 
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > Hello,
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I've been playing with FreeBSD and PF to build myself a new firewall, as Op= > en/FreeBSD + PF seems to be a common starting point.
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= > nd the like, with the observations that it's hard
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > to ensure that packets all default to drop if the rule file(s) for whatever= > reason fail to load. 
>
>
>

>
>
Hi Robert,
>

>
>
So why not defining the compile option PF_DEFAULT_TO_D= > ROP, and preload pf.ko ( via the loader(8)= > , /boot/loader.conf ) ? > >

>
>
With 13.5, or upcoming 14.3 ( you can also= >  experiment latest stable/14 ), you can d-space"> turn the loader tu= > nable net.pf.default_to_drop to 1, and  yle=3D"">preload pf.ko. > >
See also  t/?id=3Dc531c1d1462c45f7ce5de4f9913226801f3073bd" class=3D"">https://cgit.f= > reebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801f3073bd&nb= > sp;.
>

>
>
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > After looking thru the online documentation, forums and scripts, I came to = > the conclusion that it's not a PF problem or IPFW etc
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > or really a problem with any of the filters or scripts, the problem is at t= > he level of PFIL, the kernel packet filtering code: If no
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > filter is loaded, i.e. if the heads are unhooked, then PFIL sends s=3D"x_x_Apple-converted-space"> everything&n= > bsp;thru to its destination. So my thought 
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= > DEFAULT_TO_DROP) that drops all the
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= > sen filter (PF or whatever) at any given time the 
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > hooks are  unhooked. 
>
>
>

>
>
If no firewalls loaded, then the system should behave as is= > . I do not think PFIL_DEFAULT_TO_DROP is the right way to handle your = > case.
>
>
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > [No one filters on local loopback nor the link layer, so I've left those ho= > oks untouched. I suppose one could add them,
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = > there's much demand for it.]
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > Normally I'm an embedded linux kernel basher.
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > I'm not entirely sure where to send this patch. Most of the threads asking = > the above PF questions are closed to changes,
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > so that doesn't seem a good place. Sir Dice seems to be a common answerer o= > f questions; I would have sent it to him/her 
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > if I could...
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = > patch"...
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= > der. The code was written against FreeBSD-14.1-RELEASE-amd64,
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > but I suspect the kernel code in the networking core doesn't change much fr= > om platform to platform, or version to version.
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > But it works, it's pretty simple, pretty small and so just in case it might= > be useful, I'm passing it along.
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > thanks!
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > Robert
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
> <Fr= > eeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
> > > > --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_-- From nobody Wed Apr 9 16:51:30 2025 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 4ZXprH1PBXz5s3Px; Wed, 09 Apr 2025 16:51:43 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Received: from YT6PR01CU002.outbound.protection.outlook.com (mail-canadacentralazon11022098.outbound.protection.outlook.com [40.107.193.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXprD6HrDz411Y; Wed, 09 Apr 2025 16:51:40 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=willowglensystems.com header.s=selector1 header.b=ioVFD8Y1; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=willowglensystems.com; spf=pass (mx1.freebsd.org: domain of robert.austen@willowglensystems.com designates 40.107.193.98 as permitted sender) smtp.mailfrom=robert.austen@willowglensystems.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kalTTQDJn0MpHQ8VY6hhL5EKljf1/Y15Ctp7VLWUm6HPYuVguY6dc0stDvQfs5Ky25T2W1WUShAtW7DaSihJXcgmvLu/L2bi4IhnhpDikT/U9H247TPfxfxFdMOfiBi+pPOR/D+7eXAo/CXlwoMJxG+OtGmOJIGgNZnmGgJ06kXXksOJShc+s8WRk4a+4/GnGmYHSaIqd4Tl9Xdq/95YhlnBz/bGq7a3y5JNb2d7kcVIE/onr0c7MWesefVA0bUtl9m9bG/maGRa5I7yk1ddMQd/NljERAOuSc/Y7b1GS1sZMV8GdVGGxLzuvgXN3JgQGpcNN3XF9pMoe+tCYERB9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WeIyrbf7hJy7zP0uy5/Kj57IQINndaasBds4F23QPtY=; b=ipfetVANbgtdb7Op5LB0+upxqhNIcf7l7mDxDgFo69KYVNPBgogebwQSqo4+hkOMe8eSofBWEZ4PcBwBNTxaQFF8dswOgwRPzB5wPnZMJ7Ah96hQFUYjq//TM5kkTm06vtLqZshOkmurUa5EGr4o6uolhdYwWBglK7hgl2XaNZ21VaCujV6/cbOymzQGVYes2pnqtNFyqO1ey9zDzugy7cMF7h0ClAfK7fSCJiRdFW06td5la4jbpedtNkBVo/j0Ae8l9z1WUD8kZl8rq/wIs+cbPCJC+hvauLlRn69dZPGiRxuI024RtMphsn0oqBW5EIVSNZRacl3n5PcCjgQFvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=willowglensystems.com; dmarc=pass action=none header.from=willowglensystems.com; dkim=pass header.d=willowglensystems.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willowglensystems.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WeIyrbf7hJy7zP0uy5/Kj57IQINndaasBds4F23QPtY=; b=ioVFD8Y12lgdsONq4DzPhMrZUN29aFHAsMaUx7kks9WErLtij7HtYbUuDxcqgXXIJJZTFBOt6tOpUvCycW0IEGJMKjMoKArelX0fupzmvKp+k7pGEmu/7yd92bMK/oO7kvSUM2piMl2pSoGzQE7CpqnT56dfYl1MZqmYzGb+ICU= Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c08::23a) by YQXPR01MB6252.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:2b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8606.35; Wed, 9 Apr 2025 16:51:30 +0000 Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d]) by QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d%4]) with mapi id 15.20.8632.021; Wed, 9 Apr 2025 16:51:30 +0000 From: Robert Austen To: Zhenlei Huang CC: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop Thread-Topic: pfil_default_to_drop Thread-Index: AQHbqAfyk4Z18yjsM0yECEK2f5QGrrOYyea/gAAA4zGAADehgIAA+tGKgAD6MICAAJOZqIAABBt5 Date: Wed, 9 Apr 2025 16:51:30 +0000 Message-ID: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: QB1PPF4C719E46A:EE_|YQXPR01MB6252:EE_ x-ms-office365-filtering-correlation-id: e0d1db34-39cf-4505-b1b8-08dd7786c6fc x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018|13003099007|4053099003|4013099003|8096899003|7053199007; x-microsoft-antispam-message-info: =?us-ascii?Q?2MtgdtbYTrDNm+KRqOsbxSzvMn58tcAc3SnOnkHW+HunoaHKzyHlQT8tZJ0V?= =?us-ascii?Q?gWFd4nEkC6a1158IoePRBUmkb9jgJ8Gxu6s0zSxjSdOLGpnEwVba5xIZakYX?= =?us-ascii?Q?K3+bht95KCsCwPs95sYocBYM0z1VbvJI3epQ6lYq+LzgjlMcUVtv3zAQowkX?= =?us-ascii?Q?JJTMt5RaVuzdsWbc2tZ3XN9R/e4Ql9ga9pB4jVuXxtqsOYQOVbZvGzJx7Wvy?= =?us-ascii?Q?FlX9SkjH7/rcSeRfadZtCqTz8N2EaNAmNABXJBIQ+1jy/1EfdkPTToMfzIqZ?= =?us-ascii?Q?nEQsESz5QWHJzyk4lEu5Bqcxz4mWq6MH8CF2UamRI/mx/LFy2b8VL8lhYszp?= =?us-ascii?Q?0NuOG9H5omeyYHf0ixjp2FXmiHXNYvrgDDRoUXuWBvQxfyQut4jhyKzdZUvB?= =?us-ascii?Q?bH9aDjn7/NZ9AOb92nENSWUTvA1UG5huat+PACTGgLI4GOnPwT1Sa+3LnUJv?= =?us-ascii?Q?xE8WUgxrJJKvlfwk+GipjkIGVGTRisO46yhuqXu13ioilSX2sJbSuHWj+fms?= =?us-ascii?Q?xzSD2UAiqRHlTuFm3BPtxJwd1dyBNsNw9Ymp/kKg6BGBUUgsVSbQHo1fXRXl?= =?us-ascii?Q?nWUJrasVBq9N+6g0onLrOhvZkXXztNTIny7Pe80aFUPjq19pIJ+3MsUdg00M?= =?us-ascii?Q?/9+9sWfDVaVnUQnllA2yWP2q03tE2NOcIpSBM2PX11daVew9tk01K+dAJfbO?= =?us-ascii?Q?h/0QLsJvWu4TJEfj7riFbyleAyLM/LGwaGbUU2D19JviSzJUZsB9gvW7yw+p?= =?us-ascii?Q?gOil+Bbr9qJQMWMSLat2xErwJEAlK+MmAsQkcMbBXH6DvqvQmpyWW8Y259rS?= =?us-ascii?Q?wKNX5TmLFLt5ATI64fZ2nkpC240JGPyZoTTWyfxQqFK4dYW89f54mcwibeGp?= =?us-ascii?Q?PEZ1fqnjFRpksqvyoTr5HdYFU3imYJIN21MDOvu1ydWNgkcbDgFf9qg82cUq?= =?us-ascii?Q?DN1cNTqRrW07ipSUl9CslvNV/9xd8pncA3MQmmw7hd6YhBEHJQfim5rxfYyj?= =?us-ascii?Q?dNEr0cwt2JF0ed69ZayOpA9svuBtrKEd0aUSyG+Kl6xil9wqbWgMgu9bpK+7?= =?us-ascii?Q?QzfPgzszhfRqaemTo25ALnlyERYV8vSdBPzFmY1Jd1wnBh8K63+FmP4AesLE?= =?us-ascii?Q?E1uYS3QmLezRyg4BBX7+wLZlP+jnJ/3UJE4TTI8jqv9nW/MUikFcaWf5osSn?= =?us-ascii?Q?qabtbIQXJ6tKaImZLFCrGbzHH5wvU1EoDQo6L6D1sI/jiGDWuzRuqF6q0tmy?= =?us-ascii?Q?K1Vw7501w1x9B0sENowVbfPvOafoEzwnrlzELr7FP+/6xY/FvoZXR9+sPz8w?= =?us-ascii?Q?nyeX3LW4JIpcegJ7utI2uh0E2Myy8YJXwHep6aOBedyE7QzRl9iAa9YGzL3M?= =?us-ascii?Q?0WMxPvYr4gp075F+tUYfBNI61t7LO9g+cUQH6Sp3lMkYsKwr78pd+vE5xHPd?= =?us-ascii?Q?e3P/tj9MSdc=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018)(13003099007)(4053099003)(4013099003)(8096899003)(7053199007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fMD8/i/PyXmoq4YOz0XipNRWinxhc/AlrQcwfLmldrxT4PcsTS4rBbsBozTD?= =?us-ascii?Q?mVt9bVSMMcj8rtIEx2yFNVrGpjEtCGWTA3+WbP/cKeQSKpbP9PddxBQs8f8m?= =?us-ascii?Q?zbJCIquBEhynl1M35PYYHhOXE/ZvmxuHIG12qMluqXcFR6gdDIrkbsapoxyM?= =?us-ascii?Q?sbdERlwZhp1UJdfJ+K67U0ZtWnEZpSyew/O/+LTnJtvxIvz+wWH3pDiZDY0k?= =?us-ascii?Q?MRS1z7Syq1CoELWorPVkWodQ32zjTF/Pk9ycvL7rS+4ReLikuSFGc9de/RHJ?= =?us-ascii?Q?plLdk4zom75dY6rQ56AIyPl7tmeIddqXzUS89N1j8oLb969WJ/t6i1pxf1jH?= =?us-ascii?Q?4DKwFUBLTJqYAXBkM3TVRMCJf9TFL0XZHEQFavg85LIQmCSIoO7kNIIgI+BB?= =?us-ascii?Q?EmG8m7+URZX0+pdebHRB+IUhdm049rI0u2lLYMZWgN8SFbJVt7rrRgyqyRMG?= =?us-ascii?Q?SSPDYLlEM3kSqjP0CeeKNv9XR4mJ80kIUuJq1o3TQBGJjWQ54oG04mZfqnm8?= =?us-ascii?Q?EOxQAjRLim6RbepDAyWIli23tGx5cs01m0H+Q7AwJYo+LTzGa4tgMWca3klc?= =?us-ascii?Q?pdgj7gRXc4xGAnZlQ8SbaoMuWzOYYDn5faHzevSChdxwfytK+fIsW5OHVi5y?= =?us-ascii?Q?OIjbdB6hWu5LEyOClaJ+WP2nAjfqsKxxane5BLkmN6SnjMA7n9wyV8T82XDO?= =?us-ascii?Q?CEFhUhOsISNGrmAlrM076/D+0gUWyQL58p4jaO46oe0N2bJr0Db1IJN8p3xb?= =?us-ascii?Q?NW5P5dHL0TGJcQY0tprP8r7XwGvNkZj4PWhJcfh4x/shGD951UpBYMEHdh53?= =?us-ascii?Q?eHgfe2W4nmi005bse8K4yuduZ3lXlIHKuiCelJQAlsGcYaB++qwW9CAcIsaF?= =?us-ascii?Q?ZWfod8oQT9ehmN7KJ/zLUm83U980hzcPfN89h+FgGnam4J36HplOf1/6kYGl?= =?us-ascii?Q?oagHMc2uP1F38JsS6/EsmfyyviFWu+I46muuuqSTcZDz4y9LKtFzg0fZz9ik?= =?us-ascii?Q?430dOfbfQrpG+dz+fBf0FndLXDOGvNmS4MhMTKGuR78bnvRcKZv+7/1UECPR?= =?us-ascii?Q?atB1val9rBBqwADpZgdvHBOsrRALVc+FipfDMHIIhJJAz+lXSRdUqvjoiUrv?= =?us-ascii?Q?vx6oxYSGZfgsNUs/NqlNV+15qRVhZCZ+wlsVCRvC9dx59wR4hyWnWnr7uAVd?= =?us-ascii?Q?JTaW2CdvAa69+2p7zB07PBve3VjKoiFcvuheXav+F84bmPA2Bqcmn3fmLM0d?= =?us-ascii?Q?JzlVjeupnQYkDPbhwPzUHl5g4S+T1hRS86b6N3YiEOxQJy+ogm92ykmhWc7o?= =?us-ascii?Q?MA32+5mQP7Cw16ASk+e0g53q34eZYA4hapSfYR4Ai3lJdZMh4suEx3Jabwx8?= =?us-ascii?Q?GmyCPmfDWAw5vp3xBp7eNOtX7oyipeutSpZrl4ahM39Ky9rKJ6OhonR6gpLc?= =?us-ascii?Q?Xpp4nEMltkw2gH6hv632K19clJLFEIYM/yf2xWCmbGf438qqqHOtQRPWgMnw?= =?us-ascii?Q?dmG9NLiDQBwZJ13tqc5aQogdPTKFo9f5PZn/xfOpssqdUb7YH9UPHbQnAVy2?= =?us-ascii?Q?ABnDkmrqI2TWTDJfdZTwOfpJXm5zwB5ade500mCm14/RtpUpMNprkqJuNAqo?= =?us-ascii?Q?OggUE9/ncEeqPylU2Xhq9Kc=3D?= Content-Type: multipart/mixed; boundary="_004_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_" 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 X-OriginatorOrg: willowglensystems.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e0d1db34-39cf-4505-b1b8-08dd7786c6fc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2025 16:51:30.3707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c7bca0fa-9d0c-460d-8770-da688c84194e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hrASBrg8O4FDYCNEuSGB82lwWIgTVvvy4rptFOMKwP3TVuUo9Z6KBiSu2sat/Ka3Cm1XqI/9c1X1HBR6MrqMiR0lk7ngRUrONbeEpXo+KbxRPoqijEwOWKIX848vWR7K X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB6252 X-Spamd-Result: default: False [0.60 / 15.00]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; RBL_SENDERSCORE_REPUT_6(1.00)[40.107.193.98:from]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_LONG(-0.39)[-0.390]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; NEURAL_HAM_SHORT(-0.02)[-0.015]; FROM_HAS_DN(0.00)[]; HAS_ATTACHMENT(0.00)[]; DMARC_POLICY_ALLOW(0.00)[willowglensystems.com,reject]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_ALLOW(0.00)[willowglensystems.com:s=selector1]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[willowglensystems.com:+]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-net@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.193.98:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.193.98:from]; R_SPF_ALLOW(0.00)[+ip4:40.107.0.0/16]; REDIRECTOR_URL(0.00)[aka.ms]; ARC_ALLOW(0.00)[microsoft.com:s=arcselector10001:i=1]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4ZXprD6HrDz411Y X-Spamd-Bar: / --_004_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_ Content-Type: multipart/alternative; boundary="_000_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_" --_000_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: owner-freebsd-current@FreeBSD.org = on behalf of Robert Austen Sent: April 9, 2025 10:44 AM To: Zhenlei Huang Cc: freebsd-current@freebsd.org ; freebsd-net@= freebsd.org ; Kristof Provost ; Cy= Schubert Subject: Re: pfil_default_to_drop You don't often get email from robert.austen@willowglensystems.com. Learn w= hy this is important "Maybe we also want a loader tunable to enable pf(4) on load" Seems a complicated way to do a simple thing. imho. Did you happen to look at my tiny patch? There are already a bunch of macros (PFIL_HOOKED_IN, PFIL_HOOKED_OUT) defi= ned depending on the inclusion of INET v4 or 6. I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the HOOK= ED_ one, or FALSE when INET v4 or 6 is excluded or if PFIL_DEFAULT_TO_DROP isn't defined. Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= calling the filter hook, I just inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = 'goto passin/out' for the 7 occurances in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= d) and the 4 in the NETINET6 code (same as netinet4 plus ip6_foward). easy peasy. I spend 10x more time messing with the kernel Makefile + CONF structure tha= n with my changes lol. ________________________________ From: Zhenlei Huang Sent: April 9, 2025 1:48 AM To: Robert Austen Cc: freebsd-current@freebsd.org ; freebsd-net@= freebsd.org ; Kristof Provost ; Cy= Schubert Subject: Re: pfil_default_to_drop You don't often get email from zlei@freebsd.org. Learn why this is importan= t On Apr 9, 2025, at 1:01 AM, Robert Austen > wrote: I respectfully disagree. PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks. if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= . Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCSTAR= T ) or netlink command to enable it. @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= he pfil layer in the kernel has no idea what the filter will be, assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and l= ikewise the equivalents from the other filters). As for ipfw(4), by default it enables filtering on load, unless you disable= it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable` a= nd `net.link.ether.ipfw`. The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.inet= .ip.fw.default_to_accept` controls the default behavior to drop or accept. See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60= e598498df6f9e2bd . as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP, because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= all, so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= can ever provide. It appears ipf(4) unconditionally enable filtering on load, and does not ha= ve any tunables to control that. CC @Cy who is more familiar with ipf(4). thanks! ________________________________ From: Zhenlei Huang > Sent: April 7, 2025 7:55 PM To: Robert Austen > Cc: freebsd-current@freebsd.org >; freebsd-net@fre= ebsd.org >; Kristof Provost > Subject: Re: pfil_default_to_drop You don't often get email from zlei@freebsd.org. L= earn why this is important On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: ________________________________ From: Robert Austen > Sent: April 7, 2025 4:33 PM To: freebsd-current@freebsd.org >; freebsd-net@fre= ebsd.org > Subject: Fw: pfil_default_to_drop ________________________________ From: Robert Austen Sent: April 7, 2025 4:21 PM To: freebsd-current@freebsd.org > Subject: pfil_default_to_drop Hello, I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point. I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. Hi Robert, So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.k= o ( via the loader(8), /boot/loader.conf ) ? With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), y= ou can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.= ko. See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9= 913226801f3073bd . After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no filter is loaded, i.e. if the heads are unhooked, then PFIL sends everythin= g thru to its destination. So my thought was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the hooks are unhooked. If no firewalls loaded, then the system should behave as is. I do not think= PFIL_DEFAULT_TO_DROP is the right way to handle your case. [No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them, maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.] Normally I'm an embedded linux kernel basher. I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes, so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her if I could... I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch= "... I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64, but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version. But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along. thanks! Robert --_000_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: owner-freebsd-current= @FreeBSD.org <owner-freebsd-current@FreeBSD.org> on behalf of Robert = Austen <robert.austen@willowglensystems.com>
Sent: April 9, 2025 10:44 AM
To: Zhenlei Huang <zlei@FreeBSD.org>
Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>;= freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost &= lt;kp@FreeBSD.org>; Cy Schubert <cy@freebsd.org>
Subject: Re: pfil_default_to_drop
 
You don't often get email from robert.austen@willowglensystems.com. Learn why this is important
"Maybe we also want a loader tunable to enable pf(4) on load"

Seems a complicated way to do a simple thing. imho.

Did you happen to look at my tiny patch?
There are already a bunch of macros  (PFIL_HOOKED_IN, PFIL_HOOKED_OUT)= defined depending on the inclusion of INET v4 or 6.
I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the H= OOKED_ one, or FALSE when INET v4 or 6 is excluded 
or if PFIL_DEFAULT_TO_DROP isn't defined. 

Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= calling the filter hook, I just
inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = 'goto passin/out' for the 7 occurances
in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= d) and the 4 in the NETINET6 code (same as netinet4 plus  ip6_foward).=

easy peasy.
I spend 10x more time messing with the kernel Makefile + CONF structure tha= n with my changes lol.


From: Zhenlei Huang <z= lei@FreeBSD.org>
Sent: April 9, 2025 1:48 AM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>;= freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost &= lt;kp@FreeBSD.org>; Cy Schubert <cy@freebsd.org>
Subject: Re: pfil_default_to_drop
 
You don't often get email from zlei@freebsd.org. Learn why this is important


On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willowgl= ensystems.com> wrote:

I respectfully disagree.

PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks.
if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= .

Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl (&nbs= p;DIOCSTART ) or netlink command to enable it.

@Kristof Maybe we also want a loader tunable to enable pf(4) on load ?=


consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= he pfil layer in the kernel has no idea what the filter will be,
assuming there even is one. thus PF_DEFAULT_TO_DROP  has zero effect (= and likewise the equivalents from the other filters).

As for ipfw(4), by default it enables filtering on load, unless you di= sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= le` and `net.link.ether.ipfw`.

The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable= `net.inet.ip.fw.default_to_accept` controls the default behavior to drop o= r accept.


as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP,
because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= all,
so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= can ever provide.

It appears ipf(4) unconditionally enable filtering on load, and does n= ot have any tunables to control that. CC @Cy who is more familiar with ipf(= 4).


thanks!
From: Z= henlei Huang <zlei@FreeBS= D.org>
Sent: April 7, 2025 7:55 PM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: freebsd-current@= freebsd.org <<= a href=3D"mailto:freebsd-current@freebsd.org" class=3D"">freebsd-current@fr= eebsd.org>; freebsd-net@freebsd.org=  <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBS= D.org>
Subject: <= /span>Re: pfil_default_to_drop
 
You don't often get email from&nb= sp;zlei@freebsd.org. Learn why this is important


On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@willowgl= ensystems.com> wrote:




<= b class=3D"">From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD and PF to build myself a new firewall, as Op= en/FreeBSD + PF seems to be a common starting point.

I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd the like, with the observations that it's hard
to ensure that packets all default to drop if the rule file(s) for whatever= reason fail to load. 

Hi Robert,

So why not defining the compile option PF_DEFAULT_TO_D= ROP, and preload pf.ko ( via the loader(8)= , /boot/loader.conf ) ?

With 13.5, or upcoming 14.3 ( you can also=  experiment latest stable/14 ), you can turn the loader = tunable net.pf.default_to_drop to 1, and preload pf.ko.
See also https://cgit.f= reebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801f3073bd&nb= sp;.


After looking thru the online documentation, forums and scripts, I came to = the conclusion that it's not a PF problem or IPFW etc
or really a problem with any of the filters or scripts, the problem is at t= he level of PFIL, the kernel packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL sends everything=  thru to its destination. So my thought 
was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= DEFAULT_TO_DROP) that drops all the
IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= sen filter (PF or whatever) at any given time the 
hooks are  unhooked. 

If no firewalls loaded, then the system should behave as is= . I do not think PFIL_DEFAULT_TO_DROP is the right way to handle your = case.


[No one filters on local loopback nor the link layer, so I've left those ho= oks untouched. I suppose one could add them,
maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.]

Normally I'm an embedded linux kernel basher.
I'm not entirely sure where to send this patch. Most of the threads asking = the above PF questions are closed to changes,
so that doesn't seem a good place. Sir Dice seems to be a common answerer o= f questions; I would have sent it to him/her 
if I could...

I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"...
I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't change much fr= om platform to platform, or version to version.

But it works, it's pretty simple, pretty small and so just in case it might= be useful, I'm passing it along.

thanks!


Robert




<= FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip>



--_000_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_-- --_004_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_ Content-Type: application/x-zip-compressed; name="FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip" Content-Description: FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip Content-Disposition: attachment; filename="FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip"; size=3358; creation-date="Wed, 09 Apr 2025 16:51:18 GMT"; modification-date="Wed, 09 Apr 2025 16:51:30 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAAAIADhWiVoW/xswLgwAAC4yAAA1AAAARnJlZUJTRC0xNC4xLVJFTEVBU0UtYW1kNjQt cGZpbF9kZWZhdWx0X3RvX2Ryb3AucGF0Y2jdWm1v4kYQ/sxJ9x/2elIEIRBswISkiUoSuNAjgALp mypZxizYOmO7Xrtp2l5/e2df/AI2YNJcVfV0Abw7O7v77DwzO7uem4sFqnhzd/iImugbx5qfBsQ7 JZ5+Sp7Jqe7Yi9PhaNqdoG9s/LSl7u2bSqWyq3FBrsnNSq1RqbWQ1Dxv1M5lpdqQm5LUPqvVUKWm 1Gpv35TLZdZLHiWN82b9XFKqcqMhNRsJJd98gypSrdY4kWqozH/ICArn+FdTx4XC0/LtG/QeuZr+ CfsEPZm+4QQ+8p1AN0x7iXwDo+l0UKoiNDVMgnTNRjOMAoIXgQViyDDnGC1MDz9plkWYsoXnrJDv aTr2QBdGmj1HxFyZluZBC8ciVSrGRMc99bbb6zwOpup0pN4+jMbQAygntGMY5EILLB+5i2KjhLzA wtAeSu1nhH/F3rNPhyiUlamy/iCfOtNC8OdjL1tfmQ9uejMe33TGCNvazAIdugNTfTJM3UCfMHa5 UksjPrIjAAm2fTZhD+vY/BXPmSbHRhpVh4hDxaL50zL1etC5+Xg9+iHsB74NzdbxnNbCwKhGy1ku w7mGiyqfiUWt104kiS6q4/qmYxNU6FMopt2HQuG96YqZksB1Hc8HDSkxdTD6kBANe9siOvr4OE5K u3RJs2TDtYAZjm4+Ft7PLJg9AjOJ0Jo9h4uy3n4y7XYG0zvoRYwaLRyYgY81yzfo7yfNm2+MMG1K hfdzz3ETS7vWXzlqSYd7WNu4V2Ej60Xxmm6W390BfMnCh9HjtKvejzvTOyh++yaPAxKNmXPYWhs7 oa0iW9xQC9xQO48bEmq2OKJ22hE1WjIzWfgWFnt//dhTxw8jWIH+8MPbN7xgMn3oTiYqOLkpLaIY QW2hAB2qK+pTKBUMqBr2JtS0bunP7hRUfCxwqaXlzDSLyaTtgkm4C1pbjtY+XW/y9okV4rqZU4ur pp3rQXeyWdXrX6udwYdRqskERHkZIaxkMuiP1X6vp47GU6GGWKZbNfYag439Uz7MeIHSdcwQdjXe MIP62bncADM4kxpyLW0GeZSERiDJNBq1NqJRu3bSQmX6JZ1RGyC+F+g+YoirBtbm6A+ApWDafoE+ qbbhOJ8IIHgBxZ/px3sgomljTlzKqO6t2h8W3RIqFotpdcclqCpVrhLaTBtdoVppiy5Y1kOUwdBC bYDT6TF8oGN0r+meQ1iIhHgAoYu4WDcXpg4O8JmFDm1GMPh55CwgYjyLiERY61MahMwFjC3TO0Ht 2rgfh+sovEshU0o32Zjsuw0EwkbYInhPf73OYNLd00EshG2wa/gBcPHf6PQYqR+7D8PuAGa+Xgy0 VvnAVKjLRQlzoc48c77EVZ1Z7C4BRo69arIZ0pAlYEkOhiQ05adJq8VcJXwxTwmocGwoPKatWwHs Rb5mrhhAB09ylaz4inoRE/quGl9lliusohxXxC7vq6xOXM3TVnEncQXbnnAD97LqV7NgkVkOLHB0 qBFOoSk2M832Sb3F55sg5wbT1YZSKG4U9cFSFPTnnyijPMnzTaLHuuKyWFlWRYmP7ZV5jlifCRKF LNqYYpqA3/EVjX1UaauWeHLp8rSeiP45RrXQQC5Pv0IwdgPrCOztatv8D5r+1tm/ZPJ5556eem4n H2pcZ8A7lKLF7rlvtIpL8022kWuZG9lrfHrMXBiamL9TJjBi8PTQ0IiBfJr6QJJ5HxCfJpgapBVP 2GOST041cn+Al01t5fqhf/uhqz5M7zqTO3XS/6mb4Hi6slCAfKkRhRbudGSpqTCvI0tnkBc36GaE O2p1HqxWz2AP4QaAujF0vDoJNysm3aEUIEYVeQNmN8UjKqBXroiumgv3BNEPhjYFpoTeXfJNAmwA PewHnn0RaVmhy0s0fBwM0vWfAbwCXRtEBbPwLqE/qExhpS48jFfFVemCPsdKylQJosrEaLH9S4AD XCS6GCRrgj6Hnk3g02g2OD6NMwCqnsBHpGACnrCUOAtfR8dU6xZ8RHfEowgJbPrDLwFNf5hAZumA e6YJ3RoYtNGc+DCSqAu+9QxhmnmONtchwQeg4kHDJCQG1/pYQszOhE01ZelVMeMj/TftKUJttwmF QwutKNEZ/KftzwU2ypnEsWlJ7XW+mbYbhGSDcQHz0DGbdcg/qjcTHDZLDhEI/MzlEPxbsy0ay1eJ VY4kxWBRkVVcFGIdn+FPPNGH6KlciNH7jscLy4Fgr7rGM0FHRyjbDsO2azQNVW4dSDnRdbS4RXMB Z2tsYjOYdylRXehO7+Dg5RqS3vtpZ8wl2cIIkbgfXiaKWS/xU/QgFq7VEo7gTFLEwm1SZJtZ53KU dM6vbdleYNOdFl2Rf+g0bz6qg/5kqvZGD93OzV1xPqPGfhRNwDKJf0KXQrXxb37oQ0LPgqh45Qo+ 6FyjicSeRzgWMR84WYHjjQBfCOjPZEVA35JfAn0G9joHfI9LiUcS61npIfqZQnwFDl6CzTVYW4Ro FXY6Hr3ELSB06wGB49NLMZm1DvKkkCbL2lx1AeAunuYij9wrxZLJfAqzM0q4AGjU6/szyp3q4iM4 OeMITuHWBF9xWonuaVpCs7hPNI+BR9+H035npRG6/xpi/3pyy05gZxoxdeGTA4/t4+gwLOepqvOT ca7QJLCHg0M6aGRBJayFgT1czZPEZuek6STWFafBhyas8OdnVnzCno2tKCOtizuTeq3Jr0zoTH3v WUTxjY0hMzMHlqhKVG0+99AliFeuoElcdiEM+fSYfgJKD4ENqMMmeGkg6kMonNGpOjtZYqCz2Bge mdOmPG1kdr4/GSpthHLOkPC4Z3dDxBtC34SYzMeGrZkYnTu0SjU9QdS/rypXK9X95Btzr+rpvwJN 2djhH4/B7y65Uxh3JpOSwLytcMzbbY656Pmc7Sr8OSZ+jG/8lEZ24mMXNc8R5BdLB+wwuqASMCLX c3RMVS83AM2RGOZCFFruhRRGl40pVGwB1TYqV7ZBA8kuNA/xccy6hIfbKZPHvzHBrd5NBu/WyO/d mLJtvq2ecc9ZF4xtcN+W/6Rs5ji+C44k/xFa6H22VGIdKnL7MpYGZ1YQklVMdN/d6/aYs5c4Iook fBi9fiUG3KedC6LAP3qxNexMERDEM+nNCr3r/d7A1DeBHzc018U2OUE+tqxEK9MNExp2h+rwhN5c Gj7i16iCWBE10bfBykUOXKjRK0BmrQkawn5BuDwN4ortwCWq7sP9afWlzm6mzV/B1zmww4h9OTxc HOABKUsjeh7CSbCH/aQEoZysBMldtKwfRkvQdigvZc5L+fWPsg+lGg3yqm9l0YovJoR1MEjVh+CS yUgNaACvMvgv4jHjZLvOOdkOX8Ug9EiKM9J0wdhWvjMvxkdNUHbMd7eGhe3YGA0Lff01ki/W7kvg 6rx78yVZB3EtN+32x0ORKhF47QReqihG1rVx9LGwtCWB3zY/BgF2LcyZHaxYDGRB8Ah7nuNFCnUN MhDpnCLSM22TGHjOQSmEgduxce5UQAGzV3IkA0wubzqwJryNm0pDghd68nEzrTBNzxqjZ3OdnnJ4 yJdMCaZ3/QmajHrT7zsP3RPU/a47RP0e6tx+1590b9GoBxJdNB5NJv1ruLuf/kiLJo83d+i2c9/5 0M211z/8YupLJwHUByQupdr8UkqpRSmAsicHAPOsArOUOAtQKle0GVSktql9W3dWQEOxK413qTFD q/k2/Mr2/alp74mDyq5AuCveKZsBj23z45AndqhrG1O0NrJDKchwz0FBJpeXgkx4OwVbQEH5IAoy hdsp2KYUfKWd6/473qyIuZ9LOQmYayeam3vrV8J1qclBkRTBPm2piVxQOHPKM93Cmkd0x8XFo4hs sC6li2yJmI6li38hSir7w+Rm3riflsnd6aaPYRPKPluIjxSEieJ5eKxQzflyRWTle/NGJpUvc0yI bmVh89BAyNQdEgYVkSsJDh4cuV5Iw5xM27u3fAkz2Xsm4jXSlhyeuUTopeJbnP0VcXVZzZk5xs1Y Dkn1/1dSx0PZmT9mbqHnQeE0fYJ2GEX3ppFMLGciGcnuYqlyaKwEff8rmob55evnjtn8Dt8Fl/jF KvyQBYttxzYUC2gRuOfMQJk1sUwKHV2iv+7pm9zjC5oi/fDDD2F2lDI5xK97+O3KFyPkF46X9KD1 n4ZMbqnr8fJvUEsBAj8AFAAAAAgAOFaJWhb/GzAuDAAALjIAADUAJAAAAAAAAAAgAAAAAAAAAEZy ZWVCU0QtMTQuMS1SRUxFQVNFLWFtZDY0LXBmaWxfZGVmYXVsdF90b19kcm9wLnBhdGNoCgAgAAAA AAABABgAMjfvZm+p2wH5SqcBBqjbAflKpwEGqNsBUEsFBgAAAAABAAEAhwAAAIEMAAAAAA== --_004_QB1PPF4C719E46AEB54DEB246C72395D15FEFB42QB1PPF4C719E46A_-- From nobody Wed Apr 9 18:31:22 2025 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 4ZXs3j59rGz5sBTd for ; Wed, 09 Apr 2025 18:31:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXs3j2gbHz3gM8 for ; Wed, 09 Apr 2025 18:31:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-6044db3b45bso1277063eaf.1 for ; Wed, 09 Apr 2025 11:31:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744223504; x=1744828304; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6p+M/lj++82O6QOle735zhYzlDKjgeSgCYl3EPF8Qyk=; b=hrUhC4+eJsydEeFp5Akj0MXz8doyaoPgnl1z1nMXMQsxTVrS6DZpY+KOShiTWB/JyP SxiEFzE+I7qaLSz/sgq5iaJG5jXYGxQVQ0vd55pd36OpyY6HzRjP99YaksMkvpKtBcnn U38IjIT+WPio4OqWqa+ZGVIUNV4wEcemInF1uaNj/NJOtPufteN9uv54KlJr72FvXqPp vVCV59JknMv0BGG9/7GHCZYYqTWq8TYp5n669c0k4bmb/0crSRC7mpYIq7OgEccCahx+ hm6lXnCc1XUhMzogNRRFlA6QgPWIQgbBroyAsG4CPVGvAaR2Oa1jgaTiDHDosHU5Uhn7 A8ug== X-Gm-Message-State: AOJu0Yxr7MSiHIxDdGOYa0xaY59FtNBSjUoVmOWnUf2opkOTfu/8pFvK VC8uMmth0AX/pAaMxH7A5960G7qisMJSvXaxoNUrqY4n77zneZwXvq83ecKtPrRwhZvaRRkTX/1 IWdtY/8pB5Vvaj8HCpNsm4PWC/MeQZwLH X-Gm-Gg: ASbGnctutz6JGmoxWZ+/PbEkdJi4EWcXQ/ZabzlDMmBK7qcs6fIOmDQnTr0eJvMiLCI 7xLReYgX4OhT8yiKq09okpNLte3l2g0VSOc/FD42+auKcipGmq//mmvOMkVCB+hCTjjUrG0Rc3o Y3RbjqR9md1qoAiswyrw15Jg== X-Google-Smtp-Source: AGHT+IGEqNVEiDUjCCL7NmZ0YqXZhjPojKhIocAn4JcaI1lcjdES0MF+qgOhZLZmH+vQqClavAjcH4QQ6xOl5l6l4Mk= X-Received: by 2002:a05:6e02:3498:b0:3d6:d145:2ffb with SMTP id e9e14a558f8ab-3d7e4782164mr1691055ab.21.1744223493888; Wed, 09 Apr 2025 11:31:33 -0700 (PDT) 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: Ed Maste Date: Wed, 9 Apr 2025 14:31:22 -0400 X-Gm-Features: ATxdqUFIFp88Q5F-klyENYlZ_68LJ8VuDvoR6EbuzsjUPJP1xd7XBzFvKfxkf4Q Message-ID: Subject: Re: elfcopy: not found To: Sulev-Madis Silber Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4ZXs3j2gbHz3gM8 X-Spamd-Bar: ---- On Wed, 9 Apr 2025 at 10:58, Sulev-Madis Silber wrote: > > but it does indeed turn MK_ELFTOOLCHAIN_BOOTSTRAP to "no" value OK, https://reviews.freebsd.org/D49722 should fix this then (but will break some other, even more unusual cases). I'll see if I can update it to work for those cases too. > i might have optimized myself into hellhole here but what happened within last month that caused this, which change is it? This is the change that will have introduced the breakage: commit b885643b63e4df51cc6c74c4ddd4d0b640075678 Author: Ed Maste Date: Fri Mar 14 12:42:15 2025 -0400 boot: Always use ELF Tool Chain elfcopy for EFI builds We now use llvm-objcopy by default (as of commit 1cae7121c667), but it does not support efi-app-x86_64 and similar ouptut formats (for more detail see LLVM issue 108609[1]). Go back to installing ELF Tool Chain's version of objcopy as elfcopy (the standard upstream name) and use it for EFI builds. [1] https://github.com/llvm/llvm-project/issues/108609). PR: 280771 Reviewed by: andrew Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49362 > my idea was to optimize resulting armv7 build size, not any local crossbuild toolchains. many options are decade old in that config. altho i checked them recently WITHOUT_ELFTOOLCHAIN_BOOTSTRAP won't change the size of the installed system -- it just controls whether ELF Tool Chain (and in particular elfcopy) is built and used as a build tool. From nobody Wed Apr 9 19:12:31 2025 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 4ZXsz56h48z5sDx9 for ; Wed, 09 Apr 2025 19:12:49 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4ZXsz40CVsz3xLL for ; Wed, 09 Apr 2025 19:12:47 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=m9Lvrd73; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1744225953; bh=KKte6ZKtSP2OWOYCYf4UBxINWSN8+mY39EB91Ez9GpM=; h=Date:From:To:Subject:In-Reply-To:References; b=m9Lvrd73AEpC3/y3KTbCn5gkFl/Wtf1HVLPEij6Ac2FeHFCtO3haZmyigDOfTavw2 5VVetO0u5dM4FKetSdfiwDRthlnJqrc/F6IB10LV/rRpDBwDE8mF/gBcxhaB53aRo7 prtIxMrwmcjDH7O754+BLTJiroUYs6XP9PK1JoPhqsBxcmHdejJBNah8IykrH3jles EgU+9+C8nFQDOSjscOQIxOoBW/tPpGcnSRBRkYpM1IbGMCwuybdBnuVkCWT1g0UpPX uE541T6+zll7QKhB3rjN55v+2j1kyv04oY5Wmt4LRXz5O4RJyhMq4hMSGNknwXTlfZ AwkbWIWtB9AZgqe+XW8FoebpwzL6xg/ceTY2h97Hs1Mky3cbmPm6RVvn2wIMYB3iN9 TYJNKJQrFffQlDYFHWHMJOhTUItHtiDH31b/TDgsV0pMgIw+z7Q0uY98f2MLVCnb+Q t8JlHK+JcXMz0cVPe7G2gAT5/qyxXfTaUu+aqivqsVjK7zsJX54Oy9KqCG6HKPuqdJ PdTsZUZJODHvs6vHKiGuFZVocrl3lzRBzwFTkfnv6KogR1T96noBM7jRGeg9fDT/FJ AybRurySzLCPbJj2GqvJ36uJkYoRAqvqdWiDruMF89ArUjazr6M5Mb4vPhkE6WjsQi K2Qt22rsMPlUUX2Plo/+Y3Os= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 2314F5993E7 for ; Wed, 09 Apr 2025 22:12:32 +0300 (EEST) Date: Wed, 09 Apr 2025 22:12:31 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: elfcopy: not found User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <1A736C63-8173-4A02-AD98-059C7612A197@ketas.si.pri.ee> 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-Spamd-Result: default: False [0.96 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-0.98)[-0.983]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_MEDIUM(-0.20)[-0.204]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.05)[-0.054]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4ZXsz40CVsz3xLL X-Spamd-Bar: / On April 9, 2025 9:31:22 PM GMT+03:00, Ed Maste wro= te: >On Wed, 9 Apr 2025 at 10:58, Sulev-Madis Silber > wrote: >> >> but it does indeed turn MK_ELFTOOLCHAIN_BOOTSTRAP to "no" value > >OK, https://reviews=2Efreebsd=2Eorg/D49722 should fix this then (but will >break some other, even more unusual cases)=2E I'll see if I can update >it to work for those cases too=2E > >> i might have optimized myself into hellhole here but what happened with= in last month that caused this, which change is it? > >This is the change that will have introduced the breakage: > >commit b885643b63e4df51cc6c74c4ddd4d0b640075678 >Author: Ed Maste >Date: Fri Mar 14 12:42:15 2025 -0400 > > boot: Always use ELF Tool Chain elfcopy for EFI builds > > We now use llvm-objcopy by default (as of commit 1cae7121c667), but i= t > does not support efi-app-x86_64 and similar ouptut formats (for more > detail see LLVM issue 108609[1])=2E > > Go back to installing ELF Tool Chain's version of objcopy as elfcopy > (the standard upstream name) and use it for EFI builds=2E > > [1] https://github=2Ecom/llvm/llvm-project/issues/108609)=2E > > PR: 280771 > Reviewed by: andrew > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews=2Efreebsd=2Eorg/D49362 > >> my idea was to optimize resulting armv7 build size, not any local cross= build toolchains=2E many options are decade old in that config=2E altho i c= hecked them recently > >WITHOUT_ELFTOOLCHAIN_BOOTSTRAP won't change the size of the installed >system -- it just controls whether ELF Tool Chain (and in particular >elfcopy) is built and used as a build tool=2E is actually commented out there but i think i have something else that's = unneeded=2E but then those people in forums at https://forums=2Efreebsd=2Eo= rg/threads/error-trying-to-upgrade-to-version-15-current=2E97389/ have some= thing else there that also affects this? i might need #2 or #3 time of read= ing src=2Econf manpage to only use options that affect resulting build=2E a= nd which affect build size (main reason)=2E build times decrease a lot too= =2E but i kept all options in file, ordered, for reference purposes, should= i need to turn them on or off oh, i think WITHOUT_CROSS_COMPILER does it, it also turns WITHOUT_ELFTOOLC= HAIN_BOOTSTRAP on=2E i might have overlooked what all those "compiler" opti= ons actually do=2E what i wanted is to exclude compilers from resulting bui= ld target=2E not from build itself did you spot any other options that affect build itself and not target? i would guess pkgbase would eventually fix this "minimize the built system= " issues or build options could have even better clearer documentation=2E tho i'm n= ot that good documenter myself maybe to help to improve it actually the build system confuses me in more way too, as some variables a= re make ones, some could be make or env, some only env=2E meh From nobody Wed Apr 9 20:34:38 2025 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 4ZXvnn3v5dz5sLMv for ; Wed, 09 Apr 2025 20:34:53 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXvnm60Pgz3Z8J for ; Wed, 09 Apr 2025 20:34:52 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5e5e0caa151so220431a12.0 for ; Wed, 09 Apr 2025 13:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744230891; x=1744835691; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hpYTue5vvz6XDrNgQJ3s9uLdhol0q8pF6qjSXbIKbGw=; b=VDnTpQCJ8+f0+Vo3Kh0sjkFkBIg3e2xPxIVWThkIoznMXjZCNU/kbG9bgii85NWg7C lX+Z0k3HCQF6c9wxdcOuRB6IcpptP4W1I4goCGnOFHTb7d1RYJLgoOgr0lpniHlBf9o1 omZQIsvjs0wlevalFIPc57lCuCWnyTW1eX3rPurS2suL+wEgO0xGUQGKuqajDXm5BJAK vkvLT0iEJ/CIJtvjGzhXsKD56oxwpMvtXEOw5JW9KXlTvOp3nWbV4WTEqo9EZR669/9I s3y/6bZFs/PSvVeEoqs5fv/eAdrl5xHOyFofC9QroegLfuTafitZrCrm3F5skfTEcgo+ sCkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744230891; x=1744835691; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hpYTue5vvz6XDrNgQJ3s9uLdhol0q8pF6qjSXbIKbGw=; b=LnfimKJtqPiX161qw4e42zempmyd/k1esqqfGROxNfDidm/MtVqI+WdH3JBClSGEKx w7062zML6B8cnURmM8d0ThrhKlxOJTatS0fI3ojKXVc0fh74bI8wFqLyP23aUUOr4qeQ A+hZ/VD72QgzxNnw6RuakNWv4vuh6zKZzYplTd+gMv0bjOkvzcfe8hPKs+DSI2lrGQnk oXSa0brpr9KQ6pKSW16DGDV2ZFpTN5QpCm29WQDt211jIzPEvThZMkuutD09JuY0oZrN Pz5n7/vP8n6arURZ5hvTKCr5Ww0VkniZgEAwTiEkngz0O3KZjtYRq/N04kVJr5Imq0+n Izaw== X-Gm-Message-State: AOJu0YxEBU1fGDgLQ+1zBb2DuqbyE9NMp8oCAEyITt2NjDlF4eEIS/0c lwSKSbo9NAOXTmb8bIAPi6LcVRp30BX+kepG8O0g1bfvBU6Nwdn9bqs20hmsNIL1A4xhW/OpF0O AtexW5tZFNMR0pAFV6xrLX2dNWSdvvQ4= X-Gm-Gg: ASbGncuEEnoLVrxgkBWpjGKb/+M0nSA+xsIbbaT2mOO1EwqalmsLiEf3ul/5EIFWWLl d5PYE5qbg4ZO/Wce6eY87V64ccYJpT04Grf/Dc5gKVtOcUdZYvcWJkFnxollpzA4US1sR0gab7I ak9ZyqmGYec3Bw8To4S4eMWdUJ1p7wj63IKl+HTLuqrVyc50Mem9N+tQ== X-Google-Smtp-Source: AGHT+IEHZMHOavVErG1Gmp5H9bfsUlzq506EnC+bOEJL7Hk6cwQzqMdYgyomXOH686SmwX2lYpTFcaQe0hytO5vXgFo= X-Received: by 2002:a05:6402:2350:b0:5ec:fb3d:f51f with SMTP id 4fb4d7f45d1cf-5f329249ed3mr233024a12.10.1744230890454; Wed, 09 Apr 2025 13:34:50 -0700 (PDT) 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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> In-Reply-To: From: Rick Macklem Date: Wed, 9 Apr 2025 13:34:38 -0700 X-Gm-Features: ATxdqUFQ9cxxJepAsa9D-IJGeAgIjZViUjDL_NJrsaesZ3m0jVCR8E0FMYGcOZA Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZXvnm60Pgz3Z8J X-Spamd-Bar: ---- On Wed, Apr 9, 2025 at 9:43=E2=80=AFAM Shawn Webb wrote: > > On Sun, Apr 06, 2025 at 02:52:28PM -0700, Rick Macklem wrote: > > On Sat, Apr 5, 2025 at 5:45=E2=80=AFPM Shawn Webb wrote: > > > > > > On Sat, Apr 05, 2025 at 05:36:07PM -0700, Rick Macklem wrote: > > > > On Sat, Apr 5, 2025 at 4:43=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > On Sat, Apr 05, 2025 at 04:12:15PM -0700, Rick Macklem wrote: > > > > > > On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > > > > > > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wr= ote: > > > > > > > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Mackle= m wrote: > > > > > > > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb = wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Ma= cklem wrote: > > > > > > > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn We= bb wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Ric= k Macklem wrote: > > > > > > > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I d= o not think it will > > > > > > > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate c= ommits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch t= o ZFS itself to support > > > > > > > > > > > > > > > named attributes. Is that patch available som= ewhere? > > > > > > > > > > > > > > The ZFS patch is currently in phabricator as D4= 9654. > > > > > > > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.= patch > > > > > > > > > > > > > > (this is a smaller diff which can be applied to= an up-to-date main src > > > > > > > > > > > > > > tree easily) > > > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) = on a file on a ZFS > > > > > > > > > > > > > dataset with xattr=3Don (which seems to be the de= fault) returns 0. Am I > > > > > > > > > > > > > doing something wrong? > > > > > > > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrt= est xattrtest > > > > > > > > > > > > > xattrtest: Named attributes not enabled: No error= : 0 > > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs = list /usr/home/shawn > > > > > > > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get = xattr rpool/usr/home > > > > > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > > > > > rpool/usr/home xattr on default > > > > > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > > > > > > > No idea. It works for me. You used up-to-date kerne= l sources? > > > > > > > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vn= ode.h.) > > > > > > > > > > > > Oh, and one more thing to check. zfs_xattr_compat n= eeds to be non-zero. > > > > > > > > > > > > (It's found in sys/contrib/openzfs/module/os/freebs= d/zfs/zfs_vnops_os.c. > > > > > > > > > > > > It's initialized to 1 and I don't see anything that= sets it to 0?) > > > > > > > > > > > > > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xa= ttr to on, you need to > > > > > > > > > > > > reboot (or at least remount) to get it to take effe= ct. > > > > > > > > > > > > (Maybe try setting it to "dir" and then reboot/remo= unt. Maybe there is > > > > > > > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > > > > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xatt= r defaults to > > > > > > > > > > > "on" in FreeBSD by default. My src tree is synced up = to FreeBSD commit > > > > > > > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought i= n the ZFS patch > > > > > > > > > > > you linked to. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as par= t of a kernel build? > > > > > > > > > > > > (It needs the patched .h files in the kernel source= s, not something in > > > > > > > > > > > > /usr/include/sys > > > > > > > > > > > > that has not yet been updated.) > > > > > > > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS req= uires the sources > > > > > > > > > > > > build for older kernels. (Basically #ifdef'd on tha= t VIRF_NAMEDATTR mentioned > > > > > > > > > > > > above.) > > > > > > > > > > > > > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and= report back. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs= .ko by doing a "make" in > > > > > > > > > > > > the module directory. > > > > > > > > > > > > > > > > > > > > > > > > You can try the attached trivial patch and see if i= t spits out "pathconf ret=3D1" > > > > > > > > > > > > on the console. > > > > > > > > > > > > > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > > > > > > > > > > > > > Clean rebuild didn't resolve it. However, I made some p= rogress. > > > > > > > > > > > > > > > > > > > > I created a dataset specifically for this since I can't= really unmount > > > > > > > > > > my /usr/home dataset, so my example down below is a bit= different than > > > > > > > > > > the previous example I gave. > > > > > > > > > > > > > > > > > > > > The xattr property is set to "on" for the dataset. Howe= ver, it's not > > > > > > > > > > mounted with the xattr property. In order to get it to = work, I had to > > > > > > > > > > run the following commands: > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > > $ sudo zfs umount rpool/scratch/xattr > > > > > > > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scrat= ch/xattr > > > > > > > > > > $ zfs get xattr rpool/scratch/xattr > > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > > rpool/scratch/xattr xattr on local > > > > > > > > > > $ mount | grep xattr > > > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noat= ime, nfsv4acls, named attributes) > > > > > > > > > > $ mount | grep named > > > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noat= ime, nfsv4acls, named attributes) > > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs p= roperty, > > > > > > > > > > otherwise you would see a whole bunch of datasets mount= ed with the > > > > > > > > > > "named attributes" flag in that last `mount | grep` com= mand. > > > > > > > > > I've looked at this a little more... > > > > > > > > > There is a function xattr_changed_cb() that updates the x= attr property > > > > > > > > > information. > > > > > > > > > It gets called when "zfs set xattr=3DXX " is= done or when > > > > > > > > > the mount option "xattr" is set. > > > > > > > > > > > > > > > > > > The question seems to be "Why was the stuff not correctly= set for your file > > > > > > > > > systems, although they show xattr=3Don?" > > > > > > > > > > > > > > This is indeed what I was inferring. xattr has been set to "o= n" since > > > > > > > the pool's creation as far as I can tell. Until experimenting= with > > > > > > > your patch, I didn't really even know the xattr property even= existed. > > > > > > I was able to reproduce this with a fresh zpool. > > > > > > Although it reported "xattr on", that is not really accurate. > > > > > > > > > > > > I stuck a printf() in here (line#853-861 of > > > > > > sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) > > > > > > > > > > > > /* should either have both of these objects or none */ > > > > > > error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, > > > > > > &sa_obj); > > > > > > if (error !=3D 0) > > > > > > return (error); > > > > > > > > > > > > error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); > > > > > > --> The printf here shows that error =3D=3D ENOENT. > > > > > > if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) > > > > > > zfsvfs->z_xattr_sa =3D B_TRUE; > > > > > > > > > > > > The printf() of error showed ENOENT. So, "xattr" actually does = not > > > > > > exist. "zfs get xattr " calls it "on" but that's n= ot accurate. > > > > > > > > > > > > As root, I did: > > > > > > # zfs set xattr=3Ddir > > > > > > - reboot > > > > > > > > > > > > This makes it work, although the above call still returns ENOEN= T. > > > > > > It looks to me like zfsvfs_init() gets called from zfsvfs_creat= e() > > > > > > right at the beginning of zfs_domount(). > > > > > > Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_ca= llbacks(), > > > > > > which now finds the property (because of the "zfs set xattr=3Dd= ir ") > > > > > > and registers it via dsl_prop_register(). > > > > > > > > > > > > I don't know if the above is correct? > > > > > > Personally, I would prefer to see "zfs get xattr "= reply "not set" > > > > > > instead of "on". > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > Setting the property makes it work, but only after rebooting > > > > > > (a umount/mount would probably have the same effect, I think?). > > > > > > > > > > So I wonder why neither an unmount/mount nor a reboot causes `mou= nt | > > > > > grep "named attribute"` to fail for me. HardenedBSD doesn't have = any > > > > > changes to ZFS that would cause that kind of behavior. I have to > > > > > unmount, but manually mount with `mount -t zfs -o xattr ...` in o= rder > > > > > to access the new feature you wrote. Weird. > > > > So, you have done > > > > # zfs set xattr=3Ddir > > > > followed by a reboot and it still doesn't work? > > > > > > Correct, even a reboot does not work. > > No idea. If you apply the atteched little patch (just printf's) and pos= t > > what gets printed out (when a mount that doesn't work is done), > > it might help explain it. > > Turns out this was a big case of PEBCAK. I had misunderstood which > value the xattr property should have been set to. After setting it to > "dir" and rebooting, the ZFS datasets are now mounted with named > attributes support. Sounds good. I'll admit it would be nice if "zfs get xattr" reported "dir" instead of "on", but that's for another day. > > Thanks for your patience and I apologize for the noise. Now it's time > to figure out how best to prevent fdlopen(extattrfd). :-) At this time (I haven't yet been able to verify that Solaris does it this w= ay), permission to access the named attribute directory is defined by the permis= sions on the parent object. However, the individual attributes are regular files and permission is controlled for them the same way as any other regular file (mode, uid, gid, ACL). (So, I don't think there is any difference for fdlopen() from any other regular file's fd argument?) Have fun with it, rick ps: The access permission stuff is in the ZFS patch, so can be changed if t= hat seems appropriate. > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Wed Apr 9 23:28:58 2025 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 4ZXzj12T65z5sYN0 for ; Wed, 09 Apr 2025 23:31:01 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4ZXzj01jrlz3c5V for ; Wed, 09 Apr 2025 23:30:59 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=h2F2sCwN; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1744241455; bh=AQrexH3oPuQswUxlCRw6iIKiyAP6+fBoMVtLriNig9Y=; h=Date:From:To:Subject:In-Reply-To:References; b=h2F2sCwNjrtUqRshrhAUo4/iYVgEj65qf6Rki2ZjGyoKNGpqvMUsdO5MgpGr15cWm nK7PAfFFG/NpXBaWhn5YvF+MSwkV0yUQDvPMTDY/iQAFJSOuOwEBIDyP+iBCNoaZge cCNCD5RF4ONIzv9DrIzpLt2tyUfx9Izk4hESdoGVJxMsPSdDy/IjVBuP0Nd1tllKFG XcKhGWafamt5iHHY210c1AFaAoXkvU1gk4hKtZrm8qDNIBz6kAHGY3iPAMS6x/Ayn3 huaa3Wnlj03HTwE99a3L34+SgZTFxYAakSB+6C8r75z3OYhtc5KoBGZtLniqwg41Ma 3BEmThvHKR9jUvNznB4Szdc9ufZ1sXyyJbcz+royD2Q6xrw6fR0D+NS7u2pJDA32aY vz3qnqVy0St8rGa3qYOG3lFRbwXPv2s8z+BZOr6ZrcaU0dI4VC4Oreabp/2u1CfM+f EHaPPuwOwJNnXTnvwvaV/smTzWEudANQw2uk9eP3M0DvwSUZV1DIMxAS9kWNp8EDRd zdC5ZpVZ0zW34RFtOIw30rCR9swmjXDnezxzabrMf1IPIrzR69NGZ+JlpT58bxz33w lFdlghTG1aqMsOP9mDKn1Mg316yIVD/iyrBYJjgHo697zSG1cq2UDSjpOIbT1qsBIy +qTEmT6j9UUh8n18hLV0rx68= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 47AFE59A818 for ; Thu, 10 Apr 2025 02:30:55 +0300 (EEST) Date: Thu, 10 Apr 2025 02:28:58 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: elfcopy: not found User-Agent: K-9 Mail for Android In-Reply-To: <1A736C63-8173-4A02-AD98-059C7612A197@ketas.si.pri.ee> References: <1A736C63-8173-4A02-AD98-059C7612A197@ketas.si.pri.ee> 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-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [2.13 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-0.98)[-0.979]; NEURAL_SPAM_MEDIUM(0.57)[0.566]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_SPAM_SHORT(0.34)[0.344]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4ZXzj01jrlz3c5V X-Spamd-Bar: ++ i see that there's revised version of proposed fix committed now and everyo= ne can keep their configs this closes the issue at least for now From nobody Thu Apr 10 13:36:38 2025 X-Original-To: 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 4ZYLSp2WDlz5sy8Q; Thu, 10 Apr 2025 13:36:42 +0000 (UTC) (envelope-from bz@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZYLSp07Gyz3w2V; Thu, 10 Apr 2025 13:36:42 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744292202; 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=G4ZgaF9YCbU8E1vXYyiKJsbw0o4/WebyNcLiQmtzcbI=; b=mijFeery2J8BNlyq3CxjcK7jhxonLJttWtlLDnsnipK72uoUudNEM59f5pNXFUDrIZ5Dho byddr+ANKrj+2x02bNvVqK2PrF6sEuQks6eMqBc190mdNsDEGpa76QGXwspxajGFtIJ949 cn+ROX74ORs6Itw0NmOnXHLIBFatsSfkB9VVwMgWzaxYuj5Kn6hDPlqszOhv4LPoYr0tqh VJ2tdMYQAgDXmAdsf9jHQXPF2zc2rutiC80yzBVCL1M8czzgUOn0z/aLbjAlIJsxHjJc2O LZycg0F779LZUhDoHU/hhzT3EXwGSOlGpOE/r4wjBJL84eFUyILrUGyL8zrHVA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744292202; a=rsa-sha256; cv=none; b=Iyh5ZuGb7j4k6XReq+bwxv83+Rm6xbfvE4zOlwwRmjjLsknT9kBhPAE9u9aNI9o+tv7TLP josVEYUB4RPcDtkWDygAC+JsTx43M9lBNkuCf3x+AbQ/MT3xOoCymLgGFbIjSCuBdfweGl lQwR/fg3PnRhu+SLelYbmL7un+07KrtUVcI6H9gEqWjq+Ef2Mt+xb+MKj692v0yWuK/1Fq avQuq+0ovKeZC4DogJtP4ShJBX461/H4dbsb00OR9tXaSzw8S/U2kmQY0J9eWzVBcOLJox gzKL8H8nhQJqKZvePVuil4jcsSu1rE9YlcxosCybz/bUErLO+I0QVFI4nvLfsA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744292202; 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=G4ZgaF9YCbU8E1vXYyiKJsbw0o4/WebyNcLiQmtzcbI=; b=MtLFHHITpyUPN9ejPMip+R8vWA1erKStcr3wtYyQTPDtm+tJnIVSNyGtR/JwzW/BRCEcyy zcMmfH4T6NJsdVHdgP67p2RDBUdhwgCj0SZ2hI4vhsQkcDDF1GoXHA7W6f1s2tQtTgWxFJ BoUMRzyWPaAR8zG/wuIj01fezpOE8//oVQRZEYFx2s0MkW+PdJFG2fd5QPNmBrdzRHl8LP BeuQQBZq7Gh/RLaKT6FcfoIXJHUxeTPyMd25QK4yf9CoiBWoncYEx1fV0QkM7kXSpvdNLE Mek6EBUaqJil/OJTJ73TNcDcL/UrR+5mX2u9mtAAFKoBWL+e2Fgs5m92OfX7mA== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZYLSn511tz104P; Thu, 10 Apr 2025 13:36:41 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 2193AA64806; Thu, 10 Apr 2025 13:36:40 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 06FD02D029E0; Thu, 10 Apr 2025 13:36:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id EDKehGIjyd5Z; Thu, 10 Apr 2025 13:36:38 +0000 (UTC) Received: from strong-rtwn0.sbone.de (strong-rtwn0.sbone.de [IPv6:fde9:577b:c1a9:4902:3e64:cfff:fe55:bc80]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D51462D029D8; Thu, 10 Apr 2025 13:36:38 +0000 (UTC) Date: Thu, 10 Apr 2025 13:36:38 +0000 (UTC) From: "Bjoern A. Zeeb" To: FreeBSD wireless mailing list cc: current@freebsd.org, stable@freebsd.org, desktop@freebsd.org Subject: HEADS UP: iwlwifi firmware removed from main (stable/14 to follow), run fwget before updating In-Reply-To: <02s8on48-41s3-1s5n-4nqn-0s88434946q3@SerrOFQ.bet> Message-ID: <5p424pns-6p6s-1952-r39o-q20s240o7opn@SerrOFQ.bet> References: <02s8on48-41s3-1s5n-4nqn-0s88434946q3@SerrOFQ.bet> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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; format=flowed; charset=US-ASCII On Wed, 19 Mar 2025, Bjoern A. Zeeb wrote: Hi, before updating your system please run fwget(8) or build wifi-firmware-iwlwifi-kmod (or the appropriate flavor) from ports if you are using iwlwifi(4) or iwx(4). You can do it any time as the extra firmware files will do no harm until your next reboot at least. As announced almost a month ago firmware just got removed from the src repository main branch [1]. stable/14 will follow in a few days. If you are using iwlwifi(4) you may get automatically upgraded to HT and VHT support by the tunables the firmware installs along (if you haven't done yourself in the last weeks already). I wrote a summary for testing [2] the other day and the freebsd wireless list is generally a good place to follow and the right place to follow up. The email may also help in case you face problems though I am fervently working on solving open problems currently, so by the time you update they may already be gone.. (famous last words). [1] https://cgit.FreeBSD.org/src/commit/?id=558d638896239f9cd25b9d825ecfce62ec54681e [2] https://lists.freebsd.org/archives/freebsd-wireless/2025-April/003131.html Lots of joy, Bjoern > I pushed an update to the iwlwifi firmware port today[1] and with the last > release of FreeBSD 13 being out the door, 14.1-Release EoL end of this > month passed and the packages for the updated port appearing I'll > > !!! > remove iwlwifi firmware from src.git for main and stable/14 > some time early April. > !!! > > > * What you need to do? > > Please run fwget(8) to install the right firmware package for your chipset > if you have not already and then pkg upgrades will provide updates as needed. > You can do this today already as that won't change the status quo compared > to what is in the tree. > > > * Why is this happening? > > iwlwifi following rtw88 and rtw89 after a request from core to not add > more binary blob wireless firmware into src.git (accumulated firmware > for a set of modern wireless drivers at that time would have been > slightly over 100MB if I remember correctly with the amount increasing). > > As a result firmware was put into ports, broken down into flavors, added > to fwget(8) to automatically install it, updated the port to no longer > install kernel modules but firmware files on 14.2-R and later, enhanced > the install media to contain firmware so wireless-only laptops could have > connectivity with these drivers, and enhanced the installer to have a step > to run fwget and install firmware into the new installation. All of this > shipped in 14.2-R already. > Thanks to everyone who helped along these steps to make it all happen. > > > * What's your bonus? > > If you have't already tried yourself, the updated port will also turn on > HT and VHT by default for iwlwifi chipsets 22000, ax210, and bz (that's > AX200 and newer) on both main and stable/14. > Reports so far have been encouraging enough from some people who've been > testing during the last weeks (the rough edges being sorted step but > step now). For more information about how to test, about older chipsets, > or other drivers see the wireless mailing list archive[2] of this year > and the FreeBSD Foundation Laptop Project on github [3] for links to the > postings. > > Please follow up as appropriate on the wireless list. > > > Lots of health and joy, > Bjoern > > > [1] > https://cgit.freebsd.org/ports/commit/?id=ef3fa2a325a592baa6573782a72cf0d833589ffa > [2] https://lists.freebsd.org/archives/freebsd-wireless/ > [3] https://github.com/FreeBSDFoundation/proj-laptop/ > > -- Bjoern A. Zeeb r15:7 From nobody Thu Apr 10 14:03:35 2025 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 4ZYM435zYhz5t0Qy for ; Thu, 10 Apr 2025 14:03:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZYM433853z42lm for ; Thu, 10 Apr 2025 14:03:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-86135af1045so78601439f.1 for ; Thu, 10 Apr 2025 07:03:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744293826; x=1744898626; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mtNUu9Yqz4e8lVsNvGc8fuL10VOGqaWGzMXupqJFP7w=; b=gYk4uvAp2TO5Ea/MCrq/jLGk+50oLp77urE3LRLD1la4yLnl6vQzZrNlXCVy5FGjIi +uOx+JPygTqKdMojPN/62gOV+fY6UtlFuqqltYbhovUyKW54Oy/R0xyYOwVSmwesP7eW r6L2A8lqK80mukQnvidDwpm0+C/+9oI+xsMFv1j+rVkR6ISpujXXY8EKnAtlKuFjHaJY iTFC8K2sVJLDm7+6V8U/qMPQVrlWLu4KibLGgz90zxHEswQPPJbda8sEpzeiZe24ahid 0Tkd2wo/05SZQipRIGMUn9K5ySR7rZGDQoBW49PmIqui85S8oDD4NUhgLiOPbpdE7HVU lJkg== X-Gm-Message-State: AOJu0Yy8V6mN9h15VaN+8aWEGsGbIAD1KOg0nz+0k61ntcUPTSV//qi7 OKs5tNRHgXAWWVJ/1m34NIhYEQK3a1smyzgdTBtAgNzD1YqWXHvLe/k+vyYKjmt/cpeNtCpPwdl oCWPbdRFit+FQXhibxPbTB9bMiTMeUw== X-Gm-Gg: ASbGncugcmq5jVUcLaAODXCeNWqFm/RdJo7+ik661d/dsaG9LY5bzoJ7DTCPV8Ramfo OsUcL30wLzsktNlrIbi/HKsEHK2cX+BjD/yYc7m0j8cFj9wTQQWNEkzL26zQ2DrX4olKzPG6knL YUCF2Q51TEgXV22EuPU65YRviz/da546L/mir+F2PWuJksWH894ag7tZvF X-Google-Smtp-Source: AGHT+IEMtsZ0FjPqG0lRzKq/no9e0ETUO7XBaq4VSU0uW6zeRVVmYXv5y/6d6z2IYUe8srq96Iwj/Hz3ii1nOkx3cYA= X-Received: by 2002:a05:6e02:2220:b0:3d1:a75e:65f6 with SMTP id e9e14a558f8ab-3d7e5fcfe03mr30076865ab.18.1744293826440; Thu, 10 Apr 2025 07:03:46 -0700 (PDT) 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: <1A736C63-8173-4A02-AD98-059C7612A197@ketas.si.pri.ee> In-Reply-To: <1A736C63-8173-4A02-AD98-059C7612A197@ketas.si.pri.ee> From: Ed Maste Date: Thu, 10 Apr 2025 10:03:35 -0400 X-Gm-Features: ATxdqUHfuRRSaSbFXQ_9mP54I00iXgONGbqhEsL5C4H1gtqAp88SH523j3ovVig Message-ID: Subject: Re: elfcopy: not found To: Sulev-Madis Silber Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4ZYM433853z42lm X-Spamd-Bar: ---- On Wed, 9 Apr 2025 at 15:13, Sulev-Madis Silber wrote: > > oh, i think WITHOUT_CROSS_COMPILER does it, it also turns WITHOUT_ELFTOOLCHAIN_BOOTSTRAP on. i might have overlooked what all those "compiler" options actually do. what i wanted is to exclude compilers from resulting build target. not from build itself Ah yes, WITHOUT_CROSS_COMPILER implying WITHOUT_ELFTOOLCHAIN_BOOTSTRAP will explain it. We need to make it clear in src.conf which options affect the build environment and which affect the target. > i would guess pkgbase would eventually fix this "minimize the built system" issues Yes, pkgbase will make it easier to build minimal FreeBSD installations with just the functionality desired. Anyhow as you point out in your later email this should be resolved for now, but I'll keep an eye on it in case there are any remaining issues. From nobody Thu Apr 10 16:25:53 2025 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 4ZYQDV277Jz5t7NJ for ; Thu, 10 Apr 2025 16:26:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4ZYQDS31vfz3jYs for ; Thu, 10 Apr 2025 16:26:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jh+QSGMf; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744302370; bh=2mxJJNAGNcPwFPfelcvC2Mr3IIfoycoj4CFvJospZJ4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jh+QSGMfdklUNkxU8WLULiu9NFQx12r0UF1DH4sDGA8Bz1icH7GdqwzAy3sPtCWSCQqkLiIWk5cG8S6IuVWIBLdyAzaG8E/ZotAopYeNz53ud7ew1mGA+jH8HkzYsuWe6a+u6rM7LHhDq8uJhGvlm4SnezB+acnNJT30eAEzFt3+NPU0DlpI0P8qmg6Ya4PyRNoxdOtDHZI9rUlXTnbtrwfCBSfthgyD4pgz/+/l924Au9FmKEMSdV5C3rDvp/bErc4vLGZrjZV/qpkC74/QzwZDGuQ/P6m6OTg5wUbZJ3lu5rBwXQ4M35LOVMJl6U27CsfVmAR33qzfAqNr28M4IQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744302370; bh=ItEpbq/jS7JEGv1dlWq1hMO9AIhygiAwpMi754Oc4Sc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZXd/j7AkRLt7iwD98UJuGCpMu1PHcNyGPV0kRIGLqg6m+LEqfq9Hn6qmsOmAMjxxJvSdVa4lexZb4a1L15Vl/50FRlvFmFamVrHUKj/U8RcZbz4wEZOKHuIFB2z+9Pre9aO1ATci9yAry6iFe3VMYmJ4T4qVsDhPNglqvnPrfgN6896+M6tKsRfu36Vz0v97YbrhmwtxpvPoo9Ls4u87+S/P/6EyOFpbammzgxV6dg2jTKE5LNbWUxkYZwl4Z4C/allbiXc/A1GM7y7nok2O/tlUV6rNoxlHePOgRENK3n+JLr5xMIwZM3O8XXJNhJKCs2FWyOGdqe4fTzcM0AJ0ow== X-YMail-OSG: .W3J1CkVM1lCGqMcezsOblCe4czPHVPrhG7TIiG2BeGCH6WwQ9EFQ0YJBLJWKwz hv_jXjgVnGF4hVnRJAO3a.RwaHOjTOYwFzGCPlT9suNuaHSRNINGS1RHBOtHSDIDvsI0vXY6tHi. .Z4wX4lPEDcOr52GGYWxkJ2TDoQtcy4Ne8g5aAVXb1kD4iF0xJjWnYorbogI2cbkIZWZmfOSpTeI H2yKav.3awUSuGgeuw3Hxrh9XEWU7yAyyc0jb1p0hByko4U9TY1YvxCZVJRT5VxtqA6yUrjlSXEZ xys7WZiR20ELhLtG1IG2ca0JSLLm_KSgZLSYojyKEGHKmeRTuRTMHq8gwFQZBSZJKxCJAE3lWA_6 RZE0Eu7iMd2EzFuImmIWmEqoi4tTMh0q3lYpjdPGZaTLtm7U4yU96djoKLnL5caz_bVLsiuFiq8Z Jc9YUaVuwzC1bIEJ7jd5y4smbTB.LB4A5hfvZEIEbpnFc4B2Q5e9mMzRsFmnMtcK4kre9GfTiouw Nsc5oKuhdbiD02IV..NeWhARiNcztn2TzoQd2QOuegH556b2mxkAH5s991LQm093WOMJaTwK2kAq Sm9vY4qtH1L.OeSPE_YfLwIAC0DOQr_K4iPXLFPJXTMS7Z5k2rjp9dk5sB.kUVR_pkUiJbEjE7N3 SvTOYqCLQq.PGQGZbZgswdcNfAzKpsKwgid_2ojAxxo7C.7.exnStFrh4uuYisnnWxfk7KjQWX5F RWPYfJCfYi7H8mOGddRbOpWOooy8AwJ7RlaxUZu3HxRJfOFiQhOX1uhzlg4FoG4BFQxnJi_XVa7u p.hmKjzSZovvhw4j9gDgxoUR828Zo1Jz8iyn8ENJdSi4RvwLqdylBPY0T9cBitQbQxzXLQa32r6. DRVokG7tXzKY_.87paiZ4.LIoCJ20u3n_sjeWCRM4nKrqhMBOf4VGb.zRL_mdsD9rG_VzO9I_EQ4 8v0kaEHaJ.S3TFrCkobj.rgIwFkCR34mT2Off59TF3zPR859RT5qmuh4l7y4xF2pmCplV4Nn659C 9pTItZX_lGsE25ahf3B88nhkMODD9iUOwiNg3SE3_BHPozR6TJ2AnCVApeWSXXcW4Muyx8yYx7yK 7_Yr7Jz0M5h9MLlNFGPHys6RtNoYGifZ2L823NsFKVsNo22zokAxLVj_tzBwm182mpU7quTDuJt8 bMC8vjSpex6jiFx3Bis3Fo3cj6oHAb3k8z8CvGK5xZCZIiZg3b4fA.4JzEN1YkrO1ucNCckuRGBz dWP_vDo.QdLOgFWEWimtdusmEfJOZ4PyZhFbY63PQZ0GKwapzVAVIyeH5cdEYPVbDlx0g9EWv.iH pLgl_LI1tIhcztKpL2u58TpTZ.Z.jf7Fa09K6WDJmYKa7jVtH1ythueTOaI89McBweGYlGB8uFK4 fFnePp6IuCTeLDKBRl5nC_SfY46kJT.W4XpRzxcdbT2gO99K6u7EOhwCEg9rUlKElMw8XtHJMGkp 1.86.YuPrmd6f3_dW5lnOYXIXagtdfCjhTvVuRCMDFK4RHRnNg_PtERdEgbNAkdsPB1EfYLvpHl6 RH4v4MKzFfdPmezM0XUsTkqMfITVxCWDoDS4bXNheXf.7eD7KdDW32XyZynoKBdfuy7RNdcsgOmO 4D1CvlvSWLszAJlrwwo7tyyFMtn6jOqIRlg4S9DKDIDSs3GpWDDqeivvxVBcbyC_4FKs5Pa5JZ4u tPvkWsrUuuFuSyK0S1zy00RpV0bk70rzvFPuWIRcSGxDvTbDi4NXZTk56sIKU3gFt5lpPVrXl68b icKNBmO_55Sav..RdCNJV4fp0v_RMoF5SdzjtBIhbG6cZmhYd.YCbtNL0kLTb9JXSMQs2He1jkWo 4US4htM_StX.t79T2YLWzs_e3Cj1Z7ewxFukiIoMcN2bzOYWgjeD0.x4U3Th7zzB_cCfgIY3iakJ bzkD76g8UGiibOnN5pHo.u1x7_r9he8OiAku8mgaS.ZoE0W1LHsRJNw0QP1JkXcV586aPbZ6LBQT EMU_af3ehqRrP1gveZqc9AvjFYsIGQmrGEKqC8IOlsne0qrXnHNoyE7RLFzm8vPY6VNse5TMSwTN Ny96iADPNg4uP2tBiolDjjVEv50Hp1mOjmoZ1L2M6WfoxIofacqyJOBkcBOi1H_aX_LOFQ.ZhEpe lsXx6TRO2E0jYNJFIZSjTnoWgTZpg1djf2zXbQdg4lJgUUUY9Cr.mKfh8PIJeHMuzFiQBHfyRjuP 1_hv3DqIcb6z3Q.EYcGaSGuVlDd_EZgrjtpg6SKFwBQSqGqsinO_MAC0a4wKoym7tFn0hEwv2Aaj LwzaVs2WI X-Sonic-MF: X-Sonic-ID: 90383cf2-d1f0-4311-b91b-49e9f1e55999 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 10 Apr 2025 16:26:10 +0000 Received: by hermes--production-gq1-6f8bfcd964-fl6ms (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 129060d3ccdfef354133fa8524f36771; Thu, 10 Apr 2025 16:26:04 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {patch,build,lib}-depends timings for bulk -a --and related notes] From: Mark Millard In-Reply-To: Date: Thu, 10 Apr 2025 09:25:53 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-2.71 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.68.205:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.79)[0.790]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FREEMAIL_FROM(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZYQDS31vfz3jYs X-Spamd-Bar: -- The following data are from later in the builder seqeunce. Here I'm not looking at builder activity with large Elapsed multiplication factors for the build. It is more of a random sampling showing examples of build-depends, lib-depends, and run-depends and some with more than one of those notably contributing. This is later when dependencies are normally involve for the package builds. A property of the dependency based ordering of builds is that the earlier builds tend of have fewer dependencies and the later builds tend to have more. For building around 36000 packages, even a mean rate of around 1 extra second per is around 10 hrs of extra time. (But normal extra times are not generally near the mean-extra-time.) It appears that a big factor in the overall Elapsed time is the large fraction of the 30000+ packages that are "small build step" packages --the subset of that for which build later because of involved dependencies. The dependency analysis is more time consuming than the build time --or even total for all of the steps other than build-depends, lib-depends, and run-depends. Basically: for the most part, only early builder runs can be quick runs (no or very limited dependencies involved). It would take a massive decrease in most build-depends, lib-depends, and run-depends (when any) Elapsed times in later builds for this not to be the case --because of the number of packages for which the rest of the time is small. Such does not seem likely? The supporting detail . . . I'll note that the 3 load averages reported by top for the below were near the number of FreeBSD cpus whenever I happened to check that, instead of being during high load average time frames. (I.e., no packages with large builder steps were active.) There is a later explanation of this. Both build-depends and lib-depends: # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep -B4 = -A3 -e "^\[03:52:[0-9][0-9]\] .*configure$" | more . . . [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch-depends [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch [03:50:59] [14] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = build-depends [03:52:17] [14] [00:01:35] Status devel/dwarves | dwarves-1.19_3: = lib-depends [03:52:28] [14] [00:01:46] Status devel/dwarves | dwarves-1.19_3: = configure [03:52:31] [14] [00:01:49] Status devel/dwarves | dwarves-1.19_3: = build [03:52:33] [14] [00:01:51] Status devel/dwarves | dwarves-1.19_3: = run-depends [03:52:34] [14] [00:01:52] Status devel/dwarves | dwarves-1.19_3: = stage . . . -- [03:52:08] [01] [00:00:08] Status security/seccure | seccure-0.5_10: = patch-depends [03:52:08] [01] [00:00:08] Status security/seccure | seccure-0.5_10: = patch [03:52:08] [01] [00:00:08] Status security/seccure | seccure-0.5_10: = build-depends [03:52:18] [01] [00:00:18] Status security/seccure | seccure-0.5_10: = lib-depends [03:52:31] [01] [00:00:31] Status security/seccure | seccure-0.5_10: = configure [03:52:31] [01] [00:00:31] Status security/seccure | seccure-0.5_10: = build [03:52:32] [01] [00:00:32] Status security/seccure | seccure-0.5_10: = run-depends [03:52:32] [01] [00:00:32] Status security/seccure | seccure-0.5_10: = stage lib-depends: # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep -B4 = -A3 -e "^\[05:20:[0-9][0-9]\] .*configure$" | more . . . -- [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch-depends [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: build-depends [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: lib-depends [05:20:08] [05] [00:00:43] Status graphics/gdchart | = gdchart-0.11.5_11: configure [05:20:09] [05] [00:00:44] Status graphics/gdchart | = gdchart-0.11.5_11: build [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: run-depends [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: stage . . . -- [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch-depends [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch [05:20:03] [06] [00:02:05] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build-depends [05:20:04] [06] [00:02:06] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: lib-depends [05:20:26] [06] [00:02:28] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: configure [05:20:27] [06] [00:02:29] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: run-depends [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: stage build-depends and run-depends: # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep -B4 = -A3 -e "^\[09:15:[0-9][0-9]\] .*configure$" | more [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch-depends [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build-depends [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: lib-depends [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: configure [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: run-depends [09:16:01] [07] [00:01:02] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: stage . . . -- [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch-depends [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build-depends [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: lib-depends [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: configure [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: run-depends [09:16:08] [04] [00:01:08] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: stage . . . -- [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch-depends [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build-depends [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: lib-depends [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: configure [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: run-depends [09:16:19] [13] [00:01:23] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: stage -- [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch-depends [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build-depends [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: lib-depends [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: configure [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: run-depends [09:15:21] [02] [00:00:41] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: stage -- [09:14:59] [09] [00:00:03] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: patch-depends [09:15:00] [09] [00:00:04] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: patch [09:15:00] [09] [00:00:04] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: build-depends [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: lib-depends [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: configure [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: build [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: run-depends [09:15:59] [09] [00:01:03] Status security/pear-Horde_Group@php82 | = php82-pear-horde-Horde_Group-2.1.1: stage -- [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch-depends [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build-depends [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: lib-depends [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: configure [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: run-depends [09:16:00] [14] [00:01:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: stage Mostly build-depends but one also has lib-depends: # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep -B4 = -A3 -e "^\[11:10:[0-9][0-9]\] .*configure$" | more [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch-depends [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build-depends [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: lib-depends [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: configure [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: run-depends [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: stage -- [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch-depends [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch [11:09:54] [04] [00:00:11] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build-depends [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: lib-depends [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: configure [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: run-depends [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: stage -- [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch-depends [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch [11:09:37] [12] [00:00:15] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build-depends [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: lib-depends [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: configure [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: run-depends [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: stage -- [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: = patch-depends [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: patch [11:09:16] [05] [00:00:19] Status devel/obby | obby-0.4.8_6: = build-depends [11:09:59] [05] [00:01:02] Status devel/obby | obby-0.4.8_6: = lib-depends [11:10:21] [05] [00:01:24] Status devel/obby | obby-0.4.8_6: = configure [11:10:26] [05] [00:01:29] Status devel/obby | obby-0.4.8_6: build [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: = run-depends [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: stage -- [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch-depends [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build-depends [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: lib-depends [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: configure [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: run-depends [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: stage -- [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch-depends [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build-depends [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: lib-depends [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: configure [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: run-depends [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: stage -- [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch-depends [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build-depends [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: lib-depends [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: configure [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: run-depends [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: stage -- [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch-depends [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch [11:09:46] [09] [00:00:13] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build-depends [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: lib-depends [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: configure [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: run-depends [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: stage -- [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [11:09:51] [13] [00:00:17] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [11:09:52] [13] [00:00:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [11:10:14] [13] [00:00:40] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [11:10:38] [13] [00:01:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage -- [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch-depends [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build-depends [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: lib-depends [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: configure [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: run-depends [11:10:29] [12] [00:00:28] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: stage build-depends: # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep -B4 = -A3 -e "^\[12:47:[0-9][0-9]\] .*configure$" | more [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch-depends [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build-depends [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: lib-depends [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: configure [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: run-depends [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: stage -- [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch-depends [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build-depends [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: lib-depends [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: configure [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: run-depends [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: stage -- [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch-depends [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build-depends [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: lib-depends [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: configure [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: run-depends [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: stage -- [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: patch-depends [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: patch [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: build-depends [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: lib-depends [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: configure [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: build [12:47:13] [09] [00:02:15] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: run-depends [12:47:13] [09] [00:02:15] Status www/p5-Catalyst-View-XML-Simple | = p5-Catalyst-View-XML-Simple-0.01_2: stage -- [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch-depends [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build-depends [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: lib-depends [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: configure [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: run-depends [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: stage -- [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch-depends [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build-depends [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: lib-depends [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: configure [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: run-depends [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: stage build-depends and run-depends: # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep -B4 = -A3 -e "^\[14:03:[0-9][0-9]\] .*configure$" | more [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch-depends [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build-depends [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = lib-depends [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = configure [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = run-depends [14:04:43] [14] [00:01:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = stage -- [14:02:22] [01] [00:00:08] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch-depends [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build-depends [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: lib-depends [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: configure [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: run-depends [14:03:43] [01] [00:01:29] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: stage -- [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends [14:05:07] [03] [00:02:19] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage -- [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: patch-depends [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: patch [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: build-depends [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: lib-depends [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: configure [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: build [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: run-depends [14:05:38] [02] [00:02:54] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: stage -- [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch-depends [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build-depends [14:03:06] [10] [00:01:03] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: lib-depends [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: configure [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: run-depends [14:03:34] [10] [00:01:31] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: stage -- [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch-depends [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build-depends [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: lib-depends [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: configure [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: run-depends [14:03:54] [06] [00:01:26] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: stage -- [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch-depends [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build-depends [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: lib-depends [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: configure [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: run-depends [14:03:54] [13] [00:00:58] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: stage -- [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: patch-depends [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: patch [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: build-depends [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: lib-depends [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: configure [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: build [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: run-depends [14:04:24] [08] [00:02:23] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: stage -- [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch-depends [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build-depends [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: lib-depends [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: configure [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: run-depends [14:03:43] [05] [00:00:58] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: stage The log file also allows me to do the likes of the following to see what and how many (package level) dependencies were involved: # grep "\[^-]" = ~/bulk-output-release-aarch64-ports-alt-2.txt | more [00:00:17] devel/dwarves depends on devel/argp-standalone [00:00:17] devel/dwarves depends on devel/binutils [00:00:17] devel/dwarves depends on devel/cmake-core [00:00:17] devel/dwarves depends on devel/elfutils [00:00:17] devel/dwarves depends on devel/gettext-runtime [00:00:17] devel/dwarves depends on devel/gettext-tools [00:00:17] devel/dwarves depends on devel/gnulib [00:00:17] devel/dwarves depends on devel/ninja [00:00:17] devel/dwarves depends on lang/gcc14 [00:00:17] devel/dwarves depends on ports-mgmt/pkg [03:50:42] [14] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [03:50:49] [14] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = check-sanity [03:50:49] [14] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [03:50:51] [14] [00:00:09] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [03:50:51] [14] [00:00:09] Status devel/dwarves | dwarves-1.19_3: = fetch [03:50:54] [14] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = checksum [03:50:55] [14] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = extract-depends [03:50:55] [14] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = extract [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch-depends [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch [03:50:59] [14] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = build-depends [03:52:17] [14] [00:01:35] Status devel/dwarves | dwarves-1.19_3: = lib-depends [03:52:28] [14] [00:01:46] Status devel/dwarves | dwarves-1.19_3: = configure [03:52:31] [14] [00:01:49] Status devel/dwarves | dwarves-1.19_3: = build [03:52:33] [14] [00:01:51] Status devel/dwarves | dwarves-1.19_3: = run-depends [03:52:34] [14] [00:01:52] Status devel/dwarves | dwarves-1.19_3: = stage [03:52:35] [14] [00:01:53] Status devel/dwarves | dwarves-1.19_3: = package [03:52:38] [14] [00:01:56] Finished devel/dwarves | dwarves-1.19_3: = Success But it does not break out build-depends vs. lib-depends vs. run-depends specifics, for example. It looks like for many of the later small package builds, those 3 activities now make up most of the elapsed-time consequences for those builds. top over various time frames shows mostly the likes of: 66921 59 root 131 0 230016Ki 179080Ki CPU5 5 0:26 = 99.56% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg 66914 59 root 68 0 19536Ki 9344Ki wait 10 0:00 = 0.00% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg 66804 59 root 68 0 13408Ki 3120Ki wait 10 0:00 = 0.00% /bin/sh /usr/ports/Mk/Scripts/do-depends.sh for for build-depends, lib-depends, and run-depends for the activity for each active builder. None of the ports are "large build step" ones for where I happen to have sampled or when I happened to watch with top. But: Most packages are not "large build step" ones so this is expected much of the time. NOTE: The above explains the load averages being near the FreeBSD number of cpus during periods when all the active builders were doing such activity, as is common over many parts of the build sequence. Other notes: There is evidence on the build cluster results that the main-* runs have a notably larger Elapsed time multiplier than the 13* and 14* runs do. 13* and 14* are still substantial of themselves. My guess is that main-* uses a debug 15000?? kernel and possibly a debug jail-world and 13* and 14* use a non-debug 15000?? kernel (and a non-debug jail-world). But such details do not seem to be in public descriptive information or published in public log files. I expect the dependency analysis activity happens to touch Elapsed-time-consuming debug code. May be a more selective variant of debug kernel and/or world builds could be used instead that avoids a notable amount of that? It looks like having a partially pre-built bulk -a to start from could avoid wait-time for establishing a context that shows the Elapsed time behavior for build-depends, lib-depends, and run-depends. I ended up with having to restart poudriere(-devel) during my investigations and ended up using a non-debug kernel. So the times on the left below are from when it queued 26014 and then inspected 7111, not from the start of the original "bulk -c -a" on the Apple silicon M4 MAX under Parallels on macOS. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 10 17:14:31 2025 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 4ZYRJZ2fxSz5tCv9 for ; Thu, 10 Apr 2025 17:14:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4ZYRJY3gKvz4Lm8 for ; Thu, 10 Apr 2025 17:14:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DKGbqLPq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744305287; bh=Tnsdnl1X8usfK7yBFF8tTv1RDOJW35jCIXY2aEB9Z4o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DKGbqLPq1NR3UjBdVcgQKXGrN/1p6hJo68WjZ2cSI2kaxyYV7bHTgV41yXaUr72xQtENp7v/yuFRDgBFVj+8OHd1G5PEeqfJPf9XPi2THX3g/ehJWjwMsn4Nup6kDDN7GVgiz4VIZaI8k/j23MzrW/kdu2Digfm2f4QgX7X9d6p+7G2Vjx15nlfT2KA/hEm0GKfoLIreSeIieN83WVTAPOJe4ryC2mIfraL18/ELorvOcRu+Ac6egRfq4labUfimfbCEWU8IKqe/N1c47fempF4hsnqyJgCZKiUahdk9J1UMKcmYgNRX19Wse0LX1pNAzu7Mgm9EI5y7Dq8Mx91U+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744305287; bh=flFfjp2uLI7g3ZbuxNtFvsn+6mELeFq+IhfW285hcf0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tU3DEZ5EC4pxqW0lrb8bPNXxXI/pkhoENNuXvziBJg2fF5+HWJ3a4S9D7CJM8CA3RfUIU1sMBrtj5LAIuzywFWD9zY5OoRYhgG7EiYJ34DygDyg4B8MxboXd083ZvtJyU3pxpuqgrwA8joTAThKLCj4b0rofHUQ0IYIXqvUxPS3LGGKrzo2tF2cIAKZM4z2OLGkWKEWVySs4OdrsWwDmrO29+20FJ9BVt48QqkPkRM1cR1HGCZ9NHywORUB2AQt1vcg5SxFbY/ZtfTaBo+kMKpnIWAdEzznasBQ4O7klNg8Ua6hzC000YkyzuxeJn6s3gEBNDIQac+5P+Fryk0xkHA== X-YMail-OSG: HVzs7MkVM1mVxBrK0c0fblzmtrtUykVDz3F9MaX6brgIjvGeH3z.7HijhKbdOZV Chc6e6Plamzzrcpo0OK6bJ84sB_4wTHae0stl0NGKjZXaP.LrJnhj76CZzXe1nTnphOwgBJlJ4b7 .KOvuxn6I1bdreVfjBNSoq1TDZrYyPPHMMZxDM8O95RyO5owOWtzW.dKhIqAB36jk1tMq7O5f9o. lDiSoC2rOnGK2AGwdVvEFWtSUoMO_PSR1SWgfnUVPL1wj8CYng_Joo3eB2usVl1aWO.svzxjd8pY uQiFOeZjlTbo_PneNnPQKJt1JtI4qzBGSCW7XC8bEQe39iDdcffbjDStqjRHlGZnGNcp.FFs0VDN LCE0v3PqApxyX7CEdy3Ec.81d.UfR.UGtrd4QmrgwSngQmRog5E.zzvBk6uTU3Gh6OLRuWKq1xMT KJ.RHs5MtAX4RRhdUmwgAY7EPsASFq8vWcHT9Ztt_QjEpeU.3uX8kvCLs5UZpBSe.h_.kCMscv2m 4.wi7_c6q8Fe3lbuKss6VaLTgiEPQrFFiTck8.0tRWGOZMqh294M_k1ZRyTO5Omf_9pjaIcM2vYi H9PwviocA3AqqJ8CFn8IFTFY1B9oBQlAT1aQZlfdny9YpWVORKG79RO09jb8gMHlw._ox7g3LwjL hSZUt7uN1QKNpLEG5QLS6L_qQ_OFh.B8Wfm44XN._ZNlHFF79fwSGikE7k2S0cLgk6fVkEvPVgqr 1zBXmmAHoF5vGVjRxJQtZI8mvIpz.Ws7cWpTYej9Oi8nijBrTniCcIx0fUOl82L6ale2X1F8Le8p vh3zm7.GGcFHI2I95VEAWhlIR5qkGsrHt.8H751DDP1WYOgdgtgsn1bt9d8Y9KtCgRcj6O8Cg7k5 gpIjbEsfwb3pbnxMvUo7UVZcpDMTtdSemMSRYFFmuun8E1d2iB4_4R2lz6c3DM3kB_rqftmbrdfN Dlz9QCwiBQfEHwajQ8t.I5ww.jpVwuK7XOFg4QwtvwDATil_O0wwXz6S55VOXSZvhKKsXvIbj_lI TUGR0aSnWUAQL.n4rjuINkBtB9xVgHVblNR4seTTsO.NtTvFa1CX0e4_k_S1VahV3mQXG4h.Yv4I 52dgFAIaTr4uz5D0udn5anjOKyRWRfAzFnWFWcbzgyW48EvnD6T3r.XxxkiwtCRV5vjC7ZYAGw9z MlsLbuAD2Z.f8O4nmKC8_TkQx8MNra5Zm_eub4h6ElbK3Te_WxvT0izigGQoY8Zz_btzLN36PPSP p6oSf6.7LTSaw0F4iJHxMs86BYcPX9SNp6UbnExRyztT67RnIp47UFoxdiiWLnbzb.LICGaubhwM ee.L7VMy.ZQOGZ7ggr5yYzp67ZuKyPinvkMReTwujwaKs7sWjKiRK3sOTgHtXpQyoheWsyykCRmV uOlfmNT0jZA6O_qG6uXi7BAdC51aqoFdK6mHVwEGf9qU.EeHbuulZDJw4hDGt1vT.X.bAjkR_USQ 5R.SJk24cWure4CE_xl0xoJ4Gcht5VNeQxBqlQgEEyNAca7RkJv6sbd1Q0MriaIwoszDbcddxyWX 9tI93C.RQE8D_luSob6PBNjW4SR3y.awPqrwU6gduGGENVWAbM_cHZphVrHjyWwXyPIB4ZCAf.L0 Yf8oAKZ_2dbddQMYzAYanBsuUrOCnv8JokHN4cAdpEwgPLkABygfbt5D.k3PvaOi42a6fz78jjaV SKKHcEyTiGQHHbVsOFsTSM7sQ1S0H_yzwO21nGda8VXrqYQMvdF6JO0kehLD8t6Qsm14PJbircwO YUt2JYTZGjbAO1Djp38pui.kZ.5ViLT5WJX1EKUAeQdPZYnyIO8UMiEd_Tw9wYT_ZJYaE3NgH8lF nbJCKH9STdgm7EemZTMAKZcQvSHvI6vOBPy2Yc7xUg_0myGZKOMxWsBtk9rxAYYgq6lh4_xgi49M BhbhG1se5ULMaIWYSZkFrUKhcTFoU8nFWM073viq6lT8XXtYCBZV2m6aAUhYgov93GuNG3WtMvBD Au0KaYGc4j4nhOqWjTgaFXuak_dYcTD0b4WVcU5c0dfG1gW.AyT.oO5_HuPoUVYG9sX292fenqmU Y_FRCG6RysWTqH.9KJniseni1_ttrst0JloDHJaBirEZVcl3S75ttopteRXTeTvZP2pTpfEHYyG1 Bo9ICoppR26x399nQh5LTduA.ipZ9tcdQfn8.6Sia86B7iu6vrBeXagI89e77gjrEdieSkwbMG3C PDo8nNmmFcYb2rT_nL0VODrS5CaxkCIVRZlXb7akP2lr8B0SXskxIL80BA_.fFc9tNhVq4jRbNZ0 WBwpS X-Sonic-MF: X-Sonic-ID: af5bef6b-375f-41cd-878a-1e8f7e89a197 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 10 Apr 2025 17:14:47 +0000 Received: by hermes--production-gq1-6f8bfcd964-g9xd6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e4b7ec98cf08d5b3e200148a5c16b975; Thu, 10 Apr 2025 17:14:42 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {patch,build,lib}-depends timings for bulk -a --and related notes] From: Mark Millard In-Reply-To: Date: Thu, 10 Apr 2025 10:14:31 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <48D0BE51-8111-465B-96BC-969DE7EBFEFC@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-2.90 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.30:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.60)[0.599]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FREEMAIL_FROM(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.30:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZYRJY3gKvz4Lm8 X-Spamd-Bar: -- On Apr 10, 2025, at 09:25, Mark Millard wrote: > The following data are from later in the builder seqeunce. > Here I'm not looking at builder activity with large Elapsed > multiplication factors for the build. It is more of a random > sampling showing examples of build-depends, lib-depends, and > run-depends and some with more than one of those notably > contributing. This is later when dependencies are normally > involve for the package builds. >=20 > A property of the dependency based ordering of builds is that > the earlier builds tend of have fewer dependencies and the later > builds tend to have more. >=20 > For building around 36000 packages, even a mean rate of around > 1 extra second per is around 10 hrs of extra time. (But normal > extra times are not generally near the mean-extra-time.) >=20 > It appears that a big factor in the overall Elapsed time is > the large fraction of the 30000+ packages that are "small > build step" packages --the subset of that for which build later > because of involved dependencies. The dependency analysis is more > time consuming than the build time --or even total for all of the > steps other than build-depends, lib-depends, and run-depends. >=20 > Basically: for the most part, only early builder runs can be > quick runs (no or very limited dependencies involved). >=20 > It would take a massive decrease in most build-depends, > lib-depends, and run-depends (when any) Elapsed times in > later builds for this not to be the case --because of the > number of packages for which the rest of the time is small. > Such does not seem likely? The additions in this note show some examples of just one builder being active instead of when others are also active. Each is a bulk -C ORIGIN of ORIGIN I'd listed data for previously. > The supporting detail . . . >=20 > I'll note that the 3 load averages reported by top for the > below were near the number of FreeBSD cpus whenever I happened > to check that, instead of being during high load average time > frames. (I.e., no packages with large builder steps were > active.) There is a later explanation of this. >=20 >=20 > Both build-depends and lib-depends: >=20 > # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[03:52:[0-9][0-9]\] .*configure$" | more > . . . > [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch > [03:50:59] [14] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = build-depends > [03:52:17] [14] [00:01:35] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [03:52:28] [14] [00:01:46] Status devel/dwarves | dwarves-1.19_3: = configure > [03:52:31] [14] [00:01:49] Status devel/dwarves | dwarves-1.19_3: = build > [03:52:33] [14] [00:01:51] Status devel/dwarves | dwarves-1.19_3: = run-depends > [03:52:34] [14] [00:01:52] Status devel/dwarves | dwarves-1.19_3: = stage > . . . For comparison/contrast: (The fetch would not have to repeat.) I stopped the bulk -a an run just a -C devel/dwarves (no other builders, no need to rebuild dependencies): [00:00:38] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = checksum [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:01:15] [05] [00:00:37] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:01:21] [05] [00:00:43] Status devel/dwarves | dwarves-1.19_3: = configure [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = build [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = stage [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = package [00:01:22] [05] [00:00:44] Finished devel/dwarves | dwarves-1.19_3: = Success Still a non-trivial addition to the Elapsed time if there are 10s of thousands of such packages in the ball park. > -- > [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: patch-depends > [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: patch > [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: build-depends > [03:52:18] [01] [00:00:18] Status security/seccure | = seccure-0.5_10: lib-depends > [03:52:31] [01] [00:00:31] Status security/seccure | = seccure-0.5_10: configure > [03:52:31] [01] [00:00:31] Status security/seccure | = seccure-0.5_10: build > [03:52:32] [01] [00:00:32] Status security/seccure | = seccure-0.5_10: run-depends > [03:52:32] [01] [00:00:32] Status security/seccure | = seccure-0.5_10: stage >=20 >=20 > lib-depends: >=20 > # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[05:20:[0-9][0-9]\] .*configure$" | more > . . . > -- > [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch-depends > [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch > [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: build-depends > [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: lib-depends > [05:20:08] [05] [00:00:43] Status graphics/gdchart | = gdchart-0.11.5_11: configure > [05:20:09] [05] [00:00:44] Status graphics/gdchart | = gdchart-0.11.5_11: build > [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: run-depends > [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: stage > . . . > -- > [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch-depends > [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch > [05:20:03] [06] [00:02:05] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build-depends > [05:20:04] [06] [00:02:06] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: lib-depends > [05:20:26] [06] [00:02:28] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: configure > [05:20:27] [06] [00:02:29] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build > [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: run-depends > [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: stage >=20 >=20 > build-depends and run-depends: >=20 > # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[09:15:[0-9][0-9]\] .*configure$" | more > [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch-depends > [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch > [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build-depends > [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: lib-depends > [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: configure > [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build > [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: run-depends > [09:16:01] [07] [00:01:02] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: stage > . . . > -- > [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch-depends > [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch > [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build-depends > [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: lib-depends > [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: configure > [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build > [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: run-depends > [09:16:08] [04] [00:01:08] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: stage > . . . > -- > [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch-depends > [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch > [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build-depends > [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: lib-depends > [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: configure > [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build > [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: run-depends > [09:16:19] [13] [00:01:23] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: stage > -- > [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch-depends > [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch > [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build-depends > [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: lib-depends > [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: configure > [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build > [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: run-depends > [09:15:21] [02] [00:00:41] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: stage > -- > [09:14:59] [09] [00:00:03] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: patch-depends > [09:15:00] [09] [00:00:04] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: patch > [09:15:00] [09] [00:00:04] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: build-depends > [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: lib-depends > [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: configure > [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: build > [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: run-depends > [09:15:59] [09] [00:01:03] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: stage > -- > [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch-depends > [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch > [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build-depends > [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: lib-depends > [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: configure > [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build > [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: run-depends > [09:16:00] [14] [00:01:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: stage >=20 >=20 > Mostly build-depends but one also has lib-depends: >=20 > # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[11:10:[0-9][0-9]\] .*configure$" | more > [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch-depends > [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch > [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build-depends > [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: lib-depends > [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: configure > [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build > [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: run-depends > [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: stage > -- > [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch-depends > [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch > [11:09:54] [04] [00:00:11] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build-depends > [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: lib-depends > [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: configure > [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build > [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: run-depends > [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: stage > -- > [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch-depends > [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch > [11:09:37] [12] [00:00:15] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build-depends > [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: lib-depends > [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: configure > [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build > [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: run-depends > [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: stage > -- > [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: = patch-depends > [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: patch > [11:09:16] [05] [00:00:19] Status devel/obby | obby-0.4.8_6: = build-depends > [11:09:59] [05] [00:01:02] Status devel/obby | obby-0.4.8_6: = lib-depends > [11:10:21] [05] [00:01:24] Status devel/obby | obby-0.4.8_6: = configure > [11:10:26] [05] [00:01:29] Status devel/obby | obby-0.4.8_6: build > [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: = run-depends > [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: stage > -- > [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch-depends > [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch > [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build-depends > [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: lib-depends > [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: configure > [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build > [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: run-depends > [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: stage > -- > [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch-depends > [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch > [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build-depends > [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: lib-depends > [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: configure > [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build > [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: run-depends > [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: stage > -- > [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch-depends > [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch > [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build-depends > [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: lib-depends > [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: configure > [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build > [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: run-depends > [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: stage > -- > [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch-depends > [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch > [11:09:46] [09] [00:00:13] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build-depends > [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: lib-depends > [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: configure > [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build > [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: run-depends > [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: stage > -- > [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [11:09:51] [13] [00:00:17] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [11:09:52] [13] [00:00:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [11:10:14] [13] [00:00:40] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [11:10:38] [13] [00:01:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage For comparison/contrast: (The fetch would not have to repeat.) I stopped the bulk -a an run just a -C mail/mailest@nox (no other = builders, no need to rebuild dependencies): [00:00:37] [13] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:01:00] [13] [00:00:23] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:01:08] [13] [00:00:31] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success Still a non-trivial addition to the Elapsed time if there are 10s of thousands of such packages in the ball park. > -- > [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch-depends > [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch > [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build-depends > [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: lib-depends > [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: configure > [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build > [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: run-depends > [11:10:29] [12] [00:00:28] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: stage >=20 >=20 > build-depends: >=20 > # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[12:47:[0-9][0-9]\] .*configure$" | more > [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch-depends > [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch > [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build-depends > [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: lib-depends > [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: configure > [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build > [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: run-depends > [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: stage > -- > [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch-depends > [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch > [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build-depends > [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: lib-depends > [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: configure > [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build > [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: run-depends > [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: stage > -- > [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch-depends > [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch > [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build-depends > [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: lib-depends > [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: configure > [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build > [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: run-depends > [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: stage > -- > [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: patch-depends > [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: patch > [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: build-depends > [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: lib-depends > [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: configure > [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: build > [12:47:13] [09] [00:02:15] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: run-depends > [12:47:13] [09] [00:02:15] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: stage > -- > [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch-depends > [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch > [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build-depends > [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: lib-depends > [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: configure > [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build > [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: run-depends > [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: stage > -- > [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch-depends > [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch > [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build-depends > [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: lib-depends > [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: configure > [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build > [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: run-depends > [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: stage >=20 >=20 > build-depends and run-depends: >=20 > # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[14:03:[0-9][0-9]\] .*configure$" | more > [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch-depends > [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch > [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build-depends > [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = lib-depends > [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = configure > [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build > [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = run-depends > [14:04:43] [14] [00:01:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = stage > -- > [14:02:22] [01] [00:00:08] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch-depends > [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch > [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build-depends > [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: lib-depends > [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: configure > [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build > [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: run-depends > [14:03:43] [01] [00:01:29] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: stage > -- > [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [14:05:07] [03] [00:02:19] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage For comparison/contrast: (The fetch would not have to repeat.) I stopped the bulk -a an run just a -C devel/py-inline-snapshot@py311 = (no other builders, no need to rebuild dependencies): [00:00:34] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 [00:00:34] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package [00:01:24] [02] [00:00:50] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success Still a non-trivial addition to the Elapsed time if there are 10s of thousands of such packages in the ball park. > -- > [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: patch-depends > [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: patch > [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: build-depends > [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: lib-depends > [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: configure > [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: build > [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: run-depends > [14:05:38] [02] [00:02:54] Status devel/py-xsdata-plantuml@py311 | = py311-xsdata-plantuml-24.3: stage > -- > [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch-depends > [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch > [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build-depends > [14:03:06] [10] [00:01:03] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: lib-depends > [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: configure > [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build > [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: run-depends > [14:03:34] [10] [00:01:31] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: stage > -- > [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch-depends > [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch > [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build-depends > [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: lib-depends > [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: configure > [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build > [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: run-depends > [14:03:54] [06] [00:01:26] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: stage > -- > [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch-depends > [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch > [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build-depends > [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: lib-depends > [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: configure > [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build > [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: run-depends > [14:03:54] [13] [00:00:58] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: stage > -- > [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: patch-depends > [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: patch > [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: build-depends > [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: lib-depends > [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: configure > [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: build > [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: run-depends > [14:04:24] [08] [00:02:23] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: stage > -- > [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch-depends > [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch > [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build-depends > [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: lib-depends > [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: configure > [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build > [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: run-depends > [14:03:43] [05] [00:00:58] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: stage >=20 >=20 > The log file also allows me to do the likes of the following to see > what and how many (package level) dependencies were involved: >=20 > # grep "\[^-]" = ~/bulk-output-release-aarch64-ports-alt-2.txt | more > [00:00:17] devel/dwarves depends on devel/argp-standalone > [00:00:17] devel/dwarves depends on devel/binutils > [00:00:17] devel/dwarves depends on devel/cmake-core > [00:00:17] devel/dwarves depends on devel/elfutils > [00:00:17] devel/dwarves depends on devel/gettext-runtime > [00:00:17] devel/dwarves depends on devel/gettext-tools > [00:00:17] devel/dwarves depends on devel/gnulib > [00:00:17] devel/dwarves depends on devel/ninja > [00:00:17] devel/dwarves depends on lang/gcc14 > [00:00:17] devel/dwarves depends on ports-mgmt/pkg > [03:50:42] [14] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [03:50:49] [14] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [03:50:49] [14] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [03:50:51] [14] [00:00:09] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [03:50:51] [14] [00:00:09] Status devel/dwarves | dwarves-1.19_3: = fetch > [03:50:54] [14] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = checksum > [03:50:55] [14] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [03:50:55] [14] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = extract > [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch > [03:50:59] [14] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = build-depends > [03:52:17] [14] [00:01:35] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [03:52:28] [14] [00:01:46] Status devel/dwarves | dwarves-1.19_3: = configure > [03:52:31] [14] [00:01:49] Status devel/dwarves | dwarves-1.19_3: = build > [03:52:33] [14] [00:01:51] Status devel/dwarves | dwarves-1.19_3: = run-depends > [03:52:34] [14] [00:01:52] Status devel/dwarves | dwarves-1.19_3: = stage > [03:52:35] [14] [00:01:53] Status devel/dwarves | dwarves-1.19_3: = package > [03:52:38] [14] [00:01:56] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 > But it does not break out build-depends vs. lib-depends vs. = run-depends > specifics, for example. >=20 > It looks like for many of the later small package builds, those > 3 activities now make up most of the elapsed-time consequences > for those builds. >=20 > top over various time frames shows mostly the likes of: >=20 > 66921 59 root 131 0 230016Ki 179080Ki CPU5 5 0:26 = 99.56% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg > 66914 59 root 68 0 19536Ki 9344Ki wait 10 0:00 = 0.00% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg > 66804 59 root 68 0 13408Ki 3120Ki wait 10 0:00 = 0.00% /bin/sh /usr/ports/Mk/Scripts/do-depends.sh >=20 > for for build-depends, lib-depends, and run-depends for the > activity for each active builder. None of the ports are "large > build step" ones for where I happen to have sampled or when I > happened to watch with top. But: Most packages are not "large > build step" ones so this is expected much of the time. >=20 > NOTE: > The above explains the load averages being near the FreeBSD number > of cpus during periods when all the active builders were doing > such activity, as is common over many parts of the build sequence. >=20 >=20 > Other notes: >=20 > There is evidence on the build cluster results that the main-* > runs have a notably larger Elapsed time multiplier than the > 13* and 14* runs do. 13* and 14* are still substantial of > themselves. My guess is that main-* uses a debug 15000?? > kernel and possibly a debug jail-world and 13* and 14* use a > non-debug 15000?? kernel (and a non-debug jail-world). But > such details do not seem to be in public descriptive information > or published in public log files. I expect the dependency > analysis activity happens to touch Elapsed-time-consuming > debug code. May be a more selective variant of debug kernel > and/or world builds could be used instead that avoids a > notable amount of that? >=20 > It looks like having a partially pre-built bulk -a to start > from could avoid wait-time for establishing a context that > shows the Elapsed time behavior for build-depends, lib-depends, > and run-depends. >=20 > I ended up with having to restart poudriere(-devel) during my > investigations and ended up using a non-debug kernel. So the > times on the left below are from when it queued 26014 and then > inspected 7111, not from the start of the original "bulk -c -a" > on the Apple silicon M4 MAX under Parallels on macOS. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 10 22:36:48 2025 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 4ZYZSR2wXqz5rx9j for ; Thu, 10 Apr 2025 22:37:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4ZYZSP3Fhsz3Fxp for ; Thu, 10 Apr 2025 22:37:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cbD8j868; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744324623; bh=n5Xu+06lJCvXdKYBZtB1D8f1m8DSKHZg2cXe5MSvB7c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cbD8j868ftQvzaHL69TqIT15/NT2iQGGV2UR0ZiPn2foWjY6mhMwZtqaC6wJuLkTb4ktUr64oWpqzn/JSS6yT1/4D5icQPs2NRB35zpOQn7A+kEbEwXyo+Ki4qcBsm/wyBvicWcR/cZ17ahOiKjlahLG1DJFnRh4skaJ1SbKGnSebk/1JOeECUaMpT3C3HR1UdHsPBO5ok/qjzlTGN/LVTjMeQGj17o2r+UI1pAzOVwrzMR4I1Q+xbtxjdd3CPEuXpdQ2OqbZXh2pgYgKfP/QbcFbmqly0rx1UTG/4v2dhPRKcfff9KmxelFcoMIQCEu07zRgoo7fXEaLzxdgxByOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744324623; bh=M0HqZt96QK6ptpBitRwLtsblIw+C2oDBtf1WeSVkqhe=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WH0PDM4ArT0PAjqHZ/Vn3kg2qkzjOdAvvEhdClYFZ14A3HfUA4nevXHv/cZRKiS/imT+0OZO0MLknBJ7pdCL8Js4Z4+ShaDNMWSKCD0tkHLtHGGGfcm1m3YpzkUtSONCRY65AmtiQaU56NV6SoLxCQEjl3mPVSORVu9ktrp8ceO2LG75eBr3jtOEcARBCXWTyknKapUE/IeiD1iqBuamGVADISyRzV7fkJaIdiAGPGnHr1apGdXiego05b6+x1FmpCo8TXsc03WSZY4+6zROvdPUaGxSZ8dnfExnGstDnFLpokfcv5yz3W72DloI+UZuKLCbaUieiPRrEGqdGY3Mng== X-YMail-OSG: AqVJ0psVM1kEtVgFzvhOAwGR7hEQAA.kT9QqzkBoyP_6QD3OqcneN3vi6FEtuWo o9g7nYUjHXHZLZBbIF7jNuIlK9h5tQQcHP9GnXHRoHfbZW62od06M8L7qkZS0i3Y97X1NUxR2Qzj oCUKAwfZ00k9Q97z2Mbv63aOeYWTyOT8pQBTeRmIHUUmX2BQ74aSBOv37yoMXHBkTlABUYdHyu.t IlivF4ToozK.sRStdsnVGe6gXBVpl4iUrX8LUXBcBHDuGwn5ig2dvYd6nnI_o7N_OF18PnSphthQ YilL.HzVmXWFshtsT_UotGRhiO_oQIEx5fZ1sCWMZvGsSnSCNzGoaLOeofchkUix_4qRXUJ9n3vD OaHfUJjlaoNMDPwf3jIE1UjPT5Gwp7qlL71S5y4gqQnH.xjrqTy.pOQ2o_8PyEf.j75oS4bzEWOv PcCJ1Mp.KoWMMXv9oBmgt1O8aR9v9.mGVnnbF1VZcpcPTAxCheheXKelg2v12EltwKBRsQBWCwGj JGdD_dglYdugtRNlXZFzS_YCoZOur4x7feN9cJ97sOMnmAyhyZj_8TsgnArK2iBQKz6fFoMQQmo. gpxReA9pWb7uN..6lkMJfEOcQffhnjPgWavwWyQ_URlj81f2_6m6mLA3sd3APsJJBx9ihl8XCGpq FPRtnYTgWbEKiRupK.eMLCFinU.GUltVsWLg0XpZUKjOuWX_qTEpmyAfMD3Mkyso8HvD0EA_UpfB AH1UxhSlpyB.Y34hbyjHEJBEReMrGzLdWnN6ry6ERUGvTgjZUFdJ9LBh4yAc1azCVOsmUjPG_UBc MECDspVKKNPXUJ1h5Qu0OYrEQY9xgbJjDOwVRMcmXv5.76DDJY858W6mj98eGUlc9I0uaelhrnvu ND0Nza7U5Gp8b.Cmbhd2SaFjpbAa6XhJmlO45W54HygsMpJU1d50GIoJ8_tC_EWr.iXRryjS9BYt IjrkI6okxD_ie9_.akh.Dqf7DSdvayb0rcx2OtXKUTeSrgdty.OpOOes71ZjcSqEk73_VTwpd.Hq 4PV1MlE4y2i4yXpFs7DMNbLT4jddhPE01XOLgM5g._k.Z0cWaTIYs03A6Ctxz1yeM19KYTd7ctH1 linkiFZHNLJxnMwxHniYHfbRjCGulIcbWwNzSO9KFBgvGWfGLJBqTpEjzns9XP0QFqP2HYT55kO_ I.D.IPKfRxV21o5Fk7SO9ws6Jjv2muqhSnWGa681uw6fm1uY5LQptqWdzil1bLB93rtmaJYwb2fr KdHBhUc7fWip4qiKXq85K7SMrcs2UbPBU0CfLEAYql2QDGx_orOb9TH46HeMU4VXrzel407Owb.W bbmDiw4_t9RYb9qr3xWRS5H6os4BIYD0k.aky2dLLJv5GRSWkd5wVSk2M0eMHpi2IfSHxDbBz912 T9uhSnatONk1bA0ajzHFsMbDCvv6k36tPEPCuMcM8u4D0FNlOFijvo.HnzR6N4NQGqAQSJQw5cG9 X_Ze4BR5LpkbFVBk0p_n4D_WGg0ZyhxQLadVhvMVrkTw7UdbydgRJ8hsrEIB.Z5qjE6oeSvckheE HWYb5qeg9A7c9wlyibIBBaUFQH.LC3IJ.kC4vm.S5YaPSphA3Iab.JSkjBQ9QeZ9jfdqr1PfCyx. nqMNa8F1PECIT8kmMDV_lUQzcuAt9f6n9.wsvUjUAo3abQsM7BsyEFZ6_UIAfJHlkSBJOSyLRaJP 00ik2tKjkFcFZVCrioPKhFU.Ihk7EdmZ8e1jKuuOPQvBn0vT5qwr7QMBtEcEoWN5Al2aPbaaMh6G rdWFVnhnQ7JfS1KsGRB438b3KbnyvH5VYHYGb6jICl_h.xeU0CcJo.NhUe8wHi4ZzprDK3RDknOY qB_OQytvNV1IJo.KHLubuJaXtoocP9K0RgZ78pTzcnVy.isvVptEFLMbG85PED3l8tTXZlspkMCp Xm2xiae7Zke8jMo9xPOQ7zjPAxn6hYn55a674MBeNe_6AAs8pazlOzO3XXHl0hSAT6PhYGB8WP.X fLPHLYfS4YFvCdbg0VTln1qWBQ_hbg5Lfurgu.m7iatmy2ygzn_6WhthbCvgIaPI62e7KHKZE3A_ GGDSlhjpI_fKEEYHedPncA5q9NkTUE5ngcSsXMYEHLU6quqqe1IzTKsXEWD_J1XCqCqnkVMEezpU eHR8FACie18jT0uJdzh1tIoQTT81_jV8OePbsdexMDog65LwOELBrR_l1Z_hcSGOM9w.r2jjPjyA 3nL3YAjYPAJ7fVGIj3ACycVioAgG6xF5h_KzXepD2b0R6H6cDc.mYg_3FJOdgKbpGxtV2veA2Zxp c6O8- X-Sonic-MF: X-Sonic-ID: 087b9454-7a22-4cac-bc2b-c3f47b47b380 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 10 Apr 2025 22:37:03 +0000 Received: by hermes--production-gq1-6f8bfcd964-7vssx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e0f22d58c68bfca2ec62de65859c80c8; Thu, 10 Apr 2025 22:36:58 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {build,lib,run}-depends timings for bulk -a --and some other aarch64 timings] From: Mark Millard In-Reply-To: <48D0BE51-8111-465B-96BC-969DE7EBFEFC@yahoo.com> Date: Thu, 10 Apr 2025 15:36:48 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> <48D0BE51-8111-465B-96BC-969DE7EBFEFC@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.49 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.205:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from] X-Rspamd-Queue-Id: 4ZYZSP3Fhsz3Fxp X-Spamd-Bar: ---- On Apr 10, 2025, at 10:14, Mark Millard wrote: > On Apr 10, 2025, at 09:25, Mark Millard wrote: >=20 >> The following data are from later in the builder seqeunce. >> Here I'm not looking at builder activity with large Elapsed >> multiplication factors for the build. It is more of a random >> sampling showing examples of build-depends, lib-depends, and >> run-depends and some with more than one of those notably >> contributing. This is later when dependencies are normally >> involve for the package builds. >>=20 >> A property of the dependency based ordering of builds is that >> the earlier builds tend of have fewer dependencies and the later >> builds tend to have more. >>=20 >> For building around 36000 packages, even a mean rate of around >> 1 extra second per is around 10 hrs of extra time. (But normal >> extra times are not generally near the mean-extra-time.) >>=20 >> It appears that a big factor in the overall Elapsed time is >> the large fraction of the 30000+ packages that are "small >> build step" packages --the subset of that for which build later >> because of involved dependencies. The dependency analysis is more >> time consuming than the build time --or even total for all of the >> steps other than build-depends, lib-depends, and run-depends. >>=20 >> Basically: for the most part, only early builder runs can be >> quick runs (no or very limited dependencies involved). >>=20 >> It would take a massive decrease in most build-depends, >> lib-depends, and run-depends (when any) Elapsed times in >> later builds for this not to be the case --because of the >> number of packages for which the rest of the time is small. >> Such does not seem likely? >=20 > The additions in this note show some examples of just > one builder being active instead of when others are > also active. Each is a bulk -C ORIGIN of ORIGIN I'd > listed data for previously. The M4 MAX is unusually fast for aarch64 at this point. So . . . This note addition takes those 3 package examples and runs the "just the one builder" tests on each of 3 other aarch64 systems: Windows Dev Kit 2023 ( 8 core aarch64, 4 X1C cores and 4 A78C cores) RPi5B ( 4 core aarch64, cortex-a76's) HoneyComb (16 core aarch64, cortex-a72's) Note: The X1C and A78C cores do not perform the same. Scheduling variations can lead to time variations. Note: All this activity is based on an official PkgBase build of 1500035 kernel-NODEBUG and the jail world also being from an official PkgBase build for releng/14.2 : # poudriere jail -l JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 PkgBase updates do not seem to update the -p1 part of VERSION. # file /usr/local/poudriere/jails/release-aarch64/bin/sh /usr/local/poudriere/jails/release-aarch64/bin/sh: ELF 64-bit LSB pie = executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, = interpreter /libexec/ld-elf.so.1, for FreeBSD 14.2, FreeBSD-style, = stripped >> The supporting detail . . . >>=20 >> I'll note that the 3 load averages reported by top for the >> below were near the number of FreeBSD cpus whenever I happened >> to check that, instead of being during high load average time >> frames. (I.e., no packages with large builder steps were >> active.) There is a later explanation of this. >>=20 >>=20 >> Both build-depends and lib-depends: >>=20 >> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[03:52:[0-9][0-9]\] .*configure$" | more >> . . . >> [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch-depends >> [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch >> [03:50:59] [14] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = build-depends >> [03:52:17] [14] [00:01:35] Status devel/dwarves | dwarves-1.19_3: = lib-depends >> [03:52:28] [14] [00:01:46] Status devel/dwarves | dwarves-1.19_3: = configure >> [03:52:31] [14] [00:01:49] Status devel/dwarves | dwarves-1.19_3: = build >> [03:52:33] [14] [00:01:51] Status devel/dwarves | dwarves-1.19_3: = run-depends >> [03:52:34] [14] [00:01:52] Status devel/dwarves | dwarves-1.19_3: = stage >> . . . >=20 > For comparison/contrast: > (The fetch would not have to repeat.) >=20 > I stopped the bulk -a an run just a -C devel/dwarves (no other = builders, > no need to rebuild dependencies): >=20 > [00:00:38] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:01:15] [05] [00:00:37] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:01:21] [05] [00:00:43] Status devel/dwarves | dwarves-1.19_3: = configure > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = build > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = stage > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = package > [00:01:22] [05] [00:00:44] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 > Still a non-trivial addition to the Elapsed time if there > are 10s of thousands of such packages in the ball park. >=20 >> -- >> [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: patch-depends >> [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: patch >> [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: build-depends >> [03:52:18] [01] [00:00:18] Status security/seccure | = seccure-0.5_10: lib-depends >> [03:52:31] [01] [00:00:31] Status security/seccure | = seccure-0.5_10: configure >> [03:52:31] [01] [00:00:31] Status security/seccure | = seccure-0.5_10: build >> [03:52:32] [01] [00:00:32] Status security/seccure | = seccure-0.5_10: run-depends >> [03:52:32] [01] [00:00:32] Status security/seccure | = seccure-0.5_10: stage >>=20 >>=20 >> lib-depends: >>=20 >> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[05:20:[0-9][0-9]\] .*configure$" | more >> . . . >> -- >> [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch-depends >> [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch >> [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: build-depends >> [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: lib-depends >> [05:20:08] [05] [00:00:43] Status graphics/gdchart | = gdchart-0.11.5_11: configure >> [05:20:09] [05] [00:00:44] Status graphics/gdchart | = gdchart-0.11.5_11: build >> [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: run-depends >> [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: stage >> . . . >> -- >> [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch-depends >> [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch >> [05:20:03] [06] [00:02:05] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build-depends >> [05:20:04] [06] [00:02:06] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: lib-depends >> [05:20:26] [06] [00:02:28] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: configure >> [05:20:27] [06] [00:02:29] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build >> [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: run-depends >> [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: stage >>=20 >>=20 >> build-depends and run-depends: >>=20 >> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[09:15:[0-9][0-9]\] .*configure$" | more >> [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch-depends >> [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch >> [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build-depends >> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: lib-depends >> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: configure >> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build >> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: run-depends >> [09:16:01] [07] [00:01:02] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: stage >> . . . >> -- >> [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch-depends >> [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch >> [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build-depends >> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: lib-depends >> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: configure >> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build >> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: run-depends >> [09:16:08] [04] [00:01:08] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: stage >> . . . >> -- >> [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch-depends >> [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch >> [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build-depends >> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: lib-depends >> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: configure >> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build >> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: run-depends >> [09:16:19] [13] [00:01:23] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: stage >> -- >> [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch-depends >> [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch >> [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build-depends >> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: lib-depends >> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: configure >> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build >> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: run-depends >> [09:15:21] [02] [00:00:41] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: stage >> -- >> [09:14:59] [09] [00:00:03] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: patch-depends >> [09:15:00] [09] [00:00:04] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: patch >> [09:15:00] [09] [00:00:04] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: build-depends >> [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: lib-depends >> [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: configure >> [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: build >> [09:15:19] [09] [00:00:23] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: run-depends >> [09:15:59] [09] [00:01:03] Status security/pear-Horde_Group@php82 = | php82-pear-horde-Horde_Group-2.1.1: stage >> -- >> [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch-depends >> [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch >> [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build-depends >> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: lib-depends >> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: configure >> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build >> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: run-depends >> [09:16:00] [14] [00:01:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: stage >>=20 >>=20 >> Mostly build-depends but one also has lib-depends: >>=20 >> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[11:10:[0-9][0-9]\] .*configure$" | more >> [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch-depends >> [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch >> [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build-depends >> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: lib-depends >> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: configure >> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build >> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: run-depends >> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: stage >> -- >> [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch-depends >> [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch >> [11:09:54] [04] [00:00:11] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build-depends >> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: lib-depends >> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: configure >> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build >> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: run-depends >> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: stage >> -- >> [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch-depends >> [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch >> [11:09:37] [12] [00:00:15] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build-depends >> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: lib-depends >> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: configure >> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build >> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: run-depends >> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: stage >> -- >> [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: = patch-depends >> [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: = patch >> [11:09:16] [05] [00:00:19] Status devel/obby | obby-0.4.8_6: = build-depends >> [11:09:59] [05] [00:01:02] Status devel/obby | obby-0.4.8_6: = lib-depends >> [11:10:21] [05] [00:01:24] Status devel/obby | obby-0.4.8_6: = configure >> [11:10:26] [05] [00:01:29] Status devel/obby | obby-0.4.8_6: = build >> [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: = run-depends >> [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: = stage >> -- >> [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch-depends >> [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch >> [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build-depends >> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: lib-depends >> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: configure >> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build >> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: run-depends >> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: stage >> -- >> [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch-depends >> [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch >> [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build-depends >> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: lib-depends >> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: configure >> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build >> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: run-depends >> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: stage >> -- >> [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch-depends >> [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch >> [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build-depends >> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: lib-depends >> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: configure >> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build >> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: run-depends >> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: stage >> -- >> [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch-depends >> [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch >> [11:09:46] [09] [00:00:13] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build-depends >> [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: lib-depends >> [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: configure >> [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build >> [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: run-depends >> [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: stage >> -- >> [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >> [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >> [11:09:51] [13] [00:00:17] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >> [11:09:52] [13] [00:00:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >> [11:10:14] [13] [00:00:40] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >> [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >> [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >> [11:10:38] [13] [00:01:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >=20 > For comparison/contrast: > (The fetch would not have to repeat.) >=20 > I stopped the bulk -a an run just a -C mail/mailest@nox (no other = builders, > no need to rebuild dependencies): >=20 > [00:00:37] [13] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:01:00] [13] [00:00:23] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:01:08] [13] [00:00:31] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >=20 > Still a non-trivial addition to the Elapsed time if there > are 10s of thousands of such packages in the ball park. >=20 >> -- >> [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch-depends >> [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch >> [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build-depends >> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: lib-depends >> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: configure >> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build >> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: run-depends >> [11:10:29] [12] [00:00:28] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: stage >>=20 >>=20 >> build-depends: >>=20 >> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[12:47:[0-9][0-9]\] .*configure$" | more >> [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch-depends >> [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch >> [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build-depends >> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: lib-depends >> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: configure >> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build >> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: run-depends >> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: stage >> -- >> [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch-depends >> [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch >> [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build-depends >> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: lib-depends >> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: configure >> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build >> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: run-depends >> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: stage >> -- >> [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch-depends >> [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch >> [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build-depends >> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: lib-depends >> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: configure >> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build >> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: run-depends >> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: stage >> -- >> [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: patch-depends >> [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: patch >> [12:45:04] [09] [00:00:06] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: build-depends >> [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: lib-depends >> [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: configure >> [12:47:12] [09] [00:02:14] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: build >> [12:47:13] [09] [00:02:15] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: run-depends >> [12:47:13] [09] [00:02:15] Status www/p5-Catalyst-View-XML-Simple = | p5-Catalyst-View-XML-Simple-0.01_2: stage >> -- >> [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch-depends >> [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch >> [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build-depends >> [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: lib-depends >> [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: configure >> [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build >> [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: run-depends >> [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: stage >> -- >> [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch-depends >> [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch >> [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build-depends >> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: lib-depends >> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: configure >> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build >> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: run-depends >> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: stage >>=20 >>=20 >> build-depends and run-depends: >>=20 >> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[14:03:[0-9][0-9]\] .*configure$" | more >> [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch-depends >> [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch >> [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build-depends >> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = lib-depends >> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = configure >> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build >> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = run-depends >> [14:04:43] [14] [00:01:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = stage >> -- >> [14:02:22] [01] [00:00:08] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch-depends >> [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch >> [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build-depends >> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: lib-depends >> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: configure >> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build >> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: run-depends >> [14:03:43] [01] [00:01:29] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: stage >> -- >> [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch-depends >> [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch >> [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build-depends >> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: lib-depends >> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: configure >> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build >> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: run-depends >> [14:05:07] [03] [00:02:19] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: stage >=20 > For comparison/contrast: > (The fetch would not have to repeat.) >=20 > I stopped the bulk -a an run just a -C devel/py-inline-snapshot@py311 = (no other builders, > no need to rebuild dependencies): >=20 > [00:00:34] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 > [00:00:34] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage > [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package > [00:01:24] [02] [00:00:50] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success >=20 > Still a non-trivial addition to the Elapsed time if there > are 10s of thousands of such packages in the ball park. >=20 >> -- >> [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: patch-depends >> [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: patch >> [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: build-depends >> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: lib-depends >> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: configure >> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: build >> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: run-depends >> [14:05:38] [02] [00:02:54] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: stage >> -- >> [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch-depends >> [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch >> [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build-depends >> [14:03:06] [10] [00:01:03] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: lib-depends >> [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: configure >> [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build >> [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: run-depends >> [14:03:34] [10] [00:01:31] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: stage >> -- >> [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch-depends >> [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch >> [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build-depends >> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: lib-depends >> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: configure >> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build >> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: run-depends >> [14:03:54] [06] [00:01:26] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: stage >> -- >> [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch-depends >> [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch >> [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build-depends >> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: lib-depends >> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: configure >> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build >> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: run-depends >> [14:03:54] [13] [00:00:58] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: stage >> -- >> [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: patch-depends >> [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: patch >> [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: build-depends >> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: lib-depends >> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: configure >> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: build >> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: run-depends >> [14:04:24] [08] [00:02:23] Status www/py-flask-simpleldap@py311 | = py311-Flask-SimpleLDAP-2.0.0: stage >> -- >> [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch-depends >> [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch >> [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build-depends >> [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: lib-depends >> [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: configure >> [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build >> [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: run-depends >> [14:03:43] [05] [00:00:58] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: stage >>=20 >>=20 >> The log file also allows me to do the likes of the following to see >> what and how many (package level) dependencies were involved: >>=20 >> # grep "\[^-]" = ~/bulk-output-release-aarch64-ports-alt-2.txt | more >> [00:00:17] devel/dwarves depends on devel/argp-standalone >> [00:00:17] devel/dwarves depends on devel/binutils >> [00:00:17] devel/dwarves depends on devel/cmake-core >> [00:00:17] devel/dwarves depends on devel/elfutils >> [00:00:17] devel/dwarves depends on devel/gettext-runtime >> [00:00:17] devel/dwarves depends on devel/gettext-tools >> [00:00:17] devel/dwarves depends on devel/gnulib >> [00:00:17] devel/dwarves depends on devel/ninja >> [00:00:17] devel/dwarves depends on lang/gcc14 >> [00:00:17] devel/dwarves depends on ports-mgmt/pkg >> [03:50:42] [14] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >> [03:50:49] [14] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = check-sanity >> [03:50:49] [14] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = pkg-depends >> [03:50:51] [14] [00:00:09] Status devel/dwarves | dwarves-1.19_3: = fetch-depends >> [03:50:51] [14] [00:00:09] Status devel/dwarves | dwarves-1.19_3: = fetch >> [03:50:54] [14] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = checksum >> [03:50:55] [14] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = extract-depends >> [03:50:55] [14] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = extract >> [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch-depends >> [03:50:57] [14] [00:00:15] Status devel/dwarves | dwarves-1.19_3: = patch >> [03:50:59] [14] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = build-depends >> [03:52:17] [14] [00:01:35] Status devel/dwarves | dwarves-1.19_3: = lib-depends >> [03:52:28] [14] [00:01:46] Status devel/dwarves | dwarves-1.19_3: = configure >> [03:52:31] [14] [00:01:49] Status devel/dwarves | dwarves-1.19_3: = build >> [03:52:33] [14] [00:01:51] Status devel/dwarves | dwarves-1.19_3: = run-depends >> [03:52:34] [14] [00:01:52] Status devel/dwarves | dwarves-1.19_3: = stage >> [03:52:35] [14] [00:01:53] Status devel/dwarves | dwarves-1.19_3: = package >> [03:52:38] [14] [00:01:56] Finished devel/dwarves | dwarves-1.19_3: = Success >>=20 >> But it does not break out build-depends vs. lib-depends vs. = run-depends >> specifics, for example. >>=20 >> It looks like for many of the later small package builds, those >> 3 activities now make up most of the elapsed-time consequences >> for those builds. >>=20 >> top over various time frames shows mostly the likes of: >>=20 >> 66921 59 root 131 0 230016Ki 179080Ki CPU5 5 0:26 = 99.56% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg >> 66914 59 root 68 0 19536Ki 9344Ki wait 10 0:00 = 0.00% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg >> 66804 59 root 68 0 13408Ki 3120Ki wait 10 0:00 = 0.00% /bin/sh /usr/ports/Mk/Scripts/do-depends.sh >>=20 >> for for build-depends, lib-depends, and run-depends for the >> activity for each active builder. None of the ports are "large >> build step" ones for where I happen to have sampled or when I >> happened to watch with top. But: Most packages are not "large >> build step" ones so this is expected much of the time. >>=20 >> NOTE: >> The above explains the load averages being near the FreeBSD number >> of cpus during periods when all the active builders were doing >> such activity, as is common over many parts of the build sequence. >>=20 >>=20 >> Other notes: >>=20 >> There is evidence on the build cluster results that the main-* >> runs have a notably larger Elapsed time multiplier than the >> 13* and 14* runs do. 13* and 14* are still substantial of >> themselves. My guess is that main-* uses a debug 15000?? >> kernel and possibly a debug jail-world and 13* and 14* use a >> non-debug 15000?? kernel (and a non-debug jail-world). But >> such details do not seem to be in public descriptive information >> or published in public log files. I expect the dependency >> analysis activity happens to touch Elapsed-time-consuming >> debug code. May be a more selective variant of debug kernel >> and/or world builds could be used instead that avoids a >> notable amount of that? >>=20 >> It looks like having a partially pre-built bulk -a to start >> from could avoid wait-time for establishing a context that >> shows the Elapsed time behavior for build-depends, lib-depends, >> and run-depends. >>=20 >> I ended up with having to restart poudriere(-devel) during my >> investigations and ended up using a non-debug kernel. So the >> times on the left below are from when it queued 26014 and then >> inspected 7111, not from the start of the original "bulk -c -a" >> on the Apple silicon M4 MAX under Parallels on macOS. For comparison/contrast, 3 other aarch64 contexts: (The fetch would not have to repeat.) Just a -C devel/dwarves (no other builders, no need to rebuild dependencies): Windows Dev Kit 2023: [00:03:22] [03] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = fetch [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = checksum [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:05:45] [03] [00:02:23] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:06:04] [03] [00:02:42] Status devel/dwarves | dwarves-1.19_3: = configure [00:06:04] [03] [00:02:42] Status devel/dwarves | dwarves-1.19_3: = build [00:06:07] [03] [00:02:45] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:06:07] [03] [00:02:45] Status devel/dwarves | dwarves-1.19_3: = stage [00:06:07] [03] [00:02:45] Status devel/dwarves | dwarves-1.19_3: = package [00:06:08] [03] [00:02:46] Finished devel/dwarves | dwarves-1.19_3: = Success RPi5B: [00:04:01] [03] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:04:07] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:04:07] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = checksum [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:08:16] [03] [00:04:15] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:08:53] [03] [00:04:52] Status devel/dwarves | dwarves-1.19_3: = configure [00:08:54] [03] [00:04:53] Status devel/dwarves | dwarves-1.19_3: = build [00:08:59] [03] [00:04:58] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:08:59] [03] [00:04:58] Status devel/dwarves | dwarves-1.19_3: = stage [00:08:59] [03] [00:04:58] Status devel/dwarves | dwarves-1.19_3: = package [00:09:00] [03] [00:04:59] Finished devel/dwarves | dwarves-1.19_3: = Success HoneyComb: [00:04:52] [03] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:04:58] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:04:58] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = checksum [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:10:05] [03] [00:05:13] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:10:54] [03] [00:06:02] Status devel/dwarves | dwarves-1.19_3: = configure [00:10:55] [03] [00:06:03] Status devel/dwarves | dwarves-1.19_3: = build [00:10:59] [03] [00:06:07] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:10:59] [03] [00:06:07] Status devel/dwarves | dwarves-1.19_3: = stage [00:10:59] [03] [00:06:07] Status devel/dwarves | dwarves-1.19_3: = package [00:11:00] [03] [00:06:08] Finished devel/dwarves | dwarves-1.19_3: = Success M4 MAX (reminder): > [00:00:38] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch > [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:01:15] [05] [00:00:37] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:01:21] [05] [00:00:43] Status devel/dwarves | dwarves-1.19_3: = configure > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = build > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = stage > [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = package > [00:01:22] [05] [00:00:44] Finished devel/dwarves | dwarves-1.19_3: = Success Just a -C mail/mailest@nox (no other builders, no need to rebuild dependencies): Windows Dev Kit 2023: [00:03:18] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:03:18] [01] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:03:18] [01] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:03:46] [01] [00:00:28] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:03:46] [01] [00:00:28] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:03:48] [01] [00:00:30] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:04:17] [01] [00:00:59] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:04:17] [01] [00:00:59] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:04:18] [01] [00:01:00] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success RPi5B: [00:04:07] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:04:58] [01] [00:00:51] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:04:58] [01] [00:00:51] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:05:01] [01] [00:00:54] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:05:48] [01] [00:01:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:05:48] [01] [00:01:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:05:48] [01] [00:01:41] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success HoneyComb: [00:04:31] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:04:32] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:04:32] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:04:34] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:05:39] [01] [00:01:08] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:05:39] [01] [00:01:08] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:05:42] [01] [00:01:11] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:06:41] [01] [00:02:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:06:41] [01] [00:02:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:06:42] [01] [00:02:11] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success M4 MAX (reminder): > [00:00:37] [13] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:01:00] [13] [00:00:23] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:01:08] [13] [00:00:31] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success Just a -C devel/py-inline-snapshot@py311 (no other builders, no need to = rebuild dependencies): Windows Dev Kit 2023: [00:03:15] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 [00:03:15] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 [00:03:15] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity [00:03:15] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends [00:04:10] [02] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends [00:04:10] [02] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure [00:04:10] [02] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build [00:04:11] [02] [00:00:56] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends [00:05:02] [02] [00:01:47] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage [00:05:02] [02] [00:01:47] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package [00:05:03] [02] [00:01:48] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success RPi5B: [00:04:14] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 [00:04:14] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch [00:04:16] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends [00:05:53] [02] [00:01:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends [00:05:53] [02] [00:01:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure [00:05:53] [02] [00:01:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build [00:05:54] [02] [00:01:40] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends [00:07:42] [02] [00:03:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage [00:07:42] [02] [00:03:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package [00:07:42] [02] [00:03:28] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success HoneyComb: [00:04:16] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 [00:04:17] [02] [00:00:01] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 [00:04:17] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract [00:04:19] [02] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends [00:04:19] [02] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch [00:04:19] [02] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends [00:06:22] [02] [00:02:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends [00:06:22] [02] [00:02:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure [00:06:22] [02] [00:02:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build [00:06:23] [02] [00:02:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends [00:08:55] [02] [00:04:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage [00:08:55] [02] [00:04:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package [00:08:56] [02] [00:04:40] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success M4 MAX (reminder): > [00:00:34] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 > [00:00:34] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage > [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package > [00:01:24] [02] [00:00:50] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success Overall: It sure looks like each of thousands --or 10s of thousands-- of "small builder step" packages now take much longer to build because of build-depends, lib-depends, and run-depends processing. I'm not clear how optimizing to approximate the pre-pkg-2.1.0 times would be done for the "small builder step" packages type of context. =46rom various people building their own parts, you may well get requests to allow them to disable the time-taking activity, reverting to more like 2.0.6 for the handling on the issue. It looks like main-arm64-default may well take about 2 weeks to do a "bulk -a -c" on ampere2. It is at 236:49:46 and has 12458 to go, so still about 1/3rd to go. main-arm64 looks to take notably longer than 13*arm64 and 14*arm64 do for pkg 2.1.0 being in use. (Checked time and remaining at: = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp25bf3a3260c7_s680d34896c3 that updates more often than: https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 does.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 11 03:36:34 2025 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 4ZYj6G1LTjz5sRpW for ; Fri, 11 Apr 2025 03:36:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZYj6F5XC4z49TL for ; Fri, 11 Apr 2025 03:36:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BW7QyPvb; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744342607; bh=GV6kcOvqCxyxBYMSQqPQlSjQIOqcmp57ouC5x7fZJR8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BW7QyPvba7jr1W6ri1D3I/bQZx/c5BztRrDpG9nJa18RsEH1JJmPwhdlMQWdErn9RBO7Yhw2YQloUQUbM4RfdJaCXBxYjizLSRwq7/ljIPw4eBxXMFVo+HK1j2XXBm6nVIwVrFX8zNe0e9kuVHbcboXeUGq3KZBNa6UkrDVEfKYIwX+YeA6mHYFC/vRdHwDmoe/zP1+uSdi6DrITLA/T/NIjUPmsdaRnr/t8RfRlEC2KqMlryrwlE6nHxm1oPo10/lsJ64wvZ+nWxAb6Q/0ZGsD4Wgts+nPF/Abe65mnAx/2FvrKbxg6u7bbAOEjW2fwOdvfkm9jurwmcLTEEzzkSw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744342607; bh=wKve0pT/cF33xJUe8uhl5Iy6yGEBEH1/eJ7mQ9WaNsL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Hq8vowuFC+Rl9oCngrsfhNm5ufPT0X0xLyIs+buXCQEshlrHCFVL3z/ChEQmX69Gzv58cgyXg+C+gEm0I76yu9O8baT7TLKUaBnUK8y7E2lLldmoWvcxMRcZ6QbNQ+H8cbnW4252lPOPFUVT3XQsoUDj2hvfeIRfMSOW+9LiJXztup29+icN0GW/BSlM2eFCuxB5Y0WX5/2BW6No9y4RNUnxwbNyuykwv83mQA7M47aoiCaK185tw4xErTWWLbX2d+BjtvQs8/ncbIk545QO29qT5+v95WXTkyjwq1bFLXfjLJgmqoj2OgXQyUdG3uVCi9IstkicolBj+K0cTbL0hw== X-YMail-OSG: Dm8dNTMVM1mu4thmDC2QsmDWGOJQFsj2gf7GrhjVTPQGbXSsCSM749hg275m4.A WAi872HP0n11K5Uc7V_IWE0oJOFefaFgeDh2oSrom67hby3PCq2z_YVdPpTXyCxsaPrBGzw3zUh1 duk3tnI3Fk0gXxqAnqVIoWudfCGIpyxHFI0legYA0QTrCP9Eq84eT0XylRylLZ8Zw3iYUeC2ldLa RDNmu0Wy5.e8JWMuE8FgMOl00vK5kgK8cXJu3IKnp7350DWoLlAPMvT8bBLPhtTHGCTOICES_pCZ echliYB5msfCZWevq4RpdzN6i9pqm.PdUCRym5OP9uNhae199DMZtCY1PvZ_r.K6ol2m_7jaYcUJ gKgFeTe5eCP.0nPGVNlDV6MMgNIh.leKo7WxkLZIUUsewomDm4iTJm2hkmJ2Nyh7Y7aBKYgPHBcL no3C4IDRgOXAAA6ufRwta4VIm_yIuCxYogEkC.Fpe__Fgm5fUjYmoVI3M2snX3RiJ.eqp4gMyPVG 6bW6kqrXiHDwgjboZzPyWiyel1Aw7f4kcuu7buLEBC86mD9nXnlE29SwQm_8b1YYoye1MEjEh.TT 8esOsA9v.2C0untTilWdwP7UqRmxk3BU0XHenzmrsiumCrpA4RzxSe99K83HlhvhUU3fHARk19uF YQfz3KQE5d5r9nE9z9cuMMPJl.9wKEWXXTCkUsZ74TsB1Bzh85ODEA1rL.UFhi4Mn77XHmqpC5rk QPggtWflx.bcGaGBs_bbJqX6nw8wMNQhUNeiYzrJQkZWSntt.i6v5..yREbLV.MPtg6xw8IfT3FX 8vt.E.XUEgVqKl2MSzBu8I05oALDZkO8BfrehBd7tQYAQrz5xSBpPWwj6UCF1mnM.tIdKPoUtBxy DlMITJ_SB1q2goFYb5j0fgSyl5rnRNmZ4qq6melt0dz3YP8LQX4aTNbKvDqpNnBKM_VZvf7E6K11 vmtKqYwvU8Wa5VJvAa2YrsE0Rlh9dFB_CZLbY5bNpRTtRMa1r6dGAqd2.vbPs9xLxkQbXqzuaavW QePsCdNgzidwnS0KVcNtwRQPIz9QVGlMsCFzLfFGkaK84qY9dV36D7DTjRyIIJyonBRazcT_a7.9 9DyC33sQaaM46xky8yk3s2KyMyIQT598c8wKNBLRinFoW_JDHWYevi01TEhMsn5a9DaQQqDkKGf. lNY_VuK_5Y3AgLa_NtRzdxuVCcqnN2DvV8l3TTjUG8P3l2yMuRm28HS0IlLqm9k4rga8OZiTLIJa kgiIGb4joSh.3de9u2I39kjxlcVwW2_7vYr_Qra.616iBBrNV80Y_etXrQThAeTMj2YizlqTFtWz Wbhx2zOQYB1OVu8O9YzyPL.AcEI2q.tW8mhS24ePg3_wJhHNpW5ArkXpdWYMnrl4xBm.rC0P7yCp J60llqraDb5k_vOuXaD3L.LOTs6FlerMD01q3Y0.Nwz6cZoRLZ6OXj_NOWvbxHvv20ORwjwiHtkw TS95h2YvLM7MkJdM2HmV_J1B8erYE_oahCqf2CUUw7OWiQeulmsZwN3bttWIApVA6tyntuApho.B aWQ65kAmgNB3ATi39N96DBnl.wvpjGCmvwcaIP0nkriYccM5TvbL6Vc0kSXnsbtnkKtvKDmh0U4g rNnHe74.b2aE8WlRFyFxcLZ0UBEBy25NjyUXgM0mbKDsCeH8dNPwGo3m61rqyqZlAQimEGN6EeSk ChTDd221SeMiElLyFmEhU9kRYwPNuHIuKiF1m_EFaVHBX7Wv6nXBiygfbHLXvAvOGJDUsev9gK4_ uoMQM5V9WJXxYreHR.wbv9f9AIWMCP5iyjOmnk3cfuU9MrqFLWJdaT_lA9kb1yzGCzgx8kWx0Y_P da7Y5pTCcrNgqwbwk9Yq9nS_ucNd5PvdfiIl9wXkmqzp5oQ.8s0Rh8xIJTmdNEwbtedOo6CsYvWo fe8PzXfsEHJxhMzZwHDCTDg32DNB4pOvcN.1BAwmAdOOOwrTovgkY6bJDdn1ie_ttwF6NWGtjkXb qQxJKTDeSUGTuAbc442rc6N9yHQp7d.H3cJVTuqtmXnkEQVdMgQo.RmBgIq7HpAaO1t6ZtvxjkdU Po4YRfRx_jxEf1MUpEtOhmi0ZotrvzniyUUMpLdG14Hogi.zRf0.CN5NsH068xX3V90rDm5TMWzy kzv3QpMZvsK4fpvxUOtCamQTc3Hnmu5nwhGLBeA1Ow1ox5ZgJwDAjwqcMUID4R3evYBiGmuC6WKI FAh3E8jHLEaxwD2uBQiOfM3XPV.xqTdlQQvJtdoLSiwy_YcucxqFy1cliDc77Wm18JuhB0DOMKq0 U.qITLg-- X-Sonic-MF: X-Sonic-ID: b6a89c5b-cdc2-4c9f-87d6-72fbe05ce6a3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Apr 2025 03:36:47 +0000 Received: by hermes--production-gq1-6f8bfcd964-jwz7q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8edfe1cac5195409d0e97073ceda541b; Fri, 11 Apr 2025 03:36:45 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [Examples of {build,lib,run}-depends timings for bulk -a --and some other aarch64 timings] From: Mark Millard In-Reply-To: Date: Thu, 10 Apr 2025 20:36:34 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <6E1D0579-4AC3-4EEA-8426-DBA4E5CC6B0A@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <0414EBFB-B63A-4738-ADB0-38B6CF3725DA@yahoo.com> <05128806-8F20-43A6-946B-A3780259F61A@yahoo.com> <178AD8CD-57F2-4ADB-AE82-6B0C7A4D2C01@yahoo.com> <48D0BE51-8111-465B-96BC-969DE7EBFEFC@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-2.80 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.68.32:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.965]; NEURAL_SPAM_MEDIUM(0.66)[0.664]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZYj6F5XC4z49TL X-Spamd-Bar: -- On Apr 10, 2025, at 15:36, Mark Millard wrote: > On Apr 10, 2025, at 10:14, Mark Millard wrote: >=20 >> On Apr 10, 2025, at 09:25, Mark Millard wrote: >>=20 >>> The following data are from later in the builder seqeunce. >>> Here I'm not looking at builder activity with large Elapsed >>> multiplication factors for the build. It is more of a random >>> sampling showing examples of build-depends, lib-depends, and >>> run-depends and some with more than one of those notably >>> contributing. This is later when dependencies are normally >>> involve for the package builds. >>>=20 >>> A property of the dependency based ordering of builds is that >>> the earlier builds tend of have fewer dependencies and the later >>> builds tend to have more. >>>=20 >>> For building around 36000 packages, even a mean rate of around >>> 1 extra second per is around 10 hrs of extra time. (But normal >>> extra times are not generally near the mean-extra-time.) >>>=20 >>> It appears that a big factor in the overall Elapsed time is >>> the large fraction of the 30000+ packages that are "small >>> build step" packages --the subset of that for which build later >>> because of involved dependencies. The dependency analysis is more >>> time consuming than the build time --or even total for all of the >>> steps other than build-depends, lib-depends, and run-depends. >>>=20 >>> Basically: for the most part, only early builder runs can be >>> quick runs (no or very limited dependencies involved). >>>=20 >>> It would take a massive decrease in most build-depends, >>> lib-depends, and run-depends (when any) Elapsed times in >>> later builds for this not to be the case --because of the >>> number of packages for which the rest of the time is small. >>> Such does not seem likely? >>=20 >> The additions in this note show some examples of just >> one builder being active instead of when others are >> also active. Each is a bulk -C ORIGIN of ORIGIN I'd >> listed data for previously. >=20 > The M4 MAX is unusually fast for aarch64 at this point. > So . . . >=20 > This note addition takes those 3 package examples and > runs the "just the one builder" tests on each of 3 > other aarch64 systems: >=20 > Windows Dev Kit 2023 ( 8 core aarch64, 4 X1C cores and 4 A78C cores) > RPi5B ( 4 core aarch64, cortex-a76's) > HoneyComb (16 core aarch64, cortex-a72's) >=20 > Note: The X1C and A78C cores do not perform the same. Scheduling > variations can lead to time variations. >=20 > Note: All this activity is based on an official PkgBase build > of 1500035 kernel-NODEBUG and the jail world also being from an > official PkgBase build for releng/14.2 : >=20 > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH > release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 >=20 > PkgBase updates do not seem to update the -p1 part of VERSION. >=20 > # file /usr/local/poudriere/jails/release-aarch64/bin/sh > /usr/local/poudriere/jails/release-aarch64/bin/sh: ELF 64-bit LSB pie = executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, = interpreter /libexec/ld-elf.so.1, for FreeBSD 14.2, FreeBSD-style, = stripped >=20 >>> The supporting detail . . . >>>=20 >>> I'll note that the 3 load averages reported by top for the >>> below were near the number of FreeBSD cpus whenever I happened >>> to check that, instead of being during high load average time >>> frames. (I.e., no packages with large builder steps were >>> active.) There is a later explanation of this. >>>=20 >>>=20 >>> Both build-depends and lib-depends: >>>=20 >>> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[03:52:[0-9][0-9]\] .*configure$" | more >>> . . . >>> [03:50:57] [14] [00:00:15] Status devel/dwarves | = dwarves-1.19_3: patch-depends >>> [03:50:57] [14] [00:00:15] Status devel/dwarves | = dwarves-1.19_3: patch >>> [03:50:59] [14] [00:00:17] Status devel/dwarves | = dwarves-1.19_3: build-depends >>> [03:52:17] [14] [00:01:35] Status devel/dwarves | = dwarves-1.19_3: lib-depends >>> [03:52:28] [14] [00:01:46] Status devel/dwarves | = dwarves-1.19_3: configure >>> [03:52:31] [14] [00:01:49] Status devel/dwarves | = dwarves-1.19_3: build >>> [03:52:33] [14] [00:01:51] Status devel/dwarves | = dwarves-1.19_3: run-depends >>> [03:52:34] [14] [00:01:52] Status devel/dwarves | = dwarves-1.19_3: stage >>> . . . >>=20 >> For comparison/contrast: >> (The fetch would not have to repeat.) >>=20 >> I stopped the bulk -a an run just a -C devel/dwarves (no other = builders, >> no need to rebuild dependencies): >>=20 >> [00:00:38] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = check-sanity >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = pkg-depends >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch-depends >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = checksum >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract-depends >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch-depends >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = build-depends >> [00:01:15] [05] [00:00:37] Status devel/dwarves | dwarves-1.19_3: = lib-depends >> [00:01:21] [05] [00:00:43] Status devel/dwarves | dwarves-1.19_3: = configure >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = build >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = run-depends >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = stage >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = package >> [00:01:22] [05] [00:00:44] Finished devel/dwarves | dwarves-1.19_3: = Success >>=20 >> Still a non-trivial addition to the Elapsed time if there >> are 10s of thousands of such packages in the ball park. >>=20 >>> -- >>> [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: patch-depends >>> [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: patch >>> [03:52:08] [01] [00:00:08] Status security/seccure | = seccure-0.5_10: build-depends >>> [03:52:18] [01] [00:00:18] Status security/seccure | = seccure-0.5_10: lib-depends >>> [03:52:31] [01] [00:00:31] Status security/seccure | = seccure-0.5_10: configure >>> [03:52:31] [01] [00:00:31] Status security/seccure | = seccure-0.5_10: build >>> [03:52:32] [01] [00:00:32] Status security/seccure | = seccure-0.5_10: run-depends >>> [03:52:32] [01] [00:00:32] Status security/seccure | = seccure-0.5_10: stage >>>=20 >>>=20 >>> lib-depends: >>>=20 >>> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[05:20:[0-9][0-9]\] .*configure$" | more >>> . . . >>> -- >>> [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch-depends >>> [05:19:35] [05] [00:00:10] Status graphics/gdchart | = gdchart-0.11.5_11: patch >>> [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: build-depends >>> [05:19:36] [05] [00:00:11] Status graphics/gdchart | = gdchart-0.11.5_11: lib-depends >>> [05:20:08] [05] [00:00:43] Status graphics/gdchart | = gdchart-0.11.5_11: configure >>> [05:20:09] [05] [00:00:44] Status graphics/gdchart | = gdchart-0.11.5_11: build >>> [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: run-depends >>> [05:20:11] [05] [00:00:46] Status graphics/gdchart | = gdchart-0.11.5_11: stage >>> . . . >>> -- >>> [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch-depends >>> [05:20:02] [06] [00:02:04] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: patch >>> [05:20:03] [06] [00:02:05] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build-depends >>> [05:20:04] [06] [00:02:06] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: lib-depends >>> [05:20:26] [06] [00:02:28] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: configure >>> [05:20:27] [06] [00:02:29] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: build >>> [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: run-depends >>> [05:20:39] [06] [00:02:41] Status net-p2p/bitmark-recorder | = bitmark-recorder-0.16.0_1: stage >>>=20 >>>=20 >>> build-depends and run-depends: >>>=20 >>> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[09:15:[0-9][0-9]\] .*configure$" | more >>> [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch-depends >>> [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: patch >>> [09:15:03] [07] [00:00:04] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build-depends >>> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: lib-depends >>> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: configure >>> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: build >>> [09:15:22] [07] [00:00:23] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: run-depends >>> [09:16:01] [07] [00:01:02] Status = databases/pear-Horde_Memcache@php82 | = php82-pear-horde-Horde_Memcache-2.1.2: stage >>> . . . >>> -- >>> [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch-depends >>> [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: patch >>> [09:15:13] [04] [00:00:13] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build-depends >>> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: lib-depends >>> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: configure >>> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: build >>> [09:15:31] [04] [00:00:31] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: run-depends >>> [09:16:08] [04] [00:01:08] Status devel/pear-Horde_Date@php82 | = php82-pear-horde-Horde_Date-2.4.1: stage >>> . . . >>> -- >>> [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch-depends >>> [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: patch >>> [09:14:59] [13] [00:00:03] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build-depends >>> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: lib-depends >>> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: configure >>> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: build >>> [09:15:18] [13] [00:00:22] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: run-depends >>> [09:16:19] [13] [00:01:23] Status net/pear-Horde_Ldap@php82 | = php82-pear-horde-Horde_Ldap-2.4.2: stage >>> -- >>> [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch-depends >>> [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: patch >>> [09:14:44] [02] [00:00:04] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build-depends >>> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: lib-depends >>> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: configure >>> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: build >>> [09:15:03] [02] [00:00:23] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: run-depends >>> [09:15:21] [02] [00:00:41] Status net/pear-Horde_Url@php82 | = php82-pear-horde-Horde_Url-2.2.6: stage >>> -- >>> [09:14:59] [09] [00:00:03] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = patch-depends >>> [09:15:00] [09] [00:00:04] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = patch >>> [09:15:00] [09] [00:00:04] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = build-depends >>> [09:15:19] [09] [00:00:23] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = lib-depends >>> [09:15:19] [09] [00:00:23] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = configure >>> [09:15:19] [09] [00:00:23] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = build >>> [09:15:19] [09] [00:00:23] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = run-depends >>> [09:15:59] [09] [00:01:03] Status = security/pear-Horde_Group@php82 | php82-pear-horde-Horde_Group-2.1.1: = stage >>> -- >>> [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch-depends >>> [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: patch >>> [09:15:00] [14] [00:00:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build-depends >>> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: lib-depends >>> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: configure >>> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: build >>> [09:15:20] [14] [00:00:24] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: run-depends >>> [09:16:00] [14] [00:01:04] Status = www/pear-Horde_SessionHandler@php82 | = php82-pear-horde-Horde_SessionHandler-2.3.0: stage >>>=20 >>>=20 >>> Mostly build-depends but one also has lib-depends: >>>=20 >>> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[11:10:[0-9][0-9]\] .*configure$" | more >>> [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch-depends >>> [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: patch >>> [11:10:02] [14] [00:00:02] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build-depends >>> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: lib-depends >>> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: configure >>> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: build >>> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: run-depends >>> [11:10:46] [14] [00:00:46] Status devel/cask@nox | = cask-emacs_nox-0.8.3_17: stage >>> -- >>> [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch-depends >>> [11:09:53] [04] [00:00:10] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: patch >>> [11:09:54] [04] [00:00:11] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build-depends >>> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: lib-depends >>> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: configure >>> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: build >>> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: run-depends >>> [11:10:38] [04] [00:00:55] Status devel/distel@nox | = distel-emacs_nox-4.1.1_19: stage >>> -- >>> [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch-depends >>> [11:09:36] [12] [00:00:14] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: patch >>> [11:09:37] [12] [00:00:15] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build-depends >>> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: lib-depends >>> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: configure >>> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: build >>> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: run-depends >>> [11:10:00] [12] [00:00:38] Status devel/lua-mode@nox | = lua-mode-emacs_nox-20210802_10: stage >>> -- >>> [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: = patch-depends >>> [11:09:14] [05] [00:00:17] Status devel/obby | obby-0.4.8_6: = patch >>> [11:09:16] [05] [00:00:19] Status devel/obby | obby-0.4.8_6: = build-depends >>> [11:09:59] [05] [00:01:02] Status devel/obby | obby-0.4.8_6: = lib-depends >>> [11:10:21] [05] [00:01:24] Status devel/obby | obby-0.4.8_6: = configure >>> [11:10:26] [05] [00:01:29] Status devel/obby | obby-0.4.8_6: = build >>> [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: = run-depends >>> [11:10:37] [05] [00:01:40] Status devel/obby | obby-0.4.8_6: = stage >>> -- >>> [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch-depends >>> [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: patch >>> [11:10:01] [07] [00:00:06] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build-depends >>> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: lib-depends >>> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: configure >>> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: build >>> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: run-depends >>> [11:10:23] [07] [00:00:28] Status devel/pkg-info.el@nox | = pkg-info.el-emacs_nox-0.6_18: stage >>> -- >>> [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch-depends >>> [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: patch >>> [11:10:21] [02] [00:00:02] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build-depends >>> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: lib-depends >>> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: configure >>> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: build >>> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: run-depends >>> [11:10:40] [02] [00:00:21] Status devel/tablist@nox | = tablist-emacs_nox-1.0.13_10: stage >>> -- >>> [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch-depends >>> [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: patch >>> [11:10:03] [11] [00:00:02] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build-depends >>> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: lib-depends >>> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: configure >>> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: build >>> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: run-depends >>> [11:10:25] [11] [00:00:24] Status editors/apel@nox | = apel-emacs_nox-10.8.20220720_10: stage >>> -- >>> [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch-depends >>> [11:09:45] [09] [00:00:12] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: patch >>> [11:09:46] [09] [00:00:13] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build-depends >>> [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: lib-depends >>> [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: configure >>> [11:10:33] [09] [00:01:00] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: build >>> [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: run-depends >>> [11:10:37] [09] [00:01:04] Status editors/slime@nox | = slime-emacs_nox-2.26.1.9_14: stage >>> -- >>> [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >>> [11:09:48] [13] [00:00:14] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >>> [11:09:51] [13] [00:00:17] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >>> [11:09:52] [13] [00:00:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >>> [11:10:14] [13] [00:00:40] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >>> [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >>> [11:10:15] [13] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >>> [11:10:38] [13] [00:01:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >>=20 >> For comparison/contrast: >> (The fetch would not have to repeat.) >>=20 >> I stopped the bulk -a an run just a -C mail/mailest@nox (no other = builders, >> no need to rebuild dependencies): >>=20 >> [00:00:37] [13] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >> [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >> [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >> [00:01:00] [13] [00:00:23] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >> [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >> [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package >> [00:01:08] [13] [00:00:31] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >>=20 >> Still a non-trivial addition to the Elapsed time if there >> are 10s of thousands of such packages in the ball park. >>=20 >>> -- >>> [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch-depends >>> [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: patch >>> [11:10:04] [12] [00:00:03] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build-depends >>> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: lib-depends >>> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: configure >>> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: build >>> [11:10:27] [12] [00:00:26] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: run-depends >>> [11:10:29] [12] [00:00:28] Status mail/x-face-e21@nox | = x-face-e21-emacs_nox-20070306_33: stage >>>=20 >>>=20 >>> build-depends: >>>=20 >>> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[12:47:[0-9][0-9]\] .*configure$" | more >>> [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch-depends >>> [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: patch >>> [12:46:29] [14] [00:00:03] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build-depends >>> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: lib-depends >>> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: configure >>> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: build >>> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: run-depends >>> [12:47:42] [14] [00:01:16] Status databases/p5-Amazon-SimpleDB | = p5-Amazon-SimpleDB-0.03_1: stage >>> -- >>> [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch-depends >>> [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: patch >>> [12:46:40] [13] [00:00:03] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build-depends >>> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: lib-depends >>> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: configure >>> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: build >>> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: run-depends >>> [12:47:08] [13] [00:00:31] Status textproc/p5-Text-EtText | = p5-Text-EtText-2.2_2: stage >>> -- >>> [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch-depends >>> [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: patch >>> [12:45:39] [03] [00:00:03] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build-depends >>> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: lib-depends >>> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: configure >>> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: build >>> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: run-depends >>> [12:47:00] [03] [00:01:24] Status www/p5-Catalyst-Engine-PSGI | = p5-Catalyst-Engine-PSGI-0.14: stage >>> -- >>> [12:45:04] [09] [00:00:06] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = patch-depends >>> [12:45:04] [09] [00:00:06] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = patch >>> [12:45:04] [09] [00:00:06] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = build-depends >>> [12:47:12] [09] [00:02:14] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = lib-depends >>> [12:47:12] [09] [00:02:14] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = configure >>> [12:47:12] [09] [00:02:14] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = build >>> [12:47:13] [09] [00:02:15] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = run-depends >>> [12:47:13] [09] [00:02:15] Status = www/p5-Catalyst-View-XML-Simple | p5-Catalyst-View-XML-Simple-0.01_2: = stage >>> -- >>> [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch-depends >>> [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: patch >>> [12:46:45] [08] [00:00:05] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build-depends >>> [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: lib-depends >>> [12:47:36] [08] [00:00:56] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: configure >>> [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: build >>> [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: run-depends >>> [12:47:37] [08] [00:00:57] Status www/p5-MediaWiki-API | = p5-MediaWiki-API-0.52: stage >>> -- >>> [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch-depends >>> [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: patch >>> [12:46:37] [12] [00:00:04] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build-depends >>> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: lib-depends >>> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: configure >>> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: build >>> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: run-depends >>> [12:47:54] [12] [00:01:21] Status www/p5-WWW-DHL | = p5-WWW-DHL-0.03_2: stage >>>=20 >>>=20 >>> build-depends and run-depends: >>>=20 >>> # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-2.txt | grep = -B4 -A3 -e "^\[14:03:[0-9][0-9]\] .*configure$" | more >>> [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch-depends >>> [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = patch >>> [14:02:47] [14] [00:00:02] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build-depends >>> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = lib-depends >>> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = configure >>> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = build >>> [14:03:43] [14] [00:00:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = run-depends >>> [14:04:43] [14] [00:01:58] Status = databases/py-flask-sqlalchemy@py311 | py311-flask-sqlalchemy-3.1.1: = stage >>> -- >>> [14:02:22] [01] [00:00:08] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch-depends >>> [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: patch >>> [14:02:23] [01] [00:00:09] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build-depends >>> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: lib-depends >>> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: configure >>> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: build >>> [14:03:16] [01] [00:01:02] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: run-depends >>> [14:03:43] [01] [00:01:29] Status devel/py-flask-babel@py311 | = py311-flask-babel-4.0.0_1: stage >>> -- >>> [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch-depends >>> [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch >>> [14:02:51] [03] [00:00:03] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build-depends >>> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: lib-depends >>> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: configure >>> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build >>> [14:03:43] [03] [00:00:55] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: run-depends >>> [14:05:07] [03] [00:02:19] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: stage >>=20 >> For comparison/contrast: >> (The fetch would not have to repeat.) >>=20 >> I stopped the bulk -a an run just a -C devel/py-inline-snapshot@py311 = (no other builders, >> no need to rebuild dependencies): >>=20 >> [00:00:34] [02] [00:00:00] Building devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8 >> [00:00:34] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: check-sanity >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: pkg-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: checksum >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build-depends >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: lib-depends >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: configure >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: run-depends >> [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: stage >> [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: package >> [00:01:24] [02] [00:00:50] Finished devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: Success >>=20 >> Still a non-trivial addition to the Elapsed time if there >> are 10s of thousands of such packages in the ball park. >>=20 >>> -- >>> [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: patch-depends >>> [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: patch >>> [14:02:47] [02] [00:00:03] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: build-depends >>> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: lib-depends >>> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: configure >>> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: build >>> [14:03:43] [02] [00:00:59] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: run-depends >>> [14:05:38] [02] [00:02:54] Status devel/py-xsdata-plantuml@py311 = | py311-xsdata-plantuml-24.3: stage >>> -- >>> [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch-depends >>> [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: patch >>> [14:02:07] [10] [00:00:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build-depends >>> [14:03:06] [10] [00:01:03] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: lib-depends >>> [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: configure >>> [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: build >>> [14:03:07] [10] [00:01:04] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: run-depends >>> [14:03:34] [10] [00:01:31] Status mail/py-flask-mail@py311 | = py311-flask-mail-0.10.0: stage >>> -- >>> [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch-depends >>> [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: patch >>> [14:02:31] [06] [00:00:03] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build-depends >>> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: lib-depends >>> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: configure >>> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: build >>> [14:03:26] [06] [00:00:58] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: run-depends >>> [14:03:54] [06] [00:01:26] Status www/py-flask-bootstrap@py311 | = py311-Flask-Bootstrap-3.3.7.1_2: stage >>> -- >>> [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch-depends >>> [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: patch >>> [14:02:59] [13] [00:00:03] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build-depends >>> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: lib-depends >>> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: configure >>> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: build >>> [14:03:27] [13] [00:00:31] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: run-depends >>> [14:03:54] [13] [00:00:58] Status www/py-flask-caching@py311 | = py311-flask-caching-2.2.0_1: stage >>> -- >>> [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: patch-depends >>> [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: patch >>> [14:02:04] [08] [00:00:03] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: build-depends >>> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: lib-depends >>> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: configure >>> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: build >>> [14:03:00] [08] [00:00:59] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: run-depends >>> [14:04:24] [08] [00:02:23] Status www/py-flask-simpleldap@py311 = | py311-Flask-SimpleLDAP-2.0.0: stage >>> -- >>> [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch-depends >>> [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: patch >>> [14:02:47] [05] [00:00:02] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build-depends >>> [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: lib-depends >>> [14:03:15] [05] [00:00:30] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: configure >>> [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: build >>> [14:03:16] [05] [00:00:31] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: run-depends >>> [14:03:43] [05] [00:00:58] Status www/py-flask-theme@py311 | = py311-flask-theme-0.3.6_1: stage >>>=20 >>>=20 >>> The log file also allows me to do the likes of the following to see >>> what and how many (package level) dependencies were involved: >>>=20 >>> # grep "\[^-]" = ~/bulk-output-release-aarch64-ports-alt-2.txt | more >>> [00:00:17] devel/dwarves depends on devel/argp-standalone >>> [00:00:17] devel/dwarves depends on devel/binutils >>> [00:00:17] devel/dwarves depends on devel/cmake-core >>> [00:00:17] devel/dwarves depends on devel/elfutils >>> [00:00:17] devel/dwarves depends on devel/gettext-runtime >>> [00:00:17] devel/dwarves depends on devel/gettext-tools >>> [00:00:17] devel/dwarves depends on devel/gnulib >>> [00:00:17] devel/dwarves depends on devel/ninja >>> [00:00:17] devel/dwarves depends on lang/gcc14 >>> [00:00:17] devel/dwarves depends on ports-mgmt/pkg >>> [03:50:42] [14] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >>> [03:50:49] [14] [00:00:07] Status devel/dwarves | = dwarves-1.19_3: check-sanity >>> [03:50:49] [14] [00:00:07] Status devel/dwarves | = dwarves-1.19_3: pkg-depends >>> [03:50:51] [14] [00:00:09] Status devel/dwarves | = dwarves-1.19_3: fetch-depends >>> [03:50:51] [14] [00:00:09] Status devel/dwarves | = dwarves-1.19_3: fetch >>> [03:50:54] [14] [00:00:12] Status devel/dwarves | = dwarves-1.19_3: checksum >>> [03:50:55] [14] [00:00:13] Status devel/dwarves | = dwarves-1.19_3: extract-depends >>> [03:50:55] [14] [00:00:13] Status devel/dwarves | = dwarves-1.19_3: extract >>> [03:50:57] [14] [00:00:15] Status devel/dwarves | = dwarves-1.19_3: patch-depends >>> [03:50:57] [14] [00:00:15] Status devel/dwarves | = dwarves-1.19_3: patch >>> [03:50:59] [14] [00:00:17] Status devel/dwarves | = dwarves-1.19_3: build-depends >>> [03:52:17] [14] [00:01:35] Status devel/dwarves | = dwarves-1.19_3: lib-depends >>> [03:52:28] [14] [00:01:46] Status devel/dwarves | = dwarves-1.19_3: configure >>> [03:52:31] [14] [00:01:49] Status devel/dwarves | = dwarves-1.19_3: build >>> [03:52:33] [14] [00:01:51] Status devel/dwarves | = dwarves-1.19_3: run-depends >>> [03:52:34] [14] [00:01:52] Status devel/dwarves | = dwarves-1.19_3: stage >>> [03:52:35] [14] [00:01:53] Status devel/dwarves | = dwarves-1.19_3: package >>> [03:52:38] [14] [00:01:56] Finished devel/dwarves | = dwarves-1.19_3: Success >>>=20 >>> But it does not break out build-depends vs. lib-depends vs. = run-depends >>> specifics, for example. >>>=20 >>> It looks like for many of the later small package builds, those >>> 3 activities now make up most of the elapsed-time consequences >>> for those builds. >>>=20 >>> top over various time frames shows mostly the likes of: >>>=20 >>> 66921 59 root 131 0 230016Ki 179080Ki CPU5 5 = 0:26 99.56% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg >>> 66914 59 root 68 0 19536Ki 9344Ki wait 10 = 0:00 0.00% /usr/local/sbin/pkg-static add -A = /packages/All/py311-flask-3.1.0.pkg >>> 66804 59 root 68 0 13408Ki 3120Ki wait 10 = 0:00 0.00% /bin/sh /usr/ports/Mk/Scripts/do-depends.sh >>>=20 >>> for for build-depends, lib-depends, and run-depends for the >>> activity for each active builder. None of the ports are "large >>> build step" ones for where I happen to have sampled or when I >>> happened to watch with top. But: Most packages are not "large >>> build step" ones so this is expected much of the time. >>>=20 >>> NOTE: >>> The above explains the load averages being near the FreeBSD number >>> of cpus during periods when all the active builders were doing >>> such activity, as is common over many parts of the build sequence. >>>=20 >>>=20 >>> Other notes: >>>=20 >>> There is evidence on the build cluster results that the main-* >>> runs have a notably larger Elapsed time multiplier than the >>> 13* and 14* runs do. 13* and 14* are still substantial of >>> themselves. My guess is that main-* uses a debug 15000?? >>> kernel and possibly a debug jail-world and 13* and 14* use a >>> non-debug 15000?? kernel (and a non-debug jail-world). But >>> such details do not seem to be in public descriptive information >>> or published in public log files. I expect the dependency >>> analysis activity happens to touch Elapsed-time-consuming >>> debug code. May be a more selective variant of debug kernel >>> and/or world builds could be used instead that avoids a >>> notable amount of that? >>>=20 >>> It looks like having a partially pre-built bulk -a to start >>> from could avoid wait-time for establishing a context that >>> shows the Elapsed time behavior for build-depends, lib-depends, >>> and run-depends. >>>=20 >>> I ended up with having to restart poudriere(-devel) during my >>> investigations and ended up using a non-debug kernel. So the >>> times on the left below are from when it queued 26014 and then >>> inspected 7111, not from the start of the original "bulk -c -a" >>> on the Apple silicon M4 MAX under Parallels on macOS. >=20 >=20 > For comparison/contrast, 3 other aarch64 contexts: > (The fetch would not have to repeat.) >=20 >=20 > Just a -C devel/dwarves (no other builders, no need to rebuild > dependencies): >=20 > Windows Dev Kit 2023: >=20 > [00:03:22] [03] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:03:26] [03] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract > [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch > [00:03:27] [03] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:05:45] [03] [00:02:23] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:06:04] [03] [00:02:42] Status devel/dwarves | dwarves-1.19_3: = configure > [00:06:04] [03] [00:02:42] Status devel/dwarves | dwarves-1.19_3: = build > [00:06:07] [03] [00:02:45] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:06:07] [03] [00:02:45] Status devel/dwarves | dwarves-1.19_3: = stage > [00:06:07] [03] [00:02:45] Status devel/dwarves | dwarves-1.19_3: = package > [00:06:08] [03] [00:02:46] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 > RPi5B: >=20 > [00:04:01] [03] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:04:07] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:04:07] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch > [00:04:08] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:08:16] [03] [00:04:15] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:08:53] [03] [00:04:52] Status devel/dwarves | dwarves-1.19_3: = configure > [00:08:54] [03] [00:04:53] Status devel/dwarves | dwarves-1.19_3: = build > [00:08:59] [03] [00:04:58] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:08:59] [03] [00:04:58] Status devel/dwarves | dwarves-1.19_3: = stage > [00:08:59] [03] [00:04:58] Status devel/dwarves | dwarves-1.19_3: = package > [00:09:00] [03] [00:04:59] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 > HoneyComb: >=20 > [00:04:52] [03] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:04:58] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:04:58] [03] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = extract > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = patch > [00:04:59] [03] [00:00:07] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:10:05] [03] [00:05:13] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:10:54] [03] [00:06:02] Status devel/dwarves | dwarves-1.19_3: = configure > [00:10:55] [03] [00:06:03] Status devel/dwarves | dwarves-1.19_3: = build > [00:10:59] [03] [00:06:07] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:10:59] [03] [00:06:07] Status devel/dwarves | dwarves-1.19_3: = stage > [00:10:59] [03] [00:06:07] Status devel/dwarves | dwarves-1.19_3: = package > [00:11:00] [03] [00:06:08] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 > M4 MAX (reminder): >=20 >> [00:00:38] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = check-sanity >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = pkg-depends >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch-depends >> [00:00:39] [05] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = checksum >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract-depends >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = extract >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch-depends >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = patch >> [00:00:40] [05] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = build-depends >> [00:01:15] [05] [00:00:37] Status devel/dwarves | dwarves-1.19_3: = lib-depends >> [00:01:21] [05] [00:00:43] Status devel/dwarves | dwarves-1.19_3: = configure >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = build >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = run-depends >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = stage >> [00:01:22] [05] [00:00:44] Status devel/dwarves | dwarves-1.19_3: = package >> [00:01:22] [05] [00:00:44] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 >=20 >=20 > Just a -C mail/mailest@nox (no other builders, no need to rebuild > dependencies): >=20 > Windows Dev Kit 2023: >=20 > [00:03:18] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:03:18] [01] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:03:18] [01] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:03:19] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:03:46] [01] [00:00:28] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:03:46] [01] [00:00:28] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:03:48] [01] [00:00:30] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:04:17] [01] [00:00:59] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:04:17] [01] [00:00:59] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:04:18] [01] [00:01:00] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >=20 > RPi5B: >=20 > [00:04:07] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:04:08] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:04:58] [01] [00:00:51] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:04:58] [01] [00:00:51] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:05:01] [01] [00:00:54] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:05:48] [01] [00:01:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:05:48] [01] [00:01:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:05:48] [01] [00:01:41] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >=20 > HoneyComb: >=20 > [00:04:31] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:04:32] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:04:32] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:04:33] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:04:34] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:05:39] [01] [00:01:08] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:05:39] [01] [00:01:08] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:05:42] [01] [00:01:11] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:06:41] [01] [00:02:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:06:41] [01] [00:02:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:06:42] [01] [00:02:11] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >=20 > M4 MAX (reminder): >=20 >> [00:00:37] [13] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >> [00:00:37] [13] [00:00:00] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >> [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >> [00:00:59] [13] [00:00:22] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >> [00:01:00] [13] [00:00:23] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >> [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >> [00:01:08] [13] [00:00:31] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package >> [00:01:08] [13] [00:00:31] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >=20 >=20 >=20 >=20 > Just a -C devel/py-inline-snapshot@py311 (no other builders, no need = to rebuild > dependencies): >=20 > Windows Dev Kit 2023: >=20 > [00:03:15] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 > [00:03:15] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 > [00:03:15] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity > [00:03:15] [02] [00:00:00] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [00:03:16] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [00:04:10] [02] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [00:04:10] [02] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [00:04:10] [02] [00:00:55] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [00:04:11] [02] [00:00:56] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [00:05:02] [02] [00:01:47] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage > [00:05:02] [02] [00:01:47] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package > [00:05:03] [02] [00:01:48] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success >=20 > RPi5B: >=20 > [00:04:14] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 > [00:04:14] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [00:04:15] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [00:04:16] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [00:05:53] [02] [00:01:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [00:05:53] [02] [00:01:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [00:05:53] [02] [00:01:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [00:05:54] [02] [00:01:40] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [00:07:42] [02] [00:03:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage > [00:07:42] [02] [00:03:28] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package > [00:07:42] [02] [00:03:28] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success >=20 > HoneyComb: >=20 > [00:04:16] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 > [00:04:17] [02] [00:00:01] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 > [00:04:17] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity > [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends > [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends > [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch > [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum > [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends > [00:04:18] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract > [00:04:19] [02] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [00:04:19] [02] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [00:04:19] [02] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [00:06:22] [02] [00:02:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [00:06:22] [02] [00:02:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [00:06:22] [02] [00:02:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [00:06:23] [02] [00:02:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [00:08:55] [02] [00:04:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage > [00:08:55] [02] [00:04:39] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package > [00:08:56] [02] [00:04:40] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success >=20 > M4 MAX (reminder): >=20 >> [00:00:34] [02] [00:00:00] Building devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8 >> [00:00:34] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: check-sanity >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: pkg-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: checksum >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch-depends >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch >> [00:00:34] [02] [00:00:00] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build-depends >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: lib-depends >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: configure >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build >> [00:01:02] [02] [00:00:28] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: run-depends >> [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: stage >> [00:01:24] [02] [00:00:50] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: package >> [00:01:24] [02] [00:00:50] Finished devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: Success >=20 >=20 > Overall: >=20 > It sure looks like each of thousands --or 10s of thousands-- of > "small builder step" packages now take much longer to build > because of build-depends, lib-depends, and run-depends > processing. >=20 > I'm not clear how optimizing to approximate the pre-pkg-2.1.0 > times would be done for the "small builder step" packages type > of context. >=20 > =46rom various people building their own parts, you may well get > requests to allow them to disable the time-taking activity, > reverting to more like 2.0.6 for the handling on the issue. >=20 > It looks like main-arm64-default may well take about 2 weeks to > do a "bulk -a -c" on ampere2. It is at 236:49:46 and has 12458 > to go, so still about 1/3rd to go. main-arm64 looks to take > notably longer than 13*arm64 and 14*arm64 do for pkg 2.1.0 being > in use. >=20 > (Checked time and remaining at: >=20 > = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp25bf3a3260c7_s680d34896c3 >=20 > that updates more often than: >=20 > https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 >=20 > does.) An example that took notably more time when there were no other active builders (after some other packages built that were needed). Windows Dev Kit 2023 example: [00:13:28] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 [00:13:31] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = check-sanity [00:13:31] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: pkg-depends [00:13:32] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = fetch-depends [00:13:32] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: fetch [00:13:54] [01] [00:00:26] Status www/rt50 | rt50-5.0.7: checksum [00:13:54] [01] [00:00:26] Status www/rt50 | rt50-5.0.7: = extract-depends [00:13:54] [01] [00:00:26] Status www/rt50 | rt50-5.0.7: extract [00:13:55] [01] [00:00:27] Status www/rt50 | rt50-5.0.7: = patch-depends [00:13:55] [01] [00:00:27] Status www/rt50 | rt50-5.0.7: patch [00:13:55] [01] [00:00:27] Status www/rt50 | rt50-5.0.7: = build-depends [00:22:14] [01] [00:08:46] Status www/rt50 | rt50-5.0.7: lib-depends [00:22:14] [01] [00:08:46] Status www/rt50 | rt50-5.0.7: configure [00:22:15] [01] [00:08:47] Status www/rt50 | rt50-5.0.7: build [00:22:15] [01] [00:08:47] Status www/rt50 | rt50-5.0.7: run-depends [00:22:15] [01] [00:08:47] Status www/rt50 | rt50-5.0.7: stage [00:22:17] [01] [00:08:49] Status www/rt50 | rt50-5.0.7: package [00:22:38] [01] [00:09:10] Finished www/rt50 | rt50-5.0.7: Success I'll contrast that with the M4 MAX during "bulk -v -j... -v -p alt -a" (so with competing builder activity): # sort -s -k5,5 ~/bulk-output-release-aarch64-ports-alt-4.txt \ | grep -B4 -A3 -e " \[[0-9][0-9]:[1-9][0-9]:[0-9][0-9]\] .*configure$" \ | more [01:22:04] [11] [00:00:06] Status www/rt50 | rt50-5.0.7: = patch-depends [01:22:04] [11] [00:00:06] Status www/rt50 | rt50-5.0.7: patch [01:22:05] [11] [00:00:07] Status www/rt50 | rt50-5.0.7: = build-depends [01:35:46] [11] [00:13:48] Status www/rt50 | rt50-5.0.7: lib-depends [01:35:46] [11] [00:13:48] Status www/rt50 | rt50-5.0.7: configure [01:35:47] [11] [00:13:49] Status www/rt50 | rt50-5.0.7: build [01:35:47] [11] [00:13:49] Status www/rt50 | rt50-5.0.7: run-depends [01:35:48] [11] [00:13:50] Status www/rt50 | rt50-5.0.7: stage (I'll note that one thing that does seem to be more time consuming on the M4 MAX for FreeBSD under Parallels on macOS is FreeBSD's storage media I/O.) For reference: # pkg rquery -U -r FreeBSD "%#d : %n-%v %o" www/rt50 100 : rt50-5.0.7 www/rt50 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 11 09:29:22 2025 X-Original-To: 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 4ZYrx04mS0z5svVH for ; Fri, 11 Apr 2025 09:29:24 +0000 (UTC) (envelope-from avg@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZYrx03hGXz3Vc4; Fri, 11 Apr 2025 09:29:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744363764; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=iASWEPaEtM4rueE+7WAGUaQrAjtfaJa1P8CS1H4wdrE=; b=jGd7vyzLqKQpJ6vAc5n+rlQrmcIq+RXKnJZNNfrW4HhKaofaWhYWEuvE+Qzx52YrqjBUBF 9XbQzmJvfo2L//QGUOT6kIGqNdWujjf0pKDRIpWyuA5z/V9rPGipicekwikz/YI1pwzyTF oVdApkHGqmviVfH2HkANPyJFCu8TCPO7XOORHfukL+auWVIJT/HkPVVPTDFcOFgTh8LIDX KXEQFziit32fcR7qxqsIczMFWrpDtHPAnbpUkhhCyxnEdvyydY2XLjB2LudFYtPiERV8WW CgqzVEwE3Rh+Bj233obzoCSXrr9y8s2Qpl2UAUSJjPeUWwga2Ej2Q5yA6KxqsA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744363764; a=rsa-sha256; cv=none; b=a1PgMzEEJ9IYF1OA3BxZPNmmGsePql41HIu22b3AOx+E0Yx8DNljBnfAyXLf+IUx1/gT+D b6P5QEW6JN+F/dO26BJ6TDw1TcsRZaQ5bEQC+whcRJXs4JoAQcPk4uErgYIBpu7wcDpUxq wlGMGiIEo3aUOCxkAjmpFcqoxJGBPq7LgYhBNA5Z6ZnkatI53Jd34eZmE6XzSWd7mMtT84 cUx/268NzBixaflyB+LXWEyyXhefHWy4IsEh67sEDnd+Qxm+DozuPD0FKlGusuf0GgiiiM X2rmCDdMHbL+BOdwyoYTKmZheLp7ohKBxtug1Rd65NqIvagx/gexujw+TgoQLQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744363764; 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: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=iASWEPaEtM4rueE+7WAGUaQrAjtfaJa1P8CS1H4wdrE=; b=NJY9OT0pmdX1PdFsJeTZ6Ru07BusVaBxhIjPRdZsuBGJwXbpYGPpE9Nm+d1RQK2yX9u11y KkL6vZq0G45O6nmYlFkjCs5vpNuEYphKfy+zt9ItPuCoXyrSrvV4w4wmuZZmUCJtVcAHmt MAHW2jgp8MPZF1m4YfQ7cAj9jUbPfXBX64NOxz/7rT+OO8ZXaqad11eVUHEYeoQ6Age9Xc Ydab5TZonigjstZyGPIpCtfjESgvw8qw5gFzaUZe1anmiDfiI/rB5cJDxvHmQCeqM0RHmS sn+4NH20bXWlFOrzZa93PvfjqEJoSSf2fnfitoIXZAKKma+sPN3RnzhDXPXCJA== Received: from [192.168.0.88] (unknown [93.188.39.137]) (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) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZYrx00KQlz9Wb; Fri, 11 Apr 2025 09:29:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <058958c0-9024-4444-846c-7255cd367ea2@FreeBSD.org> Date: Fri, 11 Apr 2025 12:29:22 +0300 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 User-Agent: Mozilla Thunderbird Subject: WITHOUT_CLANG + WITH_CLANG_BOOTSTRAP seems to be broken Content-Language: en-US References: From: Andriy Gapon Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 To: FreeBSD Current Cc: Alex Richardson In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I think that WITHOUT_CLANG + WITH_CLANG_BOOTSTRAP (the latter is the default and doesn't need to be explicit) is supposed to work. I think that the combination should result in building clang as a cross-tool for the rest of the build, but not building clang for the target. However, it seems that the combination is broken at the moment in that the cross-tool clang is not getting built and the host clang gets used for the build. I have recently discovered this issue while trying to build releng/14.2 on a main (aka 15-CURRENT) host with WITHOUT_CLANG in src.conf. Host and target architectures are the same, amd64. 14.2 has clang 18 as a compiler, while main has clang 19. The same problem exists for WITHOUT_TOOLCHAIN as well. I think that this used to work. Or maybe I was just lucky and the compilers were either the same or sufficiently compatible that the host compiler could compile the branch code. I think that .if ${MK_CLANG} != "no" SUBDIR+= clang .endif in usr.bin/clang/Makefile is the reason why the cross-tool clang is not built when WITHOUT_CLANG is set. A bit more of info is in the forwarded message and the thread to which it belongs. What's curious is that those lines are there since commit 8e1c989abbd1db4 "Don't build and install {llvm,clang,lldb}-tblgen for the target", but I only noticed the problem a few days ago. And apparenlty nobody else has seen it. I'd imagine that the reported configuration is not too exotic. So, not sure what and when get broken. It could also be something with my build environment... -------- Forwarded Message -------- Subject: Re: c++ error when trying to build releng/14.2 on 'main' host Date: Thu, 10 Apr 2025 09:05:47 +0300 From: Andriy Gapon To: Dimitry Andric CC: toolchain@freebsd.org On 09/04/2025 8:28 pm, Andriy Gapon wrote: > What's interesting is that I saw this during the build (make with -s option): > -------------------------------------------------------------- > >>> stage 3: cross tools > -------------------------------------------------------------- > ===> lib/clang (obj,all,install) > ===> lib/clang/libllvm (all) > ===> lib/clang/libllvm (install) > ===> usr.bin/clang (obj,all,install) > ===> usr.bin/clang/lld (obj,all,install) When I compared this to other builds, I noticed a missing bit: ===> usr.bin/clang/clang (all) ===> usr.bin/clang/clang (install) usr.bin/clang/Makefile has this near the top: .if ${MK_CLANG} != "no" SUBDIR+= clang .endif If I read this right, it means that the actual clang is not built/installed if WITHOUT_CLANG is configured. Even in the cross-tools stage! I am not sure how it worked before as I do not see any recent changes in that direct area. Not sure when and what went wrong. Maybe it's something in one of .mk include files, maybe something in my environment. As hack I tried this change and it seems to have helped: --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -787,6 +787,7 @@ # TOOLS_PREFIX set in BMAKE XMAKE= ${BMAKE} \ TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \ + MK_CLANG=${MK_CLANG_BOOTSTRAP} \ MK_LLDB=no \ MK_LLVM_BINUTILS=no \ MK_TESTS=no I hope that more knowledgeable people can see what the problem could be, wherever it is. > ===> lib/libelftc (obj,all,install) > ===> lib/libpe (obj,all,install) > ===> usr.bin/elfctl (obj,all,install) > ===> usr.bin/elfdump (obj,all,install) > ===> usr.bin/objcopy (obj,all,install) > ===> usr.bin/nm (obj,all,install) > ===> usr.bin/size (obj,all,install) > ===> usr.bin/strings (obj,all,install) > ===> usr.bin/addr2line (obj,all,install) > ===> cddl/lib/libctf (obj,all,install) > ===> cddl/lib/libspl (obj,all,install) > ===> cddl/usr.bin/ctfconvert (obj,all,install) > ===> cddl/usr.bin/ctfmerge (obj,all,install) > ===> stand/usb/tools (obj,all,install) -- Andriy Gapon From nobody Fri Apr 11 18:39:37 2025 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 4ZZ58G5XSjz5sTGM for ; Fri, 11 Apr 2025 18:39:58 +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 4ZZ58G3lLKz3YS8 for ; Fri, 11 Apr 2025 18:39:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gdp9HXg4; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744396792; bh=ghPbfjr8Nv8jezOs9j1TwAoz8BuA0o2ounDO7N7jy/4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gdp9HXg4qF/6RZrx6KNSZoGiJ43rnrU/ikdOrmwulp1v5FroCgEvHeY7gKtZorch1fo858TzNQGr1Lh02x3A+5O07GwSptZDTa2zJ+vN2slsGsutPgVe3kY2tuYhlSeOISTriXUl9PveIvTbankhs87Qd6+33WVfIgN3TTr+/XlCNvWA//CAK1RKucmMzp2hYKbMPnvEwn0MwLpnWJ2WJHCIbfdvoMjcrkgELLQH4WmDzB7N+WXksdEiE7la6t0gM7Z6hrBdtbB3M1PMF4AwOXhlbFuvckm8BZDFDFiW1lVKV77ahAd3V8oIhfv7PH/5NeqUwf6+8UtGjmZpdQWDTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744396792; bh=gjyW+zJTMoZwl0wYF4H4lF0oDN15Ws/0JlJGcSvlddC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=c7y6sBGoW4KvKtb1yiglxVbwLx0iMLFGXpYYlxMiDOs2MW6eUnxmHXnIpynvb/uKk15QPpL2BXBOo8YUqZLBk7smBjJQFq+YpGQM8PWsTmcQLu27KC9F/kQJO/HhfP9e+WwiHNvgtgVYJ2pJn3dKxwZA0do2WGVc+F3WG/STQrCDV4Biyj/77CTqUFCX2KPKw1B65dFx64zcNlR12hMTmciYuuAvyEqo9ubHHaIoZ8zkhy9hHKXtVbqTqNI35A02Gs95pqZpl6cMifmwEK9odbMaFxBvGlnyY+tPwnUOJY68h4On8nXyKYdJmqc22G6GetLkKdXPskKd/xZQfHBW8Q== X-YMail-OSG: TPNwFtAVM1mqnz2yqQ2QLCbd0J1xYYWIhBeVc5_oK8I8nBeE6BFJwDpoofvYy_p wqbc8ZAId1Qo4bOHLByPGNqG1uLD0xvxV1KbYkeoMpqt5SeAjg.lUEChiNP9TeIx0EJMX6.6J8rv EA4JzdKyICEo1Aa3YDeLHRMrhG6tk5Ombn8c1U_PDKyuDY2sThqpuA.R5QdBilOFEVNxuTySeHTH loWyFGvnDkjOqBrqpDy_OfCd5FnnP5zAH8LCQ1p1uQ0Azxbj4s2w2YHWWT2PGrk1kJ3LE4brKlXd J5.CdV.MjP3Oxor_sOgflCqUqLmLQOn9KNLDMXJ6FiRHLwuYpfSb63LOfZk.uHga9N1oeMyQeXIG BaU4STt54j6b.vebUrtRdicslQWFTwJl2EIkqhJCiPyQvAY3uWiq_0YUX9ML9203DD_l88Eoq6xX Ri.odTEeevJhq6VB3jjGE6BH_0EHC2gDdVjglDyNlSZnstJrieJK921wSWSjActJJdeuwmLh459M t9pUPr8FGKwM2Ym8Va02bLoWlHa7WFon0ZN8clv.QcFxEjRLx1IRcRRoWYS9WV1VKJ1b6foQXaKw n1O2_5pnkyBuwk1EhKwd5sf1Mk.h6JPdEYt1n.DF11UumIpcyc.Cql77X.xdPEKj9T_BpQUDJc5W chygdpV3pwzPQlgAY.cxF4BboA_8eUbMAPCctR9W6UtdEtQFUJ9xjYLVvco9F.12_V_4Vl9uBIIy J_SkM_YOcN.dtVY7iEK8D3clD0gL5l8V6QUzeS1EXl918I1slZUG8MrmNYhuZDY02QzrA.fOoqNB 5xhpG.kJiQV7iYlv2zboUQ4eDMBzF8p3CPiZ.8q4D0sDBeHqBF7GkRLnTjd1cFnfkR9eM2UsAhfr YXkLRkpvBF1j.5FglxAfuh5HQjIgprkuTfO42Vwglczp6ZQcAlmkkivjhOxLfN0124ZIZt_vTKFp DbE.mnoQwfhywYytoZTAk0PfoU5rPYMlldmMX0CS.Hsxp4n9Lyvq_Ce2E4QIDiQpfj_gyzrEfkpB LE7tdnWjuEcNmzIqdrtTygjONJT0zMNyQVF.wcyuXIr04qf6BuLE9Xpn0BFt1jF9DMMbikiKOlr9 7uJdaS0p30nF9ubA5BlRIT5eJw4c..aFa8GV86wv__apbZNc1SZrEHam9u7MhOI4hlWjIkQcW3ba _BkLFRYQZCFV3KTqHa46OVXlCeXFAYLwTJEesIFSEgpxWl.Zz_UhZFSkzAktqyHPVerH.8yGSVzT q5AsKHAb9mYtxWz5p6s.v3FOboIY_qprNM93AumxoZFIPq8AjiUVGsznLzclYm0gsu4a9J4OF8f3 vE3U5rRmcYbq52mh7r7foYVAoMae5rP9daUPiUnF2sE5c8vM39NTTxNguvSQ_2qDdluKiXj_c.C. kytpMuwMnDxdqwJTxHNXJx9CM1fQYbW30I.t_uE7OMyZXKdvSAB_lqb0GtT_h3CY2r.RDRuq0Ago Y5kkUtOreHtp212Zfu5yLvnQqMsmSKD5PVsuLr7l2nJRecBIu1vqDVmpE3LLrzXkzYXwWrvClvon F..Xq7.nyWOueOM.K_UTuukbhfsETi0JvmpLz1MJ1WTfyCdW3dlsdiJYSxwXopYBobh1LY6rNFMb LvLs64KGqDFm7yWgEhsXjMO6LV_ViWxrJN2j8dBgJaCgvN3Rk4j70Z7HgIqh_IhlF4GEJjdRnCYb HsRBY31DeeVWju_RE.SRkl7Kf8impfrbkaeyrs_3w.rxZsEPlbqQiQawCnZid2zaL54HwcQpx8N0 x8PJZAc3Oc5VaFpLFi2TKnT5Z9ZORHt.RLbgXZgPzQCl5V8P5xFDGS.kptM9BAis_6bxyE5FvxZ5 rZTFhRoVxncP6cINEDKLVGp.y_QKPLPVnxknILUhq81zXaqECsedGvdOqWyHB76i7QnkvOEatxN6 P0gVVAjE9qWkMlctaeI3yvmWFk32uLzBonBTgEAV.aL1w3ffdlSvy.2ERCnRnvILvUNOhSNfZ9X6 wOgGWHyFpwjpSxYbbjp2JsHHft.RbdIsEm0GUXRYlBJ5KQVyzRFmVKo2IINxCyZNfjjLk6TXHNGt 1jnitHQyYr4YOvTeDYPoLc5xL3WDUlJ0HYgwDbbyOcIUZ3COr1BZABNz7hJcSF5CIRbotziPoJuk oCZhVZvEeq1mIux20DdYtmWwsJ8iv_vG_boF4AHJ9z8VzEKX6nxv4uHsNc_Nh_G7tz59gq4Qz7UW FjLmdphApP4cwlk1IXx0CKx3EZ21t1BF2tm5isi4h8Z9A7aF_tEmFy9sWdSrkkllTRuveXGWCYMO Ayf1p X-Sonic-MF: X-Sonic-ID: 73b568cb-f11d-467c-a998-70413635e9e1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Apr 2025 18:39:52 +0000 Received: by hermes--production-gq1-74d64bb7d7-x6m69 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e95cbde4a1c1567c2f13ee599d18f96a; Fri, 11 Apr 2025 18:39:48 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes] From: Mark Millard In-Reply-To: <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> Date: Fri, 11 Apr 2025 11:39:37 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.50 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.148:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from] X-Rspamd-Queue-Id: 4ZZ58G3lLKz3YS8 X-Spamd-Bar: ---- On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote: > . . . > the problem we have is the > performance changes depending on what is happening in parallel on the = machines. In separate list messages I've provided multiple examples of the time-taking issue that do not depend on what is running in parallel on the machines, no parallel builds involved. Part of the issue is that there are thousands of examples of "small build-step time" packages for which the build-depends, lib-depends, run-depends combination, takes notable time, given that the total time contribution across those thousands of package builds is notable overall. As stands, mostly it is the early part of "bulk -c -a" avoids the issue via building packages that have no or few dependencies. Later "small build-step time" packages tend to have various dependencies, greatly changing the time scale for their builds. Few builds are of "large build-step time" packages (relative to there being 30000+ packages). That=20 has implications for there being 30000+ packages to build for "bulk -c -a" or other builds with large numbers of packages to try to build. > which makes the performance issues invisible on local poudriere if you = want to > test it on port A or port B, I've provided counter examples to that that only involve the one builder, after the prerequisites have already been built (same or prior bulk run). > if we want to reduce the performance penalty we > need to be able to make a reproducible case which can then be = profiled, to know > where to optimize if needed. I've provided examples of such . . . (time intervals shown are from the aarch64 Windows Dev Kit 2023 with just the one builder active) www/rt50 build-depends: 00:00:27->00:08:46 devel/py-inline-snapshot@py311=20 build-depends: 00:00:01->00:00:55 run-depends: 00:00:56->00:01:47 mail/mailest@nox build-depends: 00:00:01->00:00:28 run-depends: 00:00:30->00:00:59 devel/dwarves build-depends: 00:00:05->00:02:23 lib-depends: 00:02:23->00:02:42 The timings are from the column next to the Building/Status/Finished column from using bulk -v , not from the column for the overall bulk run. > I have tried to reproduce each individual case which happen in the = ports tree > and I am not able to reproduce them, so impossible to know where to = look at > exactly. Try some of the examples that I've provided? There are more examples that I could check and report non-parallel timings on if you want. I just picked to report on only a few initially. An example that you might want is my providing more examples of lib-depends with non-parallel timings. > I know what is new and what causes the performance penalty, but not > which part is causing the super extra penalty on the cluster. Various examples reproduce the timing issues outside the cluster and without the parallel builds. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 11 21:04:49 2025 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 4ZZ8Mh2jJ4z5sgPV for ; Fri, 11 Apr 2025 21:05:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4ZZ8Mg13vrz3r7h for ; Fri, 11 Apr 2025 21:05:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I0U9lGo0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744405496; bh=zX9t+ewjCbo04maeOYBXBh7KlF1tXeGWDK3XaE3XVTM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=I0U9lGo0rmUyW4X5aWcSRMXs9SbZdFM35XyIqAzyGUF0gSgRcS68Yf+dcXfQhupcPnytE/TuTzmMXo9TRsIrVAaNqalC0XiFvBtnuSh8KYx9psEwqMmFqPN/+w2LkQFFHHRBcNJKkHNRtVUprFvIBnIH4O1j7AWZ6CtCJvrYeu57Si3jud2Oq3cQEmwNblhOS264B4stExY9XxG1p3WAXlH8pgPjzVbei65JdXIVo5t/yNwgg6B6NdYlOLDmO+2gy+eGTAp/q9HimYVgH/huOuZLzvNHSwpAlaSr1xWtM1Q44xZFzNnhSE76C0ur6nFsSd9lIodeVDVKJFdbeHc+hQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744405496; bh=vYCb+h+VJNAVzM6Sf4EzZ3vaX+IhHQi92i7uB2xiOJx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hu9GisHot6qYULl6rOXvy87HVWMp/sWfA46YLs5xTg+i0L6o63vq5MwAXKq8cT3dWT1701mxHeoFAOAixdLb2mchZOoOw5tjXwuMMvGIn89kJsn8Qf2soV6fbQzhzvy3yOH35q4EKh7DuTiPacM2uLTqcord1/F+4N0A1Dz/iwxjgiLMTvGlCTaDoGsdrcyA4dB8aaCuN1Jxaib96VP1EnNEfVYNSSM0sJ+haaChS10jTdLBoh16jjVSHEaWxKpy01PYguanVn/ucYphT4wtZ7Naw728L9qzrAHLmmJG1Z9iuiOrQiAN9JSgAN6tD0F8Uy0Ut1rWj9bhrnrEOazQWA== X-YMail-OSG: TK.OvNMVM1nsac_Vdp2ILaVMe6Y5tPpNdi4yB7U4gcBbnJSH53FL6X6HPFf3Bt1 b96LQWE9Vf1U70r0EmFpi6yopxGzYdVvOduhSHR7Mp_4uCm7s3FbO0pdb8SoPYhEFazDMwMzZm9G tCtqymn9MEAzS5fwAmjH5QcMymI7rLyIRI3egZYmco.wwRvsbFPtVjNCSURw6yBlTrTEWNHl5rMx 2mWF.sgmYt5XWAqJ78N2Opm1dJOfSWLTMKEaxa6EOnDo8nn4IL40yug.VIlTLoWXnNsyYyfDaYge 1wlhXaNcexwa7zac2M0L42KCaJicvhYMvUSSi3UIS4lXstChEpAm0VCSmcv3.1otIc3qsVA4rljc SJ5II6ncM6Vg3ft6HzVJt1o_1ojAQwpqG665ofkIaMuhGa5Z3sO.V41rBjheuFThES.6eXnFhL9l bWQN6OJ_978_MP.aZzf2mLgcmf3bqFrSM5VsLUy48g9Mtzn4ERicmmM0gUgPVpnGfxyl5dcaU.tj 2oW_kuh1af2YPt.DQMSufzxu4cNd.ivYkltYWKPXU40CgJrRNiLSLUIPe1bvVlvwHo2IXSnH_a18 3.gGv4_3CuUi2ql.kGWtbYd7rBIcGVTOzqrHbK_YqY_gL0Uvjr6tJREHwjgEsMrzdl.TVhTjH10v WkgVRgYbvPEluevKoZdG9Qq0vWAtn2TtNbvObGwvG6789NtRuZTXdzIcyGxP7UzEkGYKH9GB2YLC N6hG7m5ZvN4yy1RSkfMqv0ADair6lqfWpBBGNw.RF7aaRMPxKDfuAJ_lN7Ou_.o3NMBNeXmnm5Ur sCSSJFKlFSq7FWuXExk.epMHfHlhUdJE8xFGMvgikr10KXKWGaZIk.wdcSP2cEKZX7foVWRRFonr pa3WWJnahuHFj2LOD_4lXSkJnTiZVSw9ISxxPu0ARP9PJO2Jtk00uYU53DkuFKesP0wuHhuj7V9e zrR0_gk1VwdFJrxWhQcddJjarwC0v4FrB.MJ0Tj4bdHfxIf.eH1uV37Yl0C1MLo10G8XgHn5BBJ7 7_5NfVLMX3S5OvcFl3Ie1kSMXEA76qmVO2xspXRlGT0VR3EhZIhDYnA.P3NOQ0TE19rGl4ZNwyx_ Ay.k6u5WD_aIYL9EeVHfrH7.Z_sJJ907dt7AtMTURaH1aIC17oSjqyMsAb6LHLrxLMv7MUNJDwmc p1eFnrrsGgprV70Omtljal0uw3A1uA9ey2SVrMDSkJpsnogS9ZodM.KqMpJp6hW_mgvwag6BjTu6 jPYFBOsgcreoG.lN2XJlwAFjSjpAaXISE7LbtXKa1LAAitP10ViRv5DKnp8A1pjF9xrtvfVjiIrc CNEGSp7CQJdphAyrJOaj9cOHwOy0WKLuNE_LeVEngIAF.bYyfCn2QjO_AVIbexOhVBGfckuvBNLj 2c5sCZMEcx.61lYldmK35xt0nbl0IlPc7WfhQK_vKddOAOuMkIH63f6lBkC2j2QJwh57T7WJYkZz Biq7WKCG2JaLVSfz0ZuS9ruU8ISfuZCfgeSH6qFHxSXtLc6bbhu0_B8IkXzI_SIYcBSAQ36NgsIN v23xOibh_RiTg5STCN172XTeSZ5_7Jp3diYKcf3fpYU8rIBlwnavyc6R28jgCoKHzQTVqKoKeKDx yp.BlG9k1egtt1FELuVNcmC9VwiASCLG05Yr4NDc_2KlavmD2WU5YOAu5hky4QANF8V2aMjT7qT8 l2b58l3ltoknYffBH4G8vvQpKvzec.YJoPMOZPhmZr5pQpbOOmP_8ShXVNlbr5Yxg9YnPqWOF1Az DI2RojksALWdm9PPGkdnubskddCAJGXkXOAVpXtD6JkVIMUmkmKXt6VLP2tBdOga6gSejR.KC0yx 1Q92okiCDP_AYxDa7VP7Ag5E0zLqwGiSucSTPH0MHR5TJGhZ5uTkUznzBFzOQvJXCUmdcL1akD7P inDC3Xju2Fp.Fl.CepOT0lR7J0iDey.KPEWmk1nvYw2zhNtZO2RrzJgqyik.75TUl.mYQeQPuMdg 0liKrzvcU6fvl4u14dQi8SMXRIDkWuFTQso7f4mForb44llwXZ0_PXabYsFjpkclUQ89nqsZQfKh NPkw3H7Kf67uMtye8toM4c8XTEn7daG1y92ZdYCDVjwL4Iq7fJHylSSeS5BsrjQAId6JzdUq0HI5 gkyNwoN_T4a4RDSNeVM6ReQuFVaQwy72YJ.WSymNFhdz00BssshN4Qzrp_XaxFztBDs7IF3rVhxB JXMTYxRhLFo67eme3XSJK7XPcPed4jqXC1iqu1x8Kyv6T2lnrUv4cRO37vnqgcrQiaGlRFvy4dIX 7St8- X-Sonic-MF: X-Sonic-ID: 3fce1e46-c52c-4f99-ba2a-535d5e50e195 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Apr 2025 21:04:56 +0000 Received: by hermes--production-gq1-74d64bb7d7-mh87r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f7da9cf3db31fc16995632eb8a7c9048; Fri, 11 Apr 2025 21:04:52 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes] From: Mark Millard In-Reply-To: Date: Fri, 11 Apr 2025 14:04:49 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <8B070D1D-0524-4DA4-A5C2-EF2CF98C5E15@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.50 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.66.147:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4ZZ8Mg13vrz3r7h X-Spamd-Bar: ---- On Apr 11, 2025, at 11:39, Mark Millard wrote: > On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote: >=20 >> . . . >> the problem we have is the >> performance changes depending on what is happening in parallel on the = machines. >=20 > In separate list messages I've provided multiple examples > of the time-taking issue that do not depend on what is > running in parallel on the machines, no parallel builds > involved. >=20 > Part of the issue is that there are thousands of examples of > "small build-step time" packages for which the build-depends, > lib-depends, run-depends combination, takes notable time, > given that the total time contribution across those thousands > of package builds is notable overall. >=20 > As stands, mostly it is the early part of "bulk -c -a" avoids > the issue via building packages that have no or few > dependencies. Later "small build-step time" packages tend to > have various dependencies, greatly changing the time scale > for their builds. Few builds are of "large build-step > time" packages (relative to there being 30000+ packages). That=20 > has implications for there being 30000+ packages to build for > "bulk -c -a" or other builds with large numbers of packages > to try to build. >=20 >> which makes the performance issues invisible on local poudriere if = you want to >> test it on port A or port B, >=20 > I've provided counter examples to that that only involve the > one builder, after the prerequisites have already been built > (same or prior bulk run). >=20 >> if we want to reduce the performance penalty we >> need to be able to make a reproducible case which can then be = profiled, to know >> where to optimize if needed. >=20 > I've provided examples of such . . . > (time intervals shown are from the aarch64 > Windows Dev Kit 2023 with just the one > builder active) >=20 > www/rt50 > build-depends: 00:00:27->00:08:46 >=20 > devel/py-inline-snapshot@py311=20 > build-depends: 00:00:01->00:00:55 > run-depends: 00:00:56->00:01:47 >=20 > mail/mailest@nox > build-depends: 00:00:01->00:00:28 > run-depends: 00:00:30->00:00:59 >=20 > devel/dwarves > build-depends: 00:00:05->00:02:23 > lib-depends: 00:02:23->00:02:42 net-mgmt/fastnetmon build-depends: 00:00:03->00:00:42 lib-depends: 00:00:42->00:01:29 (See later below.) > The timings are from the column next to > the Building/Status/Finished column from > using bulk -v , not from the column for > the overall bulk run. >=20 >> I have tried to reproduce each individual case which happen in the = ports tree >> and I am not able to reproduce them, so impossible to know where to = look at >> exactly. >=20 > Try some of the examples that I've provided? >=20 > There are more examples that I could check > and report non-parallel timings on if you > want. I just picked to report on only a few > initially. >=20 > An example that you might want is my > providing more examples of lib-depends > with non-parallel timings. I took a quick look and quickly ran into: (aarch64 Windows Dev Kit 2023 no-parallel-builders timing again, after having built the prerequisites that had not previously been built) [00:11:37] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends [00:12:19] [01] [00:00:42] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends [00:13:06] [01] [00:01:29] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure [00:13:09] [01] [00:01:32] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package [00:14:22] [01] [00:02:45] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success (I still have thousands of packages that have not built in the bulk -v -a build activity. The M4 MAX is in use for that.) >> I know what is new and what causes the performance penalty, but not >> which part is causing the super extra penalty on the cluster. >=20 > Various examples reproduce the timing issues > outside the cluster and without the parallel > builds. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 12 02:28:27 2025 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 4ZZHYF408Lz5sdYh for ; Sat, 12 Apr 2025 02:28:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 4ZZHYF0znxz3RSY for ; Sat, 12 Apr 2025 02:28:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=J0QKrUyL; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744424923; bh=ymBnqBNV6BhyZvY5o9a9at8eVxIs216WXCehmIFyhxc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J0QKrUyLhb/JuCXj9EMfqElTutZx2Pgnb/kP5/tXJaNIQpTYKKo2Hmron3PdkGsg6odYE6zCYQrRXQ6XljM4CXWt0A9a5qTlugSO8xuhwr3MbdH1ox3ExSOKHlNRzGTgJjXqhAsLDxyb4dlGhv11jZheGJRp8kBE3iybq6/f3+oybnUzF2QyLDagqdqUFRCM3aDkQSoTItmVZDRsCB6squTxML2COgdW8JSi/PhdLBsRpxBl/lVeeNHi32t0y2fV3tcW6K5NkCk/QZIVOq0brcknfCxZATDuYVKc0hyVYN2z7FLyK6uouvU6EtMSzE4+v3tynKGG/IEPnfZq0AxnWQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744424923; bh=sqiifUUhH7EXFmMLWg1SGhWOJ9OXBaLvOLVS0cyXdyf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e+KjsTyjBOTDz4jIna2jUUQXVo84uYDLL/YywW1bUvHisBf5kf2L8Q5bvlnFkbWNg5iekmYUd7cAFOv5E2imCBaQ9WJO7iB52tuB1bSHN9wiAiGfD974ZJ/X35GJAIWA4Wa3lhvUySDbHkmoymWVTM9LMKcI+rp+vPXHrMImu3fU+hovxw7aqM5XI6p6R9Pmk76lXFT/xMUJ08KMHghjwC/b4kvKbAIPcXg+2C1IbBQU1KcVnVLI2PwYeAxDpeGLBdQCQLUmadWdFCTdQCGjFGWaQVdIOxZDR/LKSKYEK1wysqSuWXj/OXgUPb2/XYHZujIrg8IsPJcbqljhRgr2Kw== X-YMail-OSG: YcYqB0YVM1krZglddhb4fTTruvu0eAjw.7ptB3v9LF7Yj1YlknoN1qU3Ak9c1EZ 48DaYAD5NF3FPoJhJBVNoee7I5ObBa6w6JIwpazfIx4MFL_tS7IRpedvuQN0dBKEQYhmNYhWbhqu 9qhqX.6XkAPOcCq43r1Uf1mJWH_HlZl7UVe3lBsMVvYeRWB6rfUdQDE4o1EviEJEH8MldwxaDn6. AujabEs32Kha12F5NmwQ5hA1cSew.ONGSWgvLVdtlKOWFN2EBFwG16ipSBx7RyWqv8UN7dk7UosO kk6L_4SIb9s3Azc5IsWBqeumOphuWjh_xrfVApjh9WftfctZBl_6mykiv.1y7yE8izfDswUB5P_u q7s3qWXANpmYQJ5SYOA8na1QdIIXIj_ueDcrFsqbJV.533YVy1sBIl6HrvJ4YpCaBkiOPEbJIJh9 0oHXmISqxHOHklcFi24Mt4gIT879l6no6TVu0FQoI1yEmXzBdTok..FD7cLi1TnGUz482_O0tM0d EzV6tCdP6NtZCgHGnyMTtaGbyXL9GuSC1N.MxVzrg.xinc6IXHwRWRAK.PX96DU35_Y9xOfmSitD A.03HXK7XdafE_yV8nQFg56giQ6yZzIyY3bBqBRGVz4rnqstKnd39wHCDySJ4gY6KHShDC03JyN4 Z.JPTwB3BueNiNFcH05K5MMffWLls2S71mT8BFIXqszVhoJgT6KJOioEpoyjAz_Vhwf7Ree_KwuZ rq7xGxVI5B2pW2IoIS1oAPPgt3JOxJFqDcboCYOg7v8_2ZryvPLT33K4OamG7KIDfURyN1mILYD_ xANxesiiJcSjXr8_qkxQMVYonkfsXFfCvgOqEzzUN3eVXjJj832aViQ9w48yB1.kzgR9r3FDEM2A 3_0KPK0SSrE4coMkSpC4qB29M_ZxdIH3Zd5xsCGRQUNrKAHUYwnJQbaSBLmuiw095sqwWXxUwvjl usNWRgDXbVDJe72_yyLEyEtz26tWJU0WI715Cpkt_OIGxPJ0.kB5JPySnWx.DDNpCFMF6hYHeFSh KXyiqcLD9hw1xLiG.AG02tbHzMu9TQFEcGzbzpgBRc3SfZAKS5Y6HcE23iyw7XO2QUXZvLwVRkYk hekCaR09I2KTpFczUc2iNqwBagT80CZvncfubW1w4sRPn22k7TYDV6S.4cu_BHBeio6MrF0BAHni zeyQbZfXsYeL1K91GVh4WW6CuDrHU2gyL28SZb.4JJTHefF4Uyt8twTEZyoZvQ2..2ihK8ENDgFg PZKlNO9fqh6BoeKKzqvV5XJY778uC61cZC1o4Qd8b3NNc_U2cWS_Q8Q3SeJFYr9.yF8aFu353tS8 0eSDP373UQxm.TNwvS.pZdrK4DxKmE5D5oH4QaMRcxmOSJqMo0nOw_WJ_SyA112.4RvrUX5_W6ek pDBXTsIDtxSkGyAp6PkZSIlRSKZJa3Ne2IFWmwJwimgXUNnyKCzrmrtyIaVNld8GtqgdygNTJa5l P72d9XymG0JbsS4_ofahK8C_R1yEerbxFDURTDGsHy.YsqdlUm5CPX6OJ.GjKyNfPHAgZLeUuDVb ikxU2jc5TmPx0gOvu3erFsO.QBOfClYI1DXhID7x9_UT4cXZeRRFqwz8r4oqyDf26.aJlPQKUt0j RWzM89Sh9aJLjIJspCe1MXCft2gb.MmViLGppr1mNsMm_2vQO.qJ83SnJzIv5YmlE4zlZbFcZSsZ bK.w2MYaSRMV6Ou4VtWiYf6RTG5idmZu7vSdCukICegt.sUo3caAD8ILd8BMJpEq3sMQnuUv9JpC WZD3fZdolGwh8E.kP.DLe8WbnSYQHRV28rRD3XhPO1hhfv.Hqah_hC78tB1gPbRPBikPbBMP4i5. NUkoojRWBv2siTvpIYgRJffvLkh0TDieWx9pCVa6gm3c8Qk.Ia89SHUfg5ncXm1e6JqunR2fcCMo jB1iWGh8dGOY__6Bd.xzRNNmmTYcCaFVtNIWWAz9CJmuiqNgvxPE3O9TTa3.16gt9d7E3GLmexU4 rCJRilQayqcZZqD.xSfP9lgIJ5d8j55CC6uggjcsAWUKom7ZsINxBaQgSZT9yO1BHkxaEQPJJhKZ Nd56rgH_5zRV.Q4JbKLfdrcErKhjpy8Y8ifECaW4YLdkWt8RnMuGFuIo93YrgLJesrIk.1Z6XVud oTDb1Woui9cEU5l3EPPZxU4xdPzwkHKDQbze_PL3FDFVG30.sxjWJYXyhXCsZIu.uBBmpBkYI9Vs hs3u82quh.9GYgdOke1Yq3.SXpqKnD5T44NQVvWODyTpl_86ok3o3.p5EE3oYPH0lH0KcYYahdUe BVxu_Kg-- X-Sonic-MF: X-Sonic-ID: b8eca28f-417c-45e1-9352-a637ce3f3862 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 12 Apr 2025 02:28:43 +0000 Received: by hermes--production-gq1-74d64bb7d7-sfjhn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b71a1fe54aff611bc1d22bd28938baf1; Sat, 12 Apr 2025 02:28:38 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes] From: Mark Millard In-Reply-To: <8B070D1D-0524-4DA4-A5C2-EF2CF98C5E15@yahoo.com> Date: Fri, 11 Apr 2025 19:28:27 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <7A1322FA-A118-4F87-9D96-DE8B05E09424@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <8B070D1D-0524-4DA4-A5C2-EF2CF98C5E15@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.07 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.84:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.92)[-0.921]; NEURAL_HAM_SHORT(-0.65)[-0.647]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZZHYF0znxz3RSY X-Spamd-Bar: ---- NOTE on something newly noticed while preparing this (a top post to keep it separate): In looking to provide more detailed timing comparisons with pkg 2.0.6 I noticed another context with a sizable delta timing difference for building the packages, here using www/rt50 as an example, just the one package being built in each case. # poudriere ports -l PORTSTREE METHOD TIMESTAMP PATH alt null 2025-04-06 14:15:11 /usr/ports-alt default null 2021-04-18 02:05:47 /usr/ports pkg 2.0.6 /usr/ports/ context/vintage (default): [00:01:51] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [00:01:58] Committing packages to repository: / = usr/local/poudriere/data/packages/release-aarch64-default/.real_1744418553= via .latest symlink So: an around 7 sec delta. pkg 2.1.0 /usr/ports-alt/ context/vintage (alt): [00:17:04] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [00:20:34] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-alt/.real_1744419891 = via .latest symlink So an around 210 sec delta. It is the same Windows Dev Kit 2023. It is the same boot media with 2 /usr/ports*/ trees. Prerequisites had been previously built for both. It is also the same jail: # poudriere jail -l JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 Just "-p default" vs. "-p alt" being different on the command line. "Creating pkg repository" would not involve *-depend activity? More of a general I/O problem? May be a far more time consuming compression technique or some such? Back to the originally intended content . . . On Apr 11, 2025, at 14:04, Mark Millard wrote: >=20 > On Apr 11, 2025, at 11:39, Mark Millard wrote: >=20 >> On Apr 7, 2025, at 08:14, Baptiste Daroussin = wrote: >>=20 >>> . . . >>> the problem we have is the >>> performance changes depending on what is happening in parallel on = the machines. >>=20 >> In separate list messages I've provided multiple examples >> of the time-taking issue that do not depend on what is >> running in parallel on the machines, no parallel builds >> involved. >>=20 >> Part of the issue is that there are thousands of examples of >> "small build-step time" packages for which the build-depends, >> lib-depends, run-depends combination, takes notable time, >> given that the total time contribution across those thousands >> of package builds is notable overall. >>=20 >> As stands, mostly it is the early part of "bulk -c -a" avoids >> the issue via building packages that have no or few >> dependencies. Later "small build-step time" packages tend to >> have various dependencies, greatly changing the time scale >> for their builds. Few builds are of "large build-step >> time" packages (relative to there being 30000+ packages). That=20 >> has implications for there being 30000+ packages to build for >> "bulk -c -a" or other builds with large numbers of packages >> to try to build. >>=20 >>> which makes the performance issues invisible on local poudriere if = you want to >>> test it on port A or port B, >>=20 >> I've provided counter examples to that that only involve the >> one builder, after the prerequisites have already been built >> (same or prior bulk run). >>=20 >>> if we want to reduce the performance penalty we >>> need to be able to make a reproducible case which can then be = profiled, to know >>> where to optimize if needed. >>=20 >> I've provided examples of such . . . >> (time intervals shown are from the aarch64 >> Windows Dev Kit 2023 with just the one >> builder active) >>=20 >> www/rt50 >> build-depends: 00:00:27->00:08:46 More detailed comparison/contrast of non-parallel builds: A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: [00:01:11] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = check-sanity [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: pkg-depends [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = fetch-depends [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: fetch [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: checksum [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = extract-depends [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: extract [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = patch-depends [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: patch [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = build-depends [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: lib-depends [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: configure [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: build [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: run-depends [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: stage [00:01:29] [01] [00:00:18] Status www/rt50 | rt50-5.0.7: package [00:01:50] [01] [00:00:39] Finished www/rt50 | rt50-5.0.7: Success A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: [00:03:04] [06] [00:00:00] Building www/rt50 | rt50-5.0.7 [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: = check-sanity [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: pkg-depends [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = fetch-depends [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: fetch [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: checksum [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = extract-depends [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: extract [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = patch-depends [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: patch [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: = build-depends [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: lib-depends [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: configure [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: build [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: run-depends [00:16:28] [06] [00:13:24] Status www/rt50 | rt50-5.0.7: stage [00:16:30] [06] [00:13:26] Status www/rt50 | rt50-5.0.7: package [00:17:03] [06] [00:13:59] Finished www/rt50 | rt50-5.0.7: Success (That I got the 00:13:22 is interesting, given the prior 00:08:46. May be the A78C cores were used instead of the X1C cores? May be that there were no builds, just Inspecting activity for the prerequisites. Did I not match the USE_TMPFS settings? I expect that the general structural conclusions are not invalidated.) >> devel/py-inline-snapshot@py311 >> build-depends: 00:00:01->00:00:55 >> run-depends: 00:00:56->00:01:47 A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: [00:00:54] [04] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1 [00:00:54] [04] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.18.1 [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: check-sanity [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: pkg-depends [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch-depends [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: checksum [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract-depends [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch-depends [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build-depends [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: lib-depends [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: configure [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build [00:01:02] [04] [00:00:08] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: run-depends [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: stage [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: package [00:01:04] [04] [00:00:10] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: Success A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: [00:02:46] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 [00:02:46] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch [00:02:48] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build [00:04:00] [02] [00:01:14] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends [00:05:27] [02] [00:02:41] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage [00:05:28] [02] [00:02:42] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package [00:05:28] [02] [00:02:42] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>=20 >> mail/mailest@nox >> build-depends: 00:00:01->00:00:28 >> run-depends: 00:00:30->00:00:59 A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: [00:00:58] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:01:03] [01] [00:00:05] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:01:08] [01] [00:00:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:01:09] [01] [00:00:11] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:01:09] [01] [00:00:11] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: [00:02:50] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:03:32] [01] [00:00:42] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:04:09] [01] [00:01:19] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>=20 >> devel/dwarves >> build-depends: 00:00:05->00:02:23 >> lib-depends: 00:02:23->00:02:42 A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: [00:00:56] [07] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = checksum [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = patch [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:01:07] [07] [00:00:11] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:01:08] [07] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = configure [00:01:08] [07] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = build [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = stage [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = package [00:01:14] [07] [00:00:18] Finished devel/dwarves | dwarves-1.19_3: = Success A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: [00:02:54] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:02:58] [05] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:02:58] [05] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = checksum [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:05:33] [05] [00:02:39] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:06:07] [05] [00:03:13] Status devel/dwarves | dwarves-1.19_3: = configure [00:06:07] [05] [00:03:13] Status devel/dwarves | dwarves-1.19_3: = build [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = stage [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = package [00:06:12] [05] [00:03:18] Finished devel/dwarves | dwarves-1.19_3: = Success (Again longer 2.1.0 times vs. previous 2.1.0 times.) > net-mgmt/fastnetmon > build-depends: 00:00:03->00:00:42 > lib-depends: 00:00:42->00:01:29 A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: [00:01:00] [02] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends [00:01:03] [02] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends [00:01:07] [02] [00:00:07] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure [00:01:10] [02] [00:00:10] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package [00:03:18] [02] [00:02:18] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: [00:02:54] [06] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends [00:04:10] [06] [00:01:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends [00:05:41] [06] [00:02:47] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure [00:05:44] [06] [00:02:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage [00:07:44] [06] [00:04:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package [00:07:46] [06] [00:04:52] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success (Again longer 2.1.0 times vs. previous 2.1.0 times.) > (See later below.) >=20 >> The timings are from the column next to >> the Building/Status/Finished column from >> using bulk -v , not from the column for >> the overall bulk run. >>=20 >>> I have tried to reproduce each individual case which happen in the = ports tree >>> and I am not able to reproduce them, so impossible to know where to = look at >>> exactly. >>=20 >> Try some of the examples that I've provided? >>=20 >> There are more examples that I could check >> and report non-parallel timings on if you >> want. I just picked to report on only a few >> initially. >>=20 >> An example that you might want is my >> providing more examples of lib-depends >> with non-parallel timings. >=20 > I took a quick look and quickly ran into: > (aarch64 Windows Dev Kit 2023 no-parallel-builders > timing again, after having built the prerequisites > that had not previously been built) >=20 > [00:11:37] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 > [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity > [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch > [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends > [00:12:19] [01] [00:00:42] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends > [00:13:06] [01] [00:01:29] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure > [00:13:09] [01] [00:01:32] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build > [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends > [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage > [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package > [00:14:22] [01] [00:02:45] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >=20 > (I still have thousands of packages that have not built > in the bulk -v -a build activity. The M4 MAX is in use > for that.) >=20 >>> I know what is new and what causes the performance penalty, but not >>> which part is causing the super extra penalty on the cluster. >>=20 >> Various examples reproduce the timing issues >> outside the cluster and without the parallel >> builds. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 12 06:55:41 2025 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 4ZZPTW37D3z5t0xm for ; Sat, 12 Apr 2025 06:55:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 4ZZPTS3rYPz3jv8 for ; Sat, 12 Apr 2025 06:55:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="q/9T8+dC"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744440954; bh=YJ9gmDmRnrQnU7rpi72Dfu9RKlGLeJOTFc5kYO6j754=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=q/9T8+dC0HXnw2qBfIdyPmKtS3Bk/as0v9ITWQg4X7NCpiCe4yeDHgnevtZVP2cPPjZSaLmk2/hxzteS0VuLCC4sEYDwOxHS3veNIId1B1N2xh/pKObxxaZn2DGKITqdM7Wwo0tRp73Q1AReXx6SsEUck80gX624TdrzuB7FO+620tgB5C9o+7bGIr6DRKqFoZKg8aAF5xnelNr3m6yH9eckaxzuXxpRkdaJCfeQ/CnWjenHn5Auy2fQMxM+uAIKyJEzKe35+qA900c8KPFPpaXUq02ZBwPS496LDkjaxh/qBw2yHnAAdP06g3PDGX4V5H2ivBJdWwAYNJHgKhTf7w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744440954; bh=R5VFsCU3onbZmBufLIqS0vKnOIA9BQ80MHaV4eXdlts=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lXqCElrFQ7rxuxtkRQeKaL08YPnvQN8WZfbioDWv1oMEG64DHA9DdyIM42jX2FT8fDurBr7eeo7XtWWkUenLFu8Qep6w51B9oLxuD4QR9sd82qrdKgPQO4upanw6qZQS2w22JPsYXMBFl4f4+W42rmGSeIg7oB2+ZjjMy9G/cxzHIDLuDXQXE4Fum2X/W1PGEesYT2ezvbx4giazhGQvJud5JVPDG66GuMLVRx2rZe7iLTXPBAAf5SkUi6yRRUjQsOoFjXbcn5oIWKjkW9mDiDkC9nq2s7af7fPP9QMiMSefWl8a6ayiW1n8CPncvi0f+OGPr3SPyrzIK4AmSvvUNQ== X-YMail-OSG: opiG_0QVM1mkE.QiEvZW8bQfmrY3VxoTqwsCERGVwfUWyiXmOWUXX5X1QzibP_s W_7xHh5Z1K04dzyEEgHBej_Bg8DJ6qvg7oSmvmQZ64qUQWPlYjBQwm2FEQZf_Z.jeMmpDUDXDvd3 LcHiNgryDpUi0YwUKSZr6a.CMgzREQIOMCYU1zvF110Mvkp08qOzzRzI3PARauw0W9rqDG12Oe_Y lCS63mae6B78TFAmS1MdVMz7BfCA3T66AOrynGVxbn8y9Im28QMLO.rhPaeJUlniLidDLqdrHlSL bW_y0KNsDT7IQ0ZZ8vtAk6qokucW.mQpsAgrw4pSvgf.xKmgOXgW_i.wlfVrUrg5U9TGcSMdzLFV I8V8Anv4JGq04saZfn0EmQhSXDk0GEkr2HobKL0Jr94ymG4glOER4IZRBpJMc4hcEFUnj_.NoEHc DgVc6LQSUnGxo9sWus0cxpd37H7t5BIZITfSXgopqBanTv3Xh9eWHT.3Fr1fKXlcIXgcnsfxcDkd HEylKprDQbkird_OAoXtYt649vVSmaciYZS3W0Ubovj7c3D1fTiZJCFGpZEA1tt2wkAjs7jWXvMY mCUTTa59IMvo8PL3rMB.DfR15KC4UOZdPBQ72iTQVibOhoFpoLTcTa5xsjaC80cw0FWT5vFTZu3d lNgPotN8SKEocdpp.7_EZCnG5u.huKJLQQ6zC4Qfj0KZXgsAHv4Wu3YQbh6zoW9xXzmmKvgewZbV Hgfz1U6fJBO0bmyr4PNn_N5tHQF7CBMdfF.aO1Y6Xqze_H_Ukqw8.ftMAbDoE9iCLvyYrLZMxUEr wf4ULfmiA9D7S9vFwl4vW9DrVeCC.533KqUKGb4YQ5WxwFslrQk5hSVoRGEPOLyqdu3snomxLFVx mT.DqQDPLAXKUU.fuZUrM2aCjcC3Va3l8syTI7mYLOOvC9dP1q6P781K6Eg6OG8GFr7JqtbyJlHL dEMMWKgPSgaBULlaPt4ag5D9QFGf9djYe5EDbBrprxgWkJCOzbH9Q6upwN38kWH6e5v2JksoO2G6 mekIqWzdeFlORRxA9b2FD54R0DS1SagxVChtxIuHaa5yVArN6.5fIHHsvttchaoU0ugb1Wq9xoMN 5Ilue_AedCdkPqgRZ5tPRM8NNpQElugct5TQX.LkIhr3o4c3oDkzEWOnGyrEwIhBn.Cw8wZ85e1U tUYI1A60EG4IPSosMm2v.LmpYzg608dpFPxAsDoaWLw3DX2ygtfURgyRe7MjtwhpxxDsl8n3FUAM vSuxcAWWIJ.Kwa1Ymj2oaesXw4Itj68oPavIA3ZVq6jfExemLbC3_r_9gkch.Io3auo4fKLGhX7i ae0rAop_Eu7A50jcyGVRQV1zz2ffEg7yKkEu1oQcyTsRNYa_OTsSyvDb2TXXN8h6DblARALxcB1a 2.Si3T7shwImyS9EgwBlQST79rh_P23fWmDMml6BscbTLQ31PK0E7GuiuBQOllB60h56zTPHqkh_ Q.KV7yJ2zhc9z.2__UnYui.yjodU5R.Yo3iMQJZA7Rq.A9qXkaUi3jHI5Hqqg2ud6eEHvE4GUVxC 6JkUynKycK.7tJtmE.1uFY3sL2QF8crOaNgr7.qesi3GpPxtUkvhCgT2O7EkvFh2KC3yF1GLFfAI SnLVMBdEu5FwNczxUCoy2a4tPw.6hMNtYMw18rrbsFgMqo1CuSwVjCRAVIcK.4kfbA6TyTMMdiuK BBerrL4Vz_Mo04vJw5MokrHFTpaEzHka29jQB_TzHq_WXHcqTo7QszE95PmzpE06fgTImdrUqfA1 jAo04mGMdgQHJzb78N0N2FBjDSMuShGsFK85HgDFLpT9jyWPIQZq54v8n1TAnXOuqq4GfOh_WKGa B68tK.CraUjbucHHeIiGw1Al1OIDzXriZYH3KHelowcK2cK2nvgfMALFZUGWy.EeyxAE_fjLp3bm j2cN0RGK_G200eouDLpnUPVnXVjjVoyC9WKeBURy2yUzhuNy.RxyYXPtduJtVRtUKDkLOx5m9P27 z_VG.wYFCSNW6WWwOWJcy9HGLV78e4KZJ6_0lTIuVO3U58FgbivsY_lGg3SKS8zLZfaYIkHOwbEw 6eSiTUcqWxRtD5QGKRe8XafMpUhXD41Tc9qUtImUeRB03FuJtue_gJYRQS0MzmhXTxWqFLZJnJyb YguAK1chEW7zvgVeZIvSFNBR_NuynHWxX..kp9j2j7w51bPGsw4cMTeGbvjGUJtCzvaEFgaeXHNE Kxe5ymTseps4k17gk1yHPlKGFz4ReykLfbAieAJm2_hWzDX5saIjGfgYNmBMPin0KuqPhvugWmk2 NQW8- X-Sonic-MF: X-Sonic-ID: c0e389ba-3dde-4b82-998c-abcaedc2bbeb Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 12 Apr 2025 06:55:54 +0000 Received: by hermes--production-gq1-74d64bb7d7-4jn9v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b4fb2d8eb1ac7767d56e0a6cff00cd20; Sat, 12 Apr 2025 06:55:52 +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 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes] From: Mark Millard In-Reply-To: <7A1322FA-A118-4F87-9D96-DE8B05E09424@yahoo.com> Date: Fri, 11 Apr 2025 23:55:41 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <6C67E39F-3634-4AF6-95EC-46159E7391E5@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <8B070D1D-0524-4DA4-A5C2-EF2CF98C5E15@yahoo.com> <7A1322FA-A118-4F87-9D96-DE8B05E09424@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.29 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.206:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.979]; NEURAL_HAM_MEDIUM(-0.81)[-0.807]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from] X-Rspamd-Queue-Id: 4ZZPTS3rYPz3jv8 X-Spamd-Bar: ---- On Apr 11, 2025, at 19:28, Mark Millard wrote: >=20 >> NOTE on something newly noticed while preparing this >> (a top post to keep it separate): >>=20 > . . . > NOTE on something newly noticed while preparing this > (a top post to keep it separate): >=20 > In looking to provide more detailed timing comparisons with > pkg 2.0.6 I noticed another context with a sizable delta > timing difference for building the packages, here using > www/rt50 as an example, just the one package being > built in each case. >=20 > # poudriere ports -l > PORTSTREE METHOD TIMESTAMP PATH > alt null 2025-04-06 14:15:11 /usr/ports-alt > default null 2021-04-18 02:05:47 /usr/ports >=20 > . . . The top-posted note was a dumb mistake on my part: Only /usr/ports-alt/ has a partial "bulk -v -a" set of materials. /usr/ports/ just has specific tested items built, with their prerequsites. (I do not have room on the media for two "bulk -a" storage usages at once.) So of course /usr/ports-alt/ has a lot more involved for its "Creating repository in /tmp/packages" and takes a lot longer. Time for me to try to get some sleep . . . The originally intended content below still applies. >=20 >=20 > Back to the originally intended content . . . >=20 >=20 > On Apr 11, 2025, at 14:04, Mark Millard wrote: >>=20 >> On Apr 11, 2025, at 11:39, Mark Millard wrote: >>=20 >>> On Apr 7, 2025, at 08:14, Baptiste Daroussin = wrote: >>>=20 >>>> . . . >>>> the problem we have is the >>>> performance changes depending on what is happening in parallel on = the machines. >>>=20 >>> In separate list messages I've provided multiple examples >>> of the time-taking issue that do not depend on what is >>> running in parallel on the machines, no parallel builds >>> involved. >>>=20 >>> Part of the issue is that there are thousands of examples of >>> "small build-step time" packages for which the build-depends, >>> lib-depends, run-depends combination, takes notable time, >>> given that the total time contribution across those thousands >>> of package builds is notable overall. >>>=20 >>> As stands, mostly it is the early part of "bulk -c -a" avoids >>> the issue via building packages that have no or few >>> dependencies. Later "small build-step time" packages tend to >>> have various dependencies, greatly changing the time scale >>> for their builds. Few builds are of "large build-step >>> time" packages (relative to there being 30000+ packages). That=20 >>> has implications for there being 30000+ packages to build for >>> "bulk -c -a" or other builds with large numbers of packages >>> to try to build. >>>=20 >>>> which makes the performance issues invisible on local poudriere if = you want to >>>> test it on port A or port B, >>>=20 >>> I've provided counter examples to that that only involve the >>> one builder, after the prerequisites have already been built >>> (same or prior bulk run). >>>=20 >>>> if we want to reduce the performance penalty we >>>> need to be able to make a reproducible case which can then be = profiled, to know >>>> where to optimize if needed. >>>=20 >>> I've provided examples of such . . . >>> (time intervals shown are from the aarch64 >>> Windows Dev Kit 2023 with just the one >>> builder active) >>>=20 >>> www/rt50 >>> build-depends: 00:00:27->00:08:46 >=20 > More detailed comparison/contrast of non-parallel builds: >=20 > A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:01:11] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 > [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = check-sanity > [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = pkg-depends > [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = fetch-depends > [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: fetch > [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: checksum > [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = extract-depends > [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: extract > [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = patch-depends > [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: patch > [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = build-depends > [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: = lib-depends > [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: configure > [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: build > [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: = run-depends > [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: stage > [00:01:29] [01] [00:00:18] Status www/rt50 | rt50-5.0.7: package > [00:01:50] [01] [00:00:39] Finished www/rt50 | rt50-5.0.7: Success >=20 > A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:03:04] [06] [00:00:00] Building www/rt50 | rt50-5.0.7 > [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: = check-sanity > [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: = pkg-depends > [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = fetch-depends > [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: fetch > [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: checksum > [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = extract-depends > [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: extract > [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = patch-depends > [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: patch > [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: = build-depends > [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: = lib-depends > [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: configure > [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: build > [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: = run-depends > [00:16:28] [06] [00:13:24] Status www/rt50 | rt50-5.0.7: stage > [00:16:30] [06] [00:13:26] Status www/rt50 | rt50-5.0.7: package > [00:17:03] [06] [00:13:59] Finished www/rt50 | rt50-5.0.7: Success >=20 > (That I got the 00:13:22 is interesting, given the prior > 00:08:46. May be the A78C cores were used instead of the > X1C cores? May be that there were no builds, just Inspecting > activity for the prerequisites. Did I not match the USE_TMPFS > settings? I expect that the general structural conclusions > are not invalidated.) >=20 >>> devel/py-inline-snapshot@py311 >>> build-depends: 00:00:01->00:00:55 >>> run-depends: 00:00:56->00:01:47 >=20 > A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:00:54] [04] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1 > [00:00:54] [04] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.18.1 > [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: check-sanity > [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: pkg-depends > [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch-depends > [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch > [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: checksum > [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract-depends > [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract > [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch-depends > [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch > [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build-depends > [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: lib-depends > [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: configure > [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build > [00:01:02] [04] [00:00:08] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: run-depends > [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: stage > [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: package > [00:01:04] [04] [00:00:10] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: Success >=20 > A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:02:46] [02] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 > [00:02:46] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [00:02:48] [02] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [00:04:00] [02] [00:01:14] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [00:05:27] [02] [00:02:41] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage > [00:05:28] [02] [00:02:42] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package > [00:05:28] [02] [00:02:42] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success >=20 > (Again longer 2.1.0 times vs. previous 2.1.0 times.) >=20 >>>=20 >>> mail/mailest@nox >>> build-depends: 00:00:01->00:00:28 >>> run-depends: 00:00:30->00:00:59 >=20 > A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:00:58] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:01:03] [01] [00:00:05] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:01:08] [01] [00:00:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:01:09] [01] [00:00:11] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:01:09] [01] [00:00:11] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >=20 > A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:02:50] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:03:32] [01] [00:00:42] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:04:09] [01] [00:01:19] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >=20 > (Again longer 2.1.0 times vs. previous 2.1.0 times.) >=20 >>>=20 >>> devel/dwarves >>> build-depends: 00:00:05->00:02:23 >>> lib-depends: 00:02:23->00:02:42 >=20 > A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:00:56] [07] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract > [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = patch > [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:01:07] [07] [00:00:11] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:01:08] [07] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = configure > [00:01:08] [07] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = build > [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = stage > [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = package > [00:01:14] [07] [00:00:18] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 > A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:02:54] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:02:58] [05] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:02:58] [05] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch > [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:05:33] [05] [00:02:39] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:06:07] [05] [00:03:13] Status devel/dwarves | dwarves-1.19_3: = configure > [00:06:07] [05] [00:03:13] Status devel/dwarves | dwarves-1.19_3: = build > [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = stage > [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = package > [00:06:12] [05] [00:03:18] Finished devel/dwarves | dwarves-1.19_3: = Success >=20 > (Again longer 2.1.0 times vs. previous 2.1.0 times.) >=20 >> net-mgmt/fastnetmon >> build-depends: 00:00:03->00:00:42 >> lib-depends: 00:00:42->00:01:29 >=20 > A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:01:00] [02] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 > [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity > [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch > [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends > [00:01:03] [02] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends > [00:01:07] [02] [00:00:07] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure > [00:01:10] [02] [00:00:10] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build > [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends > [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage > [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package > [00:03:18] [02] [00:02:18] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >=20 > A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >=20 > [00:02:54] [06] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 > [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity > [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch > [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends > [00:04:10] [06] [00:01:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends > [00:05:41] [06] [00:02:47] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure > [00:05:44] [06] [00:02:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build > [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends > [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage > [00:07:44] [06] [00:04:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package > [00:07:46] [06] [00:04:52] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >=20 > (Again longer 2.1.0 times vs. previous 2.1.0 times.) >=20 >> (See later below.) >>=20 >>> The timings are from the column next to >>> the Building/Status/Finished column from >>> using bulk -v , not from the column for >>> the overall bulk run. >>>=20 >>>> I have tried to reproduce each individual case which happen in the = ports tree >>>> and I am not able to reproduce them, so impossible to know where to = look at >>>> exactly. >>>=20 >>> Try some of the examples that I've provided? >>>=20 >>> There are more examples that I could check >>> and report non-parallel timings on if you >>> want. I just picked to report on only a few >>> initially. >>>=20 >>> An example that you might want is my >>> providing more examples of lib-depends >>> with non-parallel timings. >>=20 >> I took a quick look and quickly ran into: >> (aarch64 Windows Dev Kit 2023 no-parallel-builders >> timing again, after having built the prerequisites >> that had not previously been built) >>=20 >> [00:11:37] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 >> [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity >> [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch >> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends >> [00:12:19] [01] [00:00:42] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends >> [00:13:06] [01] [00:01:29] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure >> [00:13:09] [01] [00:01:32] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build >> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends >> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage >> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package >> [00:14:22] [01] [00:02:45] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >>=20 >> (I still have thousands of packages that have not built >> in the bulk -v -a build activity. The M4 MAX is in use >> for that.) >>=20 >>>> I know what is new and what causes the performance penalty, but not >>>> which part is causing the super extra penalty on the cluster. >>>=20 >>> Various examples reproduce the timing issues >>> outside the cluster and without the parallel >>> builds. >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 12 23:35:02 2025 X-Original-To: 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 4ZZqfN4dzDz5stF2 for ; Sat, 12 Apr 2025 23:35:08 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [IPv6:2a0c:5a00:149::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZZqfM0XSKz3ByC for ; Sat, 12 Apr 2025 23:35:07 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2a0c:5a00:149::25 is neither permitted nor denied by domain of ziaee@FreeBSD.org) smtp.mailfrom=ziaee@FreeBSD.org Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1u3kNL-00AHIj-Ck for current@freebsd.org; Sun, 13 Apr 2025 01:35:03 +0200 Received: from [10.9.9.128] (helo=rmmprod06.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1u3kNK-0000Zo-Sm for current@freebsd.org; Sun, 13 Apr 2025 01:35:03 +0200 Received: from mail by rmmprod06.runbox with local (Exim 4.86_2) (envelope-from ) id 1u3kNK-00053y-RZ for current@freebsd.org; Sun, 13 Apr 2025 01:35:02 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 Received: from [Authenticated alias (960477)] by runbox.com with http (RMM6); for ; Sat, 12 Apr 2025 23:35:02 GMT From: "Alexander Ziaee" To: "current" Subject: Enabling Spleen 64 from boot Date: Sat, 12 Apr 2025 23:35:02 +0000 (UTC) X-RMM-Aliasid: 960477 X-Mailer: RMM6 Message-Id: X-Spamd-Result: default: False [0.94 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.998]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; NEURAL_HAM_SHORT(-0.96)[-0.958]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2a0c:5a00:149::25:from]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO]; FREEFALL_USER(0.00)[ziaee]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; TO_DOM_EQ_FROM_DOM(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZZqfM0XSKz3ByC X-Spamd-Bar: / Hello, I'd like to enable spleen 64 in the build. It provides 80x25 character cons= ole on my 14" 2560x1600 display. I don't understand Makefile very well, but= it is working on my machine. Attached is the review. [0]: https://reviews.freebsd.org/D49768 Best, Alex= From nobody Sun Apr 13 01:22:13 2025 X-Original-To: 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 4ZZt291rdTz5t2cm for ; Sun, 13 Apr 2025 01:22:25 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZZt281nmTz3wP1; Sun, 13 Apr 2025 01:22:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-114.area1c.commufa.jp [124.18.43.114]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 53D1MDo1058213; Sun, 13 Apr 2025 10:22:14 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1744507334; bh=ASUV7JKVreGtkVDr9Dpp+cVPcApzlw3gVcqETCSQOfU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=YDHLHDGGlDmC9sDMl7vHIs00uScx9zdC8PbiHRvdRbILAGs/GbShKaHf/28dm1WPM wEneRt5T/tIm64iVYza03HpP0doD+2mKB4IHsOGh5gWRMezbls27EOMi+9GBN2b1pG dEvnzek9o81I51f1HPr+CYH/dkfvtnvy5T4+6eMg= Date: Sun, 13 Apr 2025 10:22:13 +0900 From: Tomoaki AOKI To: "Alexander Ziaee" Cc: "current" Subject: Re: Enabling Spleen 64 from boot Message-Id: <20250413102213.c592a25e8390bdc9aa54cd30@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) 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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4ZZt281nmTz3wP1 X-Spamd-Bar: ---- On Sat, 12 Apr 2025 23:35:02 +0000 (UTC) "Alexander Ziaee" wrote: > Hello, > > I'd like to enable spleen 64 in the build. It provides 80x25 character console on my 14" 2560x1600 display. I don't understand Makefile very well, but it is working on my machine. Attached is the review. > > [0]: https://reviews.freebsd.org/D49768 > > Best, > Alex If the problem is NOT in building the font itself, commenting on the review would be pointles, so commenting here. Is the font itself built fine reproducibly? For now, assuming it's OK here. And also assuming the problem is in console (vty) after loader invoked kernel. IIRC, there are codes to default character screen to 80x25 and choosing the font that best fits with it on maximum resolution of the computer in vt, but I've lost track of them. If the resolution is properly set as you want and well fitting font is installed, registered but not chosen correctly, there could be issues around the codes. To workaround, you can set allscreens_flags="-f /path/to/your/font/fontfile.fnt" in your /etc/rc.conf[.local]. If you don't want all vtys to be same configuration, you can put vidcontrol -f /path/to/your/font/fontfile.fnt instead. FYI: I have the codes below (remnant from transitional period from sc to vt). if [ "vt" = `sysctl -n -q kern.vty` ] then keymap="jp.kbd" if [ -r /usr/share/vt/fonts/b16.fnt ] ; then allscreens_flags="-f /usr/share/vt/fonts/b16.fnt" fi else keymap="jp.106.kbd" fi -- Tomoaki AOKI From nobody Sun Apr 13 02:02:28 2025 X-Original-To: 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 4ZZtwS0rX8z5t5cZ for ; Sun, 13 Apr 2025 02:02:32 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZZtwR63Vpz3F11 for ; Sun, 13 Apr 2025 02:02:31 +0000 (UTC) (envelope-from ziaee@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1u3mg1-00AS7J-6F for current@freebsd.org; Sun, 13 Apr 2025 04:02:29 +0200 Received: from [10.9.9.128] (helo=rmmprod06.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1u3mg0-0005Qm-Fo; Sun, 13 Apr 2025 04:02:28 +0200 Received: from mail by rmmprod06.runbox with local (Exim 4.86_2) (envelope-from ) id 1u3mg0-0004s8-Eq; Sun, 13 Apr 2025 04:02:28 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 Received: from [Authenticated alias (960477)] by runbox.com with http (RMM6); Sun, 13 Apr 2025 02:02:28 GMT From: "Alexander Ziaee" To: "Tomoaki AOKI" CC: "current" Subject: Re: Enabling Spleen 64 from boot Date: Sun, 13 Apr 2025 02:02:28 +0000 (UTC) X-RMM-Aliasid: 960477 X-Mailer: RMM6 In-Reply-To: <20250413102213.c592a25e8390bdc9aa54cd30@dec.sakura.ne.jp> Message-Id: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO] X-Rspamd-Queue-Id: 4ZZtwR63Vpz3F11 X-Spamd-Bar: ---- On 2025-04-12 21:22 -04:00 EDT, "Tomoaki AOKI" = wrote: > On Sat, 12 Apr 2025 23:35:02 +0000 (UTC) > "Alexander Ziaee" wrote: >=20 >> Hello, >>=20 >> I'd like to enable spleen 64 in the build. It provides 80x25 character c= onsole on my 14" 2560x1600 display. I don't understand Makefile very well, = but it is working on my machine. Attached is the review. >>=20 >> [0]: https://reviews.freebsd.org/D49768 >>=20 >> Best, >> Alex >=20 > If the problem is NOT in building the font itself, commenting on > the review would be pointles, so commenting here. > Is the font itself built fine reproducibly? > For now, assuming it's OK here. > And also assuming the problem is in console (vty) after loader > invoked kernel. This is a good catch. I edited the commit message to attempt to make it mor= e clear, did that help? Thanks, Alex= From nobody Sun Apr 13 02:51:17 2025 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 4ZZw0n1lR4z5sQZW for ; Sun, 13 Apr 2025 02:51:21 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 "mx1.riseup.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZZw0l46JYz3WGd for ; Sun, 13 Apr 2025 02:51:19 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=rhomc83p; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (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 mx1.riseup.net (Postfix) with ESMTPS id 4ZZw0j5Xk9zDqdP for ; Sun, 13 Apr 2025 02:51:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1744512677; bh=hnbh/aGIdis/mJPLTxtJ0EV2q0tehYyjamEeOi6YxJA=; h=Date:From:To:Subject:From; b=rhomc83pEJl8881jXiiGbSpta5/ji3Lgs1ZbP01sF4cf6//sIgiW9w7BpCfhV9NxT myyEOf/C4HYRHSRVWNjdqvxkZtZUEyue6enRZ0JpN3IoWop5kFdobb6ris9RCy8bpR wxCw+YqNOylN1nRjBtOkIXvS8DQWEopZ7/LFZZpE= X-Riseup-User-ID: A38BE82B4EFB54416A9F46AF17B4B9464110F5EA3C78576D686EF2E3E94D3138 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4ZZw0j4W7vzFsj7 for ; Sun, 13 Apr 2025 02:51:17 +0000 (UTC) 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 Date: Sun, 13 Apr 2025 02:51:17 +0000 From: Alastair Hogge To: freebsd-current@freebsd.org Subject: etcupdate failed to build tree with read-only /usr/src Message-ID: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.08 / 15.00]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_SPAM_LONG(1.00)[0.998]; NEURAL_HAM_SHORT(-0.88)[-0.882]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; R_SPF_ALLOW(-0.20)[+a:mx1.riseup.net]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[198.252.153.129:from]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RECEIVED_HELO_LOCALHOST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[riseup.net:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RBL_SENDERSCORE_REPUT_8(0.00)[198.252.153.129:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZZw0l46JYz3WGd X-Spamd-Bar: - Hello, I am updating a 15-CURRENT host from 1016b3c344350fa5968f16852e5e4e388c51d817[1] (2025-03-08 18:28:50 +0000) to 63578bf225df37944b78febfb177e8c1c81f54e4[2] (2025-04-12 19:50:06 +0000). My update process is as follows: $ cat /home/agh/tasks/update-host #!/bin/sh -ex UPDATE_HOST_HOST="$(hostname -s)" (cd /usr/src && \ env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make -j64 buildworld && \ env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make -j64 buildkernel) (echo "env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make installkernel") (echo "env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make installworld") You can see that I build kernel, and world from a non-root user, into a tmpfs prefix. /usr/src is mounted read-only from a NFS exported checkout. The git checkout is owned by a non-root user: $ mount -p | grep "/usr/src" /exports/fafnir/git/freebsd/src/main /usr/src nullfs ro 0 0 After the build processes complete, I then switch to root, to start the upgrade: $ doas su - # cd /usr/src # etcupdate -p # env MAKEOBJDIRPREFIX=/tmp/fafnir make installkernel # env MAKEOBJDIRPREFIX=/tmp/fafnir make installworld # etcupdate Here etcupdate exits with, "Failed to build new tree." I used git bisect to find the commit[3] where my update process broke: commit 49bc071f40886af46eb90467dfef6cba5f95beec Author: Mark Johnston Date: Mon Apr 7 12:42:08 2025 +0000 nsswitch.conf: Avoid modification after installation To implement WITHOUT_NIS, we have a hack in the build which modifies the installed nsswitch.conf to remove NIS compat providers and databases. This hack operates on the installed nsswitch.conf, which means that the installed file size won't match that listed in the metalog. One option would be to maintain two copies of nsswitch.conf, one for each configuration, but that would result in duplication and I don't see a clear way around that. Instead, stage a copy of nsswitch.conf in the libc objdir, and modify that one before installing, so that the version recorded in the metalog matches what actually gets installed. PR: 209718 Reviewed by: kevans, emaste Sponsored by: Klara, Inc. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49300 Is my update process flawed? Is updating from a read-only ${SRC} not an option anymore, or never was meant to be an option? Is it possible configure etcupdate to build the current tree in a custom build prefix? A snippet from the etcupdate log: # tail -n40 /var/db/etcupdate/log ===> lib/csu (installconfig) ===> lib/csu/amd64 (installconfig) ===> lib/libc (installconfig) installing DIRS CONFSDIR install -N /usr/src/etc -d -m 0755 -o root -g wheel /var/db/etcupdate/etcupdate-JN3IPm7/etc install -N /usr/src/etc -C -o root -g wheel -m 644 /usr/src/etc/group /var/db/etcupdate/etcupdate-JN3IPm7/etc/group install -N /usr/src/etc -C -o root -g wheel -m 600 /usr/src/etc/master.passwd /var/db/etcupdate/etcupdate-JN3IPm7/etc/master.passwd install -N /usr/src/etc -C -o root -g wheel -m 644 /usr/src/etc/shells /var/db/etcupdate/etcupdate-JN3IPm7/etc/shells install -N /usr/src/etc -C -o root -g wheel -m 644 net/hosts /var/db/etcupdate/etcupdate-JN3IPm7/etc/hosts install -N /usr/src/etc -C -o root -g wheel -m 644 net/hosts.equiv /var/db/etcupdate/etcupdate-JN3IPm7/etc/hosts.equiv install -N /usr/src/etc -C -o root -g wheel -m 644 net/networks /var/db/etcupdate/etcupdate-JN3IPm7/etc/networks cp -f /usr/src/lib/libc/net/nsswitch.conf /usr/src/lib/libc/nsswitch.conf cp: /usr/src/lib/libc/nsswitch.conf: Read-only file system *** Error code 1 Stop. make[5]: stopped making "installconfig" in /usr/src/lib/libc *** Error code 1 Stop. make[4]: stopped making "installconfig" in /usr/src/lib *** Error code 1 Stop. make[3]: stopped making "installconfig" in /usr/src *** Error code 1 Stop. make[2]: stopped making "distribution" in /usr/src *** Error code 1 Stop. make[1]: stopped making "installetc" in /usr/src *** Error code 1 Stop. make: stopped making "installetc" in /usr/src rm: /var/db/etcupdate/etcupdate-JN3IPm7/var/empty: Operation not permitted rm: /var/db/etcupdate/etcupdate-JN3IPm7/var: Directory not empty rm: /var/db/etcupdate/etcupdate-JN3IPm7: Directory not empty 1: https://cgit.freebsd.org./src/commit/?id=1016b3c344350fa5968f16852e5e4e388c51d817 2: https://cgit.freebsd.org./src/commit/?id=63578bf225df37944b78febfb177e8c1c81f54e4 3: https://cgit.freebsd.org./src/commit/?id=49bc071f40886af46eb90467dfef6cba5f95beec -- To good health, Alastair From nobody Sun Apr 13 08:26:39 2025 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 4Zb3Rr41Zqz5svDR for ; Sun, 13 Apr 2025 08:26:48 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zb3Rr16QNz3Qhs for ; Sun, 13 Apr 2025 08:26:48 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.18.1/8.18.1) with ESMTPS id 53D8QdJX077692 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 13 Apr 2025 10:26:39 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.18.1/8.18.1/Submit) id 53D8Qdg2077690; Sun, 13 Apr 2025 10:26:39 +0200 (CEST) (envelope-from fuz) Date: Sun, 13 Apr 2025 10:26:39 +0200 From: Robert Clausecker To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src Message-ID: 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-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Queue-Id: 4Zb3Rr16QNz3Qhs X-Spamd-Bar: ---- Hi Alastair, That sounds like a bug! Please report it on Bugzilla. Yours, Robert Clausecker Am Sun, Apr 13, 2025 at 02:51:17AM +0000 schrieb Alastair Hogge: > Hello, > > I am updating a 15-CURRENT host from > 1016b3c344350fa5968f16852e5e4e388c51d817[1] (2025-03-08 18:28:50 +0000) > to > 63578bf225df37944b78febfb177e8c1c81f54e4[2] (2025-04-12 19:50:06 +0000). > My update process is as follows: > > $ cat /home/agh/tasks/update-host > #!/bin/sh -ex > > UPDATE_HOST_HOST="$(hostname -s)" > > (cd /usr/src && \ > env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make -j64 > buildworld && \ > env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make -j64 > buildkernel) > > (echo "env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make > installkernel") > (echo "env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make installworld") > > You can see that I build kernel, and world from a non-root user, into a > tmpfs prefix. > > /usr/src is mounted read-only from a NFS exported checkout. The git > checkout is owned by a non-root user: > $ mount -p | grep "/usr/src" > /exports/fafnir/git/freebsd/src/main /usr/src nullfs ro > 0 0 > > After the build processes complete, I then switch to root, to start the > upgrade: > > $ doas su - > # cd /usr/src > # etcupdate -p > # env MAKEOBJDIRPREFIX=/tmp/fafnir make installkernel > # env MAKEOBJDIRPREFIX=/tmp/fafnir make installworld > # etcupdate > > Here etcupdate exits with, "Failed to build new tree." > > I used git bisect to find the commit[3] where my update process broke: > commit 49bc071f40886af46eb90467dfef6cba5f95beec > Author: Mark Johnston > Date: Mon Apr 7 12:42:08 2025 +0000 > > nsswitch.conf: Avoid modification after installation > > To implement WITHOUT_NIS, we have a hack in the build which modifies > the > installed nsswitch.conf to remove NIS compat providers and > databases. > This hack operates on the installed nsswitch.conf, which means that > the > installed file size won't match that listed in the metalog. > > One option would be to maintain two copies of nsswitch.conf, one for > each configuration, but that would result in duplication and I don't > see > a clear way around that. > > Instead, stage a copy of nsswitch.conf in the libc objdir, and > modify > that one before installing, so that the version recorded in the > metalog > matches what actually gets installed. > > PR: 209718 > Reviewed by: kevans, emaste > Sponsored by: Klara, Inc. > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D49300 > > Is my update process flawed? Is updating from a read-only ${SRC} not an > option anymore, or never was meant to be an option? Is it possible > configure etcupdate to build the current tree in a custom build prefix? > > A snippet from the etcupdate log: > # tail -n40 /var/db/etcupdate/log > ===> lib/csu (installconfig) > ===> lib/csu/amd64 (installconfig) > ===> lib/libc (installconfig) > installing DIRS CONFSDIR > install -N /usr/src/etc -d -m 0755 -o root -g wheel > /var/db/etcupdate/etcupdate-JN3IPm7/etc > install -N /usr/src/etc -C -o root -g wheel -m 644 /usr/src/etc/group > /var/db/etcupdate/etcupdate-JN3IPm7/etc/group > install -N /usr/src/etc -C -o root -g wheel -m 600 > /usr/src/etc/master.passwd > /var/db/etcupdate/etcupdate-JN3IPm7/etc/master.passwd > install -N /usr/src/etc -C -o root -g wheel -m 644 > /usr/src/etc/shells /var/db/etcupdate/etcupdate-JN3IPm7/etc/shells > install -N /usr/src/etc -C -o root -g wheel -m 644 net/hosts > /var/db/etcupdate/etcupdate-JN3IPm7/etc/hosts > install -N /usr/src/etc -C -o root -g wheel -m 644 net/hosts.equiv > /var/db/etcupdate/etcupdate-JN3IPm7/etc/hosts.equiv > install -N /usr/src/etc -C -o root -g wheel -m 644 net/networks > /var/db/etcupdate/etcupdate-JN3IPm7/etc/networks > cp -f /usr/src/lib/libc/net/nsswitch.conf > /usr/src/lib/libc/nsswitch.conf > cp: /usr/src/lib/libc/nsswitch.conf: Read-only file system > *** Error code 1 > > Stop. > make[5]: stopped making "installconfig" in /usr/src/lib/libc > *** Error code 1 > > Stop. > make[4]: stopped making "installconfig" in /usr/src/lib > *** Error code 1 > > Stop. > make[3]: stopped making "installconfig" in /usr/src > *** Error code 1 > > Stop. > make[2]: stopped making "distribution" in /usr/src > *** Error code 1 > > Stop. > make[1]: stopped making "installetc" in /usr/src > *** Error code 1 > > Stop. > make: stopped making "installetc" in /usr/src > rm: /var/db/etcupdate/etcupdate-JN3IPm7/var/empty: Operation not > permitted > rm: /var/db/etcupdate/etcupdate-JN3IPm7/var: Directory not empty > rm: /var/db/etcupdate/etcupdate-JN3IPm7: Directory not empty > > 1: > https://cgit.freebsd.org./src/commit/?id=1016b3c344350fa5968f16852e5e4e388c51d817 > 2: > https://cgit.freebsd.org./src/commit/?id=63578bf225df37944b78febfb177e8c1c81f54e4 > 3: > https://cgit.freebsd.org./src/commit/?id=49bc071f40886af46eb90467dfef6cba5f95beec > > -- > To good health, > Alastair > -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments From nobody Sun Apr 13 08:47:10 2025 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 4Zb3vN2cPzz5swnq for ; Sun, 13 Apr 2025 08:47:12 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 "mx1.riseup.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zb3vN0jLlz3Zpd for ; Sun, 13 Apr 2025 08:47:12 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; none Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (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 mx1.riseup.net (Postfix) with ESMTPS id 4Zb3vL61KYzDqSy; Sun, 13 Apr 2025 08:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1744534030; bh=wPHJSr4Lp6OcXxyMgRXm7JaQxUtRUboycJ4ac0e7sic=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qqwKw77wY9rO2dY3lte3bEDjiJh5xnBkUs157BVsTCvhA5UGgxI2Em9KTfWtSXwBj wFaFmKJ2YNyqH9YApHd3dM4mwRhFZzYJFzmTwBwKjrQ70i6OB/HGLtKj6UPn45Qscw W0BPX4hUvepdjgFyDXKOOf7fieK08C3ZKVK8NC50= X-Riseup-User-ID: 3F90374B564CDE0FD3CBE06EAD3CAC749DF71D450D9D1CDD38D7939B8FB526B1 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4Zb3vL4V40zFtKj; Sun, 13 Apr 2025 08:47:10 +0000 (UTC) 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 Date: Sun, 13 Apr 2025 08:47:10 +0000 From: Alastair Hogge To: Robert Clausecker Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src In-Reply-To: References: Message-ID: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US] X-Rspamd-Queue-Id: 4Zb3vN0jLlz3Zpd X-Spamd-Bar: ---- On 2025-04-13 16:26, Robert Clausecker wrote: > Hi Alastair, Hey Robert, > That sounds like a bug! Please report it on Bugzilla. Done, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286072 Thanks. -- To good health, Alastair >> I am updating a 15-CURRENT host from >> 1016b3c344350fa5968f16852e5e4e388c51d817[1] (2025-03-08 18:28:50 +0000) >> to >> 63578bf225df37944b78febfb177e8c1c81f54e4[2] (2025-04-12 19:50:06 +0000). >> My update process is as follows: >> >> $ cat /home/agh/tasks/update-host >> #!/bin/sh -ex >> >> UPDATE_HOST_HOST="$(hostname -s)" >> >> (cd /usr/src && \ >> env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make -j64 >> buildworld && \ >> env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make -j64 >> buildkernel) >> >> (echo "env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make >> installkernel") >> (echo "env MAKEOBJDIRPREFIX=/tmp/${UPDATE_HOST_HOST} make installworld") >> >> You can see that I build kernel, and world from a non-root user, into a >> tmpfs prefix. >> >> /usr/src is mounted read-only from a NFS exported checkout. The git >> checkout is owned by a non-root user: >> $ mount -p | grep "/usr/src" >> /exports/fafnir/git/freebsd/src/main /usr/src nullfs ro >> 0 0 >> >> After the build processes complete, I then switch to root, to start the >> upgrade: >> >> $ doas su - >> # cd /usr/src >> # etcupdate -p >> # env MAKEOBJDIRPREFIX=/tmp/fafnir make installkernel >> # env MAKEOBJDIRPREFIX=/tmp/fafnir make installworld >> # etcupdate >> >> Here etcupdate exits with, "Failed to build new tree." >> >> I used git bisect to find the commit[3] where my update process broke: >> commit 49bc071f40886af46eb90467dfef6cba5f95beec >> Author: Mark Johnston >> Date: Mon Apr 7 12:42:08 2025 +0000 >> >> nsswitch.conf: Avoid modification after installation >> >> To implement WITHOUT_NIS, we have a hack in the build which modifies >> the >> installed nsswitch.conf to remove NIS compat providers and >> databases. >> This hack operates on the installed nsswitch.conf, which means that >> the >> installed file size won't match that listed in the metalog. >> >> One option would be to maintain two copies of nsswitch.conf, one for >> each configuration, but that would result in duplication and I don't >> see >> a clear way around that. >> >> Instead, stage a copy of nsswitch.conf in the libc objdir, and >> modify >> that one before installing, so that the version recorded in the >> metalog >> matches what actually gets installed. >> >> PR: 209718 >> Reviewed by: kevans, emaste >> Sponsored by: Klara, Inc. >> Sponsored by: The FreeBSD Foundation >> Differential Revision: https://reviews.freebsd.org/D49300 >> >> Is my update process flawed? Is updating from a read-only ${SRC} not an >> option anymore, or never was meant to be an option? Is it possible >> configure etcupdate to build the current tree in a custom build prefix? >> >> A snippet from the etcupdate log: >> # tail -n40 /var/db/etcupdate/log >> ===> lib/csu (installconfig) >> ===> lib/csu/amd64 (installconfig) >> ===> lib/libc (installconfig) >> installing DIRS CONFSDIR >> install -N /usr/src/etc -d -m 0755 -o root -g wheel >> /var/db/etcupdate/etcupdate-JN3IPm7/etc >> install -N /usr/src/etc -C -o root -g wheel -m 644 /usr/src/etc/group >> /var/db/etcupdate/etcupdate-JN3IPm7/etc/group >> install -N /usr/src/etc -C -o root -g wheel -m 600 >> /usr/src/etc/master.passwd >> /var/db/etcupdate/etcupdate-JN3IPm7/etc/master.passwd >> install -N /usr/src/etc -C -o root -g wheel -m 644 >> /usr/src/etc/shells /var/db/etcupdate/etcupdate-JN3IPm7/etc/shells >> install -N /usr/src/etc -C -o root -g wheel -m 644 net/hosts >> /var/db/etcupdate/etcupdate-JN3IPm7/etc/hosts >> install -N /usr/src/etc -C -o root -g wheel -m 644 net/hosts.equiv >> /var/db/etcupdate/etcupdate-JN3IPm7/etc/hosts.equiv >> install -N /usr/src/etc -C -o root -g wheel -m 644 net/networks >> /var/db/etcupdate/etcupdate-JN3IPm7/etc/networks >> cp -f /usr/src/lib/libc/net/nsswitch.conf >> /usr/src/lib/libc/nsswitch.conf >> cp: /usr/src/lib/libc/nsswitch.conf: Read-only file system >> *** Error code 1 >> >> Stop. >> make[5]: stopped making "installconfig" in /usr/src/lib/libc >> *** Error code 1 >> >> Stop. >> make[4]: stopped making "installconfig" in /usr/src/lib >> *** Error code 1 >> >> Stop. >> make[3]: stopped making "installconfig" in /usr/src >> *** Error code 1 >> >> Stop. >> make[2]: stopped making "distribution" in /usr/src >> *** Error code 1 >> >> Stop. >> make[1]: stopped making "installetc" in /usr/src >> *** Error code 1 >> >> Stop. >> make: stopped making "installetc" in /usr/src >> rm: /var/db/etcupdate/etcupdate-JN3IPm7/var/empty: Operation not >> permitted >> rm: /var/db/etcupdate/etcupdate-JN3IPm7/var: Directory not empty >> rm: /var/db/etcupdate/etcupdate-JN3IPm7: Directory not empty >> >> 1: >> https://cgit.freebsd.org./src/commit/?id=1016b3c344350fa5968f16852e5e4e388c51d817 >> 2: >> https://cgit.freebsd.org./src/commit/?id=63578bf225df37944b78febfb177e8c1c81f54e4 >> 3: >> https://cgit.freebsd.org./src/commit/?id=49bc071f40886af46eb90467dfef6cba5f95beec >> >> -- >> To good health, >> Alastair >> From nobody Sun Apr 13 22:32:54 2025 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 4ZbQDV3F1Jz5sq3C for ; Sun, 13 Apr 2025 22:33:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4ZbQDT5B7Yz47J0 for ; Sun, 13 Apr 2025 22:33:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I5A3y8q6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744583587; bh=aUgXOFTnF/45Tr5jMYj/ZnCr4vQAmnu/A2nLFwr9gO4=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=I5A3y8q6/hy+TKD966pwGxOi1YFCmb3YLHLBA/LF96DzhZ2d+tS7bYBvwJha1IsOl8AVmGMJTQWfmtLUt8NLRjXlu3N6Yh1q0TpYaimLLbUjL7RkLGClwbPc1nyrXZ6zqylXinVROCqTXMEnEn03NoWuCtEtEcTB1g+CXF+vBxdYBaaZIZ5SsQ6y12+b2bHDPBabKVwCJiYxzpApg7s0tcuY0Mc930MUgRGud7BOYhbuAtwg5eVCYxAGVKz7XVMKxyRJjZycO/0B129Rrq6VfEVHxhwobkiZ65RbLDPFz2YjKCo61cGaj/DaE5UTDRaZlzdFYkqIIyLhAiUVUhLKSQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744583587; bh=hZRLcLzuDvqj2ZV28jma1yd1Mp9ddnS0b5kuwK9Jbmt=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=bykAPYlr7G3rD0W8fO2C5ouH5gqZMEuXRzUFZdC5Ihvz9Ox7Rig69zyknk7X7DYyFRt42EA2Rg6xJF5AXKp29/tj36Z1EbAtfBB4L5Nu47NKdxn+0CAOXYV4dEq4JBoolXABZkLtHEuSVy3xt73SCPOJllE7DPsYT9biawQKudKVT3vXsHEE4WAV5a4L1cSHj8Ldrx0kp14Uo7PH/dqZQYtJzOCCMMl25+KyYJDVFEv+mTedsJEZRFpMNHDmZ9G78o75+xyLIERh20P+d6JJjLltB+LE96N8sarpUhKGI932HRjSfTb+15kxs5aXHrEO8bUihmP8iQDxHt9Q2GQecQ== X-YMail-OSG: NABaIOYVM1nHwRlzKvTRGGLFXfroGjpiSK4wqhVGReNUpeDSJIAVhd3g7FZx3Ng 3jQV8i6uoPPLmWM9vtLr9QR8jdeCfretOe_a8eIPJEcQ74Od5gEWH_svqoUVet3e1VDXvygkMlUd BDooUb3d_F7q3X3Y_5m8E5lGcG2Dq_7wUWqXJj7djnPyco_bb_KtZ42Y03swxgkX8zP4y5pXbpZN Vka.coWG2NIbP8sViaV.xSB_8eJWapvDYMz8WbQeLr9RkKBxxzgLscAVB2htWeAoHvCTg2d_p4Dq 3WfOnK_FA2a18gFmsnO1ATNzhq8JimGS4jnWR1n57Rizp3VjrqGScA5I8dabo4kI67DdnhBqFjZI ayj3Qp0Mzxo7yLQT1tmdo6t5HTtku5rrNdNFLDOXuLlMhilFDK3i.GxA6zaRkQAfey9jT.S9Cbex 3mUaOZ76H7QW7BNWnejOh2IfhueoGeLim.e_oVSbO7Vj_Zb2o7Ui7Z3_eDlHv82N98Mc_5cEIRGG H.2p4QPM35evMjq_nIr1.YfN8OFziEEXp80fMG4WoypMj7Fb5zZZNQisC87iupp77GpW612RzqIv 46GCrpXyCykUHBdgBqScOGk6PzpJ.LMoildNOLQrS493WH_EXANIEBMxa63ZLDML0s_DLIcaV2VM NE68nR3S226vhqCHm5lkiKY4u9QVpPpWAKJOpa.fo3qKXL28rPVnEp6xkJadDBfGT_p_8wh5qXIv any6rdbHpEysiUzNjCHSt8pxs7EVdLsWLxEfakkiBKAgVHF1VBXBC.K6JruNnHWuWgcwAFXxZ0z5 .BLOJKe0rJfO.BsewVMidmgSJ1OvtZhAhUiAC9moITQpnxrpVms_nk2DH6Y_ifOEv.OseiQ6eK7v uN5nRZdCjrvgDdDHUUqxdG_uXN3b5dMZp7YlCPrvww9PDfnbkkvFD.khZWhshckXgELhKTauK2da rTpm8tc2AliboVSuXhWEYna2S.joTWtjlAC.1XQneNcaOpGA_McdbxMgEu.cth4yRr1doydfalA. 3M41AEBPHzUZsMYT3.0fY1j5MXEgiznz2KVV7TiBx04jFM_2W0hWlsC5wdKuv2Kzj8gjHlrgR2fs g3hBtbHnb5F3K2qFWKGkFmgJYjpnlPXPH2wkJRRxT6W2vJvlIIseaXOryKBN.mrwKE0RUsy9Fs31 5TctosfvQIOJFhGRl2SXdEK1DvyFOU2SRF6q4fc_XF6aCvQxv5AGr3.g9LOMjsLIb42lYZgtAoou sb6JiAigj3KBLDqvfnLCRZr0dotY3vjIIsKP5yR73VW0MZ2vLXQw_uj2diZ3N8uQMAK.TCRobq9K cBfik4mVdZ2VjHMzqovgr4FIDSWSVORQroxgihu3skBTY.jr8EiAnKJxhIOLxEWQzf2Z17_ZAkVu fs_iwFApwW6j0QFA2nu.B56Fuv7nGmRSsN2L4rFePZ7SLO7VGJu5CNuS1BpMgsWhaN46OOFFsZ2Z 1xMhW3uiiSpeC2rTejG13f7Q7_XhvgH5KUaPWzIaLs9saxsKLFP6ujQ4E.bRTGEDmYlteQkOCQ1g VHoK5snXJ8J2mJeB6yLvAyLtjbzs5BWXWrMoLuLLJqrwutHfR8.I_vBNSYCeuOek2IZyYtajo8GL 5lN8UV0fDCof628G5MHKJkoMi72mC02Dhb1tboZECnKj2X_VZDjE2KjPbUn.7gfV4nYG3pgZLPPQ ePNI6xSchb3k0RXfBWOUaMMn9OiI_j6nYKFlhhJVXDUNQa76zbaYPMwgBVBTVwn24VWJWD3TVA_Q 5ejey8ahEB8mrCwyG43h5uYbivx5M5UUR9Q9zgrYES4MYxV54qu1N28EQizO__Oww4lQzFbqsnFQ SbXkN8RC3y2D399acel5P36NQRCnFoVZ5Jpb0UJFeMjne80P_dwfyPl13Q8rqzR0H0ml7.A3zGRc gPFRC46yiqmCvdZtx50lGxmjkPyXFm8kfhfl7OwyUek9_cXs7Qk8KZdCXVIiHjJbm0KQj8K62n8q 06bTjFLEssLCAIuSCMn6G4FT6Uy9Y110ajzwm30CsFQEJWFD2rYZg9dW6BcQ1lSFyKhqCFge5t6O wifcQnC4mvYGp3SXMwK.7524fSzl7KX8U9wxIOYRu9dXpMb788fKmTgvyedh1zWT6bkIriHNNY9I XMaSQvyYOmTxHcIxOVuqOiQuYIa4QiVyksq2c9dgCsi41erkn5DDfaFyZ5B8V6OuKPYF3dTuPE5X tKUwU270RnUp69A0uFlBThoKdnWx9iNv_a35B1ZWZxgV82nSGkdUyXSeOa0wkR6trIZod0m.j3iu YMgWGb0R7Zmz87A-- X-Sonic-MF: X-Sonic-ID: 208e9982-29e9-413b-a26c-ccf068d1a9b6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Apr 2025 22:33:07 +0000 Received: by hermes--production-gq1-74d64bb7d7-6pskz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a28d5bd89c32f1611c7a27d0e786994e; Sun, 13 Apr 2025 22:33:04 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3826.500.181.1.5\)) Subject: poudriere-devel based "bulk -a" has stuck builder slot because of "umount: unmount of . . ./01/wrkdirs failed: Device busy" Message-Id: <8E9E7F6D-E617-4C89-A10D-4C1EFCC90A2D@yahoo.com> Date: Sun, 13 Apr 2025 15:32:54 -0700 Cc: FreeBSD Current To: FreeBSD Mailing List , Bryan Drewery X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <8E9E7F6D-E617-4C89-A10D-4C1EFCC90A2D.ref@yahoo.com> X-Spamd-Result: default: False [-0.05 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.147:from]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_SPAM_LONG(0.99)[0.985]; NEURAL_HAM_SHORT(-0.54)[-0.535]; 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]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZbQDT5B7Yz47J0 X-Spamd-Bar: / In a UFS/USE_TMPFS=3Dall/TMPFS_BLACKLIST context doing some "bulk -a" = testing, I got: . . . --- intern/cycles/bvh/CMakeFiles/cycles_bvh.dir/all --- clang++: error: unsupported option '-msse' for target = 'aarch64-portbld-freebsd14.2' clang++: error: unsupported option '-msse2' for target = 'aarch64-portbld-freebsd14.2' clang++: error: unsupported option '-msse3' for target = 'aarch64-portbld-freebsd14.2' clang++: error: unsupported option '-mssse3' for target = 'aarch64-portbld-freebsd14.2' clang++: error: unsupported option '-msse4.1' for target = 'aarch64-portbld-freebsd14.2' clang++: warning: argument unused during compilation: '-msse4.2' = [-Wunused-command-line-argument] --- intern/libmv/CMakeFiles/bf_intern_libmv.dir/all --- [ 4%] Building CXX object = intern/libmv/CMakeFiles/bf_intern_libmv.dir/libmv/tracking/track_region.cc= .o --- intern/cycles/bvh/CMakeFiles/cycles_bvh.dir/all --- *** [intern/cycles/bvh/CMakeFiles/cycles_bvh.dir/bvh.cpp.o] Error code 1 make[2]: stopped in /wrkdirs/usr/ports/graphics/blender/work/.build *** [all] Error code 6 make: stopped in /wrkdirs/usr/ports/graphics/blender/work/.build 1 error make: stopped in /wrkdirs/usr/ports/graphics/blender/work/.build =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/graphics/blender =3D>> Cleaning up wrkdir =3D=3D=3D> Cleaning for blender-4.2.0_7 umount: unmount of = /usr/local/poudriere/data/.m/release-aarch64-alt/01/wrkdirs failed: = Device busy "poudriere status -b" currently shows: ID TOTAL ORIGIN PKGNAME = PHASE TIME TMPFS CPU% MEM% [01] 11:32:32 graphics/blender | blender-4.2.0_7 = build 11:07:31 5.21 GiB =20 . . . Notably [01] is not referenced in: # ps -adxlw | grep build_pkg 0 54387 2321 7 20 0 13052 2164 piperd S+ 1 0:00.00 | | = `-- grep build_pkg 0 14212 44084 10 55 0 22416 8524 select S 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][09]: build_pkg = (geany-plugin-pairtaghighlighter-2.0) (sh) 0 52600 14212 8 56 0 22416 8512 wait S 2 0:00.00 | = | | `-- sh: poudriere[release-aarch64-alt][09]: build_pkg = (geany-plugin-pairtaghighlighter-2.0) (sh) 0 20618 44084 4 42 0 22416 8588 wait I 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][05]: build_pkg = (ja-ibus-anthy-unicode-1.5.16_2) (sh) 0 32459 44084 6 31 0 22416 8624 wait I 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][02]: build_pkg = (ja-ibus-mozc-2.23.2815.102.01_26) (sh) 0 35076 44084 2 68 0 22416 8620 wait I 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][03]: build_pkg = (zh-ibus-chewing-1.5.1_1) (sh) 0 36521 44084 11 68 0 22416 8608 wait I 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][06]: build_pkg = (ibus-m17n-1.4.35) (sh) 0 50626 44084 11 68 0 22416 8644 wait S 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][04]: build_pkg = (zh-ibus-libpinyin-1.15.4) (sh) 0 54274 44084 4 32 0 22416 7888 select I 2 0:00.05 | = | |-- sh: poudriere[release-aarch64-alt][11]: build_pkg = (iridium-browser-2025.03.134.2_1) (sh) 0 47822 54274 2 34 0 22416 7876 wait I 2 0:00.00 | = | | `-- sh: poudriere[release-aarch64-alt][11]: build_pkg = (iridium-browser-2025.03.134.2_1) (sh) 0 57341 44084 6 68 0 22416 8480 select I 2 0:00.05 | = | |-- sh: poudriere[release-aarch64-alt][10]: build_pkg = (atril-lite-1.28.1_2) (sh) 0 88648 57341 7 68 0 22416 8468 wait I 2 0:00.00 | = | | `-- sh: poudriere[release-aarch64-alt][10]: build_pkg = (atril-lite-1.28.1_2) (sh) 0 77471 44084 6 28 0 22416 8504 wait I 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][07]: build_pkg = (gnome-desktop-44.1) (sh) 0 82067 44084 10 47 0 22416 8472 wait I 2 0:00.04 | = | |-- sh: poudriere[release-aarch64-alt][12]: build_pkg = (dissent-0.0.32_2) (sh) 0 91953 44084 11 68 0 22416 8484 wait S 2 0:00.04 | = | `-- sh: poudriere[release-aarch64-alt][08]: build_pkg = (gajim-2.0.2) (sh) There is a wrkdirs/blender-* reference in: # df -m | grep /01 tmpfs = 250590 1564 249026 1% = /usr/local/poudriere/data/.m/release-aarch64-alt/01 /usr/local/poudriere/data/.m/release-aarch64-alt/ref/rescue = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/rescue /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/lib32 = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/lib32 /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/share = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/share /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/tests = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/tests /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/src = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/src devfs = 0 0 0 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/dev fdescfs = 0 0 0 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/dev/fd procfs = 0 0 0 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/proc tmpfs = 2048 32 2015 2% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/.p /usr/ports-alt = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/ports /usr/local/poudriere/data/packages/release-aarch64-alt/.building = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/packages /usr/ports/distfiles = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/distfiles /usr/local/poudriere/data/.m/release-aarch64-alt/ref/var/db/ports = 249026 0 249026 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/var/db/ports tmpfs = 252761 3734 249026 1% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/local /usr/local/poudriere/data/cache/tmp/wrkdirs/blender-4.2.0_7.5edV9jyL = 1114846 531213 494445 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/wrkdirs A manual: # umount /usr/local/poudriere/data/.m/release-aarch64-alt/01/wrkdirs got rid of the mount: # df -m | grep /01 tmpfs = 247967 1564 246402 1% = /usr/local/poudriere/data/.m/release-aarch64-alt/01 /usr/local/poudriere/data/.m/release-aarch64-alt/ref/rescue = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/rescue /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/lib32 = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/lib32 /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/share = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/share /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/tests = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/tests /usr/local/poudriere/data/.m/release-aarch64-alt/ref/usr/src = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/src devfs = 0 0 0 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/dev fdescfs = 0 0 0 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/dev/fd procfs = 0 0 0 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/proc tmpfs = 2048 32 2015 2% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/.p /usr/ports-alt = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/ports /usr/local/poudriere/data/packages/release-aarch64-alt/.building = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/packages /usr/ports/distfiles = 1114846 531325 494332 52% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/distfiles /usr/local/poudriere/data/.m/release-aarch64-alt/ref/var/db/ports = 246402 0 246402 0% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/var/db/ports tmpfs = 250137 3734 246402 1% = /usr/local/poudriere/data/.m/release-aarch64-alt/01/usr/local But, after that, there is still: # poudriere status -b =3D>> [release-aarch64-alt] [2025-04-12_12h16m51s] [parallel_build] = Time: 1D:03:09:18 Queued: 18376 Inspected: 12949 Ignored: 981 Built: 1675 Failed: 229 = Skipped: 1299 Fetched: 0 Remaining: 1243 ID TOTAL ORIGIN PKGNAME = PHASE TIME TMPFS CPU% MEM% [01] 12:02:30 graphics/blender | blender-4.2.0_7 = build 11:37:29 5.21 GiB =20 . . . =3D=3D=3D Mark Millard marklmi at yahoo.com