armbian-next development

[rpardini]

8 hours ago, schwar3kat said:

The build computer is Linux Mint 20.3 (Una) has a dedicated separate drive for Armbian builds and works well for current armbian build.

 

Hi @schwar3kat -- I've looked into this. Mint Una is based on Ubuntu Focal, which I had understood was no longer supported.

Turns out I was wrong -- we can't build Focal images, but Focal was (on paper) still supported as build host (!)

 

So I went on a "let's support Focal again" spree for your benefit.

The main culprits:

- old Python 3 version (Focal has 3.8, we need 3.9; Focal does offer a `python3.9` package which I've coerced it to use now through many indirections).

- old `bash` -- which does not support `declare -I` -- which is _very_ useful. I've removed, but with pain in my heart. `shellcheck` is not gonna be happy.

- old `git` -- which does not support a bunch of new flags I've been using, but I've worked-around it.

 

So please `git pull --rebase` -- you should get revision `f558a285ae21c0be3e0153234cd2852783f48ade` which should work now, save for any Mint-specific crazy that's not in Focal.  🧑‍🚒

[going]

15 минут назад, rpardini сказал:

So I went on a "let's support Focal again" spree for your benefit.

The main culprits:

- old Python 3 version (Focal has 3.8, we need 3.9; Focal does offer a `python3.9` package which I've coerced it to use now through many indirections).

- old `bash` -- which does not support `declare -I` -- which is _very_ useful. I've removed, but with pain in my heart. `shellcheck` is not gonna be happy.

- old `git` -- which does not support a bunch of new flags I've been using, but I've worked-around it.

Ricardo, all we need in the future is a lot of additional versioning of the commands that we use in the build system.

And a message to the user if the version is lower than the required one.
Linux OS can be anything if the versions of the commands meet the requirements.
This will save us from a lot of discussions on the forum.

[rpardini]

1 hour ago, going said:

Linux OS can be anything if the versions of the commands meet the requirements

 

True in a way, but also not: since we manage the host dependencies (prepare_host() and etc) we need to manage these things at the release level, unfortunately.

But yeah, validating the specific python / git / bash / etc versions (just --version and linux-version compare, etc) would save us from a lot of trouble.

 

[schwar3kat]

6 hours ago, going said:

old `bash` -- which does not support `declare -I`

Thanks for the effort Ricardo.
I'm not sure that accommodating is perhaps the best option. 
Just change supported versions should do the trick.
If the versions supported did not include una then users would know to upgrade.

I will test your changes but then I should probably upgrade to 21.1 vera.

[schwar3kat]

4 hours ago, rpardini said:

But yeah, validating the specific python / git / bash / etc versions (just --version and linux-version compare, etc) would save us from a lot of trouble.

Docker for Linux Mint various versions (I haven't used any of these) - https://hub.docker.com/u/linuxmintd
 

# git branch -v
* armbian-next f558a285a ------------------------ armbian-next END marker -----------------------------

Build recognizes Python version issue but appears to still use 3.9:
 

[\U0001f449]    --> \U0001f3a3    2: 2391286 - 2391286 - 2391286: ehBE: extensions: Extension Method being called: extension_prepare_config [ hook: extension_prepare_config ]
[\U0001f449]    --> \U0001f6b8    2: 2391286 - 2391286 - 2391286: ehBE: warn: Using  '/usr/bin/python3.9' for [ 'una' has outdated python3, using python3.9 ]
[\U0001f449]    --> \U0001f438    2: 2391286 - 2391286 - 2391286: ehBE: command: Command debug [ /bin/bash -e -o pipefail -c env -i 'PYTHONUNBUFFERED=yes' 'PYTHONPYCACHEPREFIX=/mnt/data/build-armbian/armbian-next/build/cache/pycache' 'LOG_DEBUG=' 'SRC=/mnt/data/build-armbian/armbian-next/build' 'OUTPUT=/tmp/tmp.rIciovpubR' 'ASSET_LOG_BASE=/mnt/data/build-armbian/armbian-next/build/.tmp/logs-decd7989-926c-4c3c-8750-e97496c5dc56/006.' 'ARCH=armhf' 'RELEASE=bullseye' 'LINUXFAMILY=sunxi' 'BOARD=orangepi-r1' 'USERPATCHES_PATH=/mnt/data/build-armbian/armbian-next/build/userpatches' 'SELECTED_CONFIGURATION=cli_minimal' 'REMOVE_PACKAGES=' 'REMOVE_PACKAGES_REFS=' 'EXTRA_PACKAGES_ROOTFS=' 'EXTRA_PACKAGES_ROOTFS_REFS=' 'EXTRA_PACKAGES_IMAGE=' 'EXTRA_PACKAGES_IMAGE_REFS=' 'BUILD_DESKTOP=no' 'DESKTOP_ENVIRONMENT=' 'DESKTOP_ENVIRONMENT_CONFIG_NAME=' 'DESKTOP_APPGROUPS_SELECTED=' 'PACKAGE_LIST_FAMILY=' 'PACKAGE_LIST_BOARD=' 'PACKAGE_LIST_BOARD_REMOVE=' 'PACKAGE_LIST_FAMILY_REMOVE=' /usr/bin/python3.9 /mnt/data/build-armbian/armbian-next/build/lib/tools/aggregation.py ]
[\U0001f449]    env: \u2018/usr/bin/python3.9\u2019: No such file or directory

I won't upgrade yet, in case it is useful for testing version compare and etc. 
I much prefer Mint, but also have a (slow) Ubuntu Jammy build computer that I can try.

 

[rpardini]

3 minutes ago, schwar3kat said:

env: \u2018/usr/bin/python3.9\u2019: No such file or directory

 

Damn, I must've messed up. /usr/bin/python3.9 should have been provided by the dependency installation. Can you upload the logs? I'll try the Docker images for Una.

 

54 minutes ago, schwar3kat said:

I'm not sure that accommodating is perhaps the best option. 
Just change supported versions should do the trick.
If the versions supported did not include una then users would know to upgrade.

 

True, I've clearly marked commits to revert if this proves pointless / not worth it / too much more work.

 

[schwar3kat]

30 minutes ago, rpardini said:

Can you upload the logs?

 

armbian-build-decd7989-926c-4c3c-8750-e97496c5dc56.ansitxt.log armbian-build-decd7989-926c-4c3c-8750-e97496c5dc56.md

[rpardini]

Thanks. I am an idiot -- testing this in Docker, of course Docker has the dependencies installed after the Dockerfile build.

Without Docker, aggregation runs before prepare_host() which of course fails due to not-yet-installed 3.9 version.

 

 

[rpardini]

1 hour ago, schwar3kat said:

Can you upload the logs?

 

1 hour ago, rpardini said:

aggregation runs before prepare_host() which of course fails due to not-yet-installed 3.9 version

 

Fixed in `1173864872510`.

If mirror trouble (unfortunately common recently), add `SKIP_ARMBIAN_REPO=yes` 

I am impressed with Mint, the default terminal is sane and doesn't eat my emoji.

 

 

[schwar3kat]

7 hours ago, rpardini said:

Fixed in `1173864872510`.

 

Much better.  Dependencies install, but ntpdate failed and aborted.  (log attached)
Ntpd is running on this computer.  Ntpdate is not necessary, perhaps warn rather than abort.

--> 🐸  167: 2401396 - 2401396 - 2401396: ehBE: command: Command debug [ /bin/bash -e -o pipefail -c ntpdate pool.ntp.org ]
 6 Jan 15:11:45 ntpdate[2405625]: the NTP socket is in use, exiting

If I stop the ntp service the build continues past this point.

If I change line 105 in prepare-host.sh to this, it continues with an error in the logs:
     run_host_command_logged ntpdate "${NTP_SERVER:-pool.ntp.org}" || true

 

armbian-build-99cee99b-287b-4fa2-907d-423fa914a11c.ansitxt.log

[schwar3kat]

8 hours ago, rpardini said:

Fixed in `1173864872510`

Nearly there.... still one issue.  Easy fix, I think.
Something goes wrong with rootfs-to-image.sh DEBUG: print free space.

If I comment out from line 61 to 63 in rootfs-to-image.sh the build works:
    # DEBUG: print free space
    local freespace
    freespace=$(LC_ALL=C df -h)
    display_alert "Free SD cache" "$(echo "$freespace" | grep "${SDCARD}" | awk '{print $5}')" "info"
    display_alert "Mount point" "$(echo "$freespace" | grep "${MOUNT}" | head -1 | awk '{print $5}')" "info"

 

Cause:
df -h produces a warning/error along with the listing on this computer:
 

$ df -h
df: /root/.cache/doc: Operation not permitted
Filesystem             Size  Used Avail Use% Mounted on
udev                   4.6G     0  4.6G   0% /dev
tmpfs                  942M  1.4M  940M   1% /run
/dev/sda6              135G   92G   37G  72% /
..... etc

If I change line 61 in rootfs-to-image.sh to this, the build works:

freespace=$(LC_ALL=C df -h) || true

 

armbian-build-bb4a34a2-99b3-43a0-bde9-afa12d894fe4.ansitxt.log output.log

[schwar3kat]

When I try this build for a Rockchip64 board orangepi-r1plus-lts, a lot of patches including one of mine produce an error:
"patch is not properly mbox-formatted".  I guess that checking has become more strict? 
I don't see a log with patch errors, making it difficult to know what is wrong. 
 

[going]

11 минут назад, schwar3kat сказал:

When I try this build for a Rockchip64 board orangepi-r1plus-lts, a lot of patches including one of mine produce an error:
"patch is not properly mbox-formatted".  I guess that checking has become more strict?

😄 Ricardo well done! This is an incentive for the correct design of patches.

The patch should contain a description in this style. Otherwise, it may be difficult for another person to understand what has been done and for what purpose. This is also necessary so that the patch can be applied as a git am command.

[going]

5 часов назад, schwar3kat сказал:

# DEBUG: print free space
    local freespace
    freespace=$(LC_ALL=C df -h)
    display_alert "Free SD cache" "$(echo "$freespace" | grep "${SDCARD}" | awk '{print $5}')" "info"
    display_alert "Mount point" "$(echo "$freespace" | grep "${MOUNT}" | head -1 | awk '{print $5}')" "info"

 

 

What will show if replaced with this code:

display_alert "Free SD cache" "$(LC_ALL=C df -h "${SDCARD}" | awk '{print $5}')" "info"
display_alert "Mount point" "$(LC_ALL=C df -h "${MOUNT}" | awk '{print $5}')" "info"

 

 

 

 

[rpardini]

6 hours ago, schwar3kat said:

the NTP socket is in use, exiting

 

Yep -- same theme as always: `master` swallows errors, `armbian-next` bitches about them and stops. 

In this case, indeed we can ignore the error, or even skip the clock sync completely it if we detect ntpd already running.

 

5 hours ago, schwar3kat said:

freespace=$(LC_ALL=C df -h)

$ df -h
df: /root/.cache/doc: Operation not permitted

 

This is to show, literally everything can fail. This piece of code needs conversion to something more sane, like using `findmnt` targeting the specific directories involved, instead of asking for the world and grepping.

 

5 hours ago, schwar3kat said:

If I change line 61 in rootfs-to-image.sh to this, the build works:

 

🎇 👍 Thanks for the insistence!

 

47 minutes ago, schwar3kat said:

When I try this build for a Rockchip64 board orangepi-r1plus-lts, a lot of patches including one of mine produce an error:
"patch is not properly mbox-formatted".  I guess that checking has become more strict?

 

Hmm -- this is on a different scale -- the whole patching subsystem has been rewritten, and it by design bitches a lot about "cosmetic" issues like this.

In this case it should be a warning -- not an error, but see below.

 

32 minutes ago, going said:

This is an incentive for the correct design of patches.

The patch should contain a description in this style. Otherwise, it may be difficult for another person to understand what has been done and for what purpose. This is also necessary so that the patch can be applied as a git am command

 

Nice, not everyone understands this.

The new tooling can also force-feed the patches back into git, rewrite the patches in-place (after putting them in git, and them out of git), auto-rebase them, and auto-migrate them across releases. (There is no CLI yet to expose these functions, but it is coming soon).

The new patching system tries to understand mbox-formatted patch files, parse / split them (using a proper mbox parser), understand each hunk individually (using a "somewhat-proper" unidiff parser, if such thing exists) and apply each separately (still using Larry Wall's `patch` utility, which is fuzzy/lenient), and report individual failed hunks.

It can also try to "recover" patches that are not mbox-formatted by doing "Git archeology" looking for the (Armbian) commits that introduced that patch, across releases, with varying pitiful levels of success. 

 

The .md "log file" that is produced during a build should include Markdown patching summaries with some information about the process and the patches. This one I've been working, mvebu-edge, https://rpardini.github.io/linux/armbian-next-mvebu-6.1-20230106.html and mvebu-current https://rpardini.github.io/linux/armbian-next-mvebu-5.15-20230106.html

 

Unfortunately there's a _thousand_ different ways that mbox files can be mangled, I've been resorting to some heuristics to find the problems, and every day I find more.

 

- Look at this one: https://github.com/armbian/build/pull/4652#issuecomment-1373049039 ("FFrom"...)

- @going this one is a head-scratcher, I've been working on a "number of magic markers has to match the number of mails in the file" validation and found this friend here: `sunxi-6.1/patches.megous/Add-README.md-with-information-and-u-boot-patches.patch` (a patch that... contains a patch?) -- it is of course inoffensive problem.

[rpardini]

1 hour ago, going said:

What will show if replaced with this code:

 

Those freespace checks can fail in subtle ways, also in master, it's hell, looky this https://github.com/armbian/build/pull/4656 

[schwar3kat]

10 hours ago, rpardini said:

Unfortunately there's a _thousand_ different ways that mbox files can be mangled

 

Mmmm......  ouch, that sounds painful, and it's probably not possible to cater to "a _thousand_ different ways" if those ways are unknown, so I guess some new parsing ideas may have to evolve. 

[rpardini]

2 hours ago, schwar3kat said:

I guess some new parsing ideas may have to evolve. 

 

The gold standard (conveniently written in Python) previously known as "get-lore-mbox", now b4: https://b4.docs.kernel.org/

Its output, taken from a lore link, is what we should aspire to have.

 

b4 am -o- "https://lore.kernel.org/all/20220701185959.GC1700@begut/"

 

For Armbian specific case, though, I'd like to increase unidiff size from 3 to 10 by default -- at least on .dts / .dts files to address at least most of those pesky "} } }" dts blocks endings mispatchings.

 

[schwar3kat]

On 1/7/2023 at 12:19 AM, rpardini said:

resorting to some heuristics to find the problems

 

My patch tested fine with the current Linux Kernel checkpatch.pl (https://www.kernel.org/doc/html/latest/dev-tools/checkpatch.html),
and I couldn't see an obvious issue so I tried some manual white-space cleaning stuff, namely trim trailing spaces and remove extra file end line-feeds.

It turns out that there were trailing spaces on some blank lines and extra linefeed on the end of the file.  I don't know which caused the parsing issue.

I will do a PR to improve the patch, but maybe the parser could perhaps be made to clean up or cope with such things automatically.

[schwar3kat]

Another subtle issue that may impact other developers:  build attempts to create, git add, and git commit a patch.
It fails to sign the commit which is not surprising.
[👉]    error: gpg failed to sign the data
[👉]    fatal: failed to write commit object

I have global signing configured:

user.signingkey=xxxxxxxxxxxxx
commit.gpgsign=true

 

Attempting to override this locally didn't work, I reset it globally and that worked.  (git config --global commit.gpgsign false)
This is not ideal for me... any ideas?  Otherwise I can live with it.

[schwar3kat]

The patch parser doesn't appear to be able to parse a patch with a mbox conversation history.

The attached original file is not one of mine.  It is bad and has format issues resolved as follows:

I moved the first three lines comment into the email body.
The patch is still messy and created warnings on the checkpatch.pl test but it should have worked.

I had to disguise the mbox history except for the last email before it would parse the patch.
I disguised the history email headers by adding a "-" to the beginning of each line.

The modified patch works.  As this is not one that I'm familiar with, I can't test it so I won't submit a PR unless requested.

Attached original and modified patches.

general-add-overlay-configfs.patch modified.general-add-overlay-configfs.patch

[schwar3kat]

On 1/6/2023 at 2:46 PM, rpardini said:

Fixed in `1173864872510`.

 

I disabled a non-working patch to test the rest of the build.  It built to completion.
Then I enabled the patch with the intention of attempting to fix it. 
I ran the build again, and it apparently didn't pick up the change.  It skipped the kernel build and used the cached kernel.

I had to delete the deb file to get it to build the kernel.

[going]

1 час назад, schwar3kat сказал:

Attached original and modified patches.

Below patch is a squash of following 4 commits borrowed from ayufan's
https://github.com/ayufan-rock64/linux-mainline-kernel repo:

From cc22206776d61948f6984a4f03d8013eb4f92984 Mon Sep 17 00:00:00 2001
From: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Date: Wed, 3 Dec 2014 13:23:28 +0200
Subject: [PATCH] OF: DT-Overlay configfs interface

This is a port of Pantelis Antoniou's v3 port that makes use of the
new upstreamed configfs support for binary attributes.

Original commit message:

Add a runtime interface to using configfs for generic device tree overlay
usage. With it its possible to use device tree overlays without having
to use a per-platform overlay manager.

Must be:

From cc22206776d61948f6984a4f03d8013eb4f92984 Mon Sep 17 00:00:00 2001
From: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Date: Wed, 3 Dec 2014 13:23:28 +0200
Subject: [PATCH] OF: DT-Overlay configfs interface

Below patch is a squash of following 4 commits borrowed from ayufan's
https://github.com/ayufan-rock64/linux-mainline-kernel repo:

This is a port of Pantelis Antoniou's v3 port that makes use of the
new upstreamed configfs support for binary attributes.

.........

Change-Id: I421887697d2ba6e52aba9100100b7664760e2001

---
diff --git a/Documentation/devicetree/configfs-overlays.txt b/Documentation/devicetree/configfs-overlays.txt
new file mode 100644
index 0000000000000..5fa43e0643072
.....
-- 
2.35.3

You don't have to edit the fix file in the editor.
Instead, apply a bad patch using the patch command to the source code.

Then add the modified files to track the git git add -A. And make a commit git gui. In the commit message, add all the text that you consider important.
Then extract the commit using the git format-patch -1 command

 

From 7cfb967c52d374ddcb0fc9194f38d1d5f9d8cdd8 Mon Sep 17 00:00:00 2001
From: popcornmix <popcornmix@gmail.com>
Date: Sun, 3 Dec 2017 21:43:03 +0000
Subject: [PATCH] configfs: New of_overlay API

From 8637321fabb045fe8617360ef1b058978b0d8457 Mon Sep 17 00:00:00 2001
From: Phil Elwell <phil@raspberrypi.org>
Date: Mon, 4 Dec 2017 14:07:40 +0000
Subject: [PATCH] SQUASH: config_fs: of_overlay_apply takes a pointer

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

From 274dfabb947ca32116a429c582c74aaee6ff1b5b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kamil=20Trzci=C5=84ski?= <ayufan@ayufan.eu>
Date: Mon, 14 May 2018 11:28:09 +0200
Subject: [PATCH] ayufan: fix overlayfs to compile on 4.17 kernel
  ?????????????????????????????????????????????????
only:
  Signed-off-by: Slawomir Stepien <sst@poczta.fm>
  Signed-off-by: Phil Elwell <phil@raspberrypi.org>
  Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
  Signed-off-by: popcornmix <popcornmix@gmail.com>
  Signed-off-by: Kamil Trzciski <ayufan@ayufan.eu>
  
  

 

[Igor]

Looking for a volunteer to split kernel-drivers.sh into functions, for aufs/wireguard/kali/exfat

https://armbian.atlassian.net/browse/AR-1478

If this is not ported, we will probably just drop it. But on the other hand, this is easy task and nice opportunity to understand armbian-next better and help.

[rpardini]

3 hours ago, schwar3kat said:

I ran the build again, and it apparently didn't pick up the change.  It skipped the kernel build and used the cached kernel.

I had to delete the deb file to get it to build the kernel.

 

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.

[rpardini]

13 hours ago, schwar3kat said:

The patch parser doesn't appear to be able to parse a patch with a mbox conversation history.

The attached original file is not one of mine.  It is bad and has format issues resolved as follows:

I moved the first three lines comment into the email body.
The patch is still messy and created warnings on the checkpatch.pl test but it should have worked.

I had to disguise the mbox history except for the last email before it would parse the patch.
I disguised the history email headers by adding a "-" to the beginning of each line.

 

Hmm. This (damn) patch is everywhere. Case in point: https://github.com/armbian/build/commit/3790d46c6dbb3b7414d68109ebaaa93dd69bc207 and https://github.com/armbian/build/commit/d89b9cb3641fc119a72a11ea32fd5327578d5e9c 

 

That is simply a complete mess of a single mbox, it's not "conversation history", it's just a complete mangle. 

Worse, it was copied around everywhere in many families. 

 

We've also a lot of patches with invalid utf-8 chars due to mangled copy/paste of chinese code, also copied around, then modified differently in each family.

 

Cleanup is necessary for sanity, most of those things should just be dropped.

 

11 hours ago, going said:

Then add the modified files to track the git git add -A. And make a commit git gui. In the commit message, add all the text that you consider important.
Then extract the commit using the git format-patch -1 command

 

I have this process fully automated in the new patcher, including keeping certain matches in the same file, and rewriting both in-place (rebase against kernel built) and via git (for doing rebase across versions).

There will be a CLI for this very soon. "kernel-patches-to-git FAMILY=xxx BRANCH=xxx" and "kernel-rewrite-patches FAMILY=xx BRANCH=xx" or something like it.

 

[schwar3kat]

On 1/6/2023 at 5:12 PM, schwar3kat said:

Fixed in `1173864872510`.

I think that your una/focal stuff is tested as working on una so I've upgraded to vanessa (jammy).

 

[going]

5 часов назад, rpardini сказал:

I have this process fully automated in the new patcher, including keeping certain matches in the same file, and rewriting both in-place (rebase against kernel built) and via git (for doing rebase across versions).

 

The patch conversion process cannot be automated. This is a completely manual process. It requires a human eye. It requires a person's analytical thinking. And he will make mistakes because he will not be able to track changes in other files that are not affected by the patch, but which (files) affect changes in the file to which the patch is applied.

I do not approve of the presence of any script automating the patch conversion process in the build system itself. This can only be as an additional utility designed exclusively for manual use.

A few years ago, I wrote something similar on awk. It was a process of training and learning regular expressions and the gawk language itself. But no more than that. The script almost completely provides the capabilities of commands from the "diff-utils" package, but it does everything automatically.
And what is the result?
After several months of using this script, I put it on the shelf.

I have transferred all sunxi patches to a series and maintain only a clean set of patches in the build system.

 

I hope we understand each other.

[schwar3kat]

On 1/8/2023 at 2:00 PM, rpardini said:

Hmm, I don't think I changed anything regarding this -- yet.

@rpardini I finally got armbian-next to build some rockchip64 orange-pi-r1plus-lts working images including some customization with customize-image.sh.   This was done on both Linux Mint una (focal) and Linux Mint vanessa (jammy)
 

The patching issues are by far the biggest headache.
The second biggest headache is caching that does not pick up changes which leads to a fair amount of confusion.

Summary of actions that were required to prevent errors from aborting the build:

modified:   lib/functions/host/prepare-host.sh
line 105 changed to:
run_host_command_logged ntpdate "${NTP_SERVER:-pool.ntp.org}" > null 2&>1 || true

This behaves like current armbian-build and ignores errors caused by ntpd using the port.

modified:   lib/functions/image/rootfs-to-image.sh
line 61 changed to:
freespace=$(LC_ALL=C df -h > null 2&>1) || true

This hides any warning messages and continues.

or:
freespace=$(LC_ALL=C df -h) || true

This shows warning messages and continues.

I disabled global patch signing (if enabled git commit will error):
git config --global commit.gpgsign false

I manually deleted deb files and cache/patch/kernel-drivers/ as required.

 

I also had a problem with something cached causing makefile corruption.  
I couldn't find the cause and after I blew away the whole build, and started again from nothing the problem disappeared.

[schwar3kat]

@rpardiniI tried building with BUILD_DESKTOP=yes.
I expected a dialog to select which desktop and base config, but it aborted with an error.

[\U0001f449]    --> \U0001f4a5    2: 1401540 - 1401540 - 1401540: ehBE: err: error: stdout is not a terminal. can't use dialog. [ dialog_if_terminal_set_vars --title Choose a desktop environment --backtitle Armbian building script, https://www.armbian.com | https://docs.armbian.com | (c) 2013-2023 Igor Pecovnik  --menu Select the default desktop environment to bundle with this image -8 cinnamon Cinnamon desktop environment  gnome Gnome desktop environment  xfce Xfce desktop environment  in dialog_if_terminal_set_vars() at /mnt/data/build-armbian/armbian-next/build/lib/functions/configuration/menu.sh:17 ]

./compile.sh BOARD=pine64 BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no CREATE_PATCHES=no

armbian-build-b1f739f4-a394-44bf-ac80-72d8714be9f5.ansitxt.log armbian-build-b1f739f4-a394-44bf-ac80-72d8714be9f5.md