From patchwork Thu Sep 24 17:28:44 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99193 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A297C98327 for ; Thu, 24 Sep 2026 17:29:09 +0000 (UTC) Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by mx.groups.io with SMTP id smtpd.msgproc01-g2.3761.1790270939747144749 for ; Thu, 24 Sep 2026 10:28:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=kKCuMqkt; spf=pass (domain: gmail.com, ip: 209.85.221.169, mailfrom: twoerner@gmail.com) Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-5c675e64ffcso995722e0c.0 for ; Thu, 24 Sep 2026 10:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270939; x=1790875739; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=m9Y+E1zLOrJprCblm/jWdeMBIX9yLHkcy7xQVhGkonk=; b=kKCuMqktS+d50CLoHOsS4Kx1WMaEW+2sbicy4+gj1AIGa66Zsa5fn3dscwArKPp48i eJMOzXjQUDomldJzp4yeNfqvoX1QFh0ej58Crq9mINjrPjOyGh+SB9f4HGjBgiIQuvxl uMo+vQwiPpC+DUXRt5f8YplvdoWDGZdo6CEdfKXh1g7vhmDzyx2t4gwSRN6pXxaDyzWu 48I8EmT/EMbpwE4p0iyGHpn2MbsCnqEkKvf+xJkJPE5SFkjyBNwsNwNi2HZPDwQLj6F0 VjRMba8aLF6pA9orkiB9yQBqvCH486ifCmJRK8TV7RImxF0U97kiu1zFe/qIYjxvqb5U VnIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270939; x=1790875739; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=m9Y+E1zLOrJprCblm/jWdeMBIX9yLHkcy7xQVhGkonk=; b=U7n4nPQqTs53RpfvpUtnjGiwoL4qeZB5LBDjeSlr87GLrK8oBl37h+txC8/OpKtLRg aeyzBcKHp0H38vl/gahJYxXfsr2qKbeGyWdiv/SFaFS4ie8dZEdbY1ia1btMaAxz89ok SVo85wuhq7cyRHKqTvIghUI8f1ooo63TMflkRMMvLtz7tGjbre4yoqtcAKFF+yvR/r97 gaCTVgE82upfkT1CSTdmkO5+VNahcCVn5cAWDR9K0z6+11YLBITi4m9D7meJ51s8ZqFZ CGE8zxUhJ0K9UnKrPS7hspX2JcSvL2i+nqZRVBsEXjNS7GbSsHzodVNHKFuGcoAwL+J5 r0yg== X-Gm-Message-State: AFuF++lee47JSGLjuIvFXlmFesjz/Q4NrTXcngXAe34s8x+DBi1ri4Zr 8a1hZHSHR5Ht3taq/sqd4c+VueY9G2PyzYAtVnn3lvmseF/dkpzU8bwd49lwSw== X-Gm-Gg: AYBFou0xX27YhY9g8/gm0i6Sc93SbJ8BgVyvZY6JoMF+H1qWU+n0wAD1gR+dxTHQnk8 OPkS/ptxxzCFP8lwQ+y/Vj9v+UUd4fbngTYHt3w2TQAm0IlrrXGwXCRyq0q3hF3GdLAxmByqABP irutePvqTzodIGFr4dx0GZnrpMU+I9tjuwlxWCN2sQSrf80N8/rQYtjL1NfIkSzUyEVWuS0W2yV AUG0L7/SUU7t+9/W3gnYGMgfcWCgDEduRppc236J+jssKx0TJS1klNMOEyacsRlhySfziFe3q3Z mP2HuVrBh8hjL8J6H5nh9ucArBzkInpCkzUJ9l6kRFQ98s01Rhj8M3SycpO3E4dGnbHdv8X1G1a F6Esm66X/ZB17z0dNzDIxtfFPfORK3Vq+SSatiQ0zwmqsZwE338r3Pi2IWaImiQ+UVe92sYsAnP +mfgBOmjK+x7P/oFpmd4jEdChDY5Ox/OYjeYVfP/nx1Xq+P/dbCHasjsxtTTDZVACKFUk0PO2Fm oeWgIJ62t+nwqtPnDb7bcQB/7Ud+Yi2QssxTEADd9xnWBGsY9Dhr4Fp4XHQeQ== X-Received: by 2002:a05:6102:3a6e:b0:7a1:f2b5:646d with SMTP id ada2fe7eead31-7af1fc21578mr921125137.42.1790270938638; Thu, 24 Sep 2026 10:28:58 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.28.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:28:57 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Cc: Quentin Schulz Subject: [PATCH v3 01/10] docs: give the root prompts a preamble Date: Thu, 24 Sep 2026 13:28:44 -0400 Message-ID: <20260924172853.2665062-2-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:09 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10624 A bare "#" starting a line is a root prompt, a comment, and a line of program output all at once, and nothing can tell them apart. Most root prompts in the manuals already carry a preamble naming the machine, and the stragglers are what make the distinction unreliable. Add the preamble the others already use: the machine the surrounding steps name, or a generic "machine" where they name none. AI-Generated: codex/claude-opus 5 (xhigh) Reviewed-by: Quentin Schulz Signed-off-by: Trevor Woerner --- changes in v3: - the kernel-dev "make scripts" block is prompted too, with its working directory in the second prompt changes in v2: - rebased on master-next - the SystemTap example uses a generic root@machine prompt; the two kernel-dev ones keep qemux86, which the surrounding steps name --- documentation/kernel-dev/common.rst | 8 ++++---- documentation/profile-manual/usage.rst | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index 2a65055e2a44..65bd3d0d1f46 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -722,7 +722,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio .. code-block:: none - # dmesg | less + root@qemux86:~# dmesg | less You should see the results of your ``printk`` statements as part of the output @@ -878,7 +878,7 @@ Section. .. code-block:: none - # dmesg | less + root@qemux86:~# dmesg | less You should see the results of your ``printk`` statements as part of the output when you scroll down the @@ -1554,8 +1554,8 @@ directory. Next, ``make`` the scripts: .. code-block:: none - # cd /usr/src/kernel - # make scripts + root@machine:~# cd /usr/src/kernel + root@machine:/usr/src/kernel# make scripts Because all SDK image recipes include ``dev-pkgs``, the ``kernel-dev`` packages will be installed as part of the SDK image and diff --git a/documentation/profile-manual/usage.rst b/documentation/profile-manual/usage.rst index dc34fa36c487..4efaa6d10fce 100644 --- a/documentation/profile-manual/usage.rst +++ b/documentation/profile-manual/usage.rst @@ -1801,7 +1801,7 @@ probe, you'd just install SystemTap on the system you want to probe, and directly run the probe on that system e.g. assuming the name of the file containing the above text is ``trace_open.stp``:: - # stap trace_open.stp + root@machine:~# stap trace_open.stp What SystemTap does under the covers to run this probe is 1) parse and convert the probe to an equivalent "C" form, 2) compile the "C" form From patchwork Thu Sep 24 17:28:45 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99196 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77FBBC98321 for ; Thu, 24 Sep 2026 17:29:09 +0000 (UTC) Received: from mail-vs2-f43.google.com (mail-vs2-f43.google.com [74.125.227.43]) by mx.groups.io with SMTP id smtpd.msgproc02-g2.3791.1790270942109989960 for ; Thu, 24 Sep 2026 10:29:02 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=QW/VZP1d; spf=pass (domain: gmail.com, ip: 74.125.227.43, mailfrom: twoerner@gmail.com) Received: by mail-vs2-f43.google.com with SMTP id ada2fe7eead31-78569cf871bso34304137.2 for ; Thu, 24 Sep 2026 10:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270941; x=1790875741; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=ZgknoNaeY1U6y4e9i/tOum1bSbLBHrd3kT3cn1m0yRo=; b=QW/VZP1db/+FzUutf7Uah0umPmVkM/3K8dv+QkXZE3O5CKVY5Ki0w6GdoGZqGf8lAh Sr4A3q7av6WiveMFxVFaVmzbovPGdPNQoVJml5c/JfXIL0Q4vuRwj94QyKz5iVcwee1B 9mYjd5QQf9/YOv/Unqm1EpwdZ6uMNk4Pbc8guiESE4xQTbnbixyv5Pt/IcyVmI6wMmjT aNPr3G4kwpi6ftZu2GeQNN8om93llaLnMQvof9kHwUiNk3MPX/fS2X/V2IphqyXR4+vr mOs6yc3nrY0tNpQO6zPv2VzU/YYHgBXd6Lwbuee81bu/OPhbjsH97fkcL0LSntLCDg5V 9RaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270941; x=1790875741; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=ZgknoNaeY1U6y4e9i/tOum1bSbLBHrd3kT3cn1m0yRo=; b=k+Po2OeVb6VgKg3l+H2vwR169JOHy0rg4G+Azi1g2uzTe6N2MzhSIcGFSM3RiytBWk Xn7H/04HI8nQdUVpVvBitzKXxuZ+WNfJ1vYXjKyNkzTEqHcZjh4o0mWl4Ma+XGfS8g6O NG1S7CDMdFbq+gcu9o1fqvT3PD+0RPXGzUN/l5MpJwrPwCyME8i/CtaoGwPXFg3jXtVr 50XL1kycxeT4UqL1mWzJqKEkaDqsL8L0t8EjxErRYul+b5/T+PZbnEpuwGUscauCzpPI eAEJr4CXrg9/3c3sFuwKe6BI7qiuIbDzt8MzYeij1C2p9KLcfJt84vUWAUh6EzWlJq4t 6JpQ== X-Gm-Message-State: AFuF++keM6Ra9+bLi5WipP5GtSFFAPhHo+3/nmPlMWEnpKm5qeUEAfaO dD4F2h7nZ6eSlaS4UyVlDvO6DllnMHZGdM46FUHI/Ef9hJwu7C0adIjKzmoJgw== X-Gm-Gg: AYBFou3wBlvnUSds/yrv4wUlFZFhvPuDNok51MS0ZYnZOVq8UdH8RNE2hpHAS1FG0xY qBH4LejSnDs0q9KwZHLiPd6N2WL1ga97O9mRqOdv+UF6VgJKkV7oEg1N2btV0T3RCJ8jl1X6CuF zbkh2QFNXXkRpfO0l3DT/i3EBIC5/Am554/MNSewK/CIzS6xMBbozABRTuN01IbveSbHORsc4hA PIu4itUdP3IMcM5nW3CK3GDBaf9RuBsTPmQuwKPiXSMMR4cvPdYbp0mdwJL7nVpkFG6JvvsxDcp GSaXp9koLGS0H1lB9AlcPT12O0k4pXWWRvG7TiHyB4BbM6gLFhXL7aiUZ26CFgrXYhPEJH1l8KT TQO5jFkYt7v36Ayq9bKdav1yGR0I3tIbGWYGvYVPCDK9WoFeAPGI/Dpwl7YjHi4wGcgzSJ0Y0Hh w8vUFjf43t8aDHCTjs7etV4rvfbs73Dl7MiOpOlvx/PZ+ZYiGpKfcGMW7db6/q01RLqgEZZ95TU NVU2ZSjY08woaO44EvdBjkRCrb1Jnf2IkqN6W25 X-Received: by 2002:a05:6102:358d:b0:79e:2b00:b4da with SMTP id ada2fe7eead31-7af1c692c06mr1815068137.6.1790270940164; Thu, 24 Sep 2026 10:29:00 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.28.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:28:59 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Subject: [PATCH v3 02/10] docs: copy only the command from a console block Date: Thu, 24 Sep 2026 13:28:45 -0400 Message-ID: <20260924172853.2665062-3-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:09 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10625 The copy button matches the literal "$ " prompt, so on a block prompted any other way it matches nothing and falls back to copying every line, prompt, and output included. Match a pattern covering each prompt shape the manuals use instead, so the button gives the command alone whatever the prompt looks like. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner --- changes in v3: - the comment is shorter and no longer contradicts itself about scope - a ">>> " alternative covers the one Python interpreter example - a "(gdb) " alternative. The console lexer already marks that prompt, so a selection skipped it while the button copied it; the two now agree changes in v2: - dropped the stylesheet change, so a mouse selection keeps the output - the comment now says this governs the copy button only, and only reaches a block the console lexer has read --- documentation/conf.py | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/documentation/conf.py b/documentation/conf.py index 48d28a686807..d2252d5ab966 100644 --- a/documentation/conf.py +++ b/documentation/conf.py @@ -242,4 +242,21 @@ intersphinx_mapping = { # -- sphinx_copybutton configuration ----------------------------------------- # sphinx-copybutton configuration -copybutton_prompt_text = "$ " +# Applies to the copy button only; a mouse selection is untouched. +# Not scoped to console blocks, so every alternative has to be safe in a +# BitBake or configuration example too. +# No rule for a bare "#": it opens a comment, a root prompt, and a +# line of program output alike. +copybutton_prompt_text = "|".join(( + r"^(?:\S+[@:]\S*)?\$\s+", # "$ ", and "user@host:~$ " + r"^\S+[@:]\S*#\s+", # "root@machine:~# ", a root prompt + r"^[A-Za-z]:\\[^>]*>\s*", # "C:\WINDOWS\system32>", cmd.exe + r"^DISKPART>\s*", # diskpart prints a prompt of its own + r"^pydevshell>\s+", # bitbake -c pydevshell + r"^>>> ", # a Python interpreter session + r"^\(gdb\)\s+", # a gdb session +)) +copybutton_prompt_is_regexp = True +copybutton_only_copy_prompt_lines = True +copybutton_remove_prompts = True +copybutton_line_continuation_character = "\\" From patchwork Thu Sep 24 17:28:46 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99192 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCDE2C9830E for ; Thu, 24 Sep 2026 17:29:08 +0000 (UTC) Received: from mail-ua2-f12.google.com (mail-ua2-f12.google.com [74.125.226.204]) by mx.groups.io with SMTP id smtpd.msgproc02-g2.3792.1790270944158086449 for ; Thu, 24 Sep 2026 10:29:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=P2qGOo1t; spf=pass (domain: gmail.com, ip: 74.125.226.204, mailfrom: twoerner@gmail.com) Received: by mail-ua2-f12.google.com with SMTP id a1e0cc1a2514c-97e7c72bfebso30751241.3 for ; Thu, 24 Sep 2026 10:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270943; x=1790875743; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=/c5GGU5m+4FGyjxwL8mzFplHZeH9+V77I+YDeOYKNQM=; b=P2qGOo1t4qvho5KwsFux/r/YeRCANA46Qi2VMOmCDocFAvYESLKlKPdslW+UisfRKh lCgSeeRRZE/FWBF+dQeS1ROcKx/2XjZHCEub+qh4RyeKrM/fn8NFfIxXUmqvlQ//YVhq 9fuCLFs8ZRHB6UNq39G8tzfsu16Vnwcnk3LdiXgwVnThQHKsUzgwreRrQFvtzTAWMQw6 4oUPEF+7Z9OKKwUDjtKSDOG+ABQpzA4XzmN4pgdt+bAAF37MB/+VlPV8/DH+MrgOAfDF TDVlUawVIhpa4CCAbvEP7VOYKeSnrTuy5vAWOAWbr6CmM2KtQtlmjQ7vi0wZmZf0P8aT 8jpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270943; x=1790875743; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=/c5GGU5m+4FGyjxwL8mzFplHZeH9+V77I+YDeOYKNQM=; b=fyuUe7poeLBfZAD/Tp3QXJEa+PkFAw87K+egiH2NM1jCVumVgx9eQuyJHNZvGPYagQ uf8TgVKeulX5pOs+a6QN0ORiqSnBax2gCB/3IjIRqKcUKjY3efe7fwtQQmZb+yVXQx8g GGNvxlPFFUrpJSf3WNwdM6BhSDxTzn20SAa0Emw/u+9kVp3ZYZG9ReCDZPlizeJLvIT4 dTDBAa3go5A9VCWszkU5Yaq16G2bsboUBE4+dMxc9lAlxP2FEztAYQJUnk1uXderVyGw Kkyo/XdHvqfwbl3ErgtWXPaoEbzAdBv/zneNKyLSOWomSd5CPpSOPSyAbipnR+4fysgR vJHg== X-Gm-Message-State: AFuF++mMOSJHdkomLVySIIqQNTIyn+jmcgbfWVUtpYpOMZpLdHDlmI4p am9O2EOSc8jWFDhxmqC2N6P3x3k+SGv5Rr25FuBfyOAv7nMr2V5ZVEKmVPxCVQ== X-Gm-Gg: AYBFou27kbamYUO1XRk98AGzEMmsaugP+z61cyly1I6tWYFOnBeYcPxjoFCKIRbz9hZ 5RmwSJHRWuHGmVBLSPbJh3rV2NK3mD2xlt7j26E4BygzcIjf/4cpQIbLj/PmL5U1MoStmHkqhqE ThjLoDtEcyQCFD3GRLVYWA8tC66jCd+KdLwnXaonhCzB5EkpriltQ5bYRgdc9spUA6r4WdcogFi 5hpgUBvJjx1CcCM1pUgraJUogF4nJg/siev7PALDWmVB+VdiSJuX0zYWrksF3b1WuJhCtUcWqDF VCAQ/LgScpgiKreUICknC1x8Dg2+1hBXYS0shHG/fx/GTYpN8ixbVbInjZ/QEk1xURvl9hkyVDF OOphIM39juU9ri6hojmT9vJn0T6dIhhJJXcZ51oOrlmluNDUYvoZ8cEm0U4nBtJxYbBrtBc8a38 qHj0+/ivqpvzLBe1Bt3u2zmeMX4p3CVNgS5BlVIBnuz4wSXZ6Y8Qt6IRbrBSMpV+7PLFuysRuZe Vd/ecRAc7ZbOMn0qk2vrTUroGI2qr28R26ANCwt X-Received: by 2002:a05:6102:2928:b0:7a7:198a:c2c7 with SMTP id ada2fe7eead31-7af1f3f672emr1380050137.37.1790270942082; Thu, 24 Sep 2026 10:29:02 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:01 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Subject: [PATCH v3 03/10] docs: show a prompt on commands the reader is meant to type Date: Thu, 24 Sep 2026 13:28:46 -0400 Message-ID: <20260924172853.2665062-4-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:08 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10626 Most command blocks in the manuals start their lines with "$", but a scattering of them do not, and those read as a file listing rather than as something to run. Give them the prompt the surrounding pages already use. Transcripts take a prompt on their opening line alone. Two removals go with it, because both only matter once a line is a command: a bare "$" at the end, which is the prompt returning after the command finished, and a trailing "\" on a Windows path, which a shell reads as a continuation into the output. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner --- changes in v3: - the weston command is prompted; it had none - commands run on the target take the full user@machine:path prompt, mirroring the root prompt, rather than a bare "$" changes in v2: - rebased on master-next; no other change --- documentation/brief-yoctoprojectqs/index.rst | 2 +- .../contributor-guide/recipe-style-guide.rst | 2 +- .../contributor-guide/submit-changes.rst | 60 +++++++++---------- .../dev-manual/creating-fragments.rst | 4 +- documentation/dev-manual/debugging.rst | 1 - documentation/dev-manual/devtool.rst | 8 +-- documentation/dev-manual/disk-space.rst | 4 +- documentation/dev-manual/hashequivserver.rst | 2 +- .../dev-manual/limiting-resources.rst | 2 +- documentation/dev-manual/new-recipe.rst | 6 +- documentation/dev-manual/packages.rst | 2 +- .../dev-manual/python-development-shell.rst | 1 - documentation/dev-manual/qemu.rst | 8 +-- documentation/dev-manual/start.rst | 2 +- documentation/dev-manual/wayland.rst | 8 +-- documentation/kernel-dev/common.rst | 3 - .../migration-guides/migration-2.1.rst | 4 +- .../migration-guides/migration-2.5.rst | 4 +- .../migration-guides/migration-4.0.rst | 2 +- .../migration-guides/migration-5.3.rst | 10 ++-- .../migration-guides/release-notes-4.2.rst | 2 +- .../migration-guides/release-notes-5.3.rst | 2 +- documentation/ref-manual/classes.rst | 8 +-- .../ref-manual/devtool-reference.rst | 2 - documentation/ref-manual/fragments.rst | 16 ++--- documentation/ref-manual/qa-checks.rst | 4 +- documentation/ref-manual/variables.rst | 6 +- .../test-manual/reproducible-builds.rst | 2 +- documentation/test-manual/runtime-testing.rst | 4 +- 29 files changed, 87 insertions(+), 94 deletions(-) diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index f7e4606f1f7b..e138df6c9351 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -373,7 +373,7 @@ layer>`: First, clone the layer next to the other layers:: - git clone -b &DISTRO_NAME_NO_CAP; https://git.yoctoproject.org/meta-raspberrypi ../layers/meta-raspberrypi + $ git clone -b &DISTRO_NAME_NO_CAP; https://git.yoctoproject.org/meta-raspberrypi ../layers/meta-raspberrypi #. **Add Your Layer to the Layer Configuration File:** Before you can use it, you must add the layer and its dependencies to your :ref:`structure-build-conf-bblayers.conf` diff --git a/documentation/contributor-guide/recipe-style-guide.rst b/documentation/contributor-guide/recipe-style-guide.rst index 84c6bb14e8b0..fe12a8e6d826 100644 --- a/documentation/contributor-guide/recipe-style-guide.rst +++ b/documentation/contributor-guide/recipe-style-guide.rst @@ -436,7 +436,7 @@ By default, patches created with ``git format-patch`` have a `Git` version signa To avoid having a `Git` signature at the end of generated or updated patches, you can use `Git` configuration settings:: - git config --global format.signature "" + $ git config --global format.signature "" .. note:: Patches generated or updated by ``devtool`` are created with no signature. diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 574a92cd3465..e60f8ca7ace3 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -57,20 +57,20 @@ Set up Git The first thing to do is to install Git packages. Here is an example on Debian and Ubuntu:: - sudo apt install git-core git-email + $ sudo apt install git-core git-email Then, you need to set a name and e-mail address that Git will use to identify your commits:: - git config --global user.name "Ada Lovelace" - git config --global user.email "ada.lovelace@gmail.com" + $ git config --global user.name "Ada Lovelace" + $ git config --global user.email "ada.lovelace@gmail.com" By default, Git adds a signature line at the end of patches containing the Git version. We suggest to remove it as it doesn't add useful information. Remove it with the following command:: - git config --global format.signature "" + $ git config --global format.signature "" Clone the Git repository for the component to modify ---------------------------------------------------- @@ -79,8 +79,8 @@ After identifying the component to modify as described in the ":doc:`/contributor-guide/identify-component`" section, clone the corresponding Git repository. Here is an example for OpenEmbedded-Core:: - git clone https://git.openembedded.org/openembedded-core - cd openembedded-core + $ git clone https://git.openembedded.org/openembedded-core + $ cd openembedded-core Create a new branch ------------------- @@ -177,7 +177,7 @@ to add the upgraded version. is to look for prefixes used in previous commits touching the same files or directories:: - git log --oneline + $ git log --oneline #. For the commit description, provide detailed information that describes what you changed, why you made the change, and the @@ -278,7 +278,7 @@ Here is the general procedure on how to create patches to be sent through email: For this purpose, a good solution is to store the cover letter contents in the branch itself:: - git branch --edit-description + $ git branch --edit-description This will open a text editor to fill in the description for your changes. This description can be updated when necessary and will @@ -334,19 +334,19 @@ functional testing of the changes will be performed by ``patchtest``. Currently, it only supports testing patches for ``openembedded-core`` branches. To setup, perform the following:: - pip install -r meta/lib/patchtest/requirements.txt - source oe-init-build-env - bitbake-layers add-layer ../meta-selftest + $ pip install -r meta/lib/patchtest/requirements.txt + $ source oe-init-build-env + $ bitbake-layers add-layer ../meta-selftest Once these steps are complete and you have generated your patch files, you can run ``patchtest`` like so:: - patchtest --patch + $ patchtest --patch Alternatively, if you want ``patchtest`` to iterate over and test multiple patches stored in a directory, you can use:: - patchtest --directory + $ patchtest --directory By default, ``patchtest`` uses its own modules' file paths to determine what repository and test suite to check patches against. If you wish to test @@ -354,7 +354,7 @@ patches against a repository other than ``openembedded-core`` and/or use a different set of tests, you can use the ``--repodir`` and ``--testdir`` flags:: - patchtest --patch --repodir --testdir + $ patchtest --patch --repodir --testdir Finally, note that ``patchtest`` is designed to test patches in a standalone way, so if your patches are meant to apply on top of changes made by @@ -396,11 +396,11 @@ through a direct SMTP configuration in your Git ``~/.gitconfig`` file. Here are the settings for letting ``git send-email`` send e-mail through your regular STMP server, using a Google Mail account as an example:: - git config --global sendemail.smtpserver smtp.gmail.com - git config --global sendemail.smtpserverport 587 - git config --global sendemail.smtpencryption tls - git config --global sendemail.smtpuser ada.lovelace@gmail.com - git config --global sendemail.smtppass = XXXXXXXX + $ git config --global sendemail.smtpserver smtp.gmail.com + $ git config --global sendemail.smtpserverport 587 + $ git config --global sendemail.smtpencryption tls + $ git config --global sendemail.smtpuser ada.lovelace@gmail.com + $ git config --global sendemail.smtppass = XXXXXXXX These settings will appear in the ``.gitconfig`` file in your home directory. @@ -463,7 +463,7 @@ Sending Patches via Email At this stage, you are ready to send your patches via email. Here's the typical usage of ``git send-email``:: - git send-email --to *.patch + $ git send-email --to *.patch Then, review each subject line and list of recipients carefully, and then allow the command to send each message. @@ -476,7 +476,7 @@ or any layer other than :oe_git:`openembedded-core `, please add the appropriate prefix so that it is clear which layer the patch is intended to be applied to:: - git format-patch --subject-prefix="meta-oe][PATCH" ... + $ git format-patch --subject-prefix="meta-oe][PATCH" ... .. note:: @@ -488,13 +488,13 @@ to be applied to:: Here's a command you can use if you just have one patch in your branch:: - git send-email --to -1 + $ git send-email --to -1 If you have multiple patches and a cover letter, you can send patches for all the commits between the reference branch and the tip of your branch:: - git send-email --cover-letter --cover-from-description=auto --to -M + $ git send-email --cover-letter --cover-from-description=auto --to -M See the `git send-email manual page `__ for details. @@ -517,7 +517,7 @@ author name. The following will ensure that your e-mails have an additional maintainers accepting your patches don't have to fix commit author information manually:: - git config --global sendemail.from "linus.torvalds@kernel.org" + $ git config --global sendemail.from "linus.torvalds@kernel.org" The ``sendemail.from`` should match your ``user.email`` setting, which appears in the ``Signed-off-by`` line of your commits. @@ -530,12 +530,12 @@ with ``git send-email``, you can use Git configuration settings. - To set the right mailing list address for a given repository:: - git config --local sendemail.to openembedded-devel@lists.openembedded.org + $ git config --local sendemail.to openembedded-devel@lists.openembedded.org - If the mailing list requires a subject prefix for the layer (this only works when the repository only contains one layer):: - git config --local format.subjectprefix "meta-something][PATCH" + $ git config --local format.subjectprefix "meta-something][PATCH" Using Scripts to Push a Change Upstream and Request a Pull ========================================================== @@ -597,7 +597,7 @@ have been followed: enter the following command to bring up a short list of all commits against a specific file:: - git shortlog -- filename + $ git shortlog -- filename Just provide the name of the file for which you are interested. The information returned is not ordered by history but does include a @@ -719,7 +719,7 @@ follows: ``git format-patch``, for example to submit a patch to the "&DISTRO_NAME_NO_CAP_MINUS_ONE;" branch use:: - git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ... + $ git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ... Taking Patch Review into Account ================================ @@ -745,7 +745,7 @@ without the reported issues. A single patch can be amended using ``git commit --amend``, and multiple patches can be easily reworked and reordered through an interactive Git rebase:: - git rebase -i + $ git rebase -i See `this tutorial `__ for practical guidance about using Git interactive rebasing. @@ -755,7 +755,7 @@ sending the revised patch to mark the new iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be done by passing the ``-v`` argument to ``git format-patch`` with a version number:: - git format-patch -v2 + $ git format-patch -v2 After generating updated patches (v2, v3, and so on) via ``git diff --git a/documentation/dev-manual/creating-fragments.rst b/documentation/dev-manual/creating-fragments.rst index 8dabd599f13f..cd87341e9a51 100644 --- a/documentation/dev-manual/creating-fragments.rst +++ b/documentation/dev-manual/creating-fragments.rst @@ -86,7 +86,7 @@ For now, our fragment exists and is listed by the enable this fragment, use the :ref:`ref-bitbake-config-build-enable-fragment` command:: - bitbake-config-build enable-fragment meta-custom/custom-fragment + $ bitbake-config-build enable-fragment meta-custom/custom-fragment .. note:: @@ -143,4 +143,4 @@ configuration file: You can then use the :ref:`ref-bitbake-config-build-enable-fragment` command to set a value to the ``CUSTOM_VARIABLE`` variable:: - bitbake-config-build enable-fragment custom-builtin-fragment/somevalue + $ bitbake-config-build enable-fragment custom-builtin-fragment/somevalue diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 4995ba73f06b..0f6e9d1d7e85 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst @@ -821,7 +821,6 @@ missing dependency clearly visible at the end:: ^ compilation terminated. make: *** [tools/snep-send.o] Error 1 - $ Creating a Patch for the Fix diff --git a/documentation/dev-manual/devtool.rst b/documentation/dev-manual/devtool.rst index 242ea9dd9942..471134da8629 100644 --- a/documentation/dev-manual/devtool.rst +++ b/documentation/dev-manual/devtool.rst @@ -548,7 +548,7 @@ the two modes: - To work on the source code of a recipe another instance of VSCode is started in the recipe's workspace. Example:: - code build/workspace/sources/my-recipe + $ code build/workspace/sources/my-recipe This instance of VSCode uses plugins that are useful for the development of the application. ``devtool ide-sdk`` generates the necessary @@ -720,9 +720,9 @@ the two modes: VSCode. First of all we need a folder containing a CMake project. For this example, let's create a CMake project and start VSCode:: - mkdir kit-test - echo "project(foo VERSION 1.0)" > kit-test/CMakeLists.txt - code kit-test + $ mkdir kit-test + $ echo "project(foo VERSION 1.0)" > kit-test/CMakeLists.txt + $ code kit-test If there is a CMake project in the workspace, cross-compilation is supported: diff --git a/documentation/dev-manual/disk-space.rst b/documentation/dev-manual/disk-space.rst index 5516f793e301..ee02b267081c 100644 --- a/documentation/dev-manual/disk-space.rst +++ b/documentation/dev-manual/disk-space.rst @@ -33,7 +33,7 @@ disk space. However, only the most recent ones are likely to be reused. The following command is a quick way to purge all the cache files which haven't been used for a least a specified number of days:: - find build/sstate-cache -type f -mtime +$DAYS -delete + $ find build/sstate-cache -type f -mtime +$DAYS -delete The above command relies on the fact that BitBake touches the sstate cache files as it accesses them, when it has write access to the cache. @@ -49,7 +49,7 @@ requires a full build environment to be available and doesn't work well covering multiple releases. It won't work either on limited environments such as BSD based NAS:: - sstate-cache-management.py --remove-duplicated --cache-dir=sstate-cache + $ sstate-cache-management.py --remove-duplicated --cache-dir=sstate-cache This command will ask you to confirm the deletions it identifies. Run ``sstate-cache-management.py`` for more details about this script. diff --git a/documentation/dev-manual/hashequivserver.rst b/documentation/dev-manual/hashequivserver.rst index 75b77c30b944..0a67e79b66bc 100644 --- a/documentation/dev-manual/hashequivserver.rst +++ b/documentation/dev-manual/hashequivserver.rst @@ -22,7 +22,7 @@ the :term:`BitBake` repository, which can be found :oe_git:`here `. To start a basic Hash Equivalence server, one could simply run:: - ./bin/bitbake-hashserv + $ ./bin/bitbake-hashserv This will take all of the default options of the script, which are already sufficient to start a local server. diff --git a/documentation/dev-manual/limiting-resources.rst b/documentation/dev-manual/limiting-resources.rst index 892b0069accf..93c20c44c36e 100644 --- a/documentation/dev-manual/limiting-resources.rst +++ b/documentation/dev-manual/limiting-resources.rst @@ -104,7 +104,7 @@ details. #. Then, start a heavy-load build, for example:: - bitbake virtual/kernel -c compile -f + $ bitbake virtual/kernel -c compile -f You can stop the build at anytime with Control + C. diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst index f43fc2be3f4c..a23a796f5a40 100644 --- a/documentation/dev-manual/new-recipe.rst +++ b/documentation/dev-manual/new-recipe.rst @@ -106,19 +106,19 @@ Here are some syntax examples: - Use this syntax to generate a recipe based on source. Once generated, the recipe resides in the existing source code layer:: - recipetool create -o OUTFILE source + $ recipetool create -o OUTFILE source - Use this syntax to generate a recipe using code that you extract from source. The extracted code is placed in its own layer defined by :term:`EXTERNALSRC`:: - recipetool create -o OUTFILE -x EXTERNALSRC source + $ recipetool create -o OUTFILE -x EXTERNALSRC source - Use this syntax to generate a recipe based on source. The options direct ``recipetool`` to generate debugging information. Once generated, the recipe resides in the existing source code layer:: - recipetool create -d -o OUTFILE source + $ recipetool create -d -o OUTFILE source Locating and Using a Similar Recipe ----------------------------------- diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst index 0271cca10cc9..8cd90b9f25b1 100644 --- a/documentation/dev-manual/packages.rst +++ b/documentation/dev-manual/packages.rst @@ -176,7 +176,7 @@ work against a common, shared package feed, you have a single PR Service running and it is connected to each building system. For this scenario, you need to start the PR Service using the ``bitbake-prserv`` command:: - bitbake-prserv --host ip --port port --start + $ bitbake-prserv --host ip --port port --start In addition to hand-starting the service, you need to update the diff --git a/documentation/dev-manual/python-development-shell.rst b/documentation/dev-manual/python-development-shell.rst index 07563043232c..034100ae8799 100644 --- a/documentation/dev-manual/python-development-shell.rst +++ b/documentation/dev-manual/python-development-shell.rst @@ -25,7 +25,6 @@ functions:: pydevshell> d.delVar("FOO") pydevshell> d.getVar("FOO") pydevshell> bb.build.exec_func("do_unpack", d) - pydevshell> See the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:functions you can call from within python`" section in the BitBake User Manual for details about available functions. diff --git a/documentation/dev-manual/qemu.rst b/documentation/dev-manual/qemu.rst index 514a72fc528a..6d092b2d2034 100644 --- a/documentation/dev-manual/qemu.rst +++ b/documentation/dev-manual/qemu.rst @@ -65,7 +65,7 @@ available. Follow these general steps to run QEMU: initializes the toolchain. For example, the following commands run the initialization script from the default ``poky_sdk`` directory:: - . poky_sdk/environment-setup-core2-64-poky-linux + $ . poky_sdk/environment-setup-core2-64-poky-linux #. *Ensure the Artifacts are in Place:* You need to be sure you have a pre-built kernel that will boot in QEMU. You also need the target @@ -227,15 +227,15 @@ using an NFS server. - To start the NFS share:: - runqemu-export-rootfs start file-system-location + $ runqemu-export-rootfs start file-system-location - To stop the NFS share:: - runqemu-export-rootfs stop file-system-location + $ runqemu-export-rootfs stop file-system-location - To restart the NFS share:: - runqemu-export-rootfs restart file-system-location + $ runqemu-export-rootfs restart file-system-location QEMU CPU Compatibility Under KVM ================================ diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index c7d0fe3dab8d..73b7d9501ae4 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst @@ -423,7 +423,7 @@ your Yocto Project build host: replace the PackageFamilyName and your user on the following path to find your VHDX file:: - ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ + C:\WINDOWS\system32> ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState Mode LastWriteTime Length Name -a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx diff --git a/documentation/dev-manual/wayland.rst b/documentation/dev-manual/wayland.rst index 5e333b6265f4..ec8ed86c1c60 100644 --- a/documentation/dev-manual/wayland.rst +++ b/documentation/dev-manual/wayland.rst @@ -80,11 +80,11 @@ the CLI, you need to do the following after your image is built: #. Run these commands to export ``XDG_RUNTIME_DIR``:: - mkdir -p /tmp/$USER-weston - chmod 0700 /tmp/$USER-weston - export XDG_RUNTIME_DIR=/tmp/$USER-weston + user@machine:~$ mkdir -p /tmp/$USER-weston + user@machine:~$ chmod 0700 /tmp/$USER-weston + user@machine:~$ export XDG_RUNTIME_DIR=/tmp/$USER-weston #. Launch Weston in the shell:: - weston + user@machine:~$ weston diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index 65bd3d0d1f46..6e67156bedc5 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -75,7 +75,6 @@ section: $ bitbake-layers create-layer ../layers/meta-mylayer NOTE: Starting bitbake server... Add your new layer with 'bitbake-layers add-layer ../layers/meta-mylayer' - $ .. note:: @@ -98,7 +97,6 @@ section: $ cd bitbake-builds/build $ bitbake-layers add-layer ../../meta-mylayer NOTE: Starting bitbake server... - $ #. *Build the Clean Image:* The final step in preparing to work on the kernel is to build an initial image using ``bitbake``:: @@ -194,7 +192,6 @@ section: $ cd bitbake-builds/build $ bitbake-layers add-layer ../../meta-mylayer NOTE: Starting bitbake server ... - $ #. *Create a Local Copy of the Kernel Git Repository:* You can find Git repositories of supported Yocto Project kernels organized under diff --git a/documentation/migration-guides/migration-2.1.rst b/documentation/migration-guides/migration-2.1.rst index 473dd10ff121..987464f4d77f 100644 --- a/documentation/migration-guides/migration-2.1.rst +++ b/documentation/migration-guides/migration-2.1.rst @@ -46,8 +46,8 @@ not specify the final expand parameter to calls that do specify the parameter. You can run the following ``sed`` command at the base of a layer to make this change:: - sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *` - sed -e 's:\(\.getVarFlag([^,()]*,[^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *` + $ sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *` + $ sed -e 's:\(\.getVarFlag([^,()]*,[^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *` .. note:: diff --git a/documentation/migration-guides/migration-2.5.rst b/documentation/migration-guides/migration-2.5.rst index 8e182cd2bc4a..70946b5e11b4 100644 --- a/documentation/migration-guides/migration-2.5.rst +++ b/documentation/migration-guides/migration-2.5.rst @@ -138,11 +138,11 @@ BitBake Changes :ref:`ref-classes-archiver` classes). There is a BitBake option to complete this for any arbitrary task. For example:: - bitbake -c fetchall + $ bitbake -c fetchall should now be replaced with:: - bitbake --runall=fetch + $ bitbake --runall=fetch .. _migration-2.5-python-and-python3-changes: diff --git a/documentation/migration-guides/migration-4.0.rst b/documentation/migration-guides/migration-4.0.rst index c8c2b856d91c..31ce15a9cafc 100644 --- a/documentation/migration-guides/migration-4.0.rst +++ b/documentation/migration-guides/migration-4.0.rst @@ -256,7 +256,7 @@ Miscellaneous changes - The Python development shell (previously known as ``devpyshell``) feature has been renamed to ``pydevshell``. To start it you should now run:: - bitbake -c pydevshell + $ bitbake -c pydevshell - The ``packagegroups-core-full-cmdline-libs`` packagegroup is no longer produced, as libraries should normally be brought in via dependencies. If you have any references diff --git a/documentation/migration-guides/migration-5.3.rst b/documentation/migration-guides/migration-5.3.rst index 38c7d6771667..e5521d94b59f 100644 --- a/documentation/migration-guides/migration-5.3.rst +++ b/documentation/migration-guides/migration-5.3.rst @@ -83,16 +83,16 @@ How to make those adjustments without tedious manual editing The following sed command can be used to remove S = "${WORKDIR}/git across a whole layer:: - sed -i "/^S = \"\${WORKDIR}\/git\"/d" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'` + $ sed -i "/^S = \"\${WORKDIR}\/git\"/d" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'` Then, the following command can tweak the remaining :term:`S` assignments to refer to :term:`UNPACKDIR` instead of :term:`WORKDIR`:: - sed -i "s/^S = \"\${WORKDIR}\//S = \"\${UNPACKDIR}\//g" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'` + $ sed -i "s/^S = \"\${WORKDIR}\//S = \"\${UNPACKDIR}\//g" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'` The first change can introduce a lot of consecutive empty lines, so those can be removed with:: - sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name '*.bb' -o -name '*.inc'` + $ sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name '*.bb' -o -name '*.inc'` BitBake Git fetcher ``tag`` parameter @@ -312,11 +312,11 @@ The following classes have been removed in this release: #. Use the specific FIT image recipe rather than the base kernel recipe. For example, instead of:: - bitbake linux-yocto + $ bitbake linux-yocto the FIT image is now build by:: - bitbake linux-yocto-fitimage + $ bitbake linux-yocto-fitimage For custom kernel recipes, creating a corresponding custom FIT image recipe is usually a good approach. diff --git a/documentation/migration-guides/release-notes-4.2.rst b/documentation/migration-guides/release-notes-4.2.rst index f50ef180ac66..3586622edca9 100644 --- a/documentation/migration-guides/release-notes-4.2.rst +++ b/documentation/migration-guides/release-notes-4.2.rst @@ -173,7 +173,7 @@ New Features / Enhancements in 4.2 command, which allowed to spot and fix a regression in the ``quilt`` ptest:: - yocto_testresults_query.py regression-report 4.2_M1 4.2_M2 + $ yocto_testresults_query.py regression-report 4.2_M1 4.2_M2 See this `blog post about regression detection `__. diff --git a/documentation/migration-guides/release-notes-5.3.rst b/documentation/migration-guides/release-notes-5.3.rst index 8a564716f319..311a9a94718a 100644 --- a/documentation/migration-guides/release-notes-5.3.rst +++ b/documentation/migration-guides/release-notes-5.3.rst @@ -466,7 +466,7 @@ New Features / Enhancements in |yocto-ver| - The script can now run compressed images with snapshot mode. For example, with :term:`IMAGE_FSTYPES` containing ``ext4.zst``, you can run:: - runqemu snapshot ext4.zst + $ runqemu snapshot ext4.zst - Add support for the ``erofs`` filesystem. diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index cbad93e8a38d..7b67ae8cc6b3 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst @@ -366,7 +366,7 @@ To do so, create a recipe for your program, for example using make it inherit the :ref:`ref-classes-cargo` and :ref:`ref-classes-cargo-update-recipe-crates` and run:: - bitbake -c update_crates recipe + $ bitbake -c update_crates recipe This creates a ``recipe-crates.inc`` file that you can include in your recipe:: @@ -1372,7 +1372,7 @@ The simplest example for building a FIT image is to add:: to the machine :term:`configuration file` and to execute:: - bitbake linux-yocto-fitimage + $ bitbake linux-yocto-fitimage This results in a ``fitImage`` file deployed to the :term:`DEPLOY_DIR_IMAGE` directory and a ``linux-yocto-fitimage`` package which can be installed. @@ -1386,7 +1386,7 @@ lines to the machine configuration file:: The FIT image, this time including the RT kernel, is built again by calling:: - bitbake linux-yocto-fitimage + $ bitbake linux-yocto-fitimage For other kernels provided by other layers, the same approach would work. However, it is usually more intuitive to add a custom FIT image recipe next to @@ -3864,7 +3864,7 @@ build. Example usage:: - bitbake -c generate_vex openssl + $ bitbake -c generate_vex openssl .. _ref-classes-waf: diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index d2e80611a994..4aa95d8e0499 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst @@ -461,7 +461,6 @@ Here is an example that resets the workspace directory that contains the $ devtool reset mtr NOTE: Cleaning sysroot for recipe mtr... NOTE: Leaving source tree /home/scottrif/bitbake-builds/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually - $ .. _devtool-finish-working-on-a-recipe: @@ -634,7 +633,6 @@ to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:: $ devtool status mtr:/home/scottrif/bitbake-builds/build/workspace/sources/mtr (/home/scottrif/bitbake-builds/build/workspace/recipes/mtr/mtr_0.86.bb) - $ .. _devtool-search-for-available-target-recipes: diff --git a/documentation/ref-manual/fragments.rst b/documentation/ref-manual/fragments.rst index e5cd9fc436c1..c5640b826eae 100644 --- a/documentation/ref-manual/fragments.rst +++ b/documentation/ref-manual/fragments.rst @@ -72,25 +72,25 @@ command, you can determine which fragments can be enabled for your build. For example, the following command would enable the :ref:`ref-fragments-core-yocto-sstate-mirror-cdn` fragment:: - bitbake-config-build enable-fragment core/yocto/sstate-mirror-cdn + $ bitbake-config-build enable-fragment core/yocto/sstate-mirror-cdn .. note:: Multiple fragments can be enabled at once with the same command:: - bitbake-config-build enable-fragment ... + $ bitbake-config-build enable-fragment ... :term:`Built-in fragments ` are enabled the same way, and their values are defined from the command-line directly. For example, the following command sets the ``qemuarm64`` :term:`MACHINE` through the :ref:`ref-fragments-builtin-core-machine` fragment:: - bitbake-config-build enable-fragment machine/qemuarm64 + $ bitbake-config-build enable-fragment machine/qemuarm64 This fragment can be overridden from the command-line by setting it to another value, for example:: - bitbake-config-build enable-fragment machine/qemux86-64 + $ bitbake-config-build enable-fragment machine/qemux86-64 In the above example, the new value of :term:`MACHINE` is now equal to ``qemux86-64``. @@ -118,18 +118,18 @@ command. The list of enabled fragments can be obtained with For example, the following command disables the :ref:`ref-fragments-core-yocto-sstate-mirror-cdn` fragment:: - bitbake-config-build disable-fragment core/yocto/sstate-mirror-cdn + $ bitbake-config-build disable-fragment core/yocto/sstate-mirror-cdn Likewise, :term:`Built-in Fragments ` are disabled the same way. For example, this would disable the ``machine/qemuarm64`` fragment:: - bitbake-config-build disable-fragment machine/qemuarm64 + $ bitbake-config-build disable-fragment machine/qemuarm64 .. note:: Multiple fragments can be disabled at once with the same command:: - bitbake-config-build disable-fragment + $ bitbake-config-build disable-fragment .. _ref-bitbake-config-build-disable-all-fragments: @@ -142,7 +142,7 @@ currently enabled fragments. The list of enabled fragments can be obtained with This command is run without arguments:: - bitbake-config-build disable-all-fragments + $ bitbake-config-build disable-all-fragments Core Fragments ============== diff --git a/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst index 8e1ce4438c79..14e3632ce6b8 100644 --- a/documentation/ref-manual/qa-checks.rst +++ b/documentation/ref-manual/qa-checks.rst @@ -573,14 +573,14 @@ patched file to still compile without errors. Use the ``devtool`` command as explained by the warning. First, unpack the source into devtool workspace:: - devtool modify + $ devtool modify This will apply all of the patches, and create new commits out of them in the workspace --- with the patch context updated. Then, replace the patches in the recipe layer:: - devtool finish --force-patch-refresh + $ devtool finish --force-patch-refresh The patch updates then need be reviewed (preferably with a side-by-side diff tool) to ensure they are indeed doing the right thing i.e.: diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index 1c0864d8720e..c050c422bffc 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -967,7 +967,7 @@ system and gives an overview of their function and contents. Use the following format to export the variable to the BitBake environment:: - export BBSERVER=localhost:$port + $ export BBSERVER=localhost:$port By default, :term:`BBSERVER` also appears in :term:`BB_BASEHASH_IGNORE_VARS`. Consequently, :term:`BBSERVER` is excluded from checksum and dependency @@ -9357,7 +9357,7 @@ system and gives an overview of their function and contents. You can obtain the signature of all the tasks for the recipe ``bc`` using:: - bitbake -S none bc + $ bitbake -S none bc Then you can look at files in ``build/tmp/stamps//bc`` and look for files like: ``.do_compile.sigdata.09772aa4532512baf96d433484f27234d4b7c11dd9cda0d6f56fa1b7ce6f25f0``. @@ -9514,7 +9514,7 @@ system and gives an overview of their function and contents. This file requires permissions set to ``400`` or ``600`` to prevent other users from reading the file:: - chmod 600 "$HOME/.netrc" + $ chmod 600 "$HOME/.netrc" Another method to configure the username and password is from the URL in :term:`SOURCE_MIRROR_URL` directly, with the ``user`` and ``pswd`` diff --git a/documentation/test-manual/reproducible-builds.rst b/documentation/test-manual/reproducible-builds.rst index 892f7b9c8f0d..4e39cf3f79d8 100644 --- a/documentation/test-manual/reproducible-builds.rst +++ b/documentation/test-manual/reproducible-builds.rst @@ -89,7 +89,7 @@ it always depends upon the paths it is built in. To run our automated selftest, as we use in our CI on the Autobuilder, you can run:: - oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds + $ oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds This defaults to including a ``world`` build so, if other layers are added, it would also run the tests for recipes in the additional layers. Different build diff --git a/documentation/test-manual/runtime-testing.rst b/documentation/test-manual/runtime-testing.rst index 55c19900f439..5a7193f015b4 100644 --- a/documentation/test-manual/runtime-testing.rst +++ b/documentation/test-manual/runtime-testing.rst @@ -326,7 +326,7 @@ You can start the tests automatically or manually: Next, build your image. If the image successfully builds, the tests run:: - bitbake core-image-sato + $ bitbake core-image-sato - *Manually running tests:* To manually run the tests, first globally inherit the :ref:`ref-classes-testimage` class by editing your @@ -336,7 +336,7 @@ You can start the tests automatically or manually: Next, use BitBake to run the tests:: - bitbake -c testimage image + $ bitbake -c testimage image All test files reside in ``meta/lib/oeqa/runtime/cases`` in :term:`OpenEmbedded-Core (OE-Core)`. A test name maps From patchwork Thu Sep 24 17:28:47 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99194 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF625C98324 for ; Thu, 24 Sep 2026 17:29:08 +0000 (UTC) Received: from mail-vs2-f41.google.com (mail-vs2-f41.google.com [74.125.227.41]) by mx.groups.io with SMTP id smtpd.msgproc02-g2.3794.1790270945348239830 for ; Thu, 24 Sep 2026 10:29:05 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=iar15L9F; spf=pass (domain: gmail.com, ip: 74.125.227.41, mailfrom: twoerner@gmail.com) Received: by mail-vs2-f41.google.com with SMTP id ada2fe7eead31-78a53fe85easo23290137.1 for ; Thu, 24 Sep 2026 10:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270944; x=1790875744; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Nn6bBgY2JbzuzZekJC2r7V4Mvh/zZ1NzrWiQGXHOKbU=; b=iar15L9FR66yIXZHSHdXihi6YDiVhecsZ7Se0J6HclQ89oGZxMjAE6jW8BMeaorgcf MN5WEdfySM5tamTqdIMTUql20Zk+3+HgEIDviTV3jwxZ1tyhMXdVNXH4CKUyGmLoOY/r d+vyyPNucUedoiHosTkmdu1mTniOqHx5loqflsgKf9VfUee9UK3I3L16ZhTgKqAsIffy b48w2EeQj3PVv02iY+dVOGyuRYdu+elBiZu7lZir7GQSTnJ6NGM41AXqdqwL0jNe9hwm p7+HN6YHZnReCIz/7wUfxiOhg4fXLhgiBqzo3LktOUG9G4NoQXnJqlklgZXpg9PgCu0O gMdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270944; x=1790875744; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Nn6bBgY2JbzuzZekJC2r7V4Mvh/zZ1NzrWiQGXHOKbU=; b=qJmN2qWSs3IqCajgnVUgNrYAs0C7t7emfzc+AVzjRNkvJKFkitDnNplZ7/nahBXnEh 2qXzlO28hGNbA0qm7O+bLc1RSaANNZ5gtOa8dqLNiyEuusqR9rFgNjMclhmAILcJjSYG IuVNZ+T5+2/MIIi+VLYdNoAeqI5QF5eJl9/OtEJVqTC/87UXpuabSh3ZEvmWWwedZ8Yc o+MmM9VrIZh4Ap6XGp471jGGcJqhyyuF6mJ0XU/zHiTQH2iIcNLMcENPDMz0vtJvHAgt VOyxO751JfVAwqlMuy8ZBuahj3PfMUArNO1N0IXeF84SZfdeiF2lC9yWm5vDRCnWmzh/ 28Dw== X-Gm-Message-State: AFuF++l9+9UYrFjMFnfCU08zqLeExrhQQ0z27HlaB0TlGZ8rR8nkKFsM fqJ880Oynsfja5phnbrxttDwt+tQDQPlXEacspFx/RFT6oNt+ys+xILJdxvQCQ== X-Gm-Gg: AYBFou1KDty1H7n76HoMTG7iVqi1ZkM2/J4GySB23AxqIYkS6XQ2fXIumHLQiK8Sn1E hs7g7DktGxYY6IN/wBKKg6eaiqT6CKhUBkQFb8BgvLHh7+zVRDcA9DVrMxy1gjQOj0eARLCxTAQ Oao8tiriA3pg8b0vaLW4nTgYZczM59HbJygKbSaTWlG1/as2Gpr0RiXd5TlYN8DDNOs0uI3luPZ 6gYGRoS5tXrg2NkBuFk7GEyVI7MIwFzu1MCuSoZBBaeVqBTGhcFWXRttfHG/lGC77R+4blK4V6R tWlUwgacIdKC08x46+DIeRZllOGBnHlMdO1E6d7lQkL2QWFqHv8+9As+GoNfYYUrdfju4VA+r7S f5FDXL+wDjdUQCSf1fXptcm3ipGC3C0MenjkwGZCFO2h1X6MugsE6pRHGmCe8OY99SxCpfKgU6Y ObMEFbi+h253+SSRJpOv1EZegbpAs26ni52/AAYCnxpO3kvMTdQtiMGW9Pr1uZnjLH0uYs99ta0 LhSn+36iHBiQkb6yOc+8MOvjfQmD15KIrxEzjw08w== X-Received: by 2002:a05:6102:4b1a:b0:7a7:5355:7fb6 with SMTP id ada2fe7eead31-7af1e4f8b12mr1303814137.24.1790270944062; Thu, 24 Sep 2026 10:29:04 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:02 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Cc: Quentin Schulz Subject: [PATCH v3 04/10] docs: write an elided passage as a comment Date: Thu, 24 Sep 2026 13:28:47 -0400 Message-ID: <20260924172853.2665062-5-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:08 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10627 Several examples stand in for code they leave out with a bare "..." or a column of dots on a line of their own. Neither is valid in the language around it, so the example cannot say what language it is without also saying something false about itself. Use a comment instead, in whatever language the example is written in, and say in it what was left out. The ellipsis on its own raises a question - what is missing here, and does it matter? - that a few words can answer at no cost to the reader. AI-Generated: codex/claude-opus 5 (xhigh) Reviewed-by: Quentin Schulz Signed-off-by: Trevor Woerner --- changes in v3: - none changes in v2: - rebased on master-next; no other change --- documentation/bsp-manual/bsp.rst | 4 +--- documentation/kernel-dev/common.rst | 14 +++++++------- documentation/migration-guides/migration-3.2.rst | 2 +- documentation/overview-manual/concepts.rst | 2 +- 4 files changed, 10 insertions(+), 12 deletions(-) diff --git a/documentation/bsp-manual/bsp.rst b/documentation/bsp-manual/bsp.rst index dd613326942a..93af13f789d1 100644 --- a/documentation/bsp-manual/bsp.rst +++ b/documentation/bsp-manual/bsp.rst @@ -561,9 +561,7 @@ statements from the Raspberry Pi ``conf/layer.conf`` file:: # Additional license directories. LICENSE_PATH += "${LAYERDIR}/files/custom-licenses" - . - . - . + # ... and so on for the rest of the file ... This file simply makes :term:`BitBake` aware of the recipes and configuration directories. The file must exist so that the OpenEmbedded build system can diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index 6e67156bedc5..3de61cab08d6 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -681,9 +681,9 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio printk("*************************************\n"); if (per_cpu(cpu_loops_per_jiffy, this_cpu)) { - . - . - . + /* + * ... remaining code unchanged ... + */ #. *Build the Updated Kernel Source:* To build the updated kernel source, use ``devtool``:: @@ -817,9 +817,9 @@ Section. printk("*************************************\n"); if (per_cpu(cpu_loops_per_jiffy, this_cpu)) { - . - . - . + /* + * ... remaining code unchanged ... + */ #. *Stage and Commit Your Changes:* Use standard Git commands to stage and commit the changes you just made:: @@ -1598,7 +1598,7 @@ looks much like the one provided with the ``hello-mod`` template:: modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install - ... + # ... remaining rules ... The important point to note here is the :term:`KERNEL_SRC` variable. The :ref:`ref-classes-module` class sets this variable and the :term:`KERNEL_PATH` diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst index 5cb958e75047..a037e6f51c53 100644 --- a/documentation/migration-guides/migration-3.2.rst +++ b/documentation/migration-guides/migration-3.2.rst @@ -100,7 +100,7 @@ This also applies when conditionally adding packages to :term:`PACKAGES` where those packages have dependencies, for example (from the ``alsa-plugins`` recipe):: PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'alsa-plugins-pulseaudio-conf', '', d)}" - ... + # ... elsewhere in the same recipe ... RDEPENDS_${PN}-pulseaudio-conf += "\ ${MLPREFIX}libasound-module-conf-pulse \ ${MLPREFIX}libasound-module-ctl-pulse \ diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index 3bf672c78387..1e9c6d3a6f0b 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst @@ -2193,7 +2193,7 @@ accomplished using fakeroot. ``virtual/fakeroot-native:do_populate_sysroot``, giving the following:: fakeroot do_mytask () { - ... + # ... steps to perform task here ... } do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot" From patchwork Thu Sep 24 17:28:48 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99191 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7175C98318 for ; Thu, 24 Sep 2026 17:29:08 +0000 (UTC) Received: from mail-vs2-f40.google.com (mail-vs2-f40.google.com [74.125.227.40]) by mx.groups.io with SMTP id smtpd.msgproc01-g2.3765.1790270946992049748 for ; Thu, 24 Sep 2026 10:29:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=cQpsgABJ; spf=pass (domain: gmail.com, ip: 74.125.227.40, mailfrom: twoerner@gmail.com) Received: by mail-vs2-f40.google.com with SMTP id ada2fe7eead31-7a4fb331cc0so17413137.3 for ; Thu, 24 Sep 2026 10:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270946; x=1790875746; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=8piAVNbFI4weeWMl9dePku3OBx9p3UPVq2N3oGVUVNA=; b=cQpsgABJKz5LN7UFditIwvho/RJQvQNvwSXkDxZ+CuWeNrySl/scKyvvfc2Fyv+NEM 5ci8RnPaEtkrYK2d31fNLyD7Gywx9x/BBoL3owqNrJNCGs+YEqJXMbClWJ09g4fStiJS 3624zt/8kqnCTYDEvjQokJn3eFWwO1IRqM4htlfEpdm8mBr4eIiki/5fkubaENKJkhkg /IPEx5+FmMl/A5yQ0K7fwds9zxHRSZCkjR48/4M6axyo1iHwAmi02hAgfUKHw+O/L/pY rQJeilaRoEDkIRX8LAY75W9bzU2uNTqWp7eh8imoq3WqolqwvrJn8H795n3c0lLStH+s x9qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270946; x=1790875746; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=8piAVNbFI4weeWMl9dePku3OBx9p3UPVq2N3oGVUVNA=; b=N225B3fo2Rfo+znQP+WumXqY12UmhjFWdtBGmpDOKvV+nn3LgydvGzIVWS9/moPW/l dEQlnSGnx5IeNbhqT2P5PSoiIFv3dOwDDNODNOzfiZbz0ywRhGZEjYGhWYqb3LlJgEfT zVJDccOveqPRmE2Fnpbe1+famgX1wOgR3rN6J/5rPSYG/uv0illlwKT8IcmSM8mR2NjB r05YuNt1UBqgblcSah6UE+Hhh+e3g45XLKA6TVCgx/aJfwI2dB1kCHy1AAvNONVxOlhh vSIg67L19uCEhedyeFsdSWKPfBOAFaWo5tt6n/tXprBpIlHlSEmRGCo1eS4qrumZgCsI exEw== X-Gm-Message-State: AFuF++nipFicSIHi5rA6HjlfKjGnkEgNZLhji4JOvk/lIdjNV0l1BKek 5Y0f1YwqMdx/5kvXrk1Cct06f8yRbw9+8FwV+430goUS+3OusmGMx6kfPrZhrw== X-Gm-Gg: AYBFou3TFM40sJdUxFgVbMgI9we/i0BltD077L9LjyexIRYfdBhA+ISfhraULBGOU8o OQE6nybJjB3Y+tO7E3qRmqaol95pnWPBPHV5pVaQh93uoZnk13d16takykTdmmlD5ufGZbK2ItN xX/UPxR0TEpOwZWDVNYgzTmevPujcqQ9K1VG0xdPfOCEZHpv2S5DihHPbA7l8Mpv2qInfso8flj fa1nivT9yDnc5SQzPDkHYJv7PCwRwaMptkzDim8PDYITzFucEmaIhmhaEba2cVAOU+z3m+MdRNN K0TyDaMkeeK5H0C5r83wRONFFtVx5634pkvUcjnN9oP2SN74LLS94kP58gCvjFn2fcD4I1kOJbU gftMPyMR2IbVH7I0y2iWi500IvbqihzUn7+bwGBhSboXecQYGv8ZCYEnDnQQ4HvLOYLPaOaqosI W7jxshNchAwcT1Hg+Q3nqFFxx7ALtG2hJlfCLJzpBhNKbJPDBUpv2HFtD/57sAcEiipoIVx9fqL T+XCJrgITGt02ztPslTgJ6p+g== X-Received: by 2002:a05:6102:26c8:b0:7a1:f7d2:e846 with SMTP id ada2fe7eead31-7af1e9f25f2mr1385274137.22.1790270945709; Thu, 24 Sep 2026 10:29:05 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:04 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Subject: [PATCH v3 05/10] docs: mark the placeholders in examples Date: Thu, 24 Sep 2026 13:28:48 -0400 Message-ID: <20260924172853.2665062-6-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:08 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10628 Values the reader is expected to replace are written as though they were literal. "arch-gdb" reads like a command that exists, a Git SRC_URI example reads like a URL and a pair of revisions worth copying, and the git-config examples give an account name and address that are somebody else's. Put them in the angle brackets the manuals already use for the purpose. Two corrections go with them: the directory placeholder in the GDB example described itself at length rather than naming the thing, and the smtppass example carried a stray "=". Since git config takes a name and then a value, that "=" was the value, and the password behind it an argument git config reads as a pattern. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner --- changes in v3: - the DMARC From: header is left as it was; nothing in it is for the reader to replace - the git config name is written - the SRCREV values say they are commit SHAs - the SMTP server is a placeholder too, and the prose names smtp.gmail.com as the Google Mail value rather than the block changes in v2: - rebased on master-next; no other change --- .../contributor-guide/submit-changes.rst | 15 ++++++++------- documentation/dev-manual/debugging.rst | 8 ++++---- documentation/migration-guides/migration-5.2.rst | 16 ++++++++-------- documentation/ref-manual/devtool-reference.rst | 2 +- documentation/ref-manual/variables.rst | 2 +- 5 files changed, 22 insertions(+), 21 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index e60f8ca7ace3..589545074907 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -62,8 +62,8 @@ on Debian and Ubuntu:: Then, you need to set a name and e-mail address that Git will use to identify your commits:: - $ git config --global user.name "Ada Lovelace" - $ git config --global user.email "ada.lovelace@gmail.com" + $ git config --global user.name " " + $ git config --global user.email "" By default, Git adds a signature line at the end of patches containing the Git version. We suggest to remove it as it doesn't add useful information. @@ -394,13 +394,14 @@ Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or through a direct SMTP configuration in your Git ``~/.gitconfig`` file. Here are the settings for letting ``git send-email`` send e-mail through your -regular STMP server, using a Google Mail account as an example:: +regular STMP server, such as ``smtp.gmail.com`` for a Google Mail +account:: - $ git config --global sendemail.smtpserver smtp.gmail.com + $ git config --global sendemail.smtpserver $ git config --global sendemail.smtpserverport 587 $ git config --global sendemail.smtpencryption tls - $ git config --global sendemail.smtpuser ada.lovelace@gmail.com - $ git config --global sendemail.smtppass = XXXXXXXX + $ git config --global sendemail.smtpuser + $ git config --global sendemail.smtppass These settings will appear in the ``.gitconfig`` file in your home directory. @@ -517,7 +518,7 @@ author name. The following will ensure that your e-mails have an additional maintainers accepting your patches don't have to fix commit author information manually:: - $ git config --global sendemail.from "linus.torvalds@kernel.org" + $ git config --global sendemail.from "" The ``sendemail.from`` should match your ``user.email`` setting, which appears in the ``Signed-off-by`` line of your commits. diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 0f6e9d1d7e85..8412c997a51e 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst @@ -810,7 +810,7 @@ be visible. In this case, there is a missing dependency for the ``neard`` Makefile target. Here is some abbreviated, sample output with the missing dependency clearly visible at the end:: - i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/scott-lenovo/...... + i586-poky-linux-gcc -m32 -march=i586 --sysroot= . . . @@ -1114,11 +1114,11 @@ debugger. After running gdbserver on the target, you need to run Gdb on the host and configure it and connect to the target. Use these commands:: - $ cd directory-holding-the-debugfs-directory - $ arch-gdb + $ cd + $ -gdb (gdb) set sysroot debugfs (gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug - (gdb) target remote IP-of-target:1234 + (gdb) target remote :1234 At this point, everything should automatically load (i.e. matching binaries, diff --git a/documentation/migration-guides/migration-5.2.rst b/documentation/migration-guides/migration-5.2.rst index 77a11fe27047..0c888136494e 100644 --- a/documentation/migration-guides/migration-5.2.rst +++ b/documentation/migration-guides/migration-5.2.rst @@ -193,9 +193,9 @@ The support for having multiple Git revisions per URL in :term:`SRC_URI` was removed from BitBake, which means the following syntax is not supported anymore:: - SRC_URI = "git://some.host/somepath;bareclone=1;branch=branchX,branchY;name=nameX,nameY" - SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx" - SRCREV_nameY = "yyyyyyyyyyyyyyyyyyyy" + SRC_URI = "git:///;bareclone=1;branch=,;name=," + SRCREV_ = "" + SRCREV_ = "" This was rarely used in the core repositories because it would only ever make sense for bare clones (the ``bareclone=1`` :term:`SRC_URI` option) where recipes @@ -205,10 +205,10 @@ places. If one of your recipes is using this mechanism, you can split the code source fetching into two separate entries:: - SRC_URI = "git://some.host/somepath;bareclone=1;branch=branchX;name=nameX \ - git://some.host/somepath;bareclone=1;branch=branchY;name=nameY" - SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx" - SRCREV_nameY = "yyyyyyyyyyyyyyyyyyyy" + SRC_URI = "git:///;bareclone=1;branch=;name= \ + git:///;bareclone=1;branch=;name=" + SRCREV_ = "" + SRCREV_ = "" Git fetcher: Branch parameter now required in :term:`SRC_URI` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -216,7 +216,7 @@ Git fetcher: Branch parameter now required in :term:`SRC_URI` The ``branch`` parameter is now required when specifying a Git repository in :term:`SRC_URI`, for example:: - SRC_URI = "git://some.host/somepath;branch=branchX" + SRC_URI = "git:///;branch=" A missing ``branch`` parameter used to produce a warning, and will now produce an error. diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index 4aa95d8e0499..62c3b707b9ff 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst @@ -474,7 +474,7 @@ This is roughly equivalent to the ``devtool update-recipe`` command followed by the ``devtool reset`` command. The changes must have been committed to the git repository created by ``devtool``. Here is an example:: - $ devtool finish recipe /path/to/custom/layer + $ devtool finish .. _devtool-building-your-recipe: diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index c050c422bffc..7ba5c48fd8ed 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -162,7 +162,7 @@ system and gives an overview of their function and contents. ARCHIVER_MODE[src] = "patched" # Uses patched source files. This is the default. ARCHIVER_MODE[src] = "configured" # Uses configured source files. ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and do_patch. - ARCHIVER_MODE[diff-exclude] ?= "file file ..." # Lists files and directories to exclude from diff. + ARCHIVER_MODE[diff-exclude] ?= " ..." # Lists files and directories to exclude from diff. ARCHIVER_MODE[dumpdata] = "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses recipe and include files. From patchwork Thu Sep 24 17:28:49 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99195 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92646C98328 for ; Thu, 24 Sep 2026 17:29:09 +0000 (UTC) Received: from mail-ua2-f39.google.com (mail-ua2-f39.google.com [74.125.226.231]) by mx.groups.io with SMTP id smtpd.msgproc02-g2.3795.1790270948486011767 for ; Thu, 24 Sep 2026 10:29:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=kQ6JQ6Lk; spf=pass (domain: gmail.com, ip: 74.125.226.231, mailfrom: twoerner@gmail.com) Received: by mail-ua2-f39.google.com with SMTP id a1e0cc1a2514c-982db8d3b1eso34493241.1 for ; Thu, 24 Sep 2026 10:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270947; x=1790875747; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=LLLvrqB1D4M5phhj3cKpYVhbXvyFa5H1x7ljUd2CXj0=; b=kQ6JQ6LkDNezSrg8IJSY/LsmW5hahacpF7OvZMKY1dd2CuxfO6YK7z24Nn/hPzlXDI tVgMc3Iaww8hiJISl8xW21ggsGSaa4Fh0dZh/8Omdd4Kws2oHspbPHRe2eDUKKiAt11d gcrxI58EPrgXBwmRAxxsOHhYF/InM+q/SFUj8kPssFbYBRs1IAubLyFXJz+4cWkPwUV9 dlvtAy06cQExD8EtPI3j0GXK6GwoWOXvJwjhbVhPFtZRRAoQY55tW+4nCuYqT8MvPAc/ 76OfqpaY7F/oTgpt0SIgfZBySX5FOy+s6pMMfJ6GvmU+K/NPvM1DY90YRc38TkzXIBYT tkcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270947; x=1790875747; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=LLLvrqB1D4M5phhj3cKpYVhbXvyFa5H1x7ljUd2CXj0=; b=oGSR2VPMWWAf8dJbHB9VO9ChW/RSLwCgYKoGTe1e2vb6AbWAQvlbOWYFqb6UZHgX1h YyDM5SSoZB2eb0CS277cGWVcBul3MpC5lW567IRz7IhESr4V+X2NqIq18RM8f1RUpxK2 MdGDsbdjjXf3FXpztiLlh+xBDr/+VEHMhE+LYvJWBhTF4gr77Rtxqf8XZbQ3ms/zIRWv Xa+UXONoExvJ9Mttk6DsrZQJujmls6kGFFjF8AyFo6OLgns2l1EAGT6jYbKBy1bgbMRY 9Ef4eCwSJiJAet1/irEYJBvS7KHs/uk+XVbpFgvGwCSzDD85u4LerUr09jBnKdMrKbpX I13A== X-Gm-Message-State: AFuF++k8nybmVqTT5gIDdLkqdNPSAYsLEg7zSfEKirpWRSurUkaEzz6Y HY9wgenkxkYSFfDZm5UaC0AWWeX7DMguSSZkdxfoYdLARqIPmgimyZgx1Du9Lg== X-Gm-Gg: AYBFou2nof5vifX/i1IC9EEqMCRru1FmPvonQXmCaVJXdYRgs9cSJnSllvHMPkiOs2j XwwSpgQVgTgVGsz75nOLgrrEHb008Y8ulIrKkhiK+H943vGvmKd5JsT896FIwgqpJllJVVG9xXP grjOC2W3ZFDvY/OiqS7nv6V/1XQtw5CnX+SQ5yJlgDNT4JCT4S4yRzSXc5eczaOqGL8M0gGh3z7 G2zCLy8QmIJhOnZJQIzcTs23RI5MvVI289BlxMdOxG7UYnM1nxCZ5ft3glSSLDuzeeHwbde41uM 4q2cL/HKuKmTCzNKN9R9kzH1QD40QLvaIU1JYAMEY9y09rZPfm6/RFrEKbtO0Ri9QCDC31znb9D qVKJkWUJ/K7OGG0otScbWK+rr0+xpRKMcYgSrh1jFjVx5msDdmcs+jHmL50zYftPGOXEbcafcXY Jlv02hpIxBVjDkX7mR4yb8HMYnNbzu7j+JN9Drs3i83Dp2YkXmW5J2NTIKK1fGWimEXucgc0byX fyA54nlgvyjXPKp8JKlbRFAexBnYZe2qJipXY/U X-Received: by 2002:a05:6102:3911:b0:7a7:1db6:c769 with SMTP id ada2fe7eead31-7af1e4e799emr1400524137.22.1790270946826; Thu, 24 Sep 2026 10:29:06 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:06 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Subject: [PATCH v3 06/10] docs: remove real accounts from the examples Date: Thu, 24 Sep 2026 13:28:49 -0400 Message-ID: <20260924172853.2665062-7-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:09 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10629 Examples across the manuals carry the account names of the people who wrote them, in home directory paths and in a shell prompt that also names a machine. Use "/home/user" and a bare "$", which is what the rest of the manuals already do. Two are left as they are: the autobuilder's service account, whose paths are about autobuilder output rather than somebody's machine, and a prompt whose command is a relative path, where the working directory the prompt carries is what says where the command runs. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner --- changes in v3: - the setup-layers prompt keeps its path, which is what says where the relative command runs changes in v2: - rebased on master-next; no other change --- documentation/dev-manual/debugging.rst | 4 +- documentation/dev-manual/layers.rst | 10 ++--- documentation/dev-manual/qemu.rst | 2 +- .../dev-manual/upgrading-recipes.rst | 18 ++++---- documentation/dev-manual/wic.rst | 44 +++++++++---------- documentation/kernel-dev/common.rst | 16 +++---- documentation/profile-manual/usage.rst | 2 +- .../ref-manual/devtool-reference.rst | 6 +-- documentation/ref-manual/faq.rst | 6 +-- documentation/ref-manual/variables.rst | 8 ++-- documentation/sdk-manual/extensible.rst | 6 +-- 11 files changed, 61 insertions(+), 61 deletions(-) diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 8412c997a51e..62e19a6c8a28 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst @@ -144,7 +144,7 @@ helpful during debugging. Variables that are exported to the environment are preceded by ``export`` in the output of ``bitbake-getvar``. See the following example:: - export CC="i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/ulf/poky/build/tmp/sysroots/qemux86" + export CC="i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/user/poky/build/tmp/sysroots/qemux86" Shell functions and tasks can also be inspected with the same mechanism:: @@ -522,7 +522,7 @@ task dependency mechanisms. .. code-block:: none - WARNING: /home/ulf/openembedded-core/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is tainted from a forced run + WARNING: /home/user/openembedded-core/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is tainted from a forced run The purpose of the warning is to let you know that the work directory diff --git a/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst index 185a63feb700..5c8bf32b41fc 100644 --- a/documentation/dev-manual/layers.rst +++ b/documentation/dev-manual/layers.rst @@ -916,11 +916,11 @@ shows the layers that are in your :ref:`structure-build-conf-bblayers.conf` file NOTE: Starting bitbake server... layer path priority ============================================================================================== - meta /home/scottrif/bitbake-builds/layers/openembedded-core/meta 5 - meta-poky /home/scottrif/bitbake-builds/layers/meta-yocto/meta-poky 5 - meta-yocto-bsp /home/scottrif/bitbake-builds/layers/meta-yocto/meta-yocto-bsp 5 - workspace /home/scottrif/bitbake-builds/build/workspace 99 - meta-scottrif /home/scottrif/bitbake-builds/build/meta-scottrif 6 + meta /home/user/bitbake-builds/layers/openembedded-core/meta 5 + meta-poky /home/user/bitbake-builds/layers/meta-yocto/meta-poky 5 + meta-yocto-bsp /home/user/bitbake-builds/layers/meta-yocto/meta-yocto-bsp 5 + workspace /home/user/bitbake-builds/build/workspace 99 + meta-scottrif /home/user/bitbake-builds/build/meta-scottrif 6 Adding the layer to this file enables the build system to locate the layer during the build. diff --git a/documentation/dev-manual/qemu.rst b/documentation/dev-manual/qemu.rst index 6d092b2d2034..d7e0b2f2f44f 100644 --- a/documentation/dev-manual/qemu.rst +++ b/documentation/dev-manual/qemu.rst @@ -151,7 +151,7 @@ available. Follow these general steps to run QEMU: determines the QEMU architecture (`MACHINE`) to be "qemux86-64" and the root filesystem type to be "vmdk":: - $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk + $ runqemu /home/user/vm/core-image-minimal-qemux86-64.wic.vmdk Switching Between Consoles ========================== diff --git a/documentation/dev-manual/upgrading-recipes.rst b/documentation/dev-manual/upgrading-recipes.rst index 0bdc1351ec7f..f4b9df241093 100644 --- a/documentation/dev-manual/upgrading-recipes.rst +++ b/documentation/dev-manual/upgrading-recipes.rst @@ -244,12 +244,12 @@ script. For example, suppose you use the ``nano.bb`` recipe from the ``meta-oe`` layer in the ``meta-openembedded`` repository. For this example, assume that the layer has been cloned into following area:: - /home/scottrif/bitbake-builds/layers/meta-openembedded + /home/user/bitbake-builds/layers/meta-openembedded The following command from your :term:`Build Directory` adds the layer to your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``):: - $ bitbake-layers add-layer /home/scottrif/bitbake-builds/layers/meta-openembedded/meta-oe + $ bitbake-layers add-layer /home/user/bitbake-builds/layers/meta-openembedded/meta-oe NOTE: Starting bitbake server... Parsing recipes: 100% |##########################################| Time: 0:00:55 Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors. @@ -265,7 +265,7 @@ directory automatically upgrades the recipe for you:: $ devtool upgrade nano -V 2.9.3 NOTE: Starting bitbake server... - NOTE: Creating workspace layer in /home/scottrif/bitbake-builds/build/workspace + NOTE: Creating workspace layer in /home/user/bitbake-builds/build/workspace Parsing recipes: 100% |##########################################| Time: 0:00:46 Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors. NOTE: Extracting current version source... @@ -277,8 +277,8 @@ directory automatically upgrades the recipe for you:: NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 74 tasks of which 72 didn't need to be rerun and all succeeded. Adding changed files: 100% |#####################################| Time: 0:00:00 - NOTE: Upgraded source extracted to /home/scottrif/bitbake-builds/build/workspace/sources/nano - NOTE: New recipe is /home/scottrif/bitbake-builds/build/workspace/recipes/nano/nano_2.9.3.bb + NOTE: Upgraded source extracted to /home/user/bitbake-builds/build/workspace/sources/nano + NOTE: New recipe is /home/user/bitbake-builds/build/workspace/recipes/nano/nano_2.9.3.bb .. note:: @@ -300,7 +300,7 @@ newly upgraded recipe:: . NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks - NOTE: nano: compiling from external source tree /home/scottrif/bitbake-builds/build/workspace/sources/nano + NOTE: nano: compiling from external source tree /home/user/bitbake-builds/build/workspace/sources/nano NOTE: Tasks Summary: Attempted 520 tasks of which 304 didn't need to be rerun and all succeeded. Within the ``devtool upgrade`` workflow, you can @@ -321,9 +321,9 @@ directory:: Parsing of 1432 .bb files complete (1431 cached, 1 parsed). 2041 targets, 56 skipped, 0 masked, 0 errors. NOTE: Adding new patch 0001-nano.bb-Stuff-I-changed-when-upgrading-nano.bb.patch NOTE: Updating recipe nano_2.9.3.bb - NOTE: Removing file /home/scottrif/bitbake-builds/layers/meta-openembedded/meta-oe/recipes-support/nano/nano_2.7.4.bb - NOTE: Moving recipe file to /home/scottrif/bitbake-builds/layers/meta-openembedded/meta-oe/recipes-support/nano - NOTE: Leaving source tree /home/scottrif/bitbake-builds/build/workspace/sources/nano as-is; if you no longer need it then please delete it manually + NOTE: Removing file /home/user/bitbake-builds/layers/meta-openembedded/meta-oe/recipes-support/nano/nano_2.7.4.bb + NOTE: Moving recipe file to /home/user/bitbake-builds/layers/meta-openembedded/meta-oe/recipes-support/nano + NOTE: Leaving source tree /home/user/bitbake-builds/build/workspace/sources/nano as-is; if you no longer need it then please delete it manually Using the ``devtool finish`` command cleans up the workspace and creates a patch diff --git a/documentation/dev-manual/wic.rst b/documentation/dev-manual/wic.rst index c13655f8730a..9161122d3166 100644 --- a/documentation/dev-manual/wic.rst +++ b/documentation/dev-manual/wic.rst @@ -520,13 +520,13 @@ file: ./mkefidisk-201804191017-sda.direct The following build artifacts were used to create the image(s): - ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs - BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share - KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 - NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native + ROOTFS_DIR: /home/user/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs + BOOTIMG_DIR: /home/user/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share + KERNEL_DIR: /home/user/yocto/build/tmp-glibc/deploy/images/qemux86 + NATIVE_SYSROOT: /home/user/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: The image(s) were created using OE kickstart file: - /home/stephano/yocto/openembedded-core/files/wic/mkefidisk.wks + /home/user/yocto/openembedded-core/files/wic/mkefidisk.wks The previous example shows the easiest way to create an image by running in cooked mode and supplying a kickstart file and the "-e" option to @@ -590,8 +590,8 @@ the lines that specify the target disk from which to boot: .. code-block:: console - $ cp /home/stephano/yocto/openembedded-core/files/wic/directdisk-gpt.wks \ - /home/stephano/yocto/openembedded-core/files/wic/directdisksdb-gpt.wks + $ cp /home/user/yocto/openembedded-core/files/wic/directdisk-gpt.wks \ + /home/user/yocto/openembedded-core/files/wic/directdisksdb-gpt.wks Next, the example modifies the ``directdisksdb-gpt.wks`` file and changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The @@ -625,13 +625,13 @@ Computing (nuc) :term:`MACHINE`: ./directdisksdb-gpt-201710090938-sdb.direct The following build artifacts were used to create the image(s): - ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs - BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share - KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 - NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native + ROOTFS_DIR: /home/user/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs + BOOTIMG_DIR: /home/user/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share + KERNEL_DIR: /home/user/yocto/build/tmp-glibc/deploy/images/qemux86 + NATIVE_SYSROOT: /home/user/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: The image(s) were created using OE kickstart file: - /home/stephano/yocto/openembedded-core/files/wic/directdisksdb-gpt.wks + /home/user/yocto/openembedded-core/files/wic/directdisksdb-gpt.wks Continuing with the example, you can now directly ``dd`` the image to a USB stick, or whatever media for which you built your image, and boot @@ -655,22 +655,22 @@ default output directory, which is the current directory: .. code-block:: console - $ wic create test.wks -o /home/stephano/testwic \ - --rootfs-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \ - --bootimg-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \ - --kernel-dir /home/stephano/yocto/build/tmp/deploy/images/qemux86 \ - --native-sysroot /home/stephano/yocto/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native + $ wic create test.wks -o /home/user/testwic \ + --rootfs-dir /home/user/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \ + --bootimg-dir /home/user/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \ + --kernel-dir /home/user/yocto/build/tmp/deploy/images/qemux86 \ + --native-sysroot /home/user/yocto/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: Creating image(s)... INFO: The new image(s) can be found here: - /home/stephano/testwic/test-201710091445-sdb.direct + /home/user/testwic/test-201710091445-sdb.direct The following build artifacts were used to create the image(s): - ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs - BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share - KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 - NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native + ROOTFS_DIR: /home/user/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs + BOOTIMG_DIR: /home/user/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share + KERNEL_DIR: /home/user/yocto/build/tmp-glibc/deploy/images/qemux86 + NATIVE_SYSROOT: /home/user/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native INFO: The image(s) were created using OE kickstart file: test.wks diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index 3de61cab08d6..c478e64d6577 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -1250,32 +1250,32 @@ Here is sample output from the :ref:`ref-tasks-kernel_configcheck` task: ---------- CONFIG_X86_TSC ----------------- Config: CONFIG_X86_TSC - From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc-cpu.cfg + From: /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc-cpu.cfg Requested value: CONFIG_X86_TSC=y Actual value: ---------- CONFIG_X86_BIGSMP ----------------- Config: CONFIG_X86_BIGSMP - From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg - /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig + From: /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg + /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig Requested value: # CONFIG_X86_BIGSMP is not set Actual value: ---------- CONFIG_NR_CPUS ----------------- Config: CONFIG_NR_CPUS - From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg - /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc.cfg - /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig + From: /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg + /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc.cfg + /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig Requested value: CONFIG_NR_CPUS=8 Actual value: CONFIG_NR_CPUS=1 ---------- CONFIG_SCHED_SMT ----------------- Config: CONFIG_SCHED_SMT - From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg - /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig + From: /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg + /home/user/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig Requested value: CONFIG_SCHED_SMT=y Actual value: diff --git a/documentation/profile-manual/usage.rst b/documentation/profile-manual/usage.rst index 4efaa6d10fce..7fdbe41da5e7 100644 --- a/documentation/profile-manual/usage.rst +++ b/documentation/profile-manual/usage.rst @@ -322,7 +322,7 @@ debug packages once built can be found in ``build/tmp/deploy/rpm/*`` on the host system. Find the ``busybox-dbg-...rpm`` file and copy it to the target. For example:: - [trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2-r2.core2_32.rpm root@192.168.1.31: + $ scp /home/user/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2-r2.core2_32.rpm root@192.168.1.31: busybox-dbg-1.20.2-r2.core2_32.rpm 100% 1826KB 1.8MB/s 00:01 Now install the debug RPM on the target:: diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index 62c3b707b9ff..c8ca7bad8c9c 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst @@ -460,7 +460,7 @@ Here is an example that resets the workspace directory that contains the $ devtool reset mtr NOTE: Cleaning sysroot for recipe mtr... - NOTE: Leaving source tree /home/scottrif/bitbake-builds/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually + NOTE: Leaving source tree /home/user/bitbake-builds/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually .. _devtool-finish-working-on-a-recipe: @@ -612,7 +612,7 @@ You can create a workspace layer anywhere by supplying a pathname with the command. The following command creates a new workspace layer named "new-workspace":: - $ devtool create-workspace /home/scottrif/new-workspace + $ devtool create-workspace /home/user/new-workspace .. _devtool-get-the-status-of-the-recipes-in-your-workspace: @@ -632,7 +632,7 @@ Here is sample output after using to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:: $ devtool status - mtr:/home/scottrif/bitbake-builds/build/workspace/sources/mtr (/home/scottrif/bitbake-builds/build/workspace/recipes/mtr/mtr_0.86.bb) + mtr:/home/user/bitbake-builds/build/workspace/sources/mtr (/home/user/bitbake-builds/build/workspace/recipes/mtr/mtr_0.86.bb) .. _devtool-search-for-available-target-recipes: diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index f8e047e27fed..3646286a6e0c 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst @@ -461,11 +461,11 @@ and related variables. To better understand this, consider the following two paths (artificially broken across lines for readability) where the first is relatively normal and the second is not:: - /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/ + /home/user/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/ 1.2.8-r0/sysroot-destdir/usr/bin - /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/ - zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/ + /home/user/poky-bootchart2/build/tmp/work/x86_64-linux/ + zlib-native/1.2.8-r0/sysroot-destdir/home/user/poky-bootchart2/ build/tmp/sysroots/x86_64-linux/usr/bin Even if the paths look unusual, they both are correct --- the first for diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index 7ba5c48fd8ed..ce17d713f399 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -888,10 +888,10 @@ system and gives an overview of their function and contents. Here is an example:: BBLAYERS = " \ - /home/scottrif/bitbake-builds/layers/meta \ - /home/scottrif/bitbake-builds/layers/meta-poky \ - /home/scottrif/bitbake-builds/layers/meta-yocto-bsp \ - /home/scottrif/bitbake-builds/layers/meta-mykernel \ + /home/user/bitbake-builds/layers/meta \ + /home/user/bitbake-builds/layers/meta-poky \ + /home/user/bitbake-builds/layers/meta-yocto-bsp \ + /home/user/bitbake-builds/layers/meta-mykernel \ " This example enables four layers, one of which is a custom, diff --git a/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst index 0eb9eda8d82a..8b8034707eab 100644 --- a/documentation/sdk-manual/extensible.rst +++ b/documentation/sdk-manual/extensible.rst @@ -149,7 +149,7 @@ architecture. The example assumes the SDK installer is located in Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.5 ========================================================================== Enter target directory for SDK (default: poky_sdk): - You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed [Y/n]? Y + You are about to install the SDK to "/home/user/poky_sdk". Proceed [Y/n]? Y Extracting SDK..............done Setting it up... Extracting buildtools... @@ -162,7 +162,7 @@ architecture. The example assumes the SDK installer is located in done SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. - $ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux + $ . /home/user/poky_sdk/environment-setup-core2-64-poky-linux .. note:: @@ -197,7 +197,7 @@ script is for an IA-based target machine using i586 tuning: .. code-block:: console - $ cd /home/scottrif/poky_sdk + $ cd /home/user/poky_sdk $ source environment-setup-core2-64-poky-linux SDK environment now set up; additionally you may now run devtool to perform development tasks. Run devtool --help for further details. From patchwork Thu Sep 24 17:28:50 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99197 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A656C9830E for ; Thu, 24 Sep 2026 17:29:19 +0000 (UTC) Received: from mail-ua2-f31.google.com (mail-ua2-f31.google.com [74.125.226.223]) by mx.groups.io with SMTP id smtpd.msgproc02-g2.3797.1790270949965673337 for ; Thu, 24 Sep 2026 10:29:10 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=SqEbkvVD; spf=pass (domain: gmail.com, ip: 74.125.226.223, mailfrom: twoerner@gmail.com) Received: by mail-ua2-f31.google.com with SMTP id a1e0cc1a2514c-97e96e461feso38213241.1 for ; Thu, 24 Sep 2026 10:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270949; x=1790875749; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=64MxxPrNvmnlVDbXMLHV2pp/Hz6Zcv3Nuc7Pln5mWmU=; b=SqEbkvVDbk1tDpb+WOSmDERChuXReDYpwXzfol/9HO4moSw9KNIds3+N0qGY/Qep1M nn6ZV/9b8IHISSLF8SGtghV9rr0RM6UR7xK5sejQMddbYutRtsGkMCzwX4v+V82Kz3qm xAYYETrjAx1c+SD3J3LK0tjqB4wsFXXLiJanTuhJoG7QyLGGs6eyRjkZo7kjJ45C+IgC kgAGM29QgbF/66S/uBpKUEziZquFTa4/Wr9wL75AIAn17f/HVJv3fiERROi0xDVIgBCz AlbWLQh0dNrW1M042VYTVJKqwncmpgD+xUxs+YGvlVIZuW5sJkrl7EjccsyYHVh9pWGR eRcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270949; x=1790875749; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=64MxxPrNvmnlVDbXMLHV2pp/Hz6Zcv3Nuc7Pln5mWmU=; b=mfISgW9D6VWScZuI7yci6iGfFoUNQPsX9nyPy4ZsKkhtm+1QpraTTOt4sA425Oi7hl 0gzuHymEUs8BXx/7V4IhBMgCB+yxVRKYrHyjkYt+MmbTV/ftSJsqCXKtdEts02opmzM+ vZHRgWtKCu1W2jQSE7HWC2k+QDGYswmMwv7zUgb+axvhORjqW7ALOM01iuNrSn6l2ijO TvSHNTCjXl1tQ3/7ihSbUlbhS7vCpoIWKE0SnZMN866O4OLu99HsNdPPsJ+zwZ4A7qpH oTZdzTdM/70Jdb4UNLkSIjgiVIZs8Kt6hjUgGqiBY3AH0XKp3INtVNVdhy78L3Pj/F0M LXOw== X-Gm-Message-State: AFuF++n3dH8qMtQUkNa+mbXxkFliA52gyez+KWACUJaSyaRLDLkRNZ23 yAq7btY3Rc/B0p1VCeeqTiWgLUwbc+uPthCzJ2EINM+sSpjawj+aZkeiQY1Bfw== X-Gm-Gg: AYBFou3BUUhZrWH6dcqvR20iyHIbLbqm7mrXucgKPFXNkb+Q1Fb4lOCL/VqPL61zN66 vzD2cYgtN9LPny/OkmvO78NIvbrSolm3AG4FETDbQK09GzaWZxLYYKBaY4q06gLnC4KWlNmM4f0 K2G5ArMQWywbL2V8n5eXhgj7lE65b3mn7lW6q46h2w5a3UIpBp8C2idkbc6Hoa/fEnC1aC1vhYM LWd0i7KLjzAHqTctlXcbpel5Vh8wlU4SKroLyVx3igugqnua2qUySzgnKELOytCY2SG2hcVQg5g 6gOeWiGntj8tKKmGdD2FVHdjzDbOi69OgG7hfyC0QjOysn2u6HT/i1FruRsgJ3gxNla+2wuA1nK eFI8WOee6LwgFMpUvD4v6h1pK+MzuwxYo8Ti5m5tMdc4nMnG6hctTazoqSSCqvKFzWRCoA5+D2d NL/ZYQsON8W6qGKvrg7j0wkGFzR/BUWpfuQTNBA/3pN7msUXSE+puAN+py3sY+ktgTmi+6XpJPs XonCx8Vd0gP0l/nkyKwZC3rqiZWGKSlxdiAtomA X-Received: by 2002:a05:6102:5491:b0:7a1:f980:e93f with SMTP id ada2fe7eead31-7af1ebf59ddmr1380347137.27.1790270948647; Thu, 24 Sep 2026 10:29:08 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:07 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Cc: Quentin Schulz Subject: [PATCH v3 07/10] kernel-dev: give each example block one thing to hold Date: Thu, 24 Sep 2026 13:28:50 -0400 Message-ID: <20260924172853.2665062-8-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:19 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10630 Several kernel metadata examples put a filename label inside the block, and some go on to hold more than one file, in more than one language, under a single "::". A block shaped that way is not any one language, so it can only ever be shown unhighlighted. Split them into a block each, dedent what is left, and move the filename to the code-block caption, which keeps it attached to the block it names and renders it inside the block's frame. The theme centres a caption in italics, which reads as prose, so it is restyled to look like the filename it is. AI-Generated: codex/claude-opus 5 (xhigh) Reviewed-by: Quentin Schulz # rST Signed-off-by: Trevor Woerner --- changes in v3: - none changes in v2: - the caption takes the theme's whole font stack; the shortened copy dropped Liberation Mono, which is why it rendered in a different face --- documentation/kernel-dev/advanced.rst | 139 ++++++++++-------- .../sphinx-static/theme_overrides.css | 28 ++++ 2 files changed, 104 insertions(+), 63 deletions(-) diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst index 321033b7bd49..ecd0137fa5fd 100644 --- a/documentation/kernel-dev/advanced.rst +++ b/documentation/kernel-dev/advanced.rst @@ -216,24 +216,28 @@ used with the ``linux-yocto-4.12`` kernel as defined outside of the recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the ``cfg`` directory of the ``yocto-4.12`` branch in the -``yocto-kernel-cache`` Git repository:: +``yocto-kernel-cache`` Git repository. + +.. code-block:: + :caption: cfg/smp.scc + + define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds" + define KFEATURE_COMPATIBILITY all - cfg/smp.scc: - define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds" - define KFEATURE_COMPATIBILITY all + kconf hardware smp.cfg - kconf hardware smp.cfg +.. code-block:: + :caption: cfg/smp.cfg - cfg/smp.cfg: - CONFIG_SMP=y - CONFIG_SCHED_SMT=y - # Increase default NR_CPUS from 8 to 64 so that platform with - # more than 8 processors can be all activated at boot time - CONFIG_NR_CPUS=64 - # The following is needed when setting NR_CPUS to something - # greater than 8 on x86 architectures, it should be automatically - # disregarded by Kconfig when using a different arch - CONFIG_X86_BIGSMP=y + CONFIG_SMP=y + CONFIG_SCHED_SMT=y + # Increase default NR_CPUS from 8 to 64 so that platform with + # more than 8 processors can be all activated at boot time + CONFIG_NR_CPUS=64 + # The following is needed when setting NR_CPUS to something + # greater than 8 on x86 architectures, it should be automatically + # disregarded by Kconfig when using a different arch + CONFIG_X86_BIGSMP=y You can find general information on configuration fragment files in the ":ref:`kernel-dev/common:creating configuration fragments`" section. @@ -278,36 +282,39 @@ kernel as defined outside of the recipe space (i.e. in the ``patches/build`` directory of the ``yocto-4.12`` branch in the ``yocto-kernel-cache`` Git repository. -The following listings show the ``build.scc`` file and part of the -``modpost-mask-trivial-warnings.patch`` file:: +.. code-block:: + :caption: patches/build/build.scc - patches/build/build.scc: - patch arm-serialize-build-targets.patch - patch powerpc-serialize-image-targets.patch - patch kbuild-exclude-meta-directory-from-distclean-processi.patch + patch arm-serialize-build-targets.patch + patch powerpc-serialize-image-targets.patch + patch kbuild-exclude-meta-directory-from-distclean-processi.patch - # applied by kgit - # patch kbuild-add-meta-files-to-the-ignore-li.patch + # applied by kgit + # patch kbuild-add-meta-files-to-the-ignore-li.patch - patch modpost-mask-trivial-warnings.patch - patch menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch + patch modpost-mask-trivial-warnings.patch + patch menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch - patches/build/modpost-mask-trivial-warnings.patch: - From bd48931bc142bdd104668f3a062a1f22600aae61 Mon Sep 17 00:00:00 2001 - From: Paul Gortmaker - Date: Sun, 25 Jan 2009 17:58:09 -0500 - Subject: [PATCH] modpost: mask trivial warnings +and part of the patch it names: - Newer HOSTCC will complain about various stdio fcns because - . - . - . - char *dump_write = NULL, *files_source = NULL; - int opt; - -- - 2.10.1 +.. code-block:: + :caption: patches/build/modpost-mask-trivial-warnings.patch - generated by cgit v0.10.2 at 2017-09-28 15:23:23 (GMT) + From bd48931bc142bdd104668f3a062a1f22600aae61 Mon Sep 17 00:00:00 2001 + From: Paul Gortmaker + Date: Sun, 25 Jan 2009 17:58:09 -0500 + Subject: [PATCH] modpost: mask trivial warnings + + Newer HOSTCC will complain about various stdio fcns because + . + . + . + char *dump_write = NULL, *files_source = NULL; + int opt; + -- + 2.10.1 + + generated by cgit v0.10.2 at 2017-09-28 15:23:23 (GMT) The description file can include multiple patch statements where each statement handles a single @@ -325,16 +332,18 @@ Features Features are complex kernel Metadata types that consist of configuration fragments, patches, and possibly other feature description files. As an -example, consider the following generic listing:: +example, consider the following generic listing: + +.. code-block:: + :caption: features/myfeature.scc - features/myfeature.scc - define KFEATURE_DESCRIPTION "Enable myfeature" + define KFEATURE_DESCRIPTION "Enable myfeature" - patch 0001-myfeature-core.patch - patch 0002-myfeature-interface.patch + patch 0001-myfeature-core.patch + patch 0002-myfeature-interface.patch - include cfg/myfeature_dependency.scc - kconf non-hardware myfeature.cfg + include cfg/myfeature_dependency.scc + kconf non-hardware myfeature.cfg This example shows how the ``patch`` and ``kconf`` commands are used as well as how an additional feature description file is included with the @@ -873,17 +882,19 @@ new branch as the :term:`KBRANCH` to use for the board as follows:: KBRANCH = "mynewbranch" Another method is to use the ``branch`` command in the BSP -description:: +description: - mybsp.scc: - define KMACHINE mybsp - define KTYPE standard - define KARCH i386 - include standard.scc +.. code-block:: + :caption: mybsp.scc - branch mynewbranch + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + include standard.scc + + branch mynewbranch - include mybsp-hw.scc + include mybsp-hw.scc If you find yourself with numerous branches, you might consider using a hierarchical branching system similar to what the Yocto Linux Kernel Git @@ -925,18 +936,20 @@ that have to be regularly updated. The Yocto Project Linux kernel tools provide for this with the ``git merge`` command. To merge a feature branch into a BSP, insert the ``git merge`` command -after any ``branch`` commands:: +after any ``branch`` commands: - mybsp.scc: - define KMACHINE mybsp - define KTYPE standard - define KARCH i386 - include standard.scc +.. code-block:: + :caption: mybsp.scc + + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + include standard.scc - branch mynewbranch - git merge myfeature + branch mynewbranch + git merge myfeature - include mybsp-hw.scc + include mybsp-hw.scc SCC Description File Reference ============================== diff --git a/documentation/sphinx-static/theme_overrides.css b/documentation/sphinx-static/theme_overrides.css index f9e067239b8e..3912872e1890 100644 --- a/documentation/sphinx-static/theme_overrides.css +++ b/documentation/sphinx-static/theme_overrides.css @@ -107,6 +107,34 @@ section#welcome-to-the-yocto-project-documentation p.caption { display: none; } +/* A code-block caption names the file the block came from, so it + should read as a filename rather than as prose, and sit on the block + it titles rather than floating above it. */ +.rst-content .literal-block-wrapper .code-block-caption { + font-style: normal; + font-family: SFMono-Regular, Menlo, Monaco, Consolas, + Liberation Mono, Courier New, Courier, monospace; + font-size: 80%; + text-align: left; + color: #e6edf3; + background: #2b3137; + padding: .45em .9em; + margin: 0; + line-height: 1.5; + border-radius: 4px 4px 0 0; +} + +.rst-content .literal-block-wrapper .code-block-caption .headerlink { + color: #93a1ad; +} + +/* No gap and no doubled border between a caption and its block. */ +.rst-content .literal-block-wrapper .code-block-caption + div[class^=highlight] { + margin-top: 0; + border-top: none; + border-radius: 0 0 4px 4px; +} + @media screen { .wy-nav-content { max-width: 1000px; From patchwork Thu Sep 24 17:28:51 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99198 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 891A3C98321 for ; Thu, 24 Sep 2026 17:29:19 +0000 (UTC) Received: from mail-ua2-f43.google.com (mail-ua2-f43.google.com [74.125.226.235]) by mx.groups.io with SMTP id smtpd.msgproc02-g2.3798.1790270951397177297 for ; Thu, 24 Sep 2026 10:29:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=FLnjRT0e; spf=pass (domain: gmail.com, ip: 74.125.226.235, mailfrom: twoerner@gmail.com) Received: by mail-ua2-f43.google.com with SMTP id a1e0cc1a2514c-98531196e6aso35161241.2 for ; Thu, 24 Sep 2026 10:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270950; x=1790875750; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=FRYlRZ/sVKf9jkcGldiO64rkotBICjDkz35RxCANhvk=; b=FLnjRT0er382/B8UMq4AOb3eiUnhcLad1N7uPEUO/oxCCelKaPfEtGAizBIZeJB7XE sPnbWXCTBUOA96/Ma1kUVo2as7QwNz+fuYkL6Ar/pxqOTnuhMa00rA5VY4f0f4y9EGRX KR19TFeqhGlJuSz1UoTmn1GEguDumueM5xEvXOmHMg6mSqF2PW0yGklVQJCS1//fMoDo XFV2G50aUVc+uW/k45RM9PJBVU2I2ho4UQhfOIVms4MmhjbQ7NhwIDuJRZ/L/5qkfZoy r327d0uIJrdTgi0c8dfhbp0WWGfekycvHQTWhY19v0Zfg0BrieEHrLWlsmG2aXPliH/a EanQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270950; x=1790875750; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=FRYlRZ/sVKf9jkcGldiO64rkotBICjDkz35RxCANhvk=; b=nlvrcnUz67OTcMRPdFTiFCnGEkXojIRgivuLIC9qFHbDbcQBlL5eyldtrYwvgxJhIj bkDa9UZPTKyeSMOIHZGicneTb3lsKyE5XdB6dTlcbkzhstwk2/rG82X2M5R0xLTyXe8H K7AKM4NQoOzXHV1CAq4AdkP5RWBOeqcBKfllSejhTRT2pgjav4tvWxxmZ9ar1BkSKjs5 aXBcLQW77Oh1qpgy0YMsRWNGmQgK/zt8TWZa16Xts275taD8t7xUPyB63Lqi3fUkhbpy aIRIVi81FjPkAZgBygLA9BYpAZKhk4PFqaY/OBQGndeipMepKIofzA3PhiqacWEU9YZ0 zgmQ== X-Gm-Message-State: AFuF++lF+VXTx3U95BBquQ5aovSBFlkVaSaPNeQHsBHWVDDCWAA/9Xgx BfsPUptt4e0jrI7KnyVpAcvbYdKUtMJ7lhk/QsgQECYEzrfZ1khokVFWMauq6A== X-Gm-Gg: AYBFou1u9RLLKo9DaMYm+PrtLoRmRof0706A32M4+RdTM2cw85vx6nHgDyHw5xw0raL VZuUkNmyr+VHwomvzC8l/t5H6aitiSf+d3yiYtXL7ELa7iaKqiYPPOXe2cLrIce71enKcIsgPZ/ 1+dzNJxnfBxRfYLSrYlAh+jmYQdFnOrMvRsRHqdiJViRcSTSeegOEKRLSbKPDwa1U2F12tzhQQf UwOwzIYwU5FmF/F/X0wVDeqKHX5M4zrY5Fn2nzvlg9KiB0PpimmSLkKr0O7L1knWsgGD3bdKA6Q ifsgB82QZSmNfuA63NjGgHExMvUZodihAXmFvkMQ6OEHsM8x97Di/lzRmzppx5GAx56hUjW8dpW 3W5LnI1zRxUnBmVIP9rlr44UBq0I9uWvx4FJQqR3pcxVrCdRIl1UXTxhW8ArQdlbgPHUf/mPPKy eHER4/QQvl52oKFfmGzJjs2uuRDCSZkvYO8Q+t4geisnLuUy0Ui/e15j11NPIGuLQH83TavzLqi ym3V3YCNCvpp9GV7FqCPOAqjJKhai0l8Tde96hf X-Received: by 2002:a05:6102:d89:b0:7a1:f7d2:e83c with SMTP id ada2fe7eead31-7af1dadc07fmr1578927137.28.1790270950279; Thu, 24 Sep 2026 10:29:10 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:09 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Cc: Quentin Schulz Subject: [PATCH v3 08/10] ref-manual: put the ARCHIVER_MODE comments on their own lines Date: Thu, 24 Sep 2026 13:28:51 -0400 Message-ID: <20260924172853.2665062-9-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:19 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10631 BitBake has no inline comments. A "#" after a value is not stripped and does not end the statement: the parser simply fails to match the line, so each of these varflag examples would be rejected outright if copied into a configuration file. Move each explanation to the line above the setting it describes, which parses and reads the same. AI-Generated: codex/claude-opus 5 (xhigh) Reviewed-by: Quentin Schulz Signed-off-by: Trevor Woerner --- changes in v3: - a blank line separates each comment from the setting above it changes in v2: - the srpm varflag is no longer in this block, having been removed upstream in d5216e3fd4be --- documentation/ref-manual/variables.rst | 27 +++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index ce17d713f399..8f6f4e5998d5 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -158,13 +158,26 @@ system and gives an overview of their function and contents. original source, configured source, and so forth by employing the following variable flags (varflags):: - ARCHIVER_MODE[src] = "original" # Uses original (unpacked) source files. - ARCHIVER_MODE[src] = "patched" # Uses patched source files. This is the default. - ARCHIVER_MODE[src] = "configured" # Uses configured source files. - ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and do_patch. - ARCHIVER_MODE[diff-exclude] ?= " ..." # Lists files and directories to exclude from diff. - ARCHIVER_MODE[dumpdata] = "1" # Uses environment data. - ARCHIVER_MODE[recipe] = "1" # Uses recipe and include files. + # Uses original (unpacked) source files. + ARCHIVER_MODE[src] = "original" + + # Uses patched source files. This is the default. + ARCHIVER_MODE[src] = "patched" + + # Uses configured source files. + ARCHIVER_MODE[src] = "configured" + + # Uses patches between do_unpack and do_patch. + ARCHIVER_MODE[diff] = "1" + + # Lists files and directories to exclude from diff. + ARCHIVER_MODE[diff-exclude] ?= " ..." + + # Uses environment data. + ARCHIVER_MODE[dumpdata] = "1" + + # Uses recipe and include files. + ARCHIVER_MODE[recipe] = "1" For information on how the variable works, see the ``meta/classes/archiver.bbclass`` file in :term:`OpenEmbedded-Core From patchwork Thu Sep 24 17:28:52 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99199 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B311C98318 for ; Thu, 24 Sep 2026 17:29:29 +0000 (UTC) Received: from mail-ua2-f12.google.com (mail-ua2-f12.google.com [74.125.226.204]) by mx.groups.io with SMTP id smtpd.msgproc01-g2.3770.1790270968063828981 for ; Thu, 24 Sep 2026 10:29:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=hX6Z2clt; spf=pass (domain: gmail.com, ip: 74.125.226.204, mailfrom: twoerner@gmail.com) Received: by mail-ua2-f12.google.com with SMTP id a1e0cc1a2514c-97e97e2c7d4so61636241.1 for ; Thu, 24 Sep 2026 10:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270967; x=1790875767; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=YOMAO0KYNHaTm/dxeUCoFs3hakcUclZRCM9fFCJvjbw=; b=hX6Z2cltJ3uWoVSTxNSWrg1ePNhGBVXE4rQpuMNRpnhx0GWP92NsccE+b7+slDkfmt nFMqPYQK+qDmFwnG41LcqP3Z7PCUGD38xQ8Vl5VEorvRcj4RKpcJ9IGEtbzzpnGM+UP+ VhobdhI3eMFFfe8SpxFgGH1h0NBmEYDVFedI+w8cX/bQ9CZnsgW5kLyJG8gdsWSzOXFf glXzB286UIYS/lFBjPZle1xlomyyiwQdYts6g0+hFqkK8NY1nxr0CuJ8pJEDM47u6gsY teOdabP77B431kPnLDAKnXQsWtrxwy1TYRIKjI4IAj5wkT9wB7+ftOq8L3N+dHvovuUc 2SvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270967; x=1790875767; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=YOMAO0KYNHaTm/dxeUCoFs3hakcUclZRCM9fFCJvjbw=; b=2dEV8rV7taALF2mAwcWZP94VlY2ttP2tdM8uFsC8ZFrK6q2SATfCbkOz1XVRYc5o4p QuDc/DnjepU/Jk7OSnDkje2o0/ZrFFpYjRhJzWbZb3exkwWC52CflpHIIQafKX74B0ag br0vl+TeW8i//jsZ1FWv4g9Qg8dEcTN/whO42jt8QQr9mVjDJ2dD7NLy3/cSpGf1LasB WzmN/RQrynGve/A9ytPsbpB723nl9OUz9OK8rzDLKFI6nvQ07mziogjO82LFeZkMqkgX lDKEYWNc/BhDYCEWDs5KhSEvn6wfeOV2L+zzADwjRTgb142ooItGCLFc3hee2HxXJzcG Z7WQ== X-Gm-Message-State: AFuF++mLrW12Zpxhc6zKKgQq1WA8RuLHSgk4AyJoOK9nT6LC7+oTehMx qwy4yiqvgqQkxWlhpxTYOCwRBFztRbnhkKt7dERE/7O0fxDoq8t1JWnWaYUHQA== X-Gm-Gg: AYBFou27bE9vRsJHMBkwRg+OPr5mM99TSA6KZQDuRVGA7hDeu/T9H/ij8mSFcpBg8I7 nUGqzrDcaqAv9no/xhxrE0nbtSXQqNWVuCXGiYd65dPhG2EeVr5Jn17I+G77j9rU7yS/wsKlRZ3 FUy3zuV6y4XzdUWF1fPs3tJBOrwlU4mRvAW4rD7//dT/J7U3rUQrbIeCa9U9S+Ko8lHHoR14/Bi uRiqnZIAQHEM3YqGzuqmGVJrpbfcj0ytuEKmHpEkrUMPkSo+ghZJg6O0LC4ulZ/50uOvEXx11Mk mehu2rGtoaimmlp0toHh3+byWZO5/6MYozUGoen+eyBLwpQXnp3DRGL/Nl/wtf1z3YIgXz3IcLt 6uyRQPTfFt2jkG60UC1kozZCpxcaG0DB3Naausrs0sX40xaMshtz7l6zWxE4A9oPa/QmkTzvPVz FegZ0dpXfIm6oVbtB+TqfQMoqf/9E4agOI6r0R8/rXSWnqlXKVFQyCkvPO/S9Lp4purpOfkHhLr TqybX4Di1YaZ5TcAkYsA2wfmRbMm2Af+PPZZDdz X-Received: by 2002:a05:6102:5346:b0:79b:f57e:ea17 with SMTP id ada2fe7eead31-7af1c6921f0mr1764246137.3.1790270951818; Thu, 24 Sep 2026 10:29:11 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:10 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Subject: [PATCH v3 09/10] ref-manual: drop "partition" as a wic kickstart command Date: Thu, 24 Sep 2026 13:28:52 -0400 Message-ID: <20260924172853.2665062-10-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:29 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10632 The kickstart reference documents "partition" as a synonym for "part". wic does not accept it: its parser registers only part, bootloader, and include, so a .wks line beginning "partition" fails with an invalid-choice error. The synonym was real while wic used a bundled pykickstart, whose command table mapped both spellings to one handler. Replacing that with a parser carrying only the options wic uses kept "part" alone, and the manual was not updated to match. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner --- changes in v3: - back in the series: applied on 2026-09-22, then unapplied by the master-next rewind --- documentation/ref-manual/kickstart.rst | 9 ++++----- documentation/ref-manual/variables.rst | 2 +- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/documentation/ref-manual/kickstart.rst b/documentation/ref-manual/kickstart.rst index e7cba555a6e1..14aff6025f18 100644 --- a/documentation/ref-manual/kickstart.rst +++ b/documentation/ref-manual/kickstart.rst @@ -16,14 +16,13 @@ modifications to reflect Wic capabilities. You can see the original documentation for those commands at the following link: https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html -Command: part or partition -========================== +Command: part +============= -Either of these commands creates a partition on the system and uses the +This command creates a partition on the system and uses the following syntax:: part [mntpoint] - partition [mntpoint] If you do not provide mntpoint, Wic creates a partition but does not mount it. @@ -54,7 +53,7 @@ Here is an example that uses "/" as the mountpoint. The command uses part / --source rootfs --ondisk sdb --fstype=ext3 --label platform --align 1024 Here is a list that describes other supported options you can use with -the ``part`` and ``partition`` commands: +the ``part`` command: - ``--size``: The minimum partition size. Specify as an integer value optionally followed by one of the units "k" / "K" for kibibyte, diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index 8f6f4e5998d5..5339721f48b9 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -4587,7 +4587,7 @@ system and gives an overview of their function and contents. When using Wic tool, beware that a second overhead factor is also applied. This overhead value is defined by the ``--overhead-factor`` option, which defaults to "1.3" when omitted. See the - :ref:`ref-manual/kickstart:command: part or partition` chapter in + :ref:`ref-manual/kickstart:command: part` chapter in :doc:`/ref-manual/kickstart` for details. :term:`IMAGE_PKGTYPE` From patchwork Thu Sep 24 17:28:53 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trevor Woerner X-Patchwork-Id: 99200 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C507C98321 for ; Thu, 24 Sep 2026 17:29:29 +0000 (UTC) Received: from mail-ua2-f12.google.com (mail-ua2-f12.google.com [74.125.226.204]) by mx.groups.io with SMTP id smtpd.msgproc01-g2.3772.1790270969173303134 for ; Thu, 24 Sep 2026 10:29:29 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20251104 header.b=VFfbL4l4; spf=pass (domain: gmail.com, ip: 74.125.226.204, mailfrom: twoerner@gmail.com) Received: by mail-ua2-f12.google.com with SMTP id a1e0cc1a2514c-97ea5bd53b4so43857241.0 for ; Thu, 24 Sep 2026 10:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790270968; x=1790875768; darn=lists.yoctoproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=evrITKAmrmrAZEbz6xgdJyqZke7wj7FiYh0+udie8Uw=; b=VFfbL4l4vzWmiajhQFg3ViQloayCV8A2a03NpXftTloP90rHerJED7HA3i0OXPtlap rCfvnqTS1CnAUWCWa8ZkP0dTcbebOW6REMezRj23YjdgouAt02k2CnAg4QlZ96nl7euD c2mgQ1j1wvPik47fzQhg1YDOyLFNWtq1qRnSP7vByC3kw6+uZt/4sJadEf8V950DAXal pjq/TEbPslqhRSlOWxwgpTAv/l2GpuyvZ4xJKRXXWW8aK8BF6gfDBAt40SZnho0v20lG RCp9QtgjQqhNYeXeg+48BTWZK8HMX8Bz+loR+oYI34itsXbVSsXitiorlpQbpHz7LfOW MJ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790270968; x=1790875768; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=evrITKAmrmrAZEbz6xgdJyqZke7wj7FiYh0+udie8Uw=; b=mqTHuZGQd6y4FnMSs+3QbMR3RQ2uNI2vnaqoFsyBzr+d830SRKM3hCh9wlhmjEDuyR dpegwUPuCD6Gn7mKYjhxtySBU2SNeG6DkQmfXwjiWKCfZCx8dJJ1LHy+FVbPYRzwl4zO oFnk3DFw0glcAg0tvmmJrSHtaiza6pl2iSwnqqEmKVWT9aC5WsrD89IoIdfk76wUnaAU sJxafUJKt9SWUJ1VhKDmxxN/vVRfMldDyzDWvl478jeHog6GMTaIMjqacOLIUUHYrqmG p+E32LGx10cRPwqzaa87+kIAhbcJZCHsyOtJKQEUGedP9P+sQRgyZHiGi4MlTWxIbuPr edMA== X-Gm-Message-State: AFuF++mhvM3GrGqkXDB6JyEub0mE2kT+pIAbpk3npL1LRk/09TJBz72v IrsvWjglR3sxTFCLRLIj0uFEmrZ4BrbEXI/LAWRcSYdaUVZZtFvmO2WrnASTWQ== X-Gm-Gg: AYBFou2Esj/w9RYjnwOrDJYt3ogZwWQTzahn++WO3B+I430SqhyS8zIy3a8iooICHyz xEppPHOdABHf+xh+VJnCqGj1GYuIOqNgEaQ3Kv8V80/Zbxr/w6Nd+HQGv1N862I+P0hMmvk2sLw cOpteqO2Z+pBuYCSPbNaRlCIeRX97iNh2MY/LX10Y1J7u6xHXRmPU4Bhm+SQRHij1siraz5cE4k 9Is3/rkN7Ep9pK+NkFPCSJ41hh08mJh2Hqyv7oRdL6TDDjCInLzUY6KqdjH3aS6l0YlL+r1Hh58 4fBe+Uo3B5diezEMfl0+I5Fgv9tZV9QKqLQ51+Rp4rPdnF1IdZByR2FwmLHaO7nqTJqWX6kV4zJ v6ui+LaQGbiCBSwuAiaQVURCeBfAptM09f9nbyncxy1mhQHwYjYuWIoETcLTeZ2/mgxvX2gtvS7 DTUKkfxC1yutb25AiPOiZPR+k9iP2DOtw0LXFwQCjeWeWu9fDKqueG6o11pPF7+9PW5an/shick DuTliON9yF1FQQpbFS96b/CW5hnt5KvLKqnnrRw X-Received: by 2002:a05:6102:a47:b0:7a5:4fe2:b380 with SMTP id ada2fe7eead31-7af1eff6903mr1555033137.26.1790270967878; Thu, 24 Sep 2026 10:29:27 -0700 (PDT) Received: from localhost.localdomain (pppoe-209-91-167-254.vianet.ca. [209.91.167.254]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-98530725838sm1797974241.0.2026.09.24.10.29.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 10:29:27 -0700 (PDT) From: Trevor Woerner To: docs@lists.yoctoproject.org Subject: [PATCH v3 10/10] dev-manual: indent a list continuation so the code block ends Date: Thu, 24 Sep 2026 13:28:53 -0400 Message-ID: <20260924172853.2665062-11-twoerner@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260924172853.2665062-1-twoerner@gmail.com> References: <20260924172853.2665062-1-twoerner@gmail.com> MIME-Version: 1.0 List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Sep 2026 17:29:29 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/10633 The second line of the enumerated item is not indented, so the item ends after its first line and the "::" opens a literal block at the top level. Everything more indented then belongs to it: the assignment, the paragraph explaining what packageformat may be, and the note beneath them. They render as preformatted text inside the code box, and the note loses its admonition styling. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner --- changes in v3: - back in the series: applied on 2026-09-22, then unapplied by the master-next rewind --- documentation/dev-manual/packages.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst index 8cd90b9f25b1..380d806be041 100644 --- a/documentation/dev-manual/packages.rst +++ b/documentation/dev-manual/packages.rst @@ -561,7 +561,7 @@ to use. In your configuration, you use the variable to specify the format: #. Select the desired package format as follows from your -:ref:`structure-build-conf-local.conf` or distro :term:`configuration file`:: + :ref:`structure-build-conf-local.conf` or distro :term:`configuration file`:: PACKAGE_CLASSES ?= "package_packageformat"