contributor-guide: fix type "maintainance" to "maintenance"

Correct "maintainance" typo in recipe-style-guide.rst.

(From yocto-docs rev: f39ba5141cd518f08d491b2255a4acd74442e87b)

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit d7376cca64a0784e59d4fd60b9baefb4da2ce289)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Paul Barker <paul@pbarker.dev>

documentation/brief-yoctoprojectqs/index.rst

@@ -61,8 +61,8 @@ following requirements:
 
    -  Git &MIN_GIT_VERSION; or greater
    -  tar &MIN_TAR_VERSION; or greater
-   -  Python &MIN_PYTHON_VERSION; or greater.
-   -  gcc &MIN_GCC_VERSION; or greater.
+   -  Python &MIN_PYTHON_VERSION; or greater
+   -  gcc &MIN_GCC_VERSION; or greater
    -  GNU make &MIN_MAKE_VERSION; or greater
 
 If your build host does not satisfy all of the above version

documentation/contributor-guide/recipe-style-guide.rst

@@ -315,7 +315,7 @@ following status strings:
    No determination has been made yet, or patch has not yet been submitted to
    upstream.
 
-   Keep in mind that every patch submitted upstream reduces the maintainance
+   Keep in mind that every patch submitted upstream reduces the maintenance
    burden in OpenEmbedded and Yocto Project in the long run, so this patch
    status should only be used in exceptional cases if there are genuine
    obstacles to submitting a patch upstream; the reason for that should be
@@ -346,7 +346,7 @@ following status strings:
    The patch is not appropriate for upstream, include a brief reason on the
    same line enclosed with ``[]``. In the past, there were several different
    reasons not to submit patches upstream, but we have to consider that every
-   non-upstreamed patch means a maintainance burden for recipe maintainers.
+   non-upstreamed patch means a maintenance burden for recipe maintainers.
    Currently, the only reasons to mark patches as inappropriate for upstream
    submission are:
 

documentation/index.rst

@@ -17,7 +17,7 @@ Welcome to the Yocto Project Documentation
    Quick Build <brief-yoctoprojectqs/index>
    what-i-wish-id-known
    transitioning-to-a-custom-environment
-   Yocto Project Software Overview <https://www.yoctoproject.org/software-overview/>
+   Yocto Project Technical Overview <https://www.yoctoproject.org/development/technical-overview/>
    Tips and Tricks Wiki <https://wiki.yoctoproject.org/wiki/TipsAndTricks>
 
 .. toctree::

documentation/migration-guides/release-4.0.rst

@@ -41,3 +41,4 @@ Release 4.0 (kirkstone)
    release-notes-4.0.32
    release-notes-4.0.33
    release-notes-4.0.34
+   release-notes-4.0.35

documentation/migration-guides/release-notes-4.0.35.rst

@@ -0,0 +1,198 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.35 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  alsa-lib: Fix :cve_nist:`2026-25068`
+-  busybox: Fix :cve_nist:`2025-60876`
+-  curl: Fix :cve_nist:`2025-14524`, :cve_nist:`2026-1965`, :cve_nist:`2026-3783` and
+   :cve_nist:`2026-3784`
+-  ffmpeg: Fix :cve_nist:`2025-10256`
+-  gdk-pixbuf: Fix :cve_nist:`2025-6199`
+-  inetutils: Fix :cve_nist:`2026-28372`
+-  libarchive: Fix :cve_nist:`2026-4111`
+-  libpam: Fix :cve_nist:`2024-10963`
+-  linux-yocto/5.15: Fix :cve_nist:`2025-40082`, :cve_nist:`2025-68358`, :cve_nist:`2025-71089`,
+   :cve_nist:`2025-71220`, :cve_nist:`2025-71222`, :cve_nist:`2025-71232`, :cve_nist:`2025-71233`,
+   :cve_nist:`2025-71235`, :cve_nist:`2025-71236`, :cve_nist:`2025-71237`, :cve_nist:`2025-71238`,
+   :cve_nist:`2026-23111`, :cve_nist:`2026-23112`, :cve_nist:`2026-23169`, :cve_nist:`2026-23190`,
+   :cve_nist:`2026-23193`, :cve_nist:`2026-23198`, :cve_nist:`2026-23202`, :cve_nist:`2026-23206`,
+   :cve_nist:`2026-23209`, :cve_nist:`2026-23216`, :cve_nist:`2026-23221`, :cve_nist:`2026-23222`,
+   :cve_nist:`2026-23228`, :cve_nist:`2026-23229`, :cve_nist:`2026-23231`, :cve_nist:`2026-23234`,
+   :cve_nist:`2026-23235`, :cve_nist:`2026-23236`, :cve_nist:`2026-23237` and :cve_nist:`2026-23238`
+-  ncurses: Fix :cve_nist:`2025-69720`
+-  python3: Fix :cve_nist:`2024-6923`, :cve_nist:`2025-15282`, :cve_nist:`2025-59375`,
+   :cve_nist:`2026-0865`, :cve_nist:`2026-24515` and :cve_nist:`2026-25210`
+-  python3-pip: Fix :cve_nist:`2026-1703`
+-  python3-pyopenssl: Fix :cve_nist:`2026-27448` and :cve_nist:`2026-27459`
+-  sqlite3: Fix :cve_nist:`2025-70873`
+-  tiff: Fix :cve_nist:`2025-61143` and :cve_nist:`2025-61144`
+-  vim: Fix :cve_nist:`2026-25749`, :cve_nist:`2026-26269`, :cve_nist:`2026-28418`,
+   :cve_nist:`2026-28419` and :cve_nist:`2026-33412`
+
+
+Fixes in Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bitbake: tests/fetch: Avoid using git protocol in tests
+-  build-appliance-image: Update to kirkstone head revision
+-  contributor-guide/submit-changes.rst: Added missing word
+-  create-pull-request: Keep commit hash to be pulled in cover email
+-  createrepo-c: Fix createrepo-c-native build on GCC14 hosts (e.g. Fedora 41)
+-  gtk+3: fix incompatible-pointer-types errors for native build on Fedora 41
+-  libcomps: Fix libcomps-native build on GCC14 hosts (e.g. Fedora 41)
+-  libpam: re-add missing libgen include
+-  libtheora: set :term:`CVE_PRODUCT`
+-  linux-yocto/5.15: update to v5.15.201
+-  lsb.py: strip ' from os-release file
+-  migration-guide: add release notes for 4.0.33 4.0.34
+-  oeqa/manual: Default to https git protocol for YP/OE repos
+-  oeqa/sdk: Default to https git protocol for YP/OE repos
+-  oeqa/selftest/git-submodule-test: Default to https git protocol for YP/OE repos
+-  overview-manual: escape wildcard in inline markup
+-  poky.conf: Bump version for 4.0.35 release
+-  python3: upgrade to 3.10.20
+-  README.OE-Core: update contributor links and add kirkstone prefix
+-  recipes: Default to https git protocol for YP/OE repos
+-  recipetool: Recognise https://git. as git urls
+-  ref-manual/system-requirements.rst: update end-of-life distros
+-  scripts/install-buildtools: Update to 4.0.34
+-  scripts: Default to https git protocol for YP/OE repos
+-  selftest/scripts: Update old git protocol references
+-  tcl: skip http11 tests
+-  tiff: set status of CVE-2025-61145 as fixed by patch for :cve_nist:`2025-8961`
+-  tzdata,tzcode-native: Upgrade to 2026a
+
+
+Known Issues in Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Antonin Godard
+-  Bruce Ashfield
+-  Fabien Thomas
+-  Hitendra Prajapati
+-  Jinfeng Wang
+-  Ken Kurematsu
+-  Kristiyan Chakarov
+-  Lee Chee Yang
+-  Martin Jansa
+-  Paul Barker
+-  Peter Marko
+-  Richard Purdie
+-  Ross Burton
+-  Shaik Moin
+-  Vijay Anusuri
+-  Yanis BINARD
+-  Yoann Congal
+
+Repositories / Downloads for Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </yocto-docs/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`ce6734c68649739c635675a133fa77edb9865028 </yocto-docs/commit/?id=ce6734c68649739c635675a133fa77edb9865028>`
+-  Release Artefact: yocto-docs-ce6734c68649739c635675a133fa77edb9865028
+-  sha: ddb6fac4d257f4f76836055cafad529729e99c293d3b8d3dabef926fad5e725f
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/yocto-docs-ce6734c68649739c635675a133fa77edb9865028.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/yocto-docs-ce6734c68649739c635675a133fa77edb9865028.tar.bz2
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </poky/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`93431249a6260da7bd29ee3ca32145d89e5b8259 </poky/commit/?id=93431249a6260da7bd29ee3ca32145d89e5b8259>`
+-  Release Artefact: poky-93431249a6260da7bd29ee3ca32145d89e5b8259
+-  sha: a8e95213248c5400276611754f2c98b8d8972e166bdf41433c45fcdd2bf668cb
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/poky-93431249a6260da7bd29ee3ca32145d89e5b8259.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/poky-93431249a6260da7bd29ee3ca32145d89e5b8259.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.35 </openembedded-core/log/?h=yocto-4.0.35>`
+-  Git Revision: :oe_git:`51259c7e933a2ac8ebc01604d6e65607b76b7b56 </openembedded-core/commit/?id=51259c7e933a2ac8ebc01604d6e65607b76b7b56>`
+-  Release Artefact: oecore-51259c7e933a2ac8ebc01604d6e65607b76b7b56
+-  sha: 2cd531e2a107849e7a452e71e41f22b42160979066e10d0661e97acfab125b1f
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/oecore-51259c7e933a2ac8ebc01604d6e65607b76b7b56.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/oecore-51259c7e933a2ac8ebc01604d6e65607b76b7b56.tar.bz2
+
+meta-yocto
+
+-  Repository Location: :yocto_git:`/meta-yocto`
+-  Branch: :yocto_git:`kirkstone </meta-yocto/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </meta-yocto/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`34e3c9a19b8b955116109a2e9528966db3fced37 </meta-yocto/commit/?id=34e3c9a19b8b955116109a2e9528966db3fced37>`
+-  Release Artefact: meta-yocto-34e3c9a19b8b955116109a2e9528966db3fced37
+-  sha: 18da6dbb745d5e4e42a93527c36751778155e3762728b0b1020b890480402dde
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/meta-yocto-34e3c9a19b8b955116109a2e9528966db3fced37.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/meta-yocto-34e3c9a19b8b955116109a2e9528966db3fced37.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </meta-mingw/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`87c22abb1f11be430caf4372e6b833dc7d77564e </meta-mingw/commit/?id=87c22abb1f11be430caf4372e6b833dc7d77564e>`
+-  Release Artefact: meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e
+-  sha: f0bc4873e2e0319fb9d6d6ab9b98eb3f89664d4339a167d2db6a787dd12bc1a8
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </meta-gplv2/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.35 </bitbake/log/?h=yocto-4.0.35>`
+-  Git Revision: :oe_git:`7fd0197fd5fedd23cc885b5e7e816d86a392fdf9 </bitbake/commit/?id=7fd0197fd5fedd23cc885b5e7e816d86a392fdf9>`
+-  Release Artefact: bitbake-7fd0197fd5fedd23cc885b5e7e816d86a392fdf9
+-  sha: 6c01ff2b4b0060ef3d6d3f1fc11690094b22865af4989946544d08d74b473ec9
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/bitbake-7fd0197fd5fedd23cc885b5e7e816d86a392fdf9.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/bitbake-7fd0197fd5fedd23cc885b5e7e816d86a392fdf9.tar.bz2
+

documentation/overview-manual/development-environment.rst

@@ -172,7 +172,7 @@ these tarballs gives you a snapshot of the released files.
       BSP repository and the Source Directory (i.e. ``poky``)
       repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
       branch of ``poky`` and you are going to use ``meta-intel``, be
-      sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``.
+      sure to check out the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``.
 
 In summary, here is where you can get the project files needed for
 development:
@@ -438,7 +438,7 @@ local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream
 branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch
 of the ``poky`` repository.
 
-It is important to understand that when you create and checkout a local
+It is important to understand that when you create and check out a local
 working branch based on a branch name, your local environment matches
 the "tip" of that particular development branch at the time you created
 your local branch, which could be different from the files in the
@@ -461,10 +461,10 @@ releases.
 
 When you create a local copy of the Git repository, you also have access
 to all the tags in the upstream repository. Similar to branches, you can
-create and checkout a local working Git branch based on a tag name. When
+create and check out a local working Git branch based on a tag name. When
 you do this, you get a snapshot of the Git repository that reflects the
 state of the files when the change was made associated with that tag.
-The most common use is to checkout a working branch that matches a
+The most common use is to check out a working branch that matches a
 specific Yocto Project release. Here is an example::
 
    $ cd ~
@@ -483,7 +483,7 @@ whose "HEAD" matches the commit in the repository associated with the
 "rocko-18.0.0" tag. The files in your repository now exactly match that
 particular Yocto Project release as it is tagged in the upstream Git
 repository. It is important to understand that when you create and
-checkout a local working branch based on a tag, your environment matches
+check out a local working branch based on a tag, your environment matches
 a specific point in time and not the entire development branch (i.e.
 from the "tip" of the branch backwards).
 

documentation/overview-manual/yp-intro.rst

@@ -26,12 +26,6 @@ platforms as well as software stacks that can be maintained and scaled.
 .. image:: svg/key-dev-elements.*
     :width: 100%
 
-For further introductory information on the Yocto Project, you might be
-interested in this
-`article <https://www.embedded.com/why-the-yocto-project-for-my-iot-project/>`__
-by Drew Moseley and in this short introductory
-`video <https://www.youtube.com/watch?v=utZpKM7i5Z4>`__.
-
 The remainder of this section overviews advantages and challenges tied
 to the Yocto Project.
 
@@ -387,7 +381,7 @@ Yocto Project:
 
    .. note::
 
-      AutoBuilder is based on buildbot.
+      AutoBuilder is based on `buildbot <https://buildbot.net/>`__.
 
    A goal of the Yocto Project is to lead the open source industry with
    a project that automates testing and QA procedures. In doing so, the

documentation/transitioning-to-a-custom-environment.rst

@@ -9,10 +9,10 @@ Transitioning to a custom environment for systems development
 .. note::
 
    So you've finished the :doc:`brief-yoctoprojectqs/index` and
-   glanced over the document :doc:`what-i-wish-id-known`, the latter contains
+   glanced over the document :doc:`what-i-wish-id-known`, the latter containing
    important information learned from other users. You're well prepared. But
    now, as you are starting your own project, it isn't exactly straightforward what
-   to do. And, the documentation is daunting. We've put together a few hints to
+   to do, and the documentation is daunting. We've put together a few hints to
    get you started.
 
 #. **Make a list of the processor, target board, technologies, and capabilities
@@ -23,7 +23,7 @@ Transitioning to a custom environment for systems development
 #. **Set up your board support**.
    Even if you're using custom hardware, it might be easier to start with an
    existing target board that uses the same processor or at least the same
-   architecture as your custom hardware. Knowing the board already has a
+   architecture as your custom hardware. Knowing that the board already has a
    functioning Board Support Package (BSP) within the project makes it easier
    for you to get comfortable with project concepts.
 
@@ -34,19 +34,19 @@ Transitioning to a custom environment for systems development
    target board. The Yocto Project layer index BSPs are regularly validated. The
    best place to get your first BSP is from your silicon manufacturer or board
    vendor – they can point you to their most qualified efforts. In general, for
-   Intel silicon use meta-intel, for Texas Instruments use meta-ti, and so
+   Intel silicon use ``meta-intel``, for Texas Instruments use ``meta-ti``, and so
    forth. Choose a BSP that has been tested with the same Yocto Project release
    that you've downloaded. Be aware that some BSPs may not be immediately
    supported on the very latest release, but they will be eventually.
 
    You might want to start with the build specification that Poky provides
-   (which is reference embedded distribution) and then add your newly chosen
+   (which is reference embedded distribution) and then add your newly-chosen
    layers to that. Here is the information :ref:`about adding layers
    <dev-manual/layers:Understanding and Creating Layers>`.
 
 #. **Based on the layers you've chosen, make needed changes in your
    configuration**.
-   For instance, you've chosen a machine type and added in the corresponding BSP
+   For instance, assume you've chosen a machine type and added in the corresponding BSP
    layer. You'll then need to change the value of the :term:`MACHINE` variable in your
    configuration file (build/local.conf) to point to that same machine
    type. There could be other layer-specific settings you need to change as
@@ -68,8 +68,8 @@ Transitioning to a custom environment for systems development
    bsp layer using the \`\`bitbake-layers\`\` script>`. For example, given a
    64-bit x86-based machine, copy the conf/intel-corei7-64 definition and give
    the machine a relevant name (think board name, not product name). Make sure
-   the layer configuration is dependent on the meta-intel layer (or at least,
-   meta-intel remains in your bblayers.conf). Now you can put your custom BSP
+   the layer configuration is dependent on the ``meta-intel`` layer (or at least,
+   ``meta-intel`` remains in your ``bblayers.conf`` file). Now you can put your custom BSP
    settings into your layer and you can re-use it for different applications.
 
 #. **Write your own recipe to build additional software support that isn't

documentation/what-i-wish-id-known.rst

@@ -9,7 +9,7 @@ What I wish I'd known about Yocto Project
 .. note::
 
    Before reading further, make sure you've taken a look at the
-   :yocto_home:`Software Overview</software-overview>` page which presents the
+   :yocto_home:`Technical Overview</development/technical-overview>` page which presents the
    definitions for many of the terms referenced here. Also, know that some of the
    information here won't make sense now, but as you start developing, it is the
    information you'll want to keep close at hand. These are best known methods for
@@ -22,8 +22,8 @@ known before embarking on their first build with Yocto Project. Feel free to
 contact us with other suggestions.
 
 #. **Use Git, not the tarball download:**
-   If you use git the software will be automatically updated with bug updates
-   because of how git works. If you download the tarball instead, you will need
+   If you use Git, the software will be automatically updated with bug updates
+   because of how Git works. If you download the tarball instead, you will need
    to be responsible for your own updates.
 
 #. **Get to know the layer index:**
@@ -165,19 +165,19 @@ contact us with other suggestions.
 
    * deal with corporate proxies
    * add a package to an image
-   * understand the difference between a recipe and package
-   * build a package by itself and why that's useful
+   * understand the difference between a recipe and a package
+   * build a package by itself and understand why that's useful
    * find out what packages are created by a recipe
    * find out what files are in a package
    * find out what files are in an image
-   * add an ssh server to an image (enable transferring of files to target)
+   * add an SSH server to an image (enable transferring of files to target)
    * know the anatomy of a recipe
    * know how to create and use layers
    * find recipes (with the :oe_layerindex:`OpenEmbedded Layer index <>`)
-   * understand difference between machine and distro settings
+   * understand the difference between MACHINE and DISTRO settings
    * find and use the right BSP (machine) for your hardware
-   * find examples of distro features and know where to set them
-   * understanding the task pipeline and executing individual tasks
+   * find examples of DISTRO features and know where to set them
+   * understand the task pipeline and how to execute individual tasks
    * understand devtool and how it simplifies your workflow
    * improve build speeds with shared downloads and shared state cache
    * generate and understand a dependency graph