rpardini

https://github.com/armbian/build/pull/5606
 
Testing image:
https://github.com/rpardini/armbian-release/releases/download/23.08.18-rpardini-434/Armbian_23.08.18-rpardini-434_Odroidm1_bookworm_edge_6.5.0-rc6.img.xz
 
#### `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works; bump kernel to 6.5-rcX
- `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.4.y, update config, rebase patches to 6.4.10
- `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.5-rc6; manually fix RK808 breakage in .config; externalize overlays; use Makefile autopatcher; rebase patches
- `odroidm1`/`edge` (`rk3568-odroid`): drop 6.3 and 6.4 patches
- `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works
  - using Kwiboo's `rk3568-2023.10` branch  with BINMAN-handled blobs
  - patches (defconfig unless indicated):
    - boot usb first (rockchip-common)
    - blink leds & keep red one one on preboot; reset SPI env once after deinfesting from Petitboot
    - change usb_host0_xhci to otg (u-boot dtsi)
    - enable DM_GADGET, UMS 🔥 and RockUSB
  - **usage instructions**:
    - build & burn image to SD card
    - insert SD card into board
    - **hold the recovery (RCY) button** and power on the board
    - watch board boot
    - **de-infest Petitboot**: use `armbian-install` to install bootloader to MTD
      - if you don't, you'll need to hold the recovery button every boot
      - optionally: use `armbian-install` to install OS to eMMC/NVMe/USB
    - power-off board
    - remove SD card (new u-boot always boots SD first!)
    - boot into your newly de-infested machine
      - boot order: USB, SD, MMC, NVME, SCSI
  - de-infested machine can now boot (directly) from USB/SATA/NVMe, possibly via EFI:
    - Armbian UEFI-arm64
    - Fedora 38 aarch64
    - HASSOS for ODROID-M1
    - Talos arm64
    - others...
  - extra: new u-boot by Kwiboo (with GMAC patches) gives us stable MAC address
    - although it is based on cpuid#, doesn't match the HK sticker on the board
      - run `fw_setenv ethaddr XX:XX:XX:XX:XX:XX` to change eth addr in SPI flash environment if needed
  - `odroidm1`: update DDR/BL31 blobs (this depends on https://github.com/armbian/rkbin/pull/20)

Some progress has been made, 6.6-rc5, new alsa-ucm-conf and firmware.
Try the "Armbian Trixie - Gnome Desktop" image available at https://www.armbian.com/lenovo-x13s/ under "Other supported variants", that might work: filename is Armbian_23.8.6_Thinkpad-x13s_trixie_sc8280xp_6.6.0-rc5_gnome_desktop
 

@c0rnelius graciously submitted GitHub PR to upgrade u-boot that effectively removed the patch in question from the equation for the Radxa Zero.
While it was nice to "boot USB first", since it enabled a few interesting scenarios (boot non-Armbian EFI OSes in USB disk), it's not worth having it if normal Armbian operation is impacted.
I've advocated for this usb-first style to be default around u-boot 2022, but we're now moving to board-specific support (and removing completely in the case of the Zero) for 2023+.
 

Hey @Erica please try this experimental image: https://github.com/rpardini/armbian-release/releases/download/latest-images/Armbian_20230600_Khadas-vim3_bookworm_edge_6.4.0-rc5.img.xz
 
Instructions, for any VIM3, in any state (middle button 3 times in 1 second tells the MCU to force the SoC to boot from SD/eMMC).

-> Write oowow (https://dl.khadas.com/products/vim3/firmware/oowow/vim3-oowow-latest-sd.img.gz) to SD card. Insert SD card with oowow.
-> Power on board, press the middle button 3 times + reset until it reboots into oowow.
-> Use oowow to clear the SPI ("fast" method is enough) *and* the eMMC ("fast" method is enough).
-> Use oowow to set "bootmode" to SPI. (This way it will try SPI, which is empty, then eMMC, which is also empty, then SD).
-> Power off the board (important. MCU changes don't take effect unless you power it off completely).
-> Write Armbian to SD card, insert the SD card with Armbian.
-> Power on the board. Boot Armbian from SD. Use `armbian-install` after preparing the partitions on the target device (eMMC/NVMe/USB).
 
Good luck.

My first u-boot build:
 

Well this is a completely different subject, but yeah, valid. That probably/finally explains why media had double-patches to mkdebian/builddeb (which was already patched/replaced by Armbian before patches applied). I was trying to understand that, for months, and failed. Not a single comment explained it, as seems to be Oleg's policy. I will revisit it now that I know wth is going on and maybe it will make sense, but sincerely...
 
Currently and before:
- linux-image: has kernel, modules, and DTs (!), (in /usr/lib/<kernel_id>) -- as expected by standard Debian tooling (u-boot-menu, flash-kernel, etc). We had a long discussion about this, 2 years ago. Did we forget? (No, it was just Oleg said he agreed, but ignored it and patched his own stuff "secretly" sans any explanation or discussion).
- linux-dtb: has DTs in /boot (as expected by "most" Armbian families, using u-boot and bootscripts, also the armbian-install, config, overlays, etc).
 
Either way, we can definitely accommodate this "single pkg" need, but I'd like to do it in a way that is 1) comprehensible 2) usable by more families than just one 3) not a maintenance nightmare, eg, NOT double-patching. I don't think that is unreasonable.
 
So if we could spell out what is the need, it would be easier... again: let's work together. we've 2 months to figure out stuff before release. 

I understand now that it seems that I just blindly changed the way `media` works and am crazy... might even be true, but, we can fix, and would already have fixed if more engineer talk and less drama. IMHO.

Hello folks, sorry for the absence, I've been facing connection issues.
Let me try and explain a bit, from the beginning. I will focus on kernel, but most applies also to u-boot, firmware, etc; also keep in mind that not all packages have been migrated to the new scheme: BSPs, Desktop BSPs, etc, are not yet changed (too many things to hash / little benefit / too many things to decide before that).
 
The reason we've a new version scheme is for consistent caching and fast CI runs.
The important part about the caching is that we need to obtain the "desired" version of the kernel, **before** actually git clone/fetching the sources, before patching, and before compiling; otherwise it's useless: if the user/developer has to do any/all of this to get to the version, then it's "too late" for caching. This needs to be crystal clear, otherwise everything just looks like an insane person did random stuff and broke Versioning for no reason.
 
Important: the caching part benefits some users/builders, in the sense that someone casually building an image at home might hit the cache, but the main target/reason it exists is for our (Armbian) own Continuous Integration (CI): every PR, every nightly, every release, etc, should benefit from the caching, but it has to be consistent (not use wrong version), and hit ratios should be high. Before this scheme, we had only REPOSITORY_INSTALL mechanism, which frequently installed wrong/mismatched versions, we just said "use whatever is in the apt repo", which could be literally anything, and frequently led to half-working images.
 
Also, "apt repo" is a very inflexible/demanding solution in terms of infrastructure, which requires HTTPS servers/mirrors, Release lists, etc, and is not available for free for every developer/partner. New caching uses standard OCI registries, which are available for anyone to host, and even hosted for free on GitHub (ghcr.io) and DockerHub among others.
 
That said, let's get to how we calculate the version for the kernel package. The code, containing a long explanation, is at https://github.com/armbian/build/blob/main/lib/functions/artifacts/artifact-kernel.sh - but in essence goes like this:
 
1) "base_version" (bv): Get the KERNELSOURCE and KERNELBRANCH variables (usually set in family config file for the board being built). Use `git ls-remote` to obtain the SHA1 of the commit of that. Obtain the HTTP URL for the Makefile at that commit. ("View raw" in GitHub web interface, but also for GitLab, and others). Get the Makefile contents (using HTTP, not Git, since there is not "partial git fetch"). Parse the Makefile for the version information inside, including the "codename". (Codename here is just to "prove" that data comes from Makefile, not "git tag"). Cache all this on disk for a few minutes.
2) "S"ha1: just the SHA1 of the commit mentioned above. 
3) "D"rivers: Obtain a SHA256 hash of the "drivers". Kernel drivers (EXTRAWIFI etc) are just a complex variation of patches; they are shared across families, and are not stored as patches, but in the end are transformed into one huge patch, so behave like one.
4) "P"atches: Obtain a SHA256 hash of the "patches": simple hashing of the patches/series/etc under KERNELPATCHDIR (and userpatches variations). If no patches, "0000" is used.
5a) "C"onfig: Obtain a SHA256 hash of the ".config" file that is gonna be used for the build. LINUXCONFIG (and userpatches variations).
5b) "H"ooks: Obtain a SHA256 hash of the hooks that might modify the .config. (This is a bit more complex to explain, since it involves extension mechanism, which is out of scope here). Suffice to say that if you change a hook that changes kernel configuration, the version should change.
6) "B"ash: Some lib/framework code, if changed, should cause the version to change as well. Not all bash code, but bash that calls the "make", or does the packaging, if changed, need to change the version. Currently "lib/compilation/kernel*.sh" is hashed.
 
Hopefully, you can now understand that `Version: ` below. Each SHA256 hash is shortened to a mere 4 characters:
 
 
 
So now we've to address two things: a) the original question by @belegdol; b) the general question of "how to control upgrades via apt".
 
------------------------------------------------------------------------
 
Ref the "odroidxu4" situation: @belegdol maintains that kernel family, in the following way (please correct me if I'm wrong):
a) Vendor, HK, has an  Git repo, which has a 5.4.y version, plus HK/Exynos patches. That Makefile currently says "5.4.228". It has heavily lagged behind official releases in the past AFAIK but seems pretty recent recently. HK "merges" updates from mainline, instead of cleanly rebasing, though, since they've lost all hope of mainlining their stuff and merging is easier.
b) Belegdol extracts new/recent 5.4.y patches from upstream/kernel.org, (possibly?) manually fixes them so they apply cleanly on top of HK kernel, adds them to Armbian via PRs. Those patches modify the Makefile so the version is incremented.
 
So AFAIK this is the only kernel family that is done this way (we did some similar stuff for rk3588 legacy, but thankfully no more). Every other family works in reverse: we start with a pristine/clean/updated kernel.org branch (whose Makefile is updated), and then patch what is needed on top of that. That way the kernels "auto update", unless some patch breaks.
 
Hopefully it is clear, together with the above explanation, why the  "wrong" version is used: only the original Git's Makefile version (not tag... but tag's Makefile's contents) is considered, since patches are only ever applied after Version is calculated, and cache possibly hit or missed.
 
So while I confess I had not xu4 as the primary target of this whole thing, it representing less than 1% of all boards. Still, there needs to be a way to make it work, we just need to decide how.
 
One possibility: invert the XU4 patching scheme, by rebasing HK's branch onto an upstream tag, and extracting the patches (git format-patch); then change our KERNELSOURCE/KERNELBRANCH to mainline, and let it auto update. This might, or not, be a lot of work initially, and might, or not, impose a lot less work over time. It depends on how many changes there are in HK Git, if the relevant patches are constantly updated, etc. From what I hear HK has little work done on the Exynos, but I am not an expert. I would like this scheme since it would align XU4 with the rest.
 
Another possibility: introduce a way to (optionally) override the "base_version" (example, variable FORCE_KERNEL_EXACT_VERSION_VIA_PATCHES="5.4.232") directly in the family configuration, use that for the artifact version if present, and change nothing else. This is _more_ work for xu4 maintainer, and might be get out-of-sync with reality (change patches, but not change variable, and vice versa). This might be useful also for other situations, although none come to mind right now, it might be useful for Igor's "emergencies" 😉
 
------------------------------------------------------------------------
 
Now about "how to control upgrades via apt". 
 
To understand this, we need to understand the formally defined Debian Policy about the "Version: " field in the DEBIAN/control file.
I recommend we all read https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version -- it is one of the more dense, complex, and important paragraphs of text ever written by Debian, and defines how apt decides what version is "higher" than another.
There, we can see there are 3 components, each with its own rules, and the special rule about the "~" (tilde) character.
 
The important part: I did not want to "impose" the final apt versioning scheme before we talked about it.
Also: there's pending work in the general area of "repository management/publishing" that needs to be done before we can publish _anything_, consistent or not, to any apt repository. 
I was told we had until May/2023 (so circa 2 months) to reach consensus and implement those -- but now it seems the sky is falling down much earlier?
 
So current "Version: " is a non-working, non-deterministic, inconsistent situation in regards to apt upgrades: if you try to predict how our "bv+S+D+P+CH+B" will be handled by apt, you will soon realize it's inconsistent: "fixed"/later patches on same base version might get downgraded to broken ones, and vice versa, almost randomly (as is the property of SHA256 hashes).
 
One extremely easy way to "fix it" is to prefix our current "bv+S+D+P+CH+B" with the $REVISION (which comes from VERSION file or equivalent userpatches) and a tilde.
That would force apt to respect the "old" versioning scheme, while still keeping caching consistent.
Unfortunately, doing that would drastically decrease cache hit ratio, since changing VERSION file would cause an otherwise identical kernel to be ignored/rebuilt. That might happen because user/dev changed userpatches/VERSION, but is otherwise identical to main, or because we branched off a release/tag (otherwise identical to main at that instant).
 
But it might be the best option right now, especially if no-one else is willing to invest brain time on this. I could then twist my own brain on how to recover the cache hit ratio somehow else (eg, search cache for both with-$REVISION and without-$REVISION variants, invent some "IS_RELEASE=1" variable, doing GitHub Actions acrobatics, etc; is a lonely world where only Igor and Ricardo live).
 
Similar option: transforming $REVISION ("23.05.01") into an integer (230501) and using that as the "epoch" part of Version field, would also work, but same cache-non-hitness applies.
 
-----
 
Phew, that was long. If you read all this, give yourself a pat in the back. Let me know what you think on all the different points... @going @Werner @belegdol @Igor @SteeManand everyone else interested.
 

I couldn't reproduce the problem, after deleting `cache/tools/oras`, even with CLEAN_LEVEL=debs ARTIFACT_IGNORE_CACHE=yes.
I deleted the whole cache and was able to reproduce it.
EDIT:  deleting cache/tools/oras. does reproduce the error.  Not sure why I didn't get the same result earlier.

https://github.com/armbian/build/issues/4889

https://github.com/armbian/build/issues/4879

Might be minimal image and firstlogin don't like each other?
Either way, please open GitHub issue with those, can't keep up with 2 places for issues.

Yep, I worked on that a few months ago. We've something like `./compile.sh distccd` which starts a distcc daemon, complete with zeroconf etc, using the same toolchains Armbian would.
Something else (forget what) enables it to be used on a controller node. You do need a bigger controller machine, say 8-cores, to completely max out some two/three 4-core distccd's, due to the high preprocessing load.
The network between the machines has to be very good, too (gigabit+). All in all is a "fun" way to use all those SBCs laying around doing nothing, but don't expect something miraculous...
One day I'll finish / document this...
 

I can only imagine how happy @rpardini will be not needing to re-base any more. 
 
Jokes aside, kudos to you, you must be thrilled all your hard work will be seeing the light of day, finally.  Thanks for sticking with it all that time.

Since I've no slides, a terrible sense of humor, and nothing else to post, here's a git shortlog of the changes since last week.
 
Ricardo Pardini <ricardo@pardini.net> (99): armbian-next: `CLEAN_LEVEL=make-kernel` now does `git clean -xfd` instead, faster and 100% clean armbian-next: better logging for early apt installs during `prepare_host_basic()` armbian-oleg: handle error during host deps installation (Oleg has a mangled sources.list?) armbian-oleg: introduce `DOCKER_SIMULATE_CLEAN=yes` so I can pretend to be Oleg, but using Docker armbian-oleg: split hostdeps again, full of ifs, and reduce the minimum set of pkgs for Oleg-conditions while trying to keep Docker full armbian-next: `apt-cacher-ng` is now optional and activated via `MANAGE_ACNG=yes`; drop `NO_APT_CACHER` armbian-next: remove old template Dockerfile, -next does not use this at all armbian-oleg: `junk`: drastically reduce host-side dependencies / "remove junk" armbian-next: curb down wget logging for ORAS tooling download armbian-next: curb down `git fetch` logging; be verbose if user on terminal & not logging armbian-next: curb `aria2c`'s complaining a bit armbian-next: curb `free_loop_device_retried()`'s logging on first try armbian-next: long overdue split of `logging.sh` armbian-oleg: logging: new logfile format; `SHOW_LOG=yes` default; introduce `DEBUG=yes` armbian-next: fix quoting of retry var (cosmetic) armbian-oleg: better logs; only include non-empty .log files armbian-oleg: curb `apt-get`'s logging with `-q` / `-qq` armbian-oleg: curb Python launcher logs armbian-oleg: curb `rsync` logging during bsp armbian-oleg: drastically curb `update-initramfs` logging, unless SHOW_DEBUG=yes armbian-oleg: drastically curb `boot_logo()` logging armbian-oleg: drastically curb `apt-get` logging when running in chroot armbian-oleg: make `chroot_sdcard_apt_get_install_dry_run()` logging more useful by filtering the noise out armbian-oleg: if commands fail, write to log in bright red armbian-next: split `compilation/debs.sh`; `compile_xilinx_bootgen()` moved to family armbian-oleg: curb logging from building `armbian-firmware` armbian-oleg: curb logging from building `armbian-plymouth-theme`; do it in a logging section, like the others armbian-next: logging: reinit logging after processing cmdline parameters armbian-next: cli: half-assed, legacy based, `kernel` and `u-boot` cli commands armbian-next: `odroidxu4` vs kernel: move firmware hack to family using extension hook armbian-oleg: logging: drastically curb / make more useful kernel packaging logging armbian-oleg: logging: disable debugging (set -x) of generated postinst/etc kernel scripts (board-side, but also chroot logging) armbian-next: kernel: deterministic `.config` mtime handling; kernel build logging sections reorg armbian-next: remove `REPO_STORAGE` and `REPO_CONFIG` -- unused armbian-next: consider "Provided" installed packages when determining what is missing from host-side dependencies armbian-next: completely remove `acl` (which provided `getfacl`) and it's usages (basic deps) armbian-next: don't copy the host's `keyrings` to image armbian-next: Python tooling: use consolidated+hashed+cached pip base/pycache; don't pip during Dockerfile build, nor cli-requirements armbian-next: add core extension `c-plus-plus-compiler` which hostdeps on `g++-aarch64-linux-gnu` and enable it in JetHub family armbian-next: core extensions for `xfs` / `f2fs` / `brtfs` / `LUKS/cryptroot` hostdeps; enable in main-config armbian-next: Docker: abstract away and only run "docker info" once, it's very expensive armbian-next: `rootfs`: bunch'o'fixes, introduce `disable_systemd_service_sdcard()` to stop repeating incantantion armbian-next: don't warn about using extlinux armbian-next: a bunch of checks for Darwin; use brew's GNU coreutils first in PATH, so we get the correct utils; give instructions armbian-next: better logging for `kernel_prepare_bare_repo_from_oras_gitball()`; remove dead code armbian-next: fix re-launching of CLI commands under sudo (Docker was ok) armbian-next: `patching`: don't complain about missing files when the patch parsed OK and file was actually deleted armbian-next: `patching`: don't rewrite empty desc as "None" armbian-next: `patching`: remove quotes from author name during parsing armbian-next: `patching`: avoid mangling valid utf-8 from mbox'es armbian-next: `patching`: parse renamed source files, don't swallow them during rewrite armbian-next: optimize `config_source_board_file()`, now 600x faster by not reusing (slow) code from interactive armbian-next: optimize for `CONFIG_DEFS_ONLY=yes`, skipping stacktraces/git info armbian-next: introduce `POOR_MAN_PROFILER=yes` (under `ANSI_COLOR=none`) armbian-next: `docker`: fix Dockerfile output indentation & warning msgs about generation armbian-next: make sure temporary `kernel` and `u-boot` CLI commands always build a kernel/u-boot even if cached `risc-v`: correctly include `debian-ports-archive-keyring` in Risc-V CLI packages `risc-v`/`starfive`: use mainline kernel 6.1.y, with StarFive's rebased patches against `v6.1.5` `risc-v`/`starfive`: update kernel config, sans changes `risc-v`/`starfive`: `CONFIG_MOTORCOMM_PHY=m` for the onboard Ethernet `risc-v`/`starfive`: switch kernel config to `savedefconfig`'s output, cos that's what it should be `odroidm1`: enable working userland `fw_setenv`, so users can go back to Petitboot & otherwise tweak u-boot env from Armbian `odroidm1`: bump to 6.2-rc3; look ma, no patches. `odroidhc4`: pre-configure `fancontrol` so fans work right out of the box armbian-next: debug note about fstab with tmpfs in chroot armbian-next: mark Vagrant CLI as unimplemented armbian-next: `docker`: use dash-lines before/after launching docker; set `ARMBIAN_INSIDE_DOCKERFILE_BUILD=yes` when it is so armbian-next: `traps`: allow for cleanup handlers with arguments; unify around `run_one_cleanup_handler()` armbian-next: `ccache`: show more in ccache debugging armbian-next: make superglobals readonly (`DEST/WORKDIR/LOGDIR/SDCARD/MOUNT` and others) armbian-next: introduce `tmpfs-utils.sh`; put `LOGDIR` and `WORKDIR` under tmpfs; set `CCACHE_TEMPDIR` under `WORKDIR` armbian-next: split `prepare_host()`, fix `.tmp` reset trap armbian-next: do basic host checks before config if interactive, or during prepare-host if not armbian-next: tmpfs-utils: last-resort debugging, to stderr, of failed tmpfs unmount armbian-next: logging: squash nasty leaking file descriptor bug due to "tee" armbian-next: bring back `swig` hostdep -- needed for some u-boot's armbian-next: severe bug, countdown counted up armbian-next: kernel: cleanup bundle after patching succeeded, not after build success armbian-next: firmware: don't build `-full` firmware if not on CI/noninteractive and board's not going to use it armbian-next: `chroot_sdcard_apt_get_update()` to replace and better log `chroot_sdcard_apt_get update` armbian-next: extensions: rename `kernel-localmodconfig` to just `lsmod` armbian-next: docker: remove old code armbian-next: try harder to get `en_US.UTF-8` logging armbian-next: drop dead/duplicated code for bootsplash and mark kernel-drivers.sh (which includes bootsplash) as dead code armbian-next: extract `move_images_to_final_destination()` and optimize for fast-move when src/dst on same filesystem armbian-next: tune logging: unmounting, u-boot prep/source/install; traps; extensions armbian-next: don't leak `.raw` image if failure before move; show rootfs-tmpfs info armbian-next: `mktemp` and `tmpfs` related utility functions with automatic cleanup handlers armbian-next: small cleanups: squash typos / add function keyword / add types / mark dead code armbian-next: small cleanups: squash typos / add function keyword / add types / mark dead code armbian-next: add logging with size of actual built rootfs in MiB; debug tmpfs in trap & after pkgs done armbian-next: still fighting `tee` leaking under duress, and I think I won armbian-next: `compile_firmware()`: use new temp dir helpers (saves 2Gb+ in WORKDIR), fix typos armbian-next: severe bug, there was no prefix-emoji for Windows armbian-next: allow shortcut `EXT=` to the overly-long and plural `ENABLE_EXTENSIONS=` armbian-next: use retries for downloading ORAS tooling WiP: aggregation.py vs create-cache.sh: better hashing, much desktop WiP: patching.py vs decent logging: better, but not there yet ------------------------ armbian-next END marker ----------------------------- Richard Neese <r.neese@gmail.com> (1): `risc-v`: switch from `grub` to `extlinux`; add Debian Ports keyring hostdep to strap Debian riscv64 from ports Tony <tonymckahan@gmail.com> (1): armbian-next: officially support WSL2; pester user for UTF-8 terminal  

Yeah, parsing the patches includes being able to decode them.
Patches should match the encoding of the target patched source; In this case, it's UTF-8.
In my view, those patches are mangled (not just "in big5"): the original encoding was lost due to copy/pasting, and they're already (in master) putting frakked up characters in the source code.
So it can't get worse, but now I warn you about the error.
 
 

@rpardini one of the actions on the slides: "testing on other architectures (armhf, riscv64)"

 😀 For a lark, I thought I would give it a try on armhf, seeing as I have access to an orangepi-pc running Armbian Jammy
I mounted an external drive on it.
Armbian-next build was not successful, and because I don't think that armhf is a significant option, I didn't try too hard but here are the results. 
I suspect that the gcc-riscv64-linux-gnu package could be excluded if not cross compiling to riskv64, but I didn't investigate further.

First, I tried the same method that  I used on Intel, and it failed:
[🌱] Preparing [ host ]
[🌿] Please read documentation to set up proper compilation environment
[🌿] https://www.armbian.com/using-armbian-tools/
[💥] error: Running this tool on non x86_64 or arm64 build host is not supported  [  in prepare_host() at /mnt/storage/armbian-build/armbian-next/build/lib/functions/host/prepare-host.sh:63 ]
[💥] Build terminating... wait for cleanups...

I added this into lib/functions/host/prepare-host.sh at line 60 to include armhf in the permitted architectures:
    elif [[ $(dpkg --print-architecture) == armhf ]]; then
        :

Native build failed again:
[👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
[👉]    This may mean that the package is missing, has been obsoleted, or
[👉]    is only available from another source
[👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate
[👉]    --> 🧽   28: 13096 - 13096 - 13096: hBE: trap: main_trap_handler [ ERR and 100 trap_manager_error_handled: short_stack:/mnt/storage/armbian-build/armbian-next/build/lib/functions/logging/runners.sh:186 ]

I installed docker:
Docker build failed for the same reason:
[👉]    Get:18 http://ports.ubuntu.com/ubuntu-ports jammy-security/universe armhf Packages [491 kB]
...
[👉]    Package gcc-riscv64-linux-gnu is not available, but is referred to by another package.
[👉]    This may mean that the package is missing, has been obsoleted, or
[👉]    is only available from another source
[👉]    E: Package 'gcc-riscv64-linux-gnu' has no installation candidate

@rpardini armbian-next - repeat build string at the end of the build process leaves out build options, BOARD=...
and NO_APT_CACHER=... (although armbian build master also leaves out NO_APT_CACHER ) and possibly others.

I would probably expect that all defined options would be included?

Original test build string (with desktop and base configuration selected through dialog):
./compile.sh BOARD=pine64 BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_CONFIGURE=no CREATE_PATCHES=no NO_APT_CACHER=yes
 
Repeat build string returned at the end of the build process ("BOARD=pine64" and "NO_APT_CACHER=yes" are missing):
[✨] Repeat Build Options [ ./compile.sh   BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base DESKTOP_APPGROUPS_SELECTED="3dsupport browsers chat desktop_tools editors email internet multimedia office programming remote_desktop" COMPRESS_OUTPUTIMAGE=sha,gpg,img ]

I would also not expect COMPRESS_OUTPUTIMAGE=sha,gpg,img to be included (although no harm in including it).

@rpardini When a file has been changed in the local branch being built then master armbian-build provides a useful warning about not being able to update with a dialog to abort, continue or view changes before building.  

Personally I find this function to be a very useful reminder and would like to see it in armbian-next.

Image built with Armbian NEXT® boots on BPi M5! Most important things seem to work correctly (or at least on par with master). Well done!
 
Just to give another perspective: I'm a .NET developer and Windows user. I first heard of Armbian on 2022-10-21 (and downloaded and flashed an official image), and built my first custom image from master 12 days ago. So NEXT cannot be so bad

Yes. It is a process that requires human. What I automated is the boring part, so the human only has to use the eye at the end of it. At least for trivial rebases.
It is part of the Python patching system, but only used if invoked manually by a developer. Don't worry.
 

Hmm, I don't think I changed anything regarding this -- yet.
Currently the patches-hash and the real (6.1.3 etc) version of the kernel is not included in the deb filename/version. (it's static, "trunk123" or "23.02" etc).
And if the deb already exists, the build is skipped.
Hopefully soon we will include the patches-hash and the kernel version in the deb/filename, so the build detects the .deb is out of date and builds again.

I used `armbian-install` (nee `nand-sata-install`) for this with success.
It can use a small boot partition (/boot) on the eMMC to jumpstart kernel, but mount root in NVMe.
Take care to not overwrite SPI/MTD accidentally.
 

TF-A is progressing slowly, but there seem to be still open questions.
The DT rebase of u-boot has taken place. It still takes a rebase to be up to date, but this is only a small thing, because the basic structure conversion has already taken place.
But I haven't seen any movement in uboot WIP trees that I'm aware of. IMHO they are waiting to see how the TF-A development turns out in the end to develop u-boot accordingly further. I will report when I get news.
But the most important thing is that for the kernel only the rkvdec2 support is missing, and for the userspace only the FFmpeg v4l2-request support is missing to be usable out-of-the-box with pure mainline support for standard applications. It is thus available for all distributions without special effort for the Odroid-M1. They only have to maintain the distribution-specific modifications that they apply for other devices anyway.
I'm currently playing with jernej's FFmpeg patches for v4l2-request support and VP8 acceleration seems to work. H.264 fails with this error:
[h264_v4l2m2m @ 0xaaaabfc5ae10] Could not find a valid device [h264_v4l2m2m @ 0xaaaabfc5ae10] can't configure decoder But I don't know if the 5.1.2 paches basically work or how I can inspect the FFmpeg framework appropriately. With the gstreamer framework, however, everything works as expected.

Very good news about landed patches. 
Tobetter's posture: shortsighted. He's also contradicting himself, having worked on board DTs for Banana boards. 
 
 
Yeah, here's an edge 5.19 version, which is a snapshot/git format-patch of tobetter's 5.19 at some point, rebased to 5.19.4 and now rolled-forward by armbian to 5.19.12.
It does not carry an u-boot anymore, and uses less crazy partitioning. All blobs are from HK's SPI.
It now requires the SPI u-boot with skip_spiboot = true, https://wiki.odroid.com/odroid-m1/software/boot_sequence#bypassing_petitboot
CLI: https://github.com/rpardini/armbian-release/releases/download/20221007a/Armbian_20221007a-rpardini_Odroidm1_jammy_edge_5.19.14.img.xz
      👆☝️

Rock 5b test images, from armbian-next. Using vendor u-boot + patches, and vendor kernel, both straight from radxa's git
 
XFCE desktop with "browsers" app group
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66_xfce_desktop.img.xz
 
CLI
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66.img.xz
 
PR: https://github.com/armbian/build/pull/3984 (against master)
All work by @amazingfate I just gathered stuff and built images.
Thanks to @monkaBlyat @lanefu @piter75 @amazingfate for tests / patches etc
 
 

This is most probably a bug on my side. I build with all repos and mirrors disabled (SKIP_ARMBIAN_REPO=yes) so everything is built locally, but clearly I've a bug when you don't have that option. Try with it and let me know... meanwhile I'll try to find and fix the bug.