From nobody Mon May 5 02:43:15 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 4ZrQnb08H1z5thxd for ; Mon, 05 May 2025 02:43:31 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 4ZrQnZ1sVrz3xZR for ; Mon, 05 May 2025 02:43:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="dN63/TIG"; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-ac3fcf5ab0dso637685166b.3 for ; Sun, 04 May 2025 19:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746413007; x=1747017807; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=f09SATjAOGAEAtYKUx8Rna7I2Aq9e8EY3cDVD2GVUXQ=; b=dN63/TIGHbm8kUW55VqBCkHWCknyloLfha6bcRyvfr2IjSufRg0lU5fh0Gv4QlLKQa +xpc9DTEnnmYFFwG8ujOmnsZkg020ZbwzmiwrTdTmhrBL156WVfGQWbd3yIFK2HOwFFh 5eYLKvcZMjYzQUiwU22fOzXSXNGPVN7aIXOT8Kt1XHUdD3yoIWwDbunWOT1fmamowFyW OgdbOWzpLQenh2YhKmqzo5AlZ3FvbnHGN3tHeU+y6uVXZnopl2pnGt/g15sOjuAgZ1P5 oiXEDk+3g/6TyaFixx7Qc7kru/I71YnE4jiecBVqz75nHFCfmTyynYEJ8sFAPKQUILA2 TOOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746413007; x=1747017807; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=f09SATjAOGAEAtYKUx8Rna7I2Aq9e8EY3cDVD2GVUXQ=; b=H7BEHmXc2nkrDDR9Iot5qLjJaHVCvXES2+yZXtVQY+rVHOyMyaOmyxcgd9iXmczNwW Jl+Lq7Ixx1OOpvRZVCA1r92KwI7WhrzpqkDd5dfvTNLWEEn6jvmnr84JH+xY4I8lSd6r 9IC2iQhGg0CgR6gWDwF/Nneq1J85uDOeVmIGv9AUNlVnoVXEux+q9/Cr+aTq8fYl5x39 jwjix2xIX3R3F1v82wi/y7wcbT7/PSxjXwrCDmkdpi/uiNRw6sfea8LV+gMk9zgS3Wh+ KK6RoIlGhVkGt6AK/4JWTizHqW/AKhayxk/gJvJZHDZIaDgROlFFR16lnc1ZyQ4oT6MP Xidg== X-Gm-Message-State: AOJu0YxrY61WsFgXNq+bOnqL3Ns5oxb9nwiuqBFXT8gRcprTx3qC12/3 n+ydxq1q59EDvjTLDDjv9DZEfGHXZ9UOLtqJR0wYmHTcnrqDBqOGenXGW8hzERmJuJJcrDvVios qicxL0pKELAxIzHWVP/nKheS8zISc X-Gm-Gg: ASbGncvyzHYSoermK3iXaVC1Jvmt0exapB+EeEN1RCatqrYiN4Svkjq4WHiIF4a84n2 GIiN6cfbYlBW+mUxN0SpP/hn/azUlUaUi6DFwYKUd/+oKF/pbREYQLLLYVvzZJmTKb9XHdJk+S3 SPCdNdN4hHPRMUb2ke7F+APNEXYn98PxcHHI7Cx/nMXltvUrerSBnWPA== X-Google-Smtp-Source: AGHT+IHXMxRdHEpLNwHk6AW9YMkmhe48kPfZCCeKEJa453APw+EabP5sYxrj5QkjBiK0hzu5Bq35rNrOkUGz7pjkgqU= X-Received: by 2002:a17:907:724c:b0:aca:cde4:fac1 with SMTP id a640c23a62f3a-ad1906a9dd1mr678809666b.31.1746413006775; Sun, 04 May 2025 19:43:26 -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 From: Rick Macklem Date: Sun, 4 May 2025 19:43:15 -0700 X-Gm-Features: ATxdqUF9qQKLvwOv5UxT8W0Y4mKKCHEewMfUyPr4shC0pW6E2uo5f-4nNENuteA Message-ID: Subject: Oops, I broke the build and have reverted the commit To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4ZrQnZ1sVrz3xZR X-Spamd-Bar: / X-Spamd-Result: default: False [-0.02 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_LONG(0.98)[0.980]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[] Oops, sorry I broke the build. (I didn't realize that the nfsv4_pathconf structure was used in userland.) I have reverted the commit, so builds should be ok now. Pointy hat goes on me, rick From nobody Mon May 5 07:04:12 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 4ZrXZN6z6vz5v2pM for ; Mon, 05 May 2025 07:04:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZrXZN5n7jz3F8v for ; Mon, 05 May 2025 07:04:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746428652; 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; bh=iJUJsLLmNV9jiaztxGtZuq43ZclF8oXIQ3c/GkHPD0A=; b=F1rKS4IrZ+FVqFDAr5/4GaXVlOANKWjuPpdfLAbAJSW7wkrg2WIZJIUJAf7bcrO8/V03tW h3BImroDnbLt4iS79gjKy7UHwNzvd1oDoEDBaLNFdHyzk220vruhYGopW8zilIUltmh/iX 3cP99NghJ0usbHG/BHSilTrnlzZEZvCD4EXKFivV4pOE8gT7R48AujD1zN65WESSElEprM 9Bmewe01/JV4AuR/YTjY7W9YhHdnXKsqZEPSZxeIAptCilVuomlJDgL72yTVd3FzK+h2ex 9+CsJ6OmyJLO+UTJHY6BTE5E66GnGhykOoyffCaSsPVMrj3Eb9xqH7JgJSj7/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746428652; 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; bh=iJUJsLLmNV9jiaztxGtZuq43ZclF8oXIQ3c/GkHPD0A=; b=MqVLdfzVB09jii2ZTslrwIbwHeuBdz/K/Ge5vQaD6/aAdDPYcoqr+biM7M9Uz51Z6Ae/21 K0Eq+YzRu/1gw9OEWdBDFjumRybOfNq7MNziD6XH8/16tBbnh6fv3ad8dh0rO515AdOxPt 9KXKGf7y6wGaoEIuauiNLvP7aI+auSgZICqdGmAobD7qoZHw95LwFPxz+RL2BGUKmFNZnI xw1blRLIlb+zrVlRO2TZwHgzZ8HnxZxKhRInLLy5F55hfm62T3Zg4ZYEJ/luf4Efq/6PYA DWjs4tndcIMsFH4wRl+mkQwDgmsCiUGww304Et+h9wn/ZHKYHP3ihp8Jipy0sw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746428652; a=rsa-sha256; cv=none; b=VWtsAL1Jh7vreoIm4NYVSfc7//I75rELjqjyYWtEKeWduSdOFLiWUAza5w75ZRhNU33KBz mn/v2nioitd5v05sV9iXeKIsO9axGcPnuzGpV2M/WpsP65Wvtv2eGGf47w0x6YfvgitedY atbBiD15+UGNRrlaBu0HmQTxbrK11fdASe8saZtaL2Wx2oXsx8OSGiMiifX37WY+bBC987 3xMufW2ZqLN5xN5LTT8YlZb9wNoQXaXRUjmM5oGSa0aFec+MUbdlG3OG7baNh4/nrXyHss oHSTE/SK/LphybE+/3Byt0CAjkdKh4MKfvp0QFSUShzHsDZ9dD+ovTvEgfJw2A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ZrXZN55Qbz13hr for ; Mon, 05 May 2025 07:04:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 54574CHZ077941 for ; Mon, 5 May 2025 07:04:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 54574CtM077939 for current@FreeBSD.org; Mon, 5 May 2025 07:04:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken Date: Mon, 05 May 2025 07:04:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: agh@riseup.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285044 --- Comment #9 from Alastair Hogge --- Created attachment 260163 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D260163&action= =3Dedit 2025-05-05-15-CURRENT-794ee43e75066bfcbc00545b5bf600b9cda2d5f1-UEFI bootloa= der with misaligned ASCII art.png Remote IPMI session to a Supermicro H11SSL-i, booting in UEFI. The Supermic= ro host is booting 15-CURRENT[1] (2025-04-14 05:14:48 +0000). EFI boot is copi= ed from /boot/loader.efi. 1: https://cgit.freebsd.org./src/commit/?id=3D794ee43e75066bfcbc00545b5bf600b9= cda2d5f1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Mon May 5 13:12:02 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 4Zrhl42g4Xz5vV6Q; Mon, 05 May 2025 13:12:16 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4Zrhl33Yygz3ks9; Mon, 05 May 2025 13:12:15 +0000 (UTC) (envelope-from f0andrey@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=J3M1cYD3; spf=pass (mx1.freebsd.org: domain of f0andrey@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=f0andrey@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-ac2ab99e16eso39492366b.0; Mon, 05 May 2025 06:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746450734; x=1747055534; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=z8iKLjMmhYN5LqTl/9tj/4Qts4nT9jTBjSabTMbIcbM=; b=J3M1cYD3zAiQoi+3lB07vRgvqDhDM3VmGzhIMTVjLItLqcruY1VR4o5MwU5fzvypjF TIhNuGaDZ3S+AGfKkVLdbJgamhUepUHPnmx1QB/5/ZLZA5z5pldmAk3ski5Ox+gF0vvH boNpeqdG54Ah3zlt1iRsdDiH8pfIOSH7X/KGNgS/Bvf05HRgWL1ZrIPukBFAPeu8styG ebmzZ8caIdmt3lfDlmjA8RJqlm+r/DoMkDJNk0as62MMxRcKUsFuR/eiO34KB2MJRXnL pKXo0oh2ziN2d7JErSOeRwQ6y22MQOy9k70HBoxa2NyBKw5vg06o35GcYlVN5RRd2hCN 9FWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746450734; x=1747055534; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=z8iKLjMmhYN5LqTl/9tj/4Qts4nT9jTBjSabTMbIcbM=; b=d9ND615h6L5DEQUCusos/ZDDcmv+B5xGqwLGHQV1hkIR8qpSlon3OTZKEfrQPkmMPx qpUp9mUz0YuLH8bnqYeAas7a/+zteI/p126XboKTMUm3dqLbrlUF3nzt98KmBmQNwXs0 /X8J+tWpaylDuhiigzNUHYaekv1DROBx0jy+hjxXaGdMxX+nTEw1dcxmmX8QGTbThEo4 89ymE49tWGzy84SDtC3hvcsSuKMrLmbiym22lZPDNkKJjRhRDG8wNYXC+meMJy/Zo9Hh TyN8KMxm9SPKnqzivvt5eXYzX5tUfRofEyOOmdg2xAUfKd/Tis9n5Ofg6Mof/WhN8kNV tTtA== X-Forwarded-Encrypted: i=1; AJvYcCUqfX71jVYlIm8i3Sa2OnC4QwXivvufrwBY4paIBy1z8tfglMBmFyvtPQMA7vIyWek9H4g1ZbKPpkqEUpJ42/k=@freebsd.org X-Gm-Message-State: AOJu0YzERr1w6ANInufvCk8+FpiuR45VZuZW4BxWOXP/92nBtlfg2znK OEM0gJQ6dxH00GT0ONtibHKuLlEMvpcD7PiuWWbX0Rqy/4l5IAC50X/cExmkIBWe/eDwbJ+qORX zx9k7TeIiImWTJg2OpKItfnqRpfLyq/VEWp0= X-Gm-Gg: ASbGncuEM0DjDqG7IV7eNAa0Lb3J6Ejt/FhNwzRyIYN7RVqnEJACsoWVE9fXKOsUa8x jvi2uDgnONcURtwfpBqeaL0J3z/jYKQ9Oy7EQoMfS0vzAlc4WURFlibWNlVHIuXL52jAYxK4USo jpdUYXr2R58KsQVYTKRLF9n4qC3wAUXo5t X-Google-Smtp-Source: AGHT+IFourp3mqQEBDdFSZCB59jHdh4YUlk47lhDkL9G1kGgV5P8pWML6AeGXCluIjgIECyJPWrWVz6jz5UVNXt4QYg= X-Received: by 2002:a17:907:3fa3:b0:ace:c225:c723 with SMTP id a640c23a62f3a-ad1a48bc5efmr643324666b.12.1746450733489; Mon, 05 May 2025 06:12:13 -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 From: Andrey Fesenko Date: Mon, 5 May 2025 16:12:02 +0300 X-Gm-Features: ATxdqUH0Xrgq8zbGvcH6E27I6__aSA9uqepUYPfowQur6GtZGIsdOgsH7xS_gf8 Message-ID: Subject: netstat illegal option new exit code 64 FreeBSD-15-snapshot (fail cloud-init) To: freebsd-current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Zrhl33Yygz3ks9 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.24 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_MEDIUM(-0.25)[-0.248]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286576 Previous releases include 14.2 error code = 1 # netstat --route --numeric --extend netstat: illegal option -- - ... # echo $? 1 # uname -a FreeBSD free14.local 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64 In 15-Current exit code now 64, it's broke cloud-init (hardcode check exit code 1 https://github.com/canonical/cloud-init/issues/6206) # netstat --route --numeric --extend netstat: illegal option -- - ... # echo $? 64 # uname -a FreeBSD free15250410.local 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n276914-f676c13d4226: Thu May 1 05:11:20 UTC 2025 GENERIC amd64 From nobody Mon May 5 16:45: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 4ZrnTJ5Bggz5vkjH; Mon, 05 May 2025 16:45:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 4ZrnTH3c8gz3k5q; Mon, 05 May 2025 16:45:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-io1-f50.google.com with SMTP id ca18e2360f4ac-8613f456960so141543339f.1; Mon, 05 May 2025 09:45:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746463532; x=1747068332; 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=LzngWNJir0ESneIjrsHqCLCbmhb6IefxV7bZZW7TcEg=; b=NFVbr68DgH6COXbrAQmuM4GkGj9c7aOUg4WHyDO6vMT0MhYysDSfVdfRjKk817iZy7 HTPDSZ2OXxvAy7H28Pf8Q3cipL9mcCsX0Q6DUKSdYHsGKgkYdkSes+dY7pXwERmHAVqV aKXMfGCii9BJ+CUDru5vaWIBk0qDutk7+rMGJpQuoWo1X1N5IzzaHXnSh5J2VgQvDDKH phlzKcMuixE2YodkNnaRveoCvVud1tH1r2d9jPPfqWSnpoo+X0CutfMkVUHLTcwhpRWP Ur2Stj1QFB/dR+bK7QmoMFStkqHCSG3zbW4/i+wz7ma7+vSag0MTDCIfo+4YAJ4L5orc KNfA== X-Forwarded-Encrypted: i=1; AJvYcCUMOB9ZyqpJQRcPM794l+2qJt/rJQvDuSKSShe4S6o5Myik6dRAxkrUtOtozTwE+Ia+nJC/3I3UrUCieh8DJMY=@freebsd.org, AJvYcCVE+6ssk56A6Lnl+zJ/5vSOdB7tmd/RyxdPqcriR10F0JePuk22DJrCV0KKQbc17EY/ef/QNwU/P87Hp1w=@freebsd.org X-Gm-Message-State: AOJu0Ywz/V/eLWc46cLifLBwpgoOKtBW2ED2u9sLDZcphgInzn3YZpPV YnXTiK2YNyzNWIlSHOwB23/i8f9rVVdBbv8Ba86zqPW33N165EUdZ3Ze+3RWKp2iVV0FSGc3yge 9dU4wAHX+af4pQOgY+LxNTlogDwM= X-Gm-Gg: ASbGncsO4glbB8RG3BTli7g8WrdzmCoxWuJJr0mTsX9F4l1381AB37nOJ48TU32xjEq bOnYVfvYsGNiUyAndJvJW3IKucYHd3fpGbedAbeOhUp1yCMcENWDthMBtZd6pqvC5s9eTVZKs2k A1n0uBJvPPNdQXA/3zTMM81/0GaTFqM0otkiX+QngtiNmWE+iZlGCj66hvjc88HYblxww= X-Google-Smtp-Source: AGHT+IGZaRqgoAkoxnVYejmku4ppLI/qEtOCx1WCuA7O77H8ejJL5Tk+cfDwalG39OcWQ31wSosRSbacAtyP0knSYg8= X-Received: by 2002:a05:6602:3f82:b0:85b:577b:37c9 with SMTP id ca18e2360f4ac-86713baa166mr734812939f.12.1746463532588; Mon, 05 May 2025 09:45:32 -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: <20250504045938.71917AE@slippy.cwsent.com> In-Reply-To: From: Ed Maste Date: Mon, 5 May 2025 12:45:19 -0400 X-Gm-Features: ATxdqUHmcpLoTaozITA7IaXsg_RsZPG5ECBdnK7_eYB3yA3fU7OcSAGeNkGkb_g Message-ID: Subject: Re: pkg: invalid option --, and pkg: illegal option -- To: Kevin Oberman Cc: Cy Schubert , freebsd-pkg@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4ZrnTH3c8gz3k5q X-Spamd-Bar: / X-Spamd-Result: default: False [0.73 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.93)[-0.929]; NEURAL_SPAM_MEDIUM(0.56)[0.557]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[carpeddiem]; TO_DN_SOME(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.50:from]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MLMMJ_DEST(0.00)[freebsd-pkg@freebsd.org,freebsd-current@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.50:from] On Sun, 4 May 2025 at 02:13, Kevin Oberman wrote: > > It is definitely be61deae0aa2 and it is cosmetic. be61deae0aa2 changes t= he parser in the base system. It results in all options generating the erro= r, but they are passed to the sub-program (info, version, delete, etc), so = they are just annoying. As I mentioned, "alias pkg /usr/local/sbin/pkg" wor= ks around the issue. Hopefully it will be resolved soon. Apologies for the breakage and thanks for providing these details and workaround for folks. I've now merged Isaac's fix (73ba568b1c35aabc1682540b5b4d5d77220c5468). From nobody Mon May 5 20:34:57 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 4ZrtZ55M4xz5tnf1 for ; Mon, 05 May 2025 20:35:09 +0000 (UTC) (envelope-from eduardo@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 4ZrtZ54hKsz3V9R for ; Mon, 05 May 2025 20:35:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746477309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=0mntuEILvJlG+gB8H2/FrCmXKVMOUANj8dDjqh+fyPE=; b=Tls4uatHI+YdcRPVjRULlfv5A6NAqmH3W4xUgktAQQWha+6ZEhY1ZYcQ3k26f02UfQ9Iws 33ywtiMBZ5b97BH/pkFM7Q+1sziRLhibwKtEbBvrV6mEcKB3NZemQp36WSDAVNWDfEWf9s EwL8vs2bccK+WeaSViQGgHN0g32Jp7vGoy/2J1YiS+frLpmjv7b7dvlKdUiRUpy2nnDI+R B9VcMSp1J9nBLExftL/3d5DELDujPPBsaKjDf8N32r6DLHlK7OkotCF0vxufpV32yIAZ0U YuEppgfOg4AegLzXnuVa50QMWkjxmE9wXSp/IZhlkvxNxmM0ZTIdyIUtTZMv2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746477309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=0mntuEILvJlG+gB8H2/FrCmXKVMOUANj8dDjqh+fyPE=; b=u6yqMy8qfVvpH2lhLpughsc+1PcAh/AGu0p87vuQ12cc4AVJdJ7an3cPL/VkMhXnGpZspP 4iHNvdbx5NIFITrOhb08DPDh5xv/AVoXWihHKWklBMZyAp8w+K5nNkySLg/3HeIZmzLpNE uqZqgo2dpaV6RXZkakwBPjlhXXp1Co4JC1cSW6yDMOsmD6PfIT5WTjQ8jRUEFIq8qQ3gtb tvB091WKytXnFyVCHZJLW1uvnZlv165FUJOjz9k0mSWThoNTlAPOp6c80NGixyiFVFOt1d tbTUpcYib3gRunqFnzRGvTVY1OEnePx1KEz4f+ngSvJBM0JiGO6x7882unzM8w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746477309; a=rsa-sha256; cv=none; b=fhmHLPOsTaC7KJY4V0kG0v+KLDur4l7H660LCgEtbG7H0TqrgxjQtR6zcca7s2IGQ8gdg9 34eEdJTNcKC4egGZyMofbt+ILAQEim0Xjo//Q2Ftu10+CmU0QFhbcwhLCtmaYXFXxFOa5E GnLIHGybNWcUj5ejCiUd8830wdZvpVeis4affrrq+xHjjdfNveT7K79wW2f8OKc9eUw1B3 HowWt79jpWu93xdv6tXlPaj5SKknm2PBbW3rLMSQtyS8x0mgvOf0wrGX0TqaC/mAdMM+np amhuDCb7mdoB4S89XaZbSqiChqkXI7pTKyM6vwoZYM9v9d3MkT/Xlm18DNiQ9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZrtZ53w2pzCKm for ; Mon, 05 May 2025 20:35:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-7c964e8710eso31325585a.0 for ; Mon, 05 May 2025 13:35:09 -0700 (PDT) X-Gm-Message-State: AOJu0YxjIzVjQUKB3e0PPOYleSSyyi+qFPj4wYCh/v9aAI+2yLdC8FWJ iCSetCwNec66Avlaubx4dTMdz2s/gSUNBeKOClmo6CPAzZTnwZRkJUu4KqBQlZBlTHkXRQUFYHs QjFDaJTf6DTZzVdpB39vyS0qruR0= X-Google-Smtp-Source: AGHT+IEwDM4yj1ygSjxVaIn08Xe7ATucXounXsqON2SuNlkplBoh4Ro0cEl/3ANZM6WuIqoBpymHxlA5jkmZxYTEspM= X-Received: by 2002:a05:622a:354:b0:475:876:ac3d with SMTP id d75a77b69052e-48c331c7062mr81203001cf.13.1746477309200; Mon, 05 May 2025 13:35:09 -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 From: Nuno Teixeira Date: Mon, 5 May 2025 21:34:57 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUGdwKltuhMR-vsM9UNFPZrd_-ifpxFF4DBqCQIrlT4af_0TryIVgnSfJTI Message-ID: Subject: incremental bulds from scratch with beinstall.sh To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="0000000000009f8e030634696f65" --0000000000009f8e030634696f65 Content-Type: text/plain; charset="UTF-8" Hello, Using incremental WITH_META_MODE builds, after installation with beinstall.sh, building same src, a complete compilation happens. If someone uses this script, could you please do the following test: WITH_META_MODE=yes (/etc/src-env.conf) filemon module loaded # cd /usr/src # make buildworld-jobs buildkernel-jobs # ./tools/build/beinstall.sh # reboot # cd /usr/src # make buildworld-jobs buildkernel-jobs Since src and obj are the same from one BE to newer BE, minimal compilation should happen, not a full one. Am I missing something here? Thanks in advance, -- Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --0000000000009f8e030634696f65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Using incre= mental WITH_META_MODE builds, after installation with beinstall.sh, buildin= g same src, a complete compilation happens.

If som= eone uses this script, could you please do the following test:

WITH_META_MODE=3Dyes (/etc/src-env.conf)
filemon module= loaded

# cd /usr/src
# make buildwo= rld-jobs buildkernel-jobs
# ./tools/build/beinstall.sh
# rebo= ot

# cd /usr/src
# make buildworld-jobs buildke= rnel-jobs

Since src and obj are the same from = one BE to newer BE, minimal compilation should happen, not a full one.
<= br>
Am I missing something here?

Thanks in adva= nce,

--
Nuno Teixeira
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--0000000000009f8e030634696f65-- From nobody Mon May 5 20:37: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 4Zrtcd6wbvz5tnmV for ; Mon, 05 May 2025 20:37:21 +0000 (UTC) (envelope-from eduardo@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 4Zrtcd6RcPz3WPq for ; Mon, 05 May 2025 20:37:21 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746477441; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZAOYo55k0ssfsRsvdOAIjdW03+GdnA1mBvBawdbcOBQ=; b=u7T20R3SmVpWOpqKbZMyz3SYjsJvGACN1XdBjkqTBtuSgF+W//rrUw8uzl6XIibUEBqam7 +i59FYMHuA+BwFO0zQG16N5Lc8ui/SZjtBE5gkgM4racJGDt2EAch2rmDks04M7reVN+l+ mlgnMLstauVSDr5zmPsDEesW+FVWe/6stPl1sR4M5p3ISGLfGkcaphNIdnobFQvpyXccuz iPCB/aJFObdGyYP8cSi2A/ToUuw3YUbJJSkZEANlW2jpnmP+U79ZEoePMqZLLLD1fypfFq y+NCqp8A17Gq0xSAnJnJaFwhLW7QRAJQC6WxFjR2SDwSB/nYxP5oybkpm1iYEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746477441; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZAOYo55k0ssfsRsvdOAIjdW03+GdnA1mBvBawdbcOBQ=; b=E1d1XmhyfjRbZdLhk6aqJ2iJ48Fs0tQCSOVzLI0CAL2pCj1RFnmxNmOeXZBc/IvVqGneQm QKKokZciA79RRKR+izsKcJmvdZMq17CJAtE4X4fbCm2PjurOauqbGPE4bRJjdy4dlDduZU n04BOHACjtaq+bv6a+RwJvv08aaysIeFPnxoDqaspO2ZFDv5ec1speHJzHSQvTW91ffBHV XHmT6cePVPsRF4J1TwiY2BPmiwizW2/t/PV2MZgXWVHoOVwPE1T/o4JsBoBNGpxIR8SzHD fvbyoeT0mY0NjCMqszEU6Bqdl96nYgZWdDL8A24O0+d8o5c1utQIjdbcDASQkA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746477441; a=rsa-sha256; cv=none; b=FyrrcS/g/EUQ3H2b7EVBGs51Fd9G18p9fGmtK8k7z0pHVSEiFPEo9uVMExoN8xumFboRTa TkwbT5v7LY7MDHU/UoseB2Jng9VwFyteyUoCmUbzmF2UJAx721NkXKQh3ayWL5p56BpASB jOf3NydY3qHMdga7oZqU+8PVwOwU6iwxTYXDVCFc+XawiO5pxjedZ0Ibgpyvq7ARaTFeln viNM+oNfCYk4p1FIxZEBq2q2f2eClRMrsILsgE0fLDk+l4vrEx6OWAc/M2cQgWb5oqGvt8 F98IF+QYftW3N/mqdSVzu5wjeL5fxtWTpkA6cQLmz/ard7BW4nYcbpEYr/8tFw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zrtcd5cD4zCKn for ; Mon, 05 May 2025 20:37:21 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6e8f9c5b09dso5410816d6.0 for ; Mon, 05 May 2025 13:37:21 -0700 (PDT) X-Gm-Message-State: AOJu0YwKQ9ai6zDE22zOqABMq4Yn4c13wuydSXcQldxo6+JIOBZQD0W1 w0sv0qmv+qlRY3K1LgVdNTPbnGwB+4eZ54klRjsfpbUPUJoy7t7Ep8+lrNo91r+S3QE+dXwxY4F f2OQNb2YiQbjd8M6HhoEMtIlsJ/o= X-Google-Smtp-Source: AGHT+IEmFKGrbvCpmuLBw2yVNf+Jm/ZMeRJnWeDiH7tq0gtB1u5GirVG5I1ZQ1tAyeR1K5SN/htRqWkJ2a7PdRehPKg= X-Received: by 2002:a05:6214:2129:b0:6d8:e6be:50fc with SMTP id 6a1803df08f44-6f5155e9fb7mr79811926d6.6.1746477441306; Mon, 05 May 2025 13:37:21 -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: Nuno Teixeira Date: Mon, 5 May 2025 21:37:09 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUG6WnIEu26SzdgvQOYshf2YCPCY2-HvA631bSf-b9r6bYe2BGXYL7NS0nY Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="0000000000007f5a910634697743" --0000000000007f5a910634697743 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess with ports and stuff. Nuno Teixeira escreveu (segunda, 5/05/2025 =C3=A0(s) 21:34): > Hello, > > Using incremental WITH_META_MODE builds, after installation with > beinstall.sh, building same src, a complete compilation happens. > > If someone uses this script, could you please do the following test: > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > filemon module loaded > > # cd /usr/src > # make buildworld-jobs buildkernel-jobs > # ./tools/build/beinstall.sh > # reboot > > # cd /usr/src > # make buildworld-jobs buildkernel-jobs > > Since src and obj are the same from one BE to newer BE, minimal > compilation should happen, not a full one. > > Am I missing something here? > > Thanks in advance, > > -- > Nuno Teixeira > FreeBSD UNIX: Web: https://FreeBSD.org > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --0000000000007f5a910634697743 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)

Don't forget to `e= nv NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess with ports and stuff.

Nuno Teixeira <eduardo@freebsd.org> escreveu (segunda, 5/05/2025 =C3=A0(s) 21= :34):
Hello,

Using incremental W= ITH_META_MODE builds, after installation with beinstall.sh, building same s= rc, a complete compilation happens.

If someone use= s this script, could you please do the following test:

WI= TH_META_MODE=3Dyes (/etc/src-env.conf)
filemon module loaded<= br>

# cd /usr/src
# make buildworld-jobs= buildkernel-jobs
# ./tools/build/beinstall.sh
# reboot
# cd /usr/src
# make buildworld-jobs buildkernel-job= s

Since src and obj are the same from one BE t= o newer BE, minimal compilation should happen, not a full one.

Am I missing something here?

Thanks in advance,

--
=
Nuno Teixeira
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org


--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--0000000000007f5a910634697743-- From nobody Mon May 5 22:18: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 4Zrwst4qwhz5twds for ; Mon, 05 May 2025 22:18:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4Zrwsr2d9wz3wQq for ; Mon, 05 May 2025 22:18:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="cMY8/3AW"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746483533; bh=hCURL8pqavLKH9zH+EwfxNLPc3Z75wpsIbje8E4QCRQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=cMY8/3AWwaYxfrOOq6fNxoS8764C7VOr46iHqy8XoC7wJ2qGTbQac+rn1n22m7Y8HWdNT/V760QNOttI7Iu1vr0t+sqTwv+58Ixy9CV95ag+JpIGdAG91JlA/1D/sn3u9iYTzfCQ9FTcs7BJEQ9gQwtqbq8Kku1tZ6sC3o64Vx9+qnBfNd1se5PwtTs93duquigDy97Yqea6GxW7C2/ERx46buL6d1rj6f/Tp8hKaPBuG4F6n42Q6J+dPLHU0tCvX5uJu8xZ4wHPCp50gGDH4Evst7yNEgzo3nrWR0yNzXtbZQQM7N68RzQU0DpdD6R5Gf6JMK/ribwUdnRUng9Dnw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746483533; bh=FBx1PzIDx8DY566R/5SibAKwCSGNxRdAbIJd+8cbtmt=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=E/loagzNsm/IOCLv+dlOm7yh6yVu5yCgyYK7nBRAN5IcwDM0nZ9g2t5RYJIeLLy+hTFsU17yFxSue3Vg6FymKjGigV3zij2K7Bkbq1rxIkd1qBUmcLW/GEG4r65b+My1hTO81xFrjlhDkH6LfxOrD56G6ZOvm/NnSO1NSr0DCdqlK0NtcdKymXPOYISMv4GpmD/CmMlo+8Eb26M8fpPFI0gfQGeJrJumHDHvSFZ24+0tQw6YoFI1nqXkYNiphOdSyQpK8kQDNNvhQFK4+AG/8le/XOhXlvYyBjANwlNQCq+zE1qpaPTzRF7Gv+E7sJ2h92mB8N4lsJO9i53AQfQHeQ== X-YMail-OSG: ABsNMfwVM1lXMygKbVsXsqciqFeTEQd6AePPECEzDfqvvVu9amiqbzQijUrrx.h EMFAOSus3v1mBy7pM.9Fhp9APOzx6qRVqkAv3Su7BZ2UDELCPJDAYduxWJqeU8xuVjw7n9QxC9B8 Jt71cUZBMangOVfzQQ8wZMfVYJ9hjKrdsHvY_8EF4m8e_G6fmX3DMJVHwn09sn.RP0NGhLJdQdZi E_46Wo0Ax3KWZN.6UlsI.iC42UXkqg2CMMrvAk2U_FWWHaxby8Ul_2laKb_46Rn3CHNAqxZAMjLY ClWb_bRzOesIDBgxtx7yeklNM3qjs8Ptm5ZS1qFD4iiu5lhCAF7b.DtIz2GICnlExcD6kxpllfzW BUXcQB4WJ7NTUAS63dg4z5rVINEKW6Ut7Jz06oDE_JxXEXux7kkb_uCZNHf3nv.p6qAkZ4Z3VR_J QtByzhRQZe.pdoorSvrvEy6mh6a9rmUySyUDtjBVicZ5SExbMY2pbzxTQuMaRDMmsAK7bKTpb0Pn bzFMrv0OgHi1QIy6B93vKkInzqQ1gHHmuHFIDZVA9iVgAVVvJs7aGPXAlcbMu.WICfE5.r2h4Jju j2ov6pXZy99VLO.C.IaJ_3QP61vxl0.arJBeY2Pt2bCAxW3UGE3M7Of.LT8JgadJHjcMiKxJlamN D153Su5slOO.hp.Tko_FcCgssvTaa5bmNBVbvEsQ9myidzoJXuyvp.__cc1g6vucer1aZr1GhqFN YsreFUHmSZr6Q6EfCDKgu.MTmDdNgPlR2lStem0ujjGAm4MT40Ra1VydoIUpWpoxZSbtX31MiMCN j5gA4NjeR8UeyGEU0P.0o4MmMH44wj6BcYsuas_9dj.oXPwTP9_khrL4NdIYrB8vnhV8VHRxz95h zNcub.CbHJaRNSfyl.yt2lPOZxr2H2_a.Qfb28rMm29t4Gn92qHUa2EzoqglfOuMFt5kpxKx_jzz 8kHQnwaKl_c.X4fOZNIj6CctVJIJKYTP97GY5Ax8KTxmXxLn3q681D8HCvVG7fSvXFinqbirJju_ BwGGhNx2ITmVhv1k0LQmw6y2xpacu4YyO_HMbqtbTEG9UM2oK.H5nZ53cqZOaURf0tcrBabPj8Rl S6esytPpmMuPMtA1unzIPrOKdFomMpwxu82LjeyzrTyH9oRTx6Xls11MZTof_vYLTpokM95tRIB_ xXN4mWgW_XvahNihy0RxFjg.Rx6mnYuEXG1PBRG2b7dCXhNMGUNjwpQsPheSMLHlV18sK9tW2ClR Vy0ehrOUWQOh4p1BMD_69MasX8JBgkbxvD29O25KXr.AzmEmxrqM2uIVEmCqWKvZuwYIFseiIXC4 DE646Ro8dRpCqUiLhJ2uiJuaZ_iyAwgnUuH8s0z0A4WZOMLmIZJM_PYZM0jXE4AHSMuL4aIx.Fva bOlbf.3l23uXO996sHMKJmMXUQ14tcMaJ09AEbnuo_KNe3K0Jr2_zpBe0na5Y3kINMh7AWXXGwJj Fj2Oe6k34iO_iGslR8ATtMJ_b5cGAcgHoj514sIQorlqIUdI48zTRYc1t5m61SSoR7_VutKMJCVt r8Gzq9G0WG1DPFYGshFsCRLC6S8.C_TaDMfVo7GfHh8oljT1xXNetu8zpG5RHTu8DtPJJ0ZeepH4 QjJkewC0tyycr8i35jYuEg_QlvB6Vg_1.cMlYa6fP9tQeqvGPAiEbgLmMFNDp1wd2WVzosci3f_b TYGlqV2u9U5j9rLNUCkhPlrIEa2BPhqak5Cm8fFqWsubQ1d_1NKPlWZ9_C5DoVYiBYpleD2HkwFp iAkCFeELUV8Li4J2jhwrkxPqKXpYQ5UrITYEJEYkIynMwAYp6PvtHmVkQBa7UfpwA6L_W.BoBT2e pfEDcFO0vDDsaWTiRwUFfBtD7LyhEFglFK.HjxFKa_salPptzwouwc9NaBgkQSsDZ28JVtb53A35 2QqPybnDiF1cB2I6wW3UPLYsXd6jP97bToF0hkh4Q5TZBLpCWSBzyABEoZpHuI84aMScxJk18GA2 Mx4n7b9CxA.tTONKIroz4SutC6rPUJrRUIoD_3.zZCCXraxvLoCH32lawbjfFoyDCkrRQkI9gI4t Q0x4ddQSJ0ZBi4ng0pc2iuGUMLYwy0cmrEcfsnxqqY3wDY6wWinp2OuZvPuP9aC_4D7TQqB3VibB KUQbdAvKv2Fyf2Rcnr726xvBtIOkMoNQPhYl0WGOneEmmOVtKxAWiqdKUn4qS6ZfwpG2zO0JMSLB WfA80sXd5my360Fdl8mLIP59boWvYXX7PRt6w.4ruuBnjYJtmO1ker4.OPjnIjvp.DgpMkop3.p8 Tkmbi X-Sonic-MF: X-Sonic-ID: e1078256-88cd-4fbd-90a5-761e903bbe98 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 May 2025 22:18:53 +0000 Received: by hermes--production-gq1-74d64bb7d7-x7xzm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e593cfe36692bc8df760ecc5e898ada0; Mon, 05 May 2025 22:18:50 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 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: Re: incremental bulds from scratch with beinstall.sh Message-Id: <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> Date: Mon, 5 May 2025 15:18:39 -0700 To: Nuno Teixeira , FreeBSD Current X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> X-Rspamd-Queue-Id: 4Zrwsr2d9wz3wQq X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; NEURAL_HAM_LONG(-0.78)[-0.784]; 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]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; 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]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; 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.31:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from] Nuno Teixeira wrote on Date: Mon, 05 May 2025 20:37:09 UTC : > (...) >=20 > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess = with > ports and stuff. >=20 > Nuno Teixeira escreveu (segunda, 5/05/2025 =C3=A0(= s) > 21:34): >=20 > > Hello, > > > > Using incremental WITH_META_MODE builds, after installation with > > beinstall.sh, building same src, a complete compilation happens. > > > > If someone uses this script, could you please do the following test: > > > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > > filemon module loaded > > > > # cd /usr/src > > # make buildworld-jobs buildkernel-jobs The above used older commands and files from before the following install. META_MODE recorded the use of those commands. Example .meta mode file content: # Meta data file = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/li= bc++.a.meta CMD @echo building static c++ library CMD @rm -f libc++.a CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o = charconv.o chrono.o condition_variable.o condition_variable_destructor.o = debug.o exception.o filesystem/directory_iterator.o filesyste m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o = ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o = optional.o random.o random_shuffle.o regex.o shared_mutex.o stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o = utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o = cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o = cxxrt_libelftc_dem_g nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o = cxxrt_typeinfo.o CWD = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++ TARGET libc++.a -- command output -- building static c++ library -- filemon acquired metadata -- # filemon version 5 # Target pid 22471 # Start 1611359217.214996 V 5 E 22961 /bin/sh R 22961 /etc/libmap.conf R 22961 /var/run/ld-elf.so.hints R 22961 /lib/libedit.so.7 R 22961 /lib/libc.so.7 R 22961 /lib/libncursesw.so.9 R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE F 22961 22962 E 22962 = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/rm R 22962 /etc/libmap.conf R 22962 /var/run/ld-elf.so.hints R 22962 /lib/libc.so.7 R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE D 22962 libc++.a X 22962 0 0 . . . So META_MODE has lots of files that were used that it can later detect being newer than the prior build results, leading to rebuilds based on those newer files. > > # ./tools/build/beinstall.sh The new be will have various updated files that could be different by content and, for commands, could behave differently than those used to do the prior build. Detecting newer time stamps on such used files leads to rebuild activity. More than /usr/src/ and /usr/obj/ content are involved as well. Note that the new be is based on somewhat different files than the original buildworld-jobs buildkernel-jobs was based on. > > # reboot > > (I presume booting into the new be here.) > > # cd /usr/src > > # make buildworld-jobs buildkernel-jobs META_MODE will notice when commands are used that are newer than when the prior build was done. Similarly for other files that may be read. It will make sure that the newer commands and files are allowed to produce new results that potentially could be distinct in content from what the old context produced for results. > > > > Since src and obj are the same from one BE to newer BE, minimal > > compilation should happen, not a full one. META_MODE is more careful than that. Note: I'm not claiming that new behavior that is needed is likely for lots of the files with new dates. But META_MODE is biased to avoiding leaving in place something that should have been updated. > > > > Am I missing something here? > > Note that make has a -dM option: M Print debugging information about =E2=80=9Cmeta=E2=80= =9D mode decisions about targets. So, for example, file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk' is newer than the target... file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cap_mkdb' is newer than the target... file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cat' is newer than the target... file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cp' is newer than the target... file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchgen' is newer than the target... file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchide' is newer than the target... file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/dd' is newer than the target... . . . Various . . ./tmp/legacy/. . ./*bin/ actually were links to files. Ultimately buildworld then installworld lead to new dates for a bunch of files used. Later use of META_MODE notices such and rebuilds based on the newer files. (It is a lot of detail to go through it all.) Back in 2021 and 2023 I got help with exploring avoiding lots of these. But, in the end, it involved use of experimental code in share/mk/src.sys.obj.mk to provide a new definition to use to build some paths with. The experiments were an unsupported activity that produced an unsupported change to allow configurable enabling of taking risks with not updating files that possibly should be updated. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon May 5 22:36: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 4ZrxGF6gW2z5txqs for ; Mon, 05 May 2025 22:36:37 +0000 (UTC) (envelope-from eduardo@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 4ZrxGF3y7Mz3JNX for ; Mon, 05 May 2025 22:36:37 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746484597; 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=k/Xo+XiSR3eBsqXxrPWrmDo+FFICEDS8EN5gpX7e9Sw=; b=JxtuqoLfc9Lkx2hu73gCAcR7en9ImGNOE1Pc7aFxivExRF8HANy34ZzlnRnR+GOuaH4hIw zGHPTOT/HRFqMDPc8xObMDv+L+TBqGT+GrGJWkJCYlhce7xzvs5pfKpuVeqXdtfvwfyvv0 Z2KlfsGdQmO1olpkNOvkVwSgUqBqbOFbTVD2Rr95MWPjOeFZmAq+Gd9FV3ja2+aB0VXBgg qpmhfr473G5v0sCz79aZMAfLltis5gAsdD9dBBMK2+vJejE6q8/85AfaoKyX3hdZMvctlF JxQTNCCXjp/J7NZCXCUGFPkgLp2OxatVcajv87oKDd057TxTRCLrZ3LwQ+cdZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746484597; 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=k/Xo+XiSR3eBsqXxrPWrmDo+FFICEDS8EN5gpX7e9Sw=; b=CSGLC1lcgqRQi5WaeGlBJ7frkdUdY/vq/1d/wCY7VJz/AhCaUnCHahSmM3Pb0GFbXhGQhA rHU5fwMKdCojPPwkr22wh2tZfEQwIxDru568GBdgQEQjUWjQlLn4+yOlBTbgROOx0rKAvp 0QQ0P9Ua9ZQxRGhPP/7k7mMFhryQ/tDReyyaQNCQXmBRpIGvWBqseLpDKbvrNjV9CzBNgY EcEH3zucedlePcUBcbeYFacW5k7sHNd07flQ/6wU6EJwsDyufJ6fSk9rhqVT+EGq3IkpqL VL2b595su9xj9APJTinMvAKD1VhqvJmxakl/4lTz3I39X3c1v3CyaRB7MYfi9A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746484597; a=rsa-sha256; cv=none; b=gfFw57j0yhmSoAZJ15F8hy1pvc/eKOIP+ENytXWHekWOh1D5e0JhySSzUEiEJZTidhGWmp 8Z6I71ypupsZChIIzzMbkapkogg7D17uW5OzvN5L9pZD90Ea23bZTF0hAwJg3NXb0goDgW zubUF8uPhDYoKPV/Lxio+f0e+DlfRQzyXS7RTg+g8r4pleMIgR16vk39tJQMxzNXn+2iaF Gwg0mc0q+KzQRCxy2AEzMWsGxgMfNbrPbjlDRmzuegFnrQlYEsS4dou9iA/A+xMa85atjL EfQDRiGRZ5j6gTKXo/XGQ29gdJ3LO+oGVHfy1eit/3jibFgeAbCl1ktDKVJz2g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZrxGF339SzFYF for ; Mon, 05 May 2025 22:36:37 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-7c5f20d512fso69490385a.2 for ; Mon, 05 May 2025 15:36:37 -0700 (PDT) X-Gm-Message-State: AOJu0Yxk7QUit9boYswFYU+djGmobdnLGuYxdhbhLNbkC1W8USOlBh6Q vYaPtD8ErjaYmcNpmfZ6d9IHMXIv8HpLhv4D7HdGVyaExFl9LpaYYYQ1GvjI3WVh477fnWm+4gD fcNcBk+8qIMJVJzwpXAE+tRpI8Uw= X-Google-Smtp-Source: AGHT+IGFPb3gGKwPqXUWaC8XTF4bEKLENJ3+OeoSOsfd5lIHA8NRFTBOqXkLtObC2Xm0I+9ckkpbNOwSlO1K45Y2OgM= X-Received: by 2002:a05:622a:14d4:b0:475:820:9f6f with SMTP id d75a77b69052e-48c3192cea7mr84163121cf.9.1746484596871; Mon, 05 May 2025 15:36:36 -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: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> In-Reply-To: <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> From: Nuno Teixeira Date: Mon, 5 May 2025 23:36:25 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUFIR1OQ2IX0GZJCZljEratMjChQjHQi3i6v8Z-9K956HDUEQ_G7TAVOldo Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: Mark Millard Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000000972606346b224b" --00000000000000972606346b224b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mark, Minutes ago I used a more tradicional way: # make buildworld-jobs buildkernel-jobs ``` RELEASE=3DWhatever > bectl create ${RELEASE} > bectl mount ${RELEASE} BASEDIR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl mount > make DESTDIR=3D${BASEDIR} installkernel > etcupdate -p -D ${BASEDIR} > make DESTDIR=3D${BASEDIR} installworld > etcupdate -D ${BASEDIR} > bectl activate ${RELEASE} > reboot ``` # make buildworld-jobs[1] buildkernel-jobs[2] [1] did not compile [2] compiled # make buildworld-jobs[1] buildkernel-jobs[2] [1] did not compile [2] did not compile Cheers, Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s) 23:= 18): > Nuno Teixeira wrote on > Date: Mon, 05 May 2025 20:37:09 UTC : > > > (...) > > > > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess wit= h > > ports and stuff. > > > > Nuno Teixeira escreveu (segunda, 5/05/2025 =C3=A0= (s) > > 21:34): > > > > > Hello, > > > > > > Using incremental WITH_META_MODE builds, after installation with > > > beinstall.sh, building same src, a complete compilation happens. > > > > > > If someone uses this script, could you please do the following test: > > > > > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > > > filemon module loaded > > > > > > # cd /usr/src > > > # make buildworld-jobs buildkernel-jobs > > The above used older commands and files from before > the following install. META_MODE recorded the use of > those commands. > > Example .meta mode file content: > > # Meta data file > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/l= ibc++.a.meta > CMD @echo building static c++ library > CMD @rm -f libc++.a > CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o > charconv.o chrono.o condition_variable.o condition_variable_destructor.o > debug.o exception.o filesystem/directory_iterator.o filesyste > m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o > ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o > optional.o random.o random_shuffle.o regex.o shared_mutex.o > stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o > utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o > cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g > nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o > CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc= ++ > TARGET libc++.a > -- command output -- > building static c++ library > > -- filemon acquired metadata -- > # filemon version 5 > # Target pid 22471 > # Start 1611359217.214996 > V 5 > E 22961 /bin/sh > R 22961 /etc/libmap.conf > R 22961 /var/run/ld-elf.so.hints > R 22961 /lib/libedit.so.7 > R 22961 /lib/libc.so.7 > R 22961 /lib/libncursesw.so.9 > R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > F 22961 22962 > E 22962 > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/rm > R 22962 /etc/libmap.conf > R 22962 /var/run/ld-elf.so.hints > R 22962 /lib/libc.so.7 > R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE > D 22962 libc++.a > X 22962 0 0 > . . . > > So META_MODE has lots of files that were used > that it can later detect being newer than the > prior build results, leading to rebuilds based > on those newer files. > > > > # ./tools/build/beinstall.sh > > The new be will have various updated files > that could be different by content and, for > commands, could behave differently than those > used to do the prior build. Detecting newer > time stamps on such used files leads to > rebuild activity. > > More than /usr/src/ and /usr/obj/ content > are involved as well. > > Note that the new be is based on somewhat > different files than the original > buildworld-jobs buildkernel-jobs was based > on. > > > > # reboot > > > > > (I presume booting into the new be here.) > > > > # cd /usr/src > > > # make buildworld-jobs buildkernel-jobs > > META_MODE will notice when commands are used > that are newer than when the prior build was > done. Similarly for other files that may be > read. It will make sure that the newer commands > and files are allowed to produce new results > that potentially could be distinct in content > from what the old context produced for results. > > > > > > > Since src and obj are the same from one BE to newer BE, minimal > > > compilation should happen, not a full one. > > META_MODE is more careful than that. > > Note: I'm not claiming that new behavior that is > needed is likely for lots of the files with new > dates. But META_MODE is biased to avoiding leaving > in place something that should have been updated. > > > > > > > Am I missing something here? > > > > > Note that make has a -dM option: > > M Print debugging information about =E2=80=9Cmeta=E2= =80=9D mode > decisions > about targets. > > So, for example, > > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/awk' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cap_mkdb' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cat' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cp' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchgen' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchide' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/dd' > is newer than the target... > . . . > > Various . . ./tmp/legacy/. . ./*bin/ actually were > links to files. > > Ultimately buildworld then installworld lead to new > dates for a bunch of files used. Later use of > META_MODE notices such and rebuilds based on the > newer files. (It is a lot of detail to go through > it all.) > > Back in 2021 and 2023 I got help with exploring > avoiding lots of these. But, in the end, it > involved use of experimental code in > share/mk/src.sys.obj.mk to provide a new > definition to use to build some paths with. > > The experiments were an unsupported activity that > produced an unsupported change to allow > configurable enabling of taking risks with not > updating files that possibly should be updated. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --00000000000000972606346b224b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mark,

Minutes ago I us= ed a more tradicional way:

# make buildworld-j= obs buildkernel-jobs

```
RELEASE=3DWhate= ver
> bectl create ${RELEASE}
> bectl mount ${RELEASE}
BASED= IR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl mount

&g= t; make DESTDIR=3D${BASEDIR} installkernel
> etcupdate -p -D ${BASEDI= R}
> make DESTDIR=3D${BASEDIR} installworld
> etcupdate -D ${BA= SEDIR}
> bectl activate ${RELEASE}
> reboot
```
=

# make buildworld-jobs[1] buildkernel-jobs[2]
[1] did not compile
[2] compiled

# make buildw= orld-jobs[1] buildkernel-jobs[2]
[1] did not compile
[2] did not compile

Cheers,

Mark Millard <marklmi@yahoo.com<= /a>> escreveu (segunda, 5/05/2025 =C3=A0(s) 23:18):
Nuno Teixeira <eduardo_at_fre= ebsd.org> wrote on
Date: Mon, 05 May 2025 20:37:09 UTC :

> (...)
>
> Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mes= s with
> ports and stuff.
>
> Nuno Teixeira <eduardo@freebsd.org> escreveu (segunda, 5/05/2025 =C3=A0(s)
> 21:34):
>
> > Hello,
> >
> > Using incremental WITH_META_MODE builds, after installation with<= br> > > beinstall.sh, building same src, a complete compilation happens.<= br> > >
> > If someone uses this script, could you please do the following te= st:
> >
> > WITH_META_MODE=3Dyes (/etc/src-env.conf)
> > filemon module loaded
> >
> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

The above used older commands and files from before
the following install. META_MODE recorded the use of
those commands.

Example .meta mode file content:

# Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd= 64/lib/libc++/libc++.a.meta
CMD @echo building static c++ library
CMD @rm -f libc++.a
CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o charconv.= o chrono.o condition_variable.o condition_variable_destructor.o debug.o exc= eption.o filesystem/directory_iterator.o filesyste
m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o io= s.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o optional.= o random.o random_shuffle.o regex.o shared_mutex.o
stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o utility= .o valarray.o variant.o vector.o cxxrt_auxhelper.o cxxrt_dynamic_cast.o cxx= rt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g
nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++=
TARGET libc++.a
-- command output --
building static c++ library

-- filemon acquired metadata --
# filemon version 5
# Target pid 22471
# Start 1611359217.214996
V 5
E 22961 /bin/sh
R 22961 /etc/libmap.conf
R 22961 /var/run/ld-elf.so.hints
R 22961 /lib/libedit.so.7
R 22961 /lib/libc.so.7
R 22961 /lib/libncursesw.so.9
R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE
F 22961 22962
E 22962 /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/le= gacy/usr/sbin/rm
R 22962 /etc/libmap.conf
R 22962 /var/run/ld-elf.so.hints
R 22962 /lib/libc.so.7
R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE
D 22962 libc++.a
X 22962 0 0
. . .

So META_MODE has lots of files that were used
that it can later detect being newer than the
prior build results, leading to rebuilds based
on those newer files.

> > # ./tools/build/beinstall.sh

The new be will have various updated files
that could be different by content and, for
commands, could behave differently than those
used to do the prior build. Detecting newer
time stamps on such used files leads to
rebuild activity.

More than /usr/src/ and /usr/obj/ content
are involved as well.

Note that the new be is based on somewhat
different files than the original
buildworld-jobs buildkernel-jobs was based
on.

> > # reboot
> >

(I presume booting into the new be here.)

> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

META_MODE will notice when commands are used
that are newer than when the prior build was
done. Similarly=C2=A0 for other files that may be
read. It will make sure that the newer commands
and files are allowed to produce new results
that potentially could be distinct in content
from what the old context produced for results.

> >
> > Since src and obj are the same from one BE to newer BE, minimal > > compilation should happen, not a full one.

META_MODE is more careful than that.

Note: I'm not claiming that new behavior that is
needed is likely for lots of the files with new
dates. But META_MODE is biased to avoiding leaving
in place something that should have been updated.

> >
> > Am I missing something here?
> >

Note that make has a -dM option:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M=C2=A0 =C2=A0 =C2=A0 =C2= =A0Print debugging information about =E2=80=9Cmeta=E2=80=9D mode decisions<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0about targets.

So, for example,

file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/awk' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cap_mkdb' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cat' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cp' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchgen' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchide' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/dd' is newer than the target...
. . .

Various . . ./tmp/legacy/. . ./*bin/ actually were
links to files.

Ultimately buildworld then installworld lead to new
dates for a bunch of files used. Later use of
META_MODE notices such and rebuilds based on the
newer files. (It is a lot of detail to go through
it all.)

Back in 2021 and 2023 I got help with exploring
avoiding lots of these. But, in the end, it
involved use of experimental code in
share/mk/src.sys.obj.mk to provide a new
definition to use to build some paths with.

The experiments were an unsupported activity that
produced an unsupported change to allow
configurable enabling of taking risks with not
updating files that possibly should be updated.

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



--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--00000000000000972606346b224b-- From nobody Mon May 5 22:47: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 4ZrxVc0b3sz5tydF for ; Mon, 05 May 2025 22:47:20 +0000 (UTC) (envelope-from eduardo@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 4ZrxVb5QQLz3VBG for ; Mon, 05 May 2025 22:47:19 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746485239; 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=zCdXPmPAgQQcPChtnfhfPn/UhW5feM0A0GTMZXo+eq8=; b=OredZ7070aGxrCHUjZa+p136PtUzmpbb3c1pyeVIBZymHcWRUnv/pcmPslslTFF7oTycNr E9yWlo7QbBKoLFQmBXuz7mv606Buf0WV9KJ+q2LuYZ3iYAoJcUMWFpdYSqlJmeK6KpYrvp OqM3NGFXgAIbA+9GrbIAKwp19/95h4Mji3I0ps6W6EDp6EgJXwj7ELeGtfpMlvyffbbkvy jA5a7Lb4q36q+wp7fMRg2s42ZwJ52F3g5x9FH95XLYrGOHmmU5gv9PDPpt978jEl2o1Q8k RM3a5mxct+Q2gwSK5ebXOvvf95WEHEZynOwjBwsybXyucwYMLIPoBiTgQXeXQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746485239; 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=zCdXPmPAgQQcPChtnfhfPn/UhW5feM0A0GTMZXo+eq8=; b=X5/pjRVxPTvYKGNxv0vEqHQTTO0TEJ1vnRJ7rmXHXjMgZG4L6CCeqUgHSTF4LVa9HWOnio lNMEfmFPiETB6+cAhouHwcjvt5uovuo1IYWnB6bxxWsh5AB4zZd43vmuhQBFvnOKXshV82 b4+oR24UzwNUZqM1Xi4ViBFCXE9MONUhu7nEm6OH/96RdtKr1qLoRys+Un+CAi9+xl1r7d qIaeNp69SL6uEOXdT7Fva59GSbzlGCCEOSwRVuQNm0SAe0oBQ0acp0d1gn/IiVUFAcCnPk svXEAOLeaOwZk7BuRvBuqzBg7Pqy12OFyxMYEwhwScxOxuEkrPg4wILLadPHng== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746485239; a=rsa-sha256; cv=none; b=Er1R9x4iVsyzb9qZdLSkTgzu01vGpDtXSL6rgrTLG1PtS0hAPdBHyKHwCrmGTM5e3s2K+u erI61xYqubVl+w3h294r9Mo33y+pfhnr/j0LJyfKh1JYJ9miXPHSscCOomnss6DJi744SD 8x+gGw+SbmsQ4S+2LV+yNLE3lQvMALeQobedEFM1Zoz1OLSRRGMo2d0RLsyUp6U5tjpbAZ TsdwHcp8CD80aUzO+Trm3D0aMRrG3ljCBhJ2qP1mpsd0DxZbOjcrgF7+uZi/cPLJjBuUNU 9MzLGOuE/M2h2yOCxEYjmQxp3sedLkCleZln1QeWsj0uMkd1xUu4ynOiwDtwgQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZrxVb4fFyzFVy for ; Mon, 05 May 2025 22:47:19 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-47680c117fdso9543791cf.2 for ; Mon, 05 May 2025 15:47:19 -0700 (PDT) X-Gm-Message-State: AOJu0YwhtfVkMPmKc3317ZBTYaYxuJ5Us3EbmNuvu0oeKu87L+rFpxA6 QpDbzhQAh4SUyANC5Wt90NgCdwbcnc6pwmEUY1hu0fpseFlSyAVJy3Etjx7KglqaoIqb5o1tQ7d Z8kKITm7mgg2F8vxLpdfwmhj/l3A= X-Google-Smtp-Source: AGHT+IHBLFQgRe8EvHeCT8MsQmr71mkV5OqFMHH92bG5s9p0+wE4dun5uJXqfZ6kpDcGy4BHqBncIbsGFCfYBtXhFW0= X-Received: by 2002:a05:622a:d5:b0:477:5f29:dbc9 with SMTP id d75a77b69052e-48c32ebd22cmr83709111cf.13.1746485239223; Mon, 05 May 2025 15:47:19 -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: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Mon, 5 May 2025 23:47:08 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUE8V5C9qF3fanjTsBonzAl9_6qZOzUuKPut5romhfPD0fKwaH2hj-uKqOI Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: Mark Millard Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000004a199706346b48ff" --0000000000004a199706346b48ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) This way i did have less compiling expecially on buildworld. My rpi4 is recompiling allmost everything in buildworld phase using beinstall.sh. I will use this mehod from now on. Thanks very much for your great explanation! Cheers, Nuno Teixeira escreveu (segunda, 5/05/2025 =C3=A0(s) 23:36): > Hello Mark, > > Minutes ago I used a more tradicional way: > > # make buildworld-jobs buildkernel-jobs > > ``` > RELEASE=3DWhatever > > bectl create ${RELEASE} > > bectl mount ${RELEASE} > BASEDIR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl mount > > > make DESTDIR=3D${BASEDIR} installkernel > > etcupdate -p -D ${BASEDIR} > > make DESTDIR=3D${BASEDIR} installworld > > etcupdate -D ${BASEDIR} > > bectl activate ${RELEASE} > > reboot > ``` > > # make buildworld-jobs[1] buildkernel-jobs[2] > [1] did not compile > [2] compiled > > # make buildworld-jobs[1] buildkernel-jobs[2] > [1] did not compile > [2] did not compile > > Cheers, > > Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s) 2= 3:18): > >> Nuno Teixeira wrote on >> Date: Mon, 05 May 2025 20:37:09 UTC : >> >> > (...) >> > >> > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess wi= th >> > ports and stuff. >> > >> > Nuno Teixeira escreveu (segunda, 5/05/2025 =C3= =A0(s) >> > 21:34): >> > >> > > Hello, >> > > >> > > Using incremental WITH_META_MODE builds, after installation with >> > > beinstall.sh, building same src, a complete compilation happens. >> > > >> > > If someone uses this script, could you please do the following test: >> > > >> > > WITH_META_MODE=3Dyes (/etc/src-env.conf) >> > > filemon module loaded >> > > >> > > # cd /usr/src >> > > # make buildworld-jobs buildkernel-jobs >> >> The above used older commands and files from before >> the following install. META_MODE recorded the use of >> those commands. >> >> Example .meta mode file content: >> >> # Meta data file >> /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/= libc++.a.meta >> CMD @echo building static c++ library >> CMD @rm -f libc++.a >> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o >> charconv.o chrono.o condition_variable.o condition_variable_destructor.o >> debug.o exception.o filesystem/directory_iterator.o filesyste >> m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o >> ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o >> optional.o random.o random_shuffle.o regex.o shared_mutex.o >> stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o >> utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o >> cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_= g >> nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.= o >> CWD >> /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++ >> TARGET libc++.a >> -- command output -- >> building static c++ library >> >> -- filemon acquired metadata -- >> # filemon version 5 >> # Target pid 22471 >> # Start 1611359217.214996 >> V 5 >> E 22961 /bin/sh >> R 22961 /etc/libmap.conf >> R 22961 /var/run/ld-elf.so.hints >> R 22961 /lib/libedit.so.7 >> R 22961 /lib/libc.so.7 >> R 22961 /lib/libncursesw.so.9 >> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE >> F 22961 22962 >> E 22962 >> /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/rm >> R 22962 /etc/libmap.conf >> R 22962 /var/run/ld-elf.so.hints >> R 22962 /lib/libc.so.7 >> R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE >> D 22962 libc++.a >> X 22962 0 0 >> . . . >> >> So META_MODE has lots of files that were used >> that it can later detect being newer than the >> prior build results, leading to rebuilds based >> on those newer files. >> >> > > # ./tools/build/beinstall.sh >> >> The new be will have various updated files >> that could be different by content and, for >> commands, could behave differently than those >> used to do the prior build. Detecting newer >> time stamps on such used files leads to >> rebuild activity. >> >> More than /usr/src/ and /usr/obj/ content >> are involved as well. >> >> Note that the new be is based on somewhat >> different files than the original >> buildworld-jobs buildkernel-jobs was based >> on. >> >> > > # reboot >> > > >> >> (I presume booting into the new be here.) >> >> > > # cd /usr/src >> > > # make buildworld-jobs buildkernel-jobs >> >> META_MODE will notice when commands are used >> that are newer than when the prior build was >> done. Similarly for other files that may be >> read. It will make sure that the newer commands >> and files are allowed to produce new results >> that potentially could be distinct in content >> from what the old context produced for results. >> >> > > >> > > Since src and obj are the same from one BE to newer BE, minimal >> > > compilation should happen, not a full one. >> >> META_MODE is more careful than that. >> >> Note: I'm not claiming that new behavior that is >> needed is likely for lots of the files with new >> dates. But META_MODE is biased to avoiding leaving >> in place something that should have been updated. >> >> > > >> > > Am I missing something here? >> > > >> >> Note that make has a -dM option: >> >> M Print debugging information about =E2=80=9Cmeta=E2= =80=9D mode >> decisions >> about targets. >> >> So, for example, >> >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy= /usr/sbin/awk' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy= /usr/sbin/cap_mkdb' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy= /usr/sbin/cat' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy= /usr/sbin/cp' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy= /usr/sbin/crunchgen' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy= /usr/sbin/crunchide' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy= /usr/sbin/dd' >> is newer than the target... >> . . . >> >> Various . . ./tmp/legacy/. . ./*bin/ actually were >> links to files. >> >> Ultimately buildworld then installworld lead to new >> dates for a bunch of files used. Later use of >> META_MODE notices such and rebuilds based on the >> newer files. (It is a lot of detail to go through >> it all.) >> >> Back in 2021 and 2023 I got help with exploring >> avoiding lots of these. But, in the end, it >> involved use of experimental code in >> share/mk/src.sys.obj.mk to provide a new >> definition to use to build some paths with. >> >> The experiments were an unsupported activity that >> produced an unsupported change to allow >> configurable enabling of taking risks with not >> updating files that possibly should be updated. >> >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> >> > > -- > Nuno Teixeira > FreeBSD UNIX: Web: https://FreeBSD.org > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --0000000000004a199706346b48ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(...)

This way i did have= less compiling expecially on buildworld. My rpi4 is recompiling allmost ev= erything in buildworld phase using beinstall.sh.
I will use this m= ehod from now on.

Thanks very much for your great explanation!=

Cheers,

Nuno Teixeira <eduardo@freebsd.org> escreveu (segunda, 5/0= 5/2025 =C3=A0(s) 23:36):
Hello Mark,

Minut= es ago I used a more tradicional way:

# make b= uildworld-jobs buildkernel-jobs

```
RELE= ASE=3DWhatever
> bectl create ${RELEASE}
> bectl mount ${RELEAS= E}
BASEDIR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl moun= t

> make DESTDIR=3D${BASEDIR} installkernel
> etcupdate -p = -D ${BASEDIR}
> make DESTDIR=3D${BASEDIR} installworld
> etcupd= ate -D ${BASEDIR}
> bectl activate ${RELEASE}
> reboot
```

# make buildworld-jobs[1] buildkernel-jobs[2= ]
[1] did not compile
[2] compiled

# = make buildworld-jobs[1] buildkernel-jobs[2]
[1] did not comp= ile
[2] did not compile

Cheers,
Mark Mil= lard <marklmi@yah= oo.com> escreveu (segunda, 5/05/2025 =C3=A0(s) 23:18):
Nuno Teixeira <eduardo= _at_freebsd.org> wrote on
Date: Mon, 05 May 2025 20:37:09 UTC :

> (...)
>
> Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mes= s with
> ports and stuff.
>
> Nuno Teixeira <eduardo@freebsd.org> escreveu (segunda, 5/05/2025 =C3=A0(s)
> 21:34):
>
> > Hello,
> >
> > Using incremental WITH_META_MODE builds, after installation with<= br> > > beinstall.sh, building same src, a complete compilation happens.<= br> > >
> > If someone uses this script, could you please do the following te= st:
> >
> > WITH_META_MODE=3Dyes (/etc/src-env.conf)
> > filemon module loaded
> >
> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

The above used older commands and files from before
the following install. META_MODE recorded the use of
those commands.

Example .meta mode file content:

# Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd= 64/lib/libc++/libc++.a.meta
CMD @echo building static c++ library
CMD @rm -f libc++.a
CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o charconv.= o chrono.o condition_variable.o condition_variable_destructor.o debug.o exc= eption.o filesystem/directory_iterator.o filesyste
m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o io= s.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o optional.= o random.o random_shuffle.o regex.o shared_mutex.o
stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o utility= .o valarray.o variant.o vector.o cxxrt_auxhelper.o cxxrt_dynamic_cast.o cxx= rt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g
nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++=
TARGET libc++.a
-- command output --
building static c++ library

-- filemon acquired metadata --
# filemon version 5
# Target pid 22471
# Start 1611359217.214996
V 5
E 22961 /bin/sh
R 22961 /etc/libmap.conf
R 22961 /var/run/ld-elf.so.hints
R 22961 /lib/libedit.so.7
R 22961 /lib/libc.so.7
R 22961 /lib/libncursesw.so.9
R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE
F 22961 22962
E 22962 /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/le= gacy/usr/sbin/rm
R 22962 /etc/libmap.conf
R 22962 /var/run/ld-elf.so.hints
R 22962 /lib/libc.so.7
R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE
D 22962 libc++.a
X 22962 0 0
. . .

So META_MODE has lots of files that were used
that it can later detect being newer than the
prior build results, leading to rebuilds based
on those newer files.

> > # ./tools/build/beinstall.sh

The new be will have various updated files
that could be different by content and, for
commands, could behave differently than those
used to do the prior build. Detecting newer
time stamps on such used files leads to
rebuild activity.

More than /usr/src/ and /usr/obj/ content
are involved as well.

Note that the new be is based on somewhat
different files than the original
buildworld-jobs buildkernel-jobs was based
on.

> > # reboot
> >

(I presume booting into the new be here.)

> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

META_MODE will notice when commands are used
that are newer than when the prior build was
done. Similarly=C2=A0 for other files that may be
read. It will make sure that the newer commands
and files are allowed to produce new results
that potentially could be distinct in content
from what the old context produced for results.

> >
> > Since src and obj are the same from one BE to newer BE, minimal > > compilation should happen, not a full one.

META_MODE is more careful than that.

Note: I'm not claiming that new behavior that is
needed is likely for lots of the files with new
dates. But META_MODE is biased to avoiding leaving
in place something that should have been updated.

> >
> > Am I missing something here?
> >

Note that make has a -dM option:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M=C2=A0 =C2=A0 =C2=A0 =C2= =A0Print debugging information about =E2=80=9Cmeta=E2=80=9D mode decisions<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0about targets.

So, for example,

file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/awk' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cap_mkdb' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cat' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cp' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchgen' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchide' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/dd' is newer than the target...
. . .

Various . . ./tmp/legacy/. . ./*bin/ actually were
links to files.

Ultimately buildworld then installworld lead to new
dates for a bunch of files used. Later use of
META_MODE notices such and rebuilds based on the
newer files. (It is a lot of detail to go through
it all.)

Back in 2021 and 2023 I got help with exploring
avoiding lots of these. But, in the end, it
involved use of experimental code in
share/mk/src.sys.obj.mk to provide a new
definition to use to build some paths with.

The experiments were an unsupported activity that
produced an unsupported change to allow
configurable enabling of taking risks with not
updating files that possibly should be updated.

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



--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org


--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--0000000000004a199706346b48ff-- From nobody Tue May 6 00:49:32 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 4Zs0Cg23h0z5v753 for ; Tue, 06 May 2025 00:49:35 +0000 (UTC) (envelope-from ahmadkhalifa570@gmail.com) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (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 4Zs0Cf0jmTz3ZNn; Tue, 06 May 2025 00:49:34 +0000 (UTC) (envelope-from ahmadkhalifa570@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=LCaD3Onm; spf=pass (mx1.freebsd.org: domain of ahmadkhalifa570@gmail.com designates 2607:f8b0:4864:20::1130 as permitted sender) smtp.mailfrom=ahmadkhalifa570@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-70427fb838cso40357047b3.2; Mon, 05 May 2025 17:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746492573; x=1747097373; darn=freebsd.org; h=cc:to:subject:message-id:date:in-reply-to:references:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dDZRrnOipUjaB5BpDMALMeFOwz6tZ58CTbnLRRBvXes=; b=LCaD3Onm3ULUeXa75Mswqe7h5blc0DqoHJfTHNYS0/IY4EoT7wtKNdH1yUuKGXymaC 2qHBzxqESzNr3tZ77e1kYQ0lWbWW7dcOKQ5aXoYsJEfoErt6f2GFR9R4bMEo1r8DwXH8 g2ozpbS8fMx5Um+uDeNA9h9Jo51dI3q8hYcjZK2Atk48cFUwAJ6egHhjfKm0FmrJAqPZ LgPn9wZQWMVcYDnTVbCbHUrvIoCy8AX+pxa/jRgMXGY9HhMBr3prgKg0kpCKs3Pfz2hM ofpmKw3QSDMj12jzuVyJeByFXXE8/ZNcCZU4BdTK3f05LJ0i1zxiyNLpFRc95WHXGP0J 2+Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746492573; x=1747097373; h=cc:to:subject:message-id:date:in-reply-to:references:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dDZRrnOipUjaB5BpDMALMeFOwz6tZ58CTbnLRRBvXes=; b=AA3Akh1NA9xK7eHUZvxSldqkVYVQjXIk6vijgYW2cPPSjzquOlWHLTTLrceCiK9WIr WJHEIU0w1NZuAfGewlhYHNb0E6By1WEHs17A8MDogumRZQRIPze6bOpt1mi9mruAlpEo skvF0izZD/WiCSXT0TXGqsRzgicl1Gs9Lu06dcBa7n+n6HTxwB13Od2sOH7bKYpyDGT6 2BozhcQO7aj4A6V5fFPEeTcFqQ+t+ZLn10xKrEceb4rpW6qaa90hknmIspgG59NCq4Sc 9m+vqXxSf8J/Jp+ph0wG1DBmASqMefZJgC31jSt4em7pa9+mgj45EKP2KuoQI/3/8IBU A7dw== X-Forwarded-Encrypted: i=1; AJvYcCW7zhz+f1EaInUO2dEwKjtDtjeF8kkh912NPx8NavImQvIJcWn5BBJlsHU1tLJuIGSrEVX+@freebsd.org X-Gm-Message-State: AOJu0Yz0SHATWUz+B6MqXKoAtpWF13hVKEZD9YJu3RaJSU2+RX2UVbKJ pMKT9zIqQe+SDAdhduijp6z13nekIQvXoq+tXh4z9IkWuSHICYOj1lFGuLEHH5uBm3ZpowpdQek egev1ekqq6kB7AaP5RRsH4H11O+A= X-Gm-Gg: ASbGncuJmTik8N9meUnBi3wAfH8hIRVwe3slygdNnl5z9bfWaEPHLLn/b5hvOu3DlYV RBDPyMwjsiqsHT0fZhm5c5t+GpILR1/0LzRvv1skeN3v7Or6dAzQpC/r2i8AkKQshoRWHLLjDFs cR5l+YNLdVIZnIkCk3oVZk+k6zXva6YYJGTA== X-Google-Smtp-Source: AGHT+IEdP2SNIp6eUN9p4un+t3ZQJa1JHkG6ydCYSriC1TSYaoheaRk7D7X97P26QVNl0JANuStAPn9tmd2iF6WrfOk= X-Received: by 2002:a05:690c:640b:b0:6f9:9e25:e992 with SMTP id 00721157ae682-708cf033f6emr214015327b3.10.1746492573121; Mon, 05 May 2025 17:49:33 -0700 (PDT) Received: from 490177373942 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 May 2025 00:49:32 +0000 Received: from 490177373942 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 May 2025 00:49:32 +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 From: Ahmad Khalifa X-Mailer: aerc 0.20.0 References: In-Reply-To: Date: Tue, 6 May 2025 00:49:32 +0000 X-Gm-Features: ATxdqUEl6XMVs2zFAhqcBgHPdujIPHXCUL1wmeqo_R9dAWiHcuQw4YM2dR4K75A Message-ID: Subject: Re: How to build with cross gcc? To: Konstantin Belousov Cc: current@freebsd.org, Olivier Certner Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Zs0Cf0jmTz3ZNn X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.13 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.892]; NEURAL_HAM_LONG(-0.88)[-0.877]; NEURAL_HAM_MEDIUM(-0.86)[-0.859]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1130:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] On Wed Apr 30, 2025 at 8:58 AM +0300, Konstantin Belousov wrote: > exa% pwd > /usr/local/x86_64-unknown-freebsd13.5/bin > exa% ls -l cc1 cc1plus liblto_plugin.so > lrwxr-xr-x 1 root wheel 60 Apr 30 08:49 cc1 -> /usr/local/libexec/gcc/x86_64-unknown-freebsd13.5/14.1.0/cc1 > lrwxr-xr-x 1 root wheel 64 Apr 30 08:49 cc1plus -> /usr/local/libexec/gcc/x86_64-unknown-freebsd13.5/14.1.0/cc1plus > lrwxr-xr-x 1 root wheel 73 Apr 30 08:49 liblto_plugin.so -> /usr/local/libexec/gcc/x86_64-unknown-freebsd13.5/14.1.0/liblto_plugin.so If this was installed from FreeBSD:14:amd64/latest shouldn't GCC's target be 14.2 instead of 13.5? From nobody Tue May 6 08:18: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 4ZsB9w4XH3z5vh1x for ; Tue, 06 May 2025 08:18:44 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (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 (secp384r1) client-digest SHA384) (Client CN "prime.gushi.org", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsB9v72rRz3jc3 for ; Tue, 06 May 2025 08:18:43 +0000 (UTC) (envelope-from freebsd@gushi.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gushi.org header.s=prime2014 header.b=KBwBRfk5; spf=pass (mx1.freebsd.org: domain of freebsd@gushi.org designates 2620:137:6000:10::142 as permitted sender) smtp.mailfrom=freebsd@gushi.org; dmarc=pass (policy=none) header.from=gushi.org Received: from smtpclient.apple ([IPv6:2001:500:6b:200:c000:0:0:2d1]) (authenticated bits=0) by prime.gushi.org (8.18.1/8.18.1) with ESMTPSA id 5468Ifrj069867 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 6 May 2025 08:18:42 GMT (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 5468Ifrj069867 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1746519522; bh=MdS26FXYqjKmBOa3JFMOiI99uAR3ZEQLJ8HiO3xQIlw=; h=From:Subject:Date:To; z=From:=20"Dan=20Mahoney=20(Ports)"=20|Subject:= 20Recent=20changes=20to=20pkg=20argument=20parsing=0D=0A=20(https: //reviews.freebsd.org/D49977)|Date:=20Tue,=206=20May=202025=2001:1 8:26=20-0700|To:=20"freebsd-current@freebsd.org"=20; b=KBwBRfk5F26WIPYhJmy766+JJd5Uo1lVq1Pe1AZGBZaeQmp8qS804ECHLWcFst3L2 4lC2uAz31IWty3STwbUltEVtWZmvrdySKWcXDOLnkLgznF61g7/gvkynSElGRU0aQK bPIF5KKog9a23egtdG/VeulLIFJalAg/H97lI7ZZ4XgidLTEk3LmYFD+3C2Soy3fy4 p1aWmUxQNSx3Pj4RtgpOGKp1LN9UJ3Talt66LaJg6CbXdihuUho2lNAeLUc9IjkkLb +CFWhlRPiiPncKmJ93cIeEmeHp1XO+isnjqrYqywC+pZ1tmOgn+vH0TwmzHnKOLi0j /m0ZdReuLKnNA== X-Authentication-Warning: prime.gushi.org: Host [IPv6:2001:500:6b:200:c000:0:0:2d1] claimed to be smtpclient.apple From: "Dan Mahoney (Ports)" 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: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977) Message-Id: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> Date: Tue, 6 May 2025 01:18:26 -0700 To: "freebsd-current@freebsd.org" X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4ZsB9v72rRz3jc3 X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; DWL_DNSWL_LOW(-1.00)[gushi.org:dkim]; URL_IN_SUBJECT(1.00)[reviews.freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gushi.org,none]; MV_CASE(0.50)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[2620:137:6000:10::142:from]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[gushi.org:s=prime2014]; MIME_GOOD(-0.10)[text/plain]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[gushi.org:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:393507, ipnet:2620:137:6000::/44, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; RCVD_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; HAS_XAW(0.00)[] All, I just joined the list and can't figure out how to reply to Graham's = emails of a few days ago. Since this change, I'm also finding cases where regular pkg arguments = are being warned about (but still work). For example, we've got a cron job on every box that gathers all our leaf = packages into a file: #!/bin/sh /usr/sbin/pkg query -e '%#r =3D=3D 0' '%n-%v' We now get warnings: # /usr/local/libexec/pkgleaf pkg: invalid option -- e (but the query still runs). Has anyone else seen this? -Dan= From nobody Tue May 6 08:46: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 4ZsBp64PFbz5vjyV for ; Tue, 06 May 2025 08:46:38 +0000 (UTC) (envelope-from SRS0=y2Sc=XW=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsBp62Qm6z3tb2 for ; Tue, 06 May 2025 08:46:38 +0000 (UTC) (envelope-from SRS0=y2Sc=XW=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from crmpreview4.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview4.colo2.realworks.nl (Postfix) with ESMTP id 6A0B71C006B; Tue, 6 May 2025 10:46:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1746521194; 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=U3l4Ghtpg86zxrcvYq1AUbV4w/mDKAx6gEfSRc5L/CI=; b=TkhEx8ISBvLw6JMAsQ6Mq8n1lmxiXnrJ5kZhbJOYhwzJR5PneqOcHQPoa3kCAtucIpfpcP OLzQumZKAflhheQCZEHaNAYtfOJNxkJRk/9PQDnFXNpS/7apCwIIBO/ZTezkZ+4wtHZXju rTtwd1VV/EmPj0bucqb+Da1GwyE7gEij2ffZNWKnjchpUGFp3FRkdZbSAdpS5p73iQvglS cXVUKGbByvkfermHRxLbr+d54lnYv3XJ0xq5uoPUqIdeOuuS3m9sydggqrDyGcR1YpE59I e8NC545ur+7a90Yvn1Iju4JVdPKu32Sc/qR1+Q+iHoEsYyXUFuh3HslaKYjWtg== Date: Tue, 6 May 2025 10:46:34 +0200 (CEST) From: Ronald Klop To: "Dan Mahoney (Ports)" Cc: "freebsd-current@freebsd.org" Message-ID: <2112105736.3813.1746521194057@localhost> In-Reply-To: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> References: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> Subject: Re: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977) 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_3812_1836118416.1746521193943" X-Mailer: Realworks (748.20) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4ZsBp62Qm6z3tb2 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:3265, ipnet:194.109.0.0/16, country:NL] X-Spamd-Bar: ---- ------=_Part_3812_1836118416.1746521193943 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This pkg argument issue is fixed yesterday. https://cgit.freebsd.org/src/commit/?id=73ba568b1c35aabc1682540b5b4d5d77220c5468 Regards, Ronald. Van: "Dan Mahoney (Ports)" Datum: dinsdag, 6 mei 2025 10:18 Aan: "freebsd-current@freebsd.org" Onderwerp: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977) > > All, > > I just joined the list and can't figure out how to reply to Graham's emails of a few days ago. > > Since this change, I'm also finding cases where regular pkg arguments are being warned about (but still work). > > For example, we've got a cron job on every box that gathers all our leaf packages into a file: > > #!/bin/sh > /usr/sbin/pkg query -e '%#r == 0' '%n-%v' > > We now get warnings: > > # /usr/local/libexec/pkgleaf > pkg: invalid option -- e > > (but the query still runs). > > Has anyone else seen this? > > -Dan > > > ------=_Part_3812_1836118416.1746521193943 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit This pkg argument issue is fixed yesterday.

https://cgit.freebsd.org/src/commit/?id=73ba568b1c35aabc1682540b5b4d5d77220c5468

Regards,

Ronald.

 

Van: "Dan Mahoney (Ports)" <freebsd@gushi.org>
Datum: dinsdag, 6 mei 2025 10:18
Aan: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.org>
Onderwerp: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977)

All,

I just joined the list and can't figure out how to reply to Graham's emails of a few days ago.

Since this change, I'm also finding cases where regular pkg arguments are being warned about (but still work).

For example, we've got a cron job on every box that gathers all our leaf packages into a file:

#!/bin/sh
/usr/sbin/pkg query -e '%#r == 0' '%n-%v'

We now get warnings:

# /usr/local/libexec/pkgleaf
pkg: invalid option -- e

(but the query still runs).

Has anyone else seen this?

-Dan

  ------=_Part_3812_1836118416.1746521193943-- From nobody Tue May 6 09:04: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 4ZsCBm2H1sz5vkcy for ; Tue, 06 May 2025 09:04:32 +0000 (UTC) (envelope-from matthew@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 4ZsCBm1nbwz432s for ; Tue, 06 May 2025 09:04:32 +0000 (UTC) (envelope-from matthew@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746522272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=fVFzNg/H4uUDL5mhQzyTansr1ogm9P3NJbnHRcrEXRU=; b=ti3IIsA7/RS01LHwj24kuraNqsgDa4uyMZvjesApgI+AJiJnRbhqvibTswJWlYhX+a/jA6 H+mGmDJS0pvVhXLlq1NF+volNzj6Y0QUwoQjNZJy4szYZTI5rdP8dKz0stCMZt+rUXdtU6 PigYebfMxzERxjQOJiW6tkuIFBbQvHiDRyzmPHi5l1xfrsjVpsCHCyEPSk5sGzw29VhfLX /bA14bGLXOziC9F73TJHvfTAQxOaWjtVc9ojWESsXNqAVZNOW0vyxQyvun75/Jp8SWJYHa h5qRbWMDTRuk22IH72oX4ZGw79hN9afWZ4rx1gOHM3AXEJ/zKyWIi15IZAHp8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746522272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=fVFzNg/H4uUDL5mhQzyTansr1ogm9P3NJbnHRcrEXRU=; b=qApLekKAMzh5TBQAqBpoDgmvGSvRyJADoB8YIZc8Osw2qQ2ysPCpljql1/9bBidy9JKj5Z eh0xfAMe0Z9uHBUlYxJwglTSmbuklX2kA80J339whzpx15c7/j3mlq6wSJ1uIO4NSMueX+ Ty+DAwtYnvIzvAb0FWlH9lQkq5qMQ6VJxQje8KR0D1qdHO4E2Xvbn5WCvXUzgP58IfuHKO QpIS5N+zMYP+EnFW6+nWS7PEFCDnpAsoWjhjwePo3cQhSy4GtmRFzpouHR+u1z2zXgEVqS t1iLRROygywy84flziKDSXWPI335AET/rg75kWHGOsZvOI+1nJos0/pYeqUuDQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746522272; a=rsa-sha256; cv=none; b=vAFJRBxNsm6ObWJCU4EnYRyHbl+16lFSabTxyINuRHXE1ZCJPrSwjznC/zzJhyeJ/LODwr 59T7V7i58jjnkkbsTwY+7FW+PgfkFA1gA6Dlr6mOsSLEON1k2IkTTtz/uNnrnFDL9tHXPd 2ReER/uhUGk/3FDSJNOMvY2CG27l7W1vgKHfkGviTFFSVLnkGo1IZxmyFijY+xvI0SW10n uTcHxOi9YTqg0jPnp8TZLFRs11zRm+2E1crUjRG65tTU/DBxKk6JpGxjBa842dKQOAtZq3 cdjBcIo5R6ES+YJwhmQMwcNbmZhBJb/nwuYvmH4NpCa9bESNBcDX/whYhrcR3g== ARC-Authentication-Results: i=1; smtp.infracaninophile.co.uk; dmarc=fail (p=none dis=none) header.from=FreeBSD.org Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (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: matthew/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZsCBl6TF7zkQH for ; Tue, 06 May 2025 09:04:31 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from [IPV6:2001:8b0:151:1:9991:6f17:c61:cdc9] (unknown [IPv6:2001:8b0:151:1:9991:6f17:c61:cdc9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id D6A2E1F596 for ; Tue, 06 May 2025 10:04:30 +0100 (BST) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=fail (p=none dis=none) header.from=FreeBSD.org Message-ID: <051b6c25-152a-4f4e-bcbb-c3efa5181acf@FreeBSD.org> Date: Tue, 6 May 2025 10:04:30 +0100 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 From: Matthew Seaman Subject: Re: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977) To: freebsd-current@freebsd.org References: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> Content-Language: en-GB Autocrypt: addr=matthew@FreeBSD.org; keydata= xsFNBGgIxf4BEACvpGuW7L1ehWfPYaU0kMwJ5S+a0os7d+wj7PP1rbx83z7usIVsIJl16FjE t0jlOoFJWCV4Ja+JeeKi/7xubWzWG53lC1M7R8ZVNuYKGxPSbYVohWB+QiJ3Fb6MgD6Mj+mp dY08y8h3f7UC+YQmB/TQlahZD9UPQrexhhqA1Nq2o8Qskd0NkWN0bxLyn8Ad0eiaAbmdxQDD gq1l6AcJE75y/hF9QA4mMY2W1GxsHaWdA2AJ5Ql9HV9lIMqiOK2mtS/p7iaHfQdOE+D4RQbs WZmv2IynlUfX4Ij80+/CE1oESc3DjnqLiDXz0IBHr95NgP1tShdv4roYjc8lALBjVwfhQgz2 ClJa8a5vfdfeM9VlejBI562iy8HPCir+IqhG18runi7vfj46zZCNDM+LA3VkYFfhSCZeRj0C 2hrDcNERqO3oZmDSnBNDZOvoV1YHQLlWhKL3SY8yXDklHQjeczccdPPwRFVK8MkCCQJ4v6IR agOYmas35Hkf1slW2dlK+rrTYuUigCYQyj6i2//Mrhzwwm0NRpge11DMWMmhPAkON5APOxB7 708THhQ6myOUwzCdAF/T6RCVvNHbwa9bJQzE9Iy9ur8Z5AcrhdJMb0Cb1+7H27E2Y4uUGjBz 0Q8jTmk2H5Zr+LUcbPnFgYj7Hj6r/0NQAdkQS2axgn0/6vxIdQARAQABzSRNYXR0aGV3IFNl YW1hbiA8bWF0dGhld0BGcmVlQlNELm9yZz7CwZQEEwEKAD4WIQRQWkx88Ei5EPRvbGeh8by9 ESwXDgUCaAjGWgIbAwUJAeEzgAULCQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRCh8by9ESwX DtuUD/9qhoHDfY6aucofAFygkbCtqMGnNLlXy21cHDh4mVNWiwTTmoTbMvwg9hZ1L8/9id1T bI59H39uFWbM608oEtaEH42lB0F6vDlT1cwyoZ3wbZTjt6E6V5JLKdOnbNqwF7IElrb4UGtN bVn5cyhGOThEzE5y0J5TEZXZewsBQHO3IbIKegY3EkTrA4Lk3mg3obdvqt2uDHzxMjXZzlGP 9voU6LpYVqZg8iPOEIdm/YCCvxUmPSBpUpbozWqEx+DFeSwFRdtzrEnvKQ9eeaJCYUSv7Rvb XP/pidIrzYwwHVM9eFa2YrG5EN3A2AhsVc/ZKNrkpwaQN5ojV83wQLYpfCETWENVDMLRA0pi AVSgYPQ8/2hS+Vtgqd2FlmHGW/yQNyKZlDhH+0Vcsko+yMcQYOrlTquGGuY0dmdyYGEtdW73 77yGpGJRvLACU381E8ezmGott7azxJ14gt3rAZeWS7+9FNQ3gp7OVinnxo0OAnJCAEfdU6LD DSiMI4Qy/lygH+TPKaVZ366VbqlC6z8SjHqniwViGWYB+UglWReaFJQTq0Iu7s1KjlFDcOtX IWDUOMhZVYz813uIjO86jejPQ33e0DAAmFvCCF8uj+WWKdkddkXv4yEjrz2I1XSkja320GUh imOlFToqzNOoCUJKx2m+yb5WJpWmv1rsWNAZ5uUiH87BTQRoCMX+ARAAv1gdchMR7QM5MPVN kmSM06xWEVQ7/FmyMtiOrWoPwN2j1bj/XUdeXI85gGPUfi+Q5fJ6xrK4lvsQAAY9oltyfglJ Wb7k86EPeBis2/Jo1K2EMeFZyFLyl5WaXy3NuaX8f+PfSG56yzIL5hoxWkn/n99i75TuqIo+ Poh6BKfLsCQzMGWxz6ZktkwiQwKtELv8c0n75I3eDyrSu2u4Gz/u148ng38lLwIEHjOUEqrH LyicA7ATB6mJKusFB94tD1rwDauNJ77QDvItIASl2aEK0OK3Y0Xxh0x/EyWIaVh7/sVsARqk GAhMiYFyRmEfUrY21ol5av9neLDrPpvVDkG2sZBJppbFYYOotyHpGallKN1lJU6/18P7tI7f SrkiJxziFPgBnMy0e5bW19+3Hz5kULdJjoJZdoH2zSIID4S8d855YzzkDevo2mRKNXGUQOro EKazujou47aGKaocGWCxpWd2jVJB80l971hIU2UdzMTZufYSHgMSbJLtXWsnupzevjXo1X9h q8xrD6vNGJhwwYil4m/rkpqpOb/7TgTYHJcyPX0p8SsfUyQ8MaQnDc3r0h3QhGnwtSIR/cKS VuwplbzzTcNwG/1v2OHtw8lRvnB0/ehwV7jIkd7fdv7uYvChiWzqSCPbCS/4xuBupWNZFkbJ GDdjhkUEQBMINAaZhjsAEQEAAcLBfAQYAQoAJhYhBFBaTHzwSLkQ9G9sZ6HxvL0RLBcOBQJo CMX+AhsMBQkB4TOAAAoJEKHxvL0RLBcO8sgP/2ZEHNLrGnvEnNM3UAu1qlsBd7EX78j8o8aC DqgRf00MhYVZOP2l2p1nKwc71a/o/X0ct8k0sdEUzdV4B2fgQ3riRaH+K5ShuECApA+rmg8n iTJM/LgIHhuF1fTYQPbjCzDaHlzEI6SUQzwal9vh2Wd6qVRP5qKpLzBSS2fIegkdtpetaI64 RsXkB+AR3tgzIdXhq94QZ6Cah0wiiE7WXgMgZaUXf93cP5u/1nDl6EnuZjRSbOdMKeqOUcr7 Cod/JCRTmJIitMK5qPLosabm35ROF0iS5bC57aTVRe3y2s57I250ty+xvWl7woG8A+qikzUX jRv6sUkUGsOUGb+hPVm+LwZs8Q5xXGjdB59K4nGDjvfSaNedWYEp40vA8VnRTIz4ub8OqZwW YqEKKyeFxJfDVfnhrTkiBq1pZWQ6j6RLmXsaVvEw9JFnL5tRUks7OQjiVfsaKex2yuZUjo7L veEQCW4GtEyzfGuYVFgyEqUDFJEyImZ/jE85Heu2LWX5Zn92009+NvSMQJrb/1Jmw6zQOyxI b2Mrj5PJ+ie9flpDHDdLr7GetYV/PSxTMGbLrjfqFg/OQt7aN938reNxav4hXTqVMLjAAIu4 ZrLxvZPCUPBjpVoAHGrEK2N/JnCNZokmQM58MTh3AH5/CU37pIg1AvuNnX4YW6mNdPBoQy7Z In-Reply-To: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------4G8bxojsbqJXf9XeHnj8xltF" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------4G8bxojsbqJXf9XeHnj8xltF Content-Type: multipart/mixed; boundary="------------v01SThGR8yMqPgfNx28X0Q5y"; protected-headers="v1" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <051b6c25-152a-4f4e-bcbb-c3efa5181acf@FreeBSD.org> Subject: Re: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977) References: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> In-Reply-To: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> --------------v01SThGR8yMqPgfNx28X0Q5y Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYvMDUvMjAyNSAwOToxOCwgRGFuIE1haG9uZXkgKFBvcnRzKSB3cm90ZToNCj4gRm9y IGV4YW1wbGUsIHdlJ3ZlIGdvdCBhIGNyb24gam9iIG9uIGV2ZXJ5IGJveCB0aGF0IGdhdGhl cnMgYWxsIG91ciBsZWFmIHBhY2thZ2VzIGludG8gYSBmaWxlOg0KPiANCj4gIyEvYmluL3No DQo+IC91c3Ivc2Jpbi9wa2cgcXVlcnkgLWUgJyUjciA9PSAwJyAnJW4tJXYnDQo+IA0KPiBX ZSBub3cgZ2V0IHdhcm5pbmdzOg0KPiANCj4gIyAvdXNyL2xvY2FsL2xpYmV4ZWMvcGtnbGVh Zg0KPiBwa2c6IGludmFsaWQgb3B0aW9uIC0tIGUNCj4gDQo+IChidXQgdGhlIHF1ZXJ5IHN0 aWxsIHJ1bnMpLg0KPiANCj4gSGFzIGFueW9uZSBlbHNlIHNlZW4gdGhpcz8NCg0KVGhpcyBp cyBwa2coNykgc3RydWdnbGluZyB0byBwYXJzZSBvcHRpb25zIHRoYXQgaXQgZG9lc24ndCBk byBhbnl0aGluZyANCndpdGggb3RoZXIgdGhhbiBwYXNzIHRoZW0gdGhyb3VnaCB0byB0aGUg cmVhbCBwa2coOCkuDQoNCkFzIHNhaWQgZWxzZXdoZXJlIGluIHRoZSB0aHJlYWQsIGEgZml4 IGZvciB0aGUgcHJvYmxlbSBoYXMgYmVlbiANCmNvbW1pdHRlZCB0byBiYXNlLiAgVW50aWwg dGhhdCBtYWtlcyBpdHMgd2F5IHRocm91Z2ggdGhlIHN5c3RlbSBpbnRvIGEgDQpyZWxlYXNl LCB5b3UgY2FuIHdvcmsgYXJvdW5kIHRoZSBwcm9ibGVtIGJ5IGNoYW5naW5nIHlvdXIgY29t bWFuZCB0bzoNCg0KL3Vzci9sb2NhbC9zYmluL3BrZyBxdWVyeSAtZSAnJSNyID09IDAnICcl bi0ldicNCg0KaWUuIGNhbGwgcGtnKDgpIGRpcmVjdGx5IHJhdGhlciB0aGFuIHZpYSBwa2co NykuDQoNCglDaGVlcnMsDQoNCglNYXR0aGV3DQoNCg== --------------v01SThGR8yMqPgfNx28X0Q5y-- --------------4G8bxojsbqJXf9XeHnj8xltF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEUFpMfPBIuRD0b2xnofG8vREsFw4FAmgZ0J4FAwAAAAAACgkQofG8vREsFw4Z HBAApgL8/edARBvmiTsUiwKKixSuLueKfQCpdIMCIWGetdyoc9EW0ZCdVXUY+N2hvq2KoRrb3ofc 0KvTrRp5OklvrFHaANy0QCgIzv6EPN+hzxqmZRWQbwEgz4CREFX9p6ZBDrTcFzXK0rrbjo17BtHE 6S0DvLnsJ7Vw1DfIakPCF0IB76s3z5ah6liGu0OtyG1qnu4VbvTIHhmTLw+NujOzerrrMz2OiMWB 9OY1+S9l+8WLOI7PEBz9bPsbMfT4PpqDgZIsUVCsHbdktcoaGIE2AFg0CTF0whQ1bv6onNcsRNIk dozzTcC052H6SV3Lmr+gw0aHWSfYGHQhE/CkZM7XgXVjY2puzMInaO+aO44+MdHmitTjZqUZV0hw FNq6nhgrqn1iM9RHos4Pocue93IhYn/0hi6JBzmKLEs2XRI+/b/a6Oz/xyhBStFtjoWFqLhafKRL h7snQc1rK6vJRktOP35yTxzQHmN57c59iyvuwLjHnx3YJYO77F8tUQ47VSvA7OgYz42Qu0SsumaN 5jD7O6cvwjA/D+wqHODsy6pyZHXVqohpld57/SsHfOeXkHSVhgi8VfGJKwh+8hofX2XJTngXhFBv SKHDriyIULGGK49sdybeQfU2U3Ry5dCJ0QzWj9x93HQKVuEGOCZRtimx/O8FBabcrbZeUnUD8BzU oc0= =9DCv -----END PGP SIGNATURE----- --------------4G8bxojsbqJXf9XeHnj8xltF-- From nobody Tue May 6 10:26: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 4ZsF1Q54kNz5vq41 for ; Tue, 06 May 2025 10:26:34 +0000 (UTC) (envelope-from SRS0=y2Sc=XW=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 4ZsF1Q3CBbz3XBX; Tue, 06 May 2025 10:26:34 +0000 (UTC) (envelope-from SRS0=y2Sc=XW=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview3.colo2.realworks.nl [10.2.52.33]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4ZsF1G5cd5z1FQ; Tue, 6 May 2025 12:26:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1746527186; 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=E+qfAtuQFeF1b79vkEPBwCtKT20+SSnG6NFfBPw+4+o=; b=RBJ9AVbgYzfSUYzs09cHokbkyy8xSpIBQC5Q5iVzUXfgCjiUWwII+OpFWV+11xFKQxKezh kchAj+Wyq0TLHal8V0xfBRSkjxZ0M9gxh6VbInr/0XLmgt2X94BoNZO52qFXoHFuxAChAk KXfL4t5Bz+Es4Kw/BD4Jp/WGtGqmhJh1yHI7d85XIbK2vspDtAW4xqdjgWrC9KR3sx1YtR D5g4XVET1eJ5XTDoyZJzyZUbX7L+QBQ3D4sPOP2gDsRnCqyt6d6SlCWa1NuEJfScaJync/ 2uNY2pYfcCjndTyW0MOaP6Ud4ptYbOIiYa6b37yyVMMqoung4ZTlyD8NsXsXrg== Received: from crmpreview3.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview3.colo2.realworks.nl (Postfix) with ESMTP id B9D761400AA; Tue, 6 May 2025 12:26:26 +0200 (CEST) Date: Tue, 6 May 2025 12:26:26 +0200 (CEST) From: Ronald Klop To: Matthew Seaman Cc: freebsd-current@freebsd.org Message-ID: <561432496.5693.1746527186471@localhost> In-Reply-To: <051b6c25-152a-4f4e-bcbb-c3efa5181acf@FreeBSD.org> References: <26F78444-4489-444A-87E3-63E24F21F091@gushi.org> <051b6c25-152a-4f4e-bcbb-c3efa5181acf@FreeBSD.org> Subject: Re: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977) 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_5692_197694020.1746527186117" X-Mailer: Realworks (748.20) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview3.colo2.realworks.nl [10.2.52.33] with HTTP; Tue, 06 May 2025 12:26:26 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0 X-Rspamd-Queue-Id: 4ZsF1Q3CBbz3XBX 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-Spamd-Bar: ---- ------=_Part_5692_197694020.1746527186117 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Matthew Seaman Datum: dinsdag, 6 mei 2025 11:04 Aan: freebsd-current@freebsd.org Onderwerp: Re: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977) > > On 06/05/2025 09:18, Dan Mahoney (Ports) wrote: > > For example, we've got a cron job on every box that gathers all our leaf packages into a file: > > > > #!/bin/sh > > /usr/sbin/pkg query -e '%#r == 0' '%n-%v' > > > > We now get warnings: > > > > # /usr/local/libexec/pkgleaf > > pkg: invalid option -- e > > > > (but the query still runs). > > > > Has anyone else seen this? > > This is pkg(7) struggling to parse options that it doesn't do anything with other than pass them through to the real pkg(8). > > As said elsewhere in the thread, a fix for the problem has been committed to base. Until that makes its way through the system into a release, you can work around the problem by changing your command to: > > /usr/local/sbin/pkg query -e '%#r == 0' '%n-%v' > > ie. call pkg(8) directly rather than via pkg(7). > > Cheers, > > Matthew > > > > > The bug has never been in any release. It was only in 15-CURRENT since April 30th. Regards, Ronald. ------=_Part_5692_197694020.1746527186117 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Matthew Seaman <matthew@FreeBSD.org>
Datum: dinsdag, 6 mei 2025 11:04
Aan: freebsd-current@freebsd.org
Onderwerp: Re: Recent changes to pkg argument parsing (https://reviews.freebsd.org/D49977)

On 06/05/2025 09:18, Dan Mahoney (Ports) wrote:
> For example, we've got a cron job on every box that gathers all our leaf packages into a file:
>
> #!/bin/sh
> /usr/sbin/pkg query -e '%#r == 0' '%n-%v'
>
> We now get warnings:
>
> # /usr/local/libexec/pkgleaf
> pkg: invalid option -- e
>
> (but the query still runs).
>
> Has anyone else seen this?

This is pkg(7) struggling to parse options that it doesn't do anything with other than pass them through to the real pkg(8).

As said elsewhere in the thread, a fix for the problem has been committed to base.  Until that makes its way through the system into a release, you can work around the problem by changing your command to:

/usr/local/sbin/pkg query -e '%#r == 0' '%n-%v'

ie. call pkg(8) directly rather than via pkg(7).

    Cheers,

    Matthew
 
 


The bug has never been in any release. It was only in 15-CURRENT since April 30th.

Regards,
Ronald.

  ------=_Part_5692_197694020.1746527186117-- From nobody Tue May 6 15:15:43 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 4ZsMRH3fCGz5txwB for ; Tue, 06 May 2025 15:15:55 +0000 (UTC) (envelope-from eduardo@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 4ZsMRH3Djnz3grT for ; Tue, 06 May 2025 15:15:55 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746544555; 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=VMALnJpg3XnmuGhDtESdDQLgb5rSq5X4pRFRJ3Dg9qY=; b=jB67L0FkBIeDt/i9osmPC49D2SFyMfuuZQsgyeigoqKy+7Ko93hJXm6mLYdFW49b72j4n4 hTTviS7Q/L8nYqYCsEA9BZaBcFb5cfBEHn9/9yTy291B5F1iHtYATFFQvQrMzDPgs0pxcm br5D6PQpvAA/rxsDodm3R2LYd0ego1b0Xy/HfmQCKrshpFwmFK+TSrDyXd1F94/hkgJEpx RaIquo/horoWVg2imMXQXfMI2DQacSTdMvkTXzxzsvRx1fRFl6pgpuH3/W8VQjyh22dIJI ZFXW6CEedAY4IWZlxQdqLBxCerSLMlj2FypyICIWPIzWmjJpsgnEn+UceO3tPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746544555; 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=VMALnJpg3XnmuGhDtESdDQLgb5rSq5X4pRFRJ3Dg9qY=; b=FLsWoHjRpVKk6ouvHqY5UOMkzOThrKzHvWpYo71hXLDRqnItXRgtiRYA42/0Lg50caMgvm /daxt34A2vorCDMaRzsK3FSZjYiCv2Pzr4qtNYLMMN02Fu4Xi7cHyARNo898dfjRwVJRIJ XC6muttRE0FKkZISE0CgdikXmq18x4KSJQpbAOegiS4uGVKKqwZs553x0ScxBUC+Jn2qft tEfRUWCeixg/T8HnmbuqKTFPNtyQ6OPk4F6zS7O0v6LITsmjjn7U9ai9H1XLfnzqyIpffm gqq6BI49mkKrzWCn1zQL8MK3WKqbCYDKQ21TTI392E3FTsW/rCNPskY9WIfi/w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746544555; a=rsa-sha256; cv=none; b=K23gYEBJkNRhJbEkoIULwWTLYTJPakaSX5Vt3RJfBu9SoO/8kZHDtC+iFnX9w5wZySTNzu khrJ+gSnNOOOIkhOj/ovGTSq3XI3gT0hmyCJosfBwiGyJWKrM1bwp30LQdQaA5r2ce6XrR N5VV0AD6JoUXiqo72dK8fi7cKpBmZtrJRSyO+iCtaF60MER4CKaSTZ4wi/Cht1be3On/aL KtHBvxm5I1EE96ESPUC/uSudxBhH9Iwe8QggoksrxRpqnxNKTl15hWm58S4WEc9uLfgDT/ 080Ikni0Jt8oLLpMd8OSCaxx8W/6Pea8l7/9lcjlCowHk3Ca75LzglR0dl3Dyg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZsMRH2m6fzrsk for ; Tue, 06 May 2025 15:15:55 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-476a2b5dffcso11833581cf.3 for ; Tue, 06 May 2025 08:15:55 -0700 (PDT) X-Gm-Message-State: AOJu0YyS4j5wPnnrH43ygl1Oxm2Wa3hI8mtLwSWy/hQKMG8maeMdrwd1 5k8ms6AQEoTBFr8cpZRmN6pVpNJdsABd0wegyU05T+SVu70FpM59yfKBo6B1ETcA5FrFUqbdM8G M60ZiTkkwdptNSZMRx3hph3cUvhU= X-Google-Smtp-Source: AGHT+IECeDky7P7PHTyJ+IV6uvcpgZHXWdOsG/Pp/IpAIPO1SChEVSX5YYhDD8VWApTANzV5rMzuPi7/WUoho4/FgNs= X-Received: by 2002:a05:622a:353:b0:476:af54:503f with SMTP id d75a77b69052e-48c30d7c6bbmr100013731cf.2.1746544554533; Tue, 06 May 2025 08:15:54 -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: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> In-Reply-To: <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> From: Nuno Teixeira Date: Tue, 6 May 2025 16:15:43 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUEGwZGOkC5Z2rg63sfazwDC4i146CkMEcL0rVD3A49FKSv_hwKdUBgC2Cg Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: Mark Millard Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000c1ed180634791702" --000000000000c1ed180634791702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mark, Definitely I'm not getting the results I want with WITH_META_MODE using BEs since most of the times I end up rebuilding almost everything in new BE. Should I stop using WITH_META_MODES a go straight to clean builds (clean /usr/obj) instead? My first concern is to speed up builds expecially on rpi4. Any hints are welcome. Thanks, Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s) 23:= 18): > Nuno Teixeira wrote on > Date: Mon, 05 May 2025 20:37:09 UTC : > > > (...) > > > > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess wit= h > > ports and stuff. > > > > Nuno Teixeira escreveu (segunda, 5/05/2025 =C3=A0= (s) > > 21:34): > > > > > Hello, > > > > > > Using incremental WITH_META_MODE builds, after installation with > > > beinstall.sh, building same src, a complete compilation happens. > > > > > > If someone uses this script, could you please do the following test: > > > > > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > > > filemon module loaded > > > > > > # cd /usr/src > > > # make buildworld-jobs buildkernel-jobs > > The above used older commands and files from before > the following install. META_MODE recorded the use of > those commands. > > Example .meta mode file content: > > # Meta data file > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/l= ibc++.a.meta > CMD @echo building static c++ library > CMD @rm -f libc++.a > CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o > charconv.o chrono.o condition_variable.o condition_variable_destructor.o > debug.o exception.o filesystem/directory_iterator.o filesyste > m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o > ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o > optional.o random.o random_shuffle.o regex.o shared_mutex.o > stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o > utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o > cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g > nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o > CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc= ++ > TARGET libc++.a > -- command output -- > building static c++ library > > -- filemon acquired metadata -- > # filemon version 5 > # Target pid 22471 > # Start 1611359217.214996 > V 5 > E 22961 /bin/sh > R 22961 /etc/libmap.conf > R 22961 /var/run/ld-elf.so.hints > R 22961 /lib/libedit.so.7 > R 22961 /lib/libc.so.7 > R 22961 /lib/libncursesw.so.9 > R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > F 22961 22962 > E 22962 > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/rm > R 22962 /etc/libmap.conf > R 22962 /var/run/ld-elf.so.hints > R 22962 /lib/libc.so.7 > R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE > D 22962 libc++.a > X 22962 0 0 > . . . > > So META_MODE has lots of files that were used > that it can later detect being newer than the > prior build results, leading to rebuilds based > on those newer files. > > > > # ./tools/build/beinstall.sh > > The new be will have various updated files > that could be different by content and, for > commands, could behave differently than those > used to do the prior build. Detecting newer > time stamps on such used files leads to > rebuild activity. > > More than /usr/src/ and /usr/obj/ content > are involved as well. > > Note that the new be is based on somewhat > different files than the original > buildworld-jobs buildkernel-jobs was based > on. > > > > # reboot > > > > > (I presume booting into the new be here.) > > > > # cd /usr/src > > > # make buildworld-jobs buildkernel-jobs > > META_MODE will notice when commands are used > that are newer than when the prior build was > done. Similarly for other files that may be > read. It will make sure that the newer commands > and files are allowed to produce new results > that potentially could be distinct in content > from what the old context produced for results. > > > > > > > Since src and obj are the same from one BE to newer BE, minimal > > > compilation should happen, not a full one. > > META_MODE is more careful than that. > > Note: I'm not claiming that new behavior that is > needed is likely for lots of the files with new > dates. But META_MODE is biased to avoiding leaving > in place something that should have been updated. > > > > > > > Am I missing something here? > > > > > Note that make has a -dM option: > > M Print debugging information about =E2=80=9Cmeta=E2= =80=9D mode > decisions > about targets. > > So, for example, > > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/awk' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cap_mkdb' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cat' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cp' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchgen' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchide' > is newer than the target... > file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/dd' > is newer than the target... > . . . > > Various . . ./tmp/legacy/. . ./*bin/ actually were > links to files. > > Ultimately buildworld then installworld lead to new > dates for a bunch of files used. Later use of > META_MODE notices such and rebuilds based on the > newer files. (It is a lot of detail to go through > it all.) > > Back in 2021 and 2023 I got help with exploring > avoiding lots of these. But, in the end, it > involved use of experimental code in > share/mk/src.sys.obj.mk to provide a new > definition to use to build some paths with. > > The experiments were an unsupported activity that > produced an unsupported change to allow > configurable enabling of taking risks with not > updating files that possibly should be updated. > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --000000000000c1ed180634791702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mark,

Definitely I'm not getting the results I want wi= th WITH_META_MODE using BEs since most of the times I end up rebuilding alm= ost everything in new BE.

Should I stop using WITH_META_MODES a go straight to clean build= s (clean /usr/obj) instead?
My first concern is to spe= ed up builds expecially on rpi4.

Any hints are welcome.
Thanks,


Mark Millard <marklmi@yahoo.com> escreveu (segunda, 5/05/2= 025 =C3=A0(s) 23:18):
Nuno Teixeira <eduardo_at_freebsd.org> wrote on
Date: Mon, 05 May 2025 20:37:09 UTC :

> (...)
>
> Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mes= s with
> ports and stuff.
>
> Nuno Teixeira <eduardo@freebsd.org> escreveu (segunda, 5/05/2025 =C3=A0(s)
> 21:34):
>
> > Hello,
> >
> > Using incremental WITH_META_MODE builds, after installation with<= br> > > beinstall.sh, building same src, a complete compilation happens.<= br> > >
> > If someone uses this script, could you please do the following te= st:
> >
> > WITH_META_MODE=3Dyes (/etc/src-env.conf)
> > filemon module loaded
> >
> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

The above used older commands and files from before
the following install. META_MODE recorded the use of
those commands.

Example .meta mode file content:

# Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd= 64/lib/libc++/libc++.a.meta
CMD @echo building static c++ library
CMD @rm -f libc++.a
CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o charconv.= o chrono.o condition_variable.o condition_variable_destructor.o debug.o exc= eption.o filesystem/directory_iterator.o filesyste
m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o io= s.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o optional.= o random.o random_shuffle.o regex.o shared_mutex.o
stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o utility= .o valarray.o variant.o vector.o cxxrt_auxhelper.o cxxrt_dynamic_cast.o cxx= rt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g
nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++=
TARGET libc++.a
-- command output --
building static c++ library

-- filemon acquired metadata --
# filemon version 5
# Target pid 22471
# Start 1611359217.214996
V 5
E 22961 /bin/sh
R 22961 /etc/libmap.conf
R 22961 /var/run/ld-elf.so.hints
R 22961 /lib/libedit.so.7
R 22961 /lib/libc.so.7
R 22961 /lib/libncursesw.so.9
R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE
F 22961 22962
E 22962 /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/le= gacy/usr/sbin/rm
R 22962 /etc/libmap.conf
R 22962 /var/run/ld-elf.so.hints
R 22962 /lib/libc.so.7
R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE
D 22962 libc++.a
X 22962 0 0
. . .

So META_MODE has lots of files that were used
that it can later detect being newer than the
prior build results, leading to rebuilds based
on those newer files.

> > # ./tools/build/beinstall.sh

The new be will have various updated files
that could be different by content and, for
commands, could behave differently than those
used to do the prior build. Detecting newer
time stamps on such used files leads to
rebuild activity.

More than /usr/src/ and /usr/obj/ content
are involved as well.

Note that the new be is based on somewhat
different files than the original
buildworld-jobs buildkernel-jobs was based
on.

> > # reboot
> >

(I presume booting into the new be here.)

> > # cd /usr/src
> > # make buildworld-jobs buildkernel-jobs

META_MODE will notice when commands are used
that are newer than when the prior build was
done. Similarly=C2=A0 for other files that may be
read. It will make sure that the newer commands
and files are allowed to produce new results
that potentially could be distinct in content
from what the old context produced for results.

> >
> > Since src and obj are the same from one BE to newer BE, minimal > > compilation should happen, not a full one.

META_MODE is more careful than that.

Note: I'm not claiming that new behavior that is
needed is likely for lots of the files with new
dates. But META_MODE is biased to avoiding leaving
in place something that should have been updated.

> >
> > Am I missing something here?
> >

Note that make has a -dM option:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M=C2=A0 =C2=A0 =C2=A0 =C2= =A0Print debugging information about =E2=80=9Cmeta=E2=80=9D mode decisions<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0about targets.

So, for example,

file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/awk' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cap_mkdb' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cat' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/cp' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchgen' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/crunchide' is newer than the target...
file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/= legacy/usr/sbin/dd' is newer than the target...
. . .

Various . . ./tmp/legacy/. . ./*bin/ actually were
links to files.

Ultimately buildworld then installworld lead to new
dates for a bunch of files used. Later use of
META_MODE notices such and rebuilds based on the
newer files. (It is a lot of detail to go through
it all.)

Back in 2021 and 2023 I got help with exploring
avoiding lots of these. But, in the end, it
involved use of experimental code in
share/mk/src.sys.obj.mk to provide a new
definition to use to build some paths with.

The experiments were an unsupported activity that
produced an unsupported change to allow
configurable enabling of taking risks with not
updating files that possibly should be updated.

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



--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--000000000000c1ed180634791702-- From nobody Tue May 6 16:52: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 4ZsPZd0Nnrz5v5cZ for ; Tue, 06 May 2025 16:52:25 +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 4ZsPZb2Qdbz3RVR for ; Tue, 06 May 2025 16:52:23 +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=1746550341; bh=eWxHYNhvU3NeRe5wRpm0RzaMOpvRDqnfj/8E/wBEBsA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZrNgf+b6KbiQTSgrY1yOt3l4E6Ktmq99xMRXSAm12a4XxoReupqNUIsqILhJBTFfJdQCC7uXBDWk06KDWhdgwiIELlrbmjaYYt0+fTKaLT8ylkcoZqZxSFfAlFt+RQhI0BB9VOgCA+MH/zM2IT8HKM6pNiBGHIjZPpQUHGWLN9kIOPg7mzo4a23aDbaEbDHAu9EHKJRJ6v6/6w8LL9YXMPIN9qA6keSOLutjhy01l5/xkeaTI9vq7aUVdjMO6y+FBRNEZmdxlTtRwT2V/t4ixnVMdDlsNQ9PnoFxSY4I2eUjg5jRIVcWB35DDJdJGpp3MUBe3MizJmwZNh7ZTjXwrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746550341; bh=i40TLu9Yem7IJ335mqQA0pikWR9DsAeTipHP31ZF9sW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gr7e5gmkX34pZONyEha4T7rMJUk0bHbPvbDsMkbfY1xRXMlksXGTFU3TV0Mr232C1kG9446uSBXvp6TMW+TwKIQaU+4vWRsDOBMDpQJvcg5NIkdYrsCZgH3RwaNTg2hfkVnPrfknfzwaIomtPRvvhH9Ga+CI4Gh9TF1vp/BCSBvss/n4mjlB6UlL/pmgTcDH86eAB4fYF8xtQACupa4qrLj8z8KR+95o5YIQdV6ch3TVZyvLzYTUgUNtOee1bgfc7+Y6QlaP6iHzzuI8cOZgZ5VhzBGAV5F+7/NiaFwFOVVaAUO94ipZdq2RTcZZWzdLSHlMMzoaUDSc0guEdqHK8g== X-YMail-OSG: 4Hvo1XMVM1mlTAMAYd4knWjnFC_OqrEtSduBu_Dg2fnEoc9KI6_ERpb1f4CZtUW EaHixM9wshwd39qo6tujM9ev8BiO6Im_rtHXYTXQd3OcaJZGgtKfFte4.FMXwUsip8ZDQoCR.NtO i7enBN1FYwNytdE3Pu2mg5NtNqmV8eonjT2jD0CArExsLiYF7vL7WeV7Va1NA0A4In47diUpGwUm vZPupGcEDdF0dq2xz8OHKUlAkcTFtXCw438kG0SPlaiIh.QJZqfBH6S003HhlK5lTqigAMWR8nyo fsuTREMOb0b6Kp3x7AyflQ1cG1CTsTt0L6rOFm96bcEfkirBJmRRuRTFe0yTKcvv4Trqmxy9nW8E OGoppUj3TEyrulK9Ac6.Gj1x66fr2dybgR_xlCduql9t41UyARbF1tM20CHiOFkeHgtlvxcBuH.8 av6P70iUwTvyXEVjvMMGAELODzafWw2xpbc.GzdgTVDYX9AwWjs5Az6Cp_kCu85XEB8XEsgHsxCz mDeE1A2EB7uSqLnHncn5d84_g46.UUBA9SxL4vQDsm5A1B4NhGno.YboWC0ch_HGaQWIsjFd4QyI hwVXBLCJAiPoFzw6G_gPk0S8QeYxzrcXRS.XOC_AILkNQnIG9zuwVt8v8kR7_XRDTMA7AKWtJl_e DmTKtTby3auuzFsPO1_jfCokRQZx0ZrCPCNWuoT0Xh9ZP.zkjR89LmyYJp1LzrjxjA5cKQtVCAG0 4A5LvFTuJbWwLxEP0nP3pL3RoZiCyusODi_BVpTXt_xIx2NAj_26bmNJrkhBmz5lex5sGwDWjGMw j9GgDD62q7MMSNaRdBIxcjXwgeNQDcIC754PxpdcUoLY8dQJ1d6qvzmx_zijIikeJ23BeYUmEF_J yqkvBK4Yox8xGhxgU7ZpzPj8SSyU82tSa4aZ1vqlm10YEOHkXACz0bRfVdcH9CMnzbqc1RxvpUum BgR8rvAiRrcKYf4RCCvXe09bfgk1bc54fLmDR0RPDMOPpryfmgqQWnap7gseYG5SNLFjN8jAd8Ew x5sYj1BWR7QNrSmtrxJmUIUPVt7PN81wZBt4Q_j3.FaVd5UPiNgtuFVv6KyU9kJWdHworimPk6R7 r1Z6U7VSINscMfr.JrrIyFtaFQ7h46_83VVQWlqWv3d_uGvCY1Q8NnkivOynSkg8KRKDEUns_Y8Y ISt0CdvAa2_SlXO4Pu7QFCHPuVh_AsCe8fLsFb0xtS2LOeqWybzFIGYCpi6Fpdlcn0Z1xFgpLf9O UEcNdicFSNnQiI.AtP0adWBgAAIxRj2FB.LObxHnfWGaltxXNlHbJ1SNNCcuXUmg1j9buyhVNDfW 6bARkpyFJzYXVnOf3ecFj7a0ZxQSBVGs4OtYJmaE6IAeea9.ZNkP1rBRO3PpBlEDLxWeaheKNYPH oqHc9Arq4Xxv888htnVzDJLBMlvexxE.oVZrfunRHGRJsK8yXJkaKo6WVOwrKITc2JUPW_2xqJWH owXuJrzUM0R2UT6_2Jeu8jkLUjFb.iluEmszmKwvzfEVozL8P339oYlgvn6tE8yULp6HtXv8wRiR dgNlSRxzrQ_g0YaA_WrCjBwN35Sw2WBhggr0sjh49BD_y3l1FFJouyE6i37PdsoFeE0qnB9265r1 bSTQbvmelb0HZxwIPD8IJBWPyhANLRIvAoJX1Js5LmnzuqnOev.DqVgiPe3T0Uoo9boh0LTzK4_1 Pb9EUrHoGVGLIkAqorUMSPaSleoX4MP5WYdD8Orli6mmckwU8p_9JYMhx1G_K0eQQCq5Nyk_29qY X5SltGaz6MwPbwW5LmeI7DivHAcaAgSLpGp3bGIgNC11GLUkMjCgWhWK9eWntAXqvOckXox8mxc7 AxEcvbOCEO0pQPz6ICqzNkyhydTfziCeACYDKWpduno0Pc_Z68Kjl9j0nXbz7HxoHpDjje2ARsTn 6tZaYzs13nBUBawk.2a1dQooSmZA84MSTm2AMrREZDekUJIuMELJb7UgW.wuiDN7kZaryHcvTj0n nyhOmFHswoAlpZ0eswm1qdFUUJ1.6iztcGNHCbdDZsAWQE3RZedkq8pMRl5bFzow7cde66Twm5fa w9c6p2Ix.a_ho45eSl0qRdPLpIBAbrsLaHvoXeXhSUOBTwWkB72HXPxP0RPCevZFPQWGjR7L2n2B pn4c86HMpRD7hc5mgvSeMNwoIDfGLvCIYSa2bYc1.qJawpl8oX9I.tOAFUtN_nQBJUAWkjergYlN tlL38HYq1egf7061GsJKuhzhqnZAY9mG8lbOT2IvRF5WdEXK6P0P1Y0oe1gzn7pb.Nms1odEGS9X k3w-- X-Sonic-MF: X-Sonic-ID: 6a27a58b-14a5-4594-9788-828f3c2a1b26 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 May 2025 16:52:21 +0000 Received: by hermes--production-gq1-74d64bb7d7-w6q4t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9d8d96419fa4097a07b126af600d74ea; Tue, 06 May 2025 16:52:18 +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: incremental bulds from scratch with beinstall.sh From: Mark Millard In-Reply-To: Date: Tue, 6 May 2025 09:52:08 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <5BFEF4D2-0E42-46ED-899B-D27169DFC322@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4ZsPZb2Qdbz3RVR 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-Spamd-Bar: ---- On May 6, 2025, at 08:15, Nuno Teixeira wrote: > Hello Mark, >=20 > Definitely I'm not getting the results I want with WITH_META_MODE = using BEs since most of the times I end up rebuilding almost everything = in new BE. >=20 > Should I stop using WITH_META_MODES a go straight to clean builds = (clean /usr/obj) instead? If by "clean" you mean doing some form of "rm -fr" on all or part of what is by default somewhere under /usr/ob/ : You likely would be deleting files that would be regenerated during a build instead of any of those being reused. May be I've guess wrong about what you mean by "clean /usr/obj"? I'll note that I've never used ccache or the like: https://man.freebsd.org/cgi/man.cgi?query=3Dccache&sektion=3D1&n=3D1 I expect that there are others that have that might comment about such setups. But going in another direction: I do not know why you are doing your own builds instead of using pre-built materials, such as PkgBase's base_latest (updated multiple times per day, not that you need to do updates from it that often) or base_weekly (again, you might not update as often). Do you have local modifications of the system source that you are building? (That could mean not using PkgBase materials, for example.) Just kernel updates? Just world updates? Both? Neither? I also do not know if you build your own packages/ports. So I do not even known if you need a toolchain. Do you need to do package/port builds to get security updates sooner or some such? Can you comment on what has to be true of your system environment(s) for such (even if it in turn means build times that you do not like have to be involved)? Delimiting the tradeoff structure requirements might help in picking a path. A RPi4 specific note: One core on the RPi4B executing code for which the L1 (smallest) level cache is ineffective can saturate its memory subsystem. Depending on details I've had experiments in normal system build activity where using -j3 instead of -j4 or more actually took somewhat less time overall. (Not that the differences were huge or anything. And they might not be systematic. But -j3 can also help if there are also memory usage tradeoffs that need to be managed. Does the RPi4 have 8 GiBytes of RAM? 4 GiByte? 2 GiByte?) A note on official PkgBase build use: The below illustrates that it is possible to mix official PkgBase and personal system builds in some ways. Not that it is on RPi4B's, but I have both PkgBase kernels and my own kernel builds and use /boot/loader.conf to pick which is the default for booting. I do not boot kernels that are older than the boot world on the media. I boot a PkgBase world and have directory trees for chroot or other such use with my personal world builds, some have my personal package builds installed and others have official package builds installed. I only use my personal world builds with my personal kernel builds. (They are matched.) I never use my personal kernel build when it is older than the PkgBase kernel or world that I use. This means my personal kernel build supports booting the PkgBase based world when I use that kernel. Overall I can investigate if any problems I run into are reproducible without my system or package builds involved. I have various poudriere(-devel) jails, some use official PkgBase based jails and others are using my personal builds for the jail content: # poudriere jail -l JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-05-05 22:11:10 /usr/local/poudriere/jails/release-aarch64 release-armv7 14.2-RELEASE-p2 armv7 pkgbase = 2025-03-13 21:50:17 /usr/local/poudriere/jails/release-armv7 official-aarch64 14.2-STABLE aarch64 pkgbase = 2025-05-05 22:13:47 /usr/local/poudriere/jails/official-aarch64 official-armv7 14.2-STABLE armv7 pkgbase = 2025-03-13 21:47:04 /usr/local/poudriere/jails/official-armv7 main-aarch64 15.0-CURRENT aarch64 pkgbase = 2025-05-05 22:15:30 /usr/local/poudriere/jails/main-aarch64 main-CA76 15.0-CURRENT arm64.aarch64 null = 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud main-CA76-bulk_a 15.0-CURRENT arm64.aarch64 null = 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud-bulk_a main-CA7 15.0-CURRENT arm.armv7 null = 2025-02-20 18:16:55 /usr/obj/DESTDIRs/main-CA7-poud main-CA7-bulk_a 15.0-CURRENT arm.armv7 null = 2025-02-20 18:16:56 /usr/obj/DESTDIRs/main-CA7-poud-bulk_a main-armv7 15.0-CURRENT armv7 pkgbase = 2025-03-14 22:48:11 /usr/local/poudriere/jails/main-armv7 # poudriere jail -l JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP = PATH release-amd64 14.2-RELEASE-p2 amd64 pkgbase 2025-05-05 = 22:19:47 /usr/local/poudriere/jails/release-amd64 official-amd64 14.2-STABLE amd64 pkgbase 2025-05-05 = 22:21:46 /usr/local/poudriere/jails/official-amd64 main-ZNV4 15.0-CURRENT amd64 null 2025-02-12 = 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud main-ZNV4-bulk_a 15.0-CURRENT amd64 null 2025-02-12 = 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud-bulk_a main-ZNV4-dbg 15.0-CURRENT amd64 null 2025-04-02 = 09:20:08 /usr/obj/DESTDIRs/main-ZNV4-poud-dbg main-amd64 15.0-CURRENT amd64 pkgbase 2025-05-05 = 22:26:12 /usr/local/poudriere/jails/main-amd64 (I've never bothered with i386 in amd64 contexts and have never used FreeBSD on an actual i386 class system.) > My first concern is to speed up builds expecially on rpi4. Per some prior questions: What other constraints must also be met? > Any hints are welcome. >=20 > Thanks, >=20 >=20 > Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s) = 23:18): >> Nuno Teixeira wrote on >> Date: Mon, 05 May 2025 20:37:09 UTC : >>=20 >> > (...) >> >=20 >> > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess = with >> > ports and stuff. >> >=20 >> > Nuno Teixeira escreveu (segunda, 5/05/2025 = =C3=A0(s) >> > 21:34): >> >=20 >> > > Hello, >> > > >> > > Using incremental WITH_META_MODE builds, after installation with >> > > beinstall.sh, building same src, a complete compilation happens. >> > > >> > > If someone uses this script, could you please do the following = test: >> > > >> > > WITH_META_MODE=3Dyes (/etc/src-env.conf) >> > > filemon module loaded >> > > >> > > # cd /usr/src >> > > # make buildworld-jobs buildkernel-jobs >>=20 >> The above used older commands and files from before >> the following install. META_MODE recorded the use of >> those commands. >>=20 >> Example .meta mode file content: >>=20 >> # Meta data file = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/li= bc++.a.meta >> CMD @echo building static c++ library >> CMD @rm -f libc++.a >> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o = charconv.o chrono.o condition_variable.o condition_variable_destructor.o = debug.o exception.o filesystem/directory_iterator.o filesyste >> m/int128_builtins.o filesystem/operations.o functional.o future.o = hash.o ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o = new.o optional.o random.o random_shuffle.o regex.o shared_mutex.o >> stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o = utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o = cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o = cxxrt_libelftc_dem_g >> nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o = cxxrt_typeinfo.o >> CWD = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++ >> TARGET libc++.a >> -- command output -- >> building static c++ library >>=20 >> -- filemon acquired metadata -- >> # filemon version 5 >> # Target pid 22471 >> # Start 1611359217.214996 >> V 5 >> E 22961 /bin/sh >> R 22961 /etc/libmap.conf >> R 22961 /var/run/ld-elf.so.hints >> R 22961 /lib/libedit.so.7 >> R 22961 /lib/libc.so.7 >> R 22961 /lib/libncursesw.so.9 >> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE >> F 22961 22962 >> E 22962 = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/rm >> R 22962 /etc/libmap.conf >> R 22962 /var/run/ld-elf.so.hints >> R 22962 /lib/libc.so.7 >> R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE >> D 22962 libc++.a >> X 22962 0 0 >> . . . >>=20 >> So META_MODE has lots of files that were used >> that it can later detect being newer than the >> prior build results, leading to rebuilds based >> on those newer files. >>=20 >> > > # ./tools/build/beinstall.sh >>=20 >> The new be will have various updated files >> that could be different by content and, for >> commands, could behave differently than those >> used to do the prior build. Detecting newer >> time stamps on such used files leads to >> rebuild activity. >>=20 >> More than /usr/src/ and /usr/obj/ content >> are involved as well. >>=20 >> Note that the new be is based on somewhat >> different files than the original >> buildworld-jobs buildkernel-jobs was based >> on. >>=20 >> > > # reboot >> > > >>=20 >> (I presume booting into the new be here.) >>=20 >> > > # cd /usr/src >> > > # make buildworld-jobs buildkernel-jobs >>=20 >> META_MODE will notice when commands are used >> that are newer than when the prior build was >> done. Similarly for other files that may be >> read. It will make sure that the newer commands >> and files are allowed to produce new results >> that potentially could be distinct in content >> from what the old context produced for results. >>=20 >> > > >> > > Since src and obj are the same from one BE to newer BE, minimal >> > > compilation should happen, not a full one. >>=20 >> META_MODE is more careful than that. >>=20 >> Note: I'm not claiming that new behavior that is >> needed is likely for lots of the files with new >> dates. But META_MODE is biased to avoiding leaving >> in place something that should have been updated. >>=20 >> > > >> > > Am I missing something here? >> > > >>=20 >> Note that make has a -dM option: >>=20 >> M Print debugging information about =E2=80=9Cmeta=E2= =80=9D mode decisions >> about targets. >>=20 >> So, for example, >>=20 >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk' is newer than the target... >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cap_mkdb' is newer than the target... >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cat' is newer than the target... >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cp' is newer than the target... >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchgen' is newer than the target... >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchide' is newer than the target... >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/dd' is newer than the target... >> . . . >>=20 >> Various . . ./tmp/legacy/. . ./*bin/ actually were >> links to files. >>=20 >> Ultimately buildworld then installworld lead to new >> dates for a bunch of files used. Later use of >> META_MODE notices such and rebuilds based on the >> newer files. (It is a lot of detail to go through >> it all.) >>=20 >> Back in 2021 and 2023 I got help with exploring >> avoiding lots of these. But, in the end, it >> involved use of experimental code in >> share/mk/src.sys.obj.mk to provide a new >> definition to use to build some paths with. >>=20 >> The experiments were an unsupported activity that >> produced an unsupported change to allow >> configurable enabling of taking risks with not >> updating files that possibly should be updated. >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 6 17:47: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 4ZsQpR5GwWz5v96X for ; Tue, 06 May 2025 17:47:43 +0000 (UTC) (envelope-from eduardo@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 4ZsQpR4WCDz41L0 for ; Tue, 06 May 2025 17:47:43 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746553663; 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=hurQNVf+CbxuRhxDjYIX8a/Q3hwACN1I/DiKq18xkOU=; b=YrcX4wMzxcjBn4VHmnCVUwCRaMuq7DxI6oPXzidwFW4Yuu3n8ZWqvkEiMRpms23mRJmF/G obXXcgkBLJ+QgJjI8VocXaxfV6liN2Tal7yj/gGPop5kIDlp7ObyY/y7jvMivZpHrPE3M6 3rKdk7JetYeVE5e8rYym1K9gGzqOG6+4/iu9vhMsq6NyPF7Vl14XFZlO6S/zGJCicjnXsf 0gSFpFioUMOojyRoGe9xZI00rZ2rBJUM429V7Rq4B1l8yvwv5HXU8RMSH2oww/+ZF+USs6 /SBi70Zik74F9cV0oszBJZd/LQkaeV4dMeqwwkUoK479RxxMW4W6OqkgIc3Hqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746553663; 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=hurQNVf+CbxuRhxDjYIX8a/Q3hwACN1I/DiKq18xkOU=; b=emIeCYeBAEkjwOMOlk+DW3FfGZekfALb/n/QeqM1Z7Rsnj51KM2GhGKWy3zc05mEWJVun+ HzK1DlDXim+bH5bDJCqUolk9MrRHp1zG32KEyK1b98lX/3U5fKsce2a2fuyvIlHGnJ6KWb /Imgy3kM8IBj+J/XczhAUrpzny+j3yM/SGRRcqkbnQo0SJCQKhnwK28Augy0tGFllJgvin 8xAFApkkeX52epkjSTLYXu9f7groshXdWhKMU4IPWa+33tWbuduo13WEfH2TJ8qTJtBHRr HQdlwCNaRJ+piHfTQQCWaGLJ9c5s8ETlJYS/gQIKor1fScpD1rc01oYi48SY+A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746553663; a=rsa-sha256; cv=none; b=gpBHdZq9ZnAOlxtvqLTUjRGez0vrtoiMAWFWOhl5Pg+I0WiEDBDlk1oS6Vc8mK1q2qjhnq k5f0kcHcrbVd3Q7SQkFCXTyvTL6AFSok5i5TA6KLX1oE17j/M0L3Crh3srjeF0JZLVfwUW IPwfB6wjNgzrxg5tzWM7RZLaGzniGWVQXuayAhIFkbxMOgJWRsT878OVCzrVZ8DoqtV3sS WyEUuTb8AfXn4lsAq/rY5wl276C2tUX4KAcqTsOvSdTommNdWPNnxl1FXdqmie7IhPp13N yrJVDax8Yn2g+Hfhh0AGc/tb5bClmMwdBaXSxZLcPbJFKaZSoGOuz80mUkTUOw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZsQpR3lQHzvHr for ; Tue, 06 May 2025 17:47:43 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-7c964e8710eso45083285a.0 for ; Tue, 06 May 2025 10:47:43 -0700 (PDT) X-Gm-Message-State: AOJu0YzQ/0cjVBfzGplbf7uaIHEYbeTc7xhXiI53StPYQXJUpBgWsW5Y 66de0+wXgNIrVAq5KrrYROJX+IcLQLjyssYDIC4ubksY2hSon6pIQ8qhZm0qEi9n1F/KdiptsOf 4rjLetQdl8YIU4oYsBj28us4x11M= X-Google-Smtp-Source: AGHT+IHTz47Ql67pMiwaiug9uvL0tKp9jhJDqHIfSSoP9CnzG5FtN5IEExGtDbkcXYo42O9zh2YaWDu6onB2u2oD9xs= X-Received: by 2002:a05:622a:44c:b0:474:f601:c21e with SMTP id d75a77b69052e-49225a41fedmr306211cf.5.1746553663095; Tue, 06 May 2025 10:47: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: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <5BFEF4D2-0E42-46ED-899B-D27169DFC322@yahoo.com> In-Reply-To: <5BFEF4D2-0E42-46ED-899B-D27169DFC322@yahoo.com> From: Nuno Teixeira Date: Tue, 6 May 2025 18:47:32 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUEWnILb0icAQyIlycTvuhD6_aMf5GEhBKzj6_ZNSZj98v_z-jxxygliOL0 Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: Mark Millard Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000ab8a0e06347b3674" --000000000000ab8a0e06347b3674 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello! I use CURRENT on my laptop and rpi4 for some time now. I like to see changes in src tree and then rebuild world and test for myself. One of the things that attracts me is building and rebuilding stuff and maybe that's why I'm so happy as a ports committer :) The only "change" that I do in build world is: /etc/src.conf: WITH_MALLOC_PRODUCTION=3Dyes WITHOUT_LLVM_ASSERTIONS=3Dyes that might be incompatible with pkgbase since those settings are for releases. Cheers, Mark Millard escreveu (ter=C3=A7a, 6/05/2025 =C3=A0(s) = 17:52): > On May 6, 2025, at 08:15, Nuno Teixeira wrote: > > > Hello Mark, > > > > Definitely I'm not getting the results I want with WITH_META_MODE using > BEs since most of the times I end up rebuilding almost everything in new = BE. > > > > Should I stop using WITH_META_MODES a go straight to clean builds (clea= n > /usr/obj) instead? > > If by "clean" you mean doing some form of "rm -fr" on all > or part of what is by default somewhere under /usr/ob/ : > You likely would be deleting files that would be > regenerated during a build instead of any of those being > reused. > > May be I've guess wrong about what you mean by "clean > /usr/obj"? > > I'll note that I've never used ccache or the like: > > https://man.freebsd.org/cgi/man.cgi?query=3Dccache&sektion=3D1&n=3D1 > > I expect that there are others that have that might > comment about such setups. > > But going in another direction: I do not know why you are > doing your own builds instead of using pre-built materials, > such as PkgBase's base_latest (updated multiple times per > day, not that you need to do updates from it that often) > or base_weekly (again, you might not update as often). > > Do you have local modifications of the system source that > you are building? (That could mean not using PkgBase > materials, for example.) Just kernel updates? Just > world updates? Both? Neither? > > I also do not know if you build your own packages/ports. So > I do not even known if you need a toolchain. Do you need > to do package/port builds to get security updates sooner > or some such? > > Can you comment on what has to be true of your system > environment(s) for such (even if it in turn means build > times that you do not like have to be involved)? > Delimiting the tradeoff structure requirements might help > in picking a path. > > > A RPi4 specific note: > > One core on the RPi4B executing code for which the L1 > (smallest) level cache is ineffective can saturate its > memory subsystem. Depending on details I've had > experiments in normal system build activity where using > -j3 instead of -j4 or more actually took somewhat less > time overall. (Not that the differences were huge or > anything. And they might not be systematic. But -j3 can > also help if there are also memory usage tradeoffs that > need to be managed. Does the RPi4 have 8 GiBytes of RAM? > 4 GiByte? 2 GiByte?) > > > A note on official PkgBase build use: > > The below illustrates that it is possible to mix > official PkgBase and personal system builds in some > ways. > > Not that it is on RPi4B's, but I have both PkgBase > kernels and my own kernel builds and use > /boot/loader.conf to pick which is the default > for booting. I do not boot kernels that are > older than the boot world on the media. > > I boot a PkgBase world and have directory trees for > chroot or other such use with my personal world > builds, some have my personal package builds > installed and others have official package builds > installed. > > I only use my personal world builds with my personal > kernel builds. (They are matched.) I never use my > personal kernel build when it is older than the > PkgBase kernel or world that I use. This means > my personal kernel build supports booting the > PkgBase based world when I use that kernel. > > Overall I can investigate if any problems I run into > are reproducible without my system or package builds > involved. > > I have various poudriere(-devel) jails, some use > official PkgBase based jails and others are using my > personal builds for the jail content: > > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD > TIMESTAMP PATH > release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase > 2025-05-05 22:11:10 /usr/local/poudriere/jails/release-aarch64 > release-armv7 14.2-RELEASE-p2 armv7 pkgbase > 2025-03-13 21:50:17 /usr/local/poudriere/jails/release-armv7 > official-aarch64 14.2-STABLE aarch64 pkgbase > 2025-05-05 22:13:47 /usr/local/poudriere/jails/official-aarch64 > official-armv7 14.2-STABLE armv7 pkgbase > 2025-03-13 21:47:04 /usr/local/poudriere/jails/official-armv7 > main-aarch64 15.0-CURRENT aarch64 pkgbase > 2025-05-05 22:15:30 /usr/local/poudriere/jails/main-aarch64 > main-CA76 15.0-CURRENT arm64.aarch64 null > 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud > main-CA76-bulk_a 15.0-CURRENT arm64.aarch64 null > 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud-bulk_a > main-CA7 15.0-CURRENT arm.armv7 null > 2025-02-20 18:16:55 /usr/obj/DESTDIRs/main-CA7-poud > main-CA7-bulk_a 15.0-CURRENT arm.armv7 null > 2025-02-20 18:16:56 /usr/obj/DESTDIRs/main-CA7-poud-bulk_a > main-armv7 15.0-CURRENT armv7 pkgbase > 2025-03-14 22:48:11 /usr/local/poudriere/jails/main-armv7 > > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP > PATH > release-amd64 14.2-RELEASE-p2 amd64 pkgbase 2025-05-05 > 22:19:47 /usr/local/poudriere/jails/release-amd64 > official-amd64 14.2-STABLE amd64 pkgbase 2025-05-05 > 22:21:46 /usr/local/poudriere/jails/official-amd64 > main-ZNV4 15.0-CURRENT amd64 null 2025-02-12 > 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud > main-ZNV4-bulk_a 15.0-CURRENT amd64 null 2025-02-12 > 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud-bulk_a > main-ZNV4-dbg 15.0-CURRENT amd64 null 2025-04-02 > 09:20:08 /usr/obj/DESTDIRs/main-ZNV4-poud-dbg > main-amd64 15.0-CURRENT amd64 pkgbase 2025-05-05 > 22:26:12 /usr/local/poudriere/jails/main-amd64 > > (I've never bothered with i386 in amd64 contexts and > have never used FreeBSD on an actual i386 class system.) > > > My first concern is to speed up builds expecially on rpi4. > > Per some prior questions: What other constraints must > also be met? > > > Any hints are welcome. > > > > Thanks, > > > > > > Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s) > 23:18): > >> Nuno Teixeira wrote on > >> Date: Mon, 05 May 2025 20:37:09 UTC : > >> > >> > (...) > >> > > >> > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not mess = with > >> > ports and stuff. > >> > > >> > Nuno Teixeira escreveu (segunda, 5/05/2025 =C3= =A0(s) > >> > 21:34): > >> > > >> > > Hello, > >> > > > >> > > Using incremental WITH_META_MODE builds, after installation with > >> > > beinstall.sh, building same src, a complete compilation happens. > >> > > > >> > > If someone uses this script, could you please do the following tes= t: > >> > > > >> > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > >> > > filemon module loaded > >> > > > >> > > # cd /usr/src > >> > > # make buildworld-jobs buildkernel-jobs > >> > >> The above used older commands and files from before > >> the following install. META_MODE recorded the use of > >> those commands. > >> > >> Example .meta mode file content: > >> > >> # Meta data file > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/l= ibc++.a.meta > >> CMD @echo building static c++ library > >> CMD @rm -f libc++.a > >> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o > charconv.o chrono.o condition_variable.o condition_variable_destructor.o > debug.o exception.o filesystem/directory_iterator.o filesyste > >> m/int128_builtins.o filesystem/operations.o functional.o future.o > hash.o ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.= o > optional.o random.o random_shuffle.o regex.o shared_mutex.o > >> stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o > utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o > cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g > >> nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o > cxxrt_typeinfo.o > >> CWD > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++ > >> TARGET libc++.a > >> -- command output -- > >> building static c++ library > >> > >> -- filemon acquired metadata -- > >> # filemon version 5 > >> # Target pid 22471 > >> # Start 1611359217.214996 > >> V 5 > >> E 22961 /bin/sh > >> R 22961 /etc/libmap.conf > >> R 22961 /var/run/ld-elf.so.hints > >> R 22961 /lib/libedit.so.7 > >> R 22961 /lib/libc.so.7 > >> R 22961 /lib/libncursesw.so.9 > >> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > >> F 22961 22962 > >> E 22962 > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/rm > >> R 22962 /etc/libmap.conf > >> R 22962 /var/run/ld-elf.so.hints > >> R 22962 /lib/libc.so.7 > >> R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE > >> D 22962 libc++.a > >> X 22962 0 0 > >> . . . > >> > >> So META_MODE has lots of files that were used > >> that it can later detect being newer than the > >> prior build results, leading to rebuilds based > >> on those newer files. > >> > >> > > # ./tools/build/beinstall.sh > >> > >> The new be will have various updated files > >> that could be different by content and, for > >> commands, could behave differently than those > >> used to do the prior build. Detecting newer > >> time stamps on such used files leads to > >> rebuild activity. > >> > >> More than /usr/src/ and /usr/obj/ content > >> are involved as well. > >> > >> Note that the new be is based on somewhat > >> different files than the original > >> buildworld-jobs buildkernel-jobs was based > >> on. > >> > >> > > # reboot > >> > > > >> > >> (I presume booting into the new be here.) > >> > >> > > # cd /usr/src > >> > > # make buildworld-jobs buildkernel-jobs > >> > >> META_MODE will notice when commands are used > >> that are newer than when the prior build was > >> done. Similarly for other files that may be > >> read. It will make sure that the newer commands > >> and files are allowed to produce new results > >> that potentially could be distinct in content > >> from what the old context produced for results. > >> > >> > > > >> > > Since src and obj are the same from one BE to newer BE, minimal > >> > > compilation should happen, not a full one. > >> > >> META_MODE is more careful than that. > >> > >> Note: I'm not claiming that new behavior that is > >> needed is likely for lots of the files with new > >> dates. But META_MODE is biased to avoiding leaving > >> in place something that should have been updated. > >> > >> > > > >> > > Am I missing something here? > >> > > > >> > >> Note that make has a -dM option: > >> > >> M Print debugging information about =E2=80=9Cmeta= =E2=80=9D mode > decisions > >> about targets. > >> > >> So, for example, > >> > >> file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/awk' > is newer than the target... > >> file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cap_mkdb' > is newer than the target... > >> file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cat' > is newer than the target... > >> file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/cp' > is newer than the target... > >> file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchgen' > is newer than the target... > >> file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/crunchide' > is newer than the target... > >> file > '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/= usr/sbin/dd' > is newer than the target... > >> . . . > >> > >> Various . . ./tmp/legacy/. . ./*bin/ actually were > >> links to files. > >> > >> Ultimately buildworld then installworld lead to new > >> dates for a bunch of files used. Later use of > >> META_MODE notices such and rebuilds based on the > >> newer files. (It is a lot of detail to go through > >> it all.) > >> > >> Back in 2021 and 2023 I got help with exploring > >> avoiding lots of these. But, in the end, it > >> involved use of experimental code in > >> share/mk/src.sys.obj.mk to provide a new > >> definition to use to build some paths with. > >> > >> The experiments were an unsupported activity that > >> produced an unsupported change to allow > >> configurable enabling of taking risks with not > >> updating files that possibly should be updated. > >> > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --000000000000ab8a0e06347b3674 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!

I use CURRENT on my lap= top and rpi4 for some time now.
I like to see changes in src tree = and then rebuild world and test for myself.
One of the things that att= racts me is building and rebuilding stuff and maybe that's why I'm = so happy as a ports committer :)

The only "chan= ge" that I do in build world is:
/etc/src.conf:
WITH_MALLOC_PRODUCTION=3Dyes
WITHOUT_LLVM_ASSERTIONS=3Dyes
t= hat might be incompatible with pkgbase since those settings are for release= s.

Cheers,

Mark Millard= <marklmi@yahoo.com> escreve= u (ter=C3=A7a, 6/05/2025 =C3=A0(s) 17:52):
On May 6, 2025, at 08:15, Nuno Teixeira <eduardo@freebsd.org> wrote:

> Hello Mark,
>
> Definitely I'm not getting the results I want with WITH_META_MODE = using BEs since most of the times I end up rebuilding almost everything in = new BE.
>
> Should I stop using WITH_META_MODES a go straight to clean builds (cle= an /usr/obj) instead?

If by "clean" you mean doing some form of "rm -fr" on a= ll
or part of what is by default somewhere under /usr/ob/ :
You likely would be deleting files that would be
regenerated during a build instead of any of those being
reused.

May be I've guess wrong about what you mean by "clean
/usr/obj"?

I'll note that I've never used ccache or the like:

https://man.freebsd.or= g/cgi/man.cgi?query=3Dccache&sektion=3D1&n=3D1

I expect that there are others that have that might
comment about such setups.

But going in another direction: I do not know why you are
doing your own builds instead of using pre-built materials,
such as PkgBase's base_latest (updated multiple times per
day, not that you need to do updates from it that often)
or base_weekly (again, you might not update as often).

Do you have local modifications of the system source that
you are building? (That could mean not using PkgBase
materials, for example.) Just kernel updates? Just
world updates? Both? Neither?

I also do not know if you build your own packages/ports. So
I do not even known if you need a toolchain. Do you need
to do package/port builds to get security updates sooner
or some such?

Can you comment on what has to be true of your system
environment(s) for such (even if it in turn means build
times that you do not like have to be involved)?
Delimiting the tradeoff structure requirements might help
in picking a path.


A RPi4 specific note:

One core on the RPi4B executing code for which the L1
(smallest) level cache is ineffective can saturate its
memory subsystem. Depending on details I've had
experiments in normal system build activity where using
-j3 instead of -j4 or more actually took somewhat less
time overall. (Not that the differences were huge or
anything. And they might not be systematic. But -j3 can
also help if there are also memory usage tradeoffs that
need to be managed. Does the RPi4 have 8 GiBytes of RAM?
4 GiByte? 2 GiByte?)


A note on official PkgBase build use:

The below illustrates that it is possible to mix
official PkgBase and personal system builds in some
ways.

Not that it is on RPi4B's, but I have both PkgBase
kernels and my own kernel builds and use
/boot/loader.conf to pick which is the default
for booting. I do not boot kernels that are
older than the boot world on the media.

I boot a PkgBase world and have directory trees for
chroot or other such use with my personal world
builds, some have my personal package builds
installed and others have official package builds
installed.

I only use my personal world builds with my personal
kernel builds. (They are matched.) I never use my
personal kernel build when it is older than the
PkgBase kernel or world that I use. This means
my personal kernel build supports booting the
PkgBase based world when I use that kernel.

Overall I can investigate if any problems I run into
are reproducible without my system or package builds
involved.

I have various poudriere(-devel) jails, some use
official PkgBase based jails and others are using my
personal builds for the jail content:

# poudriere jail -l
JAILNAME=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VERSION=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OSVERSION ARCH=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 METHOD=C2=A0 TIM= ESTAMP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PATH
release-aarch64=C2=A0 14.2-RELEASE-p1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0aarch64=C2=A0 =C2=A0 =C2=A0 =C2=A0pkgbase 2025-05-05 22:11:10 /usr/local= /poudriere/jails/release-aarch64
release-armv7=C2=A0 =C2=A0 14.2-RELEASE-p2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0armv7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pkgbase 2025-03-13 21:50:1= 7 /usr/local/poudriere/jails/release-armv7
official-aarch64 14.2-STABLE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0aarch64=C2=A0 =C2=A0 =C2=A0 =C2=A0pkgbase 2025-05-05 22:13:47 /us= r/local/poudriere/jails/official-aarch64
official-armv7=C2=A0 =C2=A014.2-STABLE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0armv7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pkgbase 2025-03-= 13 21:47:04 /usr/local/poudriere/jails/official-armv7
main-aarch64=C2=A0 =C2=A0 =C2=A015.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 aarch64=C2=A0 =C2=A0 =C2=A0 =C2=A0pkgbase 2025-05-05 22:1= 5:30 /usr/local/poudriere/jails/main-aarch64
main-CA76=C2=A0 =C2=A0 =C2=A0 =C2=A0 15.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 arm64.aarch64 null=C2=A0 =C2=A0 2025-02-13 01:35:3= 9 /usr/obj/DESTDIRs/main-CA76-poud
main-CA76-bulk_a 15.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 arm64.aarch64 null=C2=A0 =C2=A0 2025-02-13 01:35:39 /usr/obj/DESTDIRs/m= ain-CA76-poud-bulk_a
main-CA7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A015.0-CURRENT=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 arm.armv7=C2=A0 =C2=A0 =C2=A0null=C2=A0 =C2=A0 = 2025-02-20 18:16:55 /usr/obj/DESTDIRs/main-CA7-poud
main-CA7-bulk_a=C2=A0 15.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 arm.armv7=C2=A0 =C2=A0 =C2=A0null=C2=A0 =C2=A0 2025-02-20 18:16:56 = /usr/obj/DESTDIRs/main-CA7-poud-bulk_a
main-armv7=C2=A0 =C2=A0 =C2=A0 =C2=A015.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 armv7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pkgbase 202= 5-03-14 22:48:11 /usr/local/poudriere/jails/main-armv7

# poudriere jail -l
JAILNAME=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VERSION=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OSVERSION ARCH=C2=A0 METHOD=C2=A0 TIMESTAMP=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0PATH
release-amd64=C2=A0 =C2=A0 14.2-RELEASE-p2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0amd64 pkgbase 2025-05-05 22:19:47 /usr/local/poudriere/jails/rele= ase-amd64
official-amd64=C2=A0 =C2=A014.2-STABLE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0amd64 pkgbase 2025-05-05 22:21:46 /usr/local/poudriere/= jails/official-amd64
main-ZNV4=C2=A0 =C2=A0 =C2=A0 =C2=A0 15.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 amd64 null=C2=A0 =C2=A0 2025-02-12 16:03:46 /usr/o= bj/DESTDIRs/main-ZNV4-poud
main-ZNV4-bulk_a 15.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 amd64 null=C2=A0 =C2=A0 2025-02-12 16:03:46 /usr/obj/DESTDIRs/main-ZNV4= -poud-bulk_a
main-ZNV4-dbg=C2=A0 =C2=A0 15.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 amd64 null=C2=A0 =C2=A0 2025-04-02 09:20:08 /usr/obj/DESTDIRs= /main-ZNV4-poud-dbg
main-amd64=C2=A0 =C2=A0 =C2=A0 =C2=A015.0-CURRENT=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 amd64 pkgbase 2025-05-05 22:26:12 /usr/local/poudr= iere/jails/main-amd64

(I've never bothered with i386 in amd64 contexts and
have never used FreeBSD on an actual i386 class system.)

> My first concern is to speed up builds expecially on rpi4.

Per some prior questions: What other constraints must
also be met?

> Any hints are welcome.
>
> Thanks,
>
>
> Mark Millard <marklmi@yahoo.com> escreveu (segunda, 5/05/2025 =C3=A0(s) 23:18):<= br> >> Nuno Teixeira <eduardo_at_freebsd.org> wrote on
>> Date: Mon, 05 May 2025 20:37:09 UTC :
>>
>> > (...)
>> >
>> > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` t= o not mess with
>> > ports and stuff.
>> >
>> > Nuno Teixeira <eduardo@freebsd.org> escreveu (segunda, 5/05/2025 =C3= =A0(s)
>> > 21:34):
>> >
>> > > Hello,
>> > >
>> > > Using incremental WITH_META_MODE builds, after installat= ion with
>> > > beinstall.sh, building same src, a complete compilation = happens.
>> > >
>> > > If someone uses this script, could you please do the fol= lowing test:
>> > >
>> > > WITH_META_MODE=3Dyes (/etc/src-env.conf)
>> > > filemon module loaded
>> > >
>> > > # cd /usr/src
>> > > # make buildworld-jobs buildkernel-jobs
>>
>> The above used older commands and files from before
>> the following install. META_MODE recorded the use of
>> those commands.
>>
>> Example .meta mode file content:
>>
>> # Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/= amd64.amd64/lib/libc++/libc++.a.meta
>> CMD @echo building static c++ library
>> CMD @rm -f libc++.a
>> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o = charconv.o chrono.o condition_variable.o condition_variable_destructor.o de= bug.o exception.o filesystem/directory_iterator.o filesyste
>> m/int128_builtins.o filesystem/operations.o functional.o future.o = hash.o ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o = optional.o random.o random_shuffle.o regex.o shared_mutex.o
>> stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.= o utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o cxxrt_dynamic_c= ast.o cxxrt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g
>> nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typ= einfo.o
>> CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/l= ib/libc++
>> TARGET libc++.a
>> -- command output --
>> building static c++ library
>>
>> -- filemon acquired metadata --
>> # filemon version 5
>> # Target pid 22471
>> # Start 1611359217.214996
>> V 5
>> E 22961 /bin/sh
>> R 22961 /etc/libmap.conf
>> R 22961 /var/run/ld-elf.so.hints
>> R 22961 /lib/libedit.so.7
>> R 22961 /lib/libc.so.7
>> R 22961 /lib/libncursesw.so.9
>> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE
>> F 22961 22962
>> E 22962 /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd= 64/tmp/legacy/usr/sbin/rm
>> R 22962 /etc/libmap.conf
>> R 22962 /var/run/ld-elf.so.hints
>> R 22962 /lib/libc.so.7
>> R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE
>> D 22962 libc++.a
>> X 22962 0 0
>> . . .
>>
>> So META_MODE has lots of files that were used
>> that it can later detect being newer than the
>> prior build results, leading to rebuilds based
>> on those newer files.
>>
>> > > # ./tools/build/beinstall.sh
>>
>> The new be will have various updated files
>> that could be different by content and, for
>> commands, could behave differently than those
>> used to do the prior build. Detecting newer
>> time stamps on such used files leads to
>> rebuild activity.
>>
>> More than /usr/src/ and /usr/obj/ content
>> are involved as well.
>>
>> Note that the new be is based on somewhat
>> different files than the original
>> buildworld-jobs buildkernel-jobs was based
>> on.
>>
>> > > # reboot
>> > >
>>
>> (I presume booting into the new be here.)
>>
>> > > # cd /usr/src
>> > > # make buildworld-jobs buildkernel-jobs
>>
>> META_MODE will notice when commands are used
>> that are newer than when the prior build was
>> done. Similarly=C2=A0 for other files that may be
>> read. It will make sure that the newer commands
>> and files are allowed to produce new results
>> that potentially could be distinct in content
>> from what the old context produced for results.
>>
>> > >
>> > > Since src and obj are the same from one BE to newer BE, = minimal
>> > > compilation should happen, not a full one.
>>
>> META_MODE is more careful than that.
>>
>> Note: I'm not claiming that new behavior that is
>> needed is likely for lots of the files with new
>> dates. But META_MODE is biased to avoiding leaving
>> in place something that should have been updated.
>>
>> > >
>> > > Am I missing something here?
>> > >
>>
>> Note that make has a -dM option:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M=C2=A0 =C2=A0 =C2= =A0 =C2=A0Print debugging information about =E2=80=9Cmeta=E2=80=9D mode dec= isions
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 about targets.
>>
>> So, for example,
>>
>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.a= md64/tmp/legacy/usr/sbin/awk' is newer than the target...
>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.a= md64/tmp/legacy/usr/sbin/cap_mkdb' is newer than the target...
>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.a= md64/tmp/legacy/usr/sbin/cat' is newer than the target...
>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.a= md64/tmp/legacy/usr/sbin/cp' is newer than the target...
>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.a= md64/tmp/legacy/usr/sbin/crunchgen' is newer than the target...
>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.a= md64/tmp/legacy/usr/sbin/crunchide' is newer than the target...
>> file '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.a= md64/tmp/legacy/usr/sbin/dd' is newer than the target...
>> . . .
>>
>> Various . . ./tmp/legacy/. . ./*bin/ actually were
>> links to files.
>>
>> Ultimately buildworld then installworld lead to new
>> dates for a bunch of files used. Later use of
>> META_MODE notices such and rebuilds based on the
>> newer files. (It is a lot of detail to go through
>> it all.)
>>
>> Back in 2021 and 2023 I got help with exploring
>> avoiding lots of these. But, in the end, it
>> involved use of experimental code in
>> share/mk/src.sys.obj.mk to provide a new
>> definition to use to build some paths with.
>>
>> The experiments were an unsupported activity that
>> produced an unsupported change to allow
>> configurable enabling of taking risks with not
>> updating files that possibly should be updated.
>>
>
=3D=3D=3D
Mark Millard
marklmi at yahoo.com



--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--000000000000ab8a0e06347b3674-- From nobody Tue May 6 18:09: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 4ZsRJN2gy5z5vBrW for ; Tue, 06 May 2025 18:10:12 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsRJN09D6z47rG; Tue, 06 May 2025 18:10:11 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 546GM6WF018377; Tue, 6 May 2025 11:10:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=ndzTQ+DnwhwJT BVGlwy1rKW92wWtqDiFpzBYnox314g=; b=dgM0UTwPODBO8NcuP2zUnFt1YNuCm 0UNq9586h3LLSKxxPf5vLOU22rN+SEgkYbqWFSYI2oBYQwAMdqWfm9H1s1+z8BmU UfZWiHQyPChcrZtOS7+3PS2hY5L9hmGmHzjuSqne5xWF7W2wyBcKcveWj7jfbTyA m9FZlT9K/KaGTppN2S5NL1bBLthPrMboTbnW7Gyeu7y+MYCLMAQ5CRRaDB4aYNjE TD0V7c99VhdUPj8Z4TyxLmcJUoudNb6Mjpkkh6OveLeJBeQNf8nbUhq+43qhqDQj Lp2SMQldLKUw+XAGc2NcjZG1uSUXipTyBZLxftGSx4LZ0JZqYHm1rqGvw== Received: from bn8pr05cu002.outbound.protection.outlook.com (mail-eastus2azlp17011027.outbound.protection.outlook.com [40.93.12.27]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 46fjtkrtr1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 May 2025 11:10:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e8iqOk9tWHLnCw++yYOtLGBTN+A/wSJ8NlX7JxY4Owm2Fv3Ie80jPQUu7E0ZkB54AxS+Am+3SLEtjteEvJrUPTQ+d4Ft8kyVpwNbQ6y/mpzi51CbBkmzkSaavrtecxbEu7t8f5IVtvUXAp4M8cEyidg/NqaN7sDjBbzSMVzvsKHGEZtEjonzuBs7shEO4vZ6FAt7yHHL8o1E0fWktPqpUL/D7xjDuCJCoXgCYFKO9V02pi5PAIeXHCasUVtn9q0WsybgEzJb/KOaWq1kbsY7OBWu+JaHGDTscwvP9FXBSNE6+T7Jv3zfhlUL3zIsly/MVgLFmpmyAPkTyAmzDGVfTw== 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=ndzTQ+DnwhwJTBVGlwy1rKW92wWtqDiFpzBYnox314g=; b=bEZo8vtYvemi0j+pUwh5bHN91wKGbq5R3NaTPl7t50sxRDy/uXOIyPnXI/7y8fkF3KDzrkhr7/V0Xnd/KvgLVoPlioh43aO+mXCxTtVjnFKK3jI+ZmYK5xbJhhGDGpmjQ4S8d84mqBkYOAmH3xSJTsMPscY1xVmy1HCfkX1fc5WeGXQBPnlzi/ZkJuhvvU7O9NR/pHkCKpcyt0KkD3UAHZYnbEKa6EeIlM/0nmV++Kk0GKBx2v2Spkh+53GLowXbHeuXYMcbOfFzZRdOuqQNquJXfHaXeUOHT3ui+Vx/351OovfookduDL8whwTy/h261s8fwEoqDXCHaA7YqO9/sA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ndzTQ+DnwhwJTBVGlwy1rKW92wWtqDiFpzBYnox314g=; b=dzrg4lh/XRb+E9AC2RaiCh9WSDdgU1uVZjf1mIkL7DVe76nSaSJqHff8+hThazdVyXkUGgU4xneoqHqQoAUYvc4laUrHCQsN79U8mkY/v0p6qllWKJUx0gZVWxuolvb7HEbI+o8GoP7eXT7K60RaepQYY8i6sc2U3VvXIqQsz8Y= Received: from BN0PR04CA0137.namprd04.prod.outlook.com (2603:10b6:408:ed::22) by SA1PR05MB9883.namprd05.prod.outlook.com (2603:10b6:806:33b::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Tue, 6 May 2025 18:10:02 +0000 Received: from BN2PEPF000044A6.namprd04.prod.outlook.com (2603:10b6:408:ed:cafe::2f) by BN0PR04CA0137.outlook.office365.com (2603:10b6:408:ed::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.33 via Frontend Transport; Tue, 6 May 2025 18:10:02 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by BN2PEPF000044A6.mail.protection.outlook.com (10.167.243.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 18:10:00 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 13:09:59 -0500 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 13:09:59 -0500 Received: from kaos.jnpr.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server id 15.2.1544.14 via Frontend Transport; Tue, 6 May 2025 13:09:59 -0500 Received: by kaos.jnpr.net (Postfix, from userid 1377) id 0343BDBA7B; Tue, 06 May 2025 11:09:27 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 000F2DBA7A; Tue, 06 May 2025 11:09:26 -0700 (PDT) To: Mark Millard CC: Nuno Teixeira , FreeBSD Current , Subject: Re: incremental bulds from scratch with beinstall.sh In-Reply-To: <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Mon, 05 May 2025 15:18:39 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 30.1 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: <47028.1746554966.1@kaos.jnpr.net> Date: Tue, 6 May 2025 11:09:26 -0700 Message-ID: <49396.1746554966@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A6:EE_|SA1PR05MB9883:EE_ X-MS-Office365-Filtering-Correlation-Id: 3d994f31-0e18-45a8-4b19-08dd8cc937a6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?kbi9hym3SXUg2qbO8J8kxYeOyVfT4l41CZoTKY686aIFoOwtQBKNiO+wu1ga?= =?us-ascii?Q?TUX57rdRF3bNBT4xpmTi5G+YPNzlOeQXmtp1J2vu0lRq9/z4mHZxVnYbytdh?= =?us-ascii?Q?X0+HWOUyDN4Rzldl0j0RUsoOEZx3uKX5M4AmZa2gK5ZvtZebKoUa9NgnKw2d?= =?us-ascii?Q?XlEZCw2YH3GMd0zN/T0b8aBUHPrEDXL1UyQGBUo3qe6BHvxvk2ONzNUUEs0t?= =?us-ascii?Q?Ohes4onaB5i/qi37QD7UtYCDRYJ05Wmq6YuHVV2rq3UnRYda0KnTP32gxGGU?= =?us-ascii?Q?yOFt7QEoi92dLocvEJQicPSrOPV0jaY0VcJ2UzbLYJnrjwG+06U+vAmuhYQC?= =?us-ascii?Q?WigeWX0w+AfX07ug73JPX5oVwOIp1MU6EGiXo6JR44hm8p9bSbZyYf44B2UC?= =?us-ascii?Q?eW9pr5y2igryVKJGynxNVhBNWUuhM9mcNhXZar2zzgZLn0t/m3fb+12H5rJu?= =?us-ascii?Q?6JtLl7MRotASaLWlttYLD5lFDg64SkFapZKJct1fpxrACV1j7EoREuLB2yVC?= =?us-ascii?Q?Fj8Wy4hfw/HuUv+uUYa55bbgLJG0WRnbA93j00g/JwdelOPdKpSakhK0ZyTp?= =?us-ascii?Q?ln5QXshfnNpq2yoH5x19RegJRI5+MH4XP6xgkdk4kWiwwkvybfWr9gjyBGzR?= =?us-ascii?Q?B392q7MDY0wGybHCY4K1C0kemN4QgmpSCDIXiYrSE5fDrCdyDJzTRGbkgkTX?= =?us-ascii?Q?iWnGbud8WhO8HbIs0POTLlaEFbTjzhJ+n94+CUlbFNrzWcfgbooe1X9endWP?= =?us-ascii?Q?XxaaZyjtt0vhZgW7AEx0qa1rvdmZ35dQEsbLZcSyNRY6KyGij1fc20wbQhmE?= =?us-ascii?Q?uh/1Z9ADSRRiAsWCu5+wh9/tR/Qe5OcUGZA+Cs97jR6+2JS8LpgYHciyvt4B?= =?us-ascii?Q?pjbEZ4llcaC/S5VnUhHy4DQE79JmmQdzLDgxl4+1QrPjvpXORKBa/BMooOMK?= =?us-ascii?Q?Rz0W2KjtP58uF7SjcFW2Jkh4hk/4Ecu8zUV6ilCs9+e+lxnGY1yoJK4L7RrK?= =?us-ascii?Q?IdnB7QHj5kbmVcLghsaFes/QbQNLL3HPNMC6qLp8nxbtLH6zxfb1VM8tJBLI?= =?us-ascii?Q?P2nIqEyXqVx06aHUN2h+4aTzpqgF6ZvVQzdw0CqTQTmUS4ENpXbLm6IUEKO4?= =?us-ascii?Q?aGzpUV+gC9lhUpz5jn9AMhV/KAV1XelA8FYJufaKJEvh4egLQW2zQj/slCa3?= =?us-ascii?Q?TPmCyMv/BRIl0WwViKVWSzANp0BPCPPW7ubI1Qiuu4HZl6ffFgiyZLkGd3un?= =?us-ascii?Q?RMb6CeiTz/7vyTPwSnGOWIHgIvn/LCBw0DApllOTHuDChg369nHawoE4RSh0?= =?us-ascii?Q?E1oe9413nheK7eW3qI6y5eL0hSxKJlH56oS26QKOyHbO+O3cgmuejBHlY3MK?= =?us-ascii?Q?4Y+4bghJ7DBkrEyHg9qpf6eaFUmfUaUEP7BM8YUwtJD2UpAgGTgUC33bopre?= =?us-ascii?Q?a+Fy+mZc/7/vy/r5ybDcPp7UAOM3DpZhfCr0HrMPO27YVdaqXt/Pt9YEmxU1?= =?us-ascii?Q?bSko+eH4dE5856KmtOp9GTJplPHVoXyLkcbv?= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 18:10:00.5035 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3d994f31-0e18-45a8-4b19-08dd8cc937a6 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF000044A6.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR05MB9883 X-Proofpoint-ORIG-GUID: -6CuLTTk7NRAaJaUcvWKUU5A1X_b5wID X-Authority-Analysis: v=2.4 cv=dcuA3WXe c=1 sm=1 tr=0 ts=681a5081 cx=c_pps a=k6qe+EuqS5agFzeLFj3oqg==:117 a=f/rncuQqEjTEF/G1odkJ9w==:17 a=h8e1o3o8w34MuCiiGQrqVE4VwXA=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=s63m1ICgrNkA:10 a=rhJc5-LppCAA:10 a=CjxXgO3LAAAA:8 a=BOa5wa8wwP5w2RdehuUA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-GUID: -6CuLTTk7NRAaJaUcvWKUU5A1X_b5wID X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTA2MDE3MCBTYWx0ZWRfX54VOTIBzuOP5 /pT5G7zbIME1YkrGKXc6mUCAm5AIwMIZDhb2ciJvGi3AGEiijww60rFjvWMl6srDZQ1W262o/W9 ugm0jKgnzezr3HCLWj2+VfiOns3vUTgpHPCdex9gkhUt+Uwqm+rRFor7llL4GVsXVFopTHqa/tQ VXgxqJZ8z6vH+IJ7PnENsq3Ta1/3k6ekUQ8wET949dreYPDam8QxJ0f3u7zvMMoIVMxOb15S+t9 p6r9BYBLDDZMmAnWOEpfQgQNDObqvD24kvJ6FdjkbGkuzB0rSZZdxDH+9FeXz4jAD7blX30ojj/ Z55PJTMS/4PgF5a8x7G/Vl8+jyRglqOf6dBub7yoY3WPO3PXqHGMD3ycWClSSIVRqyv6Wnp+qKN PgroQ+nAmNb5xca7KHKwzpPeDg3fxzsWYRleBnyRrlbvmkndO262UXyOCoYXzsvN6jC5pGxk X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-06_08,2025-05-05_01,2025-02-21_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 mlxlogscore=634 adultscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 bulkscore=0 suspectscore=0 phishscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2504070000 definitions=main-2505060170 X-Rspamd-Queue-Id: 4ZsRJN09D6z47rG 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:26211, ipnet:208.84.65.0/24, country:US] X-Spamd-Bar: ---- Mark Millard wrote: > > > # cd /usr/src > > > # make buildworld-jobs buildkernel-jobs > > The above used older commands and files from before > the following install. META_MODE recorded the use of > those commands. I'm sure you are aware, but maybe not everyone is, that bmake contains a number of methods to tame META_MODEs enthusiasm for finding things to make a target out-of-date. .MAKE.META.IGNORE_PATHS is the cheapest and generally most useful .MAKE.META.IGNORE_PATTERNS can be more selective and .MAKE.META.IGNORE_FILTER can be expensive, but let you do a lot more. With recent bmake (MAKE_VERSION > 20220126) you can also set target local variables which means you can set say .MAKE.META.IGNORE_PATHS to apply only to a given target. Of course trying to get too clever can end up being counter productive, but the tools are there... --sjg From nobody Tue May 6 18:25:09 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 4ZsRdw4kTgz5vD8M for ; Tue, 06 May 2025 18:25:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsRdw1MN6z3GtT; Tue, 06 May 2025 18:25:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 546IP9bd043548; Tue, 6 May 2025 21:25:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 546IP9bd043548 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 546IP9ZU043547; Tue, 6 May 2025 21:25:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 May 2025 21:25:09 +0300 From: Konstantin Belousov To: Ahmad Khalifa Cc: current@freebsd.org, Olivier Certner Subject: Re: How to build with cross gcc? 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-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4ZsRdw1MN6z3GtT X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- On Tue, May 06, 2025 at 12:49:32AM +0000, Ahmad Khalifa wrote: > On Wed Apr 30, 2025 at 8:58 AM +0300, Konstantin Belousov wrote: > > exa% pwd > > /usr/local/x86_64-unknown-freebsd13.5/bin > > exa% ls -l cc1 cc1plus liblto_plugin.so > > lrwxr-xr-x 1 root wheel 60 Apr 30 08:49 cc1 -> /usr/local/libexec/gcc/x86_64-unknown-freebsd13.5/14.1.0/cc1 > > lrwxr-xr-x 1 root wheel 64 Apr 30 08:49 cc1plus -> /usr/local/libexec/gcc/x86_64-unknown-freebsd13.5/14.1.0/cc1plus > > lrwxr-xr-x 1 root wheel 73 Apr 30 08:49 liblto_plugin.so -> /usr/local/libexec/gcc/x86_64-unknown-freebsd13.5/14.1.0/liblto_plugin.so > > If this was installed from FreeBSD:14:amd64/latest shouldn't GCC's > target be 14.2 instead of 13.5? I use the same package set on all my machines, which is built on 13.5. From nobody Tue May 6 19:16: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 4ZsSmp18wMz5vH8x for ; Tue, 06 May 2025 19:16:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4ZsSmn4wZZz3dfv for ; Tue, 06 May 2025 19:16:25 +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=1746558983; bh=AFjcyuto1ePmbCRo2nNn+mYeQgADfSGj7Kk7EwqcuKQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VpOO+nS5XNlbvVQlpBaDX6qwwIHUiOiHDJx2+8r5XsIBvL4nhAESya/BaZ466Z3QGNyA810JcJ+fgxyN5EM++lpUskbCYC0nx+HBYd5yb6IYhdMnjA04HLM/r6M6QoJK4vwRsmBDGeX6RVNUSFsXiqnSJ8PrnWTdL66eRg3fCfGSTgls9+zb2dTsE5P7XQ57nQVEgnZ7PlKZUPPVtXlgJmTOmYNJMyCkVLIFUY+YVbh5BaGCVO+ERYFkU0Iiv9rk7BFoLorBJOdw6Jw7GWjmIhOSF+1uE45/ZgQPXLKETzdZK7bjtp1nuVIhfq6zNfnGV4teG0IHfH2gGDX6KYCMiA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746558983; bh=iXJvg7v1KR+bs5lD3icys/LyeSq2yqrIskC3/uOfPtz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JZHb4K3bMrxbMaLq6Y7Dg8aEZYUscLbDK5/1MOEH4i7GaTW50FmuKz2Hu4gTvEyi6vrVZUML2/oFhz7aS7w2a5xIPF1COXTFSqBMnpqOJH2SHBN610vQ02LfKqZBtxTUfiVFAAIUEeeohiPpFVPMChzHTm83W5D56o+4r7nTX/ZKm4Ft4LW6FCye6dABwixzMMyFmKubQwihU2d5qIIjj5ZDZPIVSbXxGhL+IBxt0e66AXVyRlabVC4wA4/Rfq1N5DZEJbhnwRu8OSV5ZvepoAg3BkqLtg8zs3cEzpw4WaIC9jBbfN/Vx55px/wbIlk35BSXERCwddrWEPJcWmfYxg== X-YMail-OSG: lYD53qoVM1mGGokGc51GJlo_j4gyZpNNHLbaOlyXrkKtKXUkSk_APw5K5SL.de0 NiiFfQywp1Zmt57hMCWbJ98T35y1l0ssy4VLjmqvxEizqAgKnShG.z2ZZ8a4S3fS.7SMZknzHSF_ A1Qw.BD3s2Lom4JBPdpWHRytFjDSMUDLv5WdMT1V9sbria13blYA8Y7aXTtrqnREQQ_CQ3kTubbo wyoabES01o22X6j.5MJgnohmnh83_g5jV.B2a3TqqdyV0C20OmUn12du9iU2nrr1xG8qGhh7C62J _lqzw0uDc3oCBI_BuR.CYs_XVRagsbnsHfNuJN.4IoWWKSrMKjdt0JlDTDSotwzNGSWM0XhTfd_u VfK_RNuNvLhxyVmZqK_isQUDUi9rFQ7vXK8ARqCk01W0of4Afm4QjiM1iOGSJ6oVTkZxODdC73Pj ksDsK0nMFdU4XzZII1OmIC6Z1L5V59Z1A.bm5iruKAYYmZyxnbH_.o0fe78pNjOdB7QL7snWappN z_vYfV7gYodyOPohKlGK13Dztj0_tXevBFjcqnnpNi8G8wQeHMK51kF2KAyV4m00TUb9N7_fG8pe NOT3Dp7kG8_zM2XKN2c2fqrIOQ5ahUAB1yR2yRIG.6Ua3GZG1J3wnletZvlaQPAoeebxZRRXIETg 4LKNzzC8FIEE.4lay8Gxjwqc97c5Tt0gw.qQlahQegi9_TiSgi_g5UaHNnxZFjYZGPgDoXMsjXWV EVDbD3M_oE9iqPBjQB4.cC8ha5eM39drrGrPs5NmsSg2yfcV6v4Lk3oiZkhMDKNFO_Qp7Rd1QI3M ud3f5.f57PZfU7Yv9Y4uxVrOSBV9e97OeD2NJ25WQPR.dCKN9bm0S3WVU8TjvX2iapdranRI0gVp HBDmbpK359MWqnLUYTldZ2duf736IuxM_0Miexrrabr1tTx.kv9zQGjWfaA9jJg_AOh6aMSEIuC8 HCpzBaDSFG6TNgeGrOUzlO0I._1aUkb9l8.0y_Tl8JJyGYQmIQUhbIbnjK7TFs3TI2F2P7UtPEjW 7Xtp0v.5Dz8QDRQrcMebvQRbd90V01B404jO_PGVRC27Nw7Us0jrFeIQsn04YUEBDbLJt5U_E0r_ 4vjrxPTyLgDjiSC7_oVlTE59ZZP4mY8edg2lFLw2stL3LzWpCTmxHe4kMkHHQcNyKKc7fu0F4Cc1 9AA3B8RS73zDf.LwyRdNi3pCg8pcEE.iAeZ651wgijPEsK5OzIZWlkU9kUd.ZT_.iNtwvaSuiU7X ApLn27C2Kj_gLzlPbhfVyg..EyyyjtpJi9PF5oMh1usvZsG73X3GmIRqXnUtfCU9wl5rHfE_6vAy VhWUMXqP0TFWmtg5Ye95YaBv48MZxM8e.k1_RQiJPfpIp2uVcJHhy5XzPk8oLn8RRyd3mlYQxisp BcQd3lwMDU85etvveeoxwDI_WzgCBJQjgIb2pvBZERrtEtJj0z.lj3cL5oyDrJV414ZW4ukKsC9d PFyUFVOwrwGFp4HXwH5owkDk_hG5c0Y3Mwno0iW.6EUn0qTcaCdh6JZZcm3BMo8V_z15t5g0K1gH zRrvMBngIQOKSkfTLMiFMUPJUgZiGNt5MwobJUgPB2PXNSjb7qG31iUpbfc00vMCymKF4ugkI.4a YvDauT3h2VLzAKgMaHqgz5QdAvdvtivBTFvWqlrQg1o0sZcPS2517z.RggUSu2Y_qcdkpkHRjBLr o1bF9I.Owdwu34_WgAwi5m69sTu78cKxnK.m7tYihzkZP6z4Cpnx_A2ViLbobHQFq6ihH1mj8060 jnPS4W.m.gBwls05hpDaITlkmVm5RosSWi0d.sIg6_jJT.MS1i3CN6oXhv9iVCy83icpAXYRaz7t Lvgxiwy0MFrA8EZIp.sC14j2o2KHtPm9lxoE1r6lcwNInDyq95B_ur0xfJiP39w5RxGU79YQg_OZ DXNCkx19qugBLxoHYZQ_iB8CYcMWCQfNKgDjl435Kkq6QTgTp8M2pmUNN7p2eToPm8EQuZ2oYpm1 J4DArgrGLDo8E7h7s1FQmSD2J1ohQyRLqf.6dqcgkeN8OyzqKoNuBKT.Y1iapkkne.TU7g4460A. .LEnzulpQ22IXahSUwlifHP45PCkyOkeXB2__AV6U8whbRjyCuP.CD03RRqpw9fFnTeqoS0PeuTG TRnVf9WEEkMdJLNSvEgD6tpkLpVqgnC11L1c5jVYto1VNbssjhUCkTHRMas7cfuRLDD0rvyCN0cP TNKbNKMjBAtul5KMKEiQJlqITDUMElepnRSB1BsTCU5AXAM546zB9OAODZ0cFUXCT_.CJkOs2OEN s8eNY X-Sonic-MF: X-Sonic-ID: a4bd3198-c542-46ee-88eb-3680951776c9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 May 2025 19:16:23 +0000 Received: by hermes--production-gq1-74d64bb7d7-fsgc5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5ce0c37b7ce67c7e36de3fce81428d44; Tue, 06 May 2025 19:16:18 +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: incremental bulds from scratch with beinstall.sh From: Mark Millard In-Reply-To: Date: Tue, 6 May 2025 12:16:07 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <86E414BD-6FA1-4B46-B0FE-DEABCED63DC5@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <5BFEF4D2-0E42-46ED-899B-D27169DFC322@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4ZsSmn4wZZz3dfv 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-Spamd-Bar: ---- On May 6, 2025, at 10:47, Nuno Teixeira wrote: > I use CURRENT on my laptop and rpi4 for some time now. > I like to see changes in src tree and then rebuild world and test for = myself. > One of the things that attracts me is building and rebuilding stuff = and maybe that's why I'm so happy as a ports committer :) Ahh. Okay. This may get into how much risk of broken builds in non-obvious ways that you can tolerate. Also: How much context analysis and tracking you want to do vs. not. "man 7 build" references the likes of NO_CLEAN and NO_CLEANDIR and NO_KERNCLEAN that migth be used without use of META_MODE. That does not notice as much evdience of needing rebuild activity. NO_CLEAN If set, no object tree files are cleaned = at all. This is the default when WITH_META_MODE = is used with filemon(4) loaded. See = src.conf(5) for more details. Setting NO_CLEAN = implies NO_KERNELCLEAN, so when NO_CLEAN is set no = ker- nel objects are cleaned either. There is also: KERNFAST If set, the build target buildkernel = defaults to setting NO_KERNELCLEAN, NO_KERNELCONFIG, = and NO_KERNELOBJ. When set to a value other than = 1 then KERNCONF is set to the value of KERNFAST. and: WORLDFAST If set, the build target buildworld = defaults to setting NO_CLEAN, NO_OBJWALK, and will = skip most bootstrap phases. It will only = bootstrap li- braries and build all of userland. This = option should be used only when it is known = that none of the bootstrap needs changed and that = no new directories have been connected to the = build. These sorts of things get into your tracking context to know when to use them vs. not: more manual management. When things go wrong, they get into figuring out how to fix them --possibly involving bigger rebuilds than otherwise at that point. > The only "change" that I do in build world is: > /etc/src.conf: > WITH_MALLOC_PRODUCTION=3Dyes > WITHOUT_LLVM_ASSERTIONS=3Dyes > that might be incompatible with pkgbase since those settings are for = releases. PkgBase has both Debug and non-Debug kernels for main. It has builds of main and stable/14 as well, not just 14.* releases. Just FYI . . . PkgBase has available (for amd64 and aarch64 and . . .): main: base_latest/ and base_weekly/ Note: both Debug and non-Debug kernels are available for main. To my knowledge, PkgBase is the first form of official distribution of non-debug main kernels. (I have both types installed.) stable/14: base_latest/ and base_weekly/ releng/14.*: base_release_[3210]/ ( Also: kmods_latest_2/ kmods_quarterly_2/ with some kmods ) PkgBase has debug symbol file packages available to install and has its own /usr/src/ and /usr/src/sys/ packages (no git repo). PkgBase is (always?) based on WITH_LLVM_ASSERTIONS as far as I know. However, I'm not aware of PkgBase yet publishing anything listing with WITH_* and WITHOUT_* settings that are used for any of its builds --or other such details. I learned about assert by hitting an example failure. The status could have changed. I do not know the WITH*_MALLOC_PRODUCTION status. Do you really want/need the RPi4B to be able to build for the powerpc* and amd64 and the like? Might src.conf be used for: WITH_LLVM_TARGET_AARCH64=3D WITH_LLVM_TARGET_ARM=3D WITHOUT_LLVM_TARGET_MIPS=3D WITHOUT_LLVM_TARGET_POWERPC=3D WITHOUT_LLVM_TARGET_RISCV=3D WITHOUT_LLVM_TARGET_X86=3D Such could save some time on a RPi4B. A similar point might go for the laptop (enabling X86 instead?). WITHOUT_LLVM_TARGET_ALL=3D might be an option but it used to be there as an odd build consequence that I ran into that was tied to if the bootstrap toolchain build could be avoided vs. not. I've not retested and stuck with being explicit. Looks like there is also now: WITH*_LLVM_TARGET_BPF but it seems to be WITHOUT_LLVM_TARGET_BPF by default. WITHOUT_LLVM_TARGET_MIPS also looks to be the default for MIPS these days [on main]. Another thing you may not be interested in using is the results of WITH_CLANG_FULL: WITHOUT_CLANG_FULL Avoid building the ARCMigrate, Rewriter and StaticAnalyzer components of the Clang C/C++ compiler. Again, possibly avoiding the RPi4B spending the time building what is not used. > Cheers, >=20 > Mark Millard escreveu (ter=C3=A7a, 6/05/2025 =C3=A0(= s) 17:52): > On May 6, 2025, at 08:15, Nuno Teixeira wrote: >=20 > > Hello Mark, > >=20 > > Definitely I'm not getting the results I want with WITH_META_MODE = using BEs since most of the times I end up rebuilding almost everything = in new BE. > >=20 > > Should I stop using WITH_META_MODES a go straight to clean builds = (clean /usr/obj) instead? >=20 > If by "clean" you mean doing some form of "rm -fr" on all > or part of what is by default somewhere under /usr/ob/ : > You likely would be deleting files that would be > regenerated during a build instead of any of those being > reused. >=20 > May be I've guess wrong about what you mean by "clean > /usr/obj"? You did not comment about the above. WITH_CLEAN is an example of deleting things that might otherwise be reused instead of being built. I should have mentioned that above. > I'll note that I've never used ccache or the like: >=20 > https://man.freebsd.org/cgi/man.cgi?query=3Dccache&sektion=3D1&n=3D1 >=20 > I expect that there are others that have that might > comment about such setups. >=20 > But going in another direction: I do not know why you are > doing your own builds instead of using pre-built materials, > such as PkgBase's base_latest (updated multiple times per > day, not that you need to do updates from it that often) > or base_weekly (again, you might not update as often). >=20 > Do you have local modifications of the system source that > you are building? (That could mean not using PkgBase > materials, for example.) Just kernel updates? Just > world updates? Both? Neither? >=20 > I also do not know if you build your own packages/ports. So > I do not even known if you need a toolchain. Do you need > to do package/port builds to get security updates sooner > or some such? >=20 > Can you comment on what has to be true of your system > environment(s) for such (even if it in turn means build > times that you do not like have to be involved)? > Delimiting the tradeoff structure requirements might help > in picking a path. >=20 >=20 > A RPi4 specific note: >=20 > One core on the RPi4B executing code for which the L1 > (smallest) level cache is ineffective can saturate its > memory subsystem. Depending on details I've had > experiments in normal system build activity where using > -j3 instead of -j4 or more actually took somewhat less > time overall. (Not that the differences were huge or > anything. And they might not be systematic. But -j3 can > also help if there are also memory usage tradeoffs that > need to be managed. Does the RPi4 have 8 GiBytes of RAM? > 4 GiByte? 2 GiByte?) >=20 >=20 > A note on official PkgBase build use: >=20 > The below illustrates that it is possible to mix > official PkgBase and personal system builds in some > ways. >=20 > Not that it is on RPi4B's, but I have both PkgBase > kernels and my own kernel builds and use > /boot/loader.conf to pick which is the default > for booting. I do not boot kernels that are > older than the boot world on the media. >=20 > I boot a PkgBase world and have directory trees for > chroot or other such use with my personal world > builds, some have my personal package builds > installed and others have official package builds > installed. >=20 > I only use my personal world builds with my personal > kernel builds. (They are matched.) I never use my > personal kernel build when it is older than the > PkgBase kernel or world that I use. This means > my personal kernel build supports booting the > PkgBase based world when I use that kernel. >=20 > Overall I can investigate if any problems I run into > are reproducible without my system or package builds > involved. >=20 > I have various poudriere(-devel) jails, some use > official PkgBase based jails and others are using my > personal builds for the jail content: >=20 > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH > release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-05-05 22:11:10 /usr/local/poudriere/jails/release-aarch64 > release-armv7 14.2-RELEASE-p2 armv7 pkgbase = 2025-03-13 21:50:17 /usr/local/poudriere/jails/release-armv7 > official-aarch64 14.2-STABLE aarch64 pkgbase = 2025-05-05 22:13:47 /usr/local/poudriere/jails/official-aarch64 > official-armv7 14.2-STABLE armv7 pkgbase = 2025-03-13 21:47:04 /usr/local/poudriere/jails/official-armv7 > main-aarch64 15.0-CURRENT aarch64 pkgbase = 2025-05-05 22:15:30 /usr/local/poudriere/jails/main-aarch64 > main-CA76 15.0-CURRENT arm64.aarch64 null = 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud > main-CA76-bulk_a 15.0-CURRENT arm64.aarch64 null = 2025-02-13 01:35:39 /usr/obj/DESTDIRs/main-CA76-poud-bulk_a > main-CA7 15.0-CURRENT arm.armv7 null = 2025-02-20 18:16:55 /usr/obj/DESTDIRs/main-CA7-poud > main-CA7-bulk_a 15.0-CURRENT arm.armv7 null = 2025-02-20 18:16:56 /usr/obj/DESTDIRs/main-CA7-poud-bulk_a > main-armv7 15.0-CURRENT armv7 pkgbase = 2025-03-14 22:48:11 /usr/local/poudriere/jails/main-armv7 >=20 > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP = PATH > release-amd64 14.2-RELEASE-p2 amd64 pkgbase 2025-05-05 = 22:19:47 /usr/local/poudriere/jails/release-amd64 > official-amd64 14.2-STABLE amd64 pkgbase 2025-05-05 = 22:21:46 /usr/local/poudriere/jails/official-amd64 > main-ZNV4 15.0-CURRENT amd64 null 2025-02-12 = 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud > main-ZNV4-bulk_a 15.0-CURRENT amd64 null 2025-02-12 = 16:03:46 /usr/obj/DESTDIRs/main-ZNV4-poud-bulk_a > main-ZNV4-dbg 15.0-CURRENT amd64 null 2025-04-02 = 09:20:08 /usr/obj/DESTDIRs/main-ZNV4-poud-dbg > main-amd64 15.0-CURRENT amd64 pkgbase 2025-05-05 = 22:26:12 /usr/local/poudriere/jails/main-amd64 >=20 > (I've never bothered with i386 in amd64 contexts and > have never used FreeBSD on an actual i386 class system.) >=20 > > My first concern is to speed up builds expecially on rpi4. >=20 > Per some prior questions: What other constraints must > also be met? >=20 > > Any hints are welcome. > >=20 > > Thanks, > >=20 > >=20 > > Mark Millard escreveu (segunda, 5/05/2025 =C3=A0(s= ) 23:18): > >> Nuno Teixeira wrote on > >> Date: Mon, 05 May 2025 20:37:09 UTC : > >>=20 > >> > (...) > >> >=20 > >> > Don't forget to `env NO_PKG_UPGRADE=3Dyes beinstall.sh` to not = mess with > >> > ports and stuff. > >> >=20 > >> > Nuno Teixeira escreveu (segunda, 5/05/2025 = =C3=A0(s) > >> > 21:34): > >> >=20 > >> > > Hello, > >> > > > >> > > Using incremental WITH_META_MODE builds, after installation = with > >> > > beinstall.sh, building same src, a complete compilation = happens. > >> > > > >> > > If someone uses this script, could you please do the following = test: > >> > > > >> > > WITH_META_MODE=3Dyes (/etc/src-env.conf) > >> > > filemon module loaded > >> > > > >> > > # cd /usr/src > >> > > # make buildworld-jobs buildkernel-jobs > >>=20 > >> The above used older commands and files from before > >> the following install. META_MODE recorded the use of > >> those commands. > >>=20 > >> Example .meta mode file content: > >>=20 > >> # Meta data file = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/li= bc++.a.meta > >> CMD @echo building static c++ library > >> CMD @rm -f libc++.a > >> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o = charconv.o chrono.o condition_variable.o condition_variable_destructor.o = debug.o exception.o filesystem/directory_iterator.o filesyste > >> m/int128_builtins.o filesystem/operations.o functional.o future.o = hash.o ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o = new.o optional.o random.o random_shuffle.o regex.o shared_mutex.o > >> stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o = utility.o valarray.o variant.o vector.o cxxrt_auxhelper.o = cxxrt_dynamic_cast.o cxxrt_exception.o cxxrt_guard.o = cxxrt_libelftc_dem_g > >> nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o = cxxrt_typeinfo.o > >> CWD = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++ > >> TARGET libc++.a > >> -- command output -- > >> building static c++ library > >>=20 > >> -- filemon acquired metadata -- > >> # filemon version 5 > >> # Target pid 22471 > >> # Start 1611359217.214996 > >> V 5 > >> E 22961 /bin/sh > >> R 22961 /etc/libmap.conf > >> R 22961 /var/run/ld-elf.so.hints > >> R 22961 /lib/libedit.so.7 > >> R 22961 /lib/libc.so.7 > >> R 22961 /lib/libncursesw.so.9 > >> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > >> F 22961 22962 > >> E 22962 = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/rm > >> R 22962 /etc/libmap.conf > >> R 22962 /var/run/ld-elf.so.hints > >> R 22962 /lib/libc.so.7 > >> R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE > >> D 22962 libc++.a > >> X 22962 0 0 > >> . . . > >>=20 > >> So META_MODE has lots of files that were used > >> that it can later detect being newer than the > >> prior build results, leading to rebuilds based > >> on those newer files. > >>=20 > >> > > # ./tools/build/beinstall.sh > >>=20 > >> The new be will have various updated files > >> that could be different by content and, for > >> commands, could behave differently than those > >> used to do the prior build. Detecting newer > >> time stamps on such used files leads to > >> rebuild activity. > >>=20 > >> More than /usr/src/ and /usr/obj/ content > >> are involved as well. > >>=20 > >> Note that the new be is based on somewhat > >> different files than the original > >> buildworld-jobs buildkernel-jobs was based > >> on. > >>=20 > >> > > # reboot > >> > > > >>=20 > >> (I presume booting into the new be here.) > >>=20 > >> > > # cd /usr/src > >> > > # make buildworld-jobs buildkernel-jobs > >>=20 > >> META_MODE will notice when commands are used > >> that are newer than when the prior build was > >> done. Similarly for other files that may be > >> read. It will make sure that the newer commands > >> and files are allowed to produce new results > >> that potentially could be distinct in content > >> from what the old context produced for results. > >>=20 > >> > > > >> > > Since src and obj are the same from one BE to newer BE, minimal > >> > > compilation should happen, not a full one. > >>=20 > >> META_MODE is more careful than that. > >>=20 > >> Note: I'm not claiming that new behavior that is > >> needed is likely for lots of the files with new > >> dates. But META_MODE is biased to avoiding leaving > >> in place something that should have been updated. > >>=20 > >> > > > >> > > Am I missing something here? > >> > > > >>=20 > >> Note that make has a -dM option: > >>=20 > >> M Print debugging information about =E2=80=9Cmeta=E2= =80=9D mode decisions > >> about targets. > >>=20 > >> So, for example, > >>=20 > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cap_mkdb' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cat' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/cp' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchgen' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/crunchide' is newer than the target... > >> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/dd' is newer than the target... > >> . . . > >>=20 > >> Various . . ./tmp/legacy/. . ./*bin/ actually were > >> links to files. > >>=20 > >> Ultimately buildworld then installworld lead to new > >> dates for a bunch of files used. Later use of > >> META_MODE notices such and rebuilds based on the > >> newer files. (It is a lot of detail to go through > >> it all.) > >>=20 > >> Back in 2021 and 2023 I got help with exploring > >> avoiding lots of these. But, in the end, it > >> involved use of experimental code in > >> share/mk/src.sys.obj.mk to provide a new > >> definition to use to build some paths with. > >>=20 > >> The experiments were an unsupported activity that > >> produced an unsupported change to allow > >> configurable enabling of taking risks with not > >> updating files that possibly should be updated. > >>=20 > > =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 6 19:32:13 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 4ZsT7M10ypz5vJdF for ; Tue, 06 May 2025 19:32:31 +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 4ZsT7L524qz3pr8 for ; Tue, 06 May 2025 19:32:30 +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=1746559949; bh=WQcqiK+gJvzJ71XqvhDWmTSKDXQ/tp3ys7oKhrlCjl4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=j0tgwX6RgJ7zE2v4ZRZIijvgxtJ1Lj8ztk5G+ekxXGSn9QcXy2QllTNjGXxJ3vHG1zGbZdhfNqCU0G3OikGdq6FcMZx/JQMP6UWVBIEOcbniTWuApLZJBxcm3l2MVWoYNDvavqqMvCMimE/6aKhdAiSbt71RQmfSmXqZSW3W6uYTMOx5p0JrJA/+1OgJvktW5ol0x85nQbBS2Kkt2LhmfvHi2aLKsoBn/cdGZOxhR8sFcAH6WXovddQjnTPJJC2dmtH3qbGyEuDmEBPkjseAXX0Iu7TegmkaVbtOc3D0SSJGehPd+kfbdhYJtEAcCue3dGy41FYg1UvYWCE58Ec6rw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746559949; bh=/zu1vQbcncNIg04nZPDQEcqsIgmFIgxh/FFPIlb8No/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pPMxLCliTLEcrfIw/hoHLyIDjPb96O5cAjc3RXwyh8zaWguHUkjSAycc5uWAs+9iY2kiAeTeqkk81vgdNvVGs5o1CphEMocQbgwGAxGYwGJwH9enuso3cpxCVx1eEi82ZSizGtAEaD0Tu0RkghLShRL0L72o+fBdOzOX1TF5wRYSnfs2Ewf+DOH8QU/dMdV4WH/x05+ejg3EwHkpJkjds48wZMJacEvoIORI44/afPlSCsrC3M7UrwuAidF/uIjTk5FYe7wARIJLJ5OOzoeZowZ5mJRt2XILfq9UCyWJHoF4FjeDCcZSIdlULCgZ086WTwXsymR1axCvyOfxdsZglA== X-YMail-OSG: 8pI_8bYVM1mGNOlQcLElSS1gjfvJufBpaV4n.I1KW_zPAf9HzTIcXOJSWu4IP8C yUwlEetLSVi2BecPnJA5Xqew6QFBPLV0LqXCmFUVrFDUmX6.iA1uy6PEBGiQjho8FTys.hGl7U17 XQ5AG53UL0L_JNh2EFLk70oFtBhfZtg82VndaB7AzO4U9w_ZuLNLR37wYSp3CsfDRpgHeRdiJJe5 TjdzBCEEkE7c4xT.tQzKSB_1oS5_OM8XAqcLnTEMi9N7EHSu0p.GVzGUm92VsMOi5ru8gqL34ybU _qbdW9bKE.iITfz4KXOInBaAvrt2v6EZ_SIX_BivocRTZKlQ73QJdjM0VcH6cJiZhXAmYmGVaERp mL1e5UL_Uth2uqf8AQ2QDMp0yrQzyL4rG2pEPlL2kppslA2WZeivEbU_fMkS6u2NqN7VIiIqyHPL 0Msuwv.QkAmv7Jm.PUBOELKqi3SxJA0Etev0.Knomhqf7e_pFJ966a_pWBazAuWsVudipX5ggZgu 0y1ZFQGayCo5ZCLkMTyCcSfL6wdV2ANH5OSU7o31AM88smo8YHgKT3JWJZRWmJeYLvDH.ytt.YXn XEVQ84BSV1n64CPngzx5G4omvhp7eOxwSZD7TzhUcN_wt4MaPbZxfyJm18dmiVGcgNkEk3yulRBn 8flUApHy9fJSOpeIJo9e0xq2vaPJT2FFRjlZGXPSA4NItXd0UDtvrIA2.jlu1oUGElPIgaUV0C.t Npnnf0.n.aRBlsurBYiTIAPpq.FC6nNX260mpFdfin8VJP5B2NUFqS72t7qvq68uqzJdlPUmaIw2 g9QaOfeOk2Ob7X1YsZ8Qg006ZeIUJOyRJvr8SGUZTHukgiOcLWPOAeCGIHxumpAW538245IDJSZ2 65uiQn0OKD_geiNsMcWPiTumEm7aRL2mtQ2_Zm.HPnHKNPUKW5bX8yfp8ZV2pYhxdg7_75ExUCH. V1rfp9J6j1UAFRHiAtEGgLZmWEz6d1lHqAwmr8u3pqjOWBNzbpvoS533WFGaIscQ6NWi9eRYzKhI 9jn2zcW35e1hbNEiWL1wbj2cYAOQDQ87HLi_sa2lTjNRrlE5Wu.jfvpylzlIZJTKCIaNwo015CBI eLN4g.rJKgufiVbI4jxlg4bDS9mCdlbouO0Hibk5juh24J2IshKTTtVls4U8a2zzhfTSb0vanJNy QaV_ib.ma48j_qtuBMQnaPPMv6WaPt_vvczSjC5cOeTPO_scbVrusbFTbk5DYs1QjFdSYqaj1D2x rNrH3WERy1CA09_ra6.9sxqi86l9tLR.vBnbNbYz0s5BsgA7_WQ87NXS4eYzFO1gLU4rs9IYNlTN 6FYf.SvtBsxypLMVd4YZ1iW8mNjY6BM0XB4IyOeI0zEOuR03kSvLjeOT5rrUrwGYQgheJ2Yqx7lE sytWhcb2mUlXD0ICLzGKXpCa80ATOqtfBlEACL.8ovXlmxA_p8IuqiH7dM6gk7bHMUbYKHEqJBt7 WfP8JYc3v8.2wooBNjPdTcUQNj_HcBa5E.GJkv7vZMb41WuiU8bYg6IItB1QfcV0GvNU4BZnYmd_ bSazZ0c1O.cdzkIKbuPZ4PKlTLXkFBaCOCtz4h60rA4ItLduf559RKpFpmtN5b86ujNGnv9bilhH 6CXkfkD6sJuPkMBaBL6zm6_Gpg6W3SSsR4DprZII2uy04crmiS48bF1NXB8Mz6zIZ9iLTNwEaISP 7s163a2CBFrs08ehTiG7elYDrKCRDK0f5X4N7olHAQqrANsqqWlDmCKgrRKMvGkpIb5CmTXN5u03 uD4N0O9xX7Fq5c5H4hHQk1oN6K9PVx33doiSBMyyrIQth.vSwmHUGOIUPGoAO_Vrp633PpBtUrHs KrHFBOvfsNarRwx41.FTifkVkFw6F2izaYMcKY_009YJ99qTzjQcM8AWm25WcxZQb.6XwEdtZYNI npwmQhH7tX3hkAwJkpvOM4De6A3eT4WD9imZVprS6GYSouUXe7YRDsg242.TjxxWvG0ytwbRHYsX nqJeT1AIvfXO7n1xH76jQYyjJprpTXe5RSj_UCgI40Wluv19cc69UJyxLTIU0ivqHsAo.yU1e9Oe nLHkki2YzqpCAKrQNgBD_1c5OGlMrW_YSELLDhjtCwYvS8kBkJaGSz1LEs.b37vPT7TrzfMk964D 1kpTM5Ja2xk_GMRIhRkGW1XPtFtz6Lz7Kyx5KecyMzTUDG63OnW53KOaKAwv1ZCgSt21vH0W.09T 87tWVmKA1xM3MVU6jO4NJajxz8h1qnaCwvgBlXEoDUir9dpmu6pcsD9rvNmDbl3evwnMObj_jBVi 3ow-- X-Sonic-MF: X-Sonic-ID: 94fe061a-127e-4103-9fb2-fafcd03347ec Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 May 2025 19:32:29 +0000 Received: by hermes--production-gq1-74d64bb7d7-mh87r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7059dbb6bc31327bb0bb5e40c1ffcd39; Tue, 06 May 2025 19:32:23 +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: incremental bulds from scratch with beinstall.sh From: Mark Millard In-Reply-To: <49396.1746554966@kaos.jnpr.net> Date: Tue, 6 May 2025 12:32:13 -0700 Cc: Nuno Teixeira , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4ZsT7L524qz3pr8 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-Spamd-Bar: ---- On May 6, 2025, at 11:09, Simon J. Gerraty wrote: > Mark Millard wrote: >>>> # cd /usr/src >>>> # make buildworld-jobs buildkernel-jobs >>=20 >> The above used older commands and files from before >> the following install. META_MODE recorded the use of >> those commands. >=20 > I'm sure you are aware, but maybe not everyone is, that bmake contains = a > number of methods to tame META_MODEs enthusiasm for finding things to > make a target out-of-date. >=20 > .MAKE.META.IGNORE_PATHS is the cheapest and generally most useful >=20 > .MAKE.META.IGNORE_PATTERNS can be more selective and >=20 > .MAKE.META.IGNORE_FILTER can be expensive, but let you do a lot more. >=20 > With recent bmake (MAKE_VERSION > 20220126) you can also set target = local > variables which means you can set say .MAKE.META.IGNORE_PATHS to apply > only to a given target. >=20 > Of course trying to get too clever can end up being counter = productive, > but the tools are there... I still have the addition that we found was needed in my experiments years ago (white space details below may not have been preserved): # git -C /usr/main-src/ diff share/ diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk index 708559edcdb8..e710ae057fc6 100644 --- a/share/mk/src.sys.obj.mk +++ b/share/mk/src.sys.obj.mk @@ -66,6 +66,9 @@ SB_OBJROOT?=3D ${SB}/obj/ OBJROOT?=3D ${SB_OBJROOT} .endif OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ +# save the value before we mess with it +_OBJROOT:=3D ${OBJROOT:tA} +.export _OBJROOT .if ${OBJROOT:M*/} !=3D "" OBJROOT:=3D ${OBJROOT:H:tA}/ .else where I had to use _OBJROOT to have 2 appropriate paths built. (See later below.) It is still not part of the official share/mk/src.sys.obj.mk so I normally avoid referencing it or what would involve its use. But I've not checked if it has been added via some other place providing the definition. Used via: # grep -r "\<_OBJROOT\>" ~/src.configs/ /root/src.configs/make.conf:# _OBJROOT is an addition to = share/mk/src.sys.obj.mk /root/src.configs/make.conf:# +_OBJROOT:=3D ${OBJROOT:tA} /root/src.configs/make.conf:# +.export _OBJROOT /root/src.configs/make.conf:IGNORELEGACY_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr /root/src.configs/make.conf:IGNOREOTHER_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/usr/bin It was associated with symbolic links begin involved. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 6 19:51:44 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 4ZsTYn2yFyz5vL5N for ; Tue, 06 May 2025 19:51:57 +0000 (UTC) (envelope-from eduardo@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 4ZsTYn2Nchz43kn for ; Tue, 06 May 2025 19:51:57 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746561117; 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=/hA7wLJT+hJqWrRGpqMlnxUUIuKSHQn6mKX35gUoE8k=; b=WKr0I2A2q4Rr1J/e0uHCBdnaAw409NyjJhio30N0iEE6xe1lijJGjIx9+Du5yAGfhjExJA 4U7fBiPdQFIzTImtUxM+D937BBFWMg0TbJyjuhUUGGa7YHc6tRYTSDukU4ogdrdSGOKz2k Q+AoTYhrtjA2vpHpVxQsEMXLAvWJzTMMEYFORTDj29kWbniRRj26Okqp6o/tnheHyW4Mzs D5QpVR7oD1PYMLmHHJjfEjosO8aUTDvH1dNFLXnm/B03g92ysldE4P63LXkmDu5X9enu/U y29N4ROXxQk7ovqBmsBPg9UchooTnzsfIBKQfJHaBkI/DJFC6sJ2By675wHtxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746561117; 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=/hA7wLJT+hJqWrRGpqMlnxUUIuKSHQn6mKX35gUoE8k=; b=eT7eVBKbAcjPgz9FOUsf42LO3U/Be1ojfu5yGc47uFqNAu6ktIO21ssAuM9TQxoKHv3sYr eoQvU6XtXm50Jbcc4zpMSS+AqftVa9VgBa9dOWGFe8FTzxlgWs0we5SBQQV9ZlJj5sGoba uZx8HuoIbBFCXbxhBtyzcZPS3czoYwXq6JUw1JhWWuWjo9SES8CE8a6SgtuiJrPbhVX69S e1yn5JvdSDFrytCBRPA2lg6dHRjOu9xL3g9fzhsmGxC2d4Os/fjJpwQKmN21f2e818kL6T 7xyTojcmw7BFn9V+gx6OarWhTMdELeOLt3w18o18roYqvt5YLKhNoeDrPFIfdA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746561117; a=rsa-sha256; cv=none; b=BvhWhqCnqDc/krelG1vgw6xzANYH0xt2dnX2YRzHTtK6heZQTb8B1zibXhBWtz+suzaRDI dexKwu/mhp2dAm/kvTHMmxG1HQQT1rER6JJo/Fg8HDX/rXvgy25IiLYt/k2nkkypmdnhw7 6yepIZu7i+DdlqT8q1b/Zd05+udu5owK2ZEwqGUFzC5N2bcBD4w2AVrYWOiqVA/kRibA2z eccRh9dsg2Anyr6jEIxSWj+wwVm81vdedGk7uz19MtioUfD+hJSN88BQPVR4KNiXVqPXEN 2Bj4evdktKtdL2dCmet6w46NC05Um8gyPHGcpvkmwIP3Ry2SJKdZNnAxn9Ze6g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZsTYn1m1zzyPm for ; Tue, 06 May 2025 19:51:57 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7c55d853b54so71930585a.0 for ; Tue, 06 May 2025 12:51:57 -0700 (PDT) X-Gm-Message-State: AOJu0Yzy2Kf0ce3R2Fxa3bfTSgO8rQtRG4uM0bNwXAtTb7pNr9FQTyb/ 8W12dqGnjU9o5eKSznKutEZ8wchsRaPVNaNuui0JN81NEBn7CPRwxvWzYBZfFDXQWjDvYS8d2sk gSJ9zFB9FHp/jCdqvXLmmC2FX5Lw= X-Google-Smtp-Source: AGHT+IEZJzgK5FKa+Ww6pRUfaqLrCLsj12XodcJ45bsfOdRLAQfH9HorQd2veHrgh0roGDtbPkMdfLRXA7lPY3ZQ5Is= X-Received: by 2002:ac8:65cb:0:b0:474:e213:7480 with SMTP id d75a77b69052e-49227867753mr2277141cf.15.1746561116583; Tue, 06 May 2025 12:51:56 -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: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <5BFEF4D2-0E42-46ED-899B-D27169DFC322@yahoo.com> <86E414BD-6FA1-4B46-B0FE-DEABCED63DC5@yahoo.com> In-Reply-To: <86E414BD-6FA1-4B46-B0FE-DEABCED63DC5@yahoo.com> From: Nuno Teixeira Date: Tue, 6 May 2025 20:51:44 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUEJHCVC4QgxOdAf1x4WHl8UcPF3Ne-2AZY2rtqBRy6sNGF5mC3FBNLGpKA Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: Mark Millard Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000eebf0d06347cf288" --000000000000eebf0d06347cf288 Content-Type: text/plain; charset="UTF-8" Same context of WITH_META_MODE, it will speed up for sure my builds, tunning what parts/targets of llvm will be built: > WITH_LLVM_TARGET_AARCH64= > WITH_LLVM_TARGET_ARM= > WITHOUT_LLVM_TARGET_MIPS= > WITHOUT_LLVM_TARGET_POWERPC= > WITHOUT_LLVM_TARGET_RISCV= > WITHOUT_LLVM_TARGET_X86= > I will use instead the bellow: > WITHOUT_LLVM_TARGET_ALL= > and check for results, plus WITHOUT_CLANG_FULL= for extra tunning. > > May be I've guess wrong about what you mean by "clean > > /usr/obj"? > When I did say it I was talking about plain builds after `rm -fr /usr/obj/*`, but it is out of context anyway. The context is METAMODE. Other thing, I'm wandering how DIRDEPS will perform over METAMODE when we do a buildworld/buildkernel with same src/obj on a new BE. First I will do the llvm tunning and one of these days I will try DIRDEPS and see how it goes. Thanks! --000000000000eebf0d06347cf288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Same= context of WITH_META_MODE, it will speed up for sure my builds, tunning wh= at parts/targets of llvm will be built:
=C2=A0
WITH_LLVM_TARGET_AARCH64=3D
WITH_LLVM_TARGET_ARM=3D
WITHOUT_LLVM_TARGET_MIPS=3D
WITHOUT_LLVM_TARGET_POWERPC=3D
WITHOUT_LLVM_TARGET_RISCV=3D
WITHOUT_LLVM_TARGET_X86=3D

I will use instead the = bellow:=C2=A0
=C2=A0
WITHOUT_LLVM_TARGET_ALL=3D

and check fo= r results, plus

WITHOUT_CLANG_FULL=3D

for extra = tunning.
=C2=A0
> May be I've guess wrong about what you mean by "clean > /usr/obj"?

When I did say it I was talking abou= t plain builds after `rm -fr /usr/obj/*`, but it is out of context anyway. = The context is METAMODE.

Other thing, I'm wandering h= ow DIRDEPS will perform over METAMODE when we do a buildworld/buildkernel w= ith same src/obj on a new BE.
First I will do the llvm tunnin= g and one of these days I will try DIRDEPS and see how it goes.

Thanks!
--000000000000eebf0d06347cf288-- From nobody Tue May 6 20:14: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 4ZsV4067zKz5vMNn for ; Tue, 06 May 2025 20:14:40 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsV403lghz4QMQ; Tue, 06 May 2025 20:14:40 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 546IQeiZ013132; Tue, 6 May 2025 13:14:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to; s= PPS1017; bh=HCjhCgHUel3b0JNXdNOUJjfWcFRXmCY7rnAYElD71Wc=; b=VUFB LzEnNO5twGWMzHpGfTJjFP+NLiwOv4U/XrQ1OKc5LJAj5zpuoKWloR5b54hHpdqa k6Iy+7wWUMmlezLqgB/BQJ3xzN6iMl/VdLNcnmPxi2H1zIa0khNJtuTaQTZ/HU6U mdQaMcPowUIibtCgFQklP9ud4CAifytaL6VT7Okn/rmA9bP/ya6XiuNmL2PHTdeU PI3bgnQwy6QGhbcq1r4/7RCsTIzyTtpSV6TRZ2ciAbPdE5xalrIvWDX4kG1dlIxt ES6UgMxZA5ePJR3+zuvxIV0y8F3xkuzQ+AHN7UfpoSNerzo796CloDDMMzpR9acO ULHfP6mbpxPR7JuzdA== Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazlp17010004.outbound.protection.outlook.com [40.93.11.4]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 46es8dce84-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 May 2025 13:14:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ImypSVYl7hmsTjJlozN5/JqkSDuZmsTfbgtaWmoDvQtuQLt1i/4a3pz76urK2GvkcqYeOYeTOHdVj8ALh1jbsxwPgOaNBwSKXEUJhUZ0RhIFATUBKcrc00FhTsu/OsXIZq5cUsNX1ZQA6gssBoTgHYZhBTjpDzmiaBiRgWuwndFL58EMPHAbbfyqIxU89Juq6C4Ujr/BS3HhZAA7duE5Z3p4zUtP5T68/rZdOcgmPR4wk3fja+nhG2ro73HNPIGhPQNB+SLkb7mwBCMlqERGaY84fBnW4I8W06BlXw7Vm8MOo3V7KMBDzM2aos8HH2eSK3ubvqXjeZwDJLCfZUOlBg== 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=HCjhCgHUel3b0JNXdNOUJjfWcFRXmCY7rnAYElD71Wc=; b=BgWZgpk4uuu9tBMMeoVbLk4Ek5fp+ch6pM5XTraq9BVvE8DRHy11pAdid4N6TKprhIbtSmgJNrnljyZ8orgmq+70F6RH3Lt8m8F+MrQSpFicmc4hQyDzCnEooZKsTexIOLNmcuNRN0+LL2sLtHoiC6y+k8xAIXowy5TcLyIGo3s0YSJUNR6uIRk7qrhpph99ncti2rY3dfSuNj8VvOGG+waqwDeqO5Jr9ytqxBFi398AUeUCEPAj+y6nWYAqm60sZMy0gq2BPY3Gt74VqeQKig2JeocLSFVg+o9c54cSIpN8Xr41BmVsfkJ1KE3pgnG3dIqJlgNJ6J12bxUDhhHdWw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HCjhCgHUel3b0JNXdNOUJjfWcFRXmCY7rnAYElD71Wc=; b=dcf74M5b+sbHYRAR1FU21yOsWkCRrJLTUn49CzX6M4zHQFZ7v80FasR3LsOr4HCZQKxJnWNPZWv7XUiyI//BvYEmEYbjrC+OtrA4Ni4/GDEueKKDBFrN9IVRToFKNY47u/n801NX3kyXEpquH775ZKAr/9795dFl93IA4yHRThQ= Received: from MW4PR04CA0179.namprd04.prod.outlook.com (2603:10b6:303:85::34) by DS7PR05MB10044.namprd05.prod.outlook.com (2603:10b6:8:ee::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.25; Tue, 6 May 2025 20:14:35 +0000 Received: from MWH0EPF000A6730.namprd04.prod.outlook.com (2603:10b6:303:85:cafe::fa) by MW4PR04CA0179.outlook.office365.com (2603:10b6:303:85::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.33 via Frontend Transport; Tue, 6 May 2025 20:14:35 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by MWH0EPF000A6730.mail.protection.outlook.com (10.167.249.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 20:14:34 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 15:14:34 -0500 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 15:14:34 -0500 Received: from kaos.jnpr.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server id 15.2.1544.14 via Frontend Transport; Tue, 6 May 2025 15:14:34 -0500 Received: by kaos.jnpr.net (Postfix, from userid 1377) id 94E38DBAE9; Tue, 06 May 2025 13:14:01 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 9481EDBB7C; Tue, 06 May 2025 13:14:01 -0700 (PDT) To: Mark Millard CC: Nuno Teixeira , FreeBSD Current , Subject: Re: incremental bulds from scratch with beinstall.sh In-Reply-To: References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> Comments: In-reply-to: Mark Millard message dated "Tue, 06 May 2025 12:32:13 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 30.1 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: <85723.1746562441.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 6 May 2025 13:14:01 -0700 Message-ID: <87401.1746562441@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A6730:EE_|DS7PR05MB10044:EE_ X-MS-Office365-Filtering-Correlation-Id: 434b434e-ed9f-4ab2-547a-08dd8cda9ea6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?bEMLKu3D3JyahlPR7QDPBGWM+pUvcRXtRfzdLuFSSK7+W2Jjmh8ey57CIKx2?= =?us-ascii?Q?TlufocW2Do6FUw9bzFTkB7tYl/scWEFYlcRGttV9xhASrILO1fHufvLrg5UD?= =?us-ascii?Q?nQSgC6K7q1wId+bE+A24LDWp1/1KNJ/Xue8xEMZCOmRD6DV6pS8495fiIRZC?= =?us-ascii?Q?873EsP6Z2OjIfJSm20IKTmQ6gEiMOu8ehMK0CQK57JyTtRJKfpll+KdIqdL/?= =?us-ascii?Q?pQYQ46gnGphuhjN/NISpGH2zKdamCU+Yt1mE9LVd1ooEOkZgEMYHU12r/JPA?= =?us-ascii?Q?qZmCp0Alt8k839gxFzOndU0U+DBrAgaUb46Z/4c7eTboKZ+OSK0TdRiSsotx?= =?us-ascii?Q?8og8Hx7imBWBz+X/53zZ6ThZ1NScA84NKCOiA8iSEZ5QZGxFYFQg7U+yrSOP?= =?us-ascii?Q?R5u1sa09sBvAc6egNuMAOrf+tGdoIO5s0BViEFt4Qo3pnkHS5dnflKrpmv9p?= =?us-ascii?Q?oQZsEU/k5rKVAnGpvAI5/ljJ1iWzRoOEWXIjO+xdLaTxJKM23ImpFG3yzDoz?= =?us-ascii?Q?XsHKKyo9BSqsmIugtBQHOk2gw4Es3mE0/GBl2gjIX1mEvIQvnk54fqxvmpi2?= =?us-ascii?Q?u+WWRCC6dquWXl+iE2+C9dLA6F0WLB3wHdXWw9rms2Tp8UUzqv0AKoFRhkLn?= =?us-ascii?Q?aVbzvAD2addwg55h/8/hNXmXyTsqlgwVA8Qk+6FtLLwEXQi/ly+duaeYyX/7?= =?us-ascii?Q?lBq9PvNzNNiV7K8vDUbeqUEDQhMnT9QxF7Sk/VTmc6Qh2aZEor3tfldy87BQ?= =?us-ascii?Q?+X0kYAKlHP1yul98FIsyRWWm9gRzzsuyFvQJTbCqFthfoP1FHIdq83JPZN/C?= =?us-ascii?Q?VPT9Zlp0Xl9/DVPq6Xvi6gR+dUUGL5TQN8tSzmkO9SDYSPDrXAPS34+Wlnby?= =?us-ascii?Q?GiltpPd8RJD9k09KNBf/yPX/ErPMiRrayFnwjSEez5FzNRbJcNV1WUaebrQ2?= =?us-ascii?Q?GSZHShRuKSteHQra+xLjM2iCRzE1req949KeOS/xrSZsvPmCbZlKVVhyqx2C?= =?us-ascii?Q?poVigveh82MES0VHLqpG3t7ZnVyxD2c8PqsJZUoVfe4H514CKxyE7sHVW5ar?= =?us-ascii?Q?VCh/IHv1m3DPMNqNxNxTTUqZbAfGwAbzmqpPP7bFNPeZPEqHK8kgYBaoggju?= =?us-ascii?Q?xZqQj/q/yZaBAL4/XlYKiRJdsIwF20tgEl8NrKpq6bMpoZDsr3KjzpGKS1wk?= =?us-ascii?Q?7BnAMmkXnm9FULQ25hbSSw8VCH5vKQDKoONwZqXr08bEi4O1UCsD47fMPJxc?= =?us-ascii?Q?93zEJYMjjYpB9AcfHaS8qsD1EXAd9/3tGFFGyhWwHNJi+7ca6ZADBu6sP3Qw?= =?us-ascii?Q?EpcIusaPYPE7JTGcNvv1XzfFpvrqPI00W4vVyB+b4l5YxlmrOb8/xUml0UVc?= =?us-ascii?Q?5CxrUc4IyudTLmMS+oBIIB0i0bY11tB1Pk0hFIdFutL2URmGnRyA0Ex5U7T9?= =?us-ascii?Q?FHIIQrCt6Bc8K44/HkEomUpecyuNbUQsLJuJFAoyytl54Dn05Zz6RReJiSuh?= =?us-ascii?Q?w0EnUdhOD1bpqSjOwnOFr8Gy4W5hr3CnZgT0?= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 20:14:34.8370 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 434b434e-ed9f-4ab2-547a-08dd8cda9ea6 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000A6730.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR05MB10044 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTA2MDE5MCBTYWx0ZWRfXyDuaszhpizoN pmSDLh8HhuBzrHSBR+9MSkfbxuMSWUY7TfPQhyojdC2HpokFxP3ygpOO05UwzI8Vi3rOabKMYUX X5AZ6g/keIUrAgwnlDYKDwylgPAXgcpr2IDNfEPFsJN6zczJvPGyrv8/Gdn8K6Ek9FXsG7FR6+V kldSV0ircJz3Y2mdwAkUNRUWjmvIAbDIadkfiE0T/7DIKgD/idHmvirsrx+wiEwelZDwedRzcs8 vKdZOTF9HvWhRwyHp1oN2JqPXnAPNta1DnrkAFqWCP/vQd4ghRDMhAvL7DCr5vvzuE3KB85T8zO F7DYNhr7nxz3e0T5Tg/bMmQKqqP6sR6tYKADyrXFpNCW/fXCsm2umW+gSpFwsSVdsR5YdO/GwV0 QkMjSggvfe27Mm1IMcbI/lHyDf67wplp8w3/QnIKBvYjRv7V4/N2/fEWvRphhq7foVgjpOHd X-Authority-Analysis: v=2.4 cv=EMoG00ZC c=1 sm=1 tr=0 ts=681a6dae cx=c_pps a=uYdjBAypVXkA+ZVpDPXefQ==:117 a=YQU41r7WENJiSYrYYNJVsQ==:17 a=h8e1o3o8w34MuCiiGQrqVE4VwXA=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=s63m1ICgrNkA:10 a=rhJc5-LppCAA:10 a=CjxXgO3LAAAA:8 a=CVnTXXcy-bL-w-LYAykA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-GUID: n8GGp5LfzUi3KJ3LcIdqqlSf3kmdwtax X-Proofpoint-ORIG-GUID: n8GGp5LfzUi3KJ3LcIdqqlSf3kmdwtax X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-06_08,2025-05-06_01,2025-02-21_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 spamscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 mlxlogscore=647 phishscore=0 adultscore=0 mlxscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2504070000 definitions=main-2505060190 X-Rspamd-Queue-Id: 4ZsV403lghz4QMQ 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:26211, ipnet:208.84.65.0/24, country:US] X-Spamd-Bar: ---- Mark Millard wrote: > > Of course trying to get too clever can end up being counter productive= , > > but the tools are there... > = > I still have the addition that we found was needed > in my experiments years ago (white space details > below may not have been preserved): IIRC there are a few problem locations in the build where this or similar caused problems. I think this relates to some hierarchies being built with custom env - which makes it hard for src.sys.obj.mk to always get things right. I think the change below or close to it has been committed and reverted in the past. > = > # git -C /usr/main-src/ diff share/ > diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk > index 708559edcdb8..e710ae057fc6 100644 > --- a/share/mk/src.sys.obj.mk > +++ b/share/mk/src.sys.obj.mk > @@ -66,6 +66,9 @@ SB_OBJROOT?=3D ${SB}/obj/ > OBJROOT?=3D ${SB_OBJROOT} > .endif > OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ > +# save the value before we mess with it > +_OBJROOT:=3D ${OBJROOT:tA} > +.export _OBJROOT > .if ${OBJROOT:M*/} !=3D "" > OBJROOT:=3D ${OBJROOT:H:tA}/ > .else > = > where I had to use _OBJROOT to have 2 appropriate paths > built. (See later below.) > = > It is still not part of the official share/mk/src.sys.obj.mk > so I normally avoid referencing it or what would involve > its use. But I've not checked if it has been added via some > other place providing the definition. > = > Used via: > = > # grep -r "\<_OBJROOT\>" ~/src.configs/ > /root/src.configs/make.conf:# _OBJROOT is an addition to share/mk/src.sy= s.obj.mk > /root/src.configs/make.conf:# +_OBJROOT:=3D ${OBJROOT:tA} > /root/src.configs/make.conf:# +.export _OBJROOT > /root/src.configs/make.conf:IGNORELEGACY_NOSYMLINKPREFIX=3D ${_OBJROOT}/= ${TARGET}.${TARGET_ARCH}/tmp/legacy/usr > /root/src.configs/make.conf:IGNOREOTHER_NOSYMLINKPREFIX=3D ${_OBJROOT}/= ${TARGET}.${TARGET_ARCH}/tmp/usr/bin > = > It was associated with symbolic links begin involved. Your use of _OBJROOT looks similar to how we (Juniper) use SB_OBJROOT. We run make via a wrapper which defines SB (location of the tree) and a number of SB_* variables which can be assumed correct. It also obviates the need for make.conf Of course our build is never used to "install" anything - we just build packages which are then installed, so it is much simpler. From nobody Tue May 6 21:05:23 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 4ZsWBp1DKRz5vRCs; Tue, 06 May 2025 21:05:38 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4ZsWBn37yLz3jgM; Tue, 06 May 2025 21:05:37 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=UlaCnXN9; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5fbcc5aa54aso1360383a12.0; Tue, 06 May 2025 14:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746565536; x=1747170336; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gfuOzrdI0ouC39MCphqT2czr3ReeuTDBYzE5+31/fHw=; b=UlaCnXN9eFk645DlSWetnFvjFrCyoyCLXDCOAQwD0z1s8H2XI9E9jO1jJx7w6E/u7L CbXlDr3fEagUFDeY5q3YiBLkxNqv2dSUgIRaZuHBelTwoeJseSv+9tws2eEFN3dAfes2 7DAt42SuFcR3gtSO4gV39/VyAEMv73pnsZzymOfpB26THtzzW13kQZCU83JyknzeZ26C rG1HlKl7VMg9JkViWxYn6cT4K+bkyt6oE60EKSHM3dus87I44dA0tcbhKGvhXb0wyiFS EbkzcTq7qzTOpsd7m8CW1UlB4a5nKj32L0O3YNWtbjYr/z3wDQo2S0gw6+L+mjiCm21K ABKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746565536; x=1747170336; h=content-transfer-encoding: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=gfuOzrdI0ouC39MCphqT2czr3ReeuTDBYzE5+31/fHw=; b=Cf1+Fcr7djaK/tbxmEFbkPPYtRBefwJDdQ1pLKfGTiBDDybsAY7araCP12gM64e/eB AE8pVP/+zUDd0smJQlDx6oDwIGxfF4qo+fG6Y2CdeMjLr20DrN2eezNBX+j5B+yYMgnw bly7K1ncAy/s5veTBMDC3O6SzcJ5HVZ2E+LA/aVxZhPFdvd7K3KkEICrPNHUp5Pd+/xv mUuipzJms16hxGRYj9WcIodmoLk76TJLY/sKdxGqcUawGWeXAwrMFDFqhpSg+NtR8vBK TNJiItqQhe0SjRAWNYCwcxiqRA+gIRChzdCm5y6zFRKkSxlyueWy/MNgB/Tkhm+btvk5 JUxg== X-Forwarded-Encrypted: i=1; AJvYcCVWL4IykvNskrcUOMk+CRbJK28hXriKZmuHNX55rI1Bo+T5398SOfYUCJYpywobFUciOT9LaoPP1tzxSU+awIKS@freebsd.org, AJvYcCX5VV/TJxHkDsNyz8NF4Axj/MHzMUV0plYwOPwpKsjkcYnMaConLG5gr1aXDZRdGau6ckdj6AUZ9NIQIcw=@freebsd.org X-Gm-Message-State: AOJu0YwgAuG63t9k8wdbRndSMvSGybPWUA/X6p1QdzlKZuQQC4gi9+Ut 2zQWPPZw9zyZlpjXBpbYy/hMSzia46p568RGHXkOfbRyHdsJl7do/nmOvxWr1i0MKF3tDT+TBcW JoUOim6XVest43DQP9eQEW9d8Rw== X-Gm-Gg: ASbGncsVUgj/I1ky9SbgdV24ZxWIw4W7AnvLtWtFD6A+5iY+ko23C/biOkokHRHwAoe OiXyLh72mAVQ55m4xVygoZUWeEiy/YJgFw4QKJrNV4IehdLS+ncQbJp1G0rindfVNjavbamKeKk RmpYFN8ccE3XGIW41e6kgJTSOVJ3j6y/FHgGlya3OmvlePpkXzqnI= X-Google-Smtp-Source: AGHT+IFcXrdhuXZg6OemXGisJm/zSD8CzD3MM4uAnkh56C7wtJQfapD+h+RDersYsj0DFbvUJXADSW15E2UiVIkqLsE= X-Received: by 2002:a05:6402:524b:b0:5fb:d4a5:a3c2 with SMTP id 4fb4d7f45d1cf-5fbe9df633emr633794a12.10.1746565535566; Tue, 06 May 2025 14:05:35 -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: Rick Macklem Date: Tue, 6 May 2025 14:05:23 -0700 X-Gm-Features: ATxdqUHCS3xadkg23j-IZHwiIZAcTpQBXpqesH7bKwb2DxvrUWyjqyz96X0yg5g Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Rick Macklem , Lionel Cons , Cedric Blancher , freebsd-arch@freebsd.org, FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4ZsWBn37yLz3jgM X-Spamd-Bar: / X-Spamd-Result: default: False [-0.60 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; NEURAL_SPAM_LONG(0.89)[0.886]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] On Sun, May 4, 2025 at 3:28=E2=80=AFPM Lexi Winter wrote: > > Rick Macklem: > > I have coded this, but having a pathconf name for something that is > > specific to a file is a bit weird. kib@ has suggested that it might be > > better to do it as an ioctl(). > > > > So, do you think a pathconf variable is preferred, since it is > > "Solaris compatible" or an ioctl()? > > ioctl() on a regular file to discover its attributes sounds rather odd > to me. all else being equal, i would vote for the Solaris-compatible > method in the name of compatibility, since Solaris has supported this > for >=3D 20 years and i imagine a lot of third-party software has adopted > that API. That was kib@'s opinion too, so that is what I have done. In general, all source changes except for ZFS are now in main. (I still have some man page patches under review.) If you start with an up-to-date main based system (a new snapshot should be available in a couple of days), all you need to do for testing is add the ZFS patch found here: https://people.freebsd.org/~rmacklem/zfs-xattr.patch or https://reviews.freebsd.org/D49654 For those not familiar with FreeBSD: # cd /usr/src # patch -p0 < # make buildkernel # make installkernel # zfs set xattr=3Ddir - Reboot and you should be able to test things. main now has a Solaris like runat(1) and there are also these little test programs: https://people.freebsd.org/~rmacklem/xattrtest.c https://people.freebsd.org/~rmacklem/xattrtest1.c https://people.freebsd.org/~rmacklem/xattrtest2.c I have not yet put aliases for the Solaris arguments in the .h files (I'll propose a patch soon). Until then, for Solaris software that uses Solaris style extended attributes, you will need to replace.. O_XATTR --> O_NAMEDATTR _PC_XATTR_ENABLED --> _PC_NAMEDATTR_ENABLED _PC_XATTR_EXISTS --> _PC_HAS NAMEDATTR Good luck with any testing you might do, rick From nobody Tue May 6 21:31:03 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 4ZsWn05g6Nz5vSw5 for ; Tue, 06 May 2025 21:31:48 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsWn02ZNGz3yhn; Tue, 06 May 2025 21:31:48 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 546IEKpj013114; Tue, 6 May 2025 14:31:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=1ST2Dr3M4Jrxv m1f2QScTcxp4w5b6c+GB+7QZRRfPOY=; b=eXWqyDEK6kbc5NsOtEzkPJ3kroQxS sN5MYRaDa+Kua/s6fIga4rqW+tKeRrLsEPddOtXGxKBB5nQkFlFiAqblztbudmsq bApeugzl1TzfP6QSD4R3VSTTtFbigeXv2VYHsUtLVpBAMtnedhhlBs3UQhOjihNY 2hFIJGH/n33kl8E9Tfjx3FssGBligV5snyzIQemoTGtuo+hY5xQUJ0fE39iCeG3u VtqZ8kU4iWVhFITU20YDGPvc7FvW4NJLYnDkMZyYI0frQjUf6m0A+uPdp5PfjdqC pe3NT2CuljyaDtzqNzrnBBjqufKcBx7LJQB7p42dl7v203OoOWV+3G4ng== Received: from dm5pr21cu001.outbound.protection.outlook.com (mail-centralusazlp17011029.outbound.protection.outlook.com [40.93.13.29]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 46es8dcjsd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 May 2025 14:31:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sSEKH+G7RMtFLMTGcBzDTibFGNsoh8HzExv132BqtwOG0e1haznpb8ajnUSvA3S4A8wvqsBCuGPJLEIBGaI7HZaKkEvbp7JCbVvvVBRiVhTQikxy9hjCdhRmEDyjVdxjI5ENWomMb6UIzhl4I6Azz8wn1VnYrQORqdP1FAYsdmy8y9xBIqq8MeWjQq54JGR+kdBJirCSIeuTTezhD4qZKrTPLZr0Y4BoDZRvlszFlYal/IyMiZi4mO5CX2tt4tzquJHO3y0PdjZB83arYXhT6/3rhWOk6ozoAE3YQdYU6a4Dbt36RQUxEXNsk+zzlh3Vrm1OTaoNo+JP4x7rlls+kQ== 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=1ST2Dr3M4Jrxvm1f2QScTcxp4w5b6c+GB+7QZRRfPOY=; b=J2/76vcn0m4MRjY3tczoH2Z2GKBoXo2xyijw88mPiKqu9gsvIV+kBFYCEuyJvfGkgRXz69BidjkyIUJgcs9mO7Br1F7R36o2/rjLDr6OYHVA6yl7m1rw+13i4FeWfhm7Mw0yd7vxFhWOfqIDrgsfte9ARhB5LVtD6VfvYu+7h2m76Nc/QofCEDgUFksBa/q+LBj+T+EnCydpPNX+UAMEOCkFyUEqZd09pM7cLC4KKBiFWLicSc3dsQn75hxqVohtnTUq5m/1+YLyOP8YLLAk7OXdJB3CGsQWzbpppS4rWDCjPOVUEbYhzxQUWURcTNlqc9JQdUoK5tUBOAMpszRRFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ST2Dr3M4Jrxvm1f2QScTcxp4w5b6c+GB+7QZRRfPOY=; b=cieYr74Kil10dIK78Al05kZ/teSreMBumbhy/L/D3DHCav2q7tnjnX0N2RkzhxguDyE4oWEy3XSiMQHbDQZuWkZZd0v3oKNt0OXuWyfRj1bFhyxLdU/fw6+lKyyHzJctdSFf9ac7dmRNAWElHVHE5t41ysrIZGAUdPqETrM+dlk= Received: from DS7PR05CA0003.namprd05.prod.outlook.com (2603:10b6:5:3b9::8) by BYAPR05MB6632.namprd05.prod.outlook.com (2603:10b6:a03:115::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.24; Tue, 6 May 2025 21:31:37 +0000 Received: from CY4PEPF0000EDD6.namprd03.prod.outlook.com (2603:10b6:5:3b9:cafe::5a) by DS7PR05CA0003.outlook.office365.com (2603:10b6:5:3b9::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.19 via Frontend Transport; Tue, 6 May 2025 21:31:37 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by CY4PEPF0000EDD6.mail.protection.outlook.com (10.167.241.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 21:31:37 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 16:31:36 -0500 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 16:31:36 -0500 Received: from kaos.jnpr.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server id 15.2.1544.14 via Frontend Transport; Tue, 6 May 2025 16:31:36 -0500 Received: by kaos.jnpr.net (Postfix, from userid 1377) id E8820DBE88; Tue, 06 May 2025 14:31:03 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id E7282DBCB6; Tue, 06 May 2025 14:31:03 -0700 (PDT) To: Nuno Teixeira CC: Mark Millard , FreeBSD Current , Subject: Re: incremental bulds from scratch with beinstall.sh In-Reply-To: References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <5BFEF4D2-0E42-46ED-899B-D27169DFC322@yahoo.com> <86E414BD-6FA1-4B46-B0FE-DEABCED63DC5@yahoo.com> Comments: In-reply-to: Nuno Teixeira message dated "Tue, 06 May 2025 20:51:44 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 30.1 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: <39256.1746567063.1@kaos.jnpr.net> Date: Tue, 6 May 2025 14:31:03 -0700 Message-ID: <41179.1746567063@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD6:EE_|BYAPR05MB6632:EE_ X-MS-Office365-Filtering-Correlation-Id: e3684d33-9205-4faf-5248-08dd8ce561de X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|13003099007|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?eVO2dK0luRawf8f9wlzMraomrGJ9HPfJjbWFATJfsIZGFEJzMkr+BO7eBh3V?= =?us-ascii?Q?mcrCBz1HngrFwMbVg3yuKC3NWVwJ3vuVwifpjc2Y8kGOR9hOL7pyh0wNNyJK?= =?us-ascii?Q?0yxZfI59v5o+X9hij3w7JAyJ39KMZl0wKTIuIrPb4yy6fidPBbHKDjGRHIeJ?= =?us-ascii?Q?cAIrXfWGTtheNyHBL4MLMtbYeNtj9ZsAtT0RpQknSn33JhBUGg7yoFzZGjhL?= =?us-ascii?Q?Q+Q0WWEjkLmPw7uUWgGRnkiSJveajTD2Ojg5RH4IZskeQiBSSdBQZPg8/NwP?= =?us-ascii?Q?1dUIBPAnkTDgQ/rO36js7a2KG+J0QyRtQW+r7KBybP09PXnJaWfAsNwUJMKP?= =?us-ascii?Q?mXpPtqoX6Fq1fw3JtHvAU+77Csiz8l8NdrDc6rH17ZODPUoD9Gf4hSDKJn3I?= =?us-ascii?Q?zyCOE6y8SFYeg13lFVxLcAt0XF/1O8QbosCcQqQ4MUg8eUagc7/YWmK/UIj0?= =?us-ascii?Q?ONqhKfxe+P18F8otI4mgPGr9Hz2OfL+WSmvHg+HjBQvPmBYCJVVBMvXOCtIq?= =?us-ascii?Q?2JO+jdiHTkggbZbb7eTRCCSXm/7TCdo//LDKEdJAeyXK3YDCUJKrNvsxsuQ8?= =?us-ascii?Q?2SEvQe4ewFHFdFurkYJ/yZbao5UKeJ367PxuQqk+KwO/sEIn79m8scipf3Zm?= =?us-ascii?Q?6nFakHMWOA5kgc5cIbibH/OQ9JX5Ao/tz8lN7hJyDTLR6TTfpsqqih9kY7eq?= =?us-ascii?Q?sgz0wQgAZhoTfj+zLHjR8PmUKZ3IPVI2vgiBzd/W1gXFR5l5V82gsQ/8vZKV?= =?us-ascii?Q?/2MWZHMKvWPDyw1FGSdFJNaMW141eYH6+50zObQe2iQ2uhkg62LBwFAF8bRY?= =?us-ascii?Q?u9dXQESfmoi6g2d1ipUxuJuJKOWx9mvLxAKleZw6Kh4vN7MPxQ5cFOx/QDQF?= =?us-ascii?Q?i5H0ABLgBa8mh1FlwiTjIvERq8bMuP7KyoAIviwaz22fUP9WkfcmZJEjXn8r?= =?us-ascii?Q?4rOIBryhc/BNupDDwCaarQGMXzBmlT9ARHQVLY8cMFw0ON57cu1yMWwPnnSx?= =?us-ascii?Q?uQjxRHDUM4ewBT9L8AZu6ONop2udjy/4AFB5mm3/OXHGbVcIPS8gzmBYxQu5?= =?us-ascii?Q?SbWvRdkKLMrDXEVN+EK7I+u+n4N0Viy6WL6DcpYXyYXq2hlJLisidj3Mc5Hq?= =?us-ascii?Q?BHo3IuJk/PtqO28gboLVuaPXlGfID75J8dqM/Z0OvijUgPjV4Ob1xp84XB66?= =?us-ascii?Q?d7wFg02UgNl8uQJ7e68DSNlsZ0bm+4D1WFG6NrdKInsS5jA3sAL+wdODm/nW?= =?us-ascii?Q?GWaacRygYxEv98f3oJoCftfZo0UsPsqfRDZ2AZxkmMNaU6cO5PR0X+MIO4XE?= =?us-ascii?Q?x+iRJ6Ik7kmntg/CSTg/fPwH8qUQzylHKuRig1xL6mfbjXDobgtWPiHkvmN1?= =?us-ascii?Q?HoEmWcFr2W8sI8cEbBtutLQZ98YRaorwP/iJxbezFajFIn3+a642p00AGLP/?= =?us-ascii?Q?OUbsR8lmjr5EyHr8dZkd0/ADAOmcisCRqdaF53B/S5/M8T8dYzqTZQ=3D=3D?= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(13003099007)(7053199007);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 21:31:37.3227 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e3684d33-9205-4faf-5248-08dd8ce561de X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EDD6.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6632 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTA2MDIwMyBTYWx0ZWRfX0haxUpKHTOhs FGXoPgYOyGxXCwf+iYo9ZDFW3VTGiGNbrMF4nOyJR9VShBx6MIu36JP/nNjv1Y1WI3cQCJi2hLg zaJah6/3BU+aOMpRPKCqzIpBblueSjPIhdC5q04Dk2P57ILLJDBVpARgKlJSsiKc/EKDv0+AF9D ZBK+22eSeuq5PuWhn5zGvtIc0rpZDMtTbDZohVXksakKrUCe6rXUKLED4+q+pnsNamfcfRuTXF6 Qo5Ve5CGmV+SnMtHVimyH0whtO/b/Mz8KFVxGpmOtxRaR1oKA+3HE30LwgJ9J7DjLw5XlQF7Qb6 Q47g7py/Th6rAPU18seP2mZsTgZ7VQz6f7gCePfE3cJGpf2cJ7rDribComAQdl5TfMUi7Z8FtWt koF3kVjobXTyOmL06VEm3UBFS1QUk9Xa3DPMqX405eFTy3ijqA/GPajb3b2H/NXfLH9i5G6t X-Authority-Analysis: v=2.4 cv=EMoG00ZC c=1 sm=1 tr=0 ts=681a7fc2 cx=c_pps a=SA2dW19TPv9rE6CiBNbh3A==:117 a=f/rncuQqEjTEF/G1odkJ9w==:17 a=h8e1o3o8w34MuCiiGQrqVE4VwXA=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=s63m1ICgrNkA:10 a=rhJc5-LppCAA:10 a=6I5d2MoRAAAA:8 a=nd5lDxp4JityZPbRWeUA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-GUID: iGJojvtey6zdVQCTBDvkIDhjpJy1q2KR X-Proofpoint-ORIG-GUID: iGJojvtey6zdVQCTBDvkIDhjpJy1q2KR X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-06_08,2025-05-06_01,2025-02-21_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 spamscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 mlxlogscore=245 phishscore=0 adultscore=0 mlxscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2504070000 definitions=main-2505060203 X-Rspamd-Queue-Id: 4ZsWn02ZNGz3yhn 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:26211, ipnet:208.84.65.0/24, country:US] X-Spamd-Bar: ---- Nuno Teixeira wrote: > Other thing, I'm wandering how DIRDEPS will perform over METAMODE when They are different things - tackle different issues. DIRDEPS is all about build orchestration - which dirs get built and in what order. It can speed up the build by eliminating tree walks and only building what is needed, but it also eliminates all the complexity of src/Makefile* the build works the same whether you start at top-level or in some leaf dir like usr.bin/bmake META_MODE is all about [re]building the targets in a directory once visited. It doesn't matter weather you got there via a tree walk or directly via DIRDEPS. One exception to note is that if MK_DIRDEPS_BUILD==yes, .MAKE.LEVEL 0 is reserved for build orchestration, no building is done. If you just want to build the leaf dir you are in you need to use -DNO_DIRDEPS or arrange for .MAKE.LEVEL=1 eg MAKELEVEL=1 make -j8 > we do a buildworld/buildkernel with same src/obj on a new BE. > First I will do the llvm tunning and one of these days I will try > DIRDEPS and see how it goes. The FreeBSD tree lacks the per package makefiles that would allow DIRDEPS to be automatically kept up to date, but you can approximate using targets/pseudo/bootstrap-packages which will populate targets/packages/* based on the PACKAGE settings in the various makefiles under lib *bin etc. Then 'make fetch' for example would build whatever goes into the "fetch" package - but not the package itself as again there's no dir/makefile to do that. --sjg From nobody Tue May 6 22:35:23 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 4ZsYBd1kz0z5vYnX for ; Tue, 06 May 2025 22:35:37 +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 4ZsYBc6P03z3wHW for ; Tue, 06 May 2025 22:35:36 +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=1746570935; bh=o5GxFrle1npBAmXvt9ofcvVkoPZ0rXI+Of75nuMdLCU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZCzHpF2TuuuYwwWXBrNajwJv0CkveRo9d9LQ4bwea/R31ZIbSILkF3tN+Ms8oxegXkCYv+SE9CxKUzgq2bNvsfCUah5UEFhyqmTSxMKJtEmuhnIZvyoeC7FXiIIp0HYeOlQZTBWDw6NQFlX9oCTQPey+kKvRvGCIRh5//M/Fz2CNC/fPsaPOqLka9f6yn1eygt4E0//48fYbCwbIlqBZYeADnGnE9k3dwcM5SrvNX4UYlUfiCXB2MlNzeoLp5hLzjLRmyNhNsMKeB3BXcysxN4nm/SUWC2uQvwO23+OpB2roPUoYbi+Fz/i0T4ulMwS0pQ2myZ48cxJYV8LsujZOjQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746570935; bh=66LVbs5wzkcJ6qw+DB0VhmwTn8rqAF85B6exstuw7pg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qR+c5J4SfNkyPJe4hbo4E9icADU/9rJ9/DawvmPdDDh4N4sCoBY0SMdHfmssWcL0f5CIa80JZ74GiwdaxFHAP/m0/W3mI7pjx3BKdvEt+LdBanER9PdX2eWccgiOCPYHIpElRepeRfBgYqVxtw9y1wlEAtkIuNez6i5r+RD7GkrrLm/KQT/5hUllwKAqftE2iDaejZb0l7YGJQAy6fdjcy28VQcQ3NSoQpxMfZMNoKYn4EzODO9aVcV1wjAPHgYqA3cFpTI5lbw02RLG/DaUlfJteDqayx/CH0ASDGQQPmWsrGCJTGoBdgtsJDeMnfXbPvp4NTw84n/QSvcWvbmkVg== X-YMail-OSG: lLIrSL8VM1kBfDAUNJ_Wn83BvWNnPyg9FyIkwAAsS1RCJbvoKPMQd5yWwrKfUz9 EaI23vjKLvQSoffN9f2Y1WpzxLPAruwyHhZmKgcvbMAuKTE_1tCsdRukbBE9G9p4rri62a5XIG_2 2nZAC_7vCy0NZZosgzjfxEvP_8YgozSbCT40VtF1_rcDWip99i3K7VU7LifX3D8xs8y_gNR8tPA. sscIXOXi4Q8XxOnMzNX7VdquzUxwn6B9UaZUnIk5uZVJItKeYO2u.Zljn.bY_XLAcKhkh7YNykou JLWFsB_oUPmdTY_W6udmJavurY6uUJD.cuLAY8nXNsQaz.lDXHIi8BeIqmx9HHXceeWq7ETXAmzb Aziid3QtdxgbU9iMFChGg1PM11V1zPNCIheQB0hzeYI23ZvRXlztgLTlHuL6nrphx45zhdznGVOJ Ue.jcZV.W6OzUtRBbWgk_yMYfQepnsDv97Tl3paqMUDxYd6cm4YDtDx688uErFT2kdwFHzm.HE.E 7Z1lWQ5_53mJFBlwAnpR_m44p7NNl3mFlml8PAtBl.pp3T1E78YPfO0cnU9IHFpx3x9.3QX_MTiI couIY8ZZhzAIMmXQOB0NEqhZIECHjpQh9GB0jJWG7wRvBcSXx0XjfWOdAnTC.SS30nrIZ1V1ZVnU QXstcHMitgnkeF_iWo4_YxPqIlNZdx4H8Jw157TkFQ.kV7O42v45B6QHhqX8FVg9QgCuLf3lmpZo LLUCrhW5cqW6Q2Cco92xzavxdz6yhqsT2hgGyxi_lFRp.qpGawgPVW8osBslM0jeIOlhdAWE8QyV KS2wIBn21hlEw4vwynodPJUeW3rTevIEgsnb797AW3H1jLqQWwghuIONojaDj7oI2LQZXuO2jjPW WSZ57DWWbxpHHkxtc.K9svAXUzd6HQ3_xullSPsmZs2e6a8.YtYGdohRgWO5ogKLzjns0CzZckRU 1d2UFQ6.7fz2h2fiEKzvannDLPG2XD.eoWjexVBiJ9iLlVK5JzQ2NjS4jKNBE9eSzQru3md5cFfu 0ub4_jsR5hI.74Pfy5MiHSL2tef30uHHgDDDFjGs6SHD.9EHRV.IgBoxzQrrQtSe1uYDu.9nNeZP 3odHWt2jtdKraUwKA9Am0b8wTT2InSAur3ke8Fk.NWnRWPl_1KRiLSI6fhzffZ6L_0EJ37q.g01W P2kOyyH69BFAOtP0hrkkAB3SesTa2rS2Hws9xit484KUpGdINXo7u0vuXUCMl.HJbYGi4gxkhdoT .ghKgDgON3v0dJiz8rekhP9mDbMGNcocTneVx63oPX.nO3A7edpwrMjXh79pdCsM4EsKXaqxe3.D PM.SgCvmG0woVVZcOmKRvQAyx3EsPmkHvGMpDc9GtRcgHEiXkqbvpIfiCU5dA3FQRUaiHw51EHVh BR84bIZR9aqeZ73Nju98tnTDKmFixb0q3.B6cHmXdlYyjNMFnYKSH9Qc5HBFosVAWi1uQXE7doYs qAFFmGoYvAVMz.LlDUhHMUi0RIQVCu7a4DbnzL9e_QJ5ZcMOIt3CKj6arkBl.EqKulGJr5H.eO_3 O2I_zGKlUqzB.u.aJIV9zBn_ki76NGB9Pz58HBC1t8mdhpAQtGv4EHR_y5bssgYNQ8.D3dcjamps ANzxJzv8ZDw_zbWwZ7MrRlAvMnUvG1shV4XWHuSFlDLCjvfJnwXMndhlRXfSE1njsWCiyAl5g9wN gkGr_BLvIPIsLtz7PlKJb_UpK6W2he18_VxzjC7fCOrRYj29SwYcuhFTkXQ7_kjPpKt7BPITtdlY HxPdMnhXrSW_o3jLa2ZZOubWh86idnggOAhif5Eo3dhaL2QSDchP3_9Atw8qjzaLHyUzuwP_nQAI K0ej3z1NdTuL.XYbhn2EhwXgGh4yBKVbbD6Zdd0dKZbZDfP_At2FjSrmPo0UsAUHmufCE8mnNAW8 BCOA.OnQgnNPMFqj8r8UWkFSflu_WIZ36XVPdd75C_XhaAR8At8I3MrWnlIuDPnFUR4fxwiDuhLj zZFJLTa5R0_jzOHLSneSBcCaWAbWjVwLL13T5.3fIEPXpKUvg3mxW0sP2VEHiHWVRdqx0WJNj8mb eJVjyBTAv9qCbJwcTBUDfZ8zMdZFC7B8UGA7Yu_ZFtbXQHJFrLKn0isADhQkHawFCos3IsfSzYma M1P3Pr7Kzqb8bODJpKgJpELM.2hX22ApDTgjiEuQMfpZVHAWzrzBVCvE2ohYyV5zy8qcs.Tk3uaF HcWpjaW0N9bl6rW2aZeQ1z1QJQGSpq3QK_HuIS3STRJq0.mnqf9K6RN4mojKCy18j458AZOv7AQu _O8s1x_0- X-Sonic-MF: X-Sonic-ID: ecf3e492-a398-4579-9e73-e4d1d0dbeb7a Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 May 2025 22:35:35 +0000 Received: by hermes--production-gq1-74d64bb7d7-mh87r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5cc5f9d1ddcd22853e876182380e9127; Tue, 06 May 2025 22:35:34 +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: incremental bulds from scratch with beinstall.sh From: Mark Millard In-Reply-To: <87401.1746562441@kaos.jnpr.net> Date: Tue, 6 May 2025 15:35:23 -0700 Cc: Nuno Teixeira , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <4ACBBC16-3BB6-436A-B0B1-A18F088B000E@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> <87401.1746562441@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4ZsYBc6P03z3wHW 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-Spamd-Bar: ---- On May 6, 2025, at 13:14, Simon J. Gerraty wrote: > Mark Millard wrote: >>> Of course trying to get too clever can end up being counter = productive, >>> but the tools are there... >>=20 >> I still have the addition that we found was needed >> in my experiments years ago (white space details >> below may not have been preserved): >=20 > IIRC there are a few problem locations in the build where this or > similar caused problems. I think this relates to some hierarchies = being > built with custom env - which makes it hard for src.sys.obj.mk to = always > get things right. >=20 > I think the change below or close to it has been committed and = reverted > in the past. Just as a reminder of how you got to the point of providing me that patch . . .=20 QUOTE (from old, 2023 Email) >> Perhaps you want to be using >>=20 >> .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIRPREFIX}/tmp/legacy/usr >> or is that = ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr >>=20 >=20 > I had started with trying to use MAKEOBJDIRPREFIX but it > appeared to end up with an empty expansion in something > I'd looked at, making the addition to > .MAKE.META.IGNORE_PATHS ineffective. >=20 > But with the .info lines in place, I should probably > recheck an example with ${MAKEOBJDIRPREFIX} in it. > (Expecting .MAKE.META.IGNORE_PATHS to not work but > showing what happens for the MAKEOBJDIRPREFIX use.) > This turns out to be different for "modules" vs. > "pure kernel". I start with a "modules" example > below. Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going to cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX directly, set some other variable and export that. Hmm src.sys.obj.mk plays games with MAKEOBJDIRPREFIX so that's probably not a good option. Perhaps: diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk index 3b48fc3c5514..3c7e570dbdbd 100644 --- a/share/mk/src.sys.obj.mk +++ b/share/mk/src.sys.obj.mk @@ -67,6 +67,9 @@ SB_OBJROOT?=3D ${SB}/obj/ OBJROOT?=3D ${SB_OBJROOT} .endif OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ +# save the value before we mess with it +_OBJROOT:=3D ${OBJROOT:tA} +.export _OBJROOT .if ${OBJROOT:M*/} !=3D "" OBJROOT:=3D ${OBJROOT:H:tA}/ .else and then something like? .MAKE.META.IGNORE_PATHS +=3D ${_OBJROOT}/${MACHINE}.${MACHINE_ARCH}/tmp/legacy/usr > and still not right (MAKEOBJDIRPREFIX expanded > to empty). See above END QUOTE My understanding was that, without something new like what is named _OBJROOT here, the .MAKE.META.IGNORE_PATHS usage simply would not work reliably, just like it did not work with anything I tried before you supplied the _OBJROOT definition to use. See the more cmoplete text for how it is used that I've added later below. >> # git -C /usr/main-src/ diff share/ >> diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk >> index 708559edcdb8..e710ae057fc6 100644 >> --- a/share/mk/src.sys.obj.mk >> +++ b/share/mk/src.sys.obj.mk >> @@ -66,6 +66,9 @@ SB_OBJROOT?=3D ${SB}/obj/ >> OBJROOT?=3D ${SB_OBJROOT} >> .endif >> OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ >> +# save the value before we mess with it >> +_OBJROOT:=3D ${OBJROOT:tA} >> +.export _OBJROOT >> .if ${OBJROOT:M*/} !=3D "" >> OBJROOT:=3D ${OBJROOT:H:tA}/ >> .else >>=20 >> where I had to use _OBJROOT to have 2 appropriate paths >> built. (See later below.) >>=20 >> It is still not part of the official share/mk/src.sys.obj.mk >> so I normally avoid referencing it or what would involve >> its use. But I've not checked if it has been added via some >> other place providing the definition. >>=20 >> Used via: >>=20 >> # grep -r "\<_OBJROOT\>" ~/src.configs/ >> /root/src.configs/make.conf:# _OBJROOT is an addition to = share/mk/src.sys.obj.mk >> /root/src.configs/make.conf:# +_OBJROOT:=3D ${OBJROOT:tA} >> /root/src.configs/make.conf:# +.export _OBJROOT >> /root/src.configs/make.conf:IGNORELEGACY_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr >> /root/src.configs/make.conf:IGNOREOTHER_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/usr/bin >>=20 >> It was associated with symbolic links begin involved. >=20 > Your use of _OBJROOT looks similar to how we (Juniper) use SB_OBJROOT. > We run make via a wrapper which defines SB (location of the tree) and = a > number of SB_* variables which can be assumed correct. It also = obviates > the need for make.conf >=20 > Of course our build is never used to "install" anything - we just = build > packages which are then installed, so it is much simpler. As for more detail on how _OBJROOT was used: QUOTE For reference, I'm using the below block of text for the .MAKE.META.IGNORE_PATHS adjustments now. # _OBJROOT is an addition to share/mk/src.sys.obj.mk # provided by Simon J. Gerraty for my experimentation # with this avoidance of some unnecessary build # activity in META MODE: # # OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ # +# save the value before we mess with it # +_OBJROOT:=3D ${OBJROOT:tA} # +.export _OBJROOT # # TARGET.TARGET_ARCH for amd64 stays as amd64.amd64 for obj-lib32 = (correct for the purpose) # MACHINE.MACHINE_ARCH for amd64 turns into i386.i386 for obj-lib32 = (wrong for the purpose) # IGNORELEGACY_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr IGNOREOTHER_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/usr/bin # .for ignore_legacy_tool in awk basename cap_mkdb cat chmod cmp cp = crunchgen crunchide cut date dd dirname echo egrep env expr fgrep file2c = find gencat grep gzip head hostname jot lex lb ln ls m4 make mkcsmapper mkdir mktemp mtree mv nawk patch realpath rm sed sh sort = touch tr truncate uudecode uuencode wc xargs .MAKE.META.IGNORE_PATHS+=3D = ${IGNORELEGACY_NOSYMLINKPREFIX}/sbin/${ignore_legacy_tool} .endfor # .for ignore_other_tool in ctfconvert objcopy nm .MAKE.META.IGNORE_PATHS+=3D = ${IGNOREOTHER_NOSYMLINKPREFIX}/${ignore_other_tool} .endfor # .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 6 23:07: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 4ZsYvw03BGz5vbM0 for ; Tue, 06 May 2025 23:07:56 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsYvv4cZDz3PW9; Tue, 06 May 2025 23:07:55 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 546ItmBG024072; Tue, 6 May 2025 16:07:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=l7Oc5tGG7/JXR CICrJMhbOWYSF5RjY3kYq3vagmV4GM=; b=H/dj8HVAPAtvBrD3XjE1VBcXlHv3P EJblTJTYQEHxKD/L9pKRaA8Ph2ZL9ZV/n6Q43Pp0bqwb1WsujUQcC/3VYQ9TQ1Dr VlvJxqYHJiVz3AYoLa4d2Bt8N99iI0lhaOEmQMXlGhZJXh/2V9qa20rF8EA21grE oOamZdb3tB8cSJNdXy5WpjdZZO8ITsvXIcR/IENazuVS48jTtmNvNKxNHnviT2lW 2ZlkqNVeShPO3+MNBuIuuy3a684neklYfhzFgP3qmBhF2pv+MA6zug/SHs6vTQcA 9JcpqxqUhaRQra2CcYiDWb3yEe9ZXRb3RkpYmKaEwZ5rxwAh0/f+Hz8DA== Received: from sn4pr2101cu001.outbound.protection.outlook.com (mail-southcentralusazlp17012010.outbound.protection.outlook.com [40.93.14.10]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 46en4356w2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 May 2025 16:07:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FdWc6erhtSh1fs6QURUZOn0dJegBMSPRQg/5ahIhUNgQuZv1pVoU/9yuM+qFbp0+9YpQeTA5xhgUKPpgn+Cbt4Swl+FS1S61V8Lij+lBZZTx9GfuLphJtKWrJ8HHCRoTZ3afdQpWoi5y0V1DGGENY9R7IeI91JX4bi+qSvC73Y3RXvIDlbF7AE+xFRTVVt5h9okYgWv4YuXZAoKMWL7/Z1oamkF1QA4PYZuGSUmjkw1gf7gjmjnl8+Ze6qxBYtwT5RjfaQy2UJmX4colcfB+vp4GOCt5b6WBMgpAPRetT4ifi/uL/26GzEHVj4iiYgj2QvRsQXqSvhA+RpPC7ywdvA== 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=l7Oc5tGG7/JXRCICrJMhbOWYSF5RjY3kYq3vagmV4GM=; b=cGv5y1ZJZ2rBa+V25zRR0YG/15wJwrP4HYCpFWPSpKRdRiGokdMS+EqiaDm8Pb4vaR3mG3YClHkDAngkDDFI2qokA+m7CSw6ZWs+RoeQzH1DfA64H4pKqFac1UGG227NovLU0krgrilvwOK2pUSYfNP31F5Qv0/d7aMrNfg0TxxSJSoB/bTixXyAJNRtPzd0CBX8jhmoELPTQyGN7F6a83/vu73FBlaSEa/ccylkIiIpMCdfk1oAtt33EEN+VyIQ9JHid6shDbIUVz4RAotzwtvjNuWfbNs7mHwTvRj1KXJc/Wyz8MGjnfrz/xcJt1O6GATWOmJRXfKy/EQ5fgjShw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l7Oc5tGG7/JXRCICrJMhbOWYSF5RjY3kYq3vagmV4GM=; b=BT5nn5C77aZPkcMQC4g1PmuimPduGbhP5WKDR6ytqCgsPG12kho8MvIQnEmd0dF2dQ2Hl6msv+q79diCM4we+lyHhqzRxdhNQiYIXteQixkNbmZsmz+B09ISR0yClnRaMBa4FVcDuueLj1uV6tzaen488huqXp2J8/ydao0Ng2c= Received: from SJ0PR13CA0060.namprd13.prod.outlook.com (2603:10b6:a03:2c2::35) by IA3PR05MB11040.namprd05.prod.outlook.com (2603:10b6:208:506::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.26; Tue, 6 May 2025 23:07:45 +0000 Received: from BY1PEPF0001AE1B.namprd04.prod.outlook.com (2603:10b6:a03:2c2:cafe::6b) by SJ0PR13CA0060.outlook.office365.com (2603:10b6:a03:2c2::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8722.17 via Frontend Transport; Tue, 6 May 2025 23:07:45 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by BY1PEPF0001AE1B.mail.protection.outlook.com (10.167.242.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.18 via Frontend Transport; Tue, 6 May 2025 23:07:45 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 18:07:45 -0500 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 18:07:45 -0500 Received: from kaos.jnpr.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server id 15.2.1544.14 via Frontend Transport; Tue, 6 May 2025 18:07:44 -0500 Received: by kaos.jnpr.net (Postfix, from userid 1377) id 2C72EDBAFC; Tue, 06 May 2025 16:07:12 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 2B223DBCC7; Tue, 06 May 2025 16:07:12 -0700 (PDT) To: Mark Millard CC: Nuno Teixeira , FreeBSD Current , Subject: Re: incremental bulds from scratch with beinstall.sh In-Reply-To: <4ACBBC16-3BB6-436A-B0B1-A18F088B000E@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> <87401.1746562441@kaos.jnpr.net> <4ACBBC16-3BB6-436A-B0B1-A18F088B000E@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Tue, 06 May 2025 15:35:23 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 30.1 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: <4219.1746572832.1@kaos.jnpr.net> Date: Tue, 6 May 2025 16:07:12 -0700 Message-ID: <4421.1746572832@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PEPF0001AE1B:EE_|IA3PR05MB11040:EE_ X-MS-Office365-Filtering-Correlation-Id: f9fe9a33-97e8-4d0d-de09-08dd8cf2cff1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700013; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?4yz4su74CPVwO65TmKDYdDHsti++D6KtaHMzOGvSqYu5vpCwJBRLasCwQryQ?= =?us-ascii?Q?kxkfkPE3Da17zuVrvkNZHWx3Vj6+FuXr+LY9v5pbenjhl2ICzHlO+uyOBU2t?= =?us-ascii?Q?DkeA0Kb1SrUNvpg/1AjbYEchAC5ZhcLlLaMFxQeqjQuNwNlX7IjxEs3kV/Xi?= =?us-ascii?Q?HYOKXsA3L52oryGG8egWhvursQqCpCli4LFfFwUdubTZvj7h8XWR1BmoDBn0?= =?us-ascii?Q?nrvvy2hQ0h1vS5RvsdRXjYWUJUpWS2bqOyr5eZ+YXs0aeErnrjvpL6GuxCtG?= =?us-ascii?Q?fjbpBoVYd6xZKvqwOv9sxEUYlNfUYwVpy/0H4anRUJOSVUDfoM88idrKM8Qr?= =?us-ascii?Q?jq7LY62yNUcLbIv2RWWYTwQmJNiBEfLUH0BT29AEHoRQl4ynzKLr+nhNMoHC?= =?us-ascii?Q?P/yf+PgtL532s4RZCu6SV+W/+qZh8IZWlsTvln0SKYlJabmFCExcyZBg/lNf?= =?us-ascii?Q?lSg0L3OA4axWl6U3jIUb14Ifji7dOSB1VpomE4/XOZ0rHSYJfpDtqz18F4TG?= =?us-ascii?Q?D2VOWOYRa5c1dggPnVvy9ax5OxMQBwPlnQZoTyD/7CA+kKkoNhav2Y0vu8c2?= =?us-ascii?Q?z0RyibR9dv/pCrQyFyVL/2UD16+dDDx1lOHj3a2qHmw9HdsCxXFrQXO2xOFR?= =?us-ascii?Q?NGpvIukYqCNH3CtrtSxlyUdZHCkQzAmMeBETwkilZjKHSo5P3grBH0PjkIQP?= =?us-ascii?Q?Sv6Z1DAynrzYLcF8WshCvt30adKD7N0BrK9DN3d/Zc5e3WNfFoF+jgXtyJ8K?= =?us-ascii?Q?DGcJzZm775q61Zwn0apXrX5FFbFher82jCKRhw1twsaWxwr3LzMtQph0eS/y?= =?us-ascii?Q?X1+FfAyLxPtT0q0RJd65AN/BcComJmeJj/348FzU+InAmw107gw7YxMCqM97?= =?us-ascii?Q?NUyNhu2AA2EEG3Z2IEioGYsIeGDHE9INN6f12i6ntXmG8NFoh0ohLEWA866u?= =?us-ascii?Q?Ue4qm7L36lf9FB5hLEW6+OLCUJ7Ilm+pgc+KLQTiy0Ej+VneSG8AqI2eM0Nr?= =?us-ascii?Q?tVJCQlbtlX0LOnVy4uKhV8pCV38c8xM+G3qEVTZm7ycVQM890llNFKPXq+Fm?= =?us-ascii?Q?wk2Ntqvgnp0dyjmyQCwMrHP0FgRP3hNz5cUNg9S9YhsONjn6L5dd6xjSLkNs?= =?us-ascii?Q?JAf0yIMfXT2HSuj91pWnIPQJFSgF1gmkVDnbW4O6Ru+b1FKdkZ2Q/Hg6tsoG?= =?us-ascii?Q?T4r/Z/8TTu+9yrJzW2ji2DViOrnjJ9jVuAqjotFhRC0mrcmqKtmlqTgFMRKG?= =?us-ascii?Q?uQRkgtTn0zXubB+iitsGFeVTv3pRiFypCeFfA8x1c610xSgw+hXS5584FBRh?= =?us-ascii?Q?nCDb54Qtdz1aTPjRVd3Hgs0jqvcw1o9zotDsBDC6Rt9MTpbKFuq5gXCkd/PH?= =?us-ascii?Q?BL5H6j077VCk8QsMZ1lEwD4/ezPpBOoSBpIVnS+0HLiPtwn/J1u+OsgFKw+l?= =?us-ascii?Q?HR6Fl8onzFvqnCmmB4LgrLJntdYiAB7nOgYQpOS9BN2N4LeFNILmwxpxa/ro?= =?us-ascii?Q?9MHahlFYZ+Pb7dREVQAIlUO2MVomED/7w9tK?= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2025 23:07:45.5037 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f9fe9a33-97e8-4d0d-de09-08dd8cf2cff1 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BY1PEPF0001AE1B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR05MB11040 X-Authority-Analysis: v=2.4 cv=fqDcZE4f c=1 sm=1 tr=0 ts=681a964a cx=c_pps a=5L1ZokDb34JZJib1CqSWiA==:117 a=YQU41r7WENJiSYrYYNJVsQ==:17 a=h8e1o3o8w34MuCiiGQrqVE4VwXA=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=s63m1ICgrNkA:10 a=rhJc5-LppCAA:10 a=CjxXgO3LAAAA:8 a=QILUKw8zuMfny3OUFcoA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTA2MDIxOSBTYWx0ZWRfX0HOabbFoEttm RY4si6akZfTaa4OTM3afqgkWvpRXVZ3BHGM45Rc0DnT4vIDoVDMXDdNamzeIFdhtjonr5IwY2nG 1bxMAmvrww87Rgq5LtoAE5dicFfUjZYvaTnErC9IPXF+1aF9rxPIhzxODpZWkZJwnRiWj6vvaUo d+SIXZUFDSD9Nafc/lS3jolsVuCjD4+mYjteNHZIC0oX6w7PSfUd1ID3bbE+baHqxPiZKC3Oq/6 cjX0Xa0lTyoEUXOuCpKG+aCSzGrHiRgwNmVPohlc+hl2kU48shrpCRQb+lT29cS/jjj9q0fqISC H8qy+FAE8D0Sd5XXdpUtSfuREL/ZlcoZPdHHKfYDP3Gp6cPDEBoeLbkbObnUyz/KSRAZ86oYtE9 bmg/9SvsS515rzcws3zBvHKy9xFWKghHw52ZGEAjpSqc185cGR6aMOF6YFXB9cfHxMZB4nQw X-Proofpoint-ORIG-GUID: lfsZo2mkkgJ0nf0lhhazfUvabYYPc4qp X-Proofpoint-GUID: lfsZo2mkkgJ0nf0lhhazfUvabYYPc4qp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-06_09,2025-05-06_01,2025-02-21_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 adultscore=0 clxscore=1015 mlxlogscore=762 spamscore=0 malwarescore=0 phishscore=0 bulkscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2504070000 definitions=main-2505060219 X-Rspamd-Queue-Id: 4ZsYvv4cZDz3PW9 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:26211, ipnet:208.84.65.0/24, country:US] X-Spamd-Bar: ---- Mark Millard wrote: > Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going to > cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX > directly, set some other variable and export that. > Hmm src.sys.obj.mk plays games with MAKEOBJDIRPREFIX so that's > probably not a good option. > Perhaps: > > diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk > index 3b48fc3c5514..3c7e570dbdbd 100644 > --- a/share/mk/src.sys.obj.mk > +++ b/share/mk/src.sys.obj.mk > @@ -67,6 +67,9 @@ SB_OBJROOT?= ${SB}/obj/ > OBJROOT?= ${SB_OBJROOT} > .endif > OBJROOT?= ${_default_makeobjdirprefix}${SRCTOP}/ > +# save the value before we mess with it > +_OBJROOT:= ${OBJROOT:tA} > +.export _OBJROOT > .if ${OBJROOT:M*/} != "" > OBJROOT:= ${OBJROOT:H:tA}/ > .else I think you could use something like this, which should be safe to commit: diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk index 708559edcdb8..e4fe3fa9a2aa 100644 --- a/share/mk/src.sys.obj.mk +++ b/share/mk/src.sys.obj.mk @@ -73,6 +73,12 @@ OBJROOT:= ${OBJROOT:H:tA}/${OBJROOT:T} .endif # Must export since OBJDIR will dynamically be based on it .export OBJROOT SRCTOP +# if we didn't get SB_OBJROOT from env, +# it is handy to set it now, so we can remember it +.if empty(SB_OBJROOT) +SB_OBJROOT:= ${OBJROOT} +.export SB_OBJROOT +.endif .endif .if ${MK_DIRDEPS_BUILD} == "no" You can then use ${SB_OBJROOT} in your .MAKE.META.IGNORE_PATHS The difference is that nothing in the FreeBSD build should ever touch SB_OBJROOT so it should meet your need. I think ;-) And the above won't break our builds - which set SB_OBJROOT before running make. --sjg From nobody Wed May 7 01:26:33 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 4Zsd0F0Z6Qz5vlkZ for ; Wed, 07 May 2025 01:26:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4Zsd0D4vVlz3qcH for ; Wed, 07 May 2025 01:26:52 +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=1746581210; bh=pEYL41UhCr+SToyilzjhm8IxOcOtIYoUyJsDxmfLkPY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ttgeBe/OQtFuQM2UCBFpBFKmOrmoAMS9qRAcELfbnyvYSA+OnXVKnG/YhppIaReDqwURQpB0P/TYYP+DDzcNd7xHROxl6ekDzy3EHsB4DeJ8VxmQHq6ZO4i66qduBIHy8YpF5QtvEkqJEKLoXH1MAO7n4FqDvYusIidlIYPKRrT/ulADXupJRxV7DMlQdLgvVcle88PCYbPykbc1oQcRO2HFaDWY1jfzfddkelHQIonDG9ipaQqlSs0XveR3dUTBtsIzUg6QGfVrvMMTX2KWLMcqoAU1dhD5XMCJxDYivUMGgTYvB5qdO0OW/yMrWm7zGEhEphfk2eYIoS47Glw0lg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746581210; bh=ZOLbXajVqYWUcKQC/vGeBAtwXCUjfgw0ojRe0w9zYwF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nfQykDmhhvNpDoPDZPX5IzXwIfFiwqHlnoLKNBT4tPtNibOanOrGIstng6XxMl98g5dD5DiO7yhQFIwUXMc9ULHgMYLjh7tlP4ruXm9rlitm2/dRuj84aaNFWA3kCj7/M7ylNqXJMjuzf4Mf+P4zwg7cs4wCOT91duy7nul0HdxXbOxYo/lXdhkA7qsCD8DhzuVOkyif52IkVzAYwpB4H7otTmByz2eaekye1WlZWLiB0Gq16nM7lT/rWm3KIybjLD9jJz6V/VWKM5aS2cjBqNXz5JvvatHKfJyGxb12L51CE5lg6cSgZXOjggr3TzMuOUBEs1OEi5z9dGMYPWC11g== X-YMail-OSG: LoaiaNQVM1lYq8VIzvnsy1bXQVGdnUIQ49xVrQ9Da4mrWzW5xmWdL1tLtPK92rp 1N1rDLVh43dVtKqbpYadUR57QjBBHt1U37fNsXR64tk9jrzvAitgU0mBP5ELpOfKx04COyWan0IV rSO7Z31BSJhGU7WV2VozIMO8I4VUCTzvIg54mIOQishmiPH4IvyFC7hiQGtplyzHweiknxVD_iQ3 n1OtI_W.ZzTahcLXrTbL7D041Jh5gAvrEcMfZ5kEmu223KWLCsUt9hm7HMUKlZwWQcQj377M6Bb4 NrISsANQ_i3WzqZP9UTFvaBxEkMCHjsHVUfK2..ORlQ1JDzZmAo5_eNiUAGw3M87LaNUgBOFwx2u S99l.9dePW4s_pVUIb2mO9zpVW0X4zxSTFXd4eD_.GALkOfUEftSYHuc9y3jQXgrNKUcq97ZXs0A qfmdDlSJ3.LawtQsoDBbzr.d3CJBlDhV7i.G6OYpFt8GdT8IVnHxTYChN0YWfNvNdDhjynUhT4ep qo7B5fsneLHPNp0Egvvj6Xn8z8sC9m.YFrQ1ElomRApvirecqtGq.0odgXyMtxe2ekct8CSf.ArP M7bP9zfbP98MJMre6f2D6cV88iIW.MBtMNB..SNjiUu_POE6qP6xJBASBLLOwl_M8UYWawx9qhiS a9yupZ.sYY3k0.sb6EZO4dVYpQBeVhsT1Z30l7XIZvRu07mlxvcSTlQgdtT7IFQuCX6MVVj5Yisr aBTxNZ.G7vYDqN8xa50CXnU9WUrC5Bo2tuuxbXfeBpRyzDZGwjcqPtZWenP.w6nMSmf.Zhm3y1Zt vZjIOrbZZMDbwHhmMCgWOEcZs7wNXBp1NVyKT.I4CpJWyMd2dMlU6IRBbnpBc8QNk4nYP9HvPa6T mIdiLTZsL8EUvtbZL2fGbbHd_D4yo6SfemfbWCrI4rFneiZj21O3Eso2HyABGzNufrZM0bh5IryR y3j5X2k1pSFj6fnGvL9HEb3fU1C7NDR__K1EmmGL0PDBYwRBfuDdxAg_r0Q_RKr2TG_Fo264kvKd 3DGm9u9N_47ZtQZh78L42wxpn7B9h3KlhsjMhcaTeUkARUbgr2bjoFE2aYHJyg8dbXFcY2aXKuhr 4ubSYmYGt_itFcM_FzORr.NpJALaRdM4Olryw3V5bMOp5KSxMr6MXspDGZuDxwrQNSTTuYoRkcu9 JbwVtL2QyBkyVI0RmqFwHX.kaIcDT6MwMq09vZbrx0xdwMC16BZgNCqM0z7eZQTHwC0hXdQ0avdD 0vPd9LqgLZsbwe.6IWGwM2QEb8SBBrWoz.Bd_.XxiEFcPlH.93ZyvD02xUSu6t0UDR4RQC1vPGKU sn0MD4SdO6z60W4Pk0q3yt1rvsxWz_hNIqKG.ZLZenUAg.uRnkho12HW_YRgSddBmaufbx9Pgxsh DU6UgkrQ4EjRUL_n7yYkupewY0z0XG6ljV77uAQnKCGljUqIX1dvF6g_STXgjHRmsMMJ2l9cu.gk 9Q1KT10JnozdQJQRLybF4sMGzH_Sa8Dqyln1DjP9SM4HbIF7qjoEJvEZKVKfRQ_ClCV0YBjxqq1F RPDe5pKa_Pnr8TRDPvk7WmeaNbpTUJR2ZhsQcRI0vqolxbOau28ifqomg2amU2ll1p87TpMbAifm RjMG0ZXkCSku7L2AgqoNihWllO_rybR6p_YJLWF4PgnlJCg6tDto8d8EqMg3p98vyASCxvPhCeRE yLmODemrIniSeMDgBP3utN_D4OqoYmdQdksawIym6L2etr4P5aKLULW_3gvBGuzqxmKQ0yQwoFuC bydSwwEQ3zv9nYfxd8fGvNeOdJGuaGpy2ZyvT5kD21jAjm4mEy5kJjT95LJ8CyjgS3c2Rylxaj6S jPomIjz14m9Z2otO2P6OJTBPnqBNhIXxNwwkVGhHwNOq9K4pmxHTuaDIJHBD.vBmEk4amtrhWDSZ qZ3uUAr.LHkSASQM8BiPfEkllA2HPvVHwU7IK9nQ5198iFhAC7l6R8ZeJsBaES9HCCuu69VFQU.7 AzzAQCICMo2KaAdzu65kdGFDsCz5elMxuqm7CIYmZwNiW8xw1TRGToKm8eEdPzjf7U2AnOaffRAH txn7XM3x4Pyvb3mDUaoobreb6eTdPDWr2Ae8_yM_Nup2WGPs7onEpfX0oMRGou31DC4mEKnrSa9X 48gUCxZRNDmU0aSkQ2AZBfuNr16eyoF3ttri_HTrl1bClmSb8xa.ITYd.VskiG1UkoXTYxy2vF9o bD2zhhzWUEiuqKPvOhXnL_HtrB5z2i6L5C3uyystRjFKFZy_xB9_bwp1SPlFB0bSlR_UAImK29qQ LnYOl X-Sonic-MF: X-Sonic-ID: 67406a2d-a789-4c03-9dd6-f7702af8a3ea Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 May 2025 01:26:50 +0000 Received: by hermes--production-gq1-74d64bb7d7-x7xzm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e959ac306c5e82517152b24d0857391b; Wed, 07 May 2025 01:26:44 +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: incremental bulds from scratch with beinstall.sh From: Mark Millard In-Reply-To: <4421.1746572832@kaos.jnpr.net> Date: Tue, 6 May 2025 18:26:33 -0700 Cc: Nuno Teixeira , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <2CA19E21-0F2F-465A-BE8E-81ACDEE42D23@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> <87401.1746562441@kaos.jnpr.net> <4ACBBC16-3BB6-436A-B0B1-A18F088B000E@yahoo.com> <4421.1746572832@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4Zsd0D4vVlz3qcH 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-Spamd-Bar: ---- On May 6, 2025, at 16:07, Simon J. Gerraty wrote: > Mark Millard wrote: >> Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going = to >> cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX >> directly, set some other variable and export that. >> Hmm src.sys.obj.mk plays games with MAKEOBJDIRPREFIX so that's >> probably not a good option. >> Perhaps: >>=20 >> diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk >> index 3b48fc3c5514..3c7e570dbdbd 100644 >> --- a/share/mk/src.sys.obj.mk >> +++ b/share/mk/src.sys.obj.mk >> @@ -67,6 +67,9 @@ SB_OBJROOT?=3D ${SB}/obj/ >> OBJROOT?=3D ${SB_OBJROOT} >> .endif >> OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ >> +# save the value before we mess with it >> +_OBJROOT:=3D ${OBJROOT:tA} >> +.export _OBJROOT >> .if ${OBJROOT:M*/} !=3D "" >> OBJROOT:=3D ${OBJROOT:H:tA}/ >> .else >=20 > I think you could use something like this, which should be safe to > commit: I do not have a commit bit. Should I submit a bugzilla entry or something for its eventual commit? > diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk > index 708559edcdb8..e4fe3fa9a2aa 100644 > --- a/share/mk/src.sys.obj.mk > +++ b/share/mk/src.sys.obj.mk > @@ -73,6 +73,12 @@ OBJROOT:=3D ${OBJROOT:H:tA}/${OBJROOT:T} > .endif > # Must export since OBJDIR will dynamically be based on it > .export OBJROOT SRCTOP > +# if we didn't get SB_OBJROOT from env, > +# it is handy to set it now, so we can remember it > +.if empty(SB_OBJROOT) > +SB_OBJROOT:=3D ${OBJROOT} > +.export SB_OBJROOT > +.endif > .endif > =20 > .if ${MK_DIRDEPS_BUILD} =3D=3D "no" >=20 > You can then use ${SB_OBJROOT} in your .MAKE.META.IGNORE_PATHS > The difference is that nothing in the FreeBSD build should ever touch > SB_OBJROOT so it should meet your need. > I think ;-) >=20 > And the above won't break our builds - which set SB_OBJROOT > before running make. Looks to be working for both aarch64 and amd64 with ~/src.configs/make.conf as shown below. It is used in my environment's scripts via the make command line starting with: env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" # cat ~/src.configs/make.conf # SB_OBJROOT is an addition to share/mk/src.sys.obj.mk # provided by Simon J. Gerraty for my experimentation # with this avoidance of some unnecessary build # activity in META MODE: # # # if we didn't get SB_OBJROOT from env, # # it is handy to set it now, so we can remember it # .if empty(SB_OBJROOT) # SB_OBJROOT:=3D ${OBJROOT} # .export SB_OBJROOT # .endif # # TARGET.TARGET_ARCH for amd64 stays as amd64.amd64 for obj-lib32 = (correct for the purpose) # MACHINE.MACHINE_ARCH for amd64 turns into i386.i386 for obj-lib32 = (wrong for the purpose) # IGNORELEGACY_NOSYMLINKPREFIX=3D = ${SB_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr IGNOREOTHER_NOSYMLINKPREFIX=3D = ${SB_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/usr/bin # .for ignore_legacy_tool in awk basename cap_mkdb cat chmod cmp cp = crunchgen crunchide cut date dd dirname echo egrep env expr fgrep file2c = find gencat grep gzip head hostname jot lex lb ln ls m4 make mkcsmapper = mkdir mktemp mtree mv nawk patch realpath rm sed sh sort touch tr = truncate uudecode uuencode wc xargs .MAKE.META.IGNORE_PATHS+=3D = ${IGNORELEGACY_NOSYMLINKPREFIX}/sbin/${ignore_legacy_tool} .endfor # .for ignore_other_tool in ctfconvert objcopy nm .MAKE.META.IGNORE_PATHS+=3D = ${IGNOREOTHER_NOSYMLINKPREFIX}/${ignore_other_tool} .endfor # .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed May 7 02:20: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 4ZsfBp6lfXz5vprP for ; Wed, 07 May 2025 02:21:06 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsfBp4hcNz3dnT; Wed, 07 May 2025 02:21:06 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 546Jm920020787; Tue, 6 May 2025 19:21:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-id:content-type:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=PPS1017; bh=/FUJMMqspOxkq XtGBxxuToymjk7eX5sBGltORxVPXko=; b=GPrKuBCNVIX9f0CK83WdfTc8VARYl wK8wHB1SsjuTYMHZCrmL9mEKr/e8SscBxbKLtCqU7U3BBMaJYCNbpPPv+O4lk1PK XT9YlrNe5J+B2xB0DeZ3VENljKbFdrXAQXDVmVOszwBaUv2ujs0rz3TXsT64rGxm HmlMw203F0seBlNObBsxBHVA+nzhhcL+JUlv3deXyM40oGjdBt84gRTa5QwG6Ejw X/TDNvwzAle+cBUNW2/SEspZjHe9n913zMskcf+Ogu/6JINBU3uXR/rWepEaMieo jOMf8/Gi1VAlHwMvHa2z5HGkx99nDNpUU17w6TTbIsDNVjjBba/x0ThLQ== Received: from cy4pr05cu001.outbound.protection.outlook.com (mail-westcentralusazlp17010000.outbound.protection.outlook.com [40.93.6.0]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 46frw30m0f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 May 2025 19:21:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oVUtJdHffxsq3+SPJdgkmlpI9tGAWWHktROVua3bR4sHhfvLhyJEPN7bKnv7ZUf6jBnO2Pg4EGi44a7M9+dbg9M+Mx6WNOD2cGocr4Ui6THvqGuMv3SB1ulKecx896bvDyAQu3EGQ+XG1Y1IJXWNRMrekjD8EdFPSi/IM9IDhu35ZF+J8fakKk1cq8fw5pEqNeRklIhx6Hu0xSDWd5cBpWRduM+IzypapBffh7fvRVsPN6oLJf44VUaft3LoFSpSl3p4SrfLqSLAyV62xeoo3yZKJpfT4A35obO1tz/BRviXSEYiXN5DELID2XCiu9KWWCPjcGoZMJlN3nAhxtJc6A== 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=/FUJMMqspOxkqXtGBxxuToymjk7eX5sBGltORxVPXko=; b=SOY2sgXmSAHNaRYVouA4pAXpd+rfEo1fNLxKCXx6j8hEOSJAyt9L/7cp8yCXj/tKzVkS6vm/JCQjDgGIurzGYfy9GsVIE+f9kZt7XD9On/igGsdcBPVjSbHTP+enC8pm6Ql2G/IgrjLAyMSyLUs1qvW6nCJEgSrXOcwzgk5QboRfN7KM0aRdziWDiRCQTUSovYlzfBQxq2MVKAELTtQSBxSCrlo0/r72HScLBIKE8TeGpOp5RYp1BEThP9JsRkMxzRH/qz/WOvAzGDPRGuR9i6XU9r35NZA7nOG5jVV2t5SbfEhGuMHhQxPGNr83lQ3pSEvxnlnQYqVY2EWI/ZcSbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/FUJMMqspOxkqXtGBxxuToymjk7eX5sBGltORxVPXko=; b=igdOQ0VNU4HVdKsxugWTpILw/zKiNP8iS1BH8UJ2tW8PBDvOh9v8aGLFp58tybp+NwWgKBZLG/oDzFxp9b6XcccB56WNonGRRrGeCDbioHwMI9mHxhvlHw0t4xIh7bXblGmjJ8iUvoJdlIN/bAYc4wh+IO4G6CABHUwBvqaxVK8= Received: from MW4PR04CA0108.namprd04.prod.outlook.com (2603:10b6:303:83::23) by SJ2PR05MB9660.namprd05.prod.outlook.com (2603:10b6:a03:4c4::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.23; Wed, 7 May 2025 02:21:01 +0000 Received: from SJ5PEPF000001CB.namprd05.prod.outlook.com (2603:10b6:303:83:cafe::96) by MW4PR04CA0108.outlook.office365.com (2603:10b6:303:83::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8699.30 via Frontend Transport; Wed, 7 May 2025 02:21:01 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by SJ5PEPF000001CB.mail.protection.outlook.com (10.167.242.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.18 via Frontend Transport; Wed, 7 May 2025 02:21:01 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Tue, 6 May 2025 21:21:00 -0500 Received: from kaos.jnpr.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server id 15.2.1544.14 via Frontend Transport; Tue, 6 May 2025 21:21:00 -0500 Received: by kaos.jnpr.net (Postfix, from userid 1377) id 38DD6DBC73; Tue, 06 May 2025 19:20:27 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 2BB63DBCDD; Tue, 06 May 2025 19:20:27 -0700 (PDT) To: Mark Millard CC: Nuno Teixeira , FreeBSD Current , Subject: Re: incremental bulds from scratch with beinstall.sh In-Reply-To: <2CA19E21-0F2F-465A-BE8E-81ACDEE42D23@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> <87401.1746562441@kaos.jnpr.net> <4ACBBC16-3BB6-436A-B0B1-A18F088B000E@yahoo.com> <4421.1746572832@kaos.jnpr.net> <2CA19E21-0F2F-465A-BE8E-81ACDEE42D23@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Tue, 06 May 2025 18:26:33 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.8; Emacs 30.1 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: <9091.1746584427.1@kaos.jnpr.net> Date: Tue, 6 May 2025 19:20:27 -0700 Message-ID: <10858.1746584427@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CB:EE_|SJ2PR05MB9660:EE_ X-MS-Office365-Filtering-Correlation-Id: 85d352e1-9e0a-4137-1eec-08dd8d0dcf76 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?fU3NPHWXo/g6PIiuLRmj/Z8/3yrkR+4LRzdfk4bjhqPrlSGeUicqU3OZHtJc?= =?us-ascii?Q?toJpouEUsPyMHihb6xzfXPJ+sKr4+i3SAZtyoxApw8w75BDc5FccWeSx3Why?= =?us-ascii?Q?paVE4odyEkIVXeLg23gKPbrIZGzg9HRTf3S1MDxjZjI7Zt3RtL9ME858mix3?= =?us-ascii?Q?Vjmoj+mbDIOoJJ+7tKjJAL2N+UBlDwNLwEc2qk5lq6ts46DI5DmuoJwTUEsA?= =?us-ascii?Q?4w7uDkn7RvmrVPly9QaL4gDnGe6qYUfeRe1nEv+phUfBowz2Qh2pWpIu08+H?= =?us-ascii?Q?8nI5BxdLA/LNLu0DNRbxoCG6hAI4Gv9cbF5ZN71t+4lv/wT1G3uDEQ6oiYkZ?= =?us-ascii?Q?0KUMKDbb1XojSY8aUKFgd8c9ZdzRPn+j7ZpJ5JUC6RAAFYV9AItkzWuCRJdL?= =?us-ascii?Q?dm/5DkUsbY/RRAR3Law7oy8BSksqgezzuLYkMKWvyBncovU5BfKE0UUlnCCh?= =?us-ascii?Q?H973KrTHdORytSc0xJPyK/dIRtpYGQx2QizCR/aiuswou1qPW3k3DiJOaJuM?= =?us-ascii?Q?F/0oRBDFoJO43dcimZ6bfF7ItB8ox+kttsikD4x0ls2oc7q+yekPUbY8LOH9?= =?us-ascii?Q?VxFyp4d9aji6sPSpPopInqHf+hFS13dH9gnbPByL76Ep7aN9ZMicypXG3SN+?= =?us-ascii?Q?AKbMJKB8+iRLD1cQV+j+eHuCVStxho0ewW6vjvbm07nvbqx8hdGw52etliT2?= =?us-ascii?Q?JgCMC9WUFwvaMUf1Xqd5GOX1x73asrpxIGmTZQ6ddoyZuSiadhYTTAyf3Y0X?= =?us-ascii?Q?dy6DVnnZeRCpDLPdrAldnOPe/F7q6f7E+EssEQihMIpHqCU+5e71BpA0anRx?= =?us-ascii?Q?34K26RpxWln/NwET1vt0K9r+OnESrpOFjMA4/0ELRg+VixZv/P+STd1C1HOU?= =?us-ascii?Q?NKV2HJPsvvl+bjAqn1zvwOYT+VoK55qxG3XgxtGdQCJ/8SV6IOhSda4Lwtfp?= =?us-ascii?Q?sPn6/5DDbn9N6vWG0UGbF06GSUjL5L/H6nbtZA/UapDRKImMSf/jPHuHj0jl?= =?us-ascii?Q?DMHxTjhlVVhHPDpQpinQ+Rsp8YYKBDvKpsYUqLZ2TvwmSQO9ONW5tOrU4YaZ?= =?us-ascii?Q?RHBq5TE3Gv/gT2TPqCOmqw1iJooXq56zEegJhf6uoEutHp+gHc2UZxx4zjU9?= =?us-ascii?Q?8K+ZWunJa+tDHS7RRNKO9gqsrBNz1PKJHMg+eyQqL0rej+sckMmflzbbFzwu?= =?us-ascii?Q?MHpWb/y0ithhivIAeoHTJVhW5PQT4BOE/5sXkkgs44LXrWuxlQNvCDC73JAV?= =?us-ascii?Q?AdHcluA0hyw5IGZgZxYKS3hHHOQFYjkCW05JmdiJ0PN0XpppUMeHV1Lbjef8?= =?us-ascii?Q?vIpcDfjDZCk45H3NmuIMTZ3OhtiDR6Ewh+d32lQV/RaasyF7hFP1LoHSGA68?= =?us-ascii?Q?RXlX2g+ntXGXjg9jNkdWf/1IDwzh5SY57IGkqf5vEB9j6GHTblwvU7GMT/RF?= =?us-ascii?Q?gKsY7GXLQBM1O4HXjBiGSIs+7DO4kehPtCNEwTpJ/kNZxhevDU30Bw=3D=3D?= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(13003099007);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2025 02:21:01.1018 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 85d352e1-9e0a-4137-1eec-08dd8d0dcf76 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CB.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR05MB9660 X-Authority-Analysis: v=2.4 cv=QLVoRhLL c=1 sm=1 tr=0 ts=681ac391 cx=c_pps a=GHJUnOcs406mhZkDzxAeiQ==:117 a=f/rncuQqEjTEF/G1odkJ9w==:17 a=h8e1o3o8w34MuCiiGQrqVE4VwXA=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=s63m1ICgrNkA:10 a=rhJc5-LppCAA:10 a=bFur88ftAAAA:8 a=CjxXgO3LAAAA:8 a=4yt5VpsLPrCH3va_V9EA:9 a=CjuIK1q_8ugA:10 a=jGqzw8ErhhwA:10 a=3HaaJ5jlTRvNgVQuENfk:22 X-Proofpoint-GUID: LLmzbYfzkHojrh_sF27uAOC4lo25oT3S X-Proofpoint-ORIG-GUID: LLmzbYfzkHojrh_sF27uAOC4lo25oT3S X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTA3MDAyMCBTYWx0ZWRfX38ZLH/dg31Tr Az726aXOq59T1ZiduJv52aVDI1gg5DF512083qBFz6gp3Fpg9b8njSxpyNvqIj7jekPu1gOWd3V ftsO8+zuyvjYw0DiGekOgmnJw/0lizlRTJUqPTMUwJkkgTj3PFeVwC3+RhG3/jjs3ZE8q2D5H15 rfXeOQ04NL8o3B/pqnZhVFhWWXGvr4XHLebuCxCR9PztFS4BuBPiU8sh8V/XMHXDp/P4hAuor0W Y9qWcPCFdR5fwz4cTtpw8nTryFmT4Q2UuE9Gk8qNsaYJkB7gIeoJ1ThNOs/wIiw3lsw7T3r7RmR kMXjogl7IQ6vV1qufm2/wTkxcmku2v7qGCNe/1+BSNK6nF4Qrg/gKTl6jGudWkvJ+q6dApU94VF LN6wzFX/Nhqi4v9H50kjDX48GNcjiQvwyAkr/RWTaoamIs9k5FAY3fKT633mAfHO5L701wIN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-07_01,2025-05-06_01,2025-02-21_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 adultscore=0 malwarescore=0 phishscore=0 clxscore=1015 mlxlogscore=920 suspectscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2504070000 definitions=main-2505070020 X-Rspamd-Queue-Id: 4ZsfBp4hcNz3dnT 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:22843, ipnet:67.231.152.0/24, country:US] X-Spamd-Bar: ---- Mark Millard wrote: > > I think you could use something like this, which should be safe to > > commit: > > I do not have a commit bit. Should I submit a bugzilla > entry or something for its eventual commit? That's ok. Confirm it works for you and I'll see if I can break anything with it > > > diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk > > index 708559edcdb8..e4fe3fa9a2aa 100644 > > --- a/share/mk/src.sys.obj.mk > > +++ b/share/mk/src.sys.obj.mk > > @@ -73,6 +73,12 @@ OBJROOT:= ${OBJROOT:H:tA}/${OBJROOT:T} > > .endif > > # Must export since OBJDIR will dynamically be based on it > > .export OBJROOT SRCTOP > > +# if we didn't get SB_OBJROOT from env, > > +# it is handy to set it now, so we can remember it > > +.if empty(SB_OBJROOT) > > +SB_OBJROOT:= ${OBJROOT} > > +.export SB_OBJROOT > > +.endif > > .endif > > > > .if ${MK_DIRDEPS_BUILD} == "no" > > > > You can then use ${SB_OBJROOT} in your .MAKE.META.IGNORE_PATHS > > The difference is that nothing in the FreeBSD build should ever touch > > SB_OBJROOT so it should meet your need. > > I think ;-) > > > > And the above won't break our builds - which set SB_OBJROOT > > before running make. > > Looks to be working for both aarch64 and amd64 with > ~/src.configs/make.conf as shown below. It is used > in my environment's scripts via the make command > line starting with: > > env __MAKE_CONF="/usr/home/root/src.configs/make.conf" You might be interesting in https://www.crufty.net/sjg/docs/sb-tools.htm like what you are doing but on steroids ;-) From nobody Wed May 7 06:48: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 4Zsm7Q1d9vz5vsTk; Wed, 07 May 2025 06:48:34 +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 4Zsm7Q165Gz3Cf4; Wed, 07 May 2025 06:48:34 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746600514; 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=wVNVFIF+hh/qh7VFJnLFAM7iU94fpNNEnywALiKfMr4=; b=pSc1Gv56SPAGioRa8cKSJ9REGExsjaP2q5jbFGValM1ErasPQdfjSFk27IZ2JJe0Ze3IT/ rm9+jHiMVMLbJWiDGje8UdXsFBu2et98SqogIiOFg+8N0qGx/N8m4GQ0V++ziHrDdo8wrX gTY6VthEVMD/wgXR7nPsuzC/1wmprTmkniJJsScLpbCEqRt1bjl99SSCg+s+5stvGB6uIG nss2NKGfGatAl8PwZr2eV7oI+hqTQH+OMObSOMP3tBhfLBZZ7leOv6yxdKfc5h5V5/Wpq2 6acSQQB4WZ/p7skCkLyjxVq/cPzWx1qn+l24QEOAc7YFznH16jxkMTo3PVrICA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746600514; 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=wVNVFIF+hh/qh7VFJnLFAM7iU94fpNNEnywALiKfMr4=; b=RXeSeEoQbbgIOWNG2tVbMyHzZrqMIREO1CjZMFIz1FFAjpQeu4VTWL+oLUYMvLUjmShfb4 X195gwqQFrI5uGZL3t27lr8SrLXEEfxBC4EoC2POYcBdzIrdY8h363ly0qqyg2FPLdPFNX yLXKLbMfO0Dy0bWBPAXJk6S+0DM1LTBoYAM0AaqpmBAJ0RbblBtdzOX9YYRAlN3haXCZE7 HnTzTR/u3jJ8nISzdksPIEaWBZHOf+EZC4/ntUIvTlZGHa4J63QGt5r2yj9sySIMQwI/Q9 Ruj9wnZYXrpFdmCLufZ7RPJI1m/pAN6kOIz3yZOeC/2ljy6+m2u7PvvgAGT2JQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746600514; a=rsa-sha256; cv=none; b=YldWQx0dUeZSeP5oCTg1OxXSAUZoTMDFUylcdFwwZVlZmhhmq7TlFN/wmRA2K8/LxJMovy AUUQ9vebESlKbusDREJLd0ZOTKfPMRo+7yQWpaYfGZ0wUWPfYD5MawfGfU/q1gTbev9INz ic86z2xvgtYuOLFkcS4bm8rGFCqzPEy7+IgfWV2DnibV7AKAnYbAsNwC2g3yYULN9+1YVs D0Clylw1PjBZvNPQHyEbALYtj/VMBg/RyIOIbN/CpQ21RQ0U0Uidy9ZwggN/18wYt+sptu NWHCgRtCX2i0LsvrqPDR+VGYgnM5wOEbJq+9Ocj6HEsNC+ghi5sikNYdm5kCuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4Zsm7P5LYKz1C5Z; Wed, 07 May 2025 06:48:33 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <6227419f-296e-4532-ad16-01e26a8fc4bc@FreeBSD.org> Date: Wed, 7 May 2025 08:48: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: FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@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: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello! I have polished the patch and it did get further testing. I've been asked to get one more approval from someone more knowledgeable about the IPv6 stack before being able to commit this code. It works fine and I'd like to commit it soon so it can get proper testing and avoid rotting as a patch. Since I am not src committer I'll need explicit approval to commit to the src tree. Thanks in advance! On 4/6/25 16:49, Guido Falsi wrote: > 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 > > -- Guido Falsi From nobody Wed May 7 16:59: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 4Zt1hm2SBlz5wVHL; Wed, 07 May 2025 16:59:52 +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 4Zt1hm1ZDbz3WSL; Wed, 07 May 2025 16:59:52 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746637192; 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=tJQi/REVHL9eJ4sxlVYyQftnSuzz3vpbYKGmKcafswQ=; b=G/UUXXXGYlZ4tv8AXUI38gGBhLEG4hb/ZT0m2whAQ2AVoKDQzcpEqdyxVLbMhj8ubpyFUH u6chFYxgxRN44wHxjQAkT5fVSRvTcq4ZMKbXAkRBNv4M6vW33TViqrLxwD7C1C3VqpinsM 1DINJ6HtvIz9fQLct+MEdg85Jz6lE/4qmFLNgVrswPOtTZ/GyXT64AmL5rHPqujA35KoMO VtBOjivrss/+mKJ9LWGC+p+8+r0SCTaBbCT+ku2psqE8h3Bqz1hebnkwNFQiw2o/68aqWS mQkwr64AWeaV7M9ghjd/D0S2GUw6MAGOk4eKuHNz/AB8wM6q6at9Ges6HnW7zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746637192; 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=tJQi/REVHL9eJ4sxlVYyQftnSuzz3vpbYKGmKcafswQ=; b=ZoRdDaKLFcIQpNUx4fg3f5hRO56hMzdidEy+1DsPynAWX1F8+xzfCE7q0UA2vzZTKllb7q N+4kYvX359Cd/Gt2eReFaie6tIMUaXsnhD1XnHicAWUIZ2M+zWTCu6FCDc21MaxLJS9GYc yHipgKJg6CcNKK3+6ExWdrSRLSW3gvbXIntGkWOrnhGu2NloQaakMkz5mqv6DmHKixL+wQ Go+BJlmDBDBSnZ2eEVVaq2+YOM4Hk29Wbnwx/9RjaYs+EsMkT8fgjNgxFPGWEf0fnNtQrN 6TA1a+AkuglWxqiCg6SHpjE8ccxtA3grDCV6daiT1W5HfoUtbvv0r70gSBQcZg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746637192; a=rsa-sha256; cv=none; b=vZ0kddFvobynAGaBm0sHcSb5EVyTIIUmIY0PjRwArwMJPGKYJoPLgTUijHpb0hr0UKUFID cOA98Ru/BkQxeWeQs2G0xAUmb+Z8VS/KOmjuNag6nXJ6vGkHWhLrFbNDuuoyNoIvVMo5od kuIAa18Y7GVaLhtMKhaD5P+UaUPurAHMND4gM2e7o+nTl59hhHWKeyr46jSsK1PjpLd1Dg EIMbYufTdVvWU+9OHNFn8E9CXQNvGEJIXUSaD5R9RVIIaB+21Mu2RyGs2hLMu5tmdnB3nw HopVAvFKZhd1nERW9nXfH1HpvdfKZLDcMJtwYfyKwCSHAiCtA9FtUcpYhUreFA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4Zt1hl4V8rz9jT; Wed, 07 May 2025 16:59:51 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <595294ff-4a8e-4726-b0e7-9b3e2a50d866@FreeBSD.org> Date: Wed, 7 May 2025 18:59:49 +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> <0a6709f8-275c-4c18-b195-1333a44fd1a7@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: <0a6709f8-275c-4c18-b195-1333a44fd1a7@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/9/25 13:19, Guido Falsi wrote: > 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. > A small addition here: I have already taken a look, since the RFC provides for part of the algorithm to be configurable I have some code I'm testing (which I plan to submit after the present code is committed) to add a sysctl to choose what to use for hashing between interface ID, interface name and interface MAC (if that's something the interface has, while ethernet like interfaces are most common today, the world, as you all know, is not all ethernet). I plan to leave the default at the interface name though. -- Guido Falsi From nobody Wed May 7 23:46: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 4ZtBkd2Hdnz5vTbx for ; Wed, 07 May 2025 23:47:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 4ZtBkb6B8Qz3lp5 for ; Wed, 07 May 2025 23:47:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=oMcMRXVL; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102c) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-30a509649e3so373499a91.2 for ; Wed, 07 May 2025 16:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1746661621; x=1747266421; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=pVdJo3ndReV4/T04UMdgt4tNac27cOnpBEe1Suc57Vs=; b=oMcMRXVLerIPQdJrXRJ8qrDEwFXQZaMbeazMHJ+4zksnLTtPYn9qQq8CSGOCrCzYhG PSzZTxaeVbAEzQRrQRDI6HXrWFu5ExsyFFX93WHYvSvVl0nmOtlr1R0RK0BmE90XP7iX 6tVcFHpt4Xgs0VrADtkUsun1Yx5Uw+yYHQ8VfrtaXhaR3rjJqz+M4ti6yXT/F7AbgP2P pj4Pelq0AqCRlpWnEWO4hitzzDaMbsIdT/eJbUMhLxRlZGud5WhOSijWbVMW7grqr1uv 3gqSjNsEPH+ZaMhxmjBckc50n2isaQUJXTD9fHPnQ9OC9CAP8QPn990CzjCOtAJyNLsk b/9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746661621; x=1747266421; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pVdJo3ndReV4/T04UMdgt4tNac27cOnpBEe1Suc57Vs=; b=DDw80yIrrJnFpsiu/xGKe7v1ddbDNnrBf2/6hJU7AHDX82SwFNhTphN1SVO1DueoSq bOxvs7D4M1LXgBDPMkJvQNApJJwTSfU3SLo2xdYZvrnLjJa0zbKktvBaB6eAdQv6bSaq 21NmxN/CW5eS92SgdDKsD6jaWbSky2dMFLD+wcmBJOKrNcMj36kexCVJCIrLCrSCtSS/ P+KmoMY52eThAfEmQDNdbLSgVfUDN9lnHkntl0bkpCEYD2jPABrAq8tNtbyFb8CxIEWp 9eilT4pdin25AUyZ2afGw/NTKC6axtq7gf9KDJrn/1nWOYD9yl48IxL7iewL38dAj/MY VmWw== X-Gm-Message-State: AOJu0Yz1wOMvCwd3MzmwMNQsay3BnJuGKo38ZhwQ5pSZjjTSUGDliRGZ 5dIwGgEYHgWovFkpVcUWAcUyPXoKpLynFR1NsvK/nXw/E0qx5pTNvEj20O+Lg3Ipv7J7zW2S8u6 Bo9/S6hCnEOmyWGwHzl9hf/ncSMftsbkNLtdi4aWTZfSrIS0F X-Gm-Gg: ASbGncsDSwtZoJ7Hihbso+gqrq/UzWeCXdp8bA1OiSzJk0NlMt5hRNkl3NAY4ETEufP 69gkgXkfqWI4QPVzGXQeQ9r1o+FQg0w2FPMgfHblY93Ff61yhHZ/4cws5bCx1EuW2obTB4afp7/ tgOCyAo/ox7yNSLJNdtdl3qA== X-Google-Smtp-Source: AGHT+IEo6lhGzmX4RqD2GN8Pr+lr/4MbxJ7fxpzzOplmckt0Xg5HtUz3zCjE6l/w30R3j0Zv7idPwEAcyb8bbcy6Ulc= X-Received: by 2002:a17:90b:1d43:b0:2ee:edae:780 with SMTP id 98e67ed59e1d1-30aac1b4086mr8733325a91.15.1746661621278; Wed, 07 May 2025 16:47:01 -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 From: Warner Losh Date: Wed, 7 May 2025 17:46:50 -0600 X-Gm-Features: ATxdqUEHSH8FJ6JTfH9zaifnZMLorvgft0wCgIsZADp944T4nTisD-9lck0DgB0 Message-ID: Subject: Heads up: umass / CAM changes To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4ZtBkb6B8Qz3lp5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.31 / 15.00]; NEURAL_HAM_SHORT(-0.96)[-0.964]; NEURAL_HAM_MEDIUM(-0.74)[-0.741]; NEURAL_HAM_LONG(-0.60)[-0.601]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] Greetings, I just pushed some changes that I've had cooking in my tree for months. The first group of them improves umass code in various ways. The next group stops the USB stack from probing for 'quirks' and changes them all to either be auto probing, or in the case of SYNCHRONIZE CACHE, only send it if mode page 8 (cache control) is present. This works on the 50 Flash thumb drives, 20 hard disk adapters and 10 SD/CF/etc USB adapters. And in some cases, it's a lot faster since there's no reset that's needed. It also removes several overly wide quirks that could cause problems with devices that do support SYNCHRONIZE CACHE and write caches, but were made by a company that made other devices that didn't support it.. So, I'm pretty sure this will be a big nop. But if not, please let me know. Warner From nobody Thu May 8 03:31:59 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 4ZtHkF66Vbz5vkdX; Thu, 08 May 2025 03:32:05 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 4ZtHkD1Pbtz3t3H; Thu, 08 May 2025 03:32:04 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="dcs/8FNS"; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::430 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3a0bd7f4cd5so48342f8f.0; Wed, 07 May 2025 20:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746675121; x=1747279921; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=dcBt5mUnpGGlFzLPW/SLYHctOubkN5Ux2fns20ei12Q=; b=dcs/8FNSLp5ASVY9gnoQMTyu3KF133vOlEdS87uU1yHgZyB59GGS4t/hVx13vxfCq0 tgnQr+7Zg1N/joKnO7IqUTyfjG+r4DoecLPkJysd0gfUYr8oqmo//lvt1di7u0qngtM3 ZWg580N9bKE2rgaIC42sqAUmDW8CoX1c2P89KjiZuBX6v6lhCvrlxTJVMvu3ALXet9/v Mf+SI6Tx5KQ5ymY9dmoN4GTh/xYU31L3eCxAb6S4sV2T7JVzYGOt5Kdy6Y/dINztYqcN M/HSxTK1/SEcj0Y2X85IHz+Y/SaRZzOicRTizddyrwve+41mhcrJvO+ajmz527+aY/l4 u30Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746675121; x=1747279921; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dcBt5mUnpGGlFzLPW/SLYHctOubkN5Ux2fns20ei12Q=; b=LeXuGysfZIMFlepLKn+SM3LJht39zDT7qyivQmzZbFddh4XozponwWAS+Q8yTXPgQz cD3ITwB8hx+Wk6VkZghUT47a1gZBa0jQ93HMsF0Qp1Ozbjup+VkpLhkqMKac8CH4kD8T U2O8Kb0lFrYt5nsL2WUibJb9MmyBWX7Yik8xMJr28Dj66llrWLpBvC25AW9uet9uujIY jzZbnbbswl79DFNil60gaAXl1zPxZM/3csqqOdB1fwJ5K7jyfZ5jQRrnift3nslK1PqN Tval5RQesaggNmo8jZ5tM5GdnKy2RloPc4ibGCOXl62AZFmthGnlD5cfInenvZ07OioQ p3jg== X-Gm-Message-State: AOJu0Yw4GDzgvI4lGi4lMEHc3sCBBqrRvbD5bJxfotjHuarA2xYu9URD yrlcDTOhbstPGzvEoZrYM+/6dYTxJXLqOizZl3xCUsGmTVktBKpRuHjY0Q== X-Gm-Gg: ASbGncs7DMnDI8zB1mnLJUZ30Ec+Q5BqSUz97zKDE36vLwY8M9mJLDmvM3nvxJS1S8f 2/Hw/fN2fY23v5/eOgqk3EdNVcq0ee8N8U0ZAzPSwgsolmlGEUDVLqI7730fqoXGxnbJt5x+lI/ lZ5eZFpaCiDuiacsynfvdGfKAJly/v5C4x/AOemWH0BBY6+WY1L6CKQeaU57HvaASOEbq+dpK8p cIUfH3jt2bqjUeHKfNIpYwRw7NCfmY0QahZ3irSqw/wRFVSpvHgbKuUZTYJkZ9jI+K+WKoKNv8p /D7kM7ExbOCtKo4JVPwNOwcAaSYxE6TRF3EdavlkJFj2GvVxnvjAWUQ+MS4sIgZqjn1dW1EtECR loi7TasJx X-Google-Smtp-Source: AGHT+IGF6R7pa24sz7e9JJSCwkB6x9gqXu0ml78swmF/3jQRzfMdsBh27rGEtraAGJ9RsyQzF8XYBA== X-Received: by 2002:a05:6000:4020:b0:3a0:bb8e:4ef4 with SMTP id ffacd0b85a97d-3a0bb8e5066mr587168f8f.31.1746675120360; Wed, 07 May 2025 20:32:00 -0700 (PDT) Received: from [192.168.1.10] (host-83-67-212-99.as13285.net. [83.67.212.99]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a099ae3ccdsm18940805f8f.38.2025.05.07.20.31.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 May 2025 20:31:59 -0700 (PDT) Message-ID: <688e37e4-3d6d-4e5d-ad47-9d1156d50330@gmail.com> Date: Thu, 8 May 2025 04:31:59 +0100 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: Installer, before exit: /bin/tcsh for pkg (was: CFT: pkgbase support in 15.0) To: freebsd-current@freebsd.org References: <86a57t3cfu.fsf@asn.ftfl.ca> Content-Language: en-GB Cc: freebsd-pkgbase@freebsd.org From: Graham Perrin Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJimMMBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQLbHAQAJi998y42bEbq5HmABYovmAEtQj33YSUWyc9QRmAHpN8Er3lTKsgmZcVChB5Fu/d go2oYynDjlVpA7+wiSmg4AG78mOYbg/e19XMhrH0keDKqZXFkU+G7agR0mF09qvpQZ9MTJYZ 2u7FtytZK665UfipOdV8eGn2hFC/WynjUwEzKyryBgbbLAEbfOPeZNry4h2ZPWbtTvx/PE/V X3Vh2oGqYx69DCGz+0xEhy62ZKbkX5SL8LUf/1WViyCVzsHasFxmFxYPWIfBy8ayQ7xapz7M cSXSQyu4oDT4qh9eZiGP9/aAcZKHcV6t9y77JGhUJ/5O1sANKMa3YhgimE+Z86LHYa1IH774 PHj1nAXBwS+Cj/1l/NQoQcyjvOj8zuCsMJVaLMb6B46YsReP4+3yBLpyeBC//t6zWPbgAkWW VjROC0dXUAMTFpnA6NZe3UghG+Nc4fnCLGOhc2nyWFYHIaYV6Hv1ITFSem9DdeNnR1CFm1VM TJ7i7TuqYM+WZTkoUsTf4c46hS/ZNJZSCxh0s9yYr+BYk3XBbd+ElaZ1dJE6cuSVdw15+P2h DnprurxC4byl4YFkn+UAVvQsOgeq6aSHLOHX0weYu1OLoiPYsTdyGhne72+kDhEEdFD5aHdQ PFrbQIrqWLV0a04++0ZwGpNvXtgnWhDdAQJDwGsSSwbLzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmKYt7ACGwwFCQWjmoAACgkQt2dIb0oY1Av7qg//YjCZg8VXyMzXssgIQpROKKqh5V0UBSQl rM3tq4tWhyg0HVMugQj0Om+iNPsEEOGHkm6tyhHMzlKGpAc/l0iAM+8twIyg44Yo5+DcfFXr OMTbTw9T9jDsWOkOBksxy29iYhgpqpWdDBnhXvrJp/FNAiX8CfzrIOZeFPydDoEiKBEXAxfe a9o5J/JeVnZiUeoiFe7i68nZGsb4JxhPczNfqW12t0Ll5/ibjszg5BgjXiLao0KqbWNh4bS5 CVwH90Or+5qqWgzWPeBiuz+rN2QXE/V/fL44GEj1YKASCqmaiYRgjoRFubz1aq1wCXMXY3Iq d4525rscUgS7HBxbblnyTodUPaamN/2nSzcmE/Pkx8MApDSgZCIhs0RTAg+/AoX4HULV1rSE TQwMrBEQt84Tw5W5rHsvXKr4ZEsJUpbPLWYTISsp23nHR+vZtL/Ug+OWCmHC7X7D21xk/xVJ 4sA1RLJBKdCHtnyA4Unv/kNS1KVGxHnITVyw1a71QJADu4qsdtM5u6CyYUhqhM1oseWtV6j+ Qi8KC/G4C3AgZf06fe2fVl42z2grTabL4bC6FQXMwTX2dsm5NakWjUCmUL8uwsQE7ZA4zKxo EYI1YV9q1birpzncYRupr1qnMoggMUHWq0IBYshFQrEO8PeVUZBw7/GfAeh3argdw2Qu748T Cyw= In-Reply-To: <86a57t3cfu.fsf@asn.ftfl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4ZtHkD1Pbtz3t3H X-Spamd-Bar: / X-Spamd-Result: default: False [-0.12 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.996]; NEURAL_HAM_SHORT(-0.95)[-0.954]; NEURAL_SPAM_MEDIUM(0.83)[0.835]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FREEFALL_USER(0.00)[grahamperrin]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::430:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkgbase@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_HAS_DN(0.00)[] Re: has two screenshots that compare the 14.2-RELEASE experience (good) with the 15.0-CURRENT experience. It seems that /bin/tcsh no longer works around the issue that affects the print/indexinfo package with /bin/sh. Is this a regression, or am I missing something? TIA From nobody Thu May 8 14:32:59 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 4ZtZNv1n0cz5v93Y for ; Thu, 08 May 2025 14:33:03 +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 4ZtZNs4y4Rz3MyJ for ; Thu, 08 May 2025 14:33:01 +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=J88cYV+z; 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; dmarc=pass (policy=reject) header.from=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=1746714780; bh=rbqVyqqj3JCT6s82206uAr0CXPce3YCno4q6xu+SZn8=; h=Date:From:To:Subject:In-Reply-To:References; b=J88cYV+z/+aQuusfzB0IhIsDwNlDJk4jgmH5Tx/uVDbvDzpyN7lbFeJpv+W3GPnWE SVOnHdhdnLzmPcIN5yHByrxKNNwkZBnePGXRhGDCCKxY3UETZwqprrZ1HLQlT6gp19 zLiV7Zqj9xC1R3WR+Atqp+95v9gMHFqeWpqCigNR2/K2P8NMfnkQ7zRhTLXH2mpJI8 esM2em7CthsoJA9vFeBHBlW9w+iMJ0YEIQ9S1VpQHjATqfK+r3d1i7V6315zgoh3JN Dfsa8EY82xLVz/pWJ3l5bTkyTHLwYmDHbPcncRG6/+WX19uTNMqdPRuNxuafJRWwd2 0IxL9bZDB2Mp5CQvyYeBWS8O7LSgkbBKhq0+bya/b58m7r8GS4RZyRNKis7xbWfSVW tX2gpR2FGxF8bT0xNEy3zb6hLjv9XZRIzK/MAe7LgoI36EYJt8IrpoQ/g9RtDwK4pS BlbdLXMV00RTpKgaWd3d3mE3xpQmCvRt5Q6KDB0lzeokP3JU9XkquSexdy4Uqskc4Y biCaTfTKgOiUEn8MaAbmUovlNBEoWX9/9xuqohHg0U/QHG0Tow9pwdyPyWCAQCJYYE S9zWW9djDbQ+92j/0FRXf9BDXvoQ9fCcUJqcdtPxsYc2fwvJGoOSEDXfE15OhmU76o yyRQxp6/8QJ+h38/sA/BbEXE= 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 668D0598A53 for ; Thu, 08 May 2025 17:33:00 +0300 (EEST) Date: Thu, 08 May 2025 17:32:59 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? User-Agent: K-9 Mail for Android In-Reply-To: References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> Message-ID: <6AD60E0A-DF30-486E-8E6B-2393FF54CD0C@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-Rspamd-Queue-Id: 4ZtZNs4y4Rz3MyJ X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.85 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_MEDIUM(0.98)[0.984]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_SHORT(-0.33)[-0.331]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56:c]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] On April 26, 2025 4:06:16 PM GMT+03:00, void wrote: >On Sat, Apr 26, 2025 at 03:01:01PM +0300, Sulev-Madis Silber wrote: >>=20 >> that might be it!? there is hdd on machine that was tested but now neve= r really likes to complete the long smart tests, and short take ages=2E the= re are no "usual" disk errors, tho=2E that hdd is part of 2 disk mirror tha= t the git runs on > >These are exactly the symptoms that led me to junk 2x HDs=2E One was CMR = the other SMR=2E Smart tests failing to execute normally is a sure sign it'= s hardware=2E that's how i lost bunch of recent data=2E no recent backups=2E old single = disk pool=2E it took so much time for me to add mirror=2E that hdd failed= =2E i have to give it to recovery company=2E they agreed maybe it's head=2E= it corrupted data according to zfs, and smart data=2E finally after copyin= g half a disk off, it went bust=2E clicks=2E this is mirrored and backupped= system now=2E extensively stress tested but those are second hand 160g one= s that i apparently just have used up their remaining life i guess > >> i'm wondering why noone else spots it much, tho?=20 > >maybe they do but in the end attribute it to hardware > >> and this is not fixed on current either? and fix is in zfs? and ufs, as= tested by others, would not be affected=2E=2E=2E why?=20 > >I've also seen the same thing happen in a microSD and a USB2/3 context, >both were UFS2 not ZFS=2E > >> tl;dr - suspected issue of zfs on slow device filling up *entire* ram w= ith write buffers, leaving userland killed and system in unusable state > >Going by what you've described here, I'd say the problem is down to hardw= are=2E just hw eh? remember, this is not first user who reports it=2E i bet they = all didn't have bust hw i bet slow or intermittent io is just cause=2E i also have apperant too hi= gh frags here=2E i let pool fill to 100% by accident=2E now it's 51% cap an= d 65% frag=2E i know it's just free space but cow fs makes this slow i gues= s but why does it fill up the ram? is there a tunable at least? or why doesn= 't it autotune=2E arc iirc tunes to 0=2E6*ram or 1g max=2E this goes past t= hose limits=2E either write cache has own too large limit=2E or i don't kno= w i mean, there might be legit reason or small hiccup=2E in real or virtual = systems=2E local or remote storage=2E in expected situations io just slows = down or stalls=2E here it seems like zfs accepts everything in hope it be a= ble to write it down in a moment=2E but what if it can't? i still look for a way to defuse this perfect storm situation=2E hw just m= akes the problem appear=2E it should reduce throughput or just stall the io= up=2E kernel is full of all kinds of limits which work=2E i want this to w= ork too=2E even if changing defaults would be bad, maybe there is proper va= lue of some tunable that works for me? altho i still find it highly unlikel= y that zfs should take past 90% of any ram size or that combined kernel mem= ory should go 100%=2E this should never happen iirc smr disks did something what i observe where write speed falls after = x time (small cmr + big smr)=2E and those shdd's (small flash + big magneti= c) i think it's annoying and bad surprise that any kind of io issue can bring= everything just down if there's no tunable for this, maybe it should be added? where i can say = to kernel, just don't do this=2E do not go there=2E do not let memory usage= go so far=2E whether it's pre-fs, fs or post-fs buffer of some kind=2E it = can't like keep filling up i also wonder if ton of ram even helps=2E i wish i could test it somehow t= oo because i'm curious also, if disk acts up like this, could zfs be improved to to detect it? be= cause currently it doesn't do anything in any ways, this keeps confusing people forever=2E i could fix this with = hdd replacement=2E someone else finds it again From nobody Thu May 8 20: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 4ZtkmD5YjTz5vbvF for ; Thu, 08 May 2025 20:50:20 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 4ZtkmC2D4Sz49Qf; Thu, 08 May 2025 20:50:19 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Imk+6137; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=kob6558@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-e740a09eb00so1482317276.0; Thu, 08 May 2025 13:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746737417; x=1747342217; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=B+kZi4d0HeeZNosGA1hp+MJrwj9F3RLLOT5JMqN7MXY=; b=Imk+6137P1ex3CQiC5muyPWEsLhDQiI3FTqvT8+LWJ27HxQ2caObRLtypXbYHPFgnO MKWUbzmql8VZ5+K6hFbngC82QqbeRMNhLTc5ceLNbFmWeaoszZgQsMWXOujwpKA5OJ8u HHq1IXNY1XRfB0kyAMH0J+V/6uOuHio3oUm8jJ4EkKrlhbsJMmbdyvSdtAzxXGnHWBy+ 1glgEAOZzH/+8DZ/uFk4O1n5Zk8kfn1XJFGPUl1ujjMCEdKWCKV6AY5ViKg2m8jQKYAp nDuOCB0zqf7vpSyRHhIWLSfD4Yc9V1fyyQsX1+OGmdRceXyXQ0ZF1dLipIatuxdnOIuu 3P9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746737417; x=1747342217; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=B+kZi4d0HeeZNosGA1hp+MJrwj9F3RLLOT5JMqN7MXY=; b=kQWEwSz5HJQv9e6oydfO6jdcftwWYomgatFe4vXo2MmxiDr4NRl7pQG2HjLsOA1r9c 95KOQT8OsS6tO0d79UQ/K0dvSrYWiURQtIXf/9dvOhWGGc10puxzOEqfiy4iILQoSYOm fm05Z+++0RJIl0RIoAhRW5BV+vlqZ3y0a4CEdZzgqTx70nWQsRs2tOY+lsN9kPpow+u4 VRVauunRiIQe8+nGy+l58vESDuxGkFamhQydYjWRbBl1LORNz2iwzFw86MqxX4+XdALp LIw7Sm6r0+5bKRPAyHS3d2MC9MPFOg/vrREPXmIgoVsninKYqtlQYU+20O6Wr1doX3RV dCaQ== X-Forwarded-Encrypted: i=1; AJvYcCWVe4eDwtPaUWnjpZyy0lBmwH+Svwd6xyyKwpsy4cCaeu9kBYkh+iZzIKKD/b1DtjKIgDJ7@freebsd.org X-Gm-Message-State: AOJu0YwhULBi+Q2NNRkjL+LRidKg54vKhW4qcobMHgl8PI6VzTQiqXI6 dbZQxph6bc8rUWHVKA1pES+wEcVpu9NNVuML6ddOwK+pl2a4oNezrNE7N8HdfFxFEpzRXqREGaC 52807uUAqP5RzpnNyxuW5AjGbp2yIneIr X-Gm-Gg: ASbGncvFmNjOZ5Gj6sGhk/aX5HJIFX2qHonEYJFidzNwGXXF69do3JLDfz3DZddyun0 EPdk/UUGJjc67i7M/QyY+LjV1OeSX94VMGC12QIDvLsh+n2iH5nOacdNDcB1Ij+1MZxUm5qvKMs Ogt96ae6dcuVM3m8OR8hRl8Q== X-Google-Smtp-Source: AGHT+IFgVeb8q8uTNFNlMYgo6/NYzG0bqXxahyKD1/SNgXen6Sx677XAoDR+oJhlWXX5JDpRdLHJ4JaiHKIse5SytXw= X-Received: by 2002:a05:6902:1b13:b0:e72:b64c:b1fe with SMTP id 3f1490d57ef6-e78fdd645e3mr1180240276.47.1746737417506; Thu, 08 May 2025 13:50:17 -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 From: Kevin Oberman Date: Thu, 8 May 2025 13:50:01 -0700 X-Gm-Features: ATxdqUE1h382n_RcE6-W4abfi1B4K28jfcGZaa3DGRVSf_hlQJ0Jw0rxQZQbM30 Message-ID: Subject: geli patch to /sys/geom/geom_kern.c b/sys/geom/geom_kern.c broke geli attach To: FreeBSD Current , Olivier Certner Content-Type: multipart/alternative; boundary="00000000000049593d0634a5ff97" X-Rspamd-Queue-Id: 4ZtkmC2D4Sz49Qf X-Spamd-Bar: / X-Spamd-Result: default: False [-0.07 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_MEDIUM(-0.86)[-0.864]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_SHORT(0.49)[0.494]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b34:from] --00000000000049593d0634a5ff97 Content-Type: text/plain; charset="UTF-8" The commit of 713abc9880aabe0ff924ff644bceb6ff404ed3cd broke the attachment of encrypted partitions on main. # geli attach -d -k KEYFILE /dev/gpt/aux Enter passphrase: geli: Class not found: "ELI" geli: There was an error with at least one provider. Rolling back the patch fixed the issue. I have opened a bug report, 286677 for the issue. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --00000000000049593d0634a5ff97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The commit of

713abc9880aabe0ff924ff644= bceb6ff404ed3cd
broke the attachment of encrypted partitions on main= .
# gel=
i attach -d -k KEYFILE /dev/gpt/aux
Enter passphrase:
geli: Class not found: "ELI"
geli: There was an error with at least one provider.

Rolling back = the patch fixed the issue.

I have opened a bug report, 286677 for th= e issue.
--
Kevin Oberman, Part time kid herder and = retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D0= 3FB98AFA78E3B78C1694B318AB39EF1B055683
<= /div>
--00000000000049593d0634a5ff97-- From nobody Thu May 8 21:09: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 4ZtlBW1lGYz5vccg; Thu, 08 May 2025 21:09:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (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 4ZtlBV156pz3Cb0; Thu, 08 May 2025 21:09:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-f178.google.com with SMTP id e9e14a558f8ab-3d96836c1bcso4829435ab.3; Thu, 08 May 2025 14:09:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746738577; x=1747343377; 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=qmxhbyimfkDtR8lMcu498RDtLBAFPNJKK09QP+ZXy64=; b=OFAEI8NaM2dv8vMrY89rU15nqiVUs+OMqoWWQYn6YS2chw3yCkqXc78IvcUOY4Vwv0 Wqo/SxUl7y8W+x3jwpeuASefkCweRMQQpUXoI2+KXt1paO9xKX1ymZ1yDAKCHa1Uzplp T5i2zQBkkan5CjDQ8TDHv/p0iuwwJ4xgI13Ast2smjtabbTNP3Dewx5MoNN+wHDyCY/a 7+lnJhLqTwmouRlSrfwp6NK8OMWtHgcMQQbf+yvjyNie6WEPYJmVokoWRw7Gyr/NqWBS yfX5b+dBbqcyK5N9EFFTI8j1Qy8JpqSA9w1kmlV/tZZB0GV+WAY1My8nlH1cR2k8XaEA bPSA== X-Forwarded-Encrypted: i=1; AJvYcCUAahEOguv61T97CRGNawgU+XWcLL2L6ERo3tuid+IVi+0/E3srf0npJWNw+Hw2ocvMXJpfI2VoPhdajjMG2cg=@freebsd.org X-Gm-Message-State: AOJu0YwXUcGXXvi04BMFSoWDhF4KDSgHLFpm1o6gW3wQgso/1YuXecZG UsOqLvpnMK9lDXA4AUSPH0536ZKME0dvhn9Drzi2ZUS22nQaYwRRPaoDT9XiBWPYyvHY10ZpmVr S90RjmvyJyO0flkpPheeC+okKm9Y= X-Gm-Gg: ASbGncuIU7oT08UT8h/tLFks4w0SVBdX5IVKRYLnhd7t0+UmAgdoBAF0prDGsdbwnbB gDRCql8IVpNswW4FACy7gkT53btFR7iY/c33ds/BaNg+AyaZ5Rk3FTJZWUqjpCT7W7ajKyTXsmM qis45pQBe3YQgteUvnN77Z3Od/4Ygb53kym5Tt8e3OuCbQsX3i2h39SFM2OPmkdpEbIps= X-Google-Smtp-Source: AGHT+IH/vM6WsjMR8Xi/z0Qi0mCYJcEDT+j6Wm1L5Or9SnO0ySMvJ2amTLOkfhjTvDCwNWV8CirfMtmqHQGoh1r2L2E= X-Received: by 2002:a05:6e02:2611:b0:3da:715a:dde4 with SMTP id e9e14a558f8ab-3da7e1e77f5mr13241505ab.9.1746738576795; Thu, 08 May 2025 14:09:36 -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: <86a57t3cfu.fsf@asn.ftfl.ca> <688e37e4-3d6d-4e5d-ad47-9d1156d50330@gmail.com> In-Reply-To: <688e37e4-3d6d-4e5d-ad47-9d1156d50330@gmail.com> From: Ed Maste Date: Thu, 8 May 2025 17:09:25 -0400 X-Gm-Features: ATxdqUFFuNh7B5d-28M61j1MtcIMlLacgTWtT9dKZ2jkyeR23RiTxsE1UgOaQZ4 Message-ID: Subject: Re: Installer, before exit: /bin/tcsh for pkg (was: CFT: pkgbase support in 15.0) To: Graham Perrin Cc: freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4ZtlBV156pz3Cb0 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-Spamd-Bar: ---- On Wed, 7 May 2025 at 23:32, Graham Perrin wrote: > > Re: > > > has > two screenshots that compare the 14.2-RELEASE experience (good) with the > 15.0-CURRENT experience. > > It seems that /bin/tcsh no longer works around the issue that affects > the print/indexinfo package with /bin/sh. It looks like nano's post-install/-deinstall requires print/indexinfo and it's not available. This doesn't appear to be directly related to /bin/sh, /bin/tcsh, or pkgbase. If you have concise reproduction steps, please submit a PR. From nobody Fri May 9 12:47: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 4Zv8131yW7z5vf3N for ; Fri, 09 May 2025 12:47:51 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zv8103fVpz3Gmf for ; Fri, 09 May 2025 12:47:48 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=kzqPS+Uq; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 549ClcIN079078 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 9 May 2025 14:47:38 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1746794859; bh=7aaKnDD3olvtYlBw4OxxiAp0cTWAd3ZEvrpS8yQpnEE=; h=Date:Subject:To:References:From:In-Reply-To; b=kzqPS+UqIeIAi5QuOZm0wWbmqoQ6iZadZOodbZQP/Ta23Et+HJk/vBFUuOEL2RNgz LfMago+HZBGsHNyeep2EouCD3CSIVHsywrksLAxFyvc6M8c3qzk7aayx1KPL4oA5Zy eXX+m5oxsmwwT6d+i6WyqB7qz1ZBT+g4uW2mOmDcgdiFpJO//WfA0ktoKEyfxP/Nsy HCXEmQFwc8dXLnHlR+Y2UzEvV2pDPEd3yUe1Je1vIWge/ONWEv58WZa/3U57Ds1Utn HnB5/YzGA8j7qeNXxmnGeQTlgbiBXIt8LmetlNwh5CHh/zRSJDP2y5qemi4sETVv6o FriPK9aynmX2w== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: Date: Fri, 9 May 2025 14:47:38 +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: FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <6227419f-296e-4532-ad16-01e26a8fc4bc@FreeBSD.org> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <6227419f-296e-4532-ad16-01e26a8fc4bc@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Zv8103fVpz3Gmf X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.03 / 15.00]; DWL_DNSWL_MED(-2.00)[pwste.edu.pl:dkim]; NEURAL_SPAM_SHORT(0.95)[0.946]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,quarantine]; NEURAL_HAM_MEDIUM(-0.39)[-0.395]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; ONCE_RECEIVED(0.20)[]; RCVD_IN_DNSWL_MED(-0.20)[2001:678:618::40:from]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.08)[-0.085]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[] W dniu 7.05.2025 o 08:48, Guido Falsi pisze: > Hello! > > I have polished the patch and it did get further testing. > > I've been asked to get one more approval from someone more > knowledgeable about the IPv6 stack before being able to commit this code. > > It works fine and I'd like to commit it soon so it can get proper > testing and avoid rotting as a patch. > > Since I am not src committer I'll need explicit approval to commit to > the src tree. > > > Thanks in advance! Thank you for working on this implementation. It looks like complete and ready to ship, but I am only FreeBSD user, so I can't support you much. There is probably concern if your contribution breaks something for the user XY running XXX year old code someone will have to fix it. This fear prevents pushing things further. That's the tradeoff. Please let me note that we are still in pair with NetBSD and DFflyBSD - the cherished implementation from WIDE and KAME projects was left almost untouched. There is no need to modify or rewrite this code; it's decent code, a model implementation, and it will not be a trivial task, but maybe adding enhancements, only tested ones, one by one, is the way to go. It seems that some people have already given up on IPv6 in FreeBSD and do not consider FreeBSD to be a popular OS anymore. Let me cite a 2 and 1/2 years old post from RIPE ipv6-wg mailing list:  "After over 10 (yes, *ten*) years, we have finally addressed security/privacy issues in the generation of IPv6 stable addresses in most popular operating systems. (...) Over time, popular operating systems and packages adopted the proposed algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS, etc. Eventually, virtually every popular OS had adopted the scheme.... except Windows (...)"[1]. [1] https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/thread/IV46DM2TD4XUTMJITSF3T43OUC3V3RND/ Cheers Marek > > > On 4/6/25 16:49, Guido Falsi wrote: >> 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 >> >> > From nobody Fri May 9 16:39:36 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 4ZvF8W3l7sz5vsr9; Fri, 09 May 2025 16:39:39 +0000 (UTC) (envelope-from des@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 4ZvF8W1mbCz3fDy; Fri, 09 May 2025 16:39:39 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746808779; 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=7Jryw44hPptTzNCRdx865Ie4voKB5nVYrEhYyFFnHSA=; b=EMzJaK/NZshFz//rVIhgogPMwLzYQ094IY05tdTrQaOgyRvbjTc+333hCcsnQeNStNmb3B hWPgJXbTi6YvER3ng4vLtJI3IoQjr3z97XqbXxUm6iTyLU9YCU/72NsWvc2P6DbmcIiOAN Ba1FLDkWsgz+jKR1LpkOERqZKCNjf0z0iGniLtwWfaaWzrVYzkqlnoDDyZSF++ADssfiU0 Nhwfc7so/wl+1ojPcDkMqqf655hFUF9GjTycEH5Dv+QM18UoIVu0mVVBRL2gEqMz1iVE69 vmcEu1AFk6eclGCm33h5vWsuBU6T6gyg9sbJUu96vP2c3vjMYtwTJaZ49DPy3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746808779; 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=7Jryw44hPptTzNCRdx865Ie4voKB5nVYrEhYyFFnHSA=; b=PN1nvz3zqv3R1gfs3l9vZNwKo3HcHk4gENEhNeh94DKXyfsMsk8LUUysbYqCpaO3VgCvDO 5H9upgcTeHv4rd2Fr0f49/Vtm1PxFoctsnlPb8x4nVqY7XyF8y8TPf+PDO3tAvVAiFgMnA CGw7FatF4qNAocaKa+mAm6MCd6tZ/8faoYBM6wNEFcueVqBXakpc2MWho3X5eTUtwUBySz R4AZO1SHQBnY+OvYYoSwZqM4X4KTxUy++LUJMMqkXxgBn+qSknHZvEBx0ssoO/f7sL/MvB zpvKPQektMNrFfazQc35yrTX2ECHtILXDqiomszHITfGKTXVyfnbJ+fiM+fjVQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746808779; a=rsa-sha256; cv=none; b=srFAget5iV18QhjvZEbL3EouorcldCdlGxqU7F1iElQHebqyatLjmdcOOybEMC5WdZJZYO PAhoW+VpHJ2WYxZn/Z5gnSRdjqZhrdYmTyX/h5mye9AU864ZI01iavjT82McJX4uF0Qkpu fLs1kMMkNILJxKZEt4U12PASosoCgIiqLxdd45jEFqM+wRfnT5Ql8E7aBUBW7PXrw0UKKn sTjbHV/jTs5Olt5XQlIsphpQQDIlUwNuDuzBJnpWCU/XVrjA1+dtHlpiCUg3bH9Cj3/xNO H5QRCwSXXjdsjfhdd4MS9TMasKayHWxTS2+fY8wp+X/4CbvbnLzK8ySwS9u7bQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (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: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZvF8W0KvnzFfB; Fri, 09 May 2025 16:39:39 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id EFDAD148C33; Fri, 09 May 2025 18:39:36 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ed Maste Cc: Graham Perrin , freebsd-current@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: Installer, before exit: /bin/tcsh for pkg In-Reply-To: (Ed Maste's message of "Thu, 8 May 2025 17:09:25 -0400") References: <86a57t3cfu.fsf@asn.ftfl.ca> <688e37e4-3d6d-4e5d-ad47-9d1156d50330@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 09 May 2025 18:39:36 +0200 Message-ID: <865xi9u4af.fsf@ltc.des.dev> 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 Ed Maste writes: > It looks like nano's post-install/-deinstall requires print/indexinfo > and it's not available. This doesn't appear to be directly related to > /bin/sh, /bin/tcsh, or pkgbase. If you have concise reproduction > steps, please submit a PR. The nano package has a run-time dependency on indexinfo, so it's almost certainly already present. The most likely explanation is that their sh doesn't have ${LOCALBASE}/bin in PATH but tcsh does. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Sat May 10 19:28:05 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 4Zvwrk4Bj7z5vkDp for ; Sat, 10 May 2025 19:28:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zvwrh6dTxz3MDC for ; Sat, 10 May 2025 19:28:20 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zabbadoz.net header.s=20240622 header.b=MNFpdlIN; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2003:a:140a:2200:6:594:fffe:19 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=pass (policy=none) header.from=zabbadoz.net 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 78E5CA64805 for ; Sat, 10 May 2025 19:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1746905285; bh=AgxhyY5a4CK9xgJzpNuDtXj8kGGCADPDb8ZMvmIxdCc=; h=Date:From:To:Subject; b=MNFpdlINavtiM8n8HJeDE+FLTfKu3KABMhDaYw8SHFX7ymgvWsCYNylI397GqH6aM KGsheTcQ+hf3Zz8QLyU4eHH8P/KI/khA5KJvuGus5jW/Hnr1N+ivh9WnIMtFxFDS4n aGJDZ9vpPSiEA8+JF1SepY2qQDbomH6YeYe3NcuSp7mw8ZtgWwP6swfjFe3L6hb5dx zIxQRCZR4qfvy3z9o3O6n5WY4arhBLvr52xRzzaM2JWfPRTzZ5SQ/aVFZ1CxRZiJXL JA+dG9fK09GWZYipYFReYXxanplbMb4Q1Febm8FZN+ha/eY7Klq9FQxk7BrgfBDytk guwaTpjI8DNBoJ9knOJRje/p/sy2czwFn8rIxgKHNHYXom5lnHuWuFmZWMFRF4//VQ wezUg5PZS9aiUSeJXH4DZYteVPISgMOaeZSQ1qagSsy/bJX3jTo5jGjrFX2COX1gUm vJBR/39+TuPl7mtIcFfwZIfDPoeN+w/cfqFBZ9iDJdW/ps+Q5VxV+l/gCOe6L0aioT c10Bu+eFvkvj/WA8oHVPN3EYDE8TVxEs/qDyIgsZbueyFTAHoLFhoqETu3bQPEz4TZ lw5QRA4c/aBa+Rn5JMpWBent7qJm29mxObAI9ibNHxprn1GShhiqC9rGbpY0yXEcCp hJQjWd0fZ2kK69SVqrzPYfDw= 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 269912D029E0 for ; Sat, 10 May 2025 19:28:07 +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 bquDP049uz6L for ; Sat, 10 May 2025 19:28:05 +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 A132B2D029D8 for ; Sat, 10 May 2025 19:28:05 +0000 (UTC) Date: Sat, 10 May 2025 19:28:05 +0000 (UTC) From: "Bjoern A. Zeeb" To: current@FreeBSD.org Subject: Loader goes to LINES=16 and kernel stays on that :( Message-ID: <988144rr-r83q-1s32-3498-s07r557p6083@yvfgf.mnoonqbm.arg> 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 X-Rspamd-Queue-Id: 4Zvwrh6dTxz3MDC X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; NEURAL_HAM_SHORT(-0.80)[-0.804]; DMARC_POLICY_ALLOW(-0.50)[zabbadoz.net,none]; R_DKIM_ALLOW(-0.20)[zabbadoz.net:s=20240622]; R_SPF_ALLOW(-0.20)[+ip6:2003:a:140a:2200:6:594:fffe:19]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[current@FreeBSD.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[zabbadoz.net:+] Hi, I've been trying to get my laptop updated to main of the day for a few days. loader.efi (lua) gets loaded; I see the EFI bits flashing by in a tiny font and then loader sits there being more magestic than on a vt100 with LINES=16 : % kenv LINES; kenv COLUMNS 16 60 Before the kernel starts I see that bit flashing by which says 1920x... but even the kernel then stays with LINES=16. I'd appreciate if someone would help me to get this fixed so that I can cater for all the later problems better (wifi, drm-kmod, IPv6, .. all paniced on me). /bz -- Bjoern A. Zeeb r15:7 From nobody Sat May 10 19:36:04 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 4Zvx1h5s75z5vkTl; Sat, 10 May 2025 19:36:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zvx1h0K3kz3b2T; Sat, 10 May 2025 19:36:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zabbadoz.net header.s=20240622 header.b="n/K5EilT"; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2003:a:140a:2200:6:594:fffe:19 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=pass (policy=none) header.from=zabbadoz.net 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 71481A64806; Sat, 10 May 2025 19:36:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1746905764; bh=psITLCDoR/T2EDRlGIx8i5N82GDlbpv/lBWfbs0EC4g=; h=Date:From:To:Subject; b=n/K5EilTo4+qiCk/EfydhFh0NJK2wIVg++dAs/jFihacqfSh6t7RprL3q7tjoOsU/ cjOmBEfUQNIJQVMXZfwoTFXbKJKD0acorfqoKBTi1lzCK+4TMj0hopLLAWmbvKr+Dh 0dnJKNiuf+EQkgwtYe7J5FraysJgPzZJ3tVAFS2KtdbbgCHD2qtZXSWT89Hs45I7fs JjHkhUoy9KZjmdXhRAkYC89jJ09sy/U7FgIGOaCRPnUGieEcFo9kyfggL1/lQkbRpO PIkrJ6LIMkwEwpj/HoDXQvpJAB/TS0DUgLbAyweKL515IZvEBG4wQuZ3TFnKlXWsDz ymwJl8jcroOXc6iLuPVRJpF5ssIFvYGlrnu2EU5A4ERes28eeumgRMRGHkK5OtNFwS PPjW/ZbM401+8ZSsXwvC5bJM7zmvaqzSNCHMsLaCdFlgAYvT4pJXMKNjDswM4srSQh zh5KANeQE/4Unp+cxScgI49kXC1pve08BqRIoTX0F8NPKrNUVN8jLaD4aqbw+tLvqy bYA3AIxk3fXls1udww6e14yBEom7TNOxbgxE9sJ2pU5hLAtUhByMCujoh2PFmgYZsj glwR3JboYQQGIStNiuPBG+zqb77ze4LXfuOAsxK8nfyc0d+gnHoqQMWU+PIYnHj/EX CWiCAYyzG/+SXEW7UmMuCObQ= 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 33BC82D029E1; Sat, 10 May 2025 19:36:06 +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 RHOJ5oMBydG7; Sat, 10 May 2025 19:36:05 +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 65BCD2D029D8; Sat, 10 May 2025 19:36:05 +0000 (UTC) Date: Sat, 10 May 2025 19:36:04 +0000 (UTC) From: "Bjoern A. Zeeb" To: usb@freebsd.org, current@freebsd.org Subject: panic in usb_detach_device / device_printf Message-ID: <9p19rsns-ro3r-so94-14p1-2s9p61377q73@yvfgf.mnoonqbm.arg> 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 X-Rspamd-Queue-Id: 4Zvx1h0K3kz3b2T X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; NEURAL_HAM_SHORT(-0.97)[-0.974]; DMARC_POLICY_ALLOW(-0.50)[zabbadoz.net,none]; R_DKIM_ALLOW(-0.20)[zabbadoz.net:s=20240622]; R_SPF_ALLOW(-0.20)[+ip6:2003:a:140a:2200:6:594:fffe:19:c]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org,usb@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[zabbadoz.net:+] Hi, hit this twice when switching an XHCI from ppt0 back to xhci (or vice versa ?) on a previous kernel (sorry I hit 4 other panics and I don't have more details anymore). That kernel may have been 3-4 weeks old, so may be fixed by now? Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80b8d519 stack pointer = 0x28:0xfffffe01047d4c80 frame pointer = 0x28:0xfffffe01047d4dc0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (usbus0) rdi: fffffe01047d4c88 rsi: ffffffff80ba9460 rdx: fffffe01047d4d18 rcx: 0000000000200000 r8: 0000000000000001 r9: 8080808080808080 rax: 7373616c63627573 rbx: ffffffff81231211 rbp: fffffe01047d4dc0 r10: fffff8000159d110 r11: ffffcfd1ced1cfd0 r12: fffff80001595580 r13: 0000000000000000 r14: fffff8000158e700 r15: fffffe01047d4c88 trap number = 9 panic: general protection fault cpuid = 0 time = 1746609904 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01047d4a00 vpanic() at vpanic+0x136/frame 0xfffffe01047d4b30 panic() at panic+0x43/frame 0xfffffe01047d4b90 trap_fatal() at trap_fatal+0x68/frame 0xfffffe01047d4bb0 calltrap() at calltrap+0x8/frame 0xfffffe01047d4bb0 --- trap 0x9, rip = 0xffffffff80b8d519, rsp = 0xfffffe01047d4c80, rbp = 0xfffffe01047d4dc0 --- device_printf() at device_printf+0x89/frame 0xfffffe01047d4dc0 usb_detach_device() at usb_detach_device+0xd3/frame 0xfffffe01047d4e00 usb_unconfigure() at usb_unconfigure+0x83/frame 0xfffffe01047d4e40 usb_free_device() at usb_free_device+0x15c/frame 0xfffffe01047d4e80 usb_bus_detach() at usb_bus_detach+0x6e/frame 0xfffffe01047d4eb0 usb_process() at usb_process+0xc5/frame 0xfffffe01047d4ef0 fork_exit() at fork_exit+0x7b/frame 0xfffffe01047d4f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01047d4f30 --- trap 0x3a8d224b, rip = 0x91722c9d5743a0fe, rsp = 0xc95674b90f67f8da, rbp = 0x84eb42daceb9d67e --- KDB: enter: panic -- Bjoern A. Zeeb r15:7 From nobody Sat May 10 20:09:25 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 4ZvxmL62KMz5vmrD for ; Sat, 10 May 2025 20:09:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 4ZvxmL46qxz3D4k for ; Sat, 10 May 2025 20:09:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-740b3a18e26so2570970b3a.2 for ; Sat, 10 May 2025 13:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1746907776; x=1747512576; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FWNMAKLxkqbm8PBbt/xCo4tGtpY1Ke1tD2R+jHMPdtg=; b=j/p/vN+LoPhD6smk9GqU+wTDHt3CNsW8W9I+UObrlwh5E99aelCdzFox8LlFQr/H95 fGXEqS8XbaAqTjbnOl5w2uezEjs8Fui2MFkVXzr66ZRHZ8rqbKNkdIg6ATQB+IDPKHOF rRaUFa+yGmEbvEn58fJwzUEcHZDXoSQZKrH/1h7ppzMDf+gWZ5R3b2KnhGRzC2kyc8ii wD9yYvYAkmqzm1SH3nymF5m65TsWehA4ghz7QB1EhxfUqiYfZ3F7lqDng0JslYCQyIZA Xff/iLVpNe/qtYYfYDzT1OCq7AY9n3zYR2IlJzoDdWYvINtE7bF63orPVEQz929cGLdO JwUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746907776; x=1747512576; 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=FWNMAKLxkqbm8PBbt/xCo4tGtpY1Ke1tD2R+jHMPdtg=; b=P7Q+z7hj65niE+FctnpAqx+4wtbf0Pp2mmb86bJ0hke4QPRnjN7kFaMm3ivyyJi24H T5QtemJDMrCA2hgOYArq2MGjInPxrdF+MV1/eVJc8VNn9UGLKBmmV7B0WxTd27W5DTR/ 5gw1FcPbD9zGK81JGQl2Zg/6tCtmWi03tW2EFA64SM1D/Coai8e2tuDjKgZphKAzHPzA 4kY65abRcFVPdpwmN6r9+0pucjQXCIvEM7MwBOmWxQ5WfQC7cWssnBZK+qzw3Sb458LW o359gBlTvWPC2BGN9Ri6Bmzlo/Ir7As6wurdPMb71rVkAP+2duHtu/DcaF+JcbyF5tMv FfFw== X-Gm-Message-State: AOJu0YwpQIIofP0K0MT6OEvFhJlRYVZZydZ6L71rolyntoBBzOX8tCxc KlMBPoS+NoYmHNpRTsWOY6hxeKCJsf6zUNvlVHeTivRvTVujo3o+TI+Idc/kskF00jWdRJelboh VRg0AXxQo6lwDCDmdwht8D40f5H4JJSaxgg9NqL0aVUbUAfy+ X-Gm-Gg: ASbGncst4P+Gg5BvofjuT4zHtkcuBjhxtKxHDJAaYWqicgAwEk5sCpWMVYacuGZv5Qf CNZXTNNY0bK7Fg0cHLG4Avru+c4ODsOQ5ob62g0axnELKes3PjIaRC+TXTQsHb74+mRuJX6ShpK Wf62TTxfUBCU/wfehO08Bo7WJpuqjuGjqLKX4Uia3w0dL7N5V9Yg8jo3iBHEzr1gUXjhA= X-Google-Smtp-Source: AGHT+IGtre4jbn5hgHvoq2IQwGJVSSlqrWsdHak7buNajh56JyIkbW8kApCQvnNVlBTMFJOXAP7mAc9fk77UqXWsEl8= X-Received: by 2002:a05:6a21:648c:b0:204:432e:5fa4 with SMTP id adf61e73a8af0-215abb3a644mr12685801637.23.1746907776389; Sat, 10 May 2025 13:09:36 -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: <988144rr-r83q-1s32-3498-s07r557p6083@yvfgf.mnoonqbm.arg> In-Reply-To: <988144rr-r83q-1s32-3498-s07r557p6083@yvfgf.mnoonqbm.arg> From: Warner Losh Date: Sat, 10 May 2025 14:09:25 -0600 X-Gm-Features: AX0GCFvmIW7B81Wh68JV0l7gzkGFiJlS4RO8DPI63nHLZVcKT0qgH8oexTVF6gM Message-ID: Subject: Re: Loader goes to LINES=16 and kernel stays on that :( To: "Bjoern A. Zeeb" Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000077a5430634cda981" X-Rspamd-Queue-Id: 4ZvxmL46qxz3D4k 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-Spamd-Bar: ---- --00000000000077a5430634cda981 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yea. This is due to the new, larger font and a hidden bug. Warner On Sat, May 10, 2025, 1:28=E2=80=AFPM Bjoern A. Zeeb wrote: > Hi, > > I've been trying to get my laptop updated to main of the day for a > few days. > > loader.efi (lua) gets loaded; I see the EFI bits flashing by in a tiny > font and then loader sits there being more magestic than on a vt100 > with LINES=3D16 : > % kenv LINES; kenv COLUMNS > 16 > 60 > > Before the kernel starts I see that bit flashing by which says 1920x... > but even the kernel then stays with LINES=3D16. > > I'd appreciate if someone would help me to get this fixed so that I can > cater for all the later problems better (wifi, drm-kmod, IPv6, .. all > paniced on me). > > /bz > > -- > Bjoern A. Zeeb r15:7 > > --00000000000077a5430634cda981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yea. This is due to the new, larger font and a hidden bug= .=C2=A0=C2=A0

Warner

On Sat, May 10, 2025, 1:28=E2=80=AFPM Bjoern A. Zeeb <= bzeeb-lists@lists.zabbado= z.net> wrote:
Hi,

I've been trying to get my laptop updated to main of the day for a
few days.

loader.efi (lua) gets loaded;=C2=A0 I see the EFI bits flashing by in a tin= y
font and then loader sits there being more magestic than on a vt100
with LINES=3D16 :
% kenv LINES; kenv COLUMNS
16
60

Before the kernel starts I see that bit flashing by which says 1920x...
but even the kernel then stays with LINES=3D16.

I'd appreciate if someone would help me to get this fixed so that I can=
cater for all the later problems better (wifi, drm-kmod, IPv6, .. all
paniced on me).

/bz

--
Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7

--00000000000077a5430634cda981-- From nobody Sat May 10 20:13:39 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 4ZvxsF5J93z5vn2n for ; Sat, 10 May 2025 20:13:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (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 4ZvxsF3FCKz3JZQ for ; Sat, 10 May 2025 20:13:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-326ca53a7e8so15428771fa.3 for ; Sat, 10 May 2025 13:13:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746908031; x=1747512831; 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=TqX4gvFZn/0qPzShqKZdNGcbtSMfC2aKZMwcjNnKvP4=; b=VIM+Ptlbkio7XG0sS9XDh3Cxq7YRyGPLnCFguzKvNNHlOUmNKK3tXgPoxtphkBZvNw OKl8xYdUsVUYGiH6+zSyBatdMWHF1sSWjbGFkCNaCwIzpdqQdcDA/aooIa1ikoQT0Phu pCZVUY81kTgkRa1rx53zxfHZmBVRUUmGrg84ZdVpnuaqxroxYsWs9l0e/2Gsa3qHWC1Z 1dj6BoCesB5TbLmrL8m5nzw3eSt3YgWu3mGyVbW6LPoM/fe/0s7vBsK2WnPl7Ht5GpML UuV4ILjpJf7hvStPhUKX8mqAIcRfofMxeVFyfMIoSkFvepCbbsHkODwTRi4klOxIJ2r3 TpWA== X-Forwarded-Encrypted: i=1; AJvYcCXnaifQi9v2aCMKPUuXc7Op6A+LaFoLQ3xYcZFcQzReP5Y28jpu8Dn7OJArmossm9jCroNoD2xY@freebsd.org X-Gm-Message-State: AOJu0YzXrJNBTPJkU4GD/laC4WFAcoqClCAAq1VH3U7lM9W44i/HrbWr et+Fs6WwPw9DDAY5MFhGbi4QDDclFr9eWenibw8TQ/Hvz1ztOJtC0dxtDhfD+jyTT5I7yZks73T aZnA8tGMdAx+8g7+WciyzTHvBCHEae7+B X-Gm-Gg: ASbGnctjywjt4Bl031k3Fn3jfbmqBJ0Te8lw0xPvGpi/699Zp6954W1F1RUEoEVONxQ ZchEM+ccc1ceEnJeSsxpDFpx8omoZ24O6iII2d8vRNA+EXm2lRekclIQXRS5vxJPgLbtiOmdJm4 d3Vz1B4GsfemrPo2R7zf/SHekBiK5u4E4KCGFLKDDQxYYr X-Google-Smtp-Source: AGHT+IFE19M4tW+dh9P478cwBMdNAKpM9B0N1g9gff9xlmxGwa0JSjvgWkBrt8odAVBGrxkma9Zwas4fn28vMiAcIZ8= X-Received: by 2002:a05:651c:19a8:b0:30b:d40c:7eb4 with SMTP id 38308e7fff4ca-326c453c2a4mr30175581fa.7.1746908031123; Sat, 10 May 2025 13:13:51 -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: <988144rr-r83q-1s32-3498-s07r557p6083@yvfgf.mnoonqbm.arg> In-Reply-To: From: Adrian Chadd Date: Sat, 10 May 2025 13:13:39 -0700 X-Gm-Features: AX0GCFshv0SRSicBj3SLc5ee0kXGDeGLxVgo4N02k1PUoRLiYlDI52a1g3lsbFQ Message-ID: Subject: Re: Loader goes to LINES=16 and kernel stays on that :( To: Warner Losh Cc: "Bjoern A. Zeeb" , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000a6857e0634cdb83a" X-Rspamd-Queue-Id: 4ZvxsF3FCKz3JZQ 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:209.85.128.0/17, country:US] X-Spamd-Bar: ---- --000000000000a6857e0634cdb83a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 10 May 2025 at 13:10, Warner Losh wrote: > Yea. This is due to the new, larger font and a hidden bug. > Hasn't this been fixed in -HEAD? I thought tsoome was working on it. Oh, here: https://reviews.freebsd.org/D50258 Want to try that out and see if it fixes things? -adrian > > Warner > > On Sat, May 10, 2025, 1:28=E2=80=AFPM Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> Hi, >> >> I've been trying to get my laptop updated to main of the day for a >> few days. >> >> loader.efi (lua) gets loaded; I see the EFI bits flashing by in a tiny >> font and then loader sits there being more magestic than on a vt100 >> with LINES=3D16 : >> % kenv LINES; kenv COLUMNS >> 16 >> 60 >> >> Before the kernel starts I see that bit flashing by which says 1920x... >> but even the kernel then stays with LINES=3D16. >> >> I'd appreciate if someone would help me to get this fixed so that I can >> cater for all the later problems better (wifi, drm-kmod, IPv6, .. all >> paniced on me). >> >> /bz >> >> -- >> Bjoern A. Zeeb r15:7 >> >> --000000000000a6857e0634cdb83a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 10 May = 2025 at 13:10, Warner Losh <imp@bsdimp= .com> wrote:
Yea. This is due to the new, larger font and a hidden= bug.=C2=A0=C2=A0

Hasn't this bee= n fixed in -HEAD? I thought tsoome was working on it.

<= div>Oh, here:


= Want to try that out and see if it fixes things?

<= br>
-adrian
=C2=A0

Warner

On Sat, May 10, 2025, 1:28=E2=80=AFPM Bjoern A. Zee= b <b= zeeb-lists@lists.zabbadoz.net> wrote:
Hi,

I've been trying to get my laptop updated to main of the day for a
few days.

loader.efi (lua) gets loaded;=C2=A0 I see the EFI bits flashing by in a tin= y
font and then loader sits there being more magestic than on a vt100
with LINES=3D16 :
% kenv LINES; kenv COLUMNS
16
60

Before the kernel starts I see that bit flashing by which says 1920x...
but even the kernel then stays with LINES=3D16.

I'd appreciate if someone would help me to get this fixed so that I can=
cater for all the later problems better (wifi, drm-kmod, IPv6, .. all
paniced on me).

/bz

--
Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7

--000000000000a6857e0634cdb83a-- From nobody Sat May 10 20:18:34 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 4Zvxz213TLz5vnNw for ; Sat, 10 May 2025 20:18:54 +0000 (UTC) (envelope-from tsoome@me.com) Received: from outbound.pv.icloud.com (p-west1-cluster3-host11-snip4-10.eps.apple.com [57.103.66.33]) (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 4Zvxz0496Sz3Prc for ; Sat, 10 May 2025 20:18:52 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; bh=0gcYu+oJNrx7AolWAIVbbkKBU5e37HaGjIflfJjWTqk=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To:x-icloud-hme; b=g3BPY316cNiGW1iKTRYlhfh3/slBBPJcK+3ug6AbaqIoAIsYWArDUGp2v5ETlLB7k d8BUvYnkhcLfcS5jZtp/XLkighQobPf8T8fVOFTopK2ciRGrb5xPpzjnSlp7DHHzEC 09yVfeccg74iwAcJftK7Pn4j39/JxdTdBEBESevzFgjY3glY+vPYzlmIW7GESDxNQl 6SbkFUskIbi/FVZiwgGyl9udwqKNs6pxgpwFFbvi7aY3FhhlbbIQofX1J2+vrI8jqq mXe8UoROTEgyh+2fqLbb1LhiO1r0lqAdwBo95lnay3d8nCLtF5Z1oji+h4PglWNbBr RxtsVNsPxMztA== Received: from smtpclient.apple (pv-asmtp-me-k8s.p00.prod.me.com [17.56.9.36]) by outbound.pv.icloud.com (Postfix) with ESMTPSA id 48D3518007CA; Sat, 10 May 2025 20:18:48 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-50265E09-D3DC-460C-BA0F-B553B0404352 Content-Transfer-Encoding: 7bit From: Toomas Soome 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 (1.0) Subject: Re: Loader goes to LINES=16 and kernel stays on that :( Date: Sat, 10 May 2025 23:18:34 +0300 Message-Id: <067DD4B5-3EDA-40AC-B169-7A637C3CB129@me.com> References: Cc: Warner Losh , "Bjoern A. Zeeb" , FreeBSD Current In-Reply-To: To: Adrian Chadd X-Mailer: iPhone Mail (22E252) X-Proofpoint-GUID: iv_0KjCIQUvuFQOSXwyaNlj5zwS9Nkvy X-Proofpoint-ORIG-GUID: iv_0KjCIQUvuFQOSXwyaNlj5zwS9Nkvy X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-10_05,2025-05-09_01,2025-02-21_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 mlxscore=0 clxscore=1011 suspectscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2505100210 X-Rspamd-Queue-Id: 4Zvxz0496Sz3Prc 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:714, ipnet:57.103.64.0/22, country:US] X-Spamd-Bar: ---- --Apple-Mail-50265E09-D3DC-460C-BA0F-B553B0404352 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable It would be really nice if you could test i= t.
Thanks,
Toomas

Sent from my iPhone

On 10. May 2025, at 23:14, Adrian Chadd <adrian@fre= ebsd.org> wrote:

=EF=BB=BF


On Sat, 10 May 2025 at 13:10, Warner Losh <imp@bsdimp.com> wrote:
Yea. This is due to the new, larger f= ont and a hidden bug.  

Hasn= 't this been fixed in -HEAD? I thought tsoome was working on it.
<= br>
Oh, here:


Want to try that out and see if it fixes things?


-adrian
 

Warner

On Sat, May 10, 2025, 1:28=E2=80=AFPM Bjoern A. Z= eeb <= bzeeb-lists@lists.zabbadoz.net> wrote:
Hi,

I've been trying to get my laptop updated to main of the day for a
few days.

loader.efi (lua) gets loaded;  I see the EFI bits flashing by in a tiny=
font and then loader sits there being more magestic than on a vt100
with LINES=3D16 :
% kenv LINES; kenv COLUMNS
16
60

Before the kernel starts I see that bit flashing by which says 1920x...
but even the kernel then stays with LINES=3D16.

I'd appreciate if someone would help me to get this fixed so that I can
cater for all the later problems better (wifi, drm-kmod, IPv6, .. all
paniced on me).

/bz

--
Bjoern A. Zeeb                 =                      = ;              r15:7

= --Apple-Mail-50265E09-D3DC-460C-BA0F-B553B0404352-- From nobody Sat May 10 21:31:34 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 4ZvzZz3TWNz5vscd for ; Sat, 10 May 2025 21:31:39 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZvzZy6CGHz3Jwf for ; Sat, 10 May 2025 21:31:38 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none 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 8EF32A64805; Sat, 10 May 2025 21:31:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1746912693; bh=85ZEVLYnPh/UFjN5Edjr7VOnbvOpMrp48zSpBZyQsB8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=M2/ph718f9OooRAAjd0M6Ir65kxM4tsN9KpayTZueyYtDbMe6PxfUvGQm8774GyhR rojCB5aO9al/qo9UwcZt91nBH0jG/NY6mDCNUy/0aWxyw5dm5Inn+BzR9EU+NkLJDp tFaZNe/3MQekzN/hJfdhHfjO3y/+WpZRw384lyKs1gBfdNXRz9p52O7QuLYgDl8EcJ j5zxh7K9Orb81yvWjns7Kq1fENXX6dZLlHCJYVQr6rtfPYAywOgTr35VC73dWXoYrW Czu917BV2JdI7ABzOl7PtuWdsrZRraksCUcqMUU7psoCmmHis0Ncti6f9Po4uZZHKP QT8BCMxQGjBBv8yTJsaXZn0sADhJ0yfI37iAhAHvJjAOz2JBzrEJOk/Fy8lk2SQnnd zNUkgDi/tFQAJdpuNwGAC3R8UTWXV25xxyfUK8cx8P7oSfWcBo46J+xMz8bzLZ6XNR AJeat4Wa1zpWq+lC11end2e6pTQE3BwP3xFtzsJWqvf+Usn+nFQWH25n9VuCGdOiOq /JSaEZOemUVPgpN9qrHo3iVXkzCB9RULzF19icQviOb9ifxAU3iVXJSpgHWfBJycSN p5dRh03ellPOEBNhbYZ6JObyi0KF+6pnKnb0Tq09nv9A46UoxfeligVaWLu013x1OF eePeMYUYFjxFSb7Y1pY7qku4= 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 3BFFD2D029E0; Sat, 10 May 2025 21:31:35 +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 IXNwsGc0C8sg; Sat, 10 May 2025 21:31:34 +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 627BC2D029D8; Sat, 10 May 2025 21:31:34 +0000 (UTC) Date: Sat, 10 May 2025 21:31:34 +0000 (UTC) From: "Bjoern A. Zeeb" To: Toomas Soome cc: FreeBSD Current Subject: Re: Loader goes to LINES=16 and kernel stays on that :( In-Reply-To: <067DD4B5-3EDA-40AC-B169-7A637C3CB129@me.com> Message-ID: <0n8p13rn-5o8r-959s-39r3-158ppspqs579@yvfgf.mnoonqbm.arg> References: <067DD4B5-3EDA-40AC-B169-7A637C3CB129@me.com> 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; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4ZvzZy6CGHz3Jwf 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:3320, ipnet:2003::/19, country:DE] X-Spamd-Bar: ---- On Sat, 10 May 2025, Toomas Soome wrote: [..] >> https://reviews.freebsd.org/D50258 [..] > It would be really nice if you could test it.Thanks, > Toomas On it; I'll reboot as soon as buildworld dedicded to rebuild half my obj despite only applied the one change. I thought on main this is all incremental these days. *sigh*. I assume there is no way to fix this manually as a user (change the settings from within loader) at least for the next stage (kernel)? I don't know much about all this; I tried vidcontrol later from the console to at least be able to read a few more lines only to get some ioctl errors. /bz -- Bjoern A. Zeeb r15:7 From nobody Sat May 10 22:03: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 4Zw0J66WZZz5vv2v for ; Sat, 10 May 2025 22:03:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 4Zw0J64nWLz3qsG for ; Sat, 10 May 2025 22:03:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-30a9718de94so3140253a91.0 for ; Sat, 10 May 2025 15:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1746914629; x=1747519429; 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=fwgzw0vAXycgr+Xx6EElU2zqyd0D5iyF9XW810LfMzw=; b=o78q20KfjZ7ot2LGjtiX52GfQ6h0ehbEqpMDzMtaystX0OqZQsdrRLOl9sJjHOBxx8 L+irxv6Zw7x157jotO+Vw4+ptjC3K9FuDQ9GB9s0es3k485gjweBdm2N7b0qlt7TYgdz m52IER2WYbPD2RWcMEBwkfPG8UZ5ohYMIwn2FlQyU1G2b5tbnbDjF6/r9YCNHp7bAWiR rCNhn0ZpSpJOIlcgxtIMFVG8GElgg7iO20fU2PbF94ECacNfXv6vIni6aRg0JaAR4sJG V0s7KMkNi7vAhjh0vBwQY/z+MQn4jv8LR9e7q3mCSrjJNS86Nnoif/L7IEiSWCnE8d+/ PjUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746914629; x=1747519429; 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=fwgzw0vAXycgr+Xx6EElU2zqyd0D5iyF9XW810LfMzw=; b=IgGCAxfl4mbZeZ7pEVHq43OYog+XnTyNlh3Jc2XPi7hCGQaTMjKN5wh9nmCKor8a1q 5pHWWXRmFvvLWqOxSJlMh2wR74Aj8FxlnukC8Dg7vYrCSrox0YbZFAz1VxPEFrQ6vCQu QSN5Bk/h29rnb5AfyaTylM9mN2AA3PVs6+2GgUKJAn4sDCP8vfBpxCRvynUCh3u5S0hc 4Bh3NI1a5GYd0tr3orYz++WtBz/pCE6PgUZ+PDmMnYAD6ozF5Fr388YbTet6qL4Tj0ju Mqg03LugwsivGuHcGUhq3q3LqYHMQTmh++yubi/OWOk+sMk+2HB86AW4tXD+QXSBiHFF kXhg== X-Forwarded-Encrypted: i=1; AJvYcCWrb430cZeHi9c3Tbv+QV0kKKmUWo0eAAAlh6Wn1q0MigF58eC3vaurbjNCUvr+FBlLMn9sSkdf@freebsd.org X-Gm-Message-State: AOJu0YylDeXRa2qT5yVIu9DF5pOPo0NZhj84Gl35wSO2Y5yHbIkE4k+7 MPg4a0Ex4KxzdORHo9hBpZ5mft94/FndRD5MohoOGQtfR0f1reVnjNpeGKqcs/93fNOAZtrxfdu /zE/DqmzxSj0UuUJGC9bLfOa12vsN3rFzLJZihw== X-Gm-Gg: ASbGncvR22rqKGW5kFkdWMnin73q2SK4edATBek/g0oaxRDXOhck7f/fM5eqH3WQVc/ vJ1CjReajTJ7WpDJQBCOOuo+37IBZPEJE0Bk8NqGGCTiMLo1WApR5TQjq/XbsIfQm2n49dPrgyP HXtfAo/TSWz6Y2Y1+k5BZxVR8iy+0s8WPL X-Google-Smtp-Source: AGHT+IG/gPOX80Fh8cFuTrq8U7RSq1ls2eTXp71O4AZHDZN5eu9fMn7vNqhmJexFxa9VQvNAyn9gtRxbB+A0GW1gFwg= X-Received: by 2002:a17:90b:224d:b0:2fe:8902:9ecd with SMTP id 98e67ed59e1d1-30c3cafbd46mr11303818a91.1.1746914629223; Sat, 10 May 2025 15:03:49 -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: <9p19rsns-ro3r-so94-14p1-2s9p61377q73@yvfgf.mnoonqbm.arg> In-Reply-To: <9p19rsns-ro3r-so94-14p1-2s9p61377q73@yvfgf.mnoonqbm.arg> From: Warner Losh Date: Sat, 10 May 2025 16:03:38 -0600 X-Gm-Features: AX0GCFvireEY9lf__S7qH9CKQVJkWU3vVGXzCmS-Lbbbv90q0hpH_mbkNhiWpbg Message-ID: Subject: Re: panic in usb_detach_device / device_printf To: "Bjoern A. Zeeb" Cc: usb@freebsd.org, current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Zw0J64nWLz3qsG 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-Spamd-Bar: ---- Yes. usb is hanky in its newbus integration and always has been. How did you get this to happen? I know that it can happen in some weird error scenarios (that I've not been able to reproduce), but just removing t= he device is orderly enough... But it looks like jhb's cleanup may have opened the issue back up, since usb_detatch_device shouldn't find anything still attached. I'm guessing tha= t there are devices that are children of this node that are attached and also somehow devices of the interface? So interesting crash, but without a lot more data about the usb configurati= on and what device is being detached, I can't help you. Warner On Sat, May 10, 2025 at 1:36=E2=80=AFPM Bjoern A. Zeeb wrote: > > Hi, > > hit this twice when switching an XHCI from ppt0 back to xhci (or vice > versa ?) on a previous kernel (sorry I hit 4 other panics and I don't > have more details anymore). That kernel may have been 3-4 weeks old, > so may be fixed by now? > > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > instruction pointer =3D 0x20:0xffffffff80b8d519 > stack pointer =3D 0x28:0xfffffe01047d4c80 > frame pointer =3D 0x28:0xfffffe01047d4dc0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 15 (usbus0) > rdi: fffffe01047d4c88 rsi: ffffffff80ba9460 rdx: fffffe01047d4d18 > rcx: 0000000000200000 r8: 0000000000000001 r9: 8080808080808080 > rax: 7373616c63627573 rbx: ffffffff81231211 rbp: fffffe01047d4dc0 > r10: fffff8000159d110 r11: ffffcfd1ced1cfd0 r12: fffff80001595580 > r13: 0000000000000000 r14: fffff8000158e700 r15: fffffe01047d4c88 > trap number =3D 9 > panic: general protection fault > cpuid =3D 0 > time =3D 1746609904 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01047= d4a00 > vpanic() at vpanic+0x136/frame 0xfffffe01047d4b30 > panic() at panic+0x43/frame 0xfffffe01047d4b90 > trap_fatal() at trap_fatal+0x68/frame 0xfffffe01047d4bb0 > calltrap() at calltrap+0x8/frame 0xfffffe01047d4bb0 > --- trap 0x9, rip =3D 0xffffffff80b8d519, rsp =3D 0xfffffe01047d4c80, rbp= =3D 0xfffffe01047d4dc0 --- > device_printf() at device_printf+0x89/frame 0xfffffe01047d4dc0 > usb_detach_device() at usb_detach_device+0xd3/frame 0xfffffe01047d4e00 > usb_unconfigure() at usb_unconfigure+0x83/frame 0xfffffe01047d4e40 > usb_free_device() at usb_free_device+0x15c/frame 0xfffffe01047d4e80 > usb_bus_detach() at usb_bus_detach+0x6e/frame 0xfffffe01047d4eb0 > usb_process() at usb_process+0xc5/frame 0xfffffe01047d4ef0 > fork_exit() at fork_exit+0x7b/frame 0xfffffe01047d4f30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01047d4f30 > --- trap 0x3a8d224b, rip =3D 0x91722c9d5743a0fe, rsp =3D 0xc95674b90f67f8= da, rbp =3D 0x84eb42daceb9d67e --- > KDB: enter: panic > > > -- > Bjoern A. Zeeb r15:7 > From nobody Sat May 10 22:15:08 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 4Zw0YM4GG7z5vw2y for ; Sat, 10 May 2025 22:15:19 +0000 (UTC) (envelope-from tsoome@me.com) Received: from outbound.ci.icloud.com (p-east1-cluster4-host5-snip4-1.eps.apple.com [57.103.89.44]) (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 4Zw0YM1c15z43P6 for ; Sat, 10 May 2025 22:15:19 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; bh=VeF5t3oHCivBXNSFrx3MQuaOqOv85FRIkv+TL7vaYr8=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme; b=FTYmX68qDvPsJNhvm887F6pL7vtSs6xDU4NokK81p3K8dAqhENNxqQxXi8e/Vgub+ Zw1Gik8oYCJQZmW2I8RfKPx7x+l9j4cTJCIkbEOBxBoMKe6wpTXtfLhtffnJBY+TiH N3iqIp0uJM4HZIDReiD7glWt9J7TlP1EkfwUlqrCb4lSYh5uDvOFrKBeAg7t0DpVsv m1iEWq8bVdrLH4U/eYq+lwGuda1b2h31yD9tBFe0Th4QrE3mcVoyp6L15I53jdVlDm LJuJImRXknJ+6BSc0M4E5WlGeq7gO4POYsV+CKisQRiIkoK0lHMeXihU0uJcSRMiHC r1nMRodT0dWUQ== Received: from smtpclient.apple (unknown [17.57.156.36]) by outbound.ci.icloud.com (Postfix) with ESMTPSA id D2C5A18006C2; Sat, 10 May 2025 22:15:15 +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: Loader goes to LINES=16 and kernel stays on that :( From: Toomas Soome In-Reply-To: <0n8p13rn-5o8r-959s-39r3-158ppspqs579@yvfgf.mnoonqbm.arg> Date: Sun, 11 May 2025 01:15:08 +0300 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <067DD4B5-3EDA-40AC-B169-7A637C3CB129@me.com> <0n8p13rn-5o8r-959s-39r3-158ppspqs579@yvfgf.mnoonqbm.arg> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Proofpoint-GUID: yS-xbK8SJybZsKuf7hUwGzOGmvS88QBH X-Proofpoint-ORIG-GUID: yS-xbK8SJybZsKuf7hUwGzOGmvS88QBH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-10_06,2025-05-09_01,2025-02-21_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 clxscore=1015 adultscore=0 suspectscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2505100230 X-Rspamd-Queue-Id: 4Zw0YM1c15z43P6 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:714, ipnet:57.103.0.0/16, country:US] X-Spamd-Bar: ---- > On 11. May 2025, at 00:31, Bjoern A. Zeeb = wrote: >=20 > On Sat, 10 May 2025, Toomas Soome wrote: >=20 > [..] >>> https://reviews.freebsd.org/D50258 > [..] >=20 >> It would be really nice if you could test it.Thanks, >> Toomas >=20 > On it; I'll reboot as soon as buildworld dedicded to rebuild half my = obj > despite only applied the one change. I thought on main this is all > incremental these days. *sigh*. >=20 > I assume there is no way to fix this manually as a user (change the = settings > from within loader) at least for the next stage (kernel)? >=20 > I don't know much about all this; I tried vidcontrol later from the = console > to at least be able to read a few more lines only to get some ioctl = errors. >=20 oh, yes, you can set font manually, set screen.font=3D16x32 for example. = Only the autoselect with EDID data available was missing the check. = manual selection and autoselect without EDID is ok. rgds, toomas From nobody Sat May 10 22:29: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 4Zw0t90NZMz5vwmf for ; Sat, 10 May 2025 22:29:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zw0t84mBcz3Hcr for ; Sat, 10 May 2025 22:29:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-549b116321aso3265038e87.3 for ; Sat, 10 May 2025 15:29:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746916191; x=1747520991; 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=AXJRAzKNhpFUXPs5Qqv/HnqrvJ8ZbcKGH93jmL0mxVk=; b=WUZmRMoSWgHdqTNnEXUGAAeHaYWLFmpSxueD5V9UL0LKmR/DKCXybPFkQ/hT2BTOuE Fj/wGzY2N2NrrSnCzQ2vU+DhzzF1YD35p7CjAErqp9a2KMHUUyh33XTyUse2u7GeKhwN gzRW+0L0SKAIMmQKVUaG5eMl/itFV0BDSbzK9VE2pw5WFgPzO5Mpt7dGsukashI2tVEH lc+qUZRPT+Vr7ChobGo0WPgUbybmvd7/m2msuN/n5OAMOnQrDsEH8vdPXSN1fm9YvpLU uo9OQtNFz0poSPq3gjZtqaejxPI+oWi7w5TSX6qfUo98ulABsVx58sge3TenZNevSrhh jZHg== X-Forwarded-Encrypted: i=1; AJvYcCW3H1tuHcGzXGNrKHv0qErGgfNnp5gfrqCMcd0tUl0Ax/FdiwOtK1s87Jm19964uMFTRuK2XLtp@freebsd.org X-Gm-Message-State: AOJu0Yy/VS7ly8OZh2DEaSzBnk6u2wERrVVPUf/Ln5U6IJOQZAP88CiN CyhJASmZkKbgyXbr2m9UZMWDWJABrK25fyEmkTJnWbrhxy9QsvTPOdlywVTK9g8FLbqpqCEOnld 7yzd6YlzmksnCwPphCSmDGmjyF6M= X-Gm-Gg: ASbGncvNDBAIWSdBHgEyOn2G97D+uRng2Bk6O1mzNozU1HHEC3TEwCcz2qJqteH1odG bIjqyEQ3/g1lhAZR6oWUDh/YU4nRoCv6LRuX3+gxEfQQKqNCupriqmrlEHfe4ZQDFQpWaQsw+hB ApbD8rpNmyaojl26NzT4j75gwLAl9fC1jrTQ== X-Google-Smtp-Source: AGHT+IHOsjMk7QrFzEWFKUUFizfXwPxw1hBC7Yn2i73dy1EXm9I8e0+wocFrzPeoq2XULA9+UX9BUo0LNw6ZZbqRTO8= X-Received: by 2002:a05:6512:2289:b0:549:39d8:51ef with SMTP id 2adb3069b0e04-54fc67ad800mr2520753e87.6.1746916190364; Sat, 10 May 2025 15:29: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: <067DD4B5-3EDA-40AC-B169-7A637C3CB129@me.com> <0n8p13rn-5o8r-959s-39r3-158ppspqs579@yvfgf.mnoonqbm.arg> In-Reply-To: From: Adrian Chadd Date: Sat, 10 May 2025 15:29:38 -0700 X-Gm-Features: AX0GCFtrb_hikjPVJ3yxCuN9XkaiCh7cxDZGazrDG-_odrsEdvavwbGtJtYlrm4 Message-ID: Subject: Re: Loader goes to LINES=16 and kernel stays on that :( To: Toomas Soome Cc: "Bjoern A. Zeeb" , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000faa8a90634cf9e37" X-Rspamd-Queue-Id: 4Zw0t84mBcz3Hcr 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:209.85.128.0/17, country:US] X-Spamd-Bar: ---- --000000000000faa8a90634cf9e37 Content-Type: text/plain; charset="UTF-8" .. and I use this to get a smaller font, in /etc/rc.conf : # font8x8="/usr/share/vt/fonts/vgarom-8x8.fnt" font8x16="/usr/share/vt/fonts/vgarom-8x16.fnt -adrian --000000000000faa8a90634cf9e37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
.. and I use this to get a smaller font, in /etc/rc.c= onf :

# font8x8=3D"/usr/share/vt/fonts/vgarom= -8x8.fnt"
font8x16=3D"/usr/share/vt/fonts/vgarom-8x16.fnt



-adrian



--000000000000faa8a90634cf9e37-- From nobody Sat May 10 22:52:16 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 4Zw1NC6nyrz5vxr3; Sat, 10 May 2025 22:52:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zw1NC2zjRz3bjj; Sat, 10 May 2025 22:52:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none 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 CA3E4A64805; Sat, 10 May 2025 22:52:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1746917538; bh=pkJTAvv/dtaXuSYTDw3ekZ5zHbiPD1Xy0LE23YO+9JQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Em2Sg/gWq18qCByuPBktK1H+g6RcDQ+nbKkGhxjy3sHnMg3GzBohBMOI3VY2ME03c lfraGShSuMc7IYRnmuTZOJTgB8k4DwDopGTP2Xy7s3G86RLj2ueE5+IEvmsta3cdpq 362JUQ23SRz7y1mBCIbHz1/VdeClAiJPjnkOaxlKLGQvZtuF2EB7n60DrBdmyPeuSn pUL+XqJsMv/P5k7EXRVY0aI4fehBC62CDNcJDPTs91YGREFlkRLe9DVCFbEr4zub7F 0Kuqd1CmSxvJEt3eij6IuqSV6akvkN93W29+VDa62hkoqNkQNTumGuSMfgQSYJchco lboK8yj0DHEHpu4y3UQZCPMyw+7ZeT/BsHeq40Er9L6e9sLUmSEFa25hb1/KEpFEfv 0rhodcOfFL77O7NR/7vosmcdUqUdSStPKZoExFF6unM2vyjn/44qNaCvLXV0kE/M+e /QmKhORXQ7mh3/uJOj34HkfCaYl5IRBMVRbH2VDzksecRNAr8RB6m0hQEXtZ8YL0Rc 1G8yicbV8/pOopILmKPgsnWRnheNE64IJeMOOaR+KSUZIkFHLRPe02/C1bx9EAmClO ELxG+N/KHTrPK+W7gSXlZ64xqF5GqwaL5tCUT8Ib7xiTTcgHw9pIbfvBNBDYOajHKA 4ZqVV3cHZuDmoLO2B8mbPBhY= 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 77ED62D029E0; Sat, 10 May 2025 22:52:20 +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 97CjOtlvGYb8; Sat, 10 May 2025 22:52:18 +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 C36042D029D8; Sat, 10 May 2025 22:52:18 +0000 (UTC) Date: Sat, 10 May 2025 22:52:16 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: usb@freebsd.org, current@freebsd.org Subject: Re: panic in usb_detach_device / device_printf In-Reply-To: Message-ID: References: <9p19rsns-ro3r-so94-14p1-2s9p61377q73@yvfgf.mnoonqbm.arg> 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: multipart/mixed; boundary="1098556516-1388974905-1746917538=:4408" X-Rspamd-Queue-Id: 4Zw1NC2zjRz3bjj 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:3320, ipnet:2003::/19, country:DE] X-Spamd-Bar: ---- This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-1388974905-1746917538=:4408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 10 May 2025, Warner Losh wrote: > Yes. usb is hanky in its newbus integration and always has been. > > How did you get this to happen? I know that it can happen in some weird > error scenarios (that I've not been able to reproduce), but just removing the > device is orderly enough... > > But it looks like jhb's cleanup may have opened the issue back up, since > usb_detatch_device shouldn't find anything still attached. I'm guessing that > there are devices that are children of this node that are attached and also > somehow devices of the interface? > > So interesting crash, but without a lot more data about the usb configuration > and what device is being detached, I can't help you. Was a blind dump reboot on a ddb> prompt I didn't see. As said I moved the XHCI between bhyve passthru and the base system or the other direction. Seems xhci -> ppt. Unread portion of the kernel message buffer: ugen0.2: at usbus0 (disconnected) ugen0.3: at usbus0 (disconnected) ugen0.4: at usbus0 (disconnected) ugen0.5: at usbus0 (disconnected) ugen0.6: at usbus0 (disconnected) umass0: at uhub1, port 15, addr 5 (disconnected) da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: s/n 20120501030900000 detached pass1 at umass-sim0 bus 0 scbus1 target 0 lun 0 pass1: s/n 20120501030900000 detached (pass1:umass-sim0:0:0:0): Periph destroyed (da0:umass-sim0:0:0:0): Periph destroyed umass0: detached uhub1: detached ugen0.1: at usbus0 (disconnected) If I manually check the bt (the source tree has changed): #14 devclass_get_name (dc=0x7373616c63627573) at sys/kern/subr_bus.c:976 #15 device_get_name (dev=0xfffff8000158e700) at sys/kern/subr_bus.c:1908 #16 device_printf (dev=dev@entry=0xfffff8000158e700, fmt=0xffffffff81231211 "at %s, port %d, addr %d (disconnected)\n") at sys/kern/subr_bus.c:1998 (kgdb) p (*(devclass_t) 0x7373616c63627573) Cannot access memory at address 0x7373616c63627573 (kgdb) p (*(device_t) 0xfffff8000158e700) $3 = {ops = 0x6567753d6e656775, link = {tqe_next = 0x65646320312e306e, tqe_prev = 0x2e306e6567753d76}, devlink = {tqe_next = 0x726f646e65762031, tqe_prev = 0x203030303078303d}, parent = 0x3d746375646f7270, children = {tqh_first = 0x6420303030307830, tqh_last = 0x3d7373616c637665}, driver = 0x7665642039307830, devclass = 0x7373616c63627573, unit = 813183037, nameunit = 0x2022223d6d756e72 , desc = 0x3d657361656c6572 , busy = 825260080, state = 1830826032, devflags = 1030055023, flags = 1953722216, order = 1953392928, ivars = 0x646e6520303d6563, softc = 0x313d73746e696f70, props = { lh_first = 0x73616c63746e6920}, sysctl_ctx = {tqh_first = 0x6920393078303d73, tqh_last = 0x616c63627573746e}, sysctl_tree = 0x20303078303d7373} #17 0xffffffff8094ac63 in usb_detach_device_sub (udev=0xfffff800018b7000, ppdev=0xfffff80001595588, ppnpinfo=0xfffff800015955b8, flag=) (kgdb) p *(struct usb_device *)0xfffff800018b7000 $6 = .. 0x0 }, ugen_symlink = 0x0, ctrl_dev = 0xfffff8000189af40, pd_list = {slh_first = 0xfffff80001581180}, ugen_name = "ugen0.1", '\000' , plugtime = 2146883647, state = USB_STATE_DETACHED, speed = USB_SPEED_SUPER, refcount = 1, power = 0, langid = 1, autoQuirk = {0, 0, 0, 0, 0, 0, 0, 0}, address = 1 '\001', .. 0}, bufsize = 0, bufsize_max = 0, hc_max_frame_size = 0, hc_max_packet_size = 0, hc_max_packet_count = 0 '\000', speed = USB_SPEED_VARIABLE, dma_tag_max = 0 '\000', err = USB_ERR_NORMAL_COMPLETION}}}, data = "Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1", '\000' }} (kgdb) p/x *(device_t *)0xfffff80001595588 $7 = 0x0 (kgdb) p *(char *)0xfffff800015955b8 $8 = 0 '\000' #20 0xffffffff8094d24c in usb_free_device (udev=udev@entry=0xfffff800018b7000, flag=) (kgdb) p/x *(struct usb_device *)0xfffff800018b7000 $1 = .. (kgdb) p/x *$1->parent_dev $2 = {ops = 0xfffff800016e4000, link = {tqe_next = 0x0, tqe_prev = 0xfffff80001b63b30}, devlink = {tqe_next = 0xfffff80001b64200, tqe_prev = 0xfffff80001b64c18}, parent = 0xfffff80001b63b00, children = {tqh_first = 0x0, tqh_last = 0xfffff80001b64a30}, driver = 0xffffffff818952b8, devclass = 0xfffff8000170d680, unit = 0x0, nameunit = 0xfffff80001b87f30, desc = 0x0, busy = 0x0, state = 0x1e, devflags = 0x0, flags = 0x407, order = 0x0, ivars = 0xfffffe01051e0428, softc = 0x0, props = {lh_first = 0x0}, sysctl_ctx = {tqh_first = 0xfffff800018ac3a0, tqh_last = 0xfffff800018ac4c8}, sysctl_tree = 0xfffff80001b7f900} (kgdb) p (char *)$2->nameunit $6 = 0xfffff80001b87f30 "usbus0" (kgdb) p *(char *)$2->devclass $7 = 0 '\000' (kgdb) p/x *(device_t)$2->parent $8 = {ops = 0xfffff800016e3000, link = {tqe_next = 0xfffff80001b63a00, tqe_prev = 0xfffff80001b63c08}, devlink = {tqe_next = 0xfffff80001b63a00, tqe_prev = 0xfffff80001b63c18}, parent = 0xfffff80001b62100, children = {tqh_first = 0xfffff80001b64a00, tqh_last = 0xfffff80001b64a08}, driver = 0xffffffff81894d08, devclass = 0xfffff8000170d700, unit = 0x0, nameunit = 0xfffff80001b49140, desc = 0xffffffff81246094, busy = 0x0, state = 0x1e, devflags = 0x0, flags = 0x405, order = 0x0, ivars = 0xfffff80001b6f780, softc = 0xfffffe010505c000, props = {lh_first = 0x0}, sysctl_ctx = {tqh_first = 0xfffff800030a1880, tqh_last = 0xfffff800018ac668}, sysctl_tree = 0xfffff80001b50080} (kgdb) p (char *)$8->nameunit $10 = 0xfffff80001b49140 "xhci0" > Warner > > On Sat, May 10, 2025 at 1:36 PM Bjoern A. Zeeb > wrote: >> >> Hi, >> >> hit this twice when switching an XHCI from ppt0 back to xhci (or vice >> versa ?) on a previous kernel (sorry I hit 4 other panics and I don't >> have more details anymore). That kernel may have been 3-4 weeks old, >> so may be fixed by now? >> >> Fatal trap 9: general protection fault while in kernel mode >> cpuid = 0; apic id = 00 >> instruction pointer = 0x20:0xffffffff80b8d519 >> stack pointer = 0x28:0xfffffe01047d4c80 >> frame pointer = 0x28:0xfffffe01047d4dc0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 15 (usbus0) >> rdi: fffffe01047d4c88 rsi: ffffffff80ba9460 rdx: fffffe01047d4d18 >> rcx: 0000000000200000 r8: 0000000000000001 r9: 8080808080808080 >> rax: 7373616c63627573 rbx: ffffffff81231211 rbp: fffffe01047d4dc0 >> r10: fffff8000159d110 r11: ffffcfd1ced1cfd0 r12: fffff80001595580 >> r13: 0000000000000000 r14: fffff8000158e700 r15: fffffe01047d4c88 >> trap number = 9 >> panic: general protection fault >> cpuid = 0 >> time = 1746609904 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01047d4a00 >> vpanic() at vpanic+0x136/frame 0xfffffe01047d4b30 >> panic() at panic+0x43/frame 0xfffffe01047d4b90 >> trap_fatal() at trap_fatal+0x68/frame 0xfffffe01047d4bb0 >> calltrap() at calltrap+0x8/frame 0xfffffe01047d4bb0 >> --- trap 0x9, rip = 0xffffffff80b8d519, rsp = 0xfffffe01047d4c80, rbp = 0xfffffe01047d4dc0 --- >> device_printf() at device_printf+0x89/frame 0xfffffe01047d4dc0 >> usb_detach_device() at usb_detach_device+0xd3/frame 0xfffffe01047d4e00 >> usb_unconfigure() at usb_unconfigure+0x83/frame 0xfffffe01047d4e40 >> usb_free_device() at usb_free_device+0x15c/frame 0xfffffe01047d4e80 >> usb_bus_detach() at usb_bus_detach+0x6e/frame 0xfffffe01047d4eb0 >> usb_process() at usb_process+0xc5/frame 0xfffffe01047d4ef0 >> fork_exit() at fork_exit+0x7b/frame 0xfffffe01047d4f30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01047d4f30 >> --- trap 0x3a8d224b, rip = 0x91722c9d5743a0fe, rsp = 0xc95674b90f67f8da, rbp = 0x84eb42daceb9d67e --- >> KDB: enter: panic >> >> >> -- >> Bjoern A. Zeeb r15:7 >> > -- Bjoern A. Zeeb r15:7 --1098556516-1388974905-1746917538=:4408-- From nobody Sat May 10 22:54:00 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 4Zw1Q24ccrz5vyHQ for ; Sat, 10 May 2025 22:54:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zw1Q23jbbz3f2P for ; Sat, 10 May 2025 22:54:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none 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 36BB4A64805; Sat, 10 May 2025 22:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1746917639; bh=OdUBaZxS7ytnIiy98KEocYe5zW1A4sb/3m8367xnIyQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iI4o/+q7ieAxECqRrfTvFgnmh/ApvLZ6Ty+Hql1jPjNckr3RFuK61vybhEG3+/AXZ EiiCR4WVdnuSzO7WuR/WCGJRXKGHLyBHSmhJanGCw1xGzrFBEvWiGoISnK6LzeNMKG 3oQRH9hmJqZmxm7/3U1ox+CnG0KAUl6c2KF7TGsQQK4YEpyCGCVRkVymlS0ufjC2vm sW5XjEn+aphPmu9rs14RZks4xHAlsH8g8ZCQP51CNrDZA5CDIqpM6ZVKOxe5xoD1fm C3AXF9yWUkE1WY72udoEXh0uf/XHeZ+huzAxNXnHrXmfXHdVpDkVd9mjquVoljqD8B nvYMw1FUkcSmDUB7LGHmRnYJYom0t7rUjPLhlX1KPbVYO+Zp2fleWybULiAtE4Hx9m C/Nnpg3FaQYQ02sznnTnFeAtCULZVj0070nKTZFj+YNtHPi7Qp/ZBdKMjM3euldU28 OpBHRjbTr05gPcJQ65hvDhFDLcErrItmOZOe0rEfIyhH1tgpheyoVXWBD2xqSFKHtu bLij59hmnk6vWvsqwYayBhyXE+x5dvZr70dJ4W7798KiVl4zv2Lnuv2b/T1ZUwXjnV tSJo8JQ7uhIdoSEuW+wM/OXiOllJJOk5MGszKmgikf7A6XCG4PI9idFrK57UzvTZv3 V5f6FEd/42Wb1vAHSw8O1dPM= 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 EDD2A2D029E1; Sat, 10 May 2025 22:54:00 +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 3ch1vpzKn_YT; Sat, 10 May 2025 22:54:00 +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 3DAEF2D029E0; Sat, 10 May 2025 22:54:00 +0000 (UTC) Date: Sat, 10 May 2025 22:54:00 +0000 (UTC) From: "Bjoern A. Zeeb" To: Toomas Soome cc: FreeBSD Current Subject: Re: Loader goes to LINES=16 and kernel stays on that :( In-Reply-To: Message-ID: <2075n566-ns7o-9p76-n734-0911q87sn19q@yvfgf.mnoonqbm.arg> References: <067DD4B5-3EDA-40AC-B169-7A637C3CB129@me.com> <0n8p13rn-5o8r-959s-39r3-158ppspqs579@yvfgf.mnoonqbm.arg> 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; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Zw1Q23jbbz3f2P 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:3320, ipnet:2003::/19, country:DE] X-Spamd-Bar: ---- On Sun, 11 May 2025, Toomas Soome wrote: > > >> On 11. May 2025, at 00:31, Bjoern A. Zeeb wrote: >> >> On Sat, 10 May 2025, Toomas Soome wrote: >> >> [..] >>>> https://reviews.freebsd.org/D50258 >> [..] >> >>> It would be really nice if you could test it.Thanks, >>> Toomas >> >> On it; I'll reboot as soon as buildworld dedicded to rebuild half my obj >> despite only applied the one change. I thought on main this is all >> incremental these days. *sigh*. >> >> I assume there is no way to fix this manually as a user (change the settings >> from within loader) at least for the next stage (kernel)? >> >> I don't know much about all this; I tried vidcontrol later from the console >> to at least be able to read a few more lines only to get some ioctl errors. >> > > oh, yes, you can set font manually, set screen.font=16x32 for example. Only the autoselect with EDID data available was missing the check. manual selection and autoselect without EDID is ok. Well, thanks to D50258 I don't need to :) Worked. Thank you. Tested by: bz -- Bjoern A. Zeeb r15:7 From nobody Sun May 11 03:07:33 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 4Zw72p4KPxz5wDQK for ; Sun, 11 May 2025 03:07:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 4Zw72n6zjTz3RJ3 for ; Sun, 11 May 2025 03:07:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-30c7306890dso885457a91.1 for ; Sat, 10 May 2025 20:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1746932864; x=1747537664; 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=U26zlgLe0oQvuu3ZZo2FWf9El/25TRYZ4Xn0g3lrH5w=; b=fbwgadYbwn8Y3Hne8UwbfjQs56+pn64JRiCN4SLwXSsIDI0wGBfbke4XbMfMhtX8iY zDzPuVCqDz29EzOY7Nwi/V+W7PRimrQZLKxkdhDg4zS23dtAz9yTAlLYLgTrA/QJAwkr nrWcamyPIIfiH4aljSobJUZqXFs0L9KwC+S8gIr3qtySk0hnsPtpUEmeMIU7zwJZpKOc zWkWNxTSruZ3iAUDv0x2cXj7X5uV275X2bd+FxYe4WRnQo+rGdK8JgzJr7yJ3VeLxTvl h81bpVDj61s9g1lL3L1+hgMETbKDMUelFtIDZ5JMuJ5B692iIsu+SPUVz1YGqEqcWCso zISw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746932864; x=1747537664; 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=U26zlgLe0oQvuu3ZZo2FWf9El/25TRYZ4Xn0g3lrH5w=; b=CkIKfhbAOt8tFKxLKxB6fZ6QEc0+C9V6635eDwORoVh37rhhUNjLJh5VlFUwN4H9N7 LmnC6c6GtqjZig58gs+SHWUs8VHj0ek80ogRenN4xPuzEIKQiRem84RdW/Qz92pqa73v rJZBcv+yTeRIMfcHducERSdDVpHo7tvqWLQ2YvpZxEVVWRx9gdQgfTT5nH4wY3KvkEYn 5t5aQ6wzRgrzefygJx6vzYTMJoUGD1INbSjHv8iu/wsAfCKfYasLfVYwAu3IQ+WYTSIq 1LUqv+f5aOcJ7S+UyDurKZbLtE+PjWNLIZoomy5zYAt13oMiRNDXeN4vyWzY/B14YK4c 9LcQ== X-Forwarded-Encrypted: i=1; AJvYcCW6DcdXKlXsBC/n4j2y30B6D9YgBsPAuWjbmKwvfiqXN+f9m6JnI05Xp7VUareMPmXNhJcc04KH@freebsd.org X-Gm-Message-State: AOJu0Yxz+7h6hiuvSpGVF+48u3wfVhdCyfQJQtdY5FdB+cEWOgvKLRLW JaJ5zNhj+FoUICyYjWOOFyVo+DD43VX+3NzSF8d/YuMrlXAlyRXz+vVQNE92KA/0L24XLzyBAZh fXwOLIFWSbEyHGbFXdtoV4OIi1Mv137B12f1SNKiz4RCIlKQn X-Gm-Gg: ASbGncs+cbVmWVFCopUvgOJ7OJgWEjT6ZX5DJiCmJPu1n8jNOSZOMWWBrk2UAsxmniQ QDr141LNlcloubROUbnPhnUtOt3KeHGH+IzpLOFKBD/PWoyYocMjU8gXjzRZDP7mStaiYMKyZUm e5b/YpAsVA9e30WzYymFigwXcHaVLtnKSF/lDUrv62UFM= X-Google-Smtp-Source: AGHT+IGUeD+jjzZu4X+QORj+ngBRI+w+lSNq9bJeWMfTjW12ykzHhY6uHEuWG4EPby0p+6r1b70cUr5TIgYrs/SYx1E= X-Received: by 2002:a17:90b:2fd0:b0:2ee:8ea0:6b9c with SMTP id 98e67ed59e1d1-30c3d0eac6amr17448158a91.12.1746932864298; Sat, 10 May 2025 20:07:44 -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: <9p19rsns-ro3r-so94-14p1-2s9p61377q73@yvfgf.mnoonqbm.arg> In-Reply-To: From: Warner Losh Date: Sat, 10 May 2025 21:07:33 -0600 X-Gm-Features: AX0GCFvDumLSldVPTcxKrLKUhpClODimaW5-RpvtY6Dm-JIJVktNI7dHyfKZFR0 Message-ID: Subject: Re: panic in usb_detach_device / device_printf To: "Bjoern A. Zeeb" Cc: usb@freebsd.org, current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Zw72n6zjTz3RJ3 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-Spamd-Bar: ---- OK. Sorry for the top post. I need to recreate this because this data is already freed and corrupted. So is this panic in bhyve? What's the bhyve configuration you are using? You say this happens as you move the xhci pass through device back to the host. Does the same thing happen if you instead devctl detach the xhciX the device instead? It looks like you have a da0 device on the usb bus, any others? I need a way to reproduce it, and I kinda get what you're doing, but step by step instructions would be way better... And it may be a week before I get to it: my daughter is graduating next Friday, so my whole routine and schedule is off. Warner On Sat, May 10, 2025 at 4:52=E2=80=AFPM Bjoern A. Zeeb wrote: > > On Sat, 10 May 2025, Warner Losh wrote: > > > Yes. usb is hanky in its newbus integration and always has been. > > > > How did you get this to happen? I know that it can happen in some weird > > error scenarios (that I've not been able to reproduce), but just removi= ng the > > device is orderly enough... > > > > But it looks like jhb's cleanup may have opened the issue back up, sinc= e > > usb_detatch_device shouldn't find anything still attached. I'm guessing= that > > there are devices that are children of this node that are attached and = also > > somehow devices of the interface? > > > > So interesting crash, but without a lot more data about the usb configu= ration > > and what device is being detached, I can't help you. > > Was a blind dump reboot on a ddb> prompt I didn't see. > > As said I moved the XHCI between bhyve passthru and the base system or > the other direction. Seems xhci -> ppt. > > Unread portion of the kernel message buffer: > ugen0.2: at usbus0 (disconnected) > ugen0.3: at usbus0 (disconnected) > ugen0.4: at usbus0 (disc= onnected) > ugen0.5: at usbus0 (disconnected) > ugen0.6: at usbus0 (disconnected) > umass0: at uhub1, port 15, addr 5 (disconnected) > da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 > da0: s/n 20120501030900000 detached > pass1 at umass-sim0 bus 0 scbus1 target 0 lun 0 > pass1: s/n 20120501030900000 detached > (pass1:umass-sim0:0:0:0): Periph destroyed > (da0:umass-sim0:0:0:0): Periph destroyed > umass0: detached > uhub1: detached > ugen0.1: at usbus0 (disconnected) > > If I manually check the bt (the source tree has changed): > > #14 devclass_get_name (dc=3D0x7373616c63627573) at sys/kern/subr_bus.c:97= 6 > #15 device_get_name (dev=3D0xfffff8000158e700) at sys/kern/subr_bus.c:190= 8 > #16 device_printf (dev=3Ddev@entry=3D0xfffff8000158e700, fmt=3D0xffffffff= 81231211 "at %s, port %d, addr %d (disconnected)\n") at sys/kern/subr_bus.c= :1998 > > (kgdb) p (*(devclass_t) 0x7373616c63627573) > Cannot access memory at address 0x7373616c63627573 > (kgdb) p (*(device_t) 0xfffff8000158e700) > $3 =3D {ops =3D 0x6567753d6e656775, link =3D {tqe_next =3D 0x65646320312e= 306e, tqe_prev =3D 0x2e306e6567753d76}, devlink =3D {tqe_next =3D 0x726f646= e65762031, tqe_prev =3D 0x203030303078303d}, parent =3D 0x3d746375646f7270,= children =3D {tqh_first =3D 0x6420303030307830, tqh_last =3D 0x3d7373616c6= 37665}, driver =3D 0x7665642039307830, devclass =3D 0x7373616c63627573, uni= t =3D 813183037, nameunit =3D 0x2022223d6d756e72 , desc =3D 0x3d657361656c6572 , busy =3D 825260080, state = =3D 1830826032, devflags =3D 1030055023, flags =3D 1953722216, order =3D 19= 53392928, ivars =3D 0x646e6520303d6563, softc =3D 0x313d73746e696f70, props= =3D { lh_first =3D 0x73616c63746e6920}, sysctl_ctx =3D {tqh_first =3D 0x69= 20393078303d73, tqh_last =3D 0x616c63627573746e}, sysctl_tree =3D 0x2030307= 8303d7373} > > > #17 0xffffffff8094ac63 in usb_detach_device_sub (udev=3D0xfffff800018b700= 0, ppdev=3D0xfffff80001595588, ppnpinfo=3D0xfffff800015955b8, flag=3D) > (kgdb) p *(struct usb_device *)0xfffff800018b7000 > $6 =3D > .. > 0x0 }, ugen_symlink =3D 0x0, ctrl_dev =3D 0xfffff= 8000189af40, pd_list =3D {slh_first =3D 0xfffff80001581180}, ugen_name =3D = "ugen0.1", '\000' , > plugtime =3D 2146883647, state =3D USB_STATE_DETACHED, speed =3D USB_S= PEED_SUPER, refcount =3D 1, power =3D 0, langid =3D 1, autoQuirk =3D {0, 0,= 0, 0, 0, 0, 0, 0}, address =3D 1 '\001', > .. > 0}, bufsize =3D 0, bufsize_max =3D 0, hc_max_frame_size =3D = 0, hc_max_packet_size =3D 0, hc_max_packet_count =3D 0 '\000', speed =3D US= B_SPEED_VARIABLE, dma_tag_max =3D 0 '\000', > err =3D USB_ERR_NORMAL_COMPLETION}}}, data =3D "Intel XHCI roo= t HUB, class 9/0, rev 3.00/1.00, addr 1", '\000' }} > (kgdb) p/x *(device_t *)0xfffff80001595588 > $7 =3D 0x0 > (kgdb) p *(char *)0xfffff800015955b8 > $8 =3D 0 '\000' > > #20 0xffffffff8094d24c in usb_free_device (udev=3Dudev@entry=3D0xfffff800= 018b7000, flag=3D) > (kgdb) p/x *(struct usb_device *)0xfffff800018b7000 > $1 =3D .. > (kgdb) p/x *$1->parent_dev > $2 =3D {ops =3D 0xfffff800016e4000, link =3D {tqe_next =3D 0x0, tqe_prev = =3D 0xfffff80001b63b30}, devlink =3D {tqe_next =3D 0xfffff80001b64200, tqe_= prev =3D 0xfffff80001b64c18}, parent =3D 0xfffff80001b63b00, children =3D {= tqh_first =3D 0x0, tqh_last =3D 0xfffff80001b64a30}, driver =3D 0xffffffff8= 18952b8, devclass =3D 0xfffff8000170d680, unit =3D 0x0, nameunit =3D 0xffff= f80001b87f30, desc =3D 0x0, busy =3D 0x0, state =3D 0x1e, devflags =3D 0x0,= flags =3D 0x407, order =3D 0x0, ivars =3D 0xfffffe01051e0428, softc =3D 0x= 0, props =3D {lh_first =3D 0x0}, sysctl_ctx =3D {tqh_first =3D 0xfffff80001= 8ac3a0, tqh_last =3D 0xfffff800018ac4c8}, sysctl_tree =3D 0xfffff80001b7f90= 0} > (kgdb) p (char *)$2->nameunit > $6 =3D 0xfffff80001b87f30 "usbus0" > (kgdb) p *(char *)$2->devclass > $7 =3D 0 '\000' > (kgdb) p/x *(device_t)$2->parent > $8 =3D {ops =3D 0xfffff800016e3000, link =3D {tqe_next =3D 0xfffff80001b6= 3a00, tqe_prev =3D 0xfffff80001b63c08}, devlink =3D {tqe_next =3D 0xfffff80= 001b63a00, tqe_prev =3D 0xfffff80001b63c18}, parent =3D 0xfffff80001b62100,= children =3D {tqh_first =3D 0xfffff80001b64a00, tqh_last =3D 0xfffff80001b= 64a08}, driver =3D 0xffffffff81894d08, devclass =3D 0xfffff8000170d700, uni= t =3D 0x0, nameunit =3D 0xfffff80001b49140, desc =3D 0xffffffff81246094, bu= sy =3D 0x0, state =3D 0x1e, devflags =3D 0x0, flags =3D 0x405, order =3D 0x= 0, ivars =3D 0xfffff80001b6f780, softc =3D 0xfffffe010505c000, props =3D {l= h_first =3D 0x0}, sysctl_ctx =3D {tqh_first =3D 0xfffff800030a1880, tqh_las= t =3D 0xfffff800018ac668}, sysctl_tree =3D 0xfffff80001b50080} > (kgdb) p (char *)$8->nameunit > $10 =3D 0xfffff80001b49140 "xhci0" > > > > Warner > > > > On Sat, May 10, 2025 at 1:36=E2=80=AFPM Bjoern A. Zeeb > > wrote: > >> > >> Hi, > >> > >> hit this twice when switching an XHCI from ppt0 back to xhci (or vice > >> versa ?) on a previous kernel (sorry I hit 4 other panics and I don't > >> have more details anymore). That kernel may have been 3-4 weeks old, > >> so may be fixed by now? > >> > >> Fatal trap 9: general protection fault while in kernel mode > >> cpuid =3D 0; apic id =3D 00 > >> instruction pointer =3D 0x20:0xffffffff80b8d519 > >> stack pointer =3D 0x28:0xfffffe01047d4c80 > >> frame pointer =3D 0x28:0xfffffe01047d4dc0 > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >> current process =3D 15 (usbus0) > >> rdi: fffffe01047d4c88 rsi: ffffffff80ba9460 rdx: fffffe01047d4d18 > >> rcx: 0000000000200000 r8: 0000000000000001 r9: 8080808080808080 > >> rax: 7373616c63627573 rbx: ffffffff81231211 rbp: fffffe01047d4dc0 > >> r10: fffff8000159d110 r11: ffffcfd1ced1cfd0 r12: fffff80001595580 > >> r13: 0000000000000000 r14: fffff8000158e700 r15: fffffe01047d4c88 > >> trap number =3D 9 > >> panic: general protection fault > >> cpuid =3D 0 > >> time =3D 1746609904 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01= 047d4a00 > >> vpanic() at vpanic+0x136/frame 0xfffffe01047d4b30 > >> panic() at panic+0x43/frame 0xfffffe01047d4b90 > >> trap_fatal() at trap_fatal+0x68/frame 0xfffffe01047d4bb0 > >> calltrap() at calltrap+0x8/frame 0xfffffe01047d4bb0 > >> --- trap 0x9, rip =3D 0xffffffff80b8d519, rsp =3D 0xfffffe01047d4c80, = rbp =3D 0xfffffe01047d4dc0 --- > >> device_printf() at device_printf+0x89/frame 0xfffffe01047d4dc0 > >> usb_detach_device() at usb_detach_device+0xd3/frame 0xfffffe01047d4e00 > >> usb_unconfigure() at usb_unconfigure+0x83/frame 0xfffffe01047d4e40 > >> usb_free_device() at usb_free_device+0x15c/frame 0xfffffe01047d4e80 > >> usb_bus_detach() at usb_bus_detach+0x6e/frame 0xfffffe01047d4eb0 > >> usb_process() at usb_process+0xc5/frame 0xfffffe01047d4ef0 > >> fork_exit() at fork_exit+0x7b/frame 0xfffffe01047d4f30 > >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01047d4f30 > >> --- trap 0x3a8d224b, rip =3D 0x91722c9d5743a0fe, rsp =3D 0xc95674b90f6= 7f8da, rbp =3D 0x84eb42daceb9d67e --- > >> KDB: enter: panic > >> > >> > >> -- > >> Bjoern A. Zeeb r15= :7 > >> > > > > -- > Bjoern A. Zeeb r15:7 From nobody Sun May 11 08:45: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 4ZwGXc4FW9z5wXpt; Sun, 11 May 2025 08:45:36 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZwGXc1vQ6z3nmT; Sun, 11 May 2025 08:45:36 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=EPmIxHNF; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 54B8jSH8087319 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 11 May 2025 10:45:28 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1746953129; bh=wIq4JHjPcBjJV9J5pOCdGcum1qlX5IesL/sJ3rx92X8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=EPmIxHNFGhT0Pw6Odbb9yl22vp1kB0xQ/44u+e8u1AmZxto65Wm4fMjhOSjy5pxDd RX4bGgQ8mFz5QA8X7U7qxqDm4eeiaeoyGpIefoXFVsATeOmyaWan8Ag0uLsxq06s54 cQXLBLvTfjw0HXN5Uq8ZGl6c8eal+5e9REv1dC/cnBinsSOYhJZbtkAfZmTeRuYStq XlmrFD+70t4hF4+4InKw7bcXVouLKQASJ3lyPvqhHLeKYc1kTCJIPgGMYf2wdYq13q gPayepP7FEloxYoiZZFI+wx9I7SzZIYUS/F1IWX/aFbeYmJ+bxDSwND/GX1KSEvUuI 0Kru5+lr2acqg== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Content-Type: multipart/alternative; boundary="------------DXZkO9hGmrQKNq0rfiBEIQbF" Message-ID: Date: Sun, 11 May 2025 10:45:27 +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 , Guido Falsi Cc: 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 From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <1699210246.52160.1744195886991@localhost> X-Rspamd-Queue-Id: 4ZwGXc1vQ6z3nmT X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.03 / 15.00]; RSPAMD_URIBL(4.50)[pwste.edu.pl:email]; DWL_DNSWL_MED(-2.00)[pwste.edu.pl:dkim]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; NEURAL_SPAM_MEDIUM(0.23)[0.231]; RCVD_IN_DNSWL_MED(-0.20)[2001:678:618::40:from]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; BAD_REP_POLICIES(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[net@FreeBSD.org,freebsd-current@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(0.00)[+mx:c]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[plan-b.pwste.edu.pl,quarantine]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_XAW(0.00)[] This is a multi-part message in MIME format. --------------DXZkO9hGmrQKNq0rfiBEIQbF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 9.04.2025 o 12:51, Ronald Klop pisze: > 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. I ran several tests in VNET jails to evaluate the combined behavior of D49681 and D50108. Based on the results, I concluded that since the logic is implemented entirely in the kernel, only the host system’s |hostid| has an effect. This means that cloned or copied jails using interfaces with different names will not interfere with each other. However, if multiple jails are running on the same host and use the same internal interface names, they will be affected by this behavior. Cheers Marek > > *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 > ------------------------------------------------------------------------ > > --------------DXZkO9hGmrQKNq0rfiBEIQbF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
W dniu 9.04.2025 o 12:51, Ronald Klop pisze:
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.

I ran several tests in VNET jails to evaluate the combined behavior of D49681 and D50108. Based on the results, I concluded that since the logic is implemented entirely in the kernel, only the host system’s hostid has an effect. This means that cloned or copied jails using interfaces with different names will not interfere with each other. However, if multiple jails are running on the same host and use the same internal interface names, they will be affected by this behavior.

Cheers

Marek


 

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>
 

 
--------------DXZkO9hGmrQKNq0rfiBEIQbF-- From nobody Sun May 11 11:29: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 4ZwL9t2TsPz5vlG5; Sun, 11 May 2025 11:29:38 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 4ZwL9s0WTZz3tpp; Sun, 11 May 2025 11:29:37 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=aCc2vKmu; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=grahamperrin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-43cec5cd73bso23610835e9.3; Sun, 11 May 2025 04:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746962974; x=1747567774; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+pKW4qseZUEeseHEeEDRJnClUJZsbj9ZW1Zs8lVKO0k=; b=aCc2vKmun66+9JuE+5yYy3VLPtTIsVt6l647DIeMXc6UCjkrPEFs5C84m8eNS9mT9y Yx36nAeE8honNwAMzBOdpnvJHuqnsKJLz7O1Iex0IQzys+nP1iIvO7Xkwy9HoCafyfmH DVPZ4Yvc7YBvdS/otDUw9aTA9OWJkpgf9+bmc7qFgmqRtXu9b9V+6wuEfE98rFwoJ92q XXgKebj76Ewwdola6/BOhZxuVF8a6o7lMveQC9vmEKNHdyCbQ5DJD8mfh/Solrxg0KX5 pYEdV5b5qpbiC3qPN+yMFJ8YhCTKGOsAEf5hPO6jQgNvPCCJEaMLlmPNV2WT5Nz7ELCZ NUgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746962974; x=1747567774; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+pKW4qseZUEeseHEeEDRJnClUJZsbj9ZW1Zs8lVKO0k=; b=BvqyzNpJ8h8uJzdYqIU6J4hX4sqlKsVtYGwhlEkMyWfSok5fbCzNTZPiozw58Tg8VE r/ZIPtnPI1lLHl907a6R7RCOgEp2APh8oP/EpN1yuCVpzcA0OUIaVN50kYphmEqVyZ+L ojuQohSsFLlGNwfhoyq+RojCxSwz7befw9Ne13TIhBWLebY+MmVKjF40ZUhXI6rn2QS/ k/ypxD/JM9jtFzunhSuVsMoqPEeIb6gzL0+Y8V2vePZNFXv9rK7oOZu611C+YFffqCVt qZWzrHPT+ekrPtLFVU00aCi6pbkCHtYwdW8WPcPBpr0F0qZNheMXuJB3OiZGgtswnAKq xwww== X-Gm-Message-State: AOJu0YwrZ59gdCtulvle9grWNuQIFeEN72vsnUCnZiQFh7L/68gqTKz7 fDc7Uk3KQD9vl1iM3AFfqAaxAUam5KWyfH75+j6AS+dt5t5lkJHhwiaUhg== X-Gm-Gg: ASbGncv/UR64ImwUg4iozVuxox5GOfoVXQZTtTcOW1MWsHLdClbVymLzSWB6q4uLLwo /RqU3fvpYva5/+6n87OKhrv2EBo/UH8x98Rm2xlXGAXderjU6hpbc43lMy5xe4t+e37uBtGbyuc /YBCzjvWakkDip0XdCGf4JDG+4JRtIaSOaXiOyPbf4o6/3Yd2/b/uqfCNN2ccHTqxpYuLUrfrWf sAztkmJ0WKuoSB2Pesa0z9ltrFMsNY8UMQoBY4Bo8uSkneVjV+eUtsTKOLar2Xa181N9ZormTP3 9D5GiG1inXWbUIKQ8QRq2thSxfwt+NdbwzBxwZnYwkhWQZrEUKnHRICJ07hQ7YcZ7mr4Y8y5RXx eXUVs1S+k X-Google-Smtp-Source: AGHT+IEA7OmX+Vn4Wx0YWX2h7XlaniNt4YMBz3C7HYI1zliRcYXHkv4jc1m5lgvfA120fi5N3KTM7w== X-Received: by 2002:a05:600c:609a:b0:442:c98e:79ab with SMTP id 5b1f17b1804b1-442d6d37991mr89121175e9.9.1746962973890; Sun, 11 May 2025 04:29:33 -0700 (PDT) Received: from [192.168.1.10] (host-83-67-212-99.as13285.net. [83.67.212.99]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a1f5a2d30asm8967737f8f.76.2025.05.11.04.29.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 May 2025 04:29:33 -0700 (PDT) Message-ID: Date: Sun, 11 May 2025 12:29:32 +0100 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: Installer, before exit: /bin/tcsh for pkg To: freebsd-current@freebsd.org Cc: freebsd-pkgbase@freebsd.org References: <86a57t3cfu.fsf@asn.ftfl.ca> <688e37e4-3d6d-4e5d-ad47-9d1156d50330@gmail.com> <865xi9u4af.fsf@ltc.des.dev> Content-Language: en-GB From: Graham Perrin Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJimMMBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQLbHAQAJi998y42bEbq5HmABYovmAEtQj33YSUWyc9QRmAHpN8Er3lTKsgmZcVChB5Fu/d go2oYynDjlVpA7+wiSmg4AG78mOYbg/e19XMhrH0keDKqZXFkU+G7agR0mF09qvpQZ9MTJYZ 2u7FtytZK665UfipOdV8eGn2hFC/WynjUwEzKyryBgbbLAEbfOPeZNry4h2ZPWbtTvx/PE/V X3Vh2oGqYx69DCGz+0xEhy62ZKbkX5SL8LUf/1WViyCVzsHasFxmFxYPWIfBy8ayQ7xapz7M cSXSQyu4oDT4qh9eZiGP9/aAcZKHcV6t9y77JGhUJ/5O1sANKMa3YhgimE+Z86LHYa1IH774 PHj1nAXBwS+Cj/1l/NQoQcyjvOj8zuCsMJVaLMb6B46YsReP4+3yBLpyeBC//t6zWPbgAkWW VjROC0dXUAMTFpnA6NZe3UghG+Nc4fnCLGOhc2nyWFYHIaYV6Hv1ITFSem9DdeNnR1CFm1VM TJ7i7TuqYM+WZTkoUsTf4c46hS/ZNJZSCxh0s9yYr+BYk3XBbd+ElaZ1dJE6cuSVdw15+P2h DnprurxC4byl4YFkn+UAVvQsOgeq6aSHLOHX0weYu1OLoiPYsTdyGhne72+kDhEEdFD5aHdQ PFrbQIrqWLV0a04++0ZwGpNvXtgnWhDdAQJDwGsSSwbLzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmKYt7ACGwwFCQWjmoAACgkQt2dIb0oY1Av7qg//YjCZg8VXyMzXssgIQpROKKqh5V0UBSQl rM3tq4tWhyg0HVMugQj0Om+iNPsEEOGHkm6tyhHMzlKGpAc/l0iAM+8twIyg44Yo5+DcfFXr OMTbTw9T9jDsWOkOBksxy29iYhgpqpWdDBnhXvrJp/FNAiX8CfzrIOZeFPydDoEiKBEXAxfe a9o5J/JeVnZiUeoiFe7i68nZGsb4JxhPczNfqW12t0Ll5/ibjszg5BgjXiLao0KqbWNh4bS5 CVwH90Or+5qqWgzWPeBiuz+rN2QXE/V/fL44GEj1YKASCqmaiYRgjoRFubz1aq1wCXMXY3Iq d4525rscUgS7HBxbblnyTodUPaamN/2nSzcmE/Pkx8MApDSgZCIhs0RTAg+/AoX4HULV1rSE TQwMrBEQt84Tw5W5rHsvXKr4ZEsJUpbPLWYTISsp23nHR+vZtL/Ug+OWCmHC7X7D21xk/xVJ 4sA1RLJBKdCHtnyA4Unv/kNS1KVGxHnITVyw1a71QJADu4qsdtM5u6CyYUhqhM1oseWtV6j+ Qi8KC/G4C3AgZf06fe2fVl42z2grTabL4bC6FQXMwTX2dsm5NakWjUCmUL8uwsQE7ZA4zKxo EYI1YV9q1birpzncYRupr1qnMoggMUHWq0IBYshFQrEO8PeVUZBw7/GfAeh3argdw2Qu748T Cyw= In-Reply-To: <865xi9u4af.fsf@ltc.des.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4ZwL9s0WTZz3tpp X-Spamd-Bar: + X-Spamd-Result: default: False [1.62 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.999]; NEURAL_SPAM_MEDIUM(0.93)[0.934]; NEURAL_SPAM_SHORT(0.68)[0.683]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkgbase@freebsd.org]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; FREEFALL_USER(0.00)[grahamperrin]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32a:from]; FROM_HAS_DN(0.00)[] On 09/05/2025 17:39, Dag-Erling Smørgrav wrote: > Ed Maste writes: >> It looks like nano's post-install/-deinstall requires print/indexinfo >> and it's not available. This doesn't appear to be directly related to >> /bin/sh, /bin/tcsh, or pkgbase. If you have concise reproduction >> steps, please submit a PR. > The nano package has a run-time dependency on indexinfo, so it's almost > certainly already present. The most likely explanation is that their sh > doesn't have ${LOCALBASE}/bin in PATH but tcsh does. > > DES Thanks 286722 – print/indexinfo: pkg with chroot during bsdinstall: /bin/sh/indexinfo: not found, pkg: POST-INSTALL script failed > Keyword regression, because the tcsh workaround is not effective with > FreeBSD 15.0-CURRENT. From nobody Sun May 11 12:35:20 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 4ZwMf10r87z5vqHJ for ; Sun, 11 May 2025 12:35:37 +0000 (UTC) (envelope-from eduardo@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 4ZwMf05FRQz3wy9 for ; Sun, 11 May 2025 12:35:36 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746966936; 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=idH7sAGt9LX13HxBV+nunNyKwKZT0+SQnsv7tlFnHzE=; b=mqb2OsKTLn5jeqRUzD2v8cWMZNWpayjwqPqd2vgq5+3g1JDK5vU5J7PLBYlFa6+FlbsnnZ kEPP4790LWF9y1lj/W8kD0jkAgC0G4ZdwBzShfAkmWheiULbjaFtgw/2Yea18dRqCxR3xp WG0PDbd2rsdGZKQSSuFO6+mZU0Ac1g5kXCsbeQhGj+Pap8rIKE9dQqgnR1VM7EMyzj3GfY 9zEbsIqcrWXr+XJbgnRaiaiXN8w+G8SuovOHCbDh3H/A9y2yJZKZ/jodp741d9+LXnrHig Uq5xtLYtzZW/5huZlnIj/L87XYZ3rb0SlKCk9PdH8/MQSjDmfPQl0FON8bFqAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746966936; 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=idH7sAGt9LX13HxBV+nunNyKwKZT0+SQnsv7tlFnHzE=; b=NhqzaU1CupwEqkiuUQ1/DYe+g8UYKJIlg69JG40r9HeopJ+9rdfL6stveJiD2Z7wUA4LHP QnroXM9SSt/kE7YPH/pTi/cJj3swzqqFbgX0zlc9/F2T1MLcZjxuZXI0XPluV3oMkzmJHF EveH9ksC9sq+bev7wAZxWtLJV7gdbmliUpbcQTxBrCfKLG32ViGnvqNbr2POE323iYPLq4 bAwcy6i+mbs4Gw9uRN/UW1toF950Qk1VtETKF6E9s11pcp4Y0hTbJuIs6mifg7eV7pbhKT hidTyY2JMLtz7gncoec3Fr8MEO0ediVMYqEqE4Z0D7XNEujc2OofwLv3DE3ArA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746966936; a=rsa-sha256; cv=none; b=pcHZ4IyUCUQzrkN6uCB0XInZQCKT8nMC4CxRkGVixUFd+rdRCNqCW+nXex1EYWjrNBPRDE bq1G4UjfLFslRO5tqlieWJHvg1/p/Z3MAWx5QUyhud0pUu9t/kgEwTfqZ0A5/Ae/8Kgzzl t+ciqdExxcPI7E96BTo8aFvwhi58XQ8r4do5rE9I7aTFWG+nVAA4DgamzGALfYxzFIk3gh tve5gvC9A9W0v3TurxzEfIN4cjS5WdBzkWRppBm6/b/Y37V9tw+ZdKdKlIjU/U+JHX3I1o W1p7iH2p0GFXTeNFq693RV7qOhTkVGfDxCHs29iINnFiT4YHIjU7OrCroPAgYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (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)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZwMf04lHYz1RSp for ; Sun, 11 May 2025 12:35:36 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-47745b4b9aaso6855121cf.0 for ; Sun, 11 May 2025 05:35:36 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCU8ITIURHOGgJdpzYU7/YHu2QJi+iuRHTvKXpxlL+optTYzGlQx6zxmhkSA/F7ZG9NpN/huQoRYUpmkOVUpa5A=@freebsd.org X-Gm-Message-State: AOJu0YxnNf79rl6LfcsA8TnawGyjNuWRgi4PnTq6yQyTRvl+F6okEieX MgvsEam6a6uzzVIbp+FThk8W0twyGX7bkK8oHF6CmQvFzXOltD6YluiIBpiWTj67p0k5hcbw0bL ylIGaHDV+0pNcM4+gSfocirghVrE= X-Google-Smtp-Source: AGHT+IECscAWh5tjyckeIYQ9pYRtwI1hbEbz+VVppvZeOcpHJnmqm9N6K+rEo1qekDGPCRKAPTlpMmVNp2t04NFmVYU= X-Received: by 2002:a05:622a:14e:b0:477:5f29:dbc9 with SMTP id d75a77b69052e-4945280128emr52658511cf.13.1746966931348; Sun, 11 May 2025 05:35:31 -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: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> <87401.1746562441@kaos.jnpr.net> <4ACBBC16-3BB6-436A-B0B1-A18F088B000E@yahoo.com> <4421.1746572832@kaos.jnpr.net> <2CA19E21-0F2F-465A-BE8E-81ACDEE42D23@yahoo.com> <10858.1746584427@kaos.jnpr.net> In-Reply-To: <10858.1746584427@kaos.jnpr.net> From: Nuno Teixeira Date: Sun, 11 May 2025 13:35:20 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFuplSRS0Oq4HPRwmuCuVGQEbt6Hnd_pmKJk8wlqY3Q8xAv6ItinsXRi5rA Message-ID: Subject: Re: incremental bulds from scratch with beinstall.sh To: "Simon J. Gerraty" Cc: Mark Millard , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000060a6d80634db6f91" --00000000000060a6d80634db6f91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello! Is any progress going on? I can do some testing on my side too. Thanks, Simon J. Gerraty escreveu (quarta, 7/05/2025 =C3=A0(s) 03= :21): > Mark Millard wrote: > > > I think you could use something like this, which should be safe to > > > commit: > > > > I do not have a commit bit. Should I submit a bugzilla > > entry or something for its eventual commit? > > That's ok. Confirm it works for you and I'll see if I can break > anything with it > > > > > > diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk > > > index 708559edcdb8..e4fe3fa9a2aa 100644 > > > --- a/share/mk/src.sys.obj.mk > > > +++ b/share/mk/src.sys.obj.mk > > > @@ -73,6 +73,12 @@ OBJROOT:=3D ${OBJROOT:H:tA}/${OBJROOT:T} > > > .endif > > > # Must export since OBJDIR will dynamically be based on it > > > .export OBJROOT SRCTOP > > > +# if we didn't get SB_OBJROOT from env, > > > +# it is handy to set it now, so we can remember it > > > +.if empty(SB_OBJROOT) > > > +SB_OBJROOT:=3D ${OBJROOT} > > > +.export SB_OBJROOT > > > +.endif > > > .endif > > > > > > .if ${MK_DIRDEPS_BUILD} =3D=3D "no" > > > > > > You can then use ${SB_OBJROOT} in your .MAKE.META.IGNORE_PATHS > > > The difference is that nothing in the FreeBSD build should ever touch > > > SB_OBJROOT so it should meet your need. > > > I think ;-) > > > > > > And the above won't break our builds - which set SB_OBJROOT > > > before running make. > > > > Looks to be working for both aarch64 and amd64 with > > ~/src.configs/make.conf as shown below. It is used > > in my environment's scripts via the make command > > line starting with: > > > > env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" > > You might be interesting in https://www.crufty.net/sjg/docs/sb-tools.htm > like what you are doing but on steroids ;-) > > --=20 Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org --00000000000060a6d80634db6f91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!

Is any progress going on?
I can do some testing on my side too.

Thanks,

Simon J. Gerraty <sjg@juniper.net> escreveu (quarta, 7/05/2025 =C3=A0(s) 03:21):<= br>
Mark Millard <= ;marklmi@yahoo.com> wrote:
> > I think you could use something like this, which should be safe t= o
> > commit:
>
> I do not have a commit bit. Should I submit a bugzilla
> entry or something for its eventual commit?

That's ok.=C2=A0 Confirm it works for you and I'll see if I can bre= ak
anything with it

>
> > diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk > > index 708559edcdb8..e4fe3fa9a2aa 100644
> > --- a/share/mk/src.sys.obj.mk
> > +++ b/share/mk/src.sys.obj.mk
> > @@ -73,6 +73,12 @@ OBJROOT:=3D ${OBJROOT:H:tA}/${OBJROOT:T}
> >=C2=A0 .endif
> >=C2=A0 # Must export since OBJDIR will dynamically be based on it<= br> > >=C2=A0 .export OBJROOT SRCTOP
> > +# if we didn't get SB_OBJROOT from env,
> > +# it is handy to set it now, so we can remember it
> > +.if empty(SB_OBJROOT)
> > +SB_OBJROOT:=3D ${OBJROOT}
> > +.export SB_OBJROOT
> > +.endif
> >=C2=A0 .endif
> >
> >=C2=A0 .if ${MK_DIRDEPS_BUILD} =3D=3D "no"
> >
> > You can then use ${SB_OBJROOT} in your .MAKE.META.IGNORE_PATHS > > The difference is that nothing in the FreeBSD build should ever t= ouch
> > SB_OBJROOT so it should meet your need.
> > I think ;-)
> >
> > And the above won't break our builds - which set SB_OBJROOT > > before running make.
>
> Looks to be working for both aarch64 and amd64 with
> ~/src.configs/make.conf as shown below. It is used
> in my environment's scripts via the make command
> line starting with:
>
> env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf"

You might be interesting in https://www.crufty.net/sjg/d= ocs/sb-tools.htm
like what you are doing but on steroids ;-)



--
Nuno Teixeira
=
FreeBSD UNIX:=C2=A0 <eduardo@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://Fr= eeBSD.org
--00000000000060a6d80634db6f91-- From nobody Sun May 11 14:49:15 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 4ZwQcS1nsDz5w05Z; Sun, 11 May 2025 14:49:28 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZwQcR4hVVz3QXM; Sun, 11 May 2025 14:49:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none 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 B583FA64805; Sun, 11 May 2025 14:49:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1746974957; bh=qPuh7t3lWSaT0CSg0aisS8aIqHgWaJ8G4yFY5QCJx88=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=D55RjH9qX//AWd0DBlU1c/yolFvesvSUVc1o4AnmuOJ9e2dAuo4ZgPCf04GlwsQsf LPkLHFqr25cYpjvlEAnSDkfogLjvD5cPuKF81DoWVrZTj2K8OYEgpSvPbvIs3VD7c9 Ta0EOtS+IrO1i7GsMfgHJJuMmbvU7ZS+LEpNuoEuaKJfBnhr+76Et1PXrFoXSJ8mWG 7T7D51eomsE72zDgPNC5pkvIlhvHNAMKJI7XCsG+zmz/lCabfwFcqAc1lxnGV1VO4x hO9SY6JuiB63fSfzt9nPwdcU2OgRJQm9fGplU1cfoZDsW/1RFECXG56PE8DiMZ2IwU OCRdAHUYY8jc8dJMUouyqK6b7sQ9b3HYT0wTm2xU0KII/Jkm6ABZ+z+CYguI0lG6gz OyFQ55ArkYsj4kqUY/xeQ7kLFam0zZftczs+HuH/E1vw32rE++/IlXshuv19I64LXs ks9R2yFCDdOtMFKUmGza4w5+nctRZ09sdVdpblHgJpnCx3P6l+rW68fMwF2XL2bc3E C1lz/bvxclnSnr0LXNAjiE8nVUW30YVeFpMx/ybca3CQW+zgisi9IoEjwaXj4DMNHs XBRS+C9b89vRjl6Phu1n/hXorEqL+0NgQaKWkMercpY3k84ua/5Xy9abW5sb7OzGKr W/9Gerwq+kyk72eMbaEPBgbk= 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 6B2432D029E0; Sun, 11 May 2025 14:49:19 +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 AeYF9dz3_B17; Sun, 11 May 2025 14:49:17 +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 4F0E52D029D8; Sun, 11 May 2025 14:49:16 +0000 (UTC) Date: Sun, 11 May 2025 14:49:15 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: usb@freebsd.org, current@freebsd.org Subject: Re: panic in usb_detach_device / device_printf In-Reply-To: Message-ID: <49292416-982q-388o-304r-46p050pns429@yvfgf.mnoonqbm.arg> References: <9p19rsns-ro3r-so94-14p1-2s9p61377q73@yvfgf.mnoonqbm.arg> 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; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4ZwQcR4hVVz3QXM 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:3320, ipnet:2003::/19, country:DE] X-Spamd-Bar: ---- On Sat, 10 May 2025, Warner Losh wrote: > OK. Sorry for the top post. > > I need to recreate this because this data is already freed and corrupted. > > So is this panic in bhyve? What's the bhyve configuration you are using? > You say this happens as you move the xhci pass through device back to > the host. Does the same thing happen if you instead devctl detach the xhciX > the device instead? It looks like you have a da0 device on the usb bus, any > others? "Seems xhci -> ppt" So this is on the base system moving the XHCI to ppt to be used in bhyve, otherwise it wouldn't detach all the USB devices but create them. I booted a non-FreeBSD guest. The da0 is created by a blank adapter in the ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (200mA) at scbus1 target 0 lun 0 (da0,pass1) There's no card there. But it's been like this for years; even before the reader was supported and I've done this regularly. > I need a way to reproduce it, and I kinda get what you're doing, but step > by step instructions would be way better... And it may be a week before > I get to it: my daughter is graduating next Friday, so my whole routine and > schedule is off. # pciconf -l pci0:0:20:0 xhci0@pci0:0:20:0: class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d2f subvendor=0x17aa subdevice=0x225d I cannot reproduce it anymore. history is gone sadly. I do not know what I typed anymore. My bhyve.sh has these as comments so I likely just pasted them when bhyve refused to start because of no ppt0 not being there already. # devctl detach pci0:0:20:0 || true # devctl set driver pci0:0:20:0 ppt || true /bz -- Bjoern A. Zeeb r15:7