From b3d71d3e6104beda9bb4f81a6e930a9539e1df50 Mon Sep 17 00:00:00 2001 From: Ricardo Pardini Date: Fri, 8 Mar 2024 15:51:11 +0100 Subject: [PATCH] "Welcome Guide" which was for `armbian-next` (#352) * remove all references to Vagrant, as it is no longer supported * FEL boot is no more * format mkdocs.yml - no real changes * The Welcome Guide, or: blergh "What's New" back from `armbian-next` --- docs/Developer-Guide_Build-Options.md | 2 +- docs/Developer-Guide_Build-Preparation.md | 3 +- docs/Developer-Guide_FEL-boot.md | 74 ----------- docs/Developer-Guide_Using-Vagrant.md | 85 ------------ docs/Developer-Guide_Welcome.md | 127 ++++++++++++++++++ docs/Release_Changelog.md | 2 - mkdocs.yml | 151 +++++++++++----------- 7 files changed, 204 insertions(+), 240 deletions(-) delete mode 100644 docs/Developer-Guide_FEL-boot.md delete mode 100644 docs/Developer-Guide_Using-Vagrant.md create mode 100644 docs/Developer-Guide_Welcome.md diff --git a/docs/Developer-Guide_Build-Options.md b/docs/Developer-Guide_Build-Options.md index 5858d54e..0f652123 100644 --- a/docs/Developer-Guide_Build-Options.md +++ b/docs/Developer-Guide_Build-Options.md @@ -112,7 +112,7 @@ These parameters are meant to be applied to the `./compile.sh` command. They are - **SEVENZIP** ( yes | **no** ): create .7z archive with extreme compression ratio instead of .zip - **BUILD_KSRC** ( **yes** | no ): create kernel source packages while building... - **INSTALL_KSRC** ( yes | **no** ): ... and pre-install these kernel sources on the image -- **ROOTFS_TYPE** ( **ext4** | f2fs | btrfs | nilfs2 | xfs | nfs | fel ): create image with different root filesystems instead of default `ext4`. Requires setting `FIXED_IMAGE_SIZE` to something smaller than the size of your SD card for `F2FS` +- **ROOTFS_TYPE** ( **ext4** | f2fs | btrfs | nilfs2 | xfs | nfs ): create image with different root filesystems instead of default `ext4`. Requires setting `FIXED_IMAGE_SIZE` to something smaller than the size of your SD card for `F2FS` - **BTRFS_COMPRESSION** ( lzo | none | **zlib** | zstd ): when choosing `ROOTFS_TYPE=btrfs` select `btrfs` filesystem compression method and compression level. By default the compression is `zlib`. When selecting `zstd` or setting zlib compression level(`zlib:[1-9]`) user must ensure kernel version is **>=4.14.x**. When selecting zstd compression level (`zstd:[1-15]`) both the host and the target kernel version must be **>=5.1.x** since kernel started supporting zstd compression ratio only from 5.1 on. diff --git a/docs/Developer-Guide_Build-Preparation.md b/docs/Developer-Guide_Build-Preparation.md index 010cd1fe..effa7831 100644 --- a/docs/Developer-Guide_Build-Preparation.md +++ b/docs/Developer-Guide_Build-Preparation.md @@ -13,11 +13,10 @@ Not officially supported build environments from community contributions: -- Setting up VirtualBox and compile environment is easy following our [Vagrant tutorial](https://docs.armbian.com/Developer-Guide_Using-Vagrant/), - [Docker](Developer-Guide_Building-with-Docker.md) environment is also supported for building kernels and full OS images, - [Multipass](https://gist.github.com/atomic77/7633fcdbf99dca80f31fd6d64bfd0565) -Please note that system requirements (both hardware and OS/software) may differ depending on the build environment (Vagrant, Docker, Virtualbox, native). +Please note that system requirements (both hardware and OS/software) may differ depending on the build environment (Docker, Virtualbox, native). ## How to start? diff --git a/docs/Developer-Guide_FEL-boot.md b/docs/Developer-Guide_FEL-boot.md deleted file mode 100644 index b5baa8a5..00000000 --- a/docs/Developer-Guide_FEL-boot.md +++ /dev/null @@ -1,74 +0,0 @@ -# FEL/NFS boot explanation -**Warning: Armbian has dropped support for old legacy 3.x kernels. Therefore FEL is no longer supported/available. This page is archived and not maintained.** - -## What is FEL/NFS boot? - -FEL/NFS boot mode is a possibility to test freshly created Armbian distribution without using SD card. It is implemented by loading u-boot, kernel, initrd, boot script and .bin/.dtb file via [USB FEL mode](https://linux-sunxi.org/FEL/USBBoot) and providing root filesystem via NFS share. - -NOTE: this mode is designed only for testing. To use root on NFS permanently, use `ROOTFS_TYPE=nfs` option. -NOTE: "hot" switching between kernel branches (default <-> dev/next) is not supported - -## Requirements - -- Allwinner device that supports FEL mode. Check [wiki](https://linux-sunxi.org/FEL) to find out how to enter FEL mode with your device -- USB connection between build host and board OTG port (VM USB passthrough or USB over IP may work too) -- Network connection between build host and board. For target board **wired** Ethernet connection is required (either via onboard Ethernet or via USB ethernet adapter that has required kernel modules built-in) -- NFS ports on build host should be reachable from board perspective (you may need to open ports in firewall or change network configuration of your VM) -- Selected kernel should have built-in support for DHCP and NFS root filesystem -- `CLEAN_LEVEL="make,debs"` to always update u-boot configuration - -### Additional requirements (recommended) - -- DHCP server in local network -- UART console connected to target board - -## Build script options - -- KERNEL_ONLY=no -- ROOTFS_TYPE=fel - -Example: -``` -./compile.sh KERNEL_ONLY=no BOARD=cubietruck BRANCH=current PROGRESS_DISPLAY=plain RELEASE=jessie BUILD_DESKTOP=no ROOTFS_TYPE=fel -``` - -## Shutdown and reboot - -Once you start FEL boot, you will see this prompt: - -``` -[ o.k. ] Press any key to boot again, to finish [ FEL ] -``` - -Pressing `q` deletes current rootfs and finishes build process, so you need to shut down or reboot your board to avoid possible problems unmounting/deleting temporary rootfs. All changes to root filesystem will persist until you exit FEL mode. - -To reboot again into testing system, switch your board into FEL mode and press any key other than `q`. - -Because kernel and .bin/.dtb file are loaded from rootfs each time, it's possible to update kernel or its configuration (via `apt-get`, `dtc`, `fex2bin`/`bin2fex`) from within running system. - -## Advanced configuration - -If you don't have DHCP server in your local network or if you need to alter kernel command line, use `lib/scripts/fel-boot.cmd.template` as a template and save modified script as `userpatches/fel-boot.cmd`. Check [this](https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/plain/Documentation/filesystems/nfs/nfsroot.txt) for configuring static IP for NFS root. - -- Note: As of 2020-11-25, the above link is broken. However I am not sure what to replace it with. If you know (or find out) please [submit a PR](/Process_Contribute/). - TRS-80 - -Set `FEL_DTB_FILE` to relative path to .dtb or .bin file if it can't be obtained from u-boot config (mainline kernel) or boot/script.bin (legacy kernel) - -You may need to set these additional options (it's a good idea to put them in `userpatches/lib.config`: - -Set `FEL_NET_IFNAME` to name of your network interface if you have more than one non-loopback interface with assigned IPv4 address on your build host - -Set `FEL_LOCAL_IP` to IP address that can be used to reach NFS server on your build host if it can't be obtained from ifconfig (i.e. port forwarding to VM guest) - -Set `FEL_AUTO=yes` to skip prompt before trying FEL load - -## Customization - -You can even create `userpatches/fel-hooks.sh` and define there 2 functions: `fel_post_prepare` and `fel_pre_load`. All normal build variables like $BOARD, $BRANCH and so on can be used in these functions to define specific actions. - -`fel_post_prepare` is executed once after setting up u-boot script and NFS share, you can use it to add extra stuff to boot.scr (like `gpio set` or `setenv machid`) based on device name. - -`fel_pre_load` is executed before calling sunxi-fel, you can use it to implement logic to select one of multiple connected boards; to pass additional arguments to `sunxi-fel` you can use `FEL_EXTRA_ARGS` variable. - -An example is provided as `scripts/fel-hooks.sh.example`. - diff --git a/docs/Developer-Guide_Using-Vagrant.md b/docs/Developer-Guide_Using-Vagrant.md deleted file mode 100644 index 97e322e0..00000000 --- a/docs/Developer-Guide_Using-Vagrant.md +++ /dev/null @@ -1,85 +0,0 @@ -# Quick Start with Vagrant - -## Vagrant HOST Steps - -The following steps are performed on the *host* that runs Vagrant. - -### Installing Vagrant and Downloading Armbian - -First, you'll need to [install Vagrant](https://www.vagrantup.com/downloads.html) on your host box. Then you have to choose if you want to run Virtualbox or Libvirt. - -#### Virtualbox - -[Install Virtualbox](https://www.virtualbox.org/manual/UserManual.html#installation), then you'll need to install a plug-in that will enable us to resize the primary storage device. Without it, the default Vagrant images are too small to build Armbian. - - vagrant plugin install vagrant-disksize - -#### Libvirt - -[Installing libvirt](https://libvirt.org/downloads.html) is a little bit more complex as you have to install an hypervisor too (like KVM/Qemu but others are available). Discussing about which one choosing and how to install it is out of scope. Once you have libvirt and an hypervisor installed, you'll need [vagrant-libvirt](https://github.com/vagrant-libvirt/vagrant-libvirt/blob/master/README.md#installation). -Finally, you need to tell vagrant to use libvirt and not default to Virtualbox. - - export VAGRANT_DEFAULT_PROVIDER=libvirt - -#### Common steps - -Now we'll need to [install git](https://git-scm.com/downloads) and clone the Armbian repo. While this might seem obvious, we rely on it being there when we use Vagrant to bring up our guest-build box. - - # Clone the project. - git clone --depth 1 https://github.com/armbian/build - - # Make the Vagrant box available. This might take a while but only needs to be done once. - vagrant box add generic/ubuntu2204 - - # If the box gets updated by the folks at HashiCorp, we'll want to update our copy too. - # This only needs done once and a while. - vagrant box update - -### Armbian Directory Structure - -Before we bring up the box, take note of the [directory structure]( https://docs.armbian.com/Developer-Guide_Build-Process/#directory-structure) used by the Armbian build tool. When you read the Vagrantfile (which is in the build/config/templates directory) you'll see that Vagrant will mount local *output* and *userpatches* directories. This is helpful as it enables you to easily retrieve your images from the host once built, and [customize the build process](https://docs.armbian.com/Developer-Guide_User-Configurations/). - -### Creating the Vagrant Guest Box Used to Build -Let's bring the box up. This might take a minute or two depending on your bandwidth and hardware. - - # We have to be in the same directory as the Vagrant file, which is in the build/config/templates directory. - - cd build/config/templates - - # Note that you can edit the Vagrant file to specify the number of cpus and amount of memory you want Vagrant to use. - - # And now we simply let vagrant create our box and bring it up. - - vagrant up - - # When the box has been installed we can get access via ssh. - # (No need for passwords, Vagrant installs the keys we'll need.) - vagrant ssh - -### Shut down, clean up - -Wrap up your vagrant box when no longer needed (log out of the guest before running these commands on the *host* system): - - # Shutdown, but leave the box around for more building at a later time: - vagrant halt - - # Trash the box and remove all the related storage devices. - vagrant destroy - -## Important note - -It is strongly recommended to halt and restart the Vagrant box after building an image. Check [this](https://github.com/armbian/build/issues/751) issue for details. - -## Vagrant GUEST Steps - -The following steps are all run on the *guest* Vagrant created for us. - -Once it's finally up and you're logged in, it works much like any of the other install methods (NOTE: again, these commands are run on the *guest* box). - - # Let's get building! - cd armbian - sudo ./compile.sh - -## More Vagrant HOST Steps - -Moved [here](Developer-Guide_Using-Vagrant.md#shut-down-clean-up). diff --git a/docs/Developer-Guide_Welcome.md b/docs/Developer-Guide_Welcome.md new file mode 100644 index 00000000..94eac341 --- /dev/null +++ b/docs/Developer-Guide_Welcome.md @@ -0,0 +1,127 @@ +# Welcome to `armbian/build`, the Armbian build system + +Welcome to the Armbian build system (`armbian/build`). +The build system has significantly changed since release 23.02, when the `armbian-next` effort was merged into +our `main` branch. +Please expect some rough edges and report them to us. + +## Errors, errors everywhere + +Previously, when faced with an error, the build system would simply ignore them, hardly log them anywhere, and continue. +This led to builds completing successfully, but with (sometimes very sneakily) broken packages and images. +Get used to seeing errors stopping builds now. Inspect the whole log, specially the errors, the last few lines, and the +stack trace. +We try, as much as possible given Bash limitations, to show the source of the error, with a "stack trace" of sorts. +The topmost elements of the stack trace are usually the most relevant. Each line is prefixed with the file and line +number where the error occurred. +Open the file and go to the line number to see the source of the error. Most times, this simple inspection is enough to +understand the error. + +### (ANSI) Logging + +Logging is a bit more structured now. Logs are output to `output/logs`, in a few different formats. +We output ANSI color both to the screen and to the logs. +_Please_ add `SHARE_LOG=yes` to share your logs with us when reporting issues, that allows us to check the logs on a web +browser and keep to correct formatting. + +## Command line syntax has changed + +General CLI syntax: `./compile.sh PARAM=value OTHER_PARAM=other_value [ ...] []` + +- where `command` defaults to `build` if you don't specify it; could also be `kernel-config` or `u-boot` etc +- you _can't_ have a config file with the same name as a possible `` (system will check & bomb if so) +- also: there's no more `default` config -- you have to be explicit +- also: there's no more `docker` config -- Docker is fully auto-managed now. The system will complain if you have one. +- you can specify `PARAM=value`, `` or `` in _any order_ + +## No more `config-default.conf`, you need to specify the config file in the command line + +- No "default" config is auto-loaded anymore. Default config lead to unreproducible failing builds and was a source of + confusion. +- The configs still go to the same place, `userpatches/config-xyz.conf` -- but now you gotta tell the build system to + use that config, like `./compile.sh BOARD=xxx xyz`; otherwise works the same. + +## Artifacts, cache, what the ...? + +The `armbian/build` system is currently undergoing refactoring to improve its structure. Previously, the build system +was a single, complex Bash script that mixed the building of `.deb` packages with the creation of images. + +This was reworked into a `1-to-N` image-to-artifact dependency tree; a certain image build will depend on N possible +"artifacts". Artifacts are either `.deb` packages, a `.tar` of multiple `.deb` packages, or a `rootfs.tar.zstd`. Each +artifact can be individually built, and has a specific name and a _version_. + +Each artifact is also now **cached by default** using OCI storage at ghcr.io (GitHub Container Registry). To achieve +_consistent caching_, each artifact produces a version that includes _hashes_ of its composing files, variables, +patches, +hooks, external git SHA1 references, etc. That way we can consistently check the remote OCI cache for previously-built +artifacts, and possibly save image builders from having to build heavy packages just to produce an image. + +### TL-DR about artifacts and caching: + +- `KERNEL_ONLY=yes` and `KERNEL_ONLY=no` are no more. Use the `kernel` CLI command instead. +- `ARTIFACT_IGNORE_CACHE=yes` can help if you're getting false positives. Please also report the problem, with a + complete logfile. + +## Automatic Docker/sudo launcher + +- `compile.sh` will prefer to use Docker if it detects Docker is installed and working. + - This handles Docker Desktop and Rancher Desktop (in Docker emulation mode) under macOS/Darwin, including Apple + M1/M2. + - You **don't need and actually can't have the old docker config file**. +- If Docker is not installed, it will try to use `sudo` to run the build as root. +- If you run directly as root, it will warn you and ask you to run it without sudo. + +## Kernel Git Trees: shallow vs full + +During the build, depending on which local or remote caches are hit, it might be needed to build the Linux Kernel. + +The kernel's git repo is huge. Most build systems resort to fetching "shallow" trees directly from upstream git servers, +to save bandwidth. Unfortunately that creates immense extra CPU load on the git servers. To avoid this problem, +Armbian produces daily automated git tree exports cached in ghcr.io OCI repositories, and only uses `git fetch` to +update the relatively small new changes from the upstream git server. + +There are two types of cached Kernel git trees: + +- `full` is a complete git tree, including all of Torvald's `master` and all of the currently-supported `stable` + branches. + - `full` is very large download and requires a lot of disk space. + - `full` is more useful over time and when building multiple different kernels on the same machine, like for CI + servers or developer workstations. +- `shallow` is a shallow tree for a specific `stable` branch + - `shallow` is a much smaller download and requires less disk space + - `shallow` is appropriate for restricted devices like SBCs which will build a single kernel + +**TL,DR: ** `KERNEL_GIT=full` or `KERNEL_GIT=shallow` or let the system decide for you. + +## Consider Forking before cloning the repo + +Before cloning the repo, consider forking it first. This will allow you to make changes and submit pull requests. +You will need a GitHub account to do this; +see [GitHub's documentation](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) for more +information. +If you fork, make sure to keep your fork up-to-date with the main repo, by rebasing your fork. + +## Some really confusing stuff still remains + +This is (by far) not a complete list: + +- wifi/other kernel drivers are still using pre-armbian-next code, and are very hard to work with. it's not only the + contents are a mess, the way the whole thing works leads to more and more compounding work. To make it worse, family + patches sometimes need to patch driver code, leading to a cycle of sadness for developers. We're still coming up with + a plan to completely replace this lest most of us go insane. +- although "aggregation" has been rewritten in Python, it still mostly works using the legacy principle, by scanning + directories and files in a very complex and error-prone way. This is a source of many bugs and confusion. We plan to + replace this with pure extensions eventually. +- "minimal" images are far from really minimal. It is common to see "extensions" that actually remove stuff put there + by the core. Those should be refactored. +- board-side scripts (armbian-config, firstrun, hwoptimization, etc) haven't really changed with armbian-next, and are + in dire need of a rewrite. They're also a source of many bugs and confusion. They also need to be extensible. +- we've mostly working Kernel headers (linux-headers pkg) for 5.10+ including some vendor kernels; no kernel-headers for + 4.x kernels. sorry. We've no plans to support this. + +## Multiple u-boot's for same board + +Hmm. This is an interesting problem. We can build u-boot twice, using `UBOOT_TARGET_MAP`. +Some example I did in https://github.com/armbian/build/blob/main/config/boards/odroidhc4.conf#L15-L20 may help. + + diff --git a/docs/Release_Changelog.md b/docs/Release_Changelog.md index a9f7aba8..9bab30cb 100644 --- a/docs/Release_Changelog.md +++ b/docs/Release_Changelog.md @@ -1766,7 +1766,6 @@ Build script: * added option to create minimal images with around 500Mb in size BUILD_MINIMAL="yes" * added initial support of MCIMX7SABRE board (CSC) * updates for xt-q8l-v10 (CSC) -* vagrant-disksize is beeing determined automatically * Docker is installed automatically if one want use it (Debian based build host only) * refactor build all images scripting that images can be build in full parallel mode * added one file for storing which combinations shell be made for each board @@ -2523,7 +2522,6 @@ Build script: * added docker as host * Added Belink X2 (H3 based media player), and Roseapple (S500) as WIP target * introducted CLI_TARGET per board -* prepared FEL boot * prepared Xenial target * fixed USB redirector building on all kernels * support for Xenial as a build host is 95% ready. diff --git a/mkdocs.yml b/mkdocs.yml index 984d304a..ee8a7481 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -5,30 +5,30 @@ copyright: Copyright © 2015 - 2023 Armbian team repo_url: https://github.com/armbian/documentation repo_name: armbian/documentation -theme: - name: material - custom_dir: overrides - logo: images/logo.svg - icon: - repo: fontawesome/brands/github-alt - palette: - - scheme: default - primary: red - accent: red - toggle: - icon: material/toggle-switch-off-outline - name: Switch to dark mode - - scheme: slate - primary: red - accent: red - toggle: - icon: material/toggle-switch - name: Switch to light mode - favicon: images/logo.png - features: - - navigation.tabs - - navigation.top - - toc.integrate +theme: + name: material + custom_dir: overrides + logo: images/logo.svg + icon: + repo: fontawesome/brands/github-alt + palette: + - scheme: default + primary: red + accent: red + toggle: + icon: material/toggle-switch-off-outline + name: Switch to dark mode + - scheme: slate + primary: red + accent: red + toggle: + icon: material/toggle-switch + name: Switch to light mode + favicon: images/logo.png + features: + - navigation.tabs + - navigation.top + - toc.integrate extra: analytics: @@ -41,12 +41,12 @@ extra: link: https://twitter.com/armbian plugins: - - search - - with-pdf: - author: Armbian documentation team - copyright: © 2023 by Armbian - cover_title: Armbian documentation - cover_subtitle: Linux for ARM development boards + - search + #- with-pdf: + # author: Armbian documentation team + # copyright: © 2023 by Armbian + # cover_title: Armbian documentation + # cover_subtitle: Linux for ARM development boards markdown_extensions: - smarty @@ -66,55 +66,54 @@ markdown_extensions: nav: - Home: index.md - - "User Guide" : - - "Getting Started" : "User-Guide_Getting-Started.md" - - "Quick facts" : "Quick_facts.md" - - "Troubleshooting" : "User-Guide_Basic-Troubleshooting.md" - - "Recovery" : "User-Guide_Recovery.md" - - "Frequently asked questions" : "User-Guide_FAQ.md" - - "Advanced Features" : "User-Guide_Advanced-Features.md" - - "Fine Tuning" : "User-Guide_Fine-Tuning.md" - - "Armbian config" : "User-Guide_Armbian-Config.md" - - "Armbian DT overlays" : "User-Guide_Armbian_overlays.md" - - "Board Support Rules" : "User-Guide_Board-Support-Rules.md" + - "User Guide": + - "Getting Started": "User-Guide_Getting-Started.md" + - "Quick facts": "Quick_facts.md" + - "Troubleshooting": "User-Guide_Basic-Troubleshooting.md" + - "Recovery": "User-Guide_Recovery.md" + - "Frequently asked questions": "User-Guide_FAQ.md" + - "Advanced Features": "User-Guide_Advanced-Features.md" + - "Fine Tuning": "User-Guide_Fine-Tuning.md" + - "Armbian config": "User-Guide_Armbian-Config.md" + - "Armbian DT overlays": "User-Guide_Armbian_overlays.md" + - "Board Support Rules": "User-Guide_Board-Support-Rules.md" - - "Hardware Notes" : - - "Allwinner (Generic)" : "Hardware_Allwinner.md" - - "A10 and A20" : "Hardware_Allwinner-A20.md" - - "H2+ and H3" : "Hardware_Allwinner-H3.md" - - "H5 and A64" : "Hardware_Allwinner-H5-A64.md" - - "H6" : "Hardware_Allwinner-H6.md" - - "Freescale i.MX6" : "Hardware_Freescale-imx6.md" - - "Marvell Armada" : "Hardware_Marvell.md" - - "Rockchip" : "Hardware_Rockchip.md" + - "Hardware Notes": + - "Allwinner (Generic)": "Hardware_Allwinner.md" + - "A10 and A20": "Hardware_Allwinner-A20.md" + - "H2+ and H3": "Hardware_Allwinner-H3.md" + - "H5 and A64": "Hardware_Allwinner-H5-A64.md" + - "H6": "Hardware_Allwinner-H6.md" + - "Freescale i.MX6": "Hardware_Freescale-imx6.md" + - "Marvell Armada": "Hardware_Marvell.md" + - "Rockchip": "Hardware_Rockchip.md" - - "Developer Guide" : - - "Development Code Review Procedures and Guidelines" : "Development-Code_Review_Procedures_and_Guidelines.md" - - "Building Armbian" : "Developer-Guide_Build-Preparation.md" - - "Building with Vagrant" : "Developer-Guide_Using-Vagrant.md" - - "Building with Docker" : "Developer-Guide_Building-with-Docker.md" - - "Build Options" : "Developer-Guide_Build-Options.md" - - "User Configurations" : "Developer-Guide_User-Configurations.md" - - "FEL boot" : "Developer-Guide_FEL-boot.md" - - "Extensions": "Developer-Guide_Extensions.md" - - "Hooks": "Developer-Guide_Extensions-Hooks.md" # This file is autogenerated by build system. - - "Adding new board or family": "Developer-Guide_Adding-Board-Family.md" + - "Developer Guide": + - "Welcome": "Developer-Guide_Welcome.md" + - "Building Armbian": "Developer-Guide_Build-Preparation.md" + - "Building with Docker": "Developer-Guide_Building-with-Docker.md" + - "Build Options": "Developer-Guide_Build-Options.md" + - "User Configurations": "Developer-Guide_User-Configurations.md" + - "Extensions": "Developer-Guide_Extensions.md" + - "Hooks": "Developer-Guide_Extensions-Hooks.md" # This file is autogenerated by build system. + - "Adding new board or family": "Developer-Guide_Adding-Board-Family.md" - - "Contributor Process" : - - "Contribute" : "Process_Contribute.md" - - "Merge Policy" : "Process_Merge-Policy.md" - - "Continuous integration" : "Process_CI.md" - - "Documentation" : "Process_Documentation.md" + - "Contributor Process": + - "Contribute": "Process_Contribute.md" + - "Merge Policy": "Process_Merge-Policy.md" + - "Continuous integration": "Process_CI.md" + - "Documentation": "Process_Documentation.md" + - "Development Code Review Procedures and Guidelines": "Development-Code_Review_Procedures_and_Guidelines.md" - - "Release management" : - - "Model" : "Process_Release-Model.md" - - "Changelog" : "Release_Changelog.md" - - "Workflow (Jira)" : "Process_Managing_Workflow.md" - - "Board Maintainers" : "Release_Board-Maintainers.md" - - "Board Maintainers Procedures and Guidelines" : "Board_Maintainers_Procedures_and_Guidelines.md" + - "Release management": + - "Model": "Process_Release-Model.md" + - "Changelog": "Release_Changelog.md" + - "Workflow (Jira)": "Process_Managing_Workflow.md" + - "Board Maintainers": "Release_Board-Maintainers.md" + - "Board Maintainers Procedures and Guidelines": "Board_Maintainers_Procedures_and_Guidelines.md" - - "Community" : - - "IRC/Discord/Matrix" : "Community_IRC.md" - - "Governance" : "Community_Governance.md" - - "Seed our torrents" : "Community_Torrent.md" + - "Community": + - "IRC/Discord/Matrix": "Community_IRC.md" + - "Governance": "Community_Governance.md" + - "Seed our torrents": "Community_Torrent.md"