Canoeboot 20240612 release

Signed-off-by: Leah Rowe <info@minifree.org>

site.cfg

@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: CC0-1.0
 TITLE="Canoeboot"
 DOMAIN="https://canoeboot.org/"
 BLOGDIR="news/" # leave as empty string if you want the blog to be the homepage

site/about.md

@@ -9,7 +9,7 @@ operates, why it exists and what it does. Who, what, why and when.
 What is Canoeboot?
 ===================
 
-Canoeboot is free/opensource boot firmware based on Libreboot (which is in turn
+Canoeboot is free/libre boot firmware based on Libreboot (which is in turn
 based on coreboot), replacing proprietary BIOS/UEFI firmware on select x86/ARM
 laptops, desktops and server mainboards. It provides an [automated build
 system](docs/maintain/)

site/contact.it.md

@@ -0,0 +1,74 @@
+---
+title: Contatti
+x-toc-enable: true
+...
+
+Supporto utenti
+===============
+
+IRC o Reddit sono consigliati, sebbene preferiamo che usi il canale IRC
+per avere o per offrire supporto tecnico. Continua a leggere per avere
+ulteriori informazioni.
+
+Mailing list
+============
+
+No mailing lists at present.
+
+Discussione sullo sviluppo
+==========================
+
+Per ora dai un occhiata sulla
+[pagina Git](git.md) per avere maggiori informazioni su come puoi
+assistere con lo sviluppo.
+
+Su quella stessa pagina puoi trovare informazioni su come inviare
+correzioni (patches) tramite pull requests.
+
+Canale IRC
+==========
+
+IRC e' il modo principale per contattare chi collabora con il progetto Canoeboot.
+Il canale ufficiale e' `#canoeboot` su Libera IRC.
+
+Webchat:
+<https://web.libera.chat/#canoeboot>
+
+Libera e' una tra le piu' grandi reti IRC usate per i progetti di software libero.
+Maggiori informazioni le trovi qui: <https://libera.chat/>
+
+Puoi usare il client IRC che preferisci (come weechat or irssi) usando le seguenti informazioni:
+
+* Server: `irc.libera.chat`
+* Canale: `#canoeboot`
+* Porta (TLS): `6697`
+* Porta (non-TLS): `6667`
+
+Ti suggeriamo di usare la porta `6697` e ablitare la cifratura TLS...
+
+Inoltre ti suggeriamo di abilitare l'autenticazione SASL. Le pagine web
+di Libera spiegano come:
+
+* Guida per WeeChat: <https://libera.chat/guides/weechat>
+* Guida per Irssi: <https://libera.chat/guides/irssi>
+* Guida per HexChat: <https://libera.chat/guides/hexchat>
+
+Comunque dovresti sempre controllare la documentazione del tuo client IRC preferito.
+
+Reti sociali online
+===================
+
+Canoeboot esiste ufficialmente in molte piattaforme.
+
+Mastodon
+--------
+
+Il fondatore e sviluppatore principale, Leah Rowe, e' su Mastodon:
+
+* <https://mas.to/@libreleah>
+
+Posta elettronica
+-----------------
+
+Leah puo' essere contattata anche via email a questo indirizzo:
+[leah@libreboot.org](mailto:leah@libreboot.org)

site/docs/build/index.md

@@ -25,6 +25,20 @@ canoeboot from the available source code.
 The following document describes how `cbmk` works, and how you can make changes
 to it: [canoeboot maintenance manual](../maintain/)
 
+Multi-threaded builds
+=====================
+
+Canoeboot's build system defaults to a single build thread, but you can change
+it by doing e.g.
+
+	export XBMK_THREADS=4
+
+This would make cbmk run on 4 threads.
+
+More specifically: when compiling source trees via `script/trees`, `-jTHREADS`
+is passed, where THREADS is the number of threads. This is also set when running
+xz commands for compression, using the `-t` option.
+
 Environmental variables
 =======================
 

site/docs/build/index.uk.md

@@ -17,13 +17,27 @@ images (containing payloads) in `bin/`. This design is more efficient, and
 permits many configurations without needless duplication of work. More info
 is available in the [cbmk maintenance manual](../maintain/)**
 
+Multi-threaded builds
+=====================
+
+Canoeboot's build system defaults to a single build thread, but you can change
+it by doing e.g.
+
+	export XBMK_THREADS=4
+
+This would make cbmk run on 4 threads.
+
+More specifically: when compiling source trees via `script/trees`, `-jTHREADS`
+is passed, where THREADS is the number of threads. This is also set when running
+xz commands for compression, using the `-t` option.
+
 Environmental variables
 =======================
 
 Please read about environmental variables in [the build
 instructions](../maintain/), before running cbmk. You should set
 your variables accordingly, though you do not technically need to; some
-of them may be useful, e.g. `CBMK_THREADS` (sets the number of build threads).
+of them may be useful, e.g. `XBMK_THREADS` (sets the number of build threads).
 
 Introduction
 ============

site/docs/gnulinux/grub_boot_installer.md

@@ -40,13 +40,6 @@ folder, this is the command we would run:
 That's it! You should now be able to boot the installer from your USB drive
 (the instructions for doing so will be given later).
 
-## GRUB2 config on external media
-
-Pick the menu option: *Search for GRUB2 configuration on external media*
-
-If the distro installer image has a `grub.cfg` file inside, this menuentry is
-scripted to find it. This works well for many distros.
-
 ## Prepare the USB drive in NetBSD
 [This page](https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/)
 on the NetBSD website shows how to create a NetBSD bootable USB drive, from
@@ -85,6 +78,14 @@ the OpenBSD installer to it with `dd`. Here's an example:
 That's it! You should now be able to boot the installer from your USB drive
 (the instructions for doing so will be given later).
 
+## GRUB2 config on external media
+
+NOTE: This will also apply to Trisquel GNU+Linux (an Ubuntu-based distro).
+Pick the menu option: *Search for GRUB2 configuration on external media*
+
+If the distro installer image has a `grub.cfg` file inside, this menuentry is
+scripted to find it. This works well for many distros.
+
 ## Debian or Devuan net install
 
 NOTE: This will also apply to Trisquel GNU+Linux (an Ubuntu-based distro).

site/docs/gnulinux/grub_hardening.md

@@ -216,6 +216,53 @@ of user-friendliness.
 
 That just about covers it, where password setup is concerned!
 
+SeaBIOS first?
+==============
+
+In releases after Canoeboot 20240510, SeaBIOS is the primary payload on
+all images, but GRUB is available in the boot menu. Select a ROM image
+with `grubfirst` at the end, and do this to the ROM image:
+
+	cbfstool canoeboot.rom add-int -i 0 -n etc/show-boot-menu
+
+This disables the SeaBIOS menu, so that it only loads GRUB. The `grubfirst`
+image had this done to it by lbmk (Canoeboot build system) during build:
+
+	cbfstool canoeboot.rom add -f config/grub/bootorder -n bootorder -t raw
+
+This `bootorder` file has the following contents:
+
+```
+/rom@img/grub2
+```
+
+You can add it yourself if your image doesn't have it. With this, SeaBIOS
+only loads GRUB first.
+
+NOTE: Before disabling the boot menu, make sure GRUB works. Access it using
+the `bootorder` file and/or press ESC in the SeaBIOS menu. Then disable the
+SeaBIOS menu.
+
+You can still use an override grub config in CBFS, as of Canoeboot 20240612.
+
+Alternative: GRUB as primary
+----------------------------
+
+The *SeaBIOS first* policy is now law, in Canoeboot releases. The only
+exception is the x86 QEMU target. You can do this if building from source:
+
+	./build roms -p grub targetname
+
+Where `targetname` is e.g. `x200_8mb` (use the correct one for your board).
+
+Again: make sure GRUB works. Also: don't do this if you're using a non-Intel
+graphics card because only the Intel graphics have native video initialisation
+in Canoeboot, and we rely on SeaBIOS to execute the VGA ROM for others.
+
+(it is assumed that you know to add the VGA ROM in CBFS if needed, if using
+a dGPU, or that you're using a graphics card on a desktop so SeaBIOS will use
+that automatically)
+
 GPG keys
 ========
 

site/docs/hardware/dell_thermal.md

@@ -0,0 +1,54 @@
+---
+title: Dell Latitude thermal throttling
+x-toc-enable: true
+...
+
+On some Dell Latitude laptops, you may encounter random shutdowns on
+heavy load. We believe this is because the SMSC EC is overly conservative
+by default; it is in charge of handling thermals and fan control on this
+machine. Our theory is that coreboot needs to write certain EC commands
+to allow higher temperatures; please read:
+
+<https://codeberg.org/libreboot/lbmk/issues/202> (NOTE: libreboot issue page,
+no point duplicating in Canoeboot. Fixes in Libreboot that are suitable for
+Canoeboot get put in Canoeboot anyway)
+
+Basically, what you need to do is:
+
+* Use high quality thermal paste (don't use the same dried up paste that the
+  laptop came with, if you bought it on ebay for example). Arctic MX-6 is good.
+* Check that the fan works reliably
+
+Also: the `intel_pstate` driver can be used to artifically cap CPU speed. See:
+
+<https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html>
+
+When you use this machine, it is recommended that you cap the CPU speed once
+you've booted into Linux. Set it to something like 50% at first. Then run a
+stress test, for example:
+
+	stress -c x
+
+Where `x` is the number of CPU cores, e.g. 2. Monitor the temperatures using
+something like `xsensors`, making sure the CPU doesn't exceed 80c temperature.
+
+You can also monitor CPU speeds in Linux like so:
+
+	watch -n .2 grep MHz /proc/cpuinfo
+
+This will let you know what speed you're at. You can use this to determine
+whether the `intel_pstate` driver is working. How to cap speed to 50 percent, as
+in the above example:
+
+	echo 50 > /sys/devices/system/cpu/cpufreq/intel_pstate/max_perf_pct
+
+Gradually increase the CPU speed (up to 100 on `max_perf_pct`), waiting a few
+minutes each time. You should ensure that your machine does not exceed 80C.
+
+Dell's thermal safety is far too protective by default, on some of these, and
+we don't yet know how to properly configure it. Running a CPU below 80c in
+temperature and never higher than that, is a good idea anyway, for the
+long term life of your CPU.
+
+Regardless, thermal shutdown is extremely reliable on this machine, but Dell
+makes it shut down *earlier*, before it can even start to CPU throttle.

site/docs/hardware/e6400.md

@@ -3,6 +3,12 @@ title: Dell Latitude E6400
 x-toc-enable: true
 ...
 
+**Thermal safety**: this machine shuts down very quickly, when the machine
+exceeds 80c CPU temperature, which is far more conservative than on most
+laptops (non-Dell ones), so you should make sure that your thermals are
+excellent. More info available [here](dell_thermal.md). This is a known bug,
+but otherwise the machine will be mostly stable.
+
 <div class="specs">
 <center>
 <img tabindex=1 alt="Dell Latitude E6400" class="p" src="https://av.canoeboot.org/e6400/e6400-seabios.jpg" /><span class="f"><img src="https://av.canoeboot.org/e6400/e6400-seabios.jpg" /></span> <img tabindex=1 alt="Dell Latitude E6400 XFR" class="p" style="max-width:24em" src="https://av.canoeboot.org/e6400/e6400xfr-seabios.jpg" /><span class="f"><img src="https://av.canoeboot.org/e6400/e6400xfr-seabios.jpg" /></span>

site/docs/hardware/ga-g41m-es2l.md

@@ -17,7 +17,7 @@ title: Gigabyte GA-G41M-ES2L desktop board
                                         Pentium Extreme/D/4 Extreme/4/Celeron |
 | **Graphics**               | Integrated                                     |
 | **Display**                | None.                                          |
-| **Memory**                 | Up to 16GB                                     |
+| **Memory**                 | Up to 8GB (2x4GB DDR2-800)                     |
 | **Architecture**           | x86_64                                         |
 | **Original boot firmware** | AWARD BIOS                                     |
 | **Intel ME/AMD PSP**       | Present. Can be disabled                       |

site/docs/install/e6400.md

@@ -62,6 +62,19 @@ Intel GPU: libre video initialisation available
 Canoeboot uses coreboot's native `libgfxinit` on this platform, for
 variants with Intel graphics.
 
+Intel GPU errata
+----------------
+
+Systems with a 1440 x 900 display panel instead of the more common 1280 x 800
+panel will have garbled graphics before the OS boots (i.e. in SeaBIOS or GRUB)
+in Libreboot 20240504 and earlier. This is fixed in releases after 20240504.
+
+This was caused by libgfxinit calculating PLL divider values for the pixel clock
+assuming a 96 MHz reference frequency, whereas the E6400 uses a 100 MHz
+reference frequency. The error is not large enough to affect the lower
+resolution panels, but is enough to affect the 1440 x 900 panels which use a
+higher pixel clock.
+
 How to flash internally (no diassembly)
 =======================================
 

site/docs/install/index.md

@@ -3,6 +3,9 @@ title: Installation instructions
 x-toc-enable: true
 ...
 
+Flashprog
+=========
+
 **NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
 now, as of 3 May 2024, which is a fork of flashrom.**
 
@@ -161,11 +164,45 @@ an option in the boot menu.
 ROM images that have `seabios_withgrub` in the file name start with SeaBIOS
 first, but also have GRUB available in the boot menu when you press ESC.
 
+ROM images with this and `grubonly` in the image start SeaBIOS, but only load
+GRUB from SeaBIOS and the SeaBIOS menu is disabled. Use these images if you
+only want GRUB; they are provided on systems that only have VGA ROM-based
+initialisation, usually discrete graphics cards on desktop machines.
+
 Which systems are supported?
 ============================
 
 [Refer to the hardware compatibility page](../hardware/)
 
+Intel GbE MAC address (IFD-based systems)
+=====================================================================
+
+You can change the MAC address in flash, on these machines. See:
+[nvmutil documentation](nvmutil.md)
+
+The MAC address is stored in a region of the boot flashed called *GbE NVM*
+which is short for *gigabit ethernet non-volatile memory*. Refer to the
+following article:
+
+For GM45/ICH9M systems (e.g. ThinkPad X200/T400, Dell Latitude E6400), see:
+[ich9utils documentation](ich9utils.md) (you can also use nvmutil, see link
+above)
+
+Canoeboot puts a default MAC address in the available ROM images, but this is
+a generic MAC address and it's identical on every ROM image. Technically, you
+can use it but if you encounter other Canoeboot users on the same ethernet
+switch, using the same physical network as you, you will encounter a MAC
+address conflict.
+
+NOTE: R500 thinkpads do not have an Intel gigabit ethernet NIC, so on that
+laptop you can just flash the default ROM and you do not have to worry.
+
+There are also some Intel X4X platforms that use an ICH10 southbridge,
+supported in Canoeboot, but these are flashed in a *descriptorless* setup,
+which means that the MAC address is irrelevant (either there will be an Intel
+PHY module that is now unusable, and you use an add-on card, or it doesn't use
+an Intel PHY module and the onboard NIC is usable).
+
 Install via host CPU (internal flashing)
 ========================================
 

site/docs/maintain/index.md

@@ -17,14 +17,13 @@ Automated coreboot build system
 This document describes the entire Canoeboot build system, its design philosophy
 and how it's used to prepare Canoeboot releases; it is provided as a *reference*
 for *Canoeboot development*, pertaining to the current development branch of
-Canoeboot's build system (called *cbmk*, short
-for **C**anoe**B**oot **M**a**K**e).
+Canoeboot's build system (called *cbmk*).
 
 The homepage of Canoeboot says that Canoeboot is a *coreboot distro*, providing
 the necessary integration of coreboot, payloads and utilities so as to provide
-releases, much like GNU+Linux distros do for your operating system, but here we are
+releases, much like Linux distros do for your operating system, but here we are
 concerned about the *boot firmware* instead. Canoeboot is to coreboot, what
-Trisquel is to GNU+Linux. It provides easier, more automated configuration and
+Debian is to Linux. It provides easier, more automated configuration and
 installation.
 
 The build system, cbmk, *is* that coreboot distro, at its very core. You can
@@ -38,86 +37,9 @@ check itself when running *any* command; if another command had to be executed
 first, it will do so automatically. Therefore, you can run any part of cbmk
 on its own, and the entire design is modular.
 
-A note about Canoeboot vs Libreboot
------------------------------------
-
-This manual is provided for reference, although most actual development will
-be done in Libreboot first, and ported over to Canoeboot after each new
-Libreboot release. More information is available in the [about
-page](../../about.md).
-
-Occasional hotfix patches could be submitted to Canoeboot, if it's a patch that
-only affects a Canoeboot release, otherwise you should submit patches
-to [Libreboot](https://libreboot.org/) if the change can also benefit Libreboot;
-Canoeboot would then receive the same change automatically, adapted after the
-next Libreboot release. It is *preferred* that you send patches to Libreboot
-first, because this will reduce the amount of duplicated code review.
-
-You could also use this manual, the Canoeboot documentation, and the Canoeboot
-build system itself, to make your own private modifications or even release
-your own coreboot distro (based upon Canoeboot - and you have this freedom
-with Libreboot too). Many choices are available!
-
-Some of the more seasoned FSF fanatics may not like this, but it's simply
-more efficient to work on Libreboot first and port to Canoeboot afterward. It
-is essentially no different to the Trisquel development model, where development
-from each new Ubuntu releases is adapted for new Trisquel releases; and Trisquel
-has a policy of providing its own builds for everything, rather than directly
-using Ubuntu's own builds - so too does Canoeboot provide its own builds, without
-using any of the builds provided in Libreboot releases. Same sh\*\*, different
-smell. Just plug your nose or something.
-
-Environmental variables
-=======================
-
-CBMK\_THREADS
--------------
-
-For example:
-
-       export CBMK_THREADS=2
-
-This would build on two threads, when running cbmk. It defaults to 1.
-
-Previous revisions of cbmk used `nproc` by default, but this was set to 1
-instead, because nproc is not available on every operating system.
-
-CBMK\_STATUS
-------------
-
-By default, the user is asked to confirm when building for a given mainboard,
-if that mainboard is not marked *stable* in `target.cfg`. To disable such
-dialogs, do this:
-
-       export CBMK_STATUS=n
-
-CBMK\_RELEASE
--------------
-
-If set to `y`, it signals to `script/build/roms` that a release is being built,
-and it will honour `release="n"` in target.cfg files. You could also set this
-yourself, when doing regular builds, if you wanted to test how `./build roms`
-behaves running it in release mode. Do this if you want to:
-
-       export CBMK_RELEASE=y
-
 Best practises for learning cbmk
 ================================
 
-In addition to *cbmk* (CanoeBoot MaKe), you could also learn lbmk (LibreBoot
-MaKe); lbmk is the Libreboot build system. A very similar document to the one
-you're reading now, is available as the [lbmk maintenance
-manual](https://libreboot.org/docs/maintain/); since Canoeboot is based on
-Libreboot, you may find it useful to know *Libreboot*. This and the lbmk manual,
-in addition to Canoeboot vs Libreboot generally, are two sides of the same coin,
-and both projects are lead by the same developer (Leah Rowe). Libreboot and
-Canoeboot are light and dark, but which is which depends on your perspective.
-
-As stated elsewhere, the preference is for most/all development to go in
-Libreboot first, because Canoeboot simply re-bases patches from Libreboot.
-This is done, to reduce duplication of labour, since both projects are
-maintained by the same developer.
-
 The follow sections will cover subdirectories, within cbmk. Contrary to what
 some may otherwise assume, it's best to learn about everything *except* scripts
 or code within Canoeboot, first. No, you should first learn about config files
@@ -140,10 +62,35 @@ Don't be deceived by simplicity
 Canoeboot's build system is powerful, and highly configurable, yet deceptively
 simple at the same time. Remember this rule, a rule that applies to *all*
 software projects: code equals bugs, so smaller codebases will yield fewer bugs.
-Canoeboot benefits from regular auditing in the *Libreboot* build system, where
-the improvements are ported to Canoeboot after each Libreboot release.
+Canoeboot is [regularly](../../news/audit.md) [audited](../../news/audit2.md).
 
-You'll be surprised by how much can be done with so little. Continue reading!
+Many people will be shocked by how *small* Canoeboot is, at its core. You will
+be surprised by just how much can be done with so little. Continue reading!
+
+Environmental variables
+=======================
+
+XBMK\_THREADS
+-------------
+
+For example:
+
+	export XBMK_THREADS=2
+
+This would build on two threads, when running cbmk. It defaults to 1.
+
+Previous revisions of cbmk used `nproc` by default, but this was set to 1
+instead, because nproc is not available on every operating system.
+
+XBMK\_RELEASE
+-------------
+
+If set to `y`, it signals to `script/roms` that a release is being built,
+and it will honour `release="n"` in target.cfg files. You could also set this
+yourself, when doing regular builds, if you wanted to test how `./build roms`
+behaves running it in release mode. Do this if you want to:
+
+	export XBMK_RELEASE=y
 
 Projects/files downloaded/generated by cbmk
 ===========================================
@@ -173,12 +120,6 @@ The files under `bin/` are provided in regular Canoeboot releases.
 **These** are the ROM images that you should flash. Do *not* flash the ROM
 images contained under `elf/`!
 
-cbutils/
----------------
-
-The build system compiles `cbfstool` and `ifdtool`, from coreboot, and then
-places the executables here for use on coreboot ROM images.
-
 elf/
 ---------------
 
@@ -202,15 +143,39 @@ cbmk in your own custom coreboot ROM (that you didn't build with cbmk).
 This is only used by the build system, but these images are *not* provided in
 releases (only the images under `bin/` are provided).
 
+As of Canoeboot 20240612, the `elf/` directory must be used by default for all
+builds, in an effort to make exclusive use of *out-of-source builds*. As such,
+the `cbutils` directory is no longer used.
+
 release/
 ---------------
 
-The script at `script/update/release` create tarballs in here, which
+The script at `build` create tarballs in here, which
 constitute regular Canoeboot releases. It is meticulously maintained, as per
 current cbmk behaviour, and executed so as to provide Canoeboot release
 archives.
 
-This provides source tarballs and ROM images.
+This provides source tarballs, and ROM images.
+
+You can create release archives by doing:
+
+	./update release
+
+By default, this creates a release under `release/`, but you can change the
+directory, for example:
+
+	./update release -d path
+
+You can also specify that only a *source archive* be created, like so:
+
+	./update release -m src
+
+Or with a custom directory:
+
+	./update release -d path -m src
+
+The build system expects there to be a *git tag*, so make sure there is one.
+This is used to create the version number for a given release.
 
 src/
 ----
@@ -243,7 +208,7 @@ src/flashprog/
 Please also visit: <https://flashprog.org/>
 
 Although currently unused by any part of cbmk, we provide flashprog for the
-convenience of users, and this is copied to release archives. Flashprog is the
+convenience of users, and this is copied to release archives. Flashrom is the
 program that you will use to read, erase and write the flash, containing
 coreboot firmware.
 
@@ -351,9 +316,6 @@ desirable, `cbmk.git` provides a few utilities as part of itself, namely:
 util/dell-flash-unlock/
 ---------------
 
-**NOTE: The util is now called `dell-flash-unlock`, but it
-was previously called `e6400-flash-unlock`. Links have been updated.**
-
 This program, written by Nicholas Chin, unlocks the boot flash on Dell Latitude
 E6400; it permits internal flashing, from factory firmware to Canoeboot, so that
 the user need not disassemble and flash externally.
@@ -393,7 +355,7 @@ directly into `cbmk.git`, and thoroughly cleaned. The cbmk version has been
 more or less re-written, using the original logic as a base; variables are
 more clearly named. A top-down, OpenBSD-inspired coding style is used,
 replacing the GNU coding style implemented in the original code. The [OpenBSD
-coding style](https://man.openbsd.org/style.9) is much easier to read.
+coding style][https://man.openbsd.org/style.9] is much easier to read.
 
 This code has been modified to make use of the `pledge()` system call, when used
 on [OpenBSD](https://www.openbsd.org/); the original version from GRUB did not
@@ -414,18 +376,28 @@ by cbmk:
 config/
 =======
 
-config/PROJECT\*/blobs.list
----------------------------
-
-The script `include/git.sh` handles deletion of binary blobs, for downloaded
-projects, based on a `blobs.list` file that can (for single-tree projects) be
-included at `config/PROJECT/blobs.list` or (multi-tree project)
-at `config/PROJECT/TREE/blobs.list`. Learn more about how de-blobbing is
-handled by reading the [about page](../../about.md).
-
 This directory contains configuration files, used by the Canoeboot build
 system. These next sections will cover specific configuration files.
 
+config/PROJECT\*/nuke.list
+--------------------------
+
+The script `include/git.sh` handles deletion of certain files, for downloaded
+projects, based on a `nuke.list` file that can (for single-tree projects) be
+included at `config/PROJECT/nuke.list` or (multi-tree project)
+at `config/PROJECT/TREE/nuke.list` (entries are relative links from the root
+directory of the given source tree e.g. `src/coreboot/default/`).
+
+So, if `src/coreboot/default/` contained foo/bar.txt, you could add to
+the `nuke.list` file as follows:
+
+```
+foo/bar.txt
+```
+
+Ditto `src/flashprog/`, if you wanted to delete a file from in there, as one
+other example. Deletions occur when the source tree is created.
+
 config/coreboot
 ---------------
 
@@ -435,7 +407,7 @@ When a given coreboot tree is compiled, for a given target, this file defines
 which files to copy from the coreboot directory, which are then copied to
 a location under `elf/coreboot`.
 
-The presence of this file affects behaviour in `script/update/release`;
+The presence of this file affects behaviour in `./update release` commands;
 specifically, PROJECT is then downloaded to `src/PROJECT/PROJECT`, and files
 under `config/PROJECT/TARGET/target.cfg` define which tree to use, which then
 looks under `config/PROJECT/TREE/target.cfg` to get the git revision; then
@@ -485,9 +457,9 @@ as:
 * `grub_scan_disk="ata"`
 * `uboot_config=default` (specify which U-Boot tree to use)
 * `release="n"` (example entry)
-* `status=stable` (example entry)
 * `xtree="default"` (example entry)
 * `tree_depend="default"` (example entry)
+* `grubtree="nvme"` (example entry)
 
 The `tree` value refers to `config/coreboot/TREE`; in other words, a given
 target could specify a name other than its own as the tree; it would then
@@ -533,25 +505,17 @@ other than `default`, which is the default if the option is missing.
 The `grub_scan_disk` option specifies can be `ahci`, `ata` or `both`, and it
 determines which types of disks are to be scanned, when the `grub.cfg` file in
 GRUB payloads tries to automatically find other `grub.cfg` files supplied by
-your GNU+Linux distribution. On some machines, setting it to `ata` or `ahci`
+your Linux distribution. On some machines, setting it to `ata` or `ahci`
 can improve boot speed by reducing delays; for example, trying to scan `ata0`
 on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that
 machine it is advisable to set this option to `ahci` (becuse the default HDD
 slot is AHCI).
 
-The `release` variable can be set to n, which makes the `script/update/release`
-script skip that target, when creating release images. For example, a given
+The `release` variable can be set to n, which makes the `./update release`
+call skip that target, when creating release images. For example, a given
 board may not be stable and you don't want images for it to be included in the
 release.
 
-The `status` variable can be set to whatever you want, but anything other
-than `stable` will make `script/build/roms` ask for y/n confirmation if
-not building images using `script/update/release`.
-
-Recommended strings for `status` could be: `stable`, `unstable`, `broken`
-or `untested`. Alternatively, you might state `wip`. You can set whatever
-string you want here.
-
 The `xtree` option specifies that a given tree with use a specific coreboot
 tree for compiling crossgcc. This can be used to skip building gcc if OK on
 a given board; two trees may use the same crossgcc as each other.
@@ -559,12 +523,8 @@ a given board; two trees may use the same crossgcc as each other.
 The `tree_depend` option means that a given tree needs another tree, defined
 by this variable, to also be present.
 
-### config/coreboot/BOARDNAME/warn.txt
-
-Additionally: the `warn.txt` file can be included alongside target.cfg, to
-provide warning of any potential issues or quirks. For example, raminit may
-only be reliable with certain modules. This is printed on the user's terminal
-when building that target.
+The `grubtree` option specifies which GRUB tree to use. If unset, it defers to
+the `default` GRUB tree.
 
 ### config/coreboot/BOARDNAME/config/
 
@@ -672,18 +632,18 @@ of their own; for example, `config/grub/` exists.
 Multiple files exist here, and they are *concatenated* in a temporary file by
 cbmk, which is then scanned to find information about projects.
 
-config/grub/
+GRUB config
 ---------------
 
-### config/grub/background
+### config/data/grub/background
 
 Splash screen images applied duing startup when using the GRUB payload.
 
-### config/grub/background/background1024x768.png
+### config/data/grub/background/background1024x768.png
 
 Used on ThinkPad X60 and T60.
 
-### config/grub/background/background1280x800.png
+### config/data/grub/background/background1280x800.png
 
 Used on all other machines, besides X60 and T60 thinkpads.
 
@@ -693,23 +653,15 @@ example, `config/coreboot/x60/target.cfg` specifies this:
 
 	grub_background="background1024x768.png"
 
-### config/grub/background/COPYING
+### config/data/grub/background/COPYING
 
 Licensing info for GRUB bootsplash images.
 
-### config/grub/config/
+### config/grub/TREE/config/
 
 GRUB configuration files.
 
-### config/grub/config/AUTHORS
-
-Author info for GRUB configuration files.
-
-### config/grub/config/COPYING
-
-Licensing info for GRUB configuration files.
-
-### config/grub/config/grub.cfg
+### config/grub/TREE/config/grub.cfg
 
 This is a configuration file. It is used to program GRUB's shell.
 
@@ -723,7 +675,7 @@ A `grubtest.cfg` can be inserted into CBFS, but it will not override the
 default `grub.cfg` (either in CBFS or on memdisk); however, the one in memdisk
 will provide a menuentry for switching to this, if available.
 
-### config/grub/config/grub\_memdisk.cfg
+### config/data/grub/memdisk.cfg
 
 This GRUB configuration checks whether `grub.cfg` exists in CBFS and switches
 to that first (not provided by default) or, if one is not available in CBFS,
@@ -733,12 +685,12 @@ The GRUB memdisk is a file system within `grub.elf`, itself stored within the
 coreboot file system named *CBFS*, which is part of the coreboot ROM image on
 every coreboot target.
 
-### config/grub/keymap/
+### config/data/grub/keymap/
 
 Keymap files used by GRUB. They can alter the character set corresponding to
 inputted scancodes.
 
-### config/grub/keymap/\*.gkb
+### config/data/grub/keymap/\*.gkb
 
 The keymap files themselves. These are inserted into the GRUB memdisk, and
 the `grub.cfg` file can specify which one is to be used.
@@ -747,7 +699,7 @@ These files are binary-encoded, defining which characters correspond to which
 scancodes. It is handled by `grub-core/commands/keylayouts.c` in the GRUB source
 code.
 
-### config/grub/modules.list
+### config/data/grub/modules/TREE
 
 This defines which modules are inserted into `grub.elf`. These modules can be
 anything from file systems, small applications/utilities, launchers (e.g.
@@ -913,6 +865,56 @@ Another interesting config option is `CONFIG_POSITION_INDEPENDENT` for ARM
 boards, which has been so far enabled in the ones `cbmk` supports, just to be
 safe.
 
+config/submodule
+----------------
+
+In here you can find submodule configurations for projects. It works for both
+single- and multi-tree projects. Use the existing examples as reference.
+
+Files, in each directory:
+
+* `module.list` lists paths (files and directories) for given modules, which
+  can be files(via URL) or Git repositories, or both.
+* NAME/module.cfg
+
+NAME is the file/directory name for the module, with everything up to the
+final forward slash removed. E.g. foo/bar/thing.zip would be thing.zip as
+NAME.
+
+In `module.cfg` there can be either, file:
+
+```
+subfile="url"
+subfile_bkup="url"
+subhash="sha512sum for file"
+```
+
+or, git repository:
+
+```
+subrepo="url"
+subrepo_bkup="url"
+subhash="sha1 git commit id"
+```
+
+You must only use `subfile` or `subrepo`, not both, and there must be a backup
+URL. The build system intentionally *avoids* using Git's actual submodules
+feature, instead opting to download such repositories manually, because the
+official submodules feature doesn't have very good redundancy.
+
+Additionally, a `patches` directory can be included alongside `module.cfg`,
+which can be used to patch the submodule (only supported for Git repositories
+because files are not extracted, only placed at their configured destination).
+
+The destination path in `module.list` is relative to the location of the main
+Git repository under which it is placed.
+
+config/data/PROJECT
+-------------------
+
+Random configuration data provided on a per-project basis. Complements
+the `config/PROJECT` directory.
+
 U-Boot build system
 -------------------
 
@@ -977,38 +979,28 @@ Scripts in root directory of cbmk
 build
 ---------------
 
-This is the main script in cbmk, Canoeboot's build system. It is what executes
-all other parts of the Canoeboot build system. The rules are as follows:
+This is the main script. The symlink named `update` also point to it.
 
-* Argument zero, representing the name of the symlink, will be used to
-  execute `script/LINKNAME/COMMAND` - for example: `./build roms all`
-  would execute `script/build/roms all` in `sh`.
-* In the above example, `LINKNAME` could also be `update`. In examples below,
-  symlinks are described pointing to `build` (the actual script). The script
-  works by checking argument zero, so it would look in a different directory
-  under `script/` matching `LINKNAME` - in this case, `script/update/`
-* `TMPDIR` is exclicitly set, providing a constant location where temporary
-  files and directories can be made. `TMPDIR` is exported by the parent to
-  all children; for example, `./build roms all` would export it
-  to `script/build/roms`, and then anything called by *that* will also
-  inherit it - the main parent process running `cbmk` will then clean up this
-  `TMPDIR` directory upon any exit.
-* All exits from cbmk are handled by this script. *All* exits, zero or non-zero,
-  are engineered such that *this* script, in the parent process (the very first
-  instance) is what ultimately exits back to the user's shell prompt.
-* This script is programmed to *exit* with non-zero status, when run as root,
-  unless the `./build dependencies *` commands are used,
-  referencing files under `config/dependencies/`
-* Under fault conditions, each child process shall output to stderr, and the
-  main parent process running `cbmk` will output the final error message.
+Take any given file under `script/` and you can do:
 
-tl;dr break this script and you *break Canoeboot*.
+	./build file # (THIS IS NOT A VALID COMMAND)
 
-update
----------------
+For example:
 
-Symbolic link, pointing to the `build` script. This is executed by the user, or
-by cbmk, referencing scripts under `script/update/`.
+	./build roms
+	./update trees
+
+Special commands available (not provided by files under `script/`):
+
+	./update release
+
+Information about `./update release` is written elsewhere on this page.
+
+You can also know what build system revision you have by running:
+
+	./build version
+
+This script is the beating heart of Libreboot. Break it and you break Libreboot.
 
 include/
 ===============
@@ -1017,35 +1009,20 @@ This directory contains *helper scripts*, to be included
 by main scripts using the `.` command (called the `source`
 command in `bash`, but we rely upon posix `sh` only).
 
-include/err.sh
+include/git.sh
+--------------
+
+These functions in here previously existed as independent scripts, but they
+were unified here, and they are used when you pass the `-f` argument
+to `script/update/trees` (e.g. `./update trees -f coreboot`).
+
+These functions deal with git cloning, submodule updates, revision resets and
+the application of patch files via `git am`. *Every* git repository downloaded
+by cbmk is handled by the functions in this file.
+
+include/lib.sh
 ---------------
 
-Generic error handling, used by all cbmk scripts.
-
-This also contains functions to verify the current canoeboot version, and check
-whether Git is properly initialised on the host system. It also contains
-the `setvars` function, which provides a shorthand way of initialising many
-variables (combined with use of `eval`), which cbmk uses heavily.
-
-This function also contains `x_` and `xx_` which cbmk uses to execute commands
-and ensure that they cause an exit (with non-zero status) from cbmk, if they
-return an error state; the `xx_` function calls `fail()` which a script must
-provide, to perform some action before calling `err` which in turn prints an
-error message provided as argument. It is used similarly to the C
-function `err()` in BSD libc. The `x_` function simply calls `err`.
-
-This entire file is heavily inspired by `err.h` in BSD libc code. This file is
-heavily used by cbmk (it's used by every script), to provide clean error
-handling in `sh`.
-
-include/option.sh
----------------
-
-Functions used by scripts under `script/vendor/`, for checking defconfig
-files. These files are checked because the scripts need to know whether a given
-file is used; if it is, a path is then specified in defconfig, telling the vendor
-script either where it is, or where it should be downloaded to.
-
 Several other parts of cbmk also use this file. It is added to as little as
 possible, and contains miscallaneous functions that don't belong anywhere else.
 
@@ -1054,7 +1031,7 @@ them to set variables and so on.
 
 This file also contains generic error handling, used by all cbmk scripts.
 
-This also contains functions to verify the current canoeboot version, and check
+This also contains functions to verify the current Canoeboot version, and check
 whether Git is properly initialised on the host system. It also contains
 the `setvars` function, which provides a shorthand way of initialising many
 variables (combined with use of `eval`), which cbmk uses heavily.
@@ -1066,20 +1043,8 @@ return an error state.
 script/
 =======
 
-*All* scripts under `script/` are executed only by the main `cbmk` script,
-conforming to the standard `buildpath/option` e.g. `build/roms` - so,
-running `./build roms` would run `script/build/roms`.
-
-script/build/
----------------
-
-These are highly specialised build scripts, written for specific tasks, almost
-entirely in the context of building firmware images themselves, but some utils
-are also handled.
-
-The scripts that create release archives are also located under this directory.
-
-### script/build/roms
+script/roms
+-----------
 
 This builds coreboot ROM images.
 
@@ -1098,6 +1063,11 @@ To build *all* targets, specify:
 
 	./build roms all
 
+This script can build images for x86 *and* ARM targets.
+The *ARM* targets are ChromeOS devices (chromebooks and such); Canoeboot uses
+the *U-Boot* payload, rather than Google's *depthcharge* bootloader. In this
+setup, U-Boot is running on the bare metal, as enabled by *coreboot*.
+
 For x86 targets, these scripts build with the GRUB and/or SeaBIOS payloads
 inserted into the ROM images; secondary payloads like Memtest86+ are also
 handled and inserted here.
@@ -1116,28 +1086,6 @@ It creates ROM images with GRUB, SeaBIOS, U-Boot, optionally with Memtest86+
 also included, in various separate configurations in many different ROM images
 for user installation.
 
-The `romtype` entry in `target.cfg` tells this script what to do with the ROM,
-after it has been built. Currently, it operates based on these possible values
-for `romtype`:
-
-* `d8d16sas` will cause *fake* (empty) files named `pci1000,0072.rom`
-  and `pci1000,3050.rom` to be inserted in CBFS. This prevents SeaBIOS from
-  loading or executing the option ROM stored on PIKE2008 modules, present on
-  certain configurations with the ASUS KCMA-D8 or KGPE-D16 mainboards. Those
-  option ROMs cause the system to hang, so they should never be executed (this
-  means however that booting Linux kernels from SAS devices is impossible on
-  those boards, unless a Linux payload is used; Linux can use those SAS drives,
-  without relying on the PIKE2008 option ROMs). When SeaBIOS runs, it will
-  default to loading the corresponding option ROM from CBFS, if it exists, for
-  a given PCI device, overriding whatever option ROM is present on the device
-  itself, but if the option ROM is invalid/empty, SeaBIOS will not attempt to
-  load another one, until the empty/invalid one (in CBFS) is deleted.
-* `i945 laptop`: in this configuration, the upper 64KB section of the ROM is
-  copied into the 64KB section below that. This results in there being two
-  bootblocks in the ROM, and you can decide which one is used by setting `bucts`
-* If no declaration is made, or a declaration is made contrary to the above,
-  no special modifications will be made.
-
 If no payload is defined in `target.cfg`, the `build/roms` script will exit
 with error status.
 
@@ -1166,51 +1114,25 @@ When the ROM is finished compiling, it will appear under a directory in `bin/`
 This script is the beating heart of Canoeboot. Break it, and you break
 Canoeboot!
 
-### script/build/serprog
+Serprog images:
 
 Build firmware images for serprog-based SPI programmers, where they use an
 STM32 MCU. It also builds for RP2040-based programmers like Raspberry Pi Pico.
 
-Example command: `./build serprog stm32`
+Example command: `./build roms serprog stm32`
 
-Example command: `./build serprog rp2040`
+Example command: `./build roms serprog rp2040`
 
 The `list` argument is available:
 
-	./build serprog stm32 list
+	./build roms serprog stm32 list
+	./build roms serprog rp2040 list
 
 Without arguments, all targets would be compiled, but you can specify a short
 list of targets instead, based on the output of `list`.
 
-script/update/
---------------
-
-This handles most actual building of source trees, called into by scripts
-under `script/update/`.
-
-### script/update/release
-
-This script builds the release archives, which are then provided in a new
-Canoeboot release. Most users do not need to look at this file at all, but it
-is provided under free license for curious souls.
-
-Command: `./update release`
-
-NOTE: if the `-d` option is used, you can specify a directory other
-than `release`. For example:
-
-	./update release -d /media/stuff/canoeboot_release_test
-
-If `-d` is not passed, they will go under `release/` in your cbmk repository.
-The script is engineered to re-initialise git if ran from a release archive.
-
-This builds release archives, containing ROM images for coreboot and/or serprog
-programmers. It works simply: cbmk clones *itself*, and builds itself in its
-clone, then cleans itself up and creates tarballs. If you run this script, you
-should expect it to take at least 4 hours; slower on really old systems. On
-really fast systems, it might take 2-3 hours.
-
-### script/update/trees
+script/trees
+------------
 
 *This* is the other beating heart of Canoeboot. Used heavily by Canoeboot, this
 script is what handles defconfig files for SeaBIOS, U-Boot *and* coreboot; it
@@ -1286,8 +1208,7 @@ As for *projectname", this can either be `coreboot`, `u-boot` or `seabios`.
 Example commands:
 
 	./update trees -b coreboot
-	./update trees -b coreboot x200_8mb
-	./update trees -b coreboot x230_12mb x220_8mb t1650_12mb
+	./update trees -b coreboot x200_8mb t60_intelgpu
 	./update trees -x coreboot default
 	./update trees -u seabios
 	./update trees -m u-boot gru_bob
@@ -1325,3 +1246,8 @@ SeaBIOS which are *multi* downloads. The *other* requirement is that defconfigs
 be used, though this could be worked around in the future if a *multi* setup is
 needed on a project that *does not use defconfigs* (this is not yet the case in
 cbmk).
+
+All of this used to about 20 different scripts, all with much-duplicated logic.
+Now it is unified, efficiently, under a single script.
+
+Remember: code equals bugs, so less code equals fewer bugs.

site/download.md

@@ -14,7 +14,7 @@ Canoeboot from source, [read this page](docs/build/).
 GPG signing key
 ---------------
 
-**The latest release is Canoeboot 20240510, under the `canoeboot` directory.**
+**The latest release is Canoeboot 20240612, under the `canoeboot` directory.**
 
 ### NEW KEY
 
@@ -58,7 +58,7 @@ For your convenience, these are linked below (on the mirror lists).
 HTTPS mirrors {#https}
 -------------
 
-**The latest release is Canoeboot 20240510, under the `canoeboot` directory.**
+**The latest release is Canoeboot 20240612, under the `canoeboot` directory.**
 
 These mirrors are recommended, since they use TLS (https://) encryption.
 
@@ -153,7 +153,7 @@ crontab. This page tells you how to use crontab:
 HTTP mirrors {#http}
 ------------
 
-**The latest release is Canoeboot 20240510, under the `canoeboot` directory.**
+**The latest release is Canoeboot 20240612, under the `canoeboot` directory.**
 
 WARNING: these mirrors are non-HTTPS which means that they are
 unencrypted. Your traffic could be subject to interference by
@@ -167,7 +167,7 @@ if using HTTPS.
 FTP mirrors {#ftp}
 -----------
 
-**The latest release is Canoeboot 20240510, under the `canoeboot` directory.**
+**The latest release is Canoeboot 20240612, under the `canoeboot` directory.**
 
 WARNING: FTP is also unencrypted, like HTTP. The same risks are present.
 

site/download.uk.md

@@ -14,7 +14,7 @@ Canoeboot із джерельного кода, [прочитайте цю ст
 Код підпису GPG
 ---------------
 
-**Останнім випуском є Canoeboot 20240510, в директорії `canoeboot`.**
+**Останнім випуском є Canoeboot 20240612, в директорії `canoeboot`.**
 
 ### NEW KEY
 
@@ -56,7 +56,7 @@ For your convenience, these are linked below (on the mirror lists).
 Дзеркала HTTPS {#https}
 -------------
 
-**Останнім випуском є Canoeboot 20240510, в директорії `canoeboot`.**
+**Останнім випуском є Canoeboot 20240612, в директорії `canoeboot`.**
 
 Дані дзеркала є рекомендованими, оскільки використовують TLS (https://) шифрування.
 
@@ -151,7 +151,7 @@ crontab. Ця сторінка розповідає вам, як викорис
 Дзеркала HTTP {#http}
 ------------
 
-**Останнім випуском є Canoeboot 20240510, під директорією `canoeboot`.**
+**Останнім випуском є Canoeboot 20240612, під директорією `canoeboot`.**
 
 УВАГА: ці дзеркала є не-HTTPS, що означає, що вони
 незашифровані. Ваш трафік може бути об'єктом втручання
@@ -165,7 +165,7 @@ crontab. Ця сторінка розповідає вам, як викорис
 Дзеркала FTP {#ftp}
 -----------
 
-**Останнім випуском є Canoeboot 20240510, під директорією `canoeboot`.**
+**Останнім випуском є Canoeboot 20240612, під директорією `canoeboot`.**
 
 УВАГА: FTP є також незашифрованим, подібно HTTP. Ті ж самі ризики присутні.
 

site/git.de.md

@@ -3,23 +3,8 @@ title: Code review
 x-toc-enable: true
 ...
 
-NOTE FOR CONTRIBUTORS:
-======================
-
-The preferred development style is: work on Libreboot, and port changes from
-each Libreboot release into Canoeboot, but do it all at once. Whenever a new
-Libreboot release comes out, a Canoeboot release will happen either
-simultaneously or a few days later, porting all suitable changes over from
-the Libreboot release. More information about this is available
-in the [about page](about.md).
-
-In other words: please only send patches directly to Canoeboot, if they are
-patches that only Canoeboot can benefit from; use your best judgement. The
-same rule applies for bug reports and testing; do Libreboot first.
-
-Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
-Please see: [Libreboot git page](https://libreboot.org/git.html)
-and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
+If you wish to submit patches, you can. Submit them, using the instructions
+provided in the following sections:
 
 Canoeboot Repositories
 ===================
@@ -156,37 +141,6 @@ Commits/Patches verwendest dann solltest Du anonym sein. Verwende
 und [git show](https://git-scm.com/docs/git-show) um dies zu überprüfen
 bevor Du einem öffentlichen Git Repository Änderungen hinzufügst.
 
-Lizenzen (für Mitwirkende)
---------
-
-Stelle sicher, dass deine Beiträge mit einer libre Lizenz frei lizensiert
-sind. Canoeboot schreibt nicht mehr vor, welche Lizenzen akzeptiert werden,
-und es existieren einige Lizenzen. Wir werden deinen Beitrag prüfen und
-dir mitteilen sofern es ein Problem damit gibt (z.B. keine Lizenz).
-
-Gib *immer* eine Lizenz an für deine Arbeit! Keine Lizenz anzugeben bedeutet
-das deine Arbeit unter die Standard Urheberrechte fällt, was deine Arbeit 
-proprietär macht und somit von denselben Einschränkungen betroffen ist.
-
-Die MIT Lizenz ist ein guter Start, und sie ist die bevorzugte Lizenz
-für sämtliche Arbeit an Canoeboot, aber wir sind nicht pingelig. Canoeboot 
-hat in der Vergangenheit GNU Lizenzen so wie GPL verwendet; vieles davon
-besteht nach wie vor und wird auch weiterhin bestehen.
-Es ist deine Arbeit; sofern deine Arbeit auf der Arbeit eines anderen basiert,
-ist es aufgrund der Lizenz-Kompatibilität ggfs. naheliegend diesselbe Lizenz zu
-verwenden.
-
-[Hier](https://opensource.org/licenses) findest Du übliche Beispiele für Lizenzen.
-
-*Wenn* deine Arbeit auf bestehender Arbeit basiert, dann ist es wichtig
-(für deinen Beitrag) das die Lizenz deiner Arbeit kompatibel ist mit der
-Lizenz der Arbeit auf der sie beruht. Die MIT Lizenz ist hierfür gut geeignet,
-weil sie mit vielen anderen Lizenen kompatibel ist, und Freiheit zulässt
-(wie zum Beispiel die Freiheit einer SubLizenz) was bei vielen anderen
-Lizenzen nicht der Fall ist:
-
-<https://opensource.org/licenses/MIT>
-
 Patches senden
 ------------
 

site/git.md

@@ -3,37 +3,8 @@ title: Code review
 x-toc-enable: true
 ...
 
-NOTE FOR CONTRIBUTORS:
-======================
-
-The preferred development style is: work on Libreboot, and port changes from
-each Libreboot release into Canoeboot, but do it all at once. Whenever a new
-Libreboot release comes out, a Canoeboot release will happen either
-simultaneously or a few days later, porting all suitable changes over
-from the Libreboot release. More information about this is available
-in the [about page](about.md).
-
-Exceptions are often made. Since only a subset of Libreboot changes are suitable
-for Canoeboot at any given time, the result is that a given Libreboot release
-may be *skipped* if the remaining Canoeboot-friendly changes are of low quantity.
-
-In other words: please only send patches directly to Canoeboot, if they are
-patches that only Canoeboot can benefit from; use your best judgement. The
-same rule applies for bug reports and testing; do Libreboot first.
-
-Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
-Please see: [Libreboot git page](https://libreboot.org/git.html)
-and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
-
-While not everyone(especially the more hardened FSF fanatics) may approve of it,
-this is how Canoeboot is officially developed. It is essentially no different
-to how *Trisquel* is maintained, re-basing upon each new Ubuntu release! It is
-simply more efficient, enabling a general reduction in the duplication of labour.
-
-Leah Rowe is the BDFL for both Libreboot and Canoeboot, so this arrangement
-enables a tight grip on both projects, ensuring that they are always in
-absolutely perfect sync with each other (with the exception that Canoeboot
-will only include those changes which comply with GNU FSDG criteria).
+If you wish to submit patches, you can. Submit them, using the instructions
+provided in the following sections:
 
 Canoeboot repositories
 ===================
@@ -162,36 +133,6 @@ should be fairly anonymous. Use
 and [git show](https://git-scm.com/docs/git-show) to confirm that before you
 push changes to a public Git repository.
 
-Licenses (for contributors)
---------
-
-Make sure to freely license your work, under a libre license. Canoeboot no
-longer sets arbitrary restrictions on what licenses are accepted, and many
-licenses out there already exist. We will audit your contribution and tell
-you if there are problems with it (e.g. no license).
-
-*Always* declare a license on your work! Not declaring a license means that
-the default, restrictive copyright laws apply, which would make your work
-proprietary, subject to all of the same restrictions.
-
-The MIT license is a good one to start with, and it is the preferred license
-for all new works in Canoeboot, but we're not picky. Canoeboot has historically
-used GNU licensing such as GPL; much of that remains, and is likely to remain.
-It's your work; obviously, if you're deriving from an existing work,
-it may make sense to use the same license on your contribution, for license
-compatibility.
-
-You can find common examples of licenses
-[here](https://opensource.org/licenses).
-
-If you *are* deriving from an existing work, it's important that your license
-(for your contribution) be compatible with the licensing of the work from which
-yours was derived. The MIT license is good because it's widely compatible
-with many other licenses, and permits many freedoms (such as the freedom to
-sublicense) that other licenses do not:
-
-<https://opensource.org/licenses/MIT>
-
 Send patches
 ------------
 

site/git.uk.md

@@ -3,37 +3,8 @@ title: Огляд коду
 x-toc-enable: true
 ...
 
-NOTE FOR CONTRIBUTORS:
-======================
-
-The preferred development style is: work on Libreboot, and port changes from
-each Libreboot release into Canoeboot, but do it all at once. Whenever a new
-Libreboot release comes out, a Canoeboot release will happen either
-simultaneously or a few days later, porting all suitable changes over
-from the Libreboot release. More information about this is available
-in the [about page](about.md).
-
-Exceptions are often made. Since only a subset of Libreboot changes are suitable
-for Canoeboot at any given time, the result is that a given Libreboot release
-may be *skipped* if the remaining Canoeboot-friendly changes are of low quantity.
-
-In other words: please only send patches directly to Canoeboot, if they are
-patches that only Canoeboot can benefit from; use your best judgement. The
-same rule applies for bug reports and testing; do Libreboot first.
-
-Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
-Please see: [Libreboot git page](https://libreboot.org/git.html)
-and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
-
-While not everyone(especially the more hardened FSF fanatics) may approve of it,
-this is how Canoeboot is officially developed. It is essentially no different
-to how *Trisquel* is maintained, re-basing upon each new Ubuntu release! It is
-simply more efficient, enabling a general reduction in the duplication of labour.
-
-Leah Rowe is the BDFL for both Libreboot and Canoeboot, so this arrangement
-enables a tight grip on both projects, ensuring that they are always in
-absolutely perfect sync with each other (with the exception that Canoeboot
-will only include those changes which comply with GNU FSDG criteria).
+If you wish to submit patches, you can. Submit them, using the instructions
+provided in the following sections:
 
 репозиторії Canoeboot
 ===================
@@ -162,36 +133,6 @@ Untitled.
 та [git show](https://git-scm.com/docs/git-show), щоб підтвердити це перед тим, як ви
 надсилаєте зміни до загальнодоступного сховища Git.
 
-Ліцензії (для учасників)
---------
-
-Обов'язково вільно ліцензуйте свою роботу, за вільною ліцензією. Canoeboot більше не
-встановлює довільні обмеження на те, які ліцензії приймаються, і багато
-інших ліцензій вже існує. Ми перевіримо ваш внесок і розкажемо вам, якщо з ним
-виникли проблеми (наприклад, немає ліцензії).
-
-*Завжди* декларуйте ліцензію на свою роботу! Недекларування ліцензії означає, що
-за замовчуванням застосовуються обмежувальні закони про авторське право, які зроблять вашу роботу
-захищеною власністю, підпадаючи під усі ті самі обмеження.
-
-Ліцензія MIT є хорошою для початку, і вона є бажаною ліцензією
-для всіх нових робіт у Canoeboot, але ми не вибагливі. Canoeboot історично
-використовував ліцензування GNU, таке як GPL; багато з цього залишилося, і, ймовірно, залишиться.
-Це ваша робота; очевидно, якщо ви використовуєте існуючу роботу,
-може мати сенс використовувати ту саму ліцензію для вашого внеску, для сумісності
-ліцензії.
-
-Ви можете знайти типові приклади ліцензій
-[тут](https://opensource.org/licenses).
-
-Якщо ви *виходите* на основі існуючого твору, важливо, щоб ваша ліцензія (на ваш внесок)
-була сумісна з ліцензуванням твору, з якого
-ваш був отриманий. Ліцензія MIT хороша, оскільки вона широко сумісна
-з багатьма іншими ліцензіями та надає багато свобод (наприклад, свободу
-субліцензування), яких немає в інших ліцензіях:
-
-<https://opensource.org/licenses/MIT>
-
 Надсилайте виправлення
 ------------
 

site/index.de.md

@@ -15,9 +15,9 @@ und [Libera](https://libera.chat/) IRC.
 
 <img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
 
-**NEUESTE VERSION: Die neueste Version von Canoeboot ist 20240510, veröffentlicht
-am 10. May 2024.
-Siehe auch: [Canoeboot 20240510 release announcement](news/canoeboot20240510.md).**
+**NEUESTE VERSION: Die neueste Version von Canoeboot ist 20240612, veröffentlicht
+am 12. June 2024.
+Siehe auch: [Canoeboot 20240612 release announcement](news/canoeboot20240612.md).**
 
 Warum solltest Du *Canoeboot* verwenden?
 ----------------------------

site/index.fr.md

@@ -13,8 +13,8 @@ dans le canal [\#canoeboot](https://web.libera.chat/#canoeboot) sur le serveur I
 
 <img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
 
-**NOUVELLE VERSION: La dernière version est [Canoeboot 20240510](news/canoeboot20240510.md), sortie
-le 10 May 2024.**
+**NOUVELLE VERSION: La dernière version est [Canoeboot 20240612](news/canoeboot20240612.md), sortie
+le 12 June 2024.**
 
 Pourquoi devriez-vous utiliser *Canoeboot*?
 -----------------------------------

site/index.it.md

@@ -14,8 +14,8 @@ su [Libera](https://libera.chat/).
 
 <img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
 
-**ULTIMO RILASCIO: L'ultimo rilascio e' Canoeboot 20240510, rilasciato il 10 May 2024.
-Vedi: [Canoeboot 20240510 annuncio di rilascio](news/canoeboot20240510.md).**
+**ULTIMO RILASCIO: L'ultimo rilascio e' Canoeboot 20240612, rilasciato il 12 June 2024.
+Vedi: [Canoeboot 20240612 annuncio di rilascio](news/canoeboot20240612.md).**
 
 Per quale ragione utilizzare *Canoeboot*?
 -----------------------------------------

site/index.md

@@ -15,9 +15,9 @@ on [Libera](https://libera.chat/) IRC.
 
 <img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
 
-**NEW RELEASE: The latest release is Canoeboot 20240510, released
-on 10 May 2024.
-See: [Canoeboot 20240510 release announcement](news/canoeboot20240510.md).**
+**NEW RELEASE: The latest release is Canoeboot 20240612, released
+on 12 June 2024.
+See: [Canoeboot 20240612 release announcement](news/canoeboot20240612.md).**
 
 Why should you use *Canoeboot*?
 ----------------------------

site/index.uk.md

@@ -15,8 +15,8 @@ x-toc-enable: true
 
 <img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
 
-**НОВИЙ ВИПУСК: Останній випуск Canoeboot 20240510, випущено 10 травень 2024.
-Дивіться: [Оголошення про випуск Canoeboot 20240510](news/canoeboot20240510.md).**
+**НОВИЙ ВИПУСК: Останній випуск Canoeboot 20240612, випущено 12 червень 2024.
+Дивіться: [Оголошення про випуск Canoeboot 20240612](news/canoeboot20240612.md).**
 
 Чому вам варто використовувати *Canoeboot*?
 ----------------------------

site/index.zh-cn.md

@@ -7,7 +7,7 @@ x-toc-enable: true
 
 <img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
 
-**新版发布: 最新版本 Canoeboot 20240510 已在 2024 年 05 月 10 日发布。详见: [Canoeboot 20240510 发布公告](news/canoeboot20240510.md).**
+**新版发布: 最新版本 Canoeboot 20240612 已在 2024 年 06 月 12 日发布。详见: [Canoeboot 20240612 发布公告](news/canoeboot20240612.md).**
 
 为什么要使用 *Canoeboot*?
 ----------------------------

site/news/MANIFEST

@@ -1,3 +1,6 @@
+canoeboot20240612.md
+audit1.md
+gnu.md
 canoeboot20240510.md
 canoeboot20240504.md
 canoeboot20231107.md

site/news/audit1.md

@@ -0,0 +1,849 @@
+% Canoeboot Build System Audit 1
+% Leah Rowe
+% 9 June 2024
+
+**A new release is now available, with these changes. Learn more by reading
+about the [Canoeboot 20240612 release](canoeboot20240612.md).**
+
+NOTE: This audit pertains to Canoeboot as of 9 June 2024 but the article is
+published on 12 June 2024; nonetheless, the article date is set to June 9th.
+For changes up to June 12th, please read the Canoeboot 20240612 announcement.
+
+Introduction
+============
+
+Canoeboot is a free/libre boot firmware project. It replaces your
+proprietary BIOS/UEFI firmware, on supported x86 and ARM computers. It does
+this by providing an automated build system to download, patch and compile
+the various upstream sources (e.g. coreboot, GRUB, SeaBIOS). Coreboot is used
+for hardware initialisation, configuring everything from your CPU, memory
+controller all way to peripherals, readying the hardware so that it can run
+software, e.g. GNU+Linux operating systems. You can essentially think of *cbmk*,
+which is Canoeboot's build system, as a *source-based package manager*. It is
+what the Canoeboot releases are built with. The *cbmk* build system essentially
+implements a *coreboot distro*, the same way you might think of a GNU+Linux
+distribution.
+
+Extensive auditing has been performed on cbmk, since the Canoeboot 20240504
+release. These audits fix bugs, reduce code bloat and generally improve the
+efficiency of cbmk, adding and removing features in a careful, conservative
+way, with a focus on *clean code*. Remember the magic words: code equals bugs.
+
+This article covers changes from Canoeboot 20240504, up to
+revision `4f6fbfde81f5176e5892d1c00627f8f680fd3780` from 9 June 2024.
+
+Some notes about this audit
+---------------------------
+
+This is the *first* official Canoeboot audit. The initial Canoeboot releases,
+from October/November 2023, incorporated changes from Libreboot Build System
+Audit 3, and Canoeboot 20240504/20240510 included changed from Libreboot Build
+System Audit 4, plus changes adapted from releases up to Libreboot 20240504 and
+a bit beyond; however, Canoeboot used to be synced with Libreboot per each
+Libreboot release - nowadays, it is synced *per commit* on both the build system
+and the documentation, plus other repositories.
+
+Therefore, whenever a Libreboot audit is announced, a corresponding Canoeboot
+audit will also be announced. To keep it clean, we will simply refer to this
+one as the *first* official Canoeboot Build System Audit, or *audit 1*.
+
+ALSO: Canoeboot 20240510 was released *during* the audit; this changelog is in
+reference to Canoeboot 20240504, *not* 20240510.
+
+Modest code size reduction
+--------------------------
+
+There are 1054 lines of shell script in the build system, versus 1208 in the
+Canoeboot 20240504 release. Canoeboot's build system is written purely in
+POSIX sh; not BASH, not KSH, not ZSH, jush sh!
+
+This is a difference of 154 lines, or a 13% reduction. Despite the reduction,
+numerous features have been added and a large number of bugs were fixed.
+
+Summarised list of changes
+==========================
+
+Changes are in order per category, from newest to oldest:
+
+Feature changes
+---------------
+
+* **Download crossgcc tarballs as dependencies, when cloning coreboot.** We
+  previously relied on the coreboot build system, which automatically fetches
+  these when running `make crossgcc`, which we run automatically. However,
+  the coreboot logic has to be patched for reliability because the GNU HTTP 302
+  redirect often fails so we use a static mirror, and the logic has no
+  redundancy. With this new change, we use the same tarballs but we specify
+  two URLs, a main and a backup. This also means that the tarballs will once
+  again be included in Canoeboot release archives, enabling offline builds.
+* **Support downloading files as submodules, in Git repositories.** This
+  complements the pre-existing feature where sub-repositories (Git) can be
+  cloned into a subdirectory of a given main repo. We use this for crossgcc,
+  as referenced above.
+* New files under `config/dependencies/` for Fedora 40 and Ubuntu 24.04. Now
+  you can run `./build dependencies fedora40`
+  and `./build dependencies ubuntu2404` on each respective distro, to get
+  the right build dependencies for building Canoeboot from cbmk.
+* **NEVER** run `git submodule update`, *ever*. Instead, rely *solely* on
+  config/submodule/ to define which dependencies should be downloaded, to each
+  given subdirectory within a main project. This is using a feature described
+  later on (in this audit report), whereby projects can have redundant
+  submodule repositories defined; initially, this feature was an *override*
+  where otherwise the submodule update command would be executed if
+  the `.gitmodules` file existed for a given project; this override is now
+  the *only* way to do it, and is thus the default behaviour. This may be
+  considered a preventative bug fix, in case certain projects auto-download
+  submodules that might cause us trouble in the future. It's better that we
+  maintain tight control of submodules.
+* **Summarising the next few changes mentioned below: out-of-source builds
+  are now fully supported, for both single- and multi-tree projects.** (it was
+  previously only supported on multi-tree projects)
+* Moved builds of coreboot utilities (e.g. cbfstool) to `elf/utilname`,
+  e.g. `elf/cbfstool/default/cbfstool` would be the new cbfstool binary location
+  for the one build from coreboot in the `default` tree.
+* script/trees: Now single-tree builds are skipped if a build exists
+  under `elf/projectname/`, based on the presence of a `build.list` file; this
+  is consistent with the same behaviour pre-existing for multi-tree projects.
+* When building memtest86plus, the binary is now placed out-of-source,
+  into `elf/memtest86plus`.
+* When building flashprog, the binary is now placed out-of-source,
+  into `elf/flashprog/`.
+* Use new function `singletree` to decide whether to use submodules, rather
+  than hardcoding a check for *coreboot* - NOTE: use of submodules was later
+  disabled during this audit, replaced with custom handling in cbmk.
+* For error exits caused by *improper commands* (as opposed to fault conditions
+  while processing valid commands), don't directly call `err`; instead, call a
+  newly written function `badcmd` which says that much, and links to the
+  website (if `docs/` is present as in releases, it also points there).
+* Added a `projectsite` file pointing to canoeboot.org, complementing the
+  existing `projectname` file which contains the word `canoeboot`. This is
+  used in the `version` command.
+* **GRUB is now a multi-tree project.** Each given coreboot target can
+  specify which GRUB tree it wants to use, each containing its own revision
+  and patches, with its own GRUB configuration file. This can be used later on
+  to provide specific optimisations on each given mainboard, but it is used
+  at present to exclude xHCI patches on boards that don't need it; please also
+  read the bugfix section (of this audit report) pertaining to this same topic,
+  for more context. Before this change was implemented, all mainboards used
+  the exact same GRUB revision, with the same patches and the same config.
+* grub.cfg: scan `grub2/` last, on each given device/partition; this speeds
+  up the boot time in most tests, because most setups use `grub/`,
+  but `grub2/` is still used on legacy setups so we have to support it and, for
+  reasons mentioned in the bullet point below, GRUB is very inefficient at
+  generating the list of devices/partitions when using the `*` wildcard, so
+  we can't scan `grub*/`.
+* grub.cfg: it now scans a reduced set of devices/partitions by default, while
+  still ensuring (in practise, on real systems) that all such devices and
+  partitions will be scanned. We hardcode this, because the `*` wildcard in
+  GRUB is *very slow* on some machines, due to the way the GRUB kernel
+  constantly re-initialises the list of devices and partitions during operation.
+  Scanning an *excessive* number of hardcoded device/partition numbers slows
+  down the boot too, so this has been optimised. It has been tested and it
+  shouldn't cause any issues on machines/setups that people actually use.
+* **grub.cfg: scan distro-provided grub.cfg from ESP;** we previously only
+  scanned the ESP for isolinux/syslinux configurations (which GRUB can parse).
+* grub.cfg: Don't search for `*_grub.cfg` as this slows down the bootup
+  sequence, and nobody really uses this anymore; Canoeboot's GRUB is much more
+  robust these days, pretty much booting anything automatically, but you used
+  to have to (regularly) use a `canoeboot_grub.cfg` file to override the default
+  one provided by your distro. This legacy cruft has been removed, entirely!
+* script/roms: Allow to override `grub_scan_disk` via `-s`, for
+  example: `./build roms -s nvme t1650_12mb`
+* **grub.cfg: Use `grub_scan_disk` to set boot order (rather, boot order by
+  device type).** It is possible now to configure each mainboard with this
+  variable, so that certain types of devices are scanned in a precise order;
+  for example, scan NVMe SSDs first.
+* **include/git.sh: Allow manual override of `git submodule` handling**, instead
+  directly downloading Git repositories using `git clone`, into the subdirectory
+  of a given main Git repository (as per `src/projectname` scheme). With this
+  feature, it is possible now to specify a *backup* submodule repository, for
+  redundancy, all while still allowing to reset the revision (and *patch* the
+  given submodule). This has been used to provide greater redundancy when
+  downloading coreboot submodules. It also allows to *limit* the number of
+  submodules, so now we only download the ones we need, thus saving bandwidth
+  especially during very large and long build sessions. - *NOTE: this was
+  later changed so as to be the ONLY method for downloading submodules, skipping
+  the actual git-submodule-update command entirely, on all projects.*
+* **Native NVMe driver added to the GRUB payload**, allowing users to boot from
+  NVMe SSDs where present on a given mainboard. The patch is courtesy of
+  Mate Kukri, who ported SeaBIOS's own NVMe driver, converting all of the
+  code to run properly within GRUB's own kernel. NVMe SSDs are now fully
+  bootable on all machines that can have them, offering vastly superior
+  read and write performance when compared to SATA SSDs.
+* include/git.sh: Allow patching git submodules (NOTE: support for submodules
+  was removed entirely, later in the audit, in favour of custom logic in cbmk
+  for the downloading of such dependencies).
+* Added Portuguese keyboard support in the GRUB payload (patch courtesy of
+  the contributor by alias `samuraikid`).
+* Removed all help commands, because it's just a duplication of documentation
+  that is already included in releases anyway, and people using the Git
+  repository require internet access anyway, so they can just use the website.
+* Main build script: removed the functionality for generating source tarballs
+  where the only source code included is U-Boot; we do not need this, because
+  the larger source tarball containing all of Canoeboot also contains U-Boot.
+* include/option.sh: Don't bother checking for GNU Tar, because we were only
+  using it for reproducible tarball generation which didn't work yet anyway;
+  there are still ways of doing it with BSD tar and so on.
+* Print a two-line break before confirming the location of the generated
+  release archive, when running release builds. This makes it more obvious
+  to the operator.
+* Removed all status checks from script/roms (formerly script/build/roms),
+  because it's better to document this instead, and rely on testing regardless.
+
+Bug fixes
+---------
+
+Some of these changes fix actual issues that were found in testing, while
+others were fixed *before* being triggered/reported and are thus *preventative
+bug fixes*. The logic in cbmk has been very intensively audited as is customary!
+
+The changes are, from newest to earliest:
+
+* script/trees: Exit with error status if a given project is not defined. It
+  was previously decided that this script could be used to directly run Makefiles
+  from any given directory, but this is no longer done as it was error-prone;
+  this change prevents such usage, thereby preventing unstable conditions within
+  the build system.
+* **Create a lock file when running cbmk.** Only do it from the main parent
+  instance, but not child instances of it; delete it at the end, after exiting
+  from the parent process. If starting a separate parent process, that one
+  will now immediately exit (with error status) if the lock file exists. This
+  prevents the fault condition where the user accidentally runs the same cbmk
+  instance twice, from the same work directory; it is only designed to be
+  executed once, per work directory. This is similar to the locking feature
+  you find in package managers such as apt-get. Also do this in release/
+  directories, while building (but don't include a lock file inside the tarball).
+* include/git.sh: When doing a global check for files in every project all at
+  once, as defined by each respective (if existent) `nuke.list` file, hide
+  the output. Only show the output when running it on a specific project, not
+  the one in the for loop. This prevents user confusion / false bug reports.
+* include/git.sh: Download coreboot as defined by `xtree` *before* downloading
+  the main project that defined it, to prevent a situation where the main project
+  is downloaded successfully but not the dependency (defined by `xtree`); this
+  is to maintain the integrity of the build system under fault conditions.
+* include/lib.sh: When a download fails (running the `download` function),
+  don't then say that the file is "missing". Instead, actually say that the
+  download failed, so that the operator has a better understanding.
+* include/lib.sh: Hide stderr on the `download` function, for the initial
+  check when verifying an existing file; although no problem existed on
+  technical terms, the output was confusing because it made the user think
+  there was a problem. The logic then downloads and re-verifies, and the
+  output indicating *that* verification has not been hidden; if the file
+  already exists, this is simply indicated by `e()`. This is considered a bug
+  fix, because it fixes the bug where users made erroneous bug reports, by
+  re-engineering the situation so that they do not make such erroneous reports.
+  TL;DR hide a totally benign (non-)error message.
+* include/git.sh: Provide better user feedback about what is being downloaded
+  and where - although nothing was broken before, this lack of feedback was a
+  bug because it made debugging harder. Provide more clarity for the user.
+* include/git.sh: Download dependencies *before*, not *after*, downloading the
+  project sources that depend on it. For example, pico-serprog depends on
+  pico-sdk. If you were to download pico-sdk *after* pico-serprog, the latter
+  may be downloaded and placed in src/, but then the former (sdk) could fail
+  due to bad internet, and now the overall downloaded code is corrupt, and there
+  was nothing checking for this after the fact; checking for it would be bloat.
+  By downloading the dependency *before*, then if *that* download fails, so
+  does the main one, and integrity is maintained within the build system.
+* Preventative bugfix: don't check empty paths in `copy_elf` (of script/trees),
+  even though this potential bug was not yet triggered. Play it safe.
+* script/trees: Don't check pre-existing builds in elf/ if `build.list` is
+  missing, otherwise it's too soon and builds are prevented in the first place;
+  this was caused initially when supporting out-of-source builds for single-tree
+  projects, as was already done on multi-tree. Now this is fixed.
+* Documentation: only define the Untitled Static Site Generator
+  in `config/git` - the dependencies (markdown files and images) are now
+  defined in config/submodules/ instead. This prevents the bug where you could
+  download one of the dependencies first which would make the main project,
+  Untitled, un-downloadable, since the dependency projects go in subdirectories
+  of the main project that depends on them.
+* Handle serprog dependencies in config/submodule instead of relying on
+  the git submodule update command, and only provide necessary modules. This
+  prevents the bug where downloading a dependency first later prevented the
+  main project from being downloaded, if the dependency was in a subdirectory
+  of what depends on it.
+* Build coreboot utilities on a number of threads as defined by `XBMK_THREADS`;
+  although they already compiled, they would always do so on a single thread,
+  which is considered a bug. Now they can be compiled on multiple threads.
+* include/lib.sh: Don't use `./update trees -f` to build coreboot *utilities*,
+  because it's quite error prone and not what that script is designed to do;
+  it is only designed to operate based on strictly defined single- and
+  multi-tree projects. Instead, call `make` directly.
+* Don't use the presence of a `build.list` file to detect a multi-tree project
+  when running `./update trees`; instead, check the presence of `target.cfg`
+  down one level from `config/project/`, so: `config/project/*/target.cfg`
+  instead of `config/project/target.cfg`. This way, if someone working on cbmk
+  accidentally adds that `build.list` file in the wrong place, cbmk won't
+  become unusable. This also means that single-tree projects can now provide
+  a `build.list` file! (and some of them now do - look at the features section
+  on this page)
+* Move check for *root user* to include/lib.sh, *before* the version/versiondate
+  files are written; these files need to be writeable by the standard user,
+  otherwise cbmk will exit. If you run cbmk as root, except when running the
+  dependencies command, it exits with error status; ironically, that very same
+  check then prevented running as root-root, causing cbmk to become unusable
+  until those files were either deleted or had ownership changed. This fix
+  prevents the bug from occuring ever again, but people who were previously
+  affected still have to fix these files (if they were written as root).
+* Move dependency handling to include/lib.sh, *before* the version/versiondate
+  files are written, and *exit* before they are written; this prevents writing
+  the version/versiondate files as root, which previously occured when running
+  a command such as `./build dependencies debian` (installs build dependencies
+  from apt-get on a Debian machine). This bug ironically prevented cbmk from
+  running at all, under such conditions, because the dependencies script
+  required root, but cbmk exits with error status if running anything else as
+  root, and if version/versiondate are owned by root, that prevents cbmk from
+  running because writing to these files is the first thing it does, so an exit
+  with error status would otherwise occur.
+* config/git/: Bump to a newer revision of Untitled (static site generator),
+  which thereby also imports the same fix as described in the next bullet
+  point below, because Untitled had (and now no longer has) the exact same bug.
+* include/lib.sh: check environmental variables properly, for example
+  check that `${XBMK_RELEASE+x}` isn't unset; it was previously grepping
+  the output of `set`, which led to a bug report by a user who had the
+  variable `TMUX_TMPDIR` set, whereas `TMPDIR` was unset and cbmk was checking
+  the latter; in this example, the bug caused cbmk to act as though `TMPDIR`
+  was set, when it in fact wasn't, and code that used it then crashed because
+  cbmk does `set -u -e` (and it does this precisely to catch such bugs like the
+  one you're reading about now so that they can be fixed, like this one was!)
+* **Re-configured GRUB so that none of the currently supported machines contain
+  xHCI support**. This is a mitigation against the bug reported in [lbmk
+  issue 216](https://codeberg.org/libreboot/lbmk/issues/216). This is done, by
+  using the new *multi-tree* GRUB handling, which is mentioned above in
+  in the section (of this audit report) pertaining to *feature changes*, whereby
+  each mainboard can have its own GRUB revisions and patches, with its own
+  GRUB configuration file (that could be uniquely optimised for it).
+  We do not need xHCI patches on any Canoeboot machines, but the patches are
+  free software regardless, and it's important to keep Canoeboot in sync with
+  Libreboot. It may be that you want to enable it on a custom configuration,
+  for example if you use a USB3 card on a KGPE-D16, but it is not currently
+  enabled by default on any Canoeboot machines.
+* **Fix vboot build issue when running cbmk in i686 (32-bit) host machines**.
+  The patch, courtesy of *Luke T. Schumaker*, adapts vboot's vmlinuz extract
+  function so that it uses pointer logic directly, instead of defining
+  integers (of type `ssize_t`) which, the way it was written, caused GCC to
+  believe that there would be a buffer overflow in code; the new code is more
+  robust and should prevent such an issue. This is both an *acute* bug fix,
+  fixing a bug that was actually triggered, and a preventative bug fix as the
+  original code wasn't correct either, even on AMD64 hosts (where it happened
+  to compile anyway).
+* **GRUB: Never run it as a primary payload on any target but QEMU**. This is
+  a preventative bug fix, after lbmk bug report issue 216:
+  <https://codeberg.org/libreboot/lbmk/issues/216> - although it was caused by
+  the xHCI patches, and only happened on Sandybridge hardware, and although
+  this was later removed on those boards, GRUB is very complex and likely has
+  a lot of memory corruption issues. SeaBIOS is more reliable, so: Canoeboot
+  only provides *SeaBIOS* as primary payload, but allows you to execute GRUB
+  from the SeaBIOS menu (the very same GRUB). Additionally: cbmk already
+  supported a configuration whereby SeaBIOS reads a `bootorder` file in CBFS,
+  making it try to run the GRUB payload first, while still allowing you to
+  interrupt by pressing ESC to bring up an alternative boot select menu. This
+  is now the *default*, on all x86 mainboards. This is a mitigation against
+  future instability in GRUB because, if such issues happen again, it will not
+  cause a brick since you can just use SeaBIOS instead, and skip booting to
+  the GRUB payload (on the affected machines, BIOS GRUB still worked, which
+  your distro provides and SeaBIOS executes it). *NOTE: GRUB was later made
+  into a multi-tree project, with certain mainboards using a version that
+  has the xHCI patches, if required, because the machines that actually need
+  xHCI support were not affected by the bug referenced in issue 216.*
+* Main build script: Check SUID before checking Git name/email, otherwise the
+  version/versiondate files could be written as root and thus prevent building
+  of cbmk, which (for most commands) is intentionally engineered to exit (with
+  error status) if you run it as root.
+* script/trees: Reset variable `makeargs` per target, so as to prevent
+  pollution of this variable when switching from one build target to the next.
+* script/trees: Added `UPDATED_SUBMODULES=1` to the make command when running
+  any coreboot `make` command, to prevent coreboot from automatically fetching
+  certain Git submodules; this is a preventative fix, fixed before it became
+  a bug, which it likely would have become at some point as this is exactly
+  what the coreboot build system does!
+* Main build script: hide the output of `git init` when cbmk re-initialises the
+  Git history, to prevent its output from being wrongly inserted into the
+  output of commands such as `./build roms list` - such pollution would cause
+  build errors, so it's important that the Git initialisation function either
+  doesn't output anything, or that it should cause an *exit* if output is to be
+  required.
+* Added the `CHANGELOG` file to `.gitignore`. This means `./update release`
+  will now work, on release archives, because cbmk re-initialises Git history
+  when doing so, but the CHANGELOG file (when present) causes cbmk to skip
+  all source downloads (which the release builder relies on).
+* **Fix garbled output on 1440x900 monitors when using the Dell Latitude E6400.**
+  The E6400 uses a reference clock (`DPLL_REF_SSCLK`) set to 100MHz, whereas
+  libgfxinit assumed 96MHz. This timing descrepancy did not cause an issue on
+  lower resolution displays, so we never caught it in earlier testing. Patch
+  courtesy of Nicholas Chin, who debugged this issue alongside the user who
+  reported it. It was fixed by making such timing configurable, within the
+  coreboot build system, setting it to 100MHz on Dell Latitude E6400.
+* script/roms: Skip a target when its config directory is missing, so that
+  running a coreboot target with no configs in it will not yield an error;
+  instead, it will now cause a non-error return.
+* include/option.sh: If `.git` is missing, in a bare copy of cbmk (not a
+  release archive), recreate the version/versiondate files manually so as to
+  prevent a build error. Use of `cbmk.git` or the release archives is
+  recommended, but some users directly download snapshots of `cbmk.git` from
+  sites such as Codeberg, and there's no way for us to turn off this feature;
+  even if we did, it may be present on other Git hosting sites, where users
+  might host their own copy of cbmk.
+* include/option.sh: Don't return non-zero status from the function
+  named `mkrom_tarball`, because certain other functions rely on its return
+  value to always be *zero*; instead, call `err` which will then yield
+  an *exit* (with non-zero status). This means that the function will now
+  always *return* zero, when it returns.
+* include/git.sh: Remove `.git` directories *per-project*, as and when each
+  project is being downloaded, instead of having it done all in bulk by the
+  main build script. This kicks in when `XBMK_RELEASE` is set (release builds),
+  to correct the over-use of disk space during such very large builds processes.
+  This makes the build system less likely to OOM when running it inside tmpfs.
+* Main build script: initialise Git history *before* running any command,
+  because this is required for reliable use of the coreboot build system, which
+  the *inject* command makes heavy use of. This reduces the number of errors,
+  when running these commands from a release archive, where cbmk re-initialises
+  a new Git history when you run it for the first time.
+* Main build script: define `xp` as a global variable, to prevent it from
+  being lost between functions.
+* script/roms: Create full release tarball name, when generating releases.
+* Main build script: exit (with error status) if not running directly from
+  the root of the cbmk work directory.
+
+General code cleanup
+--------------------
+
+In addition to *general* very sweeping code cleanup, condensing code lines
+where possible and so on:
+
+* include/lib.sh: Simplified the `download` function (used for crossgcc tarballs).
+* include/lib.sh: Simplified the `singletree` function.
+* include/git.sh: Simplified the `link_crossgcc` function.
+* include/git.sh: Simplified the `nuke` function, because it was over-engineered
+  to the extreme. Now it's more reasonable.
+* include/lib.sh: Move download logic here from lbmk as of audit 5, for the
+  feature where *files* can be downloaded as submodules, within Git repositories.
+  Please read the notes about this in the *features* section.
+* include/lib.sh: Shortened a string in the `e` function, so that the line
+  does not exceed a length of 80 characters.
+* include/git.sh: Unified the handling of git clone/reset/am commands into a
+  single function, rather than duplicating the same logic across multiple
+  functions.
+* script/trees: simplify the `copy_elf` function; don't create the elf directory,
+  create one defined by `dest_dir` instead (which is the elf directory with
+  the subdirectory for that project concatenated). Only create it within
+  the `copy_elf` function, which is only called if actually compiling the
+  code. This avoids creating empty directories under elf/, for example under
+  fault conditions.
+* include/git.sh: Additional code cleanup, removing certain code that was in
+  place because the code used to handle both `git submodule update` and the
+  custom *override* logic for submodules; now only the override is used, at all
+  times, so the code was cleaned up and optimised only for this.
+* include/git.sh: Reduced code indentation in function `fetch_submodule`.
+* include/git.sh: Renamed a few variables for increased code clarity.
+* script/trees: Unified handling of coreboot `makeargs`.
+* Moved function `handle_coreboot_utils` to script/trees (and renamed it
+  to `check_coreboot_utils`), as it's only ever used from there.
+* Moved cfgsdir/datadir variables to include/lib.sh, because it's also used
+  from script/roms and script/trees; unify them under a common location.
+* Handle `build.list` from config/data/, not config/ - this avoids needing to
+  check for `build.list` in the `items` function on include/lib.sh, and it is
+  now avoided.
+* include/lib.sh: More user-friendly output from the `e` function, telling the
+  user whether or not a file/directory exists. This is regularly used, for
+  example when trying to download a project and the source code was already
+  prepared.
+* U-Boot on QEMU: removed the (currently) unused x86 target.
+* grub.cfg: Split function `try_user_config` into multiple smaller functions.
+* grub.cfg: Don't scan ESP on btrfs subvols as the ESP is always on a FAT32
+  partition. This saves time during the bootup sequence.
+* Renamed include/option.sh to include/lib.sh
+* Main build script: simplified the logic for Git repository initialisation
+  by *returning non-zero status*, instead of calling err, and handling this
+  return status in the calling function.
+* Main build script: condensed the logic for Git name/email checking into a
+  simply for loop running `eval`, rather than having lots of separate but very
+  similar Git commands.
+* script/trees: Removed a few unused variables.
+* include/git.sh: Moved logic for copying a Git repository to a new function.
+* include/git.sh: Moved function `link_crossgcc` to a different location
+  within the file, for proper top-down order of logic (required as per the
+  cbmk coding style).
+* include/git.sh: Split logic for crossgcc symlinking into its own function.
+* include/git.sh: Skip submodule checks if `.gitmodules` missing (NOTE: later
+  replaced with custom submodule handling in cbmk).
+* include/git.sh: Merged `patch_submodules` in `prep_submodules` (NOTE: ditto
+  to the same note below).
+* include/git.sh: Split up submodule handling into a new function (NOTE: support
+  for submodules was later replaced with custom logic in cbmk).
+* include/git.sh: Shortened a few variable names.
+* include/git.sh: Removed redundant check for the existence of the patches
+  directory, when patching a given project. This is unnecessary, where it was
+  removed, because the patching function itself also checks this. Reduction
+  in code size by *one line*.
+* include/git.sh: Removed function `fetch_from_upstream` and merged its logic
+  into calling function `fetch_project_trees`, the only calling function, since
+  the logic in `fetch_from_upstream` was very small and splitting made no sense.
+* include/option.sh: Renamed `mktar_release` to `mkrom_tarball`.
+* script/roms: Renamed function `moverom` to `copyrom`, because it runs `cp`,
+  not `mv`, therefore is is *copying* a file, not moving it.
+* script/roms: Simplified the logic for listing available serprog build targets.
+* script/roms: General simplification of configuration handling for payloads.
+* Main build script: removed the `excmd` function and merged its logic into
+  the `main` function, and then `main` was cleaned up significantly.
+* Main build script: don't make `script_path` a global variable; this allowed
+  a reduction in code size by precisely *one line of code*.
+* Main build script: merged the functionality of function `check_git` into
+  the `main` function, then deleted function `check_git` (which was in
+  the file include/option.sh).
+* Main build script: general simplification of the logic handling source code
+  downloads in function `fetch_trees`.
+* Main build script: Use `UTC+0000` when initialising git repository commit
+  dates (for initial commits).
+* Removed the `check_project` function, and placed its logic directly
+  inside `include/option.sh` so that it automatically runs in every script
+  that sources it.
+* Main build script: General cleanup on the code handling file deletions
+  under function `fetch_trees`.
+* Main build script: delete function `mkversion` and, in its calling function,
+  simply print the string contained in variable `relname`.
+* Main build script: general cleanup on the logic that handles tarballs.
+* Main build script: Remove `mkrom_images`, and move its logic into the only
+  calling function within that same file.
+* include/option.sh: Removed the function `insert_version_files` and merged
+  its logic into its only calling function.
+* Unified all logic for handling SHA512 checksums, placing it inside
+  include/option.sh for use elsewhere.
+* Move image tarball generation to script/roms (formerly script/build/roms).
+* Removed redundant function `extract_ref` from include/mrc.sh
+* Removed an errant comment from include/git.sh
+* Switched to a one-level directory structure for main scripts, rather than
+  two-level; for example, script/build/roms is now script/roms
+* Merged script/update/release into the main build script
+* Merged script/build/serprog into script/build/roms
+* script/build/roms: remove unnecessary command (errant return)
+* Merged include/err.sh with include/option.sh, into include/option.sh
+* script/build/roms: fixed improper use of variable outside a function
+* build/build/roms: more reliable exit status in `skip_board()`
+* script/build/roms: split up `main()` into multiple smaller functions
+
+Revision updates
+================
+
+Some revisions were updated as part of standard routine, but happened to be
+done during this audit. Those updates are as follows:
+
+SeaBIOS
+-------
+
+Bump SeaBIOS to revision `e5f2e4c69643bc3cd385306a9e5d29e11578148c`, which has
+these changes relative to the old one:
+
+```
+* e5f2e4c6 pciinit: don't misalign large BARs
+* 731c88d5 stdvgaio: Only read/write one color palette entry at a time
+* c5a361c0 stdvga: Add stdvga_set_vertical_size() helper function
+* 22c91412 stdvga: Rename stdvga_get_vde() to stdvga_get_vertical_size()
+* 549463db stdvga: Rename stdvga_set_scan_lines() to stdvga_set_character_height()
+* c67914ac stdvga: Rename stdvga_set_text_block_specifier() to stdvga_set_font_location()
+* aa94925d stdvga: Rework stdvga palette index paging interface functions
+* 8de51a5a stdvga: Rename stdvga_toggle_intensity() to stdvga_set_palette_blinking()
+* 96c7781f stdvga: Add comments to interface functions in stdvga.c
+* 2996819f stdvga: Rename CGA palette functions
+* 91368088 stdvgamodes: Improve naming of dac palette tables
+* 70f43981 stdvgamodes: No need to store pelmask in vga_modes[]
+* 1588fd14 vgasrc: Rename vgahw_get_linesize() to vgahw_minimum_linelength()
+* d73e18bb vgasrc: Use curmode_g instead of vmode_g when mode is the current video mode
+* 192e23b7 vbe: implement function 09h (get/set palette data)
+* 3722c21d vgasrc: round up save/restore size
+* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info
+* 163fd9f0 fix smbios blob length overflow
+* 82faf1d5 Add LBA 64bit support for reads beyond 2TB.
+* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code
+* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes
+* a6ed6b70 limit address space used for pci devices.
+```
+
+Flashprog
+---------
+
+Updated to revision 5b4fdd1 from 2 May 2024, rebasing the MX workaround patch.
+
+This imports upstream changes, relative to the previous revision:
+
+```
+* 5b4fdd1 z60_flashprog.rules: Add udev rule for CH347
+* 72c9e40 meson: Check for CPU families with known raw mem access
+* 3458220 platform/meson: Port pciutils/pci.h workaround to Meson
+* f279762 platform/meson: Check for libi386 on NetBSD
+* 14da5f7 README: Convert to Markdown
+* 8ddea57 README: Document branching and release policy
+* 2522456 util/list_yet_unsupported_chips.sh: Fix path
+* cbf9c11 spi: Don't cross 16MiB boundaries with long writes
+* 823a704 dediprog: Skip warning on first attempt to read device string
+* e8463c8 dediprog: Revise prefix check for given programmer id
+* 38af1a1 dediprog: Revise id matching
+* 4661e7c amd_spi100: Use flashprog_read_chunked() for progress reporting
+* cdcfda2 read_memmapped: Use flashprog_read_chunked() for progress reporting
+* 7679b5c spi25: Replace spi_read_chunked() with more abstract version
+* ca1c7fd spi25: Normalize parameters of spi_nbyte_read()
+* e36e3dc dediprog: Use default_spi_write_256
+* 522a86d linux_spi: Use default_spi_read()/_write_256()
+* 806509b cli_classic: Turn progress reporting into a progress bar
+* 842d678 libflashrom: Return progress state to the library user
+* aa714dd flashprog.c: Let select_erase_functions() return byte count
+* 2eed4cf serprog: Add SPI Mode and CS Mode commands
+* 821a085 dediprog: Implement id reading for SF600 and later
+* 274e655 dediprog: Read device string early
+* 0057822 dediprog: Add protocol detection for SF700 & SF600Plus-G2
+* fb176d2 dediprog: Use more general 4BA write mode for newer protocols
+* 0ab5c3d dediprog: Split device type and version parsing
+* bdef5c2 dediprog: Use unsigned conversions to parse device string
+* 5262e29 dediprog: Try to request 32B device string (instead of 16B)
+* e76e21f dediprog: Get rid of some unnecessary hex constants
+* 5a09d1e udelay: Lower the sleep vs delay threshold
+* 03ad4a4 linux_mtd: Provide no-op delay implementation
+* 211c6ec serprog: Refine flushing before synchronization
+* 383b7fe serprog: Test synchronicity before trying to synchronize
+* d7318ea serprog: Move synchronicity test into separate function
+* 9a11cbf Let the flash context directly point to the used master
+* aabb3e0 writeprotect: Hook wp functions into the chip driver
+* 89569d6 memory_mapped: Reduce `decode_sizes` to a single `max_rom_decode`
+* 929d2e1 internal: Pass programmer context down into chipset enables
+* 7c717c3 internal: Pass programmer context down into board enables
+* e3a2688 Pass programmer context to programmer->init()
+* 2b66ad9 Start implementing struct flashprog_programmer
+* 4517e92 memory_bus: Drop stale `size == 0` workaround and FIXME
+* b197402 memory_bus: Split register mapping into own function
+* 0e76d99 memory_bus: Move (un)map_flash_region into par master
+* 9eec407 Perform default mapping only for respective chips
+* 56b53dd wbsio_spi: Request memory mapping locally
+* 5596190 it87spi: Request memory mapping locally
+* 46449b4 spi25: Drop stale `bus == SPI` guards
+* ab6b18f spi25: Move 4BA preparations into spi_prepare_4ba() hook
+* 901fb95 Add prepare/finish_access() hooks for chip drivers
+* a96aaa3 dediprog: Support long writes of 16MiB and more
+* 1338936 Consider 4BA support when filtering erase functions
+* 8d36db6 flashprog.8: Fix up serprog example
+* d2ac303 flashprog.8: document new serprog cs parameter
+* d1b9153 chipset_enable.c: Add Genoa to mendocino entry
+```
+
+As a reminder:
+
+Canoeboot now uses Flashprog instead of Flashrom; Flashprog is a fork of
+Flashrom, lead by Nico Huber after a dispute with the new leadership of
+Flashrom, and it was felt that Flashprog is a better choice for Canoeboot.
+
+Git log
+=======
+
+This entire set of changelogs is based on the precise Git history in cbmk,
+relative to Canoeboot 20240504 which is from where the audit began.
+
+The latest changes are listed first, going all the way down to earlier changes:
+
+```
+* 4f6fbfde81 minor code cleanup in the build system 
+* 070aee6728 re-add ability to use cbfs grub.cfg as default 
+* b4acd0f73c trees: exit with error if project undefined 
+* fd9664c567 build: also make a lock file during release build 
+* 686bad6d4e lib.sh: more useful lock message 
+* f1caf89a28 create a lock file during builds 
+* b6dc23bc67 git.sh: hide e() output on for loop 
+* e51eae0d25 lib.sh: fix regression 
+* 8b1a54d19e git.sh: download xtree *before*, not after 
+* 14bba2d789 git.sh: fix deletion path in nuke() 
+* ab4c4d406f lib.sh: less confusing error in download() 
+* 2eaaa63f58 lib.sh: hide stderr on download() 
+* 9e2584fbd9 lib.sh: simplify download() 
+* 79fb79d239 lib.sh: fix redundancy in download() 
+* e8b1d45631 lib.sh: simplify singletree() 
+* 90a8ef90b0 git.sh: further simplify nuke() 
+* c6b692208b git.sh: simplify link_crossgcc() 
+* c043e5810d git.sh: simplify nuke() 
+* 323a17d0c8 Add dependency scripts for Fedora 40 and Ubuntu 24.04 
+* 62b2310a28 add crossgcc tarballs to config/submodules/ 
+* 8a34a0d338 git.sh: support downloading *files* as submodules 
+* 0730513709 git.sh: remove unnecessary line break 
+* ad05266f8d import file download function from lbmk c202dc61 
+* b8e9eab0ba lib.sh: shorten a string in e() 
+* a29cf274bc git.sh: fix submodule path 
+* 7ac2264f53 git.sh: simplify prep_submodules() 
+* 7c8173ebd4 git.sh: unified handling of git clone/reset/am 
+* 573199c07d trees: simplified copy_elf() handling 
+* d0d9b1204f git.sh: simplify submodule handling 
+* df5d7c18bf git.sh: provide feedback for repository downloads 
+* 591c7d28e0 git.sh: download "depend" projects *before* 
+* 548d1e20c1 git.sh: reduced indentation in fetch_submodule 
+* 12a04e8de2 git.sh: reduced indentation in prep_submodules 
+* 9825e97a83 git.sh: *never* run git submodule update 
+* 860deb3e7e lib.sh: rename variable for clarity 
+* 8d5edd4f06 trees: don't check empty path in copy_elf() 
+* c1176bbd28 trees: fix build issue caused by bad elf check 
+* c88fb8c129 trees: fix listfile check in copy_elf() 
+* 9168d33741 trees: don't say check elf/ if build.list missing 
+* db09530905 trees: don't do elfcheck if build.list missing 
+* 99418a7e82 define mdfiles/images in config/submodules/docs/ 
+* 83d84797d8 libopencm3 to config/submodules/ on stm32-vserprog 
+* c3cabcddf9 add tinyusb to config/submodule/ for pico-sdk 
+* e4eb82e089 trees: unified coreboot makeargs 
+* f7170092c8 trees: use multiple threads to build cbutils 
+* 1d7a6f04c9 move handle_coreboot_utils to script/trees 
+* ff16d27991 put coreboot utils in elf/, not cbutils/ 
+* 3748f710c9 fix build issue building coreboot utils 
+* a30bfd334f trees: skip single-tree build if a build exists 
+* b682b4ddca use correct memtest86plus path in script/roms 
+* 4749a5a29f put memtest86plus builds in elf/memtest86plus/ 
+* 0e9d9b33b2 put flashprog builds in elf/flashprog/ 
+* 7fe0106fa0 trees: also print "DONE! check elf/dir" on single 
+* 74759d876a trees: handle build-test on multi-tree projects 
+* 98e9cf6864 git.sh: use singletree() to decide submodules 
+* b3b887567a remove cbcfgsdir variable (unused) 
+* cb446e7d24 move cfgsdir/datadir variables to lib.sh 
+* 7d99786a1a handle build.list from config/data/, not config/ 
+* a61794dfca don't use build.list to detect multi-tree projects 
+* 878056f37b move id check to lib.sh too 
+* 3900642471 move root check to lib.sh (bugfix) 
+* 740b1803fa bugfix: move dependencies handling to lib.sh 
+* 4e25e335ed bump untitled revision again 
+* 44ef38b335 bump untitled revision in git config 
+* 7b9431e336 lib.sh bugfix: check environmental variables right 
+* 2478252f67 lib.sh: more friendly output from e() 
+* d21fd016ac badcmd: don't print "no context given" 
+* 663de3bab4 badcmd: link directly to the maintenance manual 
+* 1d866d17d8 better help text on invalid commands 
+* 1204bc3c96 build: print the project website address on help 
+* ca0e9354f6 add projectsite file: point to canoeboot.org 
+* eb4ac3c334 make GRUB multi-tree and re-add xhci patches 
+* 347a104ae6 u-boot on qemu: remove currently unused x86 target 
+* 23e66c113d grub.cfg: scan /boot/grub.cfg last 
+* 6151316b91 grub.cfg: scan grub2/ last 
+* 36b3be95cf grub.cfg: search a reduced list of devs/partitions 
+* 71a17efc06 grub.cfg: scan grub.cfg from ESP 
+* 8bc7e3a539 grub.cfg: split up try_user_config 
+* cb4bacc9d9 grub.cfg: don't search for *_grub.cfg 
+* ea7e6e1659 grub.cfg: remove unnecessary path for isolinux 
+* 1beca3b781 grub.cfg: don't scan EFI on btrfs subvols 
+* 0662519cca Fix building vboot on i686 
+* 224dce632b git.sh: do not remove .submodules 
+* a36504aa31 delete u-boot test/lib/strlcat.c using nuke() 
+* cdce8ba70b make nuke function more generic 
+* 2c1f6f5e7a do not allow dashes in coreboot target names 
+* 7dc5d35929 roms: allow user override of grub_scan_disk 
+* bcb65846d3 grub.cfg: actually support setting boot order 
+* 2887b77ae4 trees: use CPUS=x on regular coreboot make 
+* a056583762 update gitignore 
+* 1ac4f7409e roms: fix bad eval when comparing options 
+* 724dbfe0ce grub.cfg: add spdx header 
+* 66f5faac73 re-configure grub_scan_disk on various targets 
+* bb92776943 remove grub_scan_disk in all target.cfg files 
+* 935447b035 grub.cfg: use grub_scan_disk to set boot order 
+* 75b6fbf302 GRUB: remove XHCI patches for now (will re-add) 
+* 07340d9711 minor correction 
+* 9f489b43d5 roms: make grubfirst if seabios_withgrub=y 
+* fca9b19e18 coreboot: only run GRUB as a secondary payload 
+* b75490f8fc flashprog: bump to 5b4fdd1 from 2 May 2024 
+* d147c5d915 rename include/option.sh to include/lib.sh 
+* f534b0e973 merge nuke() back into git.sh 
+* a02b152f44 rename nukeblobs to a more generic name 
+* cb1918c5d7 roms: remove errant reference 
+* 4cff3c7d33 roms: rename bstr variable 
+* dc487df12f git.sh: remove errant whitespace 
+* cbb2f4f8a9 general code cleanup in the build system 
+* 583135e548 build: simplify git_init() 
+* aaff90f5a5 build: do root check before git check 
+* 687fdacc78 build: simplify git checks 
+* 84ee6a1ed8 option.sh: fix bad check for version/versiondate 
+* 3554593fd8 trees: reset makeargs per target/project 
+* b09261a901 trees: also use UPDATED_SUBMODULES=1 on crossgcc 
+* 698548ac59 trees: add UPDATED_SUBMODULES to coreboot make 
+* c8c516703f trees: write -C on the make command first not last 
+* aa15eef32f config: add backup coreboot submodule repositories 
+* 9e88ef2449 coreboot/default: remove chromeec from module.list 
+* 27f21c32d3 git.sh: break if a submodule clone succeeds 
+* 38fca598fb coreboot: only download the necessary submodules 
+* b5aa8b2d35 git.sh: allow finer control of git submodules 
+* 9339c6f3fd build: hide git-init output 
+* 31e089aff3 option.sh: generate version file if .git not found 
+* 7ec023907b update/trees: remove unused variable 
+* 2b0e71412e git.sh: move repo copying to a new function 
+* d71c4d326e git.sh: move link_crossgcc to end of file 
+* 0d7c249c9b move deblob function to new file "deblob.sh" 
+* 1300f09e67 git.sh: move xgcc linking to a new function 
+* 24934e6569 git.sh: don't include --checkout in submodules 
+* 5e0129eb0f git.sh: skip submodules if .gitmodules missing 
+* 7f82622caf git.sh: merge patch_submodules in prep_submodules 
+* 9c0a7f14fc git.sh: split submodule handling to new function 
+* b593127795 git.sh: remove errant line break 
+* 19f694bf2a git.sh: remove another meaningless check 
+* 71a9fcced8 git.sh: shorter variable names 
+* 6693588857 git.sh: remove meaningless check 
+* 5c459ad4ac git.sh: remove variable not meaningfully used 
+* 7be7bb8edb add CHANGELOG to .gitignore 
+* 3b2ebda890 Fix E6400 display reference clock patches 
+* 995f052bb0 fix building coreboot images on i686 hosts 
+* 31d2c818eb Also try unlocking encrypted volume on NVMe 
+* 58f6741fb4 git.sh: fix invalid command in git_prep() 
+* f58b01c300 Add NVMe support to GRUB2 payload 
+* b892036edf Fix E6400 display issue with 1440 x 900 panel 
+* f81c7ed8e9 Add pt qwerty keymap to lbmk 
+* 849466c0ac git.sh: allow patching submodules 
+* 8d4d063ace git.sh: don't delete .git if src/project/project 
+* 0ecb062df0 build/roms: skip target if config/ dir missing 
+* 4783c5b90e more minor cleanup in the build system 
+* 10ecf41ee0 git.sh: remove fetch_from_upstream() 
+* ddcb793bd2 option.sh: don't return 1 in mkrom_tarball 
+* ae8637b620 option.sh: mktar_release to mkrom_tarball 
+* 309c3b1f33 build/roms: rename moverom to copyrom 
+* a39c95cfac minor code cleanup in the build system 
+* f102e21ab6 build/roms: simplify serprog list command 
+* 7a565c9f43 build/roms: simplified config payload checks 
+* a243dc2308 option.sh: err if config directory is missing 
+* c28166ff9e option.sh: print the config filename being checked 
+* 9fd504e24a git.sh: Remove .git if XBMK_RELEASE=y 
+* e4956478db build: remove initcmd() and simplify main() 
+* f2b3bb142d build: initialise git first (before commands) 
+* 571932d33e build: remove excmd() and simplify main() 
+* 525f5525d3 build: don't make script_path a global variable 
+* fbac2d8fe6 Implemented failsafe options at boot and inside menus for enabling/disabling serial, spkmodem and gfxterm 
+* 3e5db248dd cbmk: allow easier sync with lbmk 
+* e71189420f remove help commands (user should read docs) 
+* 23854de888 option.sh: delete check_git() 
+* 2c5f52ce29 build: define "xp" in the global variables 
+* 48c5c57cff build: simplify for loop in fetch_trees() 
+* c2baebc79a build: simplified downloads in fetch_trees() 
+* 18d0e53480 ./build release: don't do u-boot-only archives 
+* d8a923f766 build: use utc+0 when initialising git repo dates 
+* 0794127986 remove check_project() (always set variables) 
+* c8bc797f31 build: simplify deletions in fetch_trees() 
+* 363ec7512c build: delete mkversion() (just print relname) 
+* ae44676727 build/roms: clean up tarball handling 
+* 3469836f18 rm src/u-boot/*/test/lib/strlcat.c in u-boot 
+* c57dfefe91 build: remove mkrom_images 
+* 6ab8c2c446 build: use same tarball name on uboot-only release 
+* 21436c6a8f build/roms: create full release tarball name 
+* 90c528032b option.sh: don't bother checking for GNU tar 
+* 422d36a07c option.sh: remove insert_version_files() 
+* ca1806f20e cleanup: remove mkvdir 
+* a0ea7f7a92 unified sha512sum creation for tarballs 
+* 09fcc343a3 move rom tarball creation to script/roms 
+* 5c888669c6 disable x301 for next release (for now) 
+* 91c90d763f print two line breaks before confirming release 
+* d423421995 remove all status checks. only handle release. 
+* 4826364afb git.sh: remove errant comment 
+* 541430016f move script/*/* to script/ 
+* 9084ab15ab build: print usage for special commands 
+* f12c2f284f merge script/update/release into build 
+* 41f4ee3c2d Canoeboot 20240510 release 
+* 0580373ff9 bump seabios to e5f2e4c69643bc3cd385306a9e5d29e11578148c 
+* 17b5cb2749 further modify the README (stragglers) 
+* 628e91a3b9 build: further prevent non-cbmk-work-directory 
+* e761a494c8 build: exit if not running from cbmk directory 
+* eb8a02e808 build/roms: print serprog help 
+* a398011180 merge script/build/serprog with script/build/roms 
+* cd5c2573ac build/roms: remove unnecessary command 
+* da748de455 merge include/err.sh with include/option.sh 
+* 3acac46536 err.sh: correct copyright info 
+* 6bdbb70dbc build/roms: don't rely on x in handle_target 
+* 1c84d0fc9d build/roms: don't use exit status from skip_board 
+* 0ada63b629 build/roms: split up main() 
+* 5cecd9e394 build/roms: allow searching status by mismatch 
+* 97d502ccc8 tone the README way, way down 
+```
+
+This is 206 changes, since Canoeboot 20240504.

site/news/canoeboot20231026.md

@@ -1,5 +1,5 @@
 % Canoeboot 20231026 released!
-% Leah Rowe in Canoe Leah Mode™
+% Leah Rowe in GNU Leah Mode™
 % 26 October 2023
 
 Introduction

site/news/canoeboot20231101.md

@@ -1,5 +1,5 @@
 % Canoeboot 20231101 released!
-% Leah Rowe in Canoe Leah Mode™
+% Leah Rowe in GNU Leah Mode™
 % 1 November 2023
 
 Introduction

site/news/canoeboot20231103.md

@@ -1,5 +1,5 @@
 % Canoeboot 20231103 released!
-% Leah Rowe in Canoe Leah Mode™
+% Leah Rowe in GNU Leah Mode™
 % 3 November 2023
 
 Introduction

site/news/canoeboot20231107.md

@@ -1,5 +1,5 @@
 % Canoeboot 20231107 released!
-% Leah Rowe in Canoe Leah Mode™
+% Leah Rowe in GNU Leah Mode™
 % 7 November 2023
 
 Introduction

site/news/canoeboot20240504.md

@@ -1,7 +1,10 @@
 % Canoeboot 20240504 released!
-% Leah Rowe
+% Leah Rowe in GNU Leah Mode™
 % 4 May 2024
 
+**Do not use the Canoeboot 20240504 release, because it had problems with it.
+Please use the [Canoeboot 20240612 release](canoeboot20240612.md) instead.**
+
 Introduction
 ============
 
@@ -466,3 +469,53 @@ All of the following boards have been disabled in the build system:
 D510MO and D945GCLF images not included either, due to lack of testing.
 
 *All other boards have ROM images in this release.*
+
+Errata
+======
+
+See: <https://codeberg.org/libreboot/lbmk/issues/216>
+
+This bug has been *fixed* in lbmk.git, and the fix will be included in
+the next release, but it wasn't caught in the 20240504 release. The same
+fix has been applied to Canoeboot's build system, cbmk.
+
+It is almost certainly guaranteed that *no* Canoeboot users were ever
+affected by this, but extreme measures have been taken to ensure that it
+is *entirely* guaranteed from now on. Read on to know more:
+
+The bug is quite serious, and it was previously decided that documentation
+should be written warning about it (in docs/install/). The bug was *only*
+triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never
+reported on other boards, but there's no way to fully know; what is known
+is that the offending patch that caused the bug has been *removed*; namely,
+xHCI GRUB patches, which are now only provided on Haswell and Broadwell
+hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the
+GRUB tree with xHCI support is provided, but not currently used on any
+mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
+
+The next release will exclude xHCI support on machines that don't need it, which
+is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510),
+and a mitigation is in place that makes SeaBIOS the primary payload, to prevent
+effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the
+first payload then the machine remains bootable even if a similar bug occurs.
+
+It is now the default behaviour, in the next release, that certain images
+contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
+still press ESC to access the SeaBIOS boot menu if you want to directly boot
+an OS from that. This, and the other change mentioned above, will guarantee
+stability. GRUB is *no longer* the primary payload, on any mainboard.
+
+However, it was later decided to put this release in the `testing`
+directory instead; it was initially designated as a stable release.
+
+All ROM images for the 20240504/20240510 releases have been *removed* from
+rsync, but the source tarball remains in place.
+
+For now, you are advised to use the November 2023 release, or build from
+cbmk.git at revision `4f6fbfde81f5176e5892d1c00627f8f680fd3780` (which is known
+to be reliable and is the current revision as of this time of writing) - or,
+alternatively, you are advised to use the next release after 20240510.
+
+A new [audit](audit1.md) has been conducted, marked complete as of 9 June 2024,
+fixing this and many issues; a new *true* stable release will be made available
+some time in June 2024.

site/news/canoeboot20240510.md

@@ -1,7 +1,10 @@
 % Canoeboot 20240510 released!
-% Leah Rowe
+% Leah Rowe in GNU Leah Mode™
 % 10 May 2024
 
+**Do not use the Canoeboot 20240510 release, because it had problems with it.
+Please use the [Canoeboot 20240612 release](canoeboot20240612.md) instead.**
+
 Introduction
 ============
 
@@ -148,3 +151,53 @@ Again, very minor release. I wasn't fully happy with the last one, specifically
 the last Canoeboot release, so I decided to another quick one.
 
 That is all.
+
+Errata
+======
+
+See: <https://codeberg.org/libreboot/lbmk/issues/216>
+
+This bug has been *fixed* in lbmk.git, and the fix will be included in
+the next release, but it wasn't caught in the 20240504 release. The same
+fix has been applied to Canoeboot's build system, cbmk.
+
+It is almost certainly guaranteed that *no* Canoeboot users were ever
+affected by this, but extreme measures have been taken to ensure that it
+is *entirely* guaranteed from now on. Read on to know more:
+
+The bug is quite serious, and it was previously decided that documentation
+should be written warning about it (in docs/install/). The bug was *only*
+triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never
+reported on other boards, but there's no way to fully know; what is known
+is that the offending patch that caused the bug has been *removed*; namely,
+xHCI GRUB patches, which are now only provided on Haswell and Broadwell
+hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the
+GRUB tree with xHCI support is provided, but not currently used on any
+mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
+
+The next release will exclude xHCI support on machines that don't need it, which
+is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510),
+and a mitigation is in place that makes SeaBIOS the primary payload, to prevent
+effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the
+first payload then the machine remains bootable even if a similar bug occurs.
+
+It is now the default behaviour, in the next release, that certain images
+contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
+still press ESC to access the SeaBIOS boot menu if you want to directly boot
+an OS from that. This, and the other change mentioned above, will guarantee
+stability. GRUB is *no longer* the primary payload, on any mainboard.
+
+However, it was later decided to put this release in the `testing`
+directory instead; it was initially designated as a stable release.
+
+All ROM images for the 20240504/20240510 releases have been *removed* from
+rsync, but the source tarball remains in place.
+
+For now, you are advised to use the November 2023 release, or build from
+cbmk.git at revision `4f6fbfde81f5176e5892d1c00627f8f680fd3780` (which is known
+to be reliable and is the current revision as of this time of writing) - or,
+alternatively, you are advised to use the next release after 20240510.
+
+A new [audit](audit1.md) has been conducted, marked complete as of 9 June 2024,
+fixing this and many issues; a new *true* stable release will be made available
+some time in June 2024.

site/news/canoeboot20240612.md

@@ -0,0 +1,870 @@
+% Canoeboot 20240612 released!
+% Leah Rowe
+% 12 June 2024
+
+Introduction
+============
+
+Canoeboot is a free/libre BIOS/UEFI replacement on x86 and ARM, providing
+boot firmware that initialises the hardware in your computer, to then load an
+operating system (e.g. GNU+Linux). It is specifically a *coreboot distribution*,
+in the same way that Trisquel is a GNU+Linux distribution. It provides an automated
+build system to produce coreboot ROM images with a variety of payloads such as
+GNU GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
+to use as possible for non-technical users. From a project management perspective,
+this works in *exactly* the same way as a GNU+Linux distro, providing the same type
+of infrastructure, but for your boot firmware instead of your operating system.
+It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
+and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
+or [GNU GRUB](https://www.gnu.org/software/grub/) to boot your operating
+system; on ARM(chromebooks), we provide *U-Boot* (as a coreboot payload).
+
+This is a *bugfix* release, and is considered stable. It fixes a series of bugs
+that were discovered in the previous Canoeboot 20240504 and 20240510 releases
+from 4 May 2024 and 10 May 2024 respectively.
+
+The [errata](canoeboot20240504.md#errata) on Canoeboot 20240504 meant that all
+ROM images had to be removed, so a new stable release had to be made ASAP to
+compensate - the Canoeboot 20240510 binaries were also removed for the same
+reason, namely that the included xHCI patches (that weren't actually needed on
+any machines) could potentially be problematic. This Canoeboot release excludes
+xHCI GRUB patches on all boards, because xHCI is not physically available on any
+current Canoeboot hardware, at least not x86.
+
+The changes of the recent [1st build system audit](audit1.md) are included, in
+this release, in addition to a few minor fixes made since that date. The audit
+was completed on 9 June 2024 and today is 12 June 2024. The release came unstuck.
+
+NOTE: Although Canoeboot 20240510 was released after 20240504, this release
+announcement for Canoeboot 20240612 is in reference to 20240504, *not* 20240510,
+so it also includes changes from the 20240510 release, with fixes made after it.
+
+Changes since Audit 1
+=====================
+
+Audit 1 was only recent, and forms most of the changes in this release, so look
+further down for a list of those changes or read [the audit 1 page](audit1.md).
+
+Some minor changes have been made in the few days since completion of that
+audit, namely:
+
+* Coreboot trees: use coreboot's own nasm mirror as backup, instead of the
+  macports mirror that was used in audit5. In audit5, a feature was added where
+  crossgcc tarballs are downloaded by lbmk, with redundant links, rather than
+  relying on the coreboot build system to do this. (and this means that cross
+  gcc tarballs are now included in the release tarballs, enabling fully offline
+  builds on boards that don't need to download vendor files at build time)
+* NVMe patch for GRUB payload: it is still present, but it is now *only* enabled
+  on boards that can physically *have* NVMe SSDs; on boards that don't need the
+  patch, it is not present. This means there are three GRUB trees: `default`
+  which most boards use and lacks nvme/xhci support, `nvme` which contains the
+  NVMe support and `xhci` which contains both xHCI and NVMe support. Each board
+  is configured to use the appropriate GRUB tree, as required.
+
+The reason for separating the NVMe patch to only those boards that need it, is
+precisely to avoid any potential issues if a board doesn't need it. The NVMe
+patch has been extensively tested, on all of the boards that actually have it.
+
+Audit 1 changes
+===============
+
+Since the recent audit 1 changes are included in this release, the changelog
+of that audit has simply been copied for sake of efficiency. Firstly:
+
+Modest code size reduction
+--------------------------
+
+There are 1054 lines of shell script in the build system, versus 1208 in the
+Canoeboot 20240504 release. Canoeboot's build system is written purely in
+POSIX sh; not BASH, not KSH, not ZSH, jush sh!
+
+This is a difference of 154 lines, or a 13% reduction. Despite the reduction,
+numerous features have been added and a large number of bugs were fixed.
+
+Summarised list of changes
+==========================
+
+Changes are in order per category, from newest to oldest:
+
+Feature changes
+---------------
+
+* **Download crossgcc tarballs as dependencies, when cloning coreboot.** We
+  previously relied on the coreboot build system, which automatically fetches
+  these when running `make crossgcc`, which we run automatically. However,
+  the coreboot logic has to be patched for reliability because the GNU HTTP 302
+  redirect often fails so we use a static mirror, and the logic has no
+  redundancy. With this new change, we use the same tarballs but we specify
+  two URLs, a main and a backup. This also means that the tarballs will once
+  again be included in Canoeboot release archives, enabling offline builds.
+* **Support downloading files as submodules, in Git repositories.** This
+  complements the pre-existing feature where sub-repositories (Git) can be
+  cloned into a subdirectory of a given main repo. We use this for crossgcc,
+  as referenced above.
+* New files under `config/dependencies/` for Fedora 40 and Ubuntu 24.04. Now
+  you can run `./build dependencies fedora40`
+  and `./build dependencies ubuntu2404` on each respective distro, to get
+  the right build dependencies for building Canoeboot from cbmk.
+* **NEVER** run `git submodule update`, *ever*. Instead, rely *solely* on
+  config/submodule/ to define which dependencies should be downloaded, to each
+  given subdirectory within a main project. This is using a feature described
+  later on (in this audit report), whereby projects can have redundant
+  submodule repositories defined; initially, this feature was an *override*
+  where otherwise the submodule update command would be executed if
+  the `.gitmodules` file existed for a given project; this override is now
+  the *only* way to do it, and is thus the default behaviour. This may be
+  considered a preventative bug fix, in case certain projects auto-download
+  submodules that might cause us trouble in the future. It's better that we
+  maintain tight control of submodules.
+* **Summarising the next few changes mentioned below: out-of-source builds
+  are now fully supported, for both single- and multi-tree projects.** (it was
+  previously only supported on multi-tree projects)
+* Moved builds of coreboot utilities (e.g. cbfstool) to `elf/utilname`,
+  e.g. `elf/cbfstool/default/cbfstool` would be the new cbfstool binary location
+  for the one build from coreboot in the `default` tree.
+* script/trees: Now single-tree builds are skipped if a build exists
+  under `elf/projectname/`, based on the presence of a `build.list` file; this
+  is consistent with the same behaviour pre-existing for multi-tree projects.
+* When building memtest86plus, the binary is now placed out-of-source,
+  into `elf/memtest86plus`.
+* When building flashprog, the binary is now placed out-of-source,
+  into `elf/flashprog/`.
+* Use new function `singletree` to decide whether to use submodules, rather
+  than hardcoding a check for *coreboot* - NOTE: use of submodules was later
+  disabled during this audit, replaced with custom handling in cbmk.
+* For error exits caused by *improper commands* (as opposed to fault conditions
+  while processing valid commands), don't directly call `err`; instead, call a
+  newly written function `badcmd` which says that much, and links to the
+  website (if `docs/` is present as in releases, it also points there).
+* Added a `projectsite` file pointing to canoeboot.org, complementing the
+  existing `projectname` file which contains the word `canoeboot`. This is
+  used in the `version` command.
+* **GRUB is now a multi-tree project.** Each given coreboot target can
+  specify which GRUB tree it wants to use, each containing its own revision
+  and patches, with its own GRUB configuration file. This can be used later on
+  to provide specific optimisations on each given mainboard, but it is used
+  at present to exclude xHCI patches on boards that don't need it; please also
+  read the bugfix section (of this audit report) pertaining to this same topic,
+  for more context. Before this change was implemented, all mainboards used
+  the exact same GRUB revision, with the same patches and the same config.
+* grub.cfg: scan `grub2/` last, on each given device/partition; this speeds
+  up the boot time in most tests, because most setups use `grub/`,
+  but `grub2/` is still used on legacy setups so we have to support it and, for
+  reasons mentioned in the bullet point below, GRUB is very inefficient at
+  generating the list of devices/partitions when using the `*` wildcard, so
+  we can't scan `grub*/`.
+* grub.cfg: it now scans a reduced set of devices/partitions by default, while
+  still ensuring (in practise, on real systems) that all such devices and
+  partitions will be scanned. We hardcode this, because the `*` wildcard in
+  GRUB is *very slow* on some machines, due to the way the GRUB kernel
+  constantly re-initialises the list of devices and partitions during operation.
+  Scanning an *excessive* number of hardcoded device/partition numbers slows
+  down the boot too, so this has been optimised. It has been tested and it
+  shouldn't cause any issues on machines/setups that people actually use.
+* **grub.cfg: scan distro-provided grub.cfg from ESP;** we previously only
+  scanned the ESP for isolinux/syslinux configurations (which GRUB can parse).
+* grub.cfg: Don't search for `*_grub.cfg` as this slows down the bootup
+  sequence, and nobody really uses this anymore; Canoeboot's GRUB is much more
+  robust these days, pretty much booting anything automatically, but you used
+  to have to (regularly) use a `canoeboot_grub.cfg` file to override the default
+  one provided by your distro. This legacy cruft has been removed, entirely!
+* script/roms: Allow to override `grub_scan_disk` via `-s`, for
+  example: `./build roms -s nvme t1650_12mb`
+* **grub.cfg: Use `grub_scan_disk` to set boot order (rather, boot order by
+  device type).** It is possible now to configure each mainboard with this
+  variable, so that certain types of devices are scanned in a precise order;
+  for example, scan NVMe SSDs first.
+* **include/git.sh: Allow manual override of `git submodule` handling**, instead
+  directly downloading Git repositories using `git clone`, into the subdirectory
+  of a given main Git repository (as per `src/projectname` scheme). With this
+  feature, it is possible now to specify a *backup* submodule repository, for
+  redundancy, all while still allowing to reset the revision (and *patch* the
+  given submodule). This has been used to provide greater redundancy when
+  downloading coreboot submodules. It also allows to *limit* the number of
+  submodules, so now we only download the ones we need, thus saving bandwidth
+  especially during very large and long build sessions. - *NOTE: this was
+  later changed so as to be the ONLY method for downloading submodules, skipping
+  the actual git-submodule-update command entirely, on all projects.*
+* **Native NVMe driver added to the GRUB payload**, allowing users to boot from
+  NVMe SSDs where present on a given mainboard. The patch is courtesy of
+  Mate Kukri, who ported SeaBIOS's own NVMe driver, converting all of the
+  code to run properly within GRUB's own kernel. NVMe SSDs are now fully
+  bootable on all machines that can have them, offering vastly superior
+  read and write performance when compared to SATA SSDs.
+* include/git.sh: Allow patching git submodules (NOTE: support for submodules
+  was removed entirely, later in the audit, in favour of custom logic in cbmk
+  for the downloading of such dependencies).
+* Added Portuguese keyboard support in the GRUB payload (patch courtesy of
+  the contributor by alias `samuraikid`).
+* Removed all help commands, because it's just a duplication of documentation
+  that is already included in releases anyway, and people using the Git
+  repository require internet access anyway, so they can just use the website.
+* Main build script: removed the functionality for generating source tarballs
+  where the only source code included is U-Boot; we do not need this, because
+  the larger source tarball containing all of Canoeboot also contains U-Boot.
+* include/option.sh: Don't bother checking for GNU Tar, because we were only
+  using it for reproducible tarball generation which didn't work yet anyway;
+  there are still ways of doing it with BSD tar and so on.
+* Print a two-line break before confirming the location of the generated
+  release archive, when running release builds. This makes it more obvious
+  to the operator.
+* Removed all status checks from script/roms (formerly script/build/roms),
+  because it's better to document this instead, and rely on testing regardless.
+
+Bug fixes
+---------
+
+Some of these changes fix actual issues that were found in testing, while
+others were fixed *before* being triggered/reported and are thus *preventative
+bug fixes*. The logic in cbmk has been very intensively audited as is customary!
+
+The changes are, from newest to earliest:
+
+* script/trees: Exit with error status if a given project is not defined. It
+  was previously decided that this script could be used to directly run Makefiles
+  from any given directory, but this is no longer done as it was error-prone;
+  this change prevents such usage, thereby preventing unstable conditions within
+  the build system.
+* **Create a lock file when running cbmk.** Only do it from the main parent
+  instance, but not child instances of it; delete it at the end, after exiting
+  from the parent process. If starting a separate parent process, that one
+  will now immediately exit (with error status) if the lock file exists. This
+  prevents the fault condition where the user accidentally runs the same cbmk
+  instance twice, from the same work directory; it is only designed to be
+  executed once, per work directory. This is similar to the locking feature
+  you find in package managers such as apt-get. Also do this in release/
+  directories, while building (but don't include a lock file inside the tarball).
+* include/git.sh: When doing a global check for files in every project all at
+  once, as defined by each respective (if existent) `nuke.list` file, hide
+  the output. Only show the output when running it on a specific project, not
+  the one in the for loop. This prevents user confusion / false bug reports.
+* include/git.sh: Download coreboot as defined by `xtree` *before* downloading
+  the main project that defined it, to prevent a situation where the main project
+  is downloaded successfully but not the dependency (defined by `xtree`); this
+  is to maintain the integrity of the build system under fault conditions.
+* include/lib.sh: When a download fails (running the `download` function),
+  don't then say that the file is "missing". Instead, actually say that the
+  download failed, so that the operator has a better understanding.
+* include/lib.sh: Hide stderr on the `download` function, for the initial
+  check when verifying an existing file; although no problem existed on
+  technical terms, the output was confusing because it made the user think
+  there was a problem. The logic then downloads and re-verifies, and the
+  output indicating *that* verification has not been hidden; if the file
+  already exists, this is simply indicated by `e()`. This is considered a bug
+  fix, because it fixes the bug where users made erroneous bug reports, by
+  re-engineering the situation so that they do not make such erroneous reports.
+  TL;DR hide a totally benign (non-)error message.
+* include/git.sh: Provide better user feedback about what is being downloaded
+  and where - although nothing was broken before, this lack of feedback was a
+  bug because it made debugging harder. Provide more clarity for the user.
+* include/git.sh: Download dependencies *before*, not *after*, downloading the
+  project sources that depend on it. For example, pico-serprog depends on
+  pico-sdk. If you were to download pico-sdk *after* pico-serprog, the latter
+  may be downloaded and placed in src/, but then the former (sdk) could fail
+  due to bad internet, and now the overall downloaded code is corrupt, and there
+  was nothing checking for this after the fact; checking for it would be bloat.
+  By downloading the dependency *before*, then if *that* download fails, so
+  does the main one, and integrity is maintained within the build system.
+* Preventative bugfix: don't check empty paths in `copy_elf` (of script/trees),
+  even though this potential bug was not yet triggered. Play it safe.
+* script/trees: Don't check pre-existing builds in elf/ if `build.list` is
+  missing, otherwise it's too soon and builds are prevented in the first place;
+  this was caused initially when supporting out-of-source builds for single-tree
+  projects, as was already done on multi-tree. Now this is fixed.
+* Documentation: only define the Untitled Static Site Generator
+  in `config/git` - the dependencies (markdown files and images) are now
+  defined in config/submodules/ instead. This prevents the bug where you could
+  download one of the dependencies first which would make the main project,
+  Untitled, un-downloadable, since the dependency projects go in subdirectories
+  of the main project that depends on them.
+* Handle serprog dependencies in config/submodule instead of relying on
+  the git submodule update command, and only provide necessary modules. This
+  prevents the bug where downloading a dependency first later prevented the
+  main project from being downloaded, if the dependency was in a subdirectory
+  of what depends on it.
+* Build coreboot utilities on a number of threads as defined by `XBMK_THREADS`;
+  although they already compiled, they would always do so on a single thread,
+  which is considered a bug. Now they can be compiled on multiple threads.
+* include/lib.sh: Don't use `./update trees -f` to build coreboot *utilities*,
+  because it's quite error prone and not what that script is designed to do;
+  it is only designed to operate based on strictly defined single- and
+  multi-tree projects. Instead, call `make` directly.
+* Don't use the presence of a `build.list` file to detect a multi-tree project
+  when running `./update trees`; instead, check the presence of `target.cfg`
+  down one level from `config/project/`, so: `config/project/*/target.cfg`
+  instead of `config/project/target.cfg`. This way, if someone working on cbmk
+  accidentally adds that `build.list` file in the wrong place, cbmk won't
+  become unusable. This also means that single-tree projects can now provide
+  a `build.list` file! (and some of them now do - look at the features section
+  on this page)
+* Move check for *root user* to include/lib.sh, *before* the version/versiondate
+  files are written; these files need to be writeable by the standard user,
+  otherwise cbmk will exit. If you run cbmk as root, except when running the
+  dependencies command, it exits with error status; ironically, that very same
+  check then prevented running as root-root, causing cbmk to become unusable
+  until those files were either deleted or had ownership changed. This fix
+  prevents the bug from occuring ever again, but people who were previously
+  affected still have to fix these files (if they were written as root).
+* Move dependency handling to include/lib.sh, *before* the version/versiondate
+  files are written, and *exit* before they are written; this prevents writing
+  the version/versiondate files as root, which previously occured when running
+  a command such as `./build dependencies debian` (installs build dependencies
+  from apt-get on a Debian machine). This bug ironically prevented cbmk from
+  running at all, under such conditions, because the dependencies script
+  required root, but cbmk exits with error status if running anything else as
+  root, and if version/versiondate are owned by root, that prevents cbmk from
+  running because writing to these files is the first thing it does, so an exit
+  with error status would otherwise occur.
+* config/git/: Bump to a newer revision of Untitled (static site generator),
+  which thereby also imports the same fix as described in the next bullet
+  point below, because Untitled had (and now no longer has) the exact same bug.
+* include/lib.sh: check environmental variables properly, for example
+  check that `${XBMK_RELEASE+x}` isn't unset; it was previously grepping
+  the output of `set`, which led to a bug report by a user who had the
+  variable `TMUX_TMPDIR` set, whereas `TMPDIR` was unset and cbmk was checking
+  the latter; in this example, the bug caused cbmk to act as though `TMPDIR`
+  was set, when it in fact wasn't, and code that used it then crashed because
+  cbmk does `set -u -e` (and it does this precisely to catch such bugs like the
+  one you're reading about now so that they can be fixed, like this one was!)
+* **Re-configured GRUB so that none of the currently supported machines contain
+  xHCI support**. This is a mitigation against the bug reported in [lbmk
+  issue 216](https://codeberg.org/libreboot/lbmk/issues/216). This is done, by
+  using the new *multi-tree* GRUB handling, which is mentioned above in
+  in the section (of this audit report) pertaining to *feature changes*, whereby
+  each mainboard can have its own GRUB revisions and patches, with its own
+  GRUB configuration file (that could be uniquely optimised for it).
+  We do not need xHCI patches on any Canoeboot machines, but the patches are
+  free software regardless, and it's important to keep Canoeboot in sync with
+  Libreboot. It may be that you want to enable it on a custom configuration,
+  for example if you use a USB3 card on a KGPE-D16, but it is not currently
+  enabled by default on any Canoeboot machines.
+* **Fix vboot build issue when running cbmk in i686 (32-bit) host machines**.
+  The patch, courtesy of *Luke T. Schumaker*, adapts vboot's vmlinuz extract
+  function so that it uses pointer logic directly, instead of defining
+  integers (of type `ssize_t`) which, the way it was written, caused GCC to
+  believe that there would be a buffer overflow in code; the new code is more
+  robust and should prevent such an issue. This is both an *acute* bug fix,
+  fixing a bug that was actually triggered, and a preventative bug fix as the
+  original code wasn't correct either, even on AMD64 hosts (where it happened
+  to compile anyway).
+* **GRUB: Never run it as a primary payload on any target but QEMU**. This is
+  a preventative bug fix, after lbmk bug report issue 216:
+  <https://codeberg.org/libreboot/lbmk/issues/216> - although it was caused by
+  the xHCI patches, and only happened on Sandybridge hardware, and although
+  this was later removed on those boards, GRUB is very complex and likely has
+  a lot of memory corruption issues. SeaBIOS is more reliable, so: Canoeboot
+  only provides *SeaBIOS* as primary payload, but allows you to execute GRUB
+  from the SeaBIOS menu (the very same GRUB). Additionally: cbmk already
+  supported a configuration whereby SeaBIOS reads a `bootorder` file in CBFS,
+  making it try to run the GRUB payload first, while still allowing you to
+  interrupt by pressing ESC to bring up an alternative boot select menu. This
+  is now the *default*, on all x86 mainboards. This is a mitigation against
+  future instability in GRUB because, if such issues happen again, it will not
+  cause a brick since you can just use SeaBIOS instead, and skip booting to
+  the GRUB payload (on the affected machines, BIOS GRUB still worked, which
+  your distro provides and SeaBIOS executes it). *NOTE: GRUB was later made
+  into a multi-tree project, with certain mainboards using a version that
+  has the xHCI patches, if required, because the machines that actually need
+  xHCI support were not affected by the bug referenced in issue 216.*
+* Main build script: Check SUID before checking Git name/email, otherwise the
+  version/versiondate files could be written as root and thus prevent building
+  of cbmk, which (for most commands) is intentionally engineered to exit (with
+  error status) if you run it as root.
+* script/trees: Reset variable `makeargs` per target, so as to prevent
+  pollution of this variable when switching from one build target to the next.
+* script/trees: Added `UPDATED_SUBMODULES=1` to the make command when running
+  any coreboot `make` command, to prevent coreboot from automatically fetching
+  certain Git submodules; this is a preventative fix, fixed before it became
+  a bug, which it likely would have become at some point as this is exactly
+  what the coreboot build system does!
+* Main build script: hide the output of `git init` when cbmk re-initialises the
+  Git history, to prevent its output from being wrongly inserted into the
+  output of commands such as `./build roms list` - such pollution would cause
+  build errors, so it's important that the Git initialisation function either
+  doesn't output anything, or that it should cause an *exit* if output is to be
+  required.
+* Added the `CHANGELOG` file to `.gitignore`. This means `./update release`
+  will now work, on release archives, because cbmk re-initialises Git history
+  when doing so, but the CHANGELOG file (when present) causes cbmk to skip
+  all source downloads (which the release builder relies on).
+* **Fix garbled output on 1440x900 monitors when using the Dell Latitude E6400.**
+  The E6400 uses a reference clock (`DPLL_REF_SSCLK`) set to 100MHz, whereas
+  libgfxinit assumed 96MHz. This timing descrepancy did not cause an issue on
+  lower resolution displays, so we never caught it in earlier testing. Patch
+  courtesy of Nicholas Chin, who debugged this issue alongside the user who
+  reported it. It was fixed by making such timing configurable, within the
+  coreboot build system, setting it to 100MHz on Dell Latitude E6400.
+* script/roms: Skip a target when its config directory is missing, so that
+  running a coreboot target with no configs in it will not yield an error;
+  instead, it will now cause a non-error return.
+* include/option.sh: If `.git` is missing, in a bare copy of cbmk (not a
+  release archive), recreate the version/versiondate files manually so as to
+  prevent a build error. Use of `cbmk.git` or the release archives is
+  recommended, but some users directly download snapshots of `cbmk.git` from
+  sites such as Codeberg, and there's no way for us to turn off this feature;
+  even if we did, it may be present on other Git hosting sites, where users
+  might host their own copy of cbmk.
+* include/option.sh: Don't return non-zero status from the function
+  named `mkrom_tarball`, because certain other functions rely on its return
+  value to always be *zero*; instead, call `err` which will then yield
+  an *exit* (with non-zero status). This means that the function will now
+  always *return* zero, when it returns.
+* include/git.sh: Remove `.git` directories *per-project*, as and when each
+  project is being downloaded, instead of having it done all in bulk by the
+  main build script. This kicks in when `XBMK_RELEASE` is set (release builds),
+  to correct the over-use of disk space during such very large builds processes.
+  This makes the build system less likely to OOM when running it inside tmpfs.
+* Main build script: initialise Git history *before* running any command,
+  because this is required for reliable use of the coreboot build system, which
+  the *inject* command makes heavy use of. This reduces the number of errors,
+  when running these commands from a release archive, where cbmk re-initialises
+  a new Git history when you run it for the first time.
+* Main build script: define `xp` as a global variable, to prevent it from
+  being lost between functions.
+* script/roms: Create full release tarball name, when generating releases.
+* Main build script: exit (with error status) if not running directly from
+  the root of the cbmk work directory.
+
+General code cleanup
+--------------------
+
+In addition to *general* very sweeping code cleanup, condensing code lines
+where possible and so on:
+
+* include/lib.sh: Simplified the `download` function (used for crossgcc tarballs).
+* include/lib.sh: Simplified the `singletree` function.
+* include/git.sh: Simplified the `link_crossgcc` function.
+* include/git.sh: Simplified the `nuke` function, because it was over-engineered
+  to the extreme. Now it's more reasonable.
+* include/lib.sh: Move download logic here from lbmk as of audit 5, for the
+  feature where *files* can be downloaded as submodules, within Git repositories.
+  Please read the notes about this in the *features* section.
+* include/lib.sh: Shortened a string in the `e` function, so that the line
+  does not exceed a length of 80 characters.
+* include/git.sh: Unified the handling of git clone/reset/am commands into a
+  single function, rather than duplicating the same logic across multiple
+  functions.
+* script/trees: simplify the `copy_elf` function; don't create the elf directory,
+  create one defined by `dest_dir` instead (which is the elf directory with
+  the subdirectory for that project concatenated). Only create it within
+  the `copy_elf` function, which is only called if actually compiling the
+  code. This avoids creating empty directories under elf/, for example under
+  fault conditions.
+* include/git.sh: Additional code cleanup, removing certain code that was in
+  place because the code used to handle both `git submodule update` and the
+  custom *override* logic for submodules; now only the override is used, at all
+  times, so the code was cleaned up and optimised only for this.
+* include/git.sh: Reduced code indentation in function `fetch_submodule`.
+* include/git.sh: Renamed a few variables for increased code clarity.
+* script/trees: Unified handling of coreboot `makeargs`.
+* Moved function `handle_coreboot_utils` to script/trees (and renamed it
+  to `check_coreboot_utils`), as it's only ever used from there.
+* Moved cfgsdir/datadir variables to include/lib.sh, because it's also used
+  from script/roms and script/trees; unify them under a common location.
+* Handle `build.list` from config/data/, not config/ - this avoids needing to
+  check for `build.list` in the `items` function on include/lib.sh, and it is
+  now avoided.
+* include/lib.sh: More user-friendly output from the `e` function, telling the
+  user whether or not a file/directory exists. This is regularly used, for
+  example when trying to download a project and the source code was already
+  prepared.
+* U-Boot on QEMU: removed the (currently) unused x86 target.
+* grub.cfg: Split function `try_user_config` into multiple smaller functions.
+* grub.cfg: Don't scan ESP on btrfs subvols as the ESP is always on a FAT32
+  partition. This saves time during the bootup sequence.
+* Renamed include/option.sh to include/lib.sh
+* Main build script: simplified the logic for Git repository initialisation
+  by *returning non-zero status*, instead of calling err, and handling this
+  return status in the calling function.
+* Main build script: condensed the logic for Git name/email checking into a
+  simply for loop running `eval`, rather than having lots of separate but very
+  similar Git commands.
+* script/trees: Removed a few unused variables.
+* include/git.sh: Moved logic for copying a Git repository to a new function.
+* include/git.sh: Moved function `link_crossgcc` to a different location
+  within the file, for proper top-down order of logic (required as per the
+  cbmk coding style).
+* include/git.sh: Split logic for crossgcc symlinking into its own function.
+* include/git.sh: Skip submodule checks if `.gitmodules` missing (NOTE: later
+  replaced with custom submodule handling in cbmk).
+* include/git.sh: Merged `patch_submodules` in `prep_submodules` (NOTE: ditto
+  to the same note below).
+* include/git.sh: Split up submodule handling into a new function (NOTE: support
+  for submodules was later replaced with custom logic in cbmk).
+* include/git.sh: Shortened a few variable names.
+* include/git.sh: Removed redundant check for the existence of the patches
+  directory, when patching a given project. This is unnecessary, where it was
+  removed, because the patching function itself also checks this. Reduction
+  in code size by *one line*.
+* include/git.sh: Removed function `fetch_from_upstream` and merged its logic
+  into calling function `fetch_project_trees`, the only calling function, since
+  the logic in `fetch_from_upstream` was very small and splitting made no sense.
+* include/option.sh: Renamed `mktar_release` to `mkrom_tarball`.
+* script/roms: Renamed function `moverom` to `copyrom`, because it runs `cp`,
+  not `mv`, therefore is is *copying* a file, not moving it.
+* script/roms: Simplified the logic for listing available serprog build targets.
+* script/roms: General simplification of configuration handling for payloads.
+* Main build script: removed the `excmd` function and merged its logic into
+  the `main` function, and then `main` was cleaned up significantly.
+* Main build script: don't make `script_path` a global variable; this allowed
+  a reduction in code size by precisely *one line of code*.
+* Main build script: merged the functionality of function `check_git` into
+  the `main` function, then deleted function `check_git` (which was in
+  the file include/option.sh).
+* Main build script: general simplification of the logic handling source code
+  downloads in function `fetch_trees`.
+* Main build script: Use `UTC+0000` when initialising git repository commit
+  dates (for initial commits).
+* Removed the `check_project` function, and placed its logic directly
+  inside `include/option.sh` so that it automatically runs in every script
+  that sources it.
+* Main build script: General cleanup on the code handling file deletions
+  under function `fetch_trees`.
+* Main build script: delete function `mkversion` and, in its calling function,
+  simply print the string contained in variable `relname`.
+* Main build script: general cleanup on the logic that handles tarballs.
+* Main build script: Remove `mkrom_images`, and move its logic into the only
+  calling function within that same file.
+* include/option.sh: Removed the function `insert_version_files` and merged
+  its logic into its only calling function.
+* Unified all logic for handling SHA512 checksums, placing it inside
+  include/option.sh for use elsewhere.
+* Move image tarball generation to script/roms (formerly script/build/roms).
+* Removed redundant function `extract_ref` from include/mrc.sh
+* Removed an errant comment from include/git.sh
+* Switched to a one-level directory structure for main scripts, rather than
+  two-level; for example, script/build/roms is now script/roms
+* Merged script/update/release into the main build script
+* Merged script/build/serprog into script/build/roms
+* script/build/roms: remove unnecessary command (errant return)
+* Merged include/err.sh with include/option.sh, into include/option.sh
+* script/build/roms: fixed improper use of variable outside a function
+* build/build/roms: more reliable exit status in `skip_board()`
+* script/build/roms: split up `main()` into multiple smaller functions
+
+Revision updates
+================
+
+Some revisions were updated as part of standard routine, but happened to be
+done during this audit. Those updates are as follows:
+
+SeaBIOS
+-------
+
+Bump SeaBIOS to revision `e5f2e4c69643bc3cd385306a9e5d29e11578148c`, which has
+these changes relative to the old one:
+
+```
+* e5f2e4c6 pciinit: don't misalign large BARs
+* 731c88d5 stdvgaio: Only read/write one color palette entry at a time
+* c5a361c0 stdvga: Add stdvga_set_vertical_size() helper function
+* 22c91412 stdvga: Rename stdvga_get_vde() to stdvga_get_vertical_size()
+* 549463db stdvga: Rename stdvga_set_scan_lines() to stdvga_set_character_height()
+* c67914ac stdvga: Rename stdvga_set_text_block_specifier() to stdvga_set_font_location()
+* aa94925d stdvga: Rework stdvga palette index paging interface functions
+* 8de51a5a stdvga: Rename stdvga_toggle_intensity() to stdvga_set_palette_blinking()
+* 96c7781f stdvga: Add comments to interface functions in stdvga.c
+* 2996819f stdvga: Rename CGA palette functions
+* 91368088 stdvgamodes: Improve naming of dac palette tables
+* 70f43981 stdvgamodes: No need to store pelmask in vga_modes[]
+* 1588fd14 vgasrc: Rename vgahw_get_linesize() to vgahw_minimum_linelength()
+* d73e18bb vgasrc: Use curmode_g instead of vmode_g when mode is the current video mode
+* 192e23b7 vbe: implement function 09h (get/set palette data)
+* 3722c21d vgasrc: round up save/restore size
+* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info
+* 163fd9f0 fix smbios blob length overflow
+* 82faf1d5 Add LBA 64bit support for reads beyond 2TB.
+* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code
+* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes
+* a6ed6b70 limit address space used for pci devices.
+```
+
+Flashprog
+---------
+
+Updated to revision 5b4fdd1 from 2 May 2024, rebasing the MX workaround patch.
+
+This imports upstream changes, relative to the previous revision:
+
+```
+* 5b4fdd1 z60_flashprog.rules: Add udev rule for CH347
+* 72c9e40 meson: Check for CPU families with known raw mem access
+* 3458220 platform/meson: Port pciutils/pci.h workaround to Meson
+* f279762 platform/meson: Check for libi386 on NetBSD
+* 14da5f7 README: Convert to Markdown
+* 8ddea57 README: Document branching and release policy
+* 2522456 util/list_yet_unsupported_chips.sh: Fix path
+* cbf9c11 spi: Don't cross 16MiB boundaries with long writes
+* 823a704 dediprog: Skip warning on first attempt to read device string
+* e8463c8 dediprog: Revise prefix check for given programmer id
+* 38af1a1 dediprog: Revise id matching
+* 4661e7c amd_spi100: Use flashprog_read_chunked() for progress reporting
+* cdcfda2 read_memmapped: Use flashprog_read_chunked() for progress reporting
+* 7679b5c spi25: Replace spi_read_chunked() with more abstract version
+* ca1c7fd spi25: Normalize parameters of spi_nbyte_read()
+* e36e3dc dediprog: Use default_spi_write_256
+* 522a86d linux_spi: Use default_spi_read()/_write_256()
+* 806509b cli_classic: Turn progress reporting into a progress bar
+* 842d678 libflashrom: Return progress state to the library user
+* aa714dd flashprog.c: Let select_erase_functions() return byte count
+* 2eed4cf serprog: Add SPI Mode and CS Mode commands
+* 821a085 dediprog: Implement id reading for SF600 and later
+* 274e655 dediprog: Read device string early
+* 0057822 dediprog: Add protocol detection for SF700 & SF600Plus-G2
+* fb176d2 dediprog: Use more general 4BA write mode for newer protocols
+* 0ab5c3d dediprog: Split device type and version parsing
+* bdef5c2 dediprog: Use unsigned conversions to parse device string
+* 5262e29 dediprog: Try to request 32B device string (instead of 16B)
+* e76e21f dediprog: Get rid of some unnecessary hex constants
+* 5a09d1e udelay: Lower the sleep vs delay threshold
+* 03ad4a4 linux_mtd: Provide no-op delay implementation
+* 211c6ec serprog: Refine flushing before synchronization
+* 383b7fe serprog: Test synchronicity before trying to synchronize
+* d7318ea serprog: Move synchronicity test into separate function
+* 9a11cbf Let the flash context directly point to the used master
+* aabb3e0 writeprotect: Hook wp functions into the chip driver
+* 89569d6 memory_mapped: Reduce `decode_sizes` to a single `max_rom_decode`
+* 929d2e1 internal: Pass programmer context down into chipset enables
+* 7c717c3 internal: Pass programmer context down into board enables
+* e3a2688 Pass programmer context to programmer->init()
+* 2b66ad9 Start implementing struct flashprog_programmer
+* 4517e92 memory_bus: Drop stale `size == 0` workaround and FIXME
+* b197402 memory_bus: Split register mapping into own function
+* 0e76d99 memory_bus: Move (un)map_flash_region into par master
+* 9eec407 Perform default mapping only for respective chips
+* 56b53dd wbsio_spi: Request memory mapping locally
+* 5596190 it87spi: Request memory mapping locally
+* 46449b4 spi25: Drop stale `bus == SPI` guards
+* ab6b18f spi25: Move 4BA preparations into spi_prepare_4ba() hook
+* 901fb95 Add prepare/finish_access() hooks for chip drivers
+* a96aaa3 dediprog: Support long writes of 16MiB and more
+* 1338936 Consider 4BA support when filtering erase functions
+* 8d36db6 flashprog.8: Fix up serprog example
+* d2ac303 flashprog.8: document new serprog cs parameter
+* d1b9153 chipset_enable.c: Add Genoa to mendocino entry
+```
+
+As a reminder:
+
+Canoeboot now uses Flashprog instead of Flashrom; Flashprog is a fork of
+Flashrom, lead by Nico Huber after a dispute with the new leadership of
+Flashrom, and it was felt that Flashprog is a better choice for Canoeboot.
+
+Git log
+=======
+
+This entire set of changelogs is based on the precise Git history in cbmk,
+relative to Canoeboot 20240504 which is from where the audit began.
+
+The latest changes are listed first, going all the way down to earlier changes:
+
+```
+* 4f6fbfde81 minor code cleanup in the build system 
+* 070aee6728 re-add ability to use cbfs grub.cfg as default 
+* b4acd0f73c trees: exit with error if project undefined 
+* fd9664c567 build: also make a lock file during release build 
+* 686bad6d4e lib.sh: more useful lock message 
+* f1caf89a28 create a lock file during builds 
+* b6dc23bc67 git.sh: hide e() output on for loop 
+* e51eae0d25 lib.sh: fix regression 
+* 8b1a54d19e git.sh: download xtree *before*, not after 
+* 14bba2d789 git.sh: fix deletion path in nuke() 
+* ab4c4d406f lib.sh: less confusing error in download() 
+* 2eaaa63f58 lib.sh: hide stderr on download() 
+* 9e2584fbd9 lib.sh: simplify download() 
+* 79fb79d239 lib.sh: fix redundancy in download() 
+* e8b1d45631 lib.sh: simplify singletree() 
+* 90a8ef90b0 git.sh: further simplify nuke() 
+* c6b692208b git.sh: simplify link_crossgcc() 
+* c043e5810d git.sh: simplify nuke() 
+* 323a17d0c8 Add dependency scripts for Fedora 40 and Ubuntu 24.04 
+* 62b2310a28 add crossgcc tarballs to config/submodules/ 
+* 8a34a0d338 git.sh: support downloading *files* as submodules 
+* 0730513709 git.sh: remove unnecessary line break 
+* ad05266f8d import file download function from lbmk c202dc61 
+* b8e9eab0ba lib.sh: shorten a string in e() 
+* a29cf274bc git.sh: fix submodule path 
+* 7ac2264f53 git.sh: simplify prep_submodules() 
+* 7c8173ebd4 git.sh: unified handling of git clone/reset/am 
+* 573199c07d trees: simplified copy_elf() handling 
+* d0d9b1204f git.sh: simplify submodule handling 
+* df5d7c18bf git.sh: provide feedback for repository downloads 
+* 591c7d28e0 git.sh: download "depend" projects *before* 
+* 548d1e20c1 git.sh: reduced indentation in fetch_submodule 
+* 12a04e8de2 git.sh: reduced indentation in prep_submodules 
+* 9825e97a83 git.sh: *never* run git submodule update 
+* 860deb3e7e lib.sh: rename variable for clarity 
+* 8d5edd4f06 trees: don't check empty path in copy_elf() 
+* c1176bbd28 trees: fix build issue caused by bad elf check 
+* c88fb8c129 trees: fix listfile check in copy_elf() 
+* 9168d33741 trees: don't say check elf/ if build.list missing 
+* db09530905 trees: don't do elfcheck if build.list missing 
+* 99418a7e82 define mdfiles/images in config/submodules/docs/ 
+* 83d84797d8 libopencm3 to config/submodules/ on stm32-vserprog 
+* c3cabcddf9 add tinyusb to config/submodule/ for pico-sdk 
+* e4eb82e089 trees: unified coreboot makeargs 
+* f7170092c8 trees: use multiple threads to build cbutils 
+* 1d7a6f04c9 move handle_coreboot_utils to script/trees 
+* ff16d27991 put coreboot utils in elf/, not cbutils/ 
+* 3748f710c9 fix build issue building coreboot utils 
+* a30bfd334f trees: skip single-tree build if a build exists 
+* b682b4ddca use correct memtest86plus path in script/roms 
+* 4749a5a29f put memtest86plus builds in elf/memtest86plus/ 
+* 0e9d9b33b2 put flashprog builds in elf/flashprog/ 
+* 7fe0106fa0 trees: also print "DONE! check elf/dir" on single 
+* 74759d876a trees: handle build-test on multi-tree projects 
+* 98e9cf6864 git.sh: use singletree() to decide submodules 
+* b3b887567a remove cbcfgsdir variable (unused) 
+* cb446e7d24 move cfgsdir/datadir variables to lib.sh 
+* 7d99786a1a handle build.list from config/data/, not config/ 
+* a61794dfca don't use build.list to detect multi-tree projects 
+* 878056f37b move id check to lib.sh too 
+* 3900642471 move root check to lib.sh (bugfix) 
+* 740b1803fa bugfix: move dependencies handling to lib.sh 
+* 4e25e335ed bump untitled revision again 
+* 44ef38b335 bump untitled revision in git config 
+* 7b9431e336 lib.sh bugfix: check environmental variables right 
+* 2478252f67 lib.sh: more friendly output from e() 
+* d21fd016ac badcmd: don't print "no context given" 
+* 663de3bab4 badcmd: link directly to the maintenance manual 
+* 1d866d17d8 better help text on invalid commands 
+* 1204bc3c96 build: print the project website address on help 
+* ca0e9354f6 add projectsite file: point to canoeboot.org 
+* eb4ac3c334 make GRUB multi-tree and re-add xhci patches 
+* 347a104ae6 u-boot on qemu: remove currently unused x86 target 
+* 23e66c113d grub.cfg: scan /boot/grub.cfg last 
+* 6151316b91 grub.cfg: scan grub2/ last 
+* 36b3be95cf grub.cfg: search a reduced list of devs/partitions 
+* 71a17efc06 grub.cfg: scan grub.cfg from ESP 
+* 8bc7e3a539 grub.cfg: split up try_user_config 
+* cb4bacc9d9 grub.cfg: don't search for *_grub.cfg 
+* ea7e6e1659 grub.cfg: remove unnecessary path for isolinux 
+* 1beca3b781 grub.cfg: don't scan EFI on btrfs subvols 
+* 0662519cca Fix building vboot on i686 
+* 224dce632b git.sh: do not remove .submodules 
+* a36504aa31 delete u-boot test/lib/strlcat.c using nuke() 
+* cdce8ba70b make nuke function more generic 
+* 2c1f6f5e7a do not allow dashes in coreboot target names 
+* 7dc5d35929 roms: allow user override of grub_scan_disk 
+* bcb65846d3 grub.cfg: actually support setting boot order 
+* 2887b77ae4 trees: use CPUS=x on regular coreboot make 
+* a056583762 update gitignore 
+* 1ac4f7409e roms: fix bad eval when comparing options 
+* 724dbfe0ce grub.cfg: add spdx header 
+* 66f5faac73 re-configure grub_scan_disk on various targets 
+* bb92776943 remove grub_scan_disk in all target.cfg files 
+* 935447b035 grub.cfg: use grub_scan_disk to set boot order 
+* 75b6fbf302 GRUB: remove XHCI patches for now (will re-add) 
+* 07340d9711 minor correction 
+* 9f489b43d5 roms: make grubfirst if seabios_withgrub=y 
+* fca9b19e18 coreboot: only run GRUB as a secondary payload 
+* b75490f8fc flashprog: bump to 5b4fdd1 from 2 May 2024 
+* d147c5d915 rename include/option.sh to include/lib.sh 
+* f534b0e973 merge nuke() back into git.sh 
+* a02b152f44 rename nukeblobs to a more generic name 
+* cb1918c5d7 roms: remove errant reference 
+* 4cff3c7d33 roms: rename bstr variable 
+* dc487df12f git.sh: remove errant whitespace 
+* cbb2f4f8a9 general code cleanup in the build system 
+* 583135e548 build: simplify git_init() 
+* aaff90f5a5 build: do root check before git check 
+* 687fdacc78 build: simplify git checks 
+* 84ee6a1ed8 option.sh: fix bad check for version/versiondate 
+* 3554593fd8 trees: reset makeargs per target/project 
+* b09261a901 trees: also use UPDATED_SUBMODULES=1 on crossgcc 
+* 698548ac59 trees: add UPDATED_SUBMODULES to coreboot make 
+* c8c516703f trees: write -C on the make command first not last 
+* aa15eef32f config: add backup coreboot submodule repositories 
+* 9e88ef2449 coreboot/default: remove chromeec from module.list 
+* 27f21c32d3 git.sh: break if a submodule clone succeeds 
+* 38fca598fb coreboot: only download the necessary submodules 
+* b5aa8b2d35 git.sh: allow finer control of git submodules 
+* 9339c6f3fd build: hide git-init output 
+* 31e089aff3 option.sh: generate version file if .git not found 
+* 7ec023907b update/trees: remove unused variable 
+* 2b0e71412e git.sh: move repo copying to a new function 
+* d71c4d326e git.sh: move link_crossgcc to end of file 
+* 0d7c249c9b move deblob function to new file "deblob.sh" 
+* 1300f09e67 git.sh: move xgcc linking to a new function 
+* 24934e6569 git.sh: don't include --checkout in submodules 
+* 5e0129eb0f git.sh: skip submodules if .gitmodules missing 
+* 7f82622caf git.sh: merge patch_submodules in prep_submodules 
+* 9c0a7f14fc git.sh: split submodule handling to new function 
+* b593127795 git.sh: remove errant line break 
+* 19f694bf2a git.sh: remove another meaningless check 
+* 71a9fcced8 git.sh: shorter variable names 
+* 6693588857 git.sh: remove meaningless check 
+* 5c459ad4ac git.sh: remove variable not meaningfully used 
+* 7be7bb8edb add CHANGELOG to .gitignore 
+* 3b2ebda890 Fix E6400 display reference clock patches 
+* 995f052bb0 fix building coreboot images on i686 hosts 
+* 31d2c818eb Also try unlocking encrypted volume on NVMe 
+* 58f6741fb4 git.sh: fix invalid command in git_prep() 
+* f58b01c300 Add NVMe support to GRUB2 payload 
+* b892036edf Fix E6400 display issue with 1440 x 900 panel 
+* f81c7ed8e9 Add pt qwerty keymap to lbmk 
+* 849466c0ac git.sh: allow patching submodules 
+* 8d4d063ace git.sh: don't delete .git if src/project/project 
+* 0ecb062df0 build/roms: skip target if config/ dir missing 
+* 4783c5b90e more minor cleanup in the build system 
+* 10ecf41ee0 git.sh: remove fetch_from_upstream() 
+* ddcb793bd2 option.sh: don't return 1 in mkrom_tarball 
+* ae8637b620 option.sh: mktar_release to mkrom_tarball 
+* 309c3b1f33 build/roms: rename moverom to copyrom 
+* a39c95cfac minor code cleanup in the build system 
+* f102e21ab6 build/roms: simplify serprog list command 
+* 7a565c9f43 build/roms: simplified config payload checks 
+* a243dc2308 option.sh: err if config directory is missing 
+* c28166ff9e option.sh: print the config filename being checked 
+* 9fd504e24a git.sh: Remove .git if XBMK_RELEASE=y 
+* e4956478db build: remove initcmd() and simplify main() 
+* f2b3bb142d build: initialise git first (before commands) 
+* 571932d33e build: remove excmd() and simplify main() 
+* 525f5525d3 build: don't make script_path a global variable 
+* fbac2d8fe6 Implemented failsafe options at boot and inside menus for enabling/disabling serial, spkmodem and gfxterm 
+* 3e5db248dd cbmk: allow easier sync with lbmk 
+* e71189420f remove help commands (user should read docs) 
+* 23854de888 option.sh: delete check_git() 
+* 2c5f52ce29 build: define "xp" in the global variables 
+* 48c5c57cff build: simplify for loop in fetch_trees() 
+* c2baebc79a build: simplified downloads in fetch_trees() 
+* 18d0e53480 ./build release: don't do u-boot-only archives 
+* d8a923f766 build: use utc+0 when initialising git repo dates 
+* 0794127986 remove check_project() (always set variables) 
+* c8bc797f31 build: simplify deletions in fetch_trees() 
+* 363ec7512c build: delete mkversion() (just print relname) 
+* ae44676727 build/roms: clean up tarball handling 
+* 3469836f18 rm src/u-boot/*/test/lib/strlcat.c in u-boot 
+* c57dfefe91 build: remove mkrom_images 
+* 6ab8c2c446 build: use same tarball name on uboot-only release 
+* 21436c6a8f build/roms: create full release tarball name 
+* 90c528032b option.sh: don't bother checking for GNU tar 
+* 422d36a07c option.sh: remove insert_version_files() 
+* ca1806f20e cleanup: remove mkvdir 
+* a0ea7f7a92 unified sha512sum creation for tarballs 
+* 09fcc343a3 move rom tarball creation to script/roms 
+* 5c888669c6 disable x301 for next release (for now) 
+* 91c90d763f print two line breaks before confirming release 
+* d423421995 remove all status checks. only handle release. 
+* 4826364afb git.sh: remove errant comment 
+* 541430016f move script/*/* to script/ 
+* 9084ab15ab build: print usage for special commands 
+* f12c2f284f merge script/update/release into build 
+* 41f4ee3c2d Canoeboot 20240510 release 
+* 0580373ff9 bump seabios to e5f2e4c69643bc3cd385306a9e5d29e11578148c 
+* 17b5cb2749 further modify the README (stragglers) 
+* 628e91a3b9 build: further prevent non-cbmk-work-directory 
+* e761a494c8 build: exit if not running from cbmk directory 
+* eb8a02e808 build/roms: print serprog help 
+* a398011180 merge script/build/serprog with script/build/roms 
+* cd5c2573ac build/roms: remove unnecessary command 
+* da748de455 merge include/err.sh with include/option.sh 
+* 3acac46536 err.sh: correct copyright info 
+* 6bdbb70dbc build/roms: don't rely on x in handle_target 
+* 1c84d0fc9d build/roms: don't use exit status from skip_board 
+* 0ada63b629 build/roms: split up main() 
+* 5cecd9e394 build/roms: allow searching status by mismatch 
+* 97d502ccc8 tone the README way, way down 
+```
+
+This is 206 changes, since Canoeboot 20240504.

site/news/gnu.md

@@ -0,0 +1,962 @@
+% Should Canoeboot become GNU Canoeboot?
+% Leah Rowe in GNU Leah Mode™
+% 12 May 2024
+
+**UPDATE ON 12 JUNE 2024: Please do not use Canoeboot 20240504 or 20240510
+because there were problems with these releases. Use
+the [Canoeboot 20240612 release](canoeboot20240612.md) instead, which contains
+a series of bug fixes that correct the issues from May 2024 releases. More
+information is available in the Canoeboot 20240612 announcement.**
+
+And now, without further ado:
+
+Original article
+================
+
+Should it? That is the question I emailed to GNU's evaluation team today.
+
+In it, I make a strong case in support of membership, and I encourage members
+of the public to also voice their opinions about this topic. Therefore, I have
+publicised this link in several places:
+
+What is Canoeboot?
+==================
+
+The *Canoeboot* project provides
+[free](https://writefreesoftware.org/learn) (*libre*) boot
+firmware based on coreboot, replacing proprietary BIOS/UEFI firmware
+on [specific Intel/AMD x86 and ARM based motherboards](docs/hardware/),
+including laptop and desktop computers. It initialises the hardware (e.g. memory
+controller, CPU, peripherals) and starts a bootloader for your operating
+system. [GNU+Linux](../docs/gnulinux/) and [BSD](../docs/bsd/) are well-supported. Help is
+available via [\#canoeboot](https://web.libera.chat/#canoeboot)
+on [Libera](https://libera.chat/) IRC.
+
+Canoeboot is a *special fork* of LIbreboot, maintained in parallel to it.
+Canoeboot adheres to the GNU Free System Distribution Guidelines, ensuring
+that everything in the flash is *free software*. Canoeboot *only* supports a
+very limited subset of hardware from coreboot (which it uses for initialisation)
+due to this policy, but it's provided for the purists who only want free
+software.
+The right to study, share, modify and use software freely without restrictions
+is a fundamental right that everyone *must* have.
+
+The benefit of Canoeboot is that it provides a completely
+automated build process and installation procedure, with well-tested builds
+released on a regular basis that the user can simply install, with minimal
+fuss. You can think of it as a *coreboot distro*. Coreboot provides snapshot
+source code archives every few months, but that's it. Canoeboot gives
+you the ROM images pre-compiled, with source code, and with payloads
+already pre-configured. In other words: Canoeboot makes coreboot
+extremely easy to use.
+
+More info about Canoeboot's design can be found in the [build system
+documentation](../docs/maintain/).
+
+Thoughts welcome!
+=================
+
+I asked this question in various places, where you can comment:
+
+Thread on FSF LibrePlanet mailing list:
+<https://lists.gnu.org/archive/html/libreplanet-discuss/2024-05/msg00001.html>
+
+Thread on my Mastodon account:
+<https://mas.to/@libreleah/112428793049670713>
+
+Thread on Trisquel forums (FSF endorsed GNU+Linux distro, and de-facto stomping
+ground for many debates within the FSF community):
+
+<https://trisquel.info/en/forum/should-gnu-boot-become-gnu-canoeboot>
+
+And reddit: <https://www.reddit.com/r/linux/comments/1cqe924/should_canoeboot_become_gnu_canoeboot/>
+
+Email sent to GNU Eval
+======================
+
+Here is the email that I sent (replies to it will **not** be published, only
+my original email below will be):
+
+```
+Message-ID: <864f2dd0-3af8-4c01-8d9b-d4236b43b335@minifree.org>
+Date: Sun, 12 May 2024 15:50:42 +0100
+MIME-Version: 1.0
+User-Agent: Mozilla Thunderbird
+Content-Language: en-US
+From: Leah Rowe <info@minifree.org>
+Autocrypt: addr=info@minifree.org; keydata=
+ xsFNBGWN15sBEADECGPEe37tdU3xe7OshKU19xVOPuJRMveCO5DHfv/lsZMXLWXwMMpbG+2x
+ SMQZcdZc0HCUq6TQE9fU0rA3kcFz0miMOuB2WJbYy9guvg9pAjLa0LUyb2T/HPDDy0ifYtqr
+ OzwETwWRiWQcTHjJ0knwNReaEterpPki1MbK79EwSuQBIgq9lQ611qLn5SmE7sBRB5kze7q3
+ KdTvY/CTfvOpVizgRF8kqqG4r4XkI0dTyrvC3i3Eub3F3YPWNjN06rECG6wO+TPzRo7em+0C
+ dPYDgtqq4Srf050KNZsVt10Plty5VpJm2GfoXFh6SZBO1zSbBpTGU+7vBsR731ye2ouQdcIs
+ 06Qi4wHmJ71liqJwxZ0ju2F5edC7jDzdk4jAIaCiSiU+iGg28RsxoUdLkJl5Q4yW507Gr0ps
+ HIBJBAWJo1i75qKVhrmN25xjJLv0MjgaR7RgT1T7uuX1KPuo8NbHbRlkIv7987NeJzgbUzzp
+ ka2MJjTEd1ova9kPyICVmKCfBnT+bO3vfJAuQXRlf3qjXSLsxCD7Jmu07if0jXFIvjy/nC4H
+ 0QPlwd/sVS7Svfn4rEGEnulrtBvVdOr6I+LmDedbSsSlYNlqagdyGsdKZfWSGxhjfz4oAkVy
+ +y39s1qAnM5191m+u72dmnQPtxI8lEH/G+j+hK8NxDvV5ri3owARAQABzR1MZWFoIFJvd2Ug
+ PGluZm9AbWluaWZyZWUub3JnPsLBlAQTAQoAPhYhBIux99KM92ltv09xklxlQGfTg7H/BQJl
+ jdebAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEFxlQGfTg7H/PKoQAIB8
+ z2Rg+R0417YRTBXvbVG5kPpKOO3DWUaQCJx6uypBUpgw2giKDsDz59c2vNaADs7Zh5xQ+2bz
+ B+jkCjVSuzguApT3gxTnICvLeM72d5ZEF6Q8/YC6s9IiIHssCujbxtNN5yDU/Kn9Qd3gb+Bn
+ 9t/ZYT+L/SGLU3Zerq57lSt8ixU7JOvAolgqRzaPwTFvi1GPZbE5Gynj9riTxZc3KLFROWYN
+ iiO33T+X17TepTUaubkoA3DgWcQ6tw2dsJ8MT0DtZH8KlU/ufq0NBfFIw79uCQ+m/GbiW9Sm
+ KtppayLUJyJndlf5fQ/NaNJw9RS+yF5ellGKWWAwh+Drv0PITzJ1dLeWOF5degtyn9+HaMSM
+ RIs5G6m69UxZmLJ9TQF1Lt1u0l1EH7yHIAf69MX4nlcDIx6moIJgo2UJ9u2D7odDUKlPG8X4
+ lbc5cvGx9l/Hy6WF8dOYUiU1avU65uhggaNXGXC6JbDiChCeuWTnzKXqlvae8rU9jSpDBSQF
+ lOOgvi3NifDLM7xFByDtFabnJHniNO1B6kS0V0nv6sJlRuB584kQUQ+PaRUj8QvXjsLvYhxY
+ Tw2G7jzQkXEOBZq3jenVzAg5ejOB7mTNoZOYOWoFY7XDRUGOmGDvH2qQGVNhedhSBJilAiu6
+ K0NyjkaFAGufvgXDjLImPav/kWdbTDvNzsFNBGWN15sBEADj4Dhn29Z0LVU+B1Wc8U0wdV7N
+ bDIjbhEvJ0Yc+FTNorQq7avY9jTkGtcnKPUti6cJxuQOZPxaIzP1mMK9BlsGbB8bTJ7oqpsI
+ XuvGKOOZQMb7i+qEIfJw6ZAXSwuKq4xBciJU52WdX8OaSWJ6KZX74yrE1SXW+7yj3ENZNWuT
+ N2kAPF595XYpZwTAaJRy/ojfORu8WFXvo5osZJI1TlrJeDFecBntPkCgvI1VPTF3fUU3lGZc
+ 8rVascaGaJ6tBd5mTx/RrRyJrrJMEd1dca0MHV4WIDbNeINpbEhS2SbqOj/9q9z8tfmleqXV
+ jb+gKjSDpD8Nsxv9+2gq29tevMLqZ5R3NA4jj4rOnyIuq+YFtkZuBuEc04UX3ApixdAQ0jIN
+ hIBfT8YcMC+wwTvl4jG4Rhzrc4jOX8igOe9wkstbl7JxGJU28x4htskAyM2CMxPaUrorm64c
+ U2S0UoJGrvLfjItGud8dyM+RgtaO5wTFNO2A0dnq2/thIIgoEaiQfKMq2ilISsnf6x8as0FV
+ 3c7mGO8pDJlRwjoNg/89CMhxVbgO+5JQ+JHLfoMA++R+QaYy1ZLY51h5Ax6OtVWpZh67EuVD
+ Lx/5EFiyM25UTpqvH7t0ae2oLbAwQtIv1fRLhHP4aVSsP793of92/1lpybbpRD7/7ruVQ64d
+ +/N49db6mQARAQABwsF8BBgBCgAmFiEEi7H30oz3aW2/T3GSXGVAZ9ODsf8FAmWN15sCGwwF
+ CQlmAYAACgkQXGVAZ9ODsf8EqQ/8CjAQTza1pvd/GmKYHtldSA1odPB7AQkB+j4oyu5gDqtM
+ /fFRv3uGVYLcyZwC3XF69KL+NpcUYG22RQWokt+z3OiVYfP5LyKjXe2cPMS2cmyXBHEcCP8Q
+ SffNQNoC2VYzaVXH4P6cBVmkDG3yPtQ2cH1Al6jhMS4Fa0TCe6kgA7qROSoapdZuwbxEE7Fe
+ aYZIXQUBLpe2C6SexljD65DLhbDE5p4N56VbncO6IAqr9JQSlEXBgvgXGhXqfOmZkmCjXJU7
+ Sgy8sIyF4b1uEOkcWxUUfvfrO1yrcWyxvTlZdPCJy802B7UVFPWTbKwFoyIq5Lr8wk2npzAm
+ Dy/hKZlIV72Vk0eIcrTCfpbj0GehrIIYcpW7Z2IUtETNkyuQs+OScIdrP3PItajNwktQJrhz
+ +UGbF9MuT+CHuruhw5KzymkzcnEzCNaYvY4eG8IXP6VpX1GCs9eUvCWEnjP0OkmhQniWvS3v
+ AB7DfZSm0NAoDX0ZvNzzIRbiM5uhYqDUSIsmOwUiJLjveLysmIRaAc/K/Euml0obCUJfanD7
+ KSs7SZYp24ZTDNsvsWbsk1y8QvAGkZBfuykfRCMxsmGRyN2hS6H/ftttCUrj8Qn1/hJDBegE
+ UJgYDItHpE7KJeBHMFNUB2sTHPbzx+a5WPYxeYJevAeTwAg0/nRobXRzER7BLIU=
+To: gnueval@gnu.org
+Cc: ksiewicz@fsf.org, zoe@fsf.org, Mike Gerwitz <mtg@gnu.org>,
+ simon@josefsson.org, christian@grothoff.org, gnu-advisory@gnu.org,
+ rms@gnu.org, bob@proulx.com
+Subject: Should Canoeboot become GNU Canoeboot?
+Content-Type: multipart/signed; micalg=pgp-sha256;
+ protocol="application/pgp-signature";
+ boundary="------------QXCa2wGHkDkyD669GgjjqNUT"
+
+This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
+--------------QXCa2wGHkDkyD669GgjjqNUT
+Content-Type: multipart/mixed; boundary="------------K2qUk5UHVXzKPCuKPN8riXWW";
+ protected-headers="v1"
+From: Leah Rowe <info@minifree.org>
+To: gnueval@gnu.org
+Cc: ksiewicz@fsf.org, zoe@fsf.org, Mike Gerwitz <mtg@gnu.org>,
+ simon@josefsson.org, christian@grothoff.org, gnu-advisory@gnu.org,
+ rms@gnu.org, bob@proulx.com
+Message-ID: <864f2dd0-3af8-4c01-8d9b-d4236b43b335@minifree.org>
+Subject: Should Canoeboot become GNU Canoeboot?
+
+--------------K2qUk5UHVXzKPCuKPN8riXWW
+Content-Type: multipart/mixed; boundary="------------qXtx1QnbZel60GYrRxArVU6C"
+
+--------------qXtx1QnbZel60GYrRxArVU6C
+Content-Type: multipart/alternative;
+ boundary="------------0qkEOS0KaVvTlm4TzFss1Nsy"
+
+--------------0qkEOS0KaVvTlm4TzFss1Nsy
+Content-Type: text/plain; charset=UTF-8; format=flowed
+Content-Transfer-Encoding: base64
+
+SGkNCg0KVGhpcyBpcyBzZW50IHRvIEdOVSBFdmFsIHRlYW0sIGJ1dCBDQydkIHRvIG90aGVy
+cy4gTXkgbWFpbiByZWNpcGllbnQgaXMgdGhlIEdOVSBFdmFsIHRlYW0uDQoNCkkgd2FudCBH
+TlUgQ2Fub2Vib290LiBUaGlzIGlzIG15IG9mZmljaWFsIGNvbnRhY3Qgd2l0aCBHTlUsIGFz
+IHRoZSBsZWFkIGRldmVsb3BlciBhbmQgZm91bmRlciBvZiB0aGUgQ2Fub2Vib290IHByb2pl
+Y3QsIGEgZnVsbHkgZnJlZSBjb3JlYm9vdCBkaXN0cm8gYmFzZWQgb24gTGlicmVib290Lg0K
+DQpDYW5vZWJvb3QgaGFzIHJlY2VudGx5IHJlbW92ZWQgYWxsIG9wcG9zaXRpb24gdG8gdGhl
+IEZTRiBhbmQgZGVjaWRlZCB0byBzdGF1bmNobHkgcHJvbW90ZSBpdCBpbnN0ZWFkLCBpbiBh
+ZGRpdGlvbiB0byBGU0RHLiBUaGlzIGlzIHBhcnQgb2YgYSBnZW5lcmFsIGRlc2lyZSBJJ3Zl
+IGhhZCBzaW5jZSB0aGUgc3RhcnQgb2YgdGhlIHllYXIsIHRvIHNlZWsgcmVjb25jaWxsaWF0
+aW9uIHdpdGggdGhlIEZTRiBhbmQgR05VIHByb2plY3QsIGFmdGVyIHRoZSBkcmFtYSB0aGF0
+IGVuc3VlZCBmaXJzdCB3aXRoIGxpYnJlYm9vdC5vcmcgdnMgbGlicmVib290LmF0LCBhbmQg
+dGhlbiBsaWJyZWJvb3Qub3JnIHZzIEdOVSBCb290Lg0KDQpUaGlzIGNoYW5nZSBpcyBwZXJt
+YW5lbnQsIHdoZXRoZXIgR05VIGFjY2VwdHMgbXkgcHJvcG9zYWwgdG9kYXk7IGV2ZW4gaWYg
+Q2Fub2Vib290IGRvZXMgbm90IGJlY29tZSBHTlUgQ2Fub2Vib290LCBpdCB3aWxsIGNvbnRp
+bnVlIHRvIG9wZXJhdGUgYXMgaXQgZG9lcyBub3cuIEkgcmVjZW50bHkgZGlkIGEgcmVsZWFz
+ZSB3aGljaCBpcyBzdGF1bmNobHkgcHJvLUZTRi4gSSd2ZSBkb25lIHRoaXMsIHByZWNpc2Vs
+eSBiZWNhdXNlIEdOVSBCb290IGlzIG5vIGxvbmdlciBjb21wZXRpdGlvbiB0byBDYW5vZWJv
+b3QgaW4gYW55IHdheTsgR05VIEJvb3Qgc2VlbXMgdG8gaGF2ZSBzdGFsbGVkLCBzbyBDYW5v
+ZWJvb3QgaGFzLCB3aXRoIHRoaXMgbW92ZWQsIGVmZmVjdGl2ZWx5IHJlcGxhY2VkIGl0LiBJ
+IGRvbid0IHNheSB0aGlzIGFzIGFuIGF0dGFjaywgYnV0IGl0IGlzIGEgZmFjdCB0aGF0IEdO
+VSBCb290IGhhcywgYXMgSSB3cml0ZSB0aGlzLCBub3Qgc3VibWl0dGVkIGFueXRoaW5nIHRv
+IHRoZWlyIG1haW4gYnJhbmNoIGluIG92ZXIgNCBtb250aHMuIGl0J3Mgbm93IGEgZGVhZCBw
+cm9qZWN0LCBhbmQgQ2Fub2Vib290IGlzIHRha2luZyBvdmVyLg0KDQpJIGtub3cgR05VIEJv
+b3QgaXMgYWxyZWFkeSBhIHRoaW5nLiBJIGVudmlzaW9uIENhbm9lYm9vdCByZXBsYWNpbmcg
+aXQuIE5vdywgYW5zd2VycyB0byBxdWVzdGlvbnMgZnJvbSBnbnVldmFsIGZvcm06DQoNCiog
+R2VuZXJhbCBJbmZvcm1hdGlvbg0KKiogRG8geW91IGFncmVlIHRvIGZvbGxvdyBHTlUgcG9s
+aWNpZXM/DQogICAgSWYgeW91ciBwcm9ncmFtIGlzIGFjY2VwdGVkIHRvIGJlIHBhcnQgb2Yg
+dGhlIEdOVSBzeXN0ZW0sIGl0IG1lYW5zDQogICAgdGhhdCB5b3UgYmVjb21lIGEgR05VIG1h
+aW50YWluZXIsIHdoaWNoIGluIHR1cm4gbWVhbnMgdGhhdCB5b3Ugd2lsbA0KICAgIG5lZWQg
+dG8gZm9sbG93IEdOVSBwb2xpY2llcyBpbiByZWdhcmRzIHRvIHRoYXQgR05VIHByb2dyYW0u
+DQogICAgKFN1bW1hcml6ZWQgYWJvdmUsIHNlZSBtYWludGFpbmVycyBkb2N1bWVudCBmb3Ig
+ZnVsbCBkZXNjcmlwdGlvbnMuKQ0KDQpZZXMuIENhbm9lYm9vdCBhbHJlYWR5IGNvbXBsaWVz
+IGZ1bGx5IHdpdGggdGhlIEdOVSBGcmVlIFN5c3RlbSBEaXN0cmlidXRpb24gR3VpZGVsaW5l
+cy4gVGhlcmUgbWF5IGJlIGEgZmV3IHN0cmFnZ2xlcnMgbGVmdCBvdmVyIGZyb20gd2hlbiBp
+dCBmb3JrZWQgZnJvbSBMaWJyZWJvb3QsIGJ1dCB0aGVzZSB3aWxsIHN1cmVseSBiZSBmb3Vu
+ZCBkdXJpbmcgcmV2aWV3Lg0KDQpJJ3ZlIGFscmVhZHkgZG9uZSBleHRlbnNpdmUgYXVkaXRp
+bmcgbXlzZWxmLCBhcyBoYXMgQ3JhaWcgVG9waGFtIGluIGhpcyBjYXBhY2l0eSBhcyBMaWNl
+bnNpbmcgYW5kIENvbXBsaWFuY2Ugb2ZmaWNlciBhdCB0aGUgRlNGLiAoQ2Fub2Vib290IDIw
+MjMgcmVsZWFzZXMgd2VyZSBhdWRpdGVkKQ0KDQoqKiBQYWNrYWdlIG5hbWUgYW5kIHZlcnNp
+b246DQoNCkNhbm9lYm9vdCAyMDI0MDUxMA0KDQoqKiBBdXRob3IgRnVsbCBOYW1lIDxFbWFp
+bD46DQoNCkxlYWggUm93ZTxpbmZvQG1pbmlmcmVlLm9yZz4NCg0KKiogVVJMIHRvIHBhY2th
+Z2UgaG9tZSBwYWdlIChpZiBhbnkpOg0KDQpodHRwczovL2Nhbm9lYm9vdC5vcmcvDQoNCioq
+IFVSTCB0byBzb3VyY2UgdGFyYmFsbDoNCiAgICAgUGxlYXNlIG1ha2UgYSByZWxlYXNlIHRh
+cmJhbGwgZm9yIHB1cnBvc2VzIG9mIGV2YWx1YXRpb24sIHdoZXRoZXINCiAgICAgb3Igbm90
+IHlvdSBwdWJsaWNseSByZWxlYXNlIGl0LiAgSWYgeW91IGRvbid0IGhhdmUNCiAgICAgYW55
+d2hlcmUgdG8gdXBsb2FkIGl0LCBzZW5kIGl0IGFzIGFuIGF0dGFjaG1lbnQuDQoNCmh0dHBz
+Oi8vd3d3Lm1pcnJvcnNlcnZpY2Uub3JnL3NpdGVzL2xpYnJlYm9vdC5vcmcvcmVsZWFzZS9j
+YW5vZWJvb3QvMjAyNDA1MTAvY2Fub2Vib290LTIwMjQwNTEwX3NyYy50YXIueHoNCg0KTk9U
+RTogU2V2ZXJhbCBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIHNpbmNlIHRoYXQgcmVsZWFzZS4g
+Q2hlY2sgdGhlIGdpdCBsb2cgZm9yIGNid3d3LmdpdCBhbmQgY2Jtay5naXQgLSBzb21lIG9m
+IHRoZXNlIGFyZSByZWxldmFudCBhcyBwYXJ0IG9mIGV2YWx1YXRpb24gKEkgZml4ZWQgc2V2
+ZXJhbCBpc3N1ZXMgYWxyZWFkeSwgdGhhdCB5b3UncmUgbGlrZWx5IHRvIGZsYWcgaW4gdGhl
+IHRhcmJhbGwpLg0KDQoqKiBCcmllZiBkZXNjcmlwdGlvbiBvZiB0aGUgcGFja2FnZToNCg0K
+VGhlIC9DYW5vZWJvb3QvIHByb2plY3QgcHJvdmlkZXMgZnJlZSANCjxodHRwczovL3dyaXRl
+ZnJlZXNvZnR3YXJlLm9yZy9sZWFybj4gKC9saWJyZS8pIGJvb3QgZmlybXdhcmUgYmFzZWQg
+b24gDQpjb3JlYm9vdCwgcmVwbGFjaW5nIHByb3ByaWV0YXJ5IEJJT1MvVUVGSSBmaXJtd2Fy
+ZSBvbiBzcGVjaWZpYyBJbnRlbC9BTUQgDQp4ODYgYW5kIEFSTSBiYXNlZCBtb3RoZXJib2Fy
+ZHMgPGh0dHBzOi8vY2Fub2Vib290Lm9yZy9kb2NzL2hhcmR3YXJlLz4sIA0KaW5jbHVkaW5n
+IGxhcHRvcCBhbmQgZGVza3RvcCBjb21wdXRlcnMuIEl0IGluaXRpYWxpc2VzIHRoZSBoYXJk
+d2FyZSANCihlLmcuwqBtZW1vcnkgY29udHJvbGxlciwgQ1BVLCBwZXJpcGhlcmFscykgYW5k
+IHN0YXJ0cyBhIGJvb3Rsb2FkZXIgZm9yIA0KeW91ciBvcGVyYXRpbmcgc3lzdGVtLiBHTlUr
+TGludXggPGh0dHBzOi8vY2Fub2Vib290Lm9yZy9kb2NzL2dudWxpbnV4Lz4gDQphbmQgQlNE
+IDxodHRwczovL2Nhbm9lYm9vdC5vcmcvZG9jcy9ic2QvPiBhcmUgd2VsbC1zdXBwb3J0ZWQu
+IEhlbHAgaXMgDQphdmFpbGFibGUgdmlhICNjYW5vZWJvb3QgPGh0dHBzOi8vd2ViLmxpYmVy
+YS5jaGF0LyNjYW5vZWJvb3Q+IG9uIExpYmVyYSANCjxodHRwczovL2xpYmVyYS5jaGF0Lz4g
+SVJDLg0KDQoNCiogQ29kZQ0KKiogRGVwZW5kZW5jaWVzOg0KICAgICBQbGVhc2UgbGlzdCB0
+aGUgcGFja2FnZSdzIGRlcGVuZGVuY2llcyAoc291cmNlIGxhbmd1YWdlLCBsaWJyYXJpZXMs
+IGV0Yy4pLg0KDQpDYW5vZWJvb3QgYnVpbGQgc3lzdGVtIChjYm1rKSB3cml0dGVuIGluIFBP
+U0lYIHNoZWxsIHNjcmlwdHMgKHNoKQ0KDQpVdGlscyAodXRpbC8pIHdyaXR0ZW4gaW4gYSBt
+aXggb2YgQyBhbmQgR28NCg0KVXBzdHJlYW0gcHJvamVjdHMgc3VjaCBhcyBjb3JlYm9vdCwg
+R1JVQiwgU2VhQklPUyBsYXJnZWx5IHdyaXR0ZW4gaW4gQywgd2l0aCBhIGJpdCBvZiBHbyBh
+bmQgcHl0aG9uLCBhbHNvIGEgbWlsZCBzZWFzb25pbmcgb2YgeDg2IGFzc2VtYmx5IGxhbmd1
+YWdlLCBpbiBhIGZldyBjYXNlcy4NCg0KKiogQ29uZmlndXJhdGlvbiwgYnVpbGRpbmcsIGlu
+c3RhbGxhdGlvbjoNCiAgICAgSXQgbWlnaHQgb3IgbWlnaHQgbm90IHVzZSBBdXRvY29uZi9B
+dXRvbWFrZSwgYnV0IGl0IG11c3QgbWVldCBHTlUNCiAgICAgc3RhbmRhcmRzLiAgRXZlbiBw
+YWNrYWdlcyB0aGF0IGRvIG5vdCByZXF1aXJlIGNvbXBpbGF0aW9uDQogICAgIG11c3QgZm9s
+bG93IHRoZXNlIHN0YW5kYXJkcywgc28gaW5zdGFsbGVycyBoYXZlIGEgdW5pZm9ybSB3YXkg
+dG8NCiAgICAgZGVmaW5lIHRhcmdldCBkaXJlY3RvcmllcywgZXRjLiAgUGxlYXNlIHNlZToN
+CiAgICAgaHR0cDovL3d3dy5nbnUub3JnL3ByZXAvc3RhbmRhcmRzL2h0bWxfbm9kZS9Db25m
+aWd1cmF0aW9uLmh0bWwNCiAgICAgaHR0cDovL3d3dy5nbnUub3JnL3ByZXAvc3RhbmRhcmRz
+L2h0bWxfbm9kZS9NYWtlZmlsZS1Db252ZW50aW9ucy5odG1sDQoNCkRvZXMgbm90IG1lZXQg
+c3RhbmRhcmRzIGF0IGFsbCwgYnV0IG5laXRoZXIgZG9lcyBHTlUgQm9vdCBhbmQgbmVpdGhl
+ciBkaWQgdGhlIGVyc3R3aGlsZSBHTlUgTGlicmVib290OyBpdCB3YXMgYWNjZXB0ZWQgYm90
+aCB0aGVuIGFuZCBub3cgdGhhdCB0aGUgZGVzaWduIGlzIGRpZmZlcmVudCwgYnV0IHRoYXQg
+R05VIG5lZWRlZCBhIHZpYWJsZSBGU0RHLWNvbXBsaWFudCBjb3JlYm9vdCBkaXN0cm8uDQoN
+ClRoZSBDYW5vZWJvb3QgYnVpbGQgc3lzdGVtIGlzIGRvY3VtZW50ZWQgaGVyZToNCg0KaHR0
+cHM6Ly9jYW5vZWJvb3Qub3JnL2RvY3MvbWFpbnRhaW4vDQoNCioqIERvY3VtZW50YXRpb246
+DQogICAgIFdlIHJlcXVpcmUgdXNpbmcgVGV4aW5mbyAoaHR0cDovL3d3dy5nbnUub3JnL3Nv
+ZnR3YXJlL3RleGluZm8vKQ0KICAgICBmb3IgZG9jdW1lbnRhdGlvbiwgYW5kIHJlY29tbWVu
+ZCB3cml0aW5nIGJvdGggcmVmZXJlbmNlIGFuZCB0dXRvcmlhbA0KICAgICBpbmZvcm1hdGlv
+biBpbiB0aGUgc2FtZSBtYW51YWwuICBQbGVhc2Ugc2VlDQogICAgIGh0dHA6Ly93d3cuZ251
+Lm9yZy9wcmVwL3N0YW5kYXJkcy9odG1sX25vZGUvR05VLU1hbnVhbHMuaHRtbA0KDQpQYW5k
+b2MgTWFya2Rvd24gaXMgdXNlZC4gU2VlOiBjYnd3dy5naXQNCg0KVGhlIFVudGl0bGVkIFN0
+YXRpYyBTaXRlIEdlbmVyYXRvciBpcyB1c2VkIHRvIGdlbmVyYXRlIGl0Lg0KDQpUaGlzIGlz
+IHdoYXQgR05VIEJvb3QgYWxzbyB1c2VzLCBhbmQgaXQgaGFzIE1hcmtkb3duLCBhbmQgd2Fz
+IGFjY2VwdGVkLg0KDQoqKiBJbnRlcm5hdGlvbmFsaXphdGlvbjoNCiAgICAgSWYgeW91ciBw
+YWNrYWdlIGhhcyBhbnkgdXNlci12aXNpYmxlIHN0cmluZ3MsIHBsZWFzZSBtYWtlIHRoZW0N
+CiAgICAgdHJhbnNsYXRhYmxlIHRvIG90aGVyIGxhbmd1YWdlcyB1c2luZyBHTlUgR2V0dGV4
+dDoNCiAgICAgaHR0cDovL3d3dy5nbnUub3JnL3NvZnR3YXJlL2dldHRleHQvDQoNCk5vIGkx
+OG4sIGJ1dCB0aGVyZSBhcmUgdHJhbnNsYXRpb25zIG9mIGNlcnRhaW4gcGFnZXMgb24gdGhl
+IHdlYnNpdGUsIG1haW50YWluZWQgbWFudWFsbHkuDQoNClNvbWUgb2YgdGhlIHBhY2thZ2Vz
+IHRoYXQgQ2Fub2Vib290IHVzZXMgbWF5IGhhdmUgaTE4biwgc3VjaCBhcyBHTlUgR1JVQi4N
+Cg0KKiogQWNjZXNzaWJpbGl0eToNCiAgICAgUGxlYXNlIGRpc2N1c3MgYW55YWNjZXNzaWJp
+bGl0eSBpc3N1ZXMgIDxodHRwczovL3d3dy5nbnUub3JnL2FjY2Vzc2liaWxpdHkvYWNjZXNz
+aWJpbGl0eS5odG1sPg0KICAgICB3aXRoIHlvdXIgcGFja2FnZSwgc3VjaCBhcyB1c2Ugb2Yg
+cmVsZXZhbnQgQVBJcy4NCg0KQWNjZXNzaWJpbGl0eSBpc3N1ZXM6IG5vIHNjcmVlbiByZWFk
+ZXIgaW4gdGhlIEdSVUIvU2VhQklPUyBib290IG1lbnUsIHRob3VnaCBHUlVCIChjb3JlYm9v
+dCBwYXlsb2FkIG9mdGVuIHVzZWQgb24gQ2Fub2Vib290IGluc3RhbGxhdGlvbnMpIGhhcyBh
+IG1vcnNlIGNvZGUgZ2VuZXJhdG9yIHdoaWNoIEkgY291bGQgcHJvYmFibHkgcmUtcHVycG9z
+ZSBmb3IgYmxpbmQgdXNlcnMuDQoNCioqIFNlY3VyaXR5Og0KICAgICBQbGVhc2UgZGlzY3Vz
+cyBhbnkgcG9zc2libGUgc2VjdXJpdHkgaXNzdWVzIHdpdGggeW91ciBwYWNrYWdlOg0KICAg
+ICBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgYmVpbmcgdXNlZCwgc2Vuc2l0aXZlIGRhdGEg
+YmVpbmcgc3RvcmVkLA0KICAgICBwb3NzaWJsZSBlbGV2YXRpb24gb2YgcHJpdmlsZWdlcywg
+ZXRjLg0KDQpObyBpc3N1ZXMgdGhhdCBJIGNhbiB0aGluayBvZi4NCg0KQ2Fub2Vib290IGFj
+dHVhbGx5IGltcHJvdmVzIHRoZSBzZWN1cml0eSBvbiBzb21lIG9mIGl0cyBwYWNrYWdlcy4g
+Rm9yIGV4YW1wbGUgaXQgYWRkcyBBcmdvbjIgS0RGIHN1cHBvcnQgdG8gR05VIEdSVUIsIHNv
+IHRoYXQgeW91IGNhbiBib290IGZyb20gTFVLUzIgZm9ybWF0dGVkIC9ib290IHBhcnRpdGlv
+bnMuDQoNCiogTGljZW5zaW5nOg0KICAgIEJvdGggdGhlIHNvZnR3YXJlIGl0c2VsZiAqYW5k
+IGFsbCBkZXBlbmRlbmNpZXMqICh0aGlyZC1wYXJ0eQ0KICAgIGxpYnJhcmllcywgZXRjLikg
+bXVzdCBiZSBmcmVlIHNvZnR3YXJlIGluIG9yZGVyIHRvIGJlIGluY2x1ZGVkIGluDQogICAg
+R05VLiAgSW4gZ2VuZXJhbCwgb2ZmaWNpYWwgR05VIHNvZnR3YXJlIHNob3VsZCBiZSByZWxl
+YXNlZCB1bmRlciB0aGUNCiAgICBHTlUgR1BMIHZlcnNpb24gMyBvciBhbnkgbGF0ZXIgdmVy
+c2lvbiwgYW5kIEdOVSBkb2N1bWVudGF0aW9uIHNob3VsZA0KICAgIGJlIHJlbGVhc2VkIHVu
+ZGVyIHRoZSBHTlUgRkRMIHZlcnNpb24gMS4zIG9yIGFueSBsYXRlciB2ZXJzaW9uLg0KDQpD
+YW5vZWJvb3QgYnVpbGQgc3lzdGVtIGxhcmdlbHkgR1BMdjMrLCBzb21lIHBhcnRzIGFyZSBH
+UEx2Mi1vbmx5Lg0KDQpDb3JlYm9vdCBpcyBsYXJnZWx5IEdQTHYyLg0KDQpHUlVCIGxhcmdl
+bHkgR1BMdjMrLCBzb21ldGltZXMgdjIrIG9yIHYyLW9ubHkNCg0KU2VhQklPUyBsYXJnZWx5
+IEdQTHYyLCB3aXRoIHNvbWUgdjMgc2Vhc29uaW5nDQoNCiAgICBQbGVhc2Ugc2VlaHR0cDov
+L3d3dy5nbnUub3JnL3BoaWxvc29waHkvbGljZW5zZS1saXN0Lmh0bWwgIGZvciBhDQogICAg
+cHJhY3RpY2FsIGd1aWRlIHRvIHdoaWNoIGxpY2Vuc2VzIGFyZSBmcmVlIChmb3IgR05VJ3Mg
+cHVycG9zZXMpIGFuZA0KICAgIHdoaWNoIGFyZSBub3QuICBQbGVhc2UgZ2l2ZSBzcGVjaWZp
+YyB1cmwncyB0byBhbnkgbGljZW5zZXMgaW52b2x2ZWQNCiAgICB0aGF0IGFyZSBub3QgbGlz
+dGVkIG9uIHRoYXQgcGFnZS4NCg0KTk9URTogQ2Fub2Vib290IGFscmVhZHkgbGlzdGVkIG9u
+IEZTRDoNCg0KaHR0cHM6Ly9kaXJlY3RvcnkuZnNmLm9yZy93aWtpL0Nhbm9lYm9vdA0KDQpG
+U0YncyBvd24gY3JhaWd0IGhlYXZpbHkgYXVkaXRlZCBpdCBvdmVyIGEgb25lLXdlZWsgcGVy
+aW9kLCBleHRlbnNpdmVseSBzY2FubmluZyBpdCBhbmQgdGhlbiBnb2luZyB0aHJvdWdoIGl0
+IGFsbCB3aXRoIG1lLg0KDQoqIFNpbWlsYXIgZnJlZSBzb2Z0d2FyZSBwcm9qZWN0czoNCiAg
+ICBQbGVhc2UgZXhwbGFpbiB3aGF0IG1vdGl2YXRlZCB5b3UgdG8gd3JpdGUgeW91ciBwYWNr
+YWdlLCBhbmQgc2VhcmNoDQogICAgYXQgbGVhc3QgdGhlIEZyZWUgU29mdHdhcmUgRGlyZWN0
+b3J5IChodHRwOi8vd3d3LmdudS5vcmcvZGlyZWN0b3J5LykNCiAgICBmb3IgcHJvamVjdHMg
+c2ltaWxhciB0byB5b3Vycy4gIElmIGFueSBleGlzdCwgcGxlYXNlIGFsc28gZXhwbGFpbg0K
+ICAgIHdoYXQgdGhlIHByaW5jaXBhbCBkaWZmZXJlbmNlcyBhcmUuDQoNCkdOVSBCb290DQoN
+CkkgaW50ZW5kIGZvciBDYW5vZWJvb3QgdG8gcmVwbGFjZSBHTlUgQm9vdCwgYW5kIGZvciBH
+TlUgQm9vdCB0byBiZSBkZWNvbW1pc3Npb25lZCwgc2luY2UgaXQgaXMgY3VycmVudGx5IGEg
+ZGVhZCBwcm9qZWN0OyBDYW5vZWJvb3QgaXMgdGhlIG9ubHkgRlNERyBjb21wbGlhbnQgY29y
+ZWJvb3QgZGlzdHJvIHVuZGVyIGFjdGl2ZSBkZXZlbG9wbWVudC4NCg0KSW4gYWRkaXRpb24s
+IGlmIGFjY2VwdGVkLCBJIHN1cHBvc2UgbGlicmVib290LmF0IHdvdWxkIGFsc28gYmUgcmVk
+aXJlY3RlZC4gQm90aCBsaWJyZWJvb3QuYXQgYW5kIEdOVSBCb290IHdvdWxkIHJlZGlyZWN0
+IHRvIENhbm9lYm9vdC4NCg0KVGhlIGN1cnJlbnQgR05VIEJvb3QgZGV2ZWxvcGVycyBhcmUg
+d2VsY29tZSB0byB3b3JrIHdpdGggbWUgYXMgY29udHJpYnV0b3JzIGlmIHRoZXkgd2lzaCwg
+YnV0IHRoZXkgbXVzdCBub3QgYmUgbWFkZSBtYWludGFpbmVycyBvZmZpY2lhbGx5OyBJIHdp
+bGwgYXNzdW1lIHRoYXQgcnVsZSBhcyBHTlUgQ2Fub2Vib290IG1haW50YWluZXIuDQoNCiog
+QW55IG90aGVyIGluZm9ybWF0aW9uLCBjb21tZW50cywgb3IgcXVlc3Rpb25zOg0KDQpodHRw
+czovL3RyaXNxdWVsLmluZm8vZW4vZm9ydW0vY2Fub2Vib290LTIwMjQwNTEwLXJlbGVhc2Vk
+LWdudS1mc2RnLWNvbXBsaWFudC0xMDAtZnJlZS1zb2Z0d2FyZS1jb3JlYm9vdC1kaXN0cm8t
+cmVwbGFjaW5nLXBybw0KDQpUaGlzIGxpbmsgY29udGFpbnMgZGlzY3Vzc2lvbiwgaW5jbHVk
+aW5nIGZyb20ganhzZWxmIChsZWFkaW5nIG1lbWJlciBvZiBHTlUgQWR2aXNvcnkgQ29tbWl0
+dGVlKS4gVGhlIHN1YnRleHQgaXMgR05VIENhbm9lYm9vdCwgYmVjYXVzZSBqeHNlbGYgd2Fz
+IGF3YXJlIG9mIG15IHBsYW4gd2hlbiBoZSBwb3N0ZWQgaGVyZS4NCg0KRWFybHkgZGF5cyB0
+aHVzIGZhciwgYnV0IHRoZSBnaXN0IGlzIHRoaXM6IENhbm9lYm9vdCBoYXMgZHJvcHBlZCAx
+MDAlIG9mIGl0cyBob3N0aWxpdHkgdG8gRlNGIGFuZCBJJ3ZlIGRlY2lkZWQgdGhhdCBpdCB3
+aWxsIHN0YXVuY2hseSAqc3VwcG9ydCogdGhlIEZTRiBpbnN0ZWFkLCBvcGVubHkgcHJvbW90
+aW5nIEdOVSBGU0RHIHBvbGljeSBhbmQgZW5jb3VyYWdpbmcgdGhlIHVzZSBvZiBGU0RHIGxp
+Y2Vuc2VkIGRpc3Ryb3Mgc3VjaCBhcyBUcmlzcXVlbC4gVGhpcyB3b3VsZCBiZSBqdXN0IGxp
+a2UgdGhlIGdvb2Qgb2xkIGRheXMgb2YgR05VIExpYnJlYm9vdCEgVGhpcyBjaGFuZ2UgaXMg
+cGVybWFuZW50Lg0KSSB3YXNuJ3QgZ29pbmcgdG8gbWFrZSB0aGlzIHJlcXVlc3QgdG8gZ251
+ZXZhbCwgYnV0IHNpbmNlIEdOVSBCb290IGlzbid0IHJlYWxseSBhIHRoaW5nIGFueW1vcmUg
+KG5vIGNvbW1pdHMgaW4gb3ZlciA0IG1vbnRocyBvbiB0aGVpciBtYWluIGJyYW5jaCwgYW5k
+IGdlbmVyYWxseSBzbG93IGRldmVsb3BtZW50IGJlZm9yZSB0aGVuKSwgSSB0aG91Z2h0OiB3
+aHkgbm90Pw0KDQpDYW5vZWJvb3QgaXMgYmVpbmcga2VwdCBzZXBhcmF0ZSBmcm9tIExpYnJl
+Ym9vdCBmcm9tIG5vdyBvbi4gSXQgbm8gbG9uZ2VyIHByb21vdGVzIExpYnJlYm9vdC4gV2hl
+biBJJ20gd29ya2luZyBvbiBDYW5vZWJvb3QsIEkgc2ltcGx5IGVudGVyIEdOVSBMZWFoIE1v
+ZGUsIHdoaWNoIGlzIGEgYnJhaW5tb2RlIHdoZXJlIEkgYmVsaWV2ZSBhYnNvbHV0ZWx5IGlu
+IGl0IGFuZCB3aWxsIHN0YW5kIGJ5IGl0IHRvIHRoZSB2ZXJ5IGVuZC4gSSdtIHJlYWxseSBn
+b29kIGF0IHRoYXQsIGFuZCBJIGFsc28gZGlkIHRoYXQgd2hlbiBHTlUgTGlicmVib290IHdh
+cyBhIHRoaW5nLg0KDQpJJ3ZlIGFscmVhZHkgc3Bva2VuIHRvIHNldmVyYWwgcGVvcGxlIHdo
+byBhcmUgaW5mbHVlbnRpYWwgc3VjaCBhcyBNaWtlIEdlcndpdHogYW5kIEJvYiBQcm91bHgs
+IGFuZCB0aGV5IGhhdmUgc2FpZCB0aGF0LCBpbiBwcmluY2lwbGUsIHRoZXkgc3VwcG9ydCB0
+aGlzIG1vdmUsIHRob3VnaCB0aGV5IGhhdmUgYWxzbyB0b2xkIG1lIHRoYXQgdGhleSB3aWxs
+IG5vdCBiZSBpbnZvbHZlZCAob2YgY291cnNlLCBpZiB0aGV5IGRvIHdhbnQgdG8sIEknZCBs
+aWtlIHRoYXQpLg0KDQpHTlUgQ2Fub2Vib290Lg0KDQpUaGF0IGlzIHdoYXQgSSB3YW50LCBh
+bmQgdGhhdCBpcyB3aGF0IEkgcHJvcG9zZS4gSSB3aWxsIGZvbGxvdyBhbGwgcnVsZXMgYW5k
+IGRvIHRoaW5ncyByaWdodC4NCg0KQWxzbzoNCg0KQW5vdGhlciBsaWJyZXhpdCAobGlicmVi
+b290IGV4aXQgZnJvbSBHTlUpIHdpbGwgbm90IG9jY3VyLiBDYW5vZWJvb3Qgd2lsbCBiZSBH
+TlUgZm9yZXZlciwgaWYgYWNjZXB0ZWQuIEkgbmV2ZXIgdG9sZCBhbnlvbmUgdGhpcyBiZWZv
+cmUsIGFuZCBpdCdzIG5vdCBhbiBleGNsdXNlLCBidXQgaXQgaXMgYSBtaXRpZ2F0aW5nIGZh
+Y3RvcjogSSB3YXMgZ29pbmcgdGhyb3VnaCBhIHZlcnkgZGlmZmljdWx0IHRpbWUgaW4gbXkg
+bGlmZSB3aGVuIExpYnJlYm9vdCBsZWZ0IEdOVSBhbGwgdGhvZXMgeWVhcnMgYWdvLiBJIHdh
+cyByZWd1bGFybHkgZHJpbmtpbmcsIGFuZCBJIHdhcyBkcnVuayB3aGVuIEkgb3JpZ2luYWxs
+eSBzZW50IHRob2VzIGhvc3RpbGUgbWVzc2FnZXMgdG8gR05VIGluIDIwMTYuIEknbSBub3Qg
+bGlrZSB0aGF0IGZvciB5ZWFycyBub3cuIEkgZG9uJ3QgZHJpbmsgYW55bW9yZSwgYW5kIEkg
+ZG9uJ3QgZG8gZHJ1Z3MgLSBhbmQgSSBoYXZlbid0IGRvbmUgc28gZm9yIG1hbnkgeWVhcnMg
+bm93Lg0KDQpUaGUgd2F5IEkgc2VlIGl0LCB0aGVyZSB3aWxsIGFsd2F5cyBiZSBhIGRlbWFu
+ZCBmb3IgYSBmdWxseSBmcmVlIGNvcmVib290IGRpc3RybywgYW5kIENhbm9lYm9vdCBpcyBj
+dXJyZW50bHkgdGhlIG9ubHkgdmlhYmxlIHByb2plY3QgaW4gdGhpcyByZWdhcmQuDQoNCkNh
+bm9lYm9vdCBpcyBzdXBlcmlvciB0byBHTlUgQm9vdCBmb3IgdGhlc2UgcmVhc29uczoNCg0K
+KiBNdWNoIG1vcmUgdXAgdG8gZGF0ZS4gVXNlcyBjb3JlYm9vdCwgR1JVQiBhbmQgU2VhQklP
+UyByZXZpc2lvbnMgZnJvbSAyMDI0LCB3aGVyZWFzIEdOVSBCb290IHVzZXMgcmV2cyBmcm9t
+IGxhdGUgMjAyMS4NCg0KKiBCdWlsZCBzeXN0ZW0gaXMgbW9yZSBlZmZpY2llbnQ6IDYgc2hl
+bGwgc2NyaXB0cyBpbnN0ZWFkIG9mIEdOVSBCb290J3MgNTAsIGFuZCBhYm91dCAxMzAwIGxp
+bmVzIG9mIGNvZGUgaW4gdGhlIGJ1aWxkIHN5c3RlbSwgdmVyc3VzIEdOVSBCb290J3MgfjUw
+MDAuIEdlbmVyYWxseSBjbGVhbmVyIGNvZGluZyBzdHlsZSBpbiBDYW5vZWJvb3QuDQoNCiog
+RGVzcGl0ZSBiZWluZyBzbWFsbGVyLCBDYW5vZWJvb3QgYWN0dWFsbHkgaGFzIG1vcmUgZmVh
+dHVyZXMuIFN1Y2ggYXMgYnVpbGRpbmcgb2Ygc2VycHJvZyBpbWFnZXMgKHRvIG1ha2UgY2hl
+YXAgU1BJIGZsYXNoZXJzKSwgc3VwcG9ydCBmb3IgYnVpbGRpbmcgVS1Cb290IHBheWxvYWQg
+b24gQVJNIGRldmljZXMgKGFuZCB0aGV5IGJvb3QpLCBhbmQgbW9yZSBoYXJkd2FyZSBzdXBw
+b3J0Lg0KDQoqIEkndmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgc3R1ZmYgZm9yIG92ZXIgMTAg
+eWVhcnMuIEkga25vdyBhbGwgdGhlIG5vb2tzIGFuZCBjcmFubmllcyBvZiBjb3JlYm9vdCwg
+YW5kIGhvdyB0byByZWFsbHkgbWFrZSB5b3VyIGJvb3Rsb2FkZXIgc2luZw0KDQoqIEdOVSBC
+b290IHVzZXMgTGlicmVib290J3Mgb2xkIGJ1aWxkIHN5c3RlbSBkZXNpZ24sIHdoaWNoIGlz
+IHdoeSBpdCdzIG11Y2ggYmlnZ2VyLiBJIGRpZCBhIHNlcmllcyBvZiBhdWRpdHMgaW4gMjAy
+MyB0byB2YXN0bHkgaW5jcmVhc2UgdGhlIGNvZGUgcXVhbGl0eSBpbiB0aGUgYnVpbGQgc3lz
+dGVtLg0KDQoqIEdOVSBCb290IGlzIGdvaW5nIHRvIGJlY29tZSBtb3JlIGNvbXBsZXgsIGJl
+Y2F1c2UgdGhleSB3YW50L3dhbnRlZCB0byByZXdyaXRlIGl0IGFsbCBpbiBHdWlsbGUgYW5k
+IHVzZSB0aGUgR1VpeCBwYWNrYWdlIG1hbmFnZXIgdG8gYnVpbGQgZXZlcnl0aGluZy4gV2hp
+bGUgdGhpcyB3b3VsZCBtYWtlIGluZGl2aWR1YWwgYnVpbGRpbmcgZWFzaWVyLCBpdCB3b3Vs
+ZCB2YXN0bHkgaW5jcmVhc2UgdGhlIG1haW50ZW5hbmNlIGJ1cmRlbiBhbmQgaW50cm9kdWNl
+IG1hbnkgbW92aW5nIHBhcnRzIHRvIHRoZSBwcm9qZWN0LCBtYWtpbmcgaXQgdW5tYWludGFp
+bmFibGUgb3ZlciB0aW1lLiBDYW5vZWJvb3QncyBkZXNpZ24gaXMgbXVjaCBzaW1wbGVyIGFu
+ZCBJJ20gYWxzbyB3b3JraW5nIG9uIGJvb3RzdHJhcHBpbmcgKGUuZy4gbXVzbC1jcm9zcy1t
+YWtlIGludGVncmF0aW9uKQ0KDQoqIEdOVSBCb290IGxhY2tzIG1hbnkgb2YgTGlicmVib290
+J3MgbmV3ZXIgc2VjdXJpdHkgZmVhdHVyZXMsIHN1Y2ggYXMgQXJnb24yIEtERiBzdXBwb3J0
+IGZvciBMVUtTMiBib290DQoNClNvLCBiYXNpY2FsbHksIENhbm9lYm9vdCBpcyBtdWNoIGVh
+c2llciBhbmQgYmV0dGVyLg0KDQpJIGFjdHVhbGx5IGRpZCBpbml0aWFsbHkgdHJ5IHRvIGhl
+bHAgR05VIEJvb3QgaW5zdGVhZC4gVGhlIHByb2JsZW0gd2l0aCBHTlUgQm9vdCBpcyB0aGF0
+IGl0J3MgYmFzZWQgb24gYSByZWFsbHkgb2xkIExpYnJlYm9vdCB2ZXJzaW9uIGFuZCBoYXNu
+J3QgYmVlbiBjaGFuZ2VkIG11Y2ggc2luY2UsIGFuZCB0aGV5J3ZlIGJhc2ljYWxseSBiZWVu
+IGluICJkZXZlbG9wbWVudCBoZWxsIi4gSSBzZW50IHRoZW0gZXh0ZW5zaXZlIHBhdGNoZXMg
+ZmdpeGluZyBidWlsZCBpc3N1ZXMsIHNvIHRoYXQgaXQgYnVpbGRzIG9uIG1vZGVybiBkaXN0
+cm9zLCBhbmRoIEkgc2VudCB0aGVtIHBhdGNoZXMgdXBkYXRpbmcgaXQgdG8gbmV3ZXIgdXBz
+dHJlYW0gcmV2aXNpb25zIGUuZy4gY29yZWJvb3QsIGJ1dCBub25lIG9mIG15IHBhdGNoZXMg
+d2VyZSByZXZpZXdlZC4gSSBkb24ndCB0aGluayB0aGUgY3VycmVudCBkZXZlbG9wZXJzIGFy
+ZSB1cCB0byB0aGUgdGFzaywgYW5kIHRoaXMgaXMgbm90IGFuIGluc3VsdDsgdGhleSB3b3Jr
+ZWQgdW5kZXIgbWUgYXMgTGlicmVib290IGNvbnRyaWJ1dG9ycyBpbiB0aGUgcGFzdCwgYW5k
+IHRoZXkgb25seSBldmVyIHdvcmtlZCBvbiBtaW5vciB0YXNrcywgdGhleSBuZXZlciBkaWQg
+YW55dGhpbmcgYmlnLiBJJ3ZlIHNhaWQgaW4gdGhlIHBhc3QgdGhhdCBwZXJoYXBzIEkgc2hv
+dWxkIGJlIGFwcG9pbnRlZCBhcyBsZWFkZXIgb2YgR05VIEJvb3QgaW5zdGVhZCwgYnV0IEkg
+aGF2ZSBteSBDYW5vZWJvb3QgcHJvamVjdCB3aGljaCBoYXMgc3VycGFzc2VkIGl0IHRlY2hu
+aWNhbGx5IGluIGV2ZXJ5IHdheSwgc28gbm93IEkgd2FudCBhIEdOVSBDYW5vZWJvb3QuDQoN
+ClVwY29taW5nIHdvcmsgb24gQ2Fub2Vib290Og0KDQoqIE1vcmUgQVJNIGNocm9tZWJvb2tz
+LCB3aGljaCBBbHBlciBOZWJpIFlhc2FrIChsaWJyZWJvb3QgZGV2ZWxvcGVyKSBpcyB3b3Jr
+aW5nIG9uDQoNCiogTW9yZSBEZWxsIExhdGl0dWRlcyAoR000NSBtb2R1bGVzKS4gSSdtIHdv
+cmtpbmcgb24gdGhlc2UsIGJhc2VkIG9uIHRoZSBEZWxsIEU2NDAwIHBvcnQNCg0KKiBNYXRl
+IEt1a3JpIChjb3JlYm9vdCBkZXZlbG9wZXIpIGlzIHdvcmtpbmcgb24gYW4gZXhwbG9pdCBv
+ZiBJbnRlbCBTQS0wMDA4NiB0byBnYWluIHVuc2lnbmVkIGNvZGUgZXhlY3V0aW9uIG9uIElu
+dGVsIE1FIHYxMSwgZm9yIFNreWxha2UgYm9hcmRzLCBidXQgSSdtIHRvbGQgdGhhdCBzaW1p
+bGFyIGV4cGxvaXRzIGFyZSBwb3NzaWJsZSBhbmQgd2lsbCBiZSB3b3JrZWQgb24sIGZvciBv
+bGRlciBzYW5keWJyaWRnZSwgaXZ5YnJpZGdlIGFuZCBoYXN3ZWxsIGhhcmR3YXJlIChlLmcu
+IFRoaW5rUGFkIFgyMjAsIFgyMzAsIFQ0NDBwKSAtIGN1cnJlbnRseSwgdGhlIG9ubHkgYmxv
+YnMgbmVlZGVkIG9uIHRob3NlIGJvYXJkcyBhcmUgSW50ZWwgTUUgYW5kIG1pY3JvY29kZSwg
+dGhvdWdoIHRoZXkgY2FuIGJvb3Qgd2l0aG91dCBtaWNyb2NvZGUuIFRoZXJlJ3MgYSBjaGFu
+Y2UgdGhhdCBpbiB0aGUgbmV4dCBmZXcgeWVhcnMsIHdlIHdpbGwgaGF2ZSB3aGF0IEkgY2Fs
+bCB0aGUgSW50ZWwgRnJlZWRvbSBFbmdpbmUsIGEgZnVsbCBmcmVlIHJlcGxhY2VtZW50IG9m
+IEludGVsIE1FLiBUaGlzIHdvdWxkIGJlY29tZSBwYXJ0IG9mIEdOVSwgaWYgR05VIGFjY2Vw
+dHMgQ2Fub2Vib290IHRvZGF5Lg0KDQoqIExpbnV4LWxpYnJlIHBheWxvYWQgd2l0aCBtdXNs
+IGxpYmMgYW5kIGJ1c3lib3gsIGFuZCBVLVJvb3QsIHRvIHByb3ZpZGUgYm9vdGluZyBvZiBs
+aW51eCBrZXJuZWxzIG9uIGRpc2sgYW5kIG92ZXIgdGhlIG5ldHdvcmssIGZyb20gdGhlIGZs
+YXNoLiAoR05VK0xpbnV4IHN5c3RlbSBpbiBmbGFzaCBiYXNpY2FsbHkpLCB3aXRoIG1hbnkg
+c2VjdXJpdHkgZmVhdHVyZXMgc3VjaCBhcyBtZWFzdXJlZCBib290LCBhbmQgbmF0aXZlIHN1
+cHBvcnQgZm9yIFpGUyBmaWxlIHN5c3RlbS4NCg0KU29tZSBvciBhbGwgb2YgdGhlIGFib3Zl
+LCBhbmQgbW9yZSwgd2lsbCBiZSBwcmVzZW50IGluIENhbm9lYm9vdCB0aGlzIHllYXIuDQoN
+ClNvIGhvdyBhYm91dCBpdD8NCg0KTWFueSBwZW9wbGUgd2lsbCBiZSBzdXJwcmlzZWQgYnkg
+dGhpcyBlbWFpbC4gQnV0IGlmIHlvdSBwdXQgeW91ciB0cnVzdCBpbiBtZSwgSSBwcm9taXNl
+IEkgd29uJ3QgZGlzYXBwb2ludC4gSSB3aWxsIG9mIGNvdXJzZSBtYWtlIGEgc2F2YW5uYWgg
+YWNjb3VudCBhcyBwYXJ0IG9mIHRoaXMsIGFuZCB1c2UgaXQsIGlmIGFjY2VwdGVkLg0KDQot
+LSANCkNvbXBhbnkgZGlyZWN0b3IsIE1pbmlmcmVlIEx0ZA0KUmVnaXN0ZXJlZCBpbiBFbmds
+YW5kLCBOby4gOTM2MTgyNiB8IFZBVCBOby4gR0IyMDIxOTA0NjINClJlZ2lzdGVyZWQgT2Zm
+aWNlOiAxOSBIaWx0b24gUm9hZCwgQ2FudmV5IElzbGFuZCwgRXNzZXggU1M4IDlRQSwgVUsN
+Cg0K
+--------------0qkEOS0KaVvTlm4TzFss1Nsy
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<!DOCTYPE html>
+<html>
+  <head>
+
+    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
+-8">
+  </head>
+  <body>
+    <pre>
+Hi
+
+This is sent to GNU Eval team, but CC'd to others. My main recipient is t=
+he GNU Eval team.
+
+I want GNU Canoeboot. This is my official contact with GNU, as the lead d=
+eveloper and founder of the Canoeboot project, a fully free coreboot dist=
+ro based on Libreboot.
+
+Canoeboot has recently removed all opposition to the FSF and decided to s=
+taunchly promote it instead, in addition to FSDG. This is part of a gener=
+al desire I've had since the start of the year, to seek reconcilliation w=
+ith the FSF and GNU project, after the drama that ensued first with libre=
+boot.org vs libreboot.at, and then libreboot.org vs GNU Boot.
+
+This change is permanent, whether GNU accepts my proposal today; even if =
+Canoeboot does not become GNU Canoeboot, it will continue to operate as i=
+t does now. I recently did a release which is staunchly pro-FSF. I've don=
+e this, precisely because GNU Boot is no longer competition to Canoeboot =
+in any way; GNU Boot seems to have stalled, so Canoeboot has, with this m=
+oved, effectively replaced it. I don't say this as an attack, but it is a=
+ fact that GNU Boot has, as I write this, not submitted anything to their=
+ main branch in over 4 months. it's now a dead project, and Canoeboot is =
+taking over.
+
+I know GNU Boot is already a thing. I envision Canoeboot replacing it. No=
+w, answers to questions from gnueval form:
+
+* General Information
+** Do you agree to follow GNU policies?
+   If your program is accepted to be part of the GNU system, it means
+   that you become a GNU maintainer, which in turn means that you will
+   need to follow GNU policies in regards to that GNU program.
+   (Summarized above, see maintainers document for full descriptions.)
+
+Yes. Canoeboot already complies fully with the GNU Free System Distributi=
+on Guidelines. There may be a few stragglers left over from when it forke=
+d from Libreboot, but these will surely be found during review.
+
+I've already done extensive auditing myself, as has Craig Topham in his c=
+apacity as Licensing and Compliance officer at the FSF. (Canoeboot 2023 r=
+eleases were audited)
+
+** Package name and version:
+
+Canoeboot 20240510
+
+** Author Full Name &lt;Email&gt;:
+
+Leah Rowe <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:info@minifree=
+=2Eorg">&lt;info@minifree.org&gt;</a>
+
+** URL to package home page (if any):
+
+<a class=3D"moz-txt-link-freetext" href=3D"https://canoeboot.org/">https:=
+//canoeboot.org/</a>
+
+** URL to source tarball:
+    Please make a release tarball for purposes of evaluation, whether
+    or not you publicly release it.  If you don't have
+    anywhere to upload it, send it as an attachment.
+
+<a class=3D"moz-txt-link-freetext" href=3D"https://www.mirrorservice.org/=
+sites/libreboot.org/release/canoeboot/20240510/canoeboot-20240510_src.tar=
+=2Exz">https://www.mirrorservice.org/sites/libreboot.org/release/canoeboo=
+t/20240510/canoeboot-20240510_src.tar.xz</a>
+
+NOTE: Several changes have been made since that release. Check the git lo=
+g for cbwww.git and cbmk.git - some of these are relevant as part of eval=
+uation (I fixed several issues already, that you're likely to flag in the=
+ tarball).
+
+** Brief description of the package:
+
+</pre>
+    <p>The <em>Canoeboot</em> project provides <a
+        href=3D"https://writefreesoftware.org/learn">free</a> (<em>libre<=
+/em>)
+      boot firmware based on coreboot, replacing proprietary BIOS/UEFI
+      firmware on <a href=3D"https://canoeboot.org/docs/hardware/">specif=
+ic
+        Intel/AMD x86 and ARM based motherboards</a>, including laptop
+      and desktop computers. It initialises the hardware (e.g.=C2=A0memor=
+y
+      controller, CPU, peripherals) and starts a bootloader for your
+      operating system. <a href=3D"https://canoeboot.org/docs/gnulinux/">=
+GNU+Linux</a>
+      and <a href=3D"https://canoeboot.org/docs/bsd/">BSD</a> are
+      well-supported. Help is available via <a
+        href=3D"https://web.libera.chat/#canoeboot">#canoeboot</a> on <a
+        href=3D"https://libera.chat/">Libera</a> IRC.</p>
+    <pre>
+
+* Code
+** Dependencies:
+    Please list the package's dependencies (source language, libraries, e=
+tc.).
+
+Canoeboot build system (cbmk) written in POSIX shell scripts (sh)
+
+Utils (util/) written in a mix of C and Go
+
+Upstream projects such as coreboot, GRUB, SeaBIOS largely written in C, w=
+ith a bit of Go and python, also a mild seasoning of x86 assembly languag=
+e, in a few cases.
+
+** Configuration, building, installation:
+    It might or might not use Autoconf/Automake, but it must meet GNU
+    standards.  Even packages that do not require compilation
+    must follow these standards, so installers have a uniform way to
+    define target directories, etc.  Please see:
+    <a class=3D"moz-txt-link-freetext" href=3D"http://www.gnu.org/prep/st=
+andards/html_node/Configuration.html">http://www.gnu.org/prep/standards/h=
+tml_node/Configuration.html</a>
+    <a class=3D"moz-txt-link-freetext" href=3D"http://www.gnu.org/prep/st=
+andards/html_node/Makefile-Conventions.html">http://www.gnu.org/prep/stan=
+dards/html_node/Makefile-Conventions.html</a>
+
+Does not meet standards at all, but neither does GNU Boot and neither did=
+ the erstwhile GNU Libreboot; it was accepted both then and now that the =
+design is different, but that GNU needed a viable FSDG-compliant coreboot=
+ distro.
+
+The Canoeboot build system is documented here:
+
+<a class=3D"moz-txt-link-freetext" href=3D"https://canoeboot.org/docs/mai=
+ntain/">https://canoeboot.org/docs/maintain/</a>
+
+** Documentation:
+    We require using Texinfo (<a class=3D"moz-txt-link-freetext" href=3D"=
+http://www.gnu.org/software/texinfo/">http://www.gnu.org/software/texinfo=
+/</a>)
+    for documentation, and recommend writing both reference and tutorial
+    information in the same manual.  Please see
+    <a class=3D"moz-txt-link-freetext" href=3D"http://www.gnu.org/prep/st=
+andards/html_node/GNU-Manuals.html">http://www.gnu.org/prep/standards/htm=
+l_node/GNU-Manuals.html</a>
+
+Pandoc Markdown is used. See: cbwww.git
+
+The Untitled Static Site Generator is used to generate it.
+
+This is what GNU Boot also uses, and it has Markdown, and was accepted.
+
+** Internationalization:
+    If your package has any user-visible strings, please make them
+    translatable to other languages using GNU Gettext:
+    <a class=3D"moz-txt-link-freetext" href=3D"http://www.gnu.org/softwar=
+e/gettext/">http://www.gnu.org/software/gettext/</a>
+
+No i18n, but there are translations of certain pages on the website, main=
+tained manually.
+
+Some of the packages that Canoeboot uses may have i18n, such as GNU GRUB.=
+
+
+** Accessibility:
+    Please discuss any <a
+    href=3D"https://www.gnu.org/accessibility/accessibility.html">accessi=
+bility issues</a>
+    with your package, such as use of relevant APIs.
+
+Accessibility issues: no screen reader in the GRUB/SeaBIOS boot menu, tho=
+ugh GRUB (coreboot payload often used on Canoeboot installations) has a m=
+orse code generator which I could probably re-purpose for blind users.
+
+** Security:
+    Please discuss any possible security issues with your package:
+    cryptographic algorithms being used, sensitive data being stored,
+    possible elevation of privileges, etc.
+
+No issues that I can think of.
+
+Canoeboot actually improves the security on some of its packages. For exa=
+mple it adds Argon2 KDF support to GNU GRUB, so that you can boot from LU=
+KS2 formatted /boot partitions.
+
+* Licensing:
+   Both the software itself *and all dependencies* (third-party
+   libraries, etc.) must be free software in order to be included in
+   GNU.  In general, official GNU software should be released under the
+   GNU GPL version 3 or any later version, and GNU documentation should
+   be released under the GNU FDL version 1.3 or any later version.
+
+Canoeboot build system largely GPLv3+, some parts are GPLv2-only.
+
+Coreboot is largely GPLv2.
+
+GRUB largely GPLv3+, sometimes v2+ or v2-only
+
+SeaBIOS largely GPLv2, with some v3 seasoning
+
+   Please see <a class=3D"moz-txt-link-freetext" href=3D"http://www.gnu.o=
+rg/philosophy/license-list.html">http://www.gnu.org/philosophy/license-li=
+st.html</a> for a
+   practical guide to which licenses are free (for GNU's purposes) and
+   which are not.  Please give specific url's to any licenses involved
+   that are not listed on that page.
+
+NOTE: Canoeboot already listed on FSD:
+
+<a class=3D"moz-txt-link-freetext" href=3D"https://directory.fsf.org/wiki=
+/Canoeboot">https://directory.fsf.org/wiki/Canoeboot</a>
+
+FSF's own craigt heavily audited it over a one-week period, extensively s=
+canning it and then going through it all with me.
+
+* Similar free software projects:
+   Please explain what motivated you to write your package, and search
+   at least the Free Software Directory (<a class=3D"moz-txt-link-freetex=
+t" href=3D"http://www.gnu.org/directory/">http://www.gnu.org/directory/</=
+a>)
+   for projects similar to yours.  If any exist, please also explain
+   what the principal differences are.
+
+GNU Boot
+
+I intend for Canoeboot to replace GNU Boot, and for GNU Boot to be decomm=
+issioned, since it is currently a dead project; Canoeboot is the only FSD=
+G compliant coreboot distro under active development.
+
+In addition, if accepted, I suppose libreboot.at would also be redirected=
+=2E Both libreboot.at and GNU Boot would redirect to Canoeboot.
+
+The current GNU Boot developers are welcome to work with me as contributo=
+rs if they wish, but they must not be made maintainers officially; I will=
+ assume that rule as GNU Canoeboot maintainer.
+
+* Any other information, comments, or questions:
+
+<a class=3D"moz-txt-link-freetext" href=3D"https://trisquel.info/en/forum=
+/canoeboot-20240510-released-gnu-fsdg-compliant-100-free-software-coreboo=
+t-distro-replacing-pro">https://trisquel.info/en/forum/canoeboot-20240510=
+-released-gnu-fsdg-compliant-100-free-software-coreboot-distro-replacing-=
+pro</a>
+
+This link contains discussion, including from jxself (leading member of G=
+NU Advisory Committee). The subtext is GNU Canoeboot, because jxself was =
+aware of my plan when he posted here.
+
+Early days thus far, but the gist is this: Canoeboot has dropped 100% of =
+its hostility to FSF and I've decided that it will staunchly *support* th=
+e FSF instead, openly promoting GNU FSDG policy and encouraging the use o=
+f FSDG licensed distros such as Trisquel. This would be just like the goo=
+d old days of GNU Libreboot! This change is permanent.
+I wasn't going to make this request to gnueval, but since GNU Boot isn't =
+really a thing anymore (no commits in over 4 months on their main branch,=
+ and generally slow development before then), I thought: why not?
+
+Canoeboot is being kept separate from Libreboot from now on. It no longer=
+ promotes Libreboot. When I'm working on Canoeboot, I simply enter GNU Le=
+ah Mode, which is a brainmode where I believe absolutely in it and will s=
+tand by it to the very end. I'm really good at that, and I also did that =
+when GNU Libreboot was a thing.
+
+I've already spoken to several people who are influential such as Mike Ge=
+rwitz and Bob Proulx, and they have said that, in principle, they support=
+ this move, though they have also told me that they will not be involved =
+(of course, if they do want to, I'd like that).
+
+GNU Canoeboot.
+
+That is what I want, and that is what I propose. I will follow all rules =
+and do things right.
+
+Also:
+
+Another librexit (libreboot exit from GNU) will not occur. Canoeboot will=
+ be GNU forever, if accepted. I never told anyone this before, and it's n=
+ot an excluse, but it is a mitigating factor: I was going through a very =
+difficult time in my life when Libreboot left GNU all thoes years ago. I =
+was regularly drinking, and I was drunk when I originally sent thoes host=
+ile messages to GNU in 2016. I'm not like that for years now. I don't dri=
+nk anymore, and I don't do drugs - and I haven't done so for many years n=
+ow.
+
+The way I see it, there will always be a demand for a fully free coreboot=
+ distro, and Canoeboot is currently the only viable project in this regar=
+d.
+
+Canoeboot is superior to GNU Boot for these reasons:
+
+* Much more up to date. Uses coreboot, GRUB and SeaBIOS revisions from 20=
+24, whereas GNU Boot uses revs from late 2021.
+
+* Build system is more efficient: 6 shell scripts instead of GNU Boot's 5=
+0, and about 1300 lines of code in the build system, versus GNU Boot's ~5=
+000. Generally cleaner coding style in Canoeboot.
+
+* Despite being smaller, Canoeboot actually has more features. Such as bu=
+ilding of serprog images (to make cheap SPI flashers), support for buildi=
+ng U-Boot payload on ARM devices (and they boot), and more hardware suppo=
+rt.
+
+* I've been working on this stuff for over 10 years. I know all the nooks=
+ and crannies of coreboot, and how to really make your bootloader sing
+
+* GNU Boot uses Libreboot's old build system design, which is why it's mu=
+ch bigger. I did a series of audits in 2023 to vastly increase the code q=
+uality in the build system.
+
+* GNU Boot is going to become more complex, because they want/wanted to r=
+ewrite it all in Guille and use the GUix package manager to build everyth=
+ing. While this would make individual building easier, it would vastly in=
+crease the maintenance burden and introduce many moving parts to the proj=
+ect, making it unmaintainable over time. Canoeboot's design is much simpl=
+er and I'm also working on bootstrapping (e.g. musl-cross-make integratio=
+n)
+
+* GNU Boot lacks many of Libreboot's newer security features, such as Arg=
+on2 KDF support for LUKS2 boot
+
+So, basically, Canoeboot is much easier and better.
+
+I actually did initially try to help GNU Boot instead. The problem with G=
+NU Boot is that it's based on a really old Libreboot version and hasn't b=
+een changed much since, and they've basically been in "development hell".=
+ I sent them extensive patches fgixing build issues, so that it builds on=
+ modern distros, andh I sent them patches updating it to newer upstream r=
+evisions e.g. coreboot, but none of my patches were reviewed. I don't thi=
+nk the current developers are up to the task, and this is not an insult; =
+they worked under me as Libreboot contributors in the past, and they only=
+ ever worked on minor tasks, they never did anything big. I've said in th=
+e past that perhaps I should be appointed as leader of GNU Boot instead, =
+but I have my Canoeboot project which has surpassed it technically in eve=
+ry way, so now I want a GNU Canoeboot.
+
+Upcoming work on Canoeboot:
+
+* More ARM chromebooks, which Alper Nebi Yasak (libreboot developer) is w=
+orking on
+
+* More Dell Latitudes (GM45 modules). I'm working on these, based on the =
+Dell E6400 port
+
+* Mate Kukri (coreboot developer) is working on an exploit of Intel SA-00=
+086 to gain unsigned code execution on Intel ME v11, for Skylake boards, =
+but I'm told that similar exploits are possible and will be worked on, fo=
+r older sandybridge, ivybridge and haswell hardware (e.g. ThinkPad X220, =
+X230, T440p) - currently, the only blobs needed on those boards are Intel=
+ ME and microcode, though they can boot without microcode. There's a chan=
+ce that in the next few years, we will have what I call the Intel Freedom=
+ Engine, a full free replacement of Intel ME. This would become part of G=
+NU, if GNU accepts Canoeboot today.
+
+* Linux-libre payload with musl libc and busybox, and U-Root, to provide =
+booting of linux kernels on disk and over the network, from the flash. (G=
+NU+Linux system in flash basically), with many security features such as =
+measured boot, and native support for ZFS file system.
+
+Some or all of the above, and more, will be present in Canoeboot this yea=
+r.
+
+So how about it?
+
+Many people will be surprised by this email. But if you put your trust in=
+ me, I promise I won't disappoint. I will of course make a savannah accou=
+nt as part of this, and use it, if accepted.
+</pre>
+    <p></p>
+    <pre class=3D"moz-signature" cols=3D"72">--=20
+Company director, Minifree Ltd
+Registered in England, No. 9361826 | VAT No. GB202190462
+Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK</pre>=
+
+  </body>
+</html>
+
+--------------0qkEOS0KaVvTlm4TzFss1Nsy--
+
+--------------qXtx1QnbZel60GYrRxArVU6C
+Content-Type: application/pgp-keys; name="OpenPGP_0x5C654067D383B1FF.asc"
+Content-Disposition: attachment; filename="OpenPGP_0x5C654067D383B1FF.asc"
+Content-Description: OpenPGP public key
+Content-Transfer-Encoding: quoted-printable
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+
+xsFNBGWN15sBEADECGPEe37tdU3xe7OshKU19xVOPuJRMveCO5DHfv/lsZMXLWXw
+MMpbG+2xSMQZcdZc0HCUq6TQE9fU0rA3kcFz0miMOuB2WJbYy9guvg9pAjLa0LUy
+b2T/HPDDy0ifYtqrOzwETwWRiWQcTHjJ0knwNReaEterpPki1MbK79EwSuQBIgq9
+lQ611qLn5SmE7sBRB5kze7q3KdTvY/CTfvOpVizgRF8kqqG4r4XkI0dTyrvC3i3E
+ub3F3YPWNjN06rECG6wO+TPzRo7em+0CdPYDgtqq4Srf050KNZsVt10Plty5VpJm
+2GfoXFh6SZBO1zSbBpTGU+7vBsR731ye2ouQdcIs06Qi4wHmJ71liqJwxZ0ju2F5
+edC7jDzdk4jAIaCiSiU+iGg28RsxoUdLkJl5Q4yW507Gr0psHIBJBAWJo1i75qKV
+hrmN25xjJLv0MjgaR7RgT1T7uuX1KPuo8NbHbRlkIv7987NeJzgbUzzpka2MJjTE
+d1ova9kPyICVmKCfBnT+bO3vfJAuQXRlf3qjXSLsxCD7Jmu07if0jXFIvjy/nC4H
+0QPlwd/sVS7Svfn4rEGEnulrtBvVdOr6I+LmDedbSsSlYNlqagdyGsdKZfWSGxhj
+fz4oAkVy+y39s1qAnM5191m+u72dmnQPtxI8lEH/G+j+hK8NxDvV5ri3owARAQAB
+zR1MZWFoIFJvd2UgPGluZm9AbWluaWZyZWUub3JnPsLBlAQTAQoAPhYhBIux99KM
+92ltv09xklxlQGfTg7H/BQJljdebAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMB
+Ah4BAheAAAoJEFxlQGfTg7H/PKoQAIB8z2Rg+R0417YRTBXvbVG5kPpKOO3DWUaQ
+CJx6uypBUpgw2giKDsDz59c2vNaADs7Zh5xQ+2bzB+jkCjVSuzguApT3gxTnICvL
+eM72d5ZEF6Q8/YC6s9IiIHssCujbxtNN5yDU/Kn9Qd3gb+Bn9t/ZYT+L/SGLU3Ze
+rq57lSt8ixU7JOvAolgqRzaPwTFvi1GPZbE5Gynj9riTxZc3KLFROWYNiiO33T+X
+17TepTUaubkoA3DgWcQ6tw2dsJ8MT0DtZH8KlU/ufq0NBfFIw79uCQ+m/GbiW9Sm
+KtppayLUJyJndlf5fQ/NaNJw9RS+yF5ellGKWWAwh+Drv0PITzJ1dLeWOF5degty
+n9+HaMSMRIs5G6m69UxZmLJ9TQF1Lt1u0l1EH7yHIAf69MX4nlcDIx6moIJgo2UJ
+9u2D7odDUKlPG8X4lbc5cvGx9l/Hy6WF8dOYUiU1avU65uhggaNXGXC6JbDiChCe
+uWTnzKXqlvae8rU9jSpDBSQFlOOgvi3NifDLM7xFByDtFabnJHniNO1B6kS0V0nv
+6sJlRuB584kQUQ+PaRUj8QvXjsLvYhxYTw2G7jzQkXEOBZq3jenVzAg5ejOB7mTN
+oZOYOWoFY7XDRUGOmGDvH2qQGVNhedhSBJilAiu6K0NyjkaFAGufvgXDjLImPav/
+kWdbTDvNzsFNBGWN15sBEADj4Dhn29Z0LVU+B1Wc8U0wdV7NbDIjbhEvJ0Yc+FTN
+orQq7avY9jTkGtcnKPUti6cJxuQOZPxaIzP1mMK9BlsGbB8bTJ7oqpsIXuvGKOOZ
+QMb7i+qEIfJw6ZAXSwuKq4xBciJU52WdX8OaSWJ6KZX74yrE1SXW+7yj3ENZNWuT
+N2kAPF595XYpZwTAaJRy/ojfORu8WFXvo5osZJI1TlrJeDFecBntPkCgvI1VPTF3
+fUU3lGZc8rVascaGaJ6tBd5mTx/RrRyJrrJMEd1dca0MHV4WIDbNeINpbEhS2Sbq
+Oj/9q9z8tfmleqXVjb+gKjSDpD8Nsxv9+2gq29tevMLqZ5R3NA4jj4rOnyIuq+YF
+tkZuBuEc04UX3ApixdAQ0jINhIBfT8YcMC+wwTvl4jG4Rhzrc4jOX8igOe9wkstb
+l7JxGJU28x4htskAyM2CMxPaUrorm64cU2S0UoJGrvLfjItGud8dyM+RgtaO5wTF
+NO2A0dnq2/thIIgoEaiQfKMq2ilISsnf6x8as0FV3c7mGO8pDJlRwjoNg/89CMhx
+VbgO+5JQ+JHLfoMA++R+QaYy1ZLY51h5Ax6OtVWpZh67EuVDLx/5EFiyM25UTpqv
+H7t0ae2oLbAwQtIv1fRLhHP4aVSsP793of92/1lpybbpRD7/7ruVQ64d+/N49db6
+mQARAQABwsF8BBgBCgAmFiEEi7H30oz3aW2/T3GSXGVAZ9ODsf8FAmWN15sCGwwF
+CQlmAYAACgkQXGVAZ9ODsf8EqQ/8CjAQTza1pvd/GmKYHtldSA1odPB7AQkB+j4o
+yu5gDqtM/fFRv3uGVYLcyZwC3XF69KL+NpcUYG22RQWokt+z3OiVYfP5LyKjXe2c
+PMS2cmyXBHEcCP8QSffNQNoC2VYzaVXH4P6cBVmkDG3yPtQ2cH1Al6jhMS4Fa0TC
+e6kgA7qROSoapdZuwbxEE7FeaYZIXQUBLpe2C6SexljD65DLhbDE5p4N56VbncO6
+IAqr9JQSlEXBgvgXGhXqfOmZkmCjXJU7Sgy8sIyF4b1uEOkcWxUUfvfrO1yrcWyx
+vTlZdPCJy802B7UVFPWTbKwFoyIq5Lr8wk2npzAmDy/hKZlIV72Vk0eIcrTCfpbj
+0GehrIIYcpW7Z2IUtETNkyuQs+OScIdrP3PItajNwktQJrhz+UGbF9MuT+CHuruh
+w5KzymkzcnEzCNaYvY4eG8IXP6VpX1GCs9eUvCWEnjP0OkmhQniWvS3vAB7DfZSm
+0NAoDX0ZvNzzIRbiM5uhYqDUSIsmOwUiJLjveLysmIRaAc/K/Euml0obCUJfanD7
+KSs7SZYp24ZTDNsvsWbsk1y8QvAGkZBfuykfRCMxsmGRyN2hS6H/ftttCUrj8Qn1
+/hJDBegEUJgYDItHpE7KJeBHMFNUB2sTHPbzx+a5WPYxeYJevAeTwAg0/nRobXRz
+ER7BLIU=3D
+=3D29JQ
+-----END PGP PUBLIC KEY BLOCK-----
+
+--------------qXtx1QnbZel60GYrRxArVU6C--
+
+--------------K2qUk5UHVXzKPCuKPN8riXWW--
+
+--------------QXCa2wGHkDkyD669GgjjqNUT
+Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
+Content-Description: OpenPGP digital signature
+Content-Disposition: attachment; filename="OpenPGP_signature.asc"
+
+-----BEGIN PGP SIGNATURE-----
+
+wsF5BAABCAAjFiEEi7H30oz3aW2/T3GSXGVAZ9ODsf8FAmZA10IFAwAAAAAACgkQXGVAZ9ODsf9i
+zQ//YateZS8rcc4CKaqGwGpwOq+hepIigkQznYXi5c1p5gHdcVExi4RzkzfdwfOEmqzpMYfX7ivd
++zlgyEx0u6v/fDE2gtTUbT6p/17PI+aKw/mubMeA42jRTuey3jmOUf6fek5crpMkZyd//Q9iXGj1
+LGQ6pZFhb2hk5RNCYU4n8Lv55LW0tlW4jToagkCxQ403ji6YXLugLbTfgctnP17dkuIvwO7vKL3D
+xzzNa6joluoEvVPKwRVBycaWTaGLYVYXPO4CBiX9ZxaNWN1RZaxBL3t9ZHL3WZndzK4kymJtStAJ
+TYjOGRQt0rQSh1DoNwSK//vFOMaJXjalQhmC6Qrf/1ee6sdTwg8V1SficuseJBkZ400RDowYUwg9
+BFdzkRMVhHH+oauxOE+lhzPYMwteYTggy5oob/M5DCpZMSG5rz1ySx+1WtTANwkQ7XmLxbV7DVxN
+vHR3FCvnsBvW7h5vqNWfUCkfIDeHKXPP+p85T/FW+BLYJeyAvPSPOnoDemsfowXxzkm1z/nc01ok
+Vg4zARtSCjYXZZheD+0CgXZPDEnXavQC4ol4bD+/AZA3J8G24H6qf+QLs7cTD5putPwdwFTNZGJt
+Br68vl8pzoLx6Rxu+e2JSbflhL7gNAkdCEbpClIQ+uU8fG/O69OaMWkoYEn1QzmOvH+YcvXWVPOK
+nc0=
+=JKOf
+-----END PGP SIGNATURE-----
+
+--------------QXCa2wGHkDkyD669GgjjqNUT--
+```
+
+That is all.
+
+I anticipate that precisely nothing will happen; however, I am deadly serious,
+and I would be quite pleased if they say yes.
+
+
+```
+flashprog -p linux_spi:dev=/dev/canoe0.0,canoespeed=gnu -w canoegnucanoegnu.gnu.rom
+```
+
+Follow-up
+=========
+
+In addition to the original message, I also sent this message to GNU Eval:
+
+some people have actually asked me if i should contribute to GNU Boot, instead of trying to replace it with GNU Canoeboot. They have asked this outside of this email discussion, but some here may be wondering that.
+
+I'd like now to address it. Here goes:
+
+I actually submitted extensive patches to gnuboot in January 2024:
+
+<https://lists.gnu.org/archive/html/gnuboot-patches/2024-01/index.html>
+
+<https://web.archive.org/web/20240511074211/https://lists.gnu.org/archive/html/gnuboot-patches/2024-01/index.html>
+
+The patches were never reviewed, let alone merged, but they:
+
+* Replace "Libreboot" with "GNU Boot" in several places on the documentation (**THIS IS THE ONLY PATCH THEY MERGED**)
+* Fix major build issues, allowing GNU Boot to build on modern distros (GNU Boot only builds on Trisquel 10, my patches make it build on 12. also Gentoo-libre and Arch/Parabola)
+* Add Dell Latitude E6400 support
+* Fix hang in GRUB caused when there is a stuck key, by disabling the "Unknown key" spew message
+* ESP and btrfs subvol support in grub.cfg
+* Fixes building KGPE-D16 on newer distros, by skipping GNAT which isn't needed
+* Add gru bob support (rk3399 chromebooks, with free EC and *no* microcode) - ditto gru kevin
+* Keyboard fix for GRUB: force it to use scancode set 2 translated, instead of untranslated set 2 to work around buggy ECs such as Dell Latitude E6400
+* Avoid spewing the Unknown prefix message in GRUB
+* Adds the dell-flash-unlock tool from Nicholas Chin, allowing internal flashing from factory BIOS to GNU Boot, on the E6400
+* cache cbfstool/ifdtool builds to speed up build time
+* better caching of coreboot rom images during build, to speed up build time
+* Prevent future GRUB build errors by disabling -Werror
+* Support for *building* U-Boot as a coreboot payload, on gru bob/kevin chromebooks (GNU Boot only archives it, doesn't build it)
+
+A second patch set that I sent does the above, and also:
+
+* Updates GRUB, coreboot and SeaBIOS to newer revisions from late 2023 (GNU Boot uses late 2021 revisions)
+* Adds Argon2 KDF support, for booting from LUKS2-encrypted /boot (GNU Boot can't boot from encrypted LUKS2 /boot without this patch)
+* Reduced the number of modules in GRUB to only those needed, saving 100KB of space in flash
+* Update memtest86+ to v6.x instead of 5.x
+
+I sent all of these patches to GNU Boot while bored, and it only took me 1 day to implement all of them, re-using what I had done in Canoeboot months beforehand
+
+My patches fixed all of the fundamental issues with GNU Boot, without rewriting the build system; they use an older version of the Libreboot build system, prior to my re-write of the latter half of 2023 (my re-write makes the build system much smaller and more efficient.
+
+All of the above improvements *and much more* is in Canoeboot. In terms of development, Canoeboot is about 2 years ahead of Canoeboot; Canoeboot has since far surpassed the improvements sent to GNU Boot in January, so even if they did merge them now, they'd still be behind.
+
+I may be missing a thing or two, above, but one thing I'm not missing is my strong and stable commitment to the free software movement, even when I'm dealing with hostile project maintainers who won't even consider my patches.
+
+This is why I will no longer assist the GNU Boot project. Because I tried to help them; and this wasn't my first attempt to help, either.
+
+Whether GNU accepts Canoeboot or not, Canoeboot will continue to press full speed ahead. I say now it's 2 years ahead of GNU Boot;
+
+Next year it'll be 3 years ahead.