armbian-next development

[going]

19.04.2022 в 20:44, Igor сказал:

By the end of this month we want to merge https://github.com/armbian/build/tree/armbian-next in case it will produce working images. After the merge we are going directly into code freeze / bug fix only phase. https://docs.armbian.com/Process_Release-Model/#release-testing There are a lot of changes and this is the only sane way to integrate this big chunk of code.

 

I think we should do exactly the opposite.
As soon as the author realizes that his codebase has begun to create stable images for the family\branch, he can invite the most active members of this group to test and fix bugs.

That is, errors, changes must be made in this branch. While the master should remain stable and not create problems for the current work.

[going]

I made the first attempt to test the branch https://github.com/armbian/build/tree/armbian-next .
Unsuccessful.

...
[🌱] Kernel build starting [ kernel/arm64__5.15__sunxi64 ]
[🌱] Getting sources from Git [ unused:set via GIT_FIXED_WORKDIR linux-5.15.y ]
[🌿] Creating local copy [ unused:set via GIT_FIXED_WORKDIR linux-5.15.y ]
[🌱] Downloading Git cold bundle via HTTP [ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle ]
...
[👉]    Resolving mirrors.edge.kernel.org (mirrors.edge.kernel.org)... 147.75.101.1, 2604:1380:2001:3900::1 
[👉]    Connecting to mirrors.edge.kernel.org (mirrors.edge.kernel.org)|147.75.101.1|:443... connected. 
[👉]    HTTP request sent, awaiting response... 200 OK 
[👉]    Length: 2530673996 (2.4G) [application/octet-stream] 
[👉]    Saving to: ‘/home/leo/build/cache/gitbundles/cold/dda92618d5138e315cf9b5031c20a936.gitbundle’ 
[👉]         0K ........ ........ ........ ........  1% 1.83M 21m44s 
[👉]     32768K ........ ........ ........ ........  2% 2.37M 18m58s 
[👉]     65536K ........ ........ ........ ........  3% 2.35M 17m58s
...

The connection is broken on my side by the provider.

Three subsequent attempts were unsuccessful.

An attempt to download 460 megabytes already downloaded ends with a server failure and the program waits 10 seconds. Then again an unsuccessful replay.

 

I had to delete a partially downloaded file.

A 2.4GB file is excruciatingly long for my connection.

 

Fantastic! On the fifth attempt, he coped.

 

The compilation process has started

 

[👉]    E: Failed getting release file http://localhost:3142/ports.ubuntu.com/dists/focal/Release 
[👉]    -->--> command failed with error code 1 after 1 seconds 
[👉]    --> 🐛 4430: 24605 - 24605 - 24605: ehBE: debug: Error-related files found [  ] 
[👉]    --> 💥 4430: 24605 - 24605 - 24605: ehBE: err: error: Debootstrap first stage failed 

 

The log file brought special joy:

[🌿] Build log file [ /home/leo/build/output/logs/armbian-logs-4775c623-741d-4662-87fd-f4d1da533e6f.html ]

From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable
 * [new tag]                   v2.6.12           -> v2.6.12 
 * [new tag]                   v2.6.12-rc2       -> v2.6.12-rc2 
 * [new tag]                   v2.6.12-rc3       -> v2.6.12-rc3 
 * [new tag]                   v2.6.12-rc4       -> v2.6.12-rc4 
 * [new tag]                   v2.6.12-rc5       -> v2.6.12-rc5 
 * [new tag]                   v2.6.12-rc6       -> v2.6.12-rc6 
 * [new tag]                   v2.6.13           -> v2.6.13 
 * [new tag]                   v2.6.13-rc1       -> v2.6.13-rc1 
 * [new tag]                   v2.6.13-rc2       -> v2.6.13-rc2 
 * [new tag]                   v2.6.13-rc3       -> v2.6.13-rc3 
 * [new tag]                   v2.6.13-rc4       -> v2.6.13-rc4 
 * [new tag]                   v2.6.13-rc5       -> v2.6.13-rc5 
 * [new tag]                   v2.6.13-rc6       -> v2.6.13-rc6 
 * [new tag]                   v2.6.13-rc7       -> v2.6.13-rc7 
 * [new tag]                   v2.6.14           -> v2.6.14 

 

 

For me, this branch is a very difficult and expensive case in terms of support.

[Igor]

17 hours ago, going said:

An attempt to download 460 megabytes already downloaded ends with a server failure and the program waits 10 seconds. Then again an unsuccessful replay.

 

We were blocked twice by kernel.org (still blocked) because our CI is generating too much requests. We need to establish https://kernel.org/best-way-to-do-linux-clones-for-your-ci.html and this mechanism is moving into this direction. 

 

17 hours ago, going said:

A 2.4GB file is excruciatingly long for my connection.

 

Current mechanism is also broken. When using Google mirrors:

 

[ o.k. ] Checking git sources [ linux-mainline/5.17 https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stableorigin/linux-5.17.y ]
[ o.k. ] Add original git sources [ linux-mainline/5.17 origin/linux-5.17.y ]
fatal: Server does not support --shallow-exclude
fatal: the remote end hung up unexpectedly
fatal: Server does not support --shallow-exclude
fatal: the remote end hung up unexpectedly
fatal: Server does not support --deepen
fatal: the remote end hung up unexpectedly
fatal: Server does not support --deepen
fatal: the remote end hung up unexpectedly
Nothing new to pack.
remote: Sending approximately 2.59 GiB ...

 

17 hours ago, going said:

For me, this branch is a very difficult and expensive case in terms of support.

I am sure there are bugs but it also solves many problems we have in the current script. We are not merging at all costs, but we have to try. 

[rpardini]

Here's some info on armbian-next status:

- In development since October/2021 (thus 7 months)
- Currently sitting at 189 commits, almost all lib/**/*.sh files are changed.
- More than 17 rounds of manual merges performed manually against master. Sometimes we have 1-2 weeks of delay, but it's mostly master-equivalent. Each round takes 2-5 hours of carefully reviewing every commit that landed on master and maybe rewriting it.
- Huge changes around logging and error control. Errors now stop the build. Logs contain actionable information.
- Rewritten kernel building and packaging. There's no more packaging patches or builddeb hacks. Kernel-headers support cross compiles across all arches. No more byteshift patch. Still needs tuning.
- Completely changed git handling, specially for kernel. This still needs handling of previously git://, now http:// bundle downloading as reported above, and caching.
- Patch hashing is half-rewritten, still needing work. Now same code can both actually patch and produce hashes, making it consistent. "fasthash"
- apt-cacher-ng configuration for local usecase is now under Armbian control.
- 100% working without any external/downloadable toolchains.
- full support for building any arch under any other arch, including "reverse cross-compiles" and running of rkbin/fip x86-only binaries.
- source code is now properly formatted according to shellfmt, and 90% of shellcheck warnings are squashed. A lot remains still.
- 20x faster kernel rebuilds, 2-3x faster full builds due to consolidated make invocations, benefitting from bintree caching as well as ccache.
- most compression points changed to zstd, yielding multicore (de-)compression and thus much faster image building during cache hits.
- full support for DKMS modules, eg nvidia-drivers and ZFS, under any cross compile scenario.
- data channel for metadata communication, config extraction, matrix generation etc by having stdout clean for machine data. logs to stderr.
- per-build TMPDIR affecting and protecting all `mktemp` invocations
- all traps rewritten under a cleanup/trap manager.
- full HTML-based, single-file, full build log artifact. no more output/debug.
- many others I forget.

 

All that said, I've still a ton of stuff pending before this can 100% replace current master:
- EXTRAWIFI-style manual patching of things is not idempotent nor proven working with "fashhash" and probably causes full kernel recompiles, negating previous benefits until fixed.
- (server-based) Caching of warm/cold git bundles, to avoid people downloading 4gb+ of git sources.
- kernel-headers will probably be unified with kernel-sources, since they contain mostly the same stuff.
- extra-buildpkgs is not touched nor run, and safe to assume needs lots of work.
- certain CI-only build ops like "rebuild roofs only" and "build all BSPs" and "build all u-boots" never run so probably won't work.

Some few brave souls like @NicoD, @Rich Neese, and @going have actually tried armbian-next and every single try there's stuff to fix, thanks for trying and reporting.

TL,DR: armbian-next is doing well, thanks. Work continues. It might not be ready for merge, will it ever be? I will keep it rebased as much as possible. There's no pressure. Try it out, and report. Thanks!

 

[Igor]

1 hour ago, rpardini said:

- certain CI-only build ops like "rebuild roofs only" and "build all BSPs" and "build all u-boots" never run so probably won't work.

If you mean build-all way, then this is deprecated. CI now generate all packages from the outside. If its possible, for example, generate BSP package or U-boot package only and skip generating the rest, job is done.

 

1 hour ago, rpardini said:

extra-buildpkgs is not touched nor run, and safe to assume needs lots of work.

This is rarely used but we should have this (or some other way) to generate packages from sources. Within chroot ...

 

1 hour ago, rpardini said:

(server-based) Caching of warm/cold git bundles, to avoid people downloading 4gb+ of git sources.

Would be sane to place bundles to our servers and how much space / resources we would need for that?

 

my 2c

[going]

Igor, I didn't say the main thing. Spring has come in our area where I live. Every day adds new worries.

I will switch off from the development process in 10 days.

I will only be able to support the process of applying patches for sunxi.

 

3 часа назад, Igor сказал:

We were blocked twice by kernel.org (still blocked) because our CI is generating too much requests

This is the imperfection of our own algorithms. We upload the same thing to the build server many times.

This is the first in line for a fix.

I've been trying to fix something in my repository, but I don't understand this code well and I'm doing even worse than it was. But perhaps we can discuss the algorithm in words?

 

3 часа назад, Igor сказал:

Current mechanism is also broken. When using Google mirrors:

I do not know how to defeat the monster.
Probably just to get away from him on github?

 

Once a few years ago I was tracking this:

https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.4               285K

https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.17.4.tar.xz               122M

Downloading 120-150 MB, checking and unpacking is fast.

This is a ready-made archive and it is distributed for download.

 

[Igor]

19 minutes ago, going said:

Igor, I didn't say the main thing. Spring has come in our area where I live. Every day adds new worries.

I will switch off from the development process in 10 days.

I will only be able to support the process of applying patches for sunxi.

Understand. I will do my best to lower the impact of those change to everyone involved. We are all involved in many things and our work is important for other people too. We don't want to generate them pain by providing tool that is crippled / unmatured.

 

25 minutes ago, going said:

This is the imperfection of our own algorithms.

I agree. We have to improve our caching systems. No other way. 

 

27 minutes ago, going said:

I do not know how to defeat the monster.

Neither I, but together we will win  

[rpardini]

This is deviating from the main subject, but just to clarify a bit what armbian-next is trying to do with kernel's git:

 

- First: it knows the main version (eg: 5.15, 5.16) of every kernel to be built, even if it's not from mainline sources, for example vendor source, say a legacy. Idea was taken from sunxi; I've modified every family to have that information (similar, but not identical, to KERNELBRANCH)

- When fetching kernel sources, say for 5.15, it will:

  - check for 5.15 git bundle "warm" cache. if found, fetch from it and skip down to item X. if not, continue. (point of interest "1".)

  - check for Torvald's git "cold" cache. if found, fetch from it. if not, download it via HTTP+CDN from kernel.org's non-git mirrors, then fetch from it. this is slow, error prone, and many gigabytes; it has all "master" history, but not stable branch history.

  - "X": add a 2nd remote which is stable kernel git from whatever mirror we want. fetch the latest 5.15.y from it, and all stable tags too. this is always done even if non-mainline kernel.

  - if warm bundle for 5.15 does not exist yet: export it, in the process making it shallow before 5.15-rc1. include tags. (produced warm bundle is around 300mb and super fast to fetch from) - (point of interest "2") 

  - (if non-mainline kernel) add a 3rd remote "origin" and fetch from it, just like we did before. this fetch is now in order of few megabytes or even a few kilobytes.

 

With this we end up with something that does 0 shallow fetches from remotes (which is what kernel.org wants from us) but in the end is both shallow and contains tags that are useful for maintainers.

The main improvement needed here are "point of interest" 1 and 2: those could try to offer "ready-to-go",  around 300mb, shallowed-with-tags files that could be cached and offered to users just like we do for rootfs caches. So with 300mb we end up with a very usable git tree instead of a tarball of just-source for half of that.

The fact that the bundles age (and are out of date) is irrelevant, since we always fetch (only differences, never shallow) from remotes, so it's easy to update.

 

I am investigating using freely available resources (eg: OCI registries on Github) to store and fetch those "gitbundle caches" so that people don't have to suffer the 4gb marathon that is fetching from torvald's bundle.

 

 

 

 

[schwar3kat]

I'm building from the armbian-next branch for testing and I'm finding the experience quite unfamiliar and a little annoying.   It does seem faster though.

Orangepizeroplus (H5) built successfully for current, jammy and the image produced worked. I suspect that other flavors will build okay for testing.
but it errored after building the image [] Error occurred [ code 23 at /root/build-armbian/rc/build/lib/functions/logging/runners.sh:134

Orangepi-r1plus-lts (rockchip64 RK3328) built successfully for current, jammy.  No build errors.

Orangepi-r1 (H2) build system failed near the end.  019.000.create_board_package.log
--> 🛠1272: 1319406 - 1319406 - 1319406: ehBE: debug: Running family_tweaks_bsp [ sunxi ]
--> 🧽 1272: 1319406 - 1319406 - 1319406: ehBE: trap: main_trap_handler [ ERR and 1 trap_manager_error_handled: ]
The annoying 6.8 MiB html log file is a pain to parse. 

I guess that the build system enhancement issues will be picked up and dealt with separately and should probably not have bugs logged by SBC testers, or should I be logging bugs?

Can I switch off the time wasting and annoying markdown / html logging behaviour?
I don't want caterpillars, butterflies ants, bunches of leaves and comic explosions that don't make anything clearer and are unnecessary annoyances that don't play nicely with my tools.
LOG_ENABLE_EXTENSION=no, didn't do it.
Is it possible to keep the split .tmp files on error / build fail?

[rpardini]

9 hours ago, schwar3kat said:

Orangepi-r1 (H2) build system failed near the end

 

Thanks, a pesky short-circuit bug was leftover in sunxi_common at the end of family_tweaks_bsp. Fixed. Please pull and try again...

 

9 hours ago, schwar3kat said:

Can I switch off the time wasting and annoying markdown / html logging behaviour?
I don't want caterpillars, butterflies ants, bunches of leaves and comic explosions that don't make anything clearer and are unnecessary annoyances that don't play nicely with my tools.

 

Will be possible (and default) soon. Real Logs are now produced inside the WORKDIR (in .tmp) in text + ANSI colors format, and during cleanup, processed and aggregated into a single file HTML.

This has brought joy to some and hatred to others. Sorry to offend your sensibilities...

But do expand on "don't play nice with my tools", which tools? We wanna play nice.

 

9 hours ago, schwar3kat said:

Is it possible to keep the split .tmp files on error / build fail?

 

Yes. `PRESERVE_WORKDIR=yes` won't cleanup the workdir in .tmp -- this leaves over a gigabyte of stuff but should be safe.

Also `PRESERVE_SDCARD_MOUNT=yes` will preserve $SDCARD, $MOUNT (and thus $LOOP) -- take much care in this case, things are left mounted and you can easily shoot yourself in the foot (eg, destroy your host) if use this and is not careful.

 

Other interesting things you might like

- `SHOW_LOGS=yes` shows the output of run commands

- `SHOW_COMMAND=yes` shows the invocation of each said command

 

Thanks for trying and reporting!

[rpardini]

People, I feel bad about hijacking this thread with armbian-next stuff. Could someone with forum-fu move armbian-next related posts to its own thread? Maybe in a contributor-only forum?

[Werner]

topic split

[schwar3kat]

14 hours ago, rpardini said:

Yes. `PRESERVE_WORKDIR=yes` won't cleanup the workdir in .tmp

Thanks for the response @rpardini
I tried this, it seems to preserve the build artifacts, but not the logs, which seem to be created in .tmp/logs-......./
The text logs, split up into manageable chunks, are what I'm after.
I tried 'PRESERVE_LOGDIR=yes' just in case there was such a thing but no such luck.

On a new git clone:
Orangepi-r1 built to completion after your change, but I noticed another minor issue:  Repeat Build Options left out 'BOARD=orangepi-r1'
[✨] Repeat Build Options [ ./compile.sh   BRANCH=current RELEASE=jammy BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=img ]
 

[balbes150]

I am currently trying to test the armbian-next branch for a native build (directly on the rk3399 device) using Jammy version 22.04. This Ubuntu version uses gcc-11 by default, which causes the u-boot-2017 build problem. I installed gcc-10 from the rep, tried to set a variable to limit the version of gcc used. But when starting the build, this variable is ignored. Maybe I'm using the wrong syntax. How to set the variable (restriction) of the GCC version correctly, so that the u-boot build uses a version no older than 10?

 

UBOOT_USE_GCC='< 11.0'

[Igor]

Quote

Downloading Git cold bundle via HTTP [ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle ]

 

@rpardini 

 

• I am still blocked  Can't use bundles from git.kernel.org ...  USE_MAINLINE_GOOGLE_MIRROR="yes", what about other mirrors?
• we should exit if HOST is less them Jammy, since Git is too old. 
• Clearfog (current) fails at compiling u-boot (we can't go up with u-boot, too much work)
• Cubox fails at compiling u-boot (we can't go up with u-boot, too much work)
• Helios, kernel breaks when using Google mirror with:
  Spoiler

  [🌱] Fetching from cold git bundle, wait [ dda92618d5138e315cf9b5031c20a936 ]
  [💥]     👇👇👇 Showing logfile below 👇👇👇 [ /home/build/build/.tmp/logs-b819bf22-7124-45fb-b6b2-4e7b007b865a/007.000.kernel_prepare_git.log ]
  [👉]    --> 🦋   51: 22578 - 22578 - 22578: ehBE: group:  [ <kernel_prepare_git> ] 
  [👉]    --> 🔖   51: 22578 - 22578 - 22578: ehBE: git: Downloading sources [ kernel ] 
  [👉]    --> 🔖   51: 22578 - 22578 - 22578: ehBE: git: fetch_from_repo [ https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable unused:set via GIT_FIXED_WORKDIR branch:linux-5.15.y yes ] 

   

I'll also try to dig into the code if I can find something ...

[Igor]

https://github.com/armbian/build/commit/a712d7aebc39f16484b9eb787b23b445e6c76732

7th version of rockchip kernel ?

 

config/templates/config-docker.conf is not merged well

lib/functions/compilation/patch/kernel-drivers.sh (behind / merged wrong , we have GITHUB as variable not hardcoded for those sources)

It is difficult to review functions that were split into new files, but I would propose to:
- fix known bugs, resolve wireless / kernel-drivers hast to work (not optimal also fine) ... then open a merge request so we can start reviewing properly.

[balbes150]

Trying to use the NEXT version causes a lot of errors. I have checked different combinations of images and settings (with disabling all package caching), but all options end in errors.

One of the logs of the simplest build for Jetson Nano.

https://disk.yandex.ru/d/QU9K-1RjLmaVVQ

[rpardini]

On 4/25/2022 at 6:38 PM, Igor said:

I am still blocked  Can't use bundles from git.kernel.org ...  USE_MAINLINE_GOOGLE_MIRROR="yes", what about other mirrors?

@Igor Hmm this will be a challenge. Are you sure you can't download the bundles, or is some other error? Send me a log file please?

I'll find a way, if the bundle can't be downloaded, to revert to fetching from origin, so Google mirror can be used. I guess folks in China and others might need that as well.

Also if I ever get around to the gitbundle caching storing in docker layer in GCHR.IO, we could have a workflow that publishes ready-to-go, 300mb gitbundles for each version (5.15 / 5.17 etc) and solve this once and for all.

 

I've thought and studied a lot about this problem, and there' s another possible, although very different, solution: using a single, shared `.git` tree with all remotes and all branches, huge, possibly seeded by bundle, for all kernels, and then for each built kernel, a separate working copy. See https://git-scm.com/docs/git-worktree -- this would be even more complex to manage than already, but would be more efficient when building say more than 2/3 kernels, and much more efficient when building many different versions (eg 4.19 / 5.15 / 5.17). But that is maybe for armbian-next-next. 

 

 

On 4/25/2022 at 6:38 PM, Igor said:

we should exit if HOST is less them Jammy, since Git is too old

 

Thanks, will investigate, I am still building in Impish and is somehow working... 

 

On 4/25/2022 at 6:38 PM, Igor said:

• Clearfog (current) fails at compiling u-boot (we can't go up with u-boot, too much work)
• Cubox fails at compiling u-boot (we can't go up with u-boot, too much work)

 

Those are very interesting. I will investigate. I've small patches to make compatible with newer gcc for some other families, like xu4, so I have hope.

 

On 4/25/2022 at 7:40 PM, Igor said:

7th version of rockchip kernel ?

 

Ooops, this was not supposed to be included in armbian-next, was trying to reproduce some boards that used to work 1/2 years ago but no longer boot. I do think BRANCH=classic, generally 5.10.y, is a good idea, but armbian-next is not the place for this.

 

On 4/25/2022 at 7:40 PM, Igor said:

config/templates/config-docker.conf is not merged well

lib/functions/compilation/patch/kernel-drivers.sh (behind / merged wrong , we have GITHUB as variable not hardcoded for those sources)

 

Yeah. I've too many manual merges and at a certain point I lost track. The fact that our docker support uses a "docker" config file that itself re-launches the build inside docker is very confusing. The template-copying style of this is also hard to maintain...

At a certain point I thought to rewrite, never did, and merges were sloppy. I will review. My bad.

 

Regarding kernel-drivers.sh, this is one of my main to-do items.

I've good progress on 'fasthash' (which is required for kernel-drivers) so this is getting close to doable. Will keep you posted.

 

On 4/26/2022 at 11:52 AM, balbes150 said:

Trying to use the NEXT version causes a lot of errors. I have checked different combinations of images and settings (with disabling all package caching), but all options end in errors.

 

@balbes150 thanks for your tests and posting the logs. These errors were a bit unrelated and came from master, "nala" package which was added by "desktop" sources, and desktop sources were included in CLI builds in master. Dunno if really intended...

Since I rebase irregularly sometimes this was fixed fast in master but -next lagged quite a bit.

I've disabled this in armbian-next (sources only added for desktop builds again) but will lead to discussions, since it was already accepted into master, and armbian-next already breaks a lot of other stuff.

Those kind of changes are marked *breaking change* in the commits in armbian-next when I can identify them. There's quite a few.

 

------------------

 

To all here: thanks a lot for the tests and reporting the problems. 

I have already started a huge rebase against master, fixing a few things and doing a few CI runs to catch the more obvious problems.

Also rebasing showed frozen kernel tags, armbian-next has all that is needed to do that externally now, so also working some long overdue features.

Will post when it's pushed!

 

[Igor]

10 hours ago, rpardini said:

Are you sure you can't download the bundles, or is some other error? Send me a log file please?

Ban is still in place  I am writing an email right now. In general it would be better to use Google mirror primarily. Or we need to use kernel.org Git for bundles?

 

10 hours ago, rpardini said:

I've thought and studied a lot about this problem, and there' s another possible, although very different, solution

You mean like having our own full kernel mirror?

 

10 hours ago, rpardini said:

Those are very interesting. I will investigate. I've small patches to make compatible with newer gcc for some other families, like xu4, so I have hope.

I would not push on moving everything to distro compilers at once. What works, works and we do this gradually. Going on half now, removing them all in one year. Something like that. Even today, sometimes we will need to deal with a special compiler, so support has to remain. And a few of them if there is too much work with adopting the code.

Thanks for update. Will do another cycle of review when possible.

[rpardini]

Ok, a weekend later, here's armbian-next v64. 

https://github.com/armbian/build/commits/armbian-next - do `git pull --rebase` and build away and report problems here 😉

 

Builds are green. https://github.com/rpardini/armbian-release/actions/runs/2289642908

Images are up for download: https://github.com/rpardini/armbian-release/releases/tag/20220508d

(a few novelties there. eg, ODROID-M1)

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

8 hours ago, Igor said:

I would not push on moving everything to distro compilers at once. What works, works and we do this gradually. Going on half now, removing them all in one year. Something like that. Even today, sometimes we will need to deal with a special compiler, so support has to remain. And a few of them if there is too much work with adopting the code.

 

No fun in that @Igor😉 -- I've fixed the Makefiles for cubie-i and clearfog u-boot so they build. Those were exactly the same problem as from xu4: 2017/2018 u-boot, that original Makefile wanted "armv5" target which does not exist anymore in newer gccs. https://github.com/armbian/build/commit/0a3fc81b5e519a11ac41c1d196b076a91ce38a1b

Most of those boards are actually armv7a, so I patched and they built. If they _work_, we'll only know if some of you download the above images and try it out (cubie, clearfog, odroidxu4 at least). Thanks!

 

Many other changes/fixes and a few breaking ones, like removal of LIB_TAG/.ignore_changes for @lanefu

 

I've not tested desktop building so here's when @Rich Neese comes in, let me know.

 

Thanks for all the tests!

 

[Igor]

If you start on Jammy, 
https://github.com/armbian/build/blob/armbian-next/lib/functions/host/prepare-host.sh#L46

is no more.

Also office unblocked at kernel.org

[rpardini]

On 4/25/2022 at 6:38 PM, Igor said:

we should exit if HOST is less them Jammy, since Git is too old.

23 minutes ago, Igor said:

If you start on Jammy, 
https://github.com/armbian/build/blob/armbian-next/lib/functions/host/prepare-host.sh#L46

is no more.

 

Ahn, ok, this is recent addition for 1 runner that was failing uboot, I thought you meant GIT version.

We'll have a hard time without python2 for those old uboots, so it's a symptom of shit to come.

But thanks for the catch, I'll fix that ASAP, and probably more when I move builders to Jammy.

 

 

27 minutes ago, Igor said:

Also office unblocked at kernel.org

 

I still couldn't find time to work on this. 

 

 

[rpardini]

1 minute ago, rpardini said:

We'll have a hard time without python2 for those old uboots

 

Nah, Jammy has python2, it does not have python-is-python2 gimmick which just symlinks or update-alternatives.

I'll have to hack around this manually.

[schwar3kat]

On 5/9/2022 at 4:21 AM, rpardini said:

here's armbian-next

 

I watched the video of the Armbian developers meeting 1/4/2023 and it looks like you want testing. 
Not sure where to post this.  Please feel free to move it.

I tested the armbian-next branch build for a couple of my boards.
The build computer is Linux Mint 20.3 (Una) has a dedicated separate drive for Armbian builds and works well for current armbian build.
The build errors as per attached.
Is this a known issue or perhaps I don't understand something?

build_output.txt

armbian-build-2500d172-dffc-4a16-97c4-3b509abcbd0f.ansitxt.log armbian-build-2500d172-dffc-4a16-97c4-3b509abcbd0f.md

[going]

@schwar3kat A good place to discuss. Please add echo "$(git diff)" here. I am interested in whether or not new files appeared in the build system after you started it to run?

 

 

@rpardini Please explain why this is in the log:

....
--> 🦋    1: 2382876 - 2382876 - 2382876: ehBE: ....
--> 🧽    1: 2382876 - 2382876 - 2382876: ehBE: ....
--> 🧽    1: 2382876 - 2382876 - 2382876: ehBE: ....
....

And what does it mean, how can I understand the meaning?

[going]

Скрытый текст

'BOARD': '(empty)' --> 'orangepi-r1' early
'RELEASE': '(empty)' --> 'bullseye' early
Applying cmdline param 'CREATE_PATCHES': '(empty)' --> 'no' early
Applying cmdline param 'BUILD_MINIMAL': '(empty)' --> 'yes' early
Applying cmdline param 'BUILD_DESKTOP': '(empty)' --> 'no' early
Applying cmdline param 'KERNEL_ONLY': '(empty)' --> 'no' early
Applying cmdline param 'BRANCH': '(empty)' --> 'current' early
Applying cmdline param 'KERNEL_CONFIGURE': '(empty)' --> 'no' early
Starting single build process orangepi-r1
Sourcing board configuration/mnt/data/build-armbian/armbian-next/build/config/boards/orangepi-r1.conf
Starting main configuration
Sourcing family configuration /mnt/data/build-armbian/armbian-next/build/config/sources/families/sun8i.conf
Enabling extension sunxi-tools
Sourcing arch configuration armhf.conf
Extension manager processed 3 Extension Methods calls and 3 Extension Method implementations

Traceback (most recent call last):
  File "/mnt/data/build-armbian/armbian-next/build/lib/tools/aggregation.py", line 165, in <module>

output_lists: list[tuple[str, str, object, object]] = [
TypeError: 'type' object is not subscriptable
Showing logfile below /mnt/data/build-armbian/armbian-next/build/.tmp/logs-2500d172-dffc-4a16-97c4-3b509abcbd0f/002.000.prepare_host_basic.log
group:  [ <prepare_host_basic> ]
debug: basic-deps are already installed on host [ nothing to be done ]
group:  [ </prepare_host_basic> in 0s ]
debug: Executing final CLI command [ build ]
debug: Calling run function for command [ build: cli_standard_build_run ]
info: Starting single build process [ orangepi-r1 ]
info: Sourcing board configuration [ /mnt/data/build-armbian/armbian-next/build/config/boards/orangepi-r1.conf ]
debug: Already set BRANCH, skipping interactive [ current ]
info: Starting main configuration [  ]
debug: DEST_LANG... [ DEST_LANG: en_US.UTF-8 ]
debug: Using host's /etc/timezone for [ TZDATA: Pacific/Auckland ]
debug: .deb compression [ DEB_COMPRESS=none ]
info: Sourcing family configuration [ /mnt/data/build-armbian/armbian-next/build/config/sources/families/sun8i.conf ]
other: Enabling extension [ sunxi-tools ]
debug: Sourcing common arch configuration [ common.conf ]
info: Sourcing arch configuration [ armhf.conf ]
debug: Initializing EXTENSION_MANAGER_TMP_DIR [ /mnt/data/build-armbian/armbian-next/build/.tmp/extensions-2500d172-dffc-4a16-97c4-3b509abcbd0f ]
cleanup: Add callback as cleanup handler [ cleanup_handler_extensions ]

extensions: Initializing EXTENSION_MANAGER [ initializing extension manager ]
extensions: Extensions hook point [ build_host_tools ]
extensionstrace: Extensions hook_point_functions_pre_sort [ compile_sunxi_tools ]
extensionstrace: Extensions hook_point_functions_sorted_by_sort_id [ 500_compile_sunxi_tools ]
extensionstrace: Extensions hook_point_functions (final sorted realnames) [ compile_sunxi_tools ]
extensions: Extensions hook_point: build_host_tools will run 1 functions [ 1 ]
extensions: Extensions hook point [ fetch_sources_tools ]
extensionstrace: Extensions hook_point_functions_pre_sort [ sunxi_tools ]
extensionstrace: Extensions hook_point_functions_sorted_by_sort_id [ 500_sunxi_tools ]
extensionstrace: Extensions hook_point_functions (final sorted realnames) [ sunxi_tools ]
extensions: Extensions hook_point: fetch_sources_tools will run 1 functions [ 1 ]
extensions: Extensions hook point [ run_after_build ]
extensionstrace: Extensions hook_point_functions_pre_sort [ 999_finish_extension_manager ]
extensionstrace: Extensions hook_point_functions_sorted_by_sort_id [ 999_finish_extension_manager ]
extensionstrace: Extensions hook_point_functions (final sorted realnames) [ 999_finish_extension_manager ]
extensions: Extensions hook_point: run_after_build will run 1 functions [ 1 ]
info: Extension manager [ processed 3 Extension Methods calls and 3 Extension Method implementations ]
extensions:
    Extension Method 'post_family_config' being called from [
    cli/entrypoint.sh:155
    -> cli/utils-cli.sh:126
    -> cli/cli-build.sh:12
    -> main/config-prepare.sh:93
    -> configuration/main-config.sh:255 ]

extensions: Extension Method being called: post_family_config [ hook: post_family_config ]
extensions: Extension Method being called: config_tweaks_post_family_config [ hook: config_tweaks_post_family_config ]
extensions: Extension Method 'post_family_config_branch_current' being called from [
    cli/entrypoint.sh:155
    -> cli/utils-cli.sh:126
    -> cli/cli-build.sh:12
    -> main/config-prepare.sh:93
    -> configuration/main-config.sh:263 ]

extensions: Extension Method being called: post_family_config_branch_current [ hook: post_family_config_branch_current ]
extensions: Extension Method 'user_config' being called from [
    cli/entrypoint.sh:155
    -> cli/utils-cli.sh:126
    -> cli/cli-build.sh:12
    -> main/config-prepare.sh:93
    -> configuration/main-config.sh:401 ]

extensions: Extension Method being called: user_config [ hook: user_config ]
extensions: Extension Method 'add_host_dependencies' being called from [
    cli/entrypoint.sh:155
    -> cli/utils-cli.sh:126
    -> cli/cli-build.sh:12
    -> main/config-prepare.sh:93
    -> configuration/main-config.sh:409
    -> host/prepare-host.sh:264 ]

extensions: Extension Method being called: add_host_dependencies [ hook: add_host_dependencies ]
extensions: Extension Method 'host_dependencies_known' being called from [
    cli/entrypoint.sh:155
    -> cli/utils-cli.sh:126
    -> cli/cli-build.sh:12
    -> main/config-prepare.sh:93
    -> configuration/main-config.sh:409
    -> host/prepare-host.sh:275 ]

extensions: Extension Method being called: host_dependencies_known [ hook: host_dependencies_known ]
debug: Extensions: prepare configuration [ extension_prepare_config ]
extensions: Extension Method 'extension_prepare_config' being called from [
    cli/entrypoint.sh:155
    -> cli/utils-cli.sh:126
    -> cli/cli-build.sh:12
    -> main/config-prepare.sh:93
    -> configuration/main-config.sh:412 ]

extensions: Extension Method being called: extension_prepare_config [ hook: extension_prepare_config ]

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.F6iHD86qBC' \
    'ASSET_LOG_BASE=/mnt/data/build-armbian/armbian-next/build/.tmp/logs-2500d172-dffc-4a16-97c4-3b509abcbd0f/002.' \
    '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=' \
    python3 /mnt/data/build-armbian/armbian-next/build/lib/tools/aggregation.py
]

trap: main_trap_handler [
ERR and 1 trap_manager_error_handled: short_stack:
    /mnt/data/build-armbian/armbian-next/build/lib/functions/logging/runners.sh:186
    ]

Showing logfile above /mnt/data/build-armbian/armbian-next/build/.tmp/logs-2500d172-dffc-4a16-97c4-3b509abcbd0f/002.000.prepare_host_basic.log

Error occurred in main shell code 1 at /mnt/data/build-armbian/armbian-next/build/lib/functions/logging/runners.sh:186
 run_host_command_logged_raw() --> ./lib/functions/logging/runners.sh:186
     run_host_command_logged() --> ./lib/functions/logging/runners.sh:169
      aggregate_all_packages() --> ./lib/functions/configuration/aggregation.sh:59
       do_main_configuration() --> ./lib/functions/configuration/main-config.sh:428
prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:93
      cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12
     armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:126
              cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:155
                        main() --> ./compile.sh:52
exited with code 1
/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.F6iHD86qBC'
'ASSET_LOG_BASE=/mnt/data/build-armbian/armbian-next/build/.tmp/logs-2500d172-dffc-4a16-97c4-3b509abcbd0f/002.'
'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='
python3 /mnt/data/build-armbian/armbian-next/build/lib/tools/aggregation.py

stacktrace for failed command run_host_command_logged() --> ./lib/functions/logging/runners.sh:169
      aggregate_all_packages() --> ./lib/functions/configuration/aggregation.sh:59
       do_main_configuration() --> ./lib/functions/configuration/main-config.sh:428
prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:93
      cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12
     armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:126
              cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:155
                        main() --> ./compile.sh:52

Error occurred in main shell code 1 at /mnt/data/build-armbian/armbian-next/build/lib/functions/logging/runners.sh:169
     run_host_command_logged() --> ./lib/functions/logging/runners.sh:169
      aggregate_all_packages() --> ./lib/functions/configuration/aggregation.sh:59
       do_main_configuration() --> ./lib/functions/configuration/main-config.sh:428
prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:93
      cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12
     armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:126
              cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:155
                        main() --> ./compile.sh:52

Cleaning up extension manager
Archiving old logfile armbian-build-5036b938-b30a-48fe-b3b0-8f8c3dd0db81.ansitxt.log
Archiving old logfile armbian-build-5036b938-b30a-48fe-b3b0-8f8c3dd0db81.md
Built ANSI log file /mnt/data/build-armbian/armbian-next/build/output/logs/armbian-build-2500d172-dffc-4a16-97c4-3b509abcbd0f.ansitxt.log

 

I cleaned part of the log from the husk that prevented reading. But I didn't understand what the mistake was.
I guess I'll have to do this every time I get an error and try to read the log.
Is that true?

What is the sacred meaning of typing the same message 2 and 3 times?

[atone]

@rpardini it seems that @schwar3kat has the same issue as @balbes150 with python3 here

 

Sorry, no. it's another issue.

[rpardini]

Hi, thanks again @schwar3kat for testing.

You've hit a snag with the Python3 version. I've been using type annotations, which are not supported under all Python versions.

I have not tested this under MINT UNA -- is there a Docker image for it? 

I will push fixes soon and let you know.

The actual error is (only visible on your screen, not in the logfile, see below for why):

 

    output_lists: list[tuple[str, str, object, object]] = [
TypeError: 'type' object is not subscriptable

 

@going and others, ref the logging:

 

In this specific case (error during early configuration), the logging to file was not working as intended.

That happens because capturing stdout/stderr while at the same time possibly running an interactive program (like `dialog`) does not work.

I have further split the config into more functions, which are individually logged, so that we can get the actual error in the logs (not only on screen).

 

Ref the log format: it's crazy, I know, and not good yet. I will try to make it more useful / readable / complete with your feedback.

Just for info, here's what the current format means:

 

taking for example 

--> 🐛    1: 2382876 - 2382876 - 2382876: ehBE: debug: Already set BRANCH, skipping interactive [ current ]

- --> is a display_alert.  All levels (even debug) are logged to the log file. Lines without it are the output of an external tool / program being run.

- 🐛 is the emoji corresponding to the logging level (debug, see below); I think I will remove these from log file since everyone hates them

- 1:  is ${SECONDS} -- thus the number of seconds since the build started. (useful? I dunno)

- 2382876 - 2382876 - 2382876 : are $$, caller BASH_PID, the current BASH_PID  (unuseful, unless you're debugging a terribly gnarly issue due to sub-shells. not for normal people...)

- ehBE is $- (thus the bash setopts active at that moment, again, unuseful unless you're debugging very complex things like shortcircuits, use of $(), etc etc)

- debug is the display_alert logging level (has a corresponding emoji)

- the rest is the 1st and 2nd display_alert arguments.

 

My proposal is to reduce this drastically just to:

 

--> DEBUG: (1:)  Already set BRANCH, skipping interactive [ current ]

 

 and also remove all ANSI-color from the logs so it can be read without a terminal.

[going]

2 часа назад, rpardini сказал:

taking for example 

Thanks for the clarification.
If you think all this information is necessary for debugging, then you can try to enter the key "VERBOSE" and set it to "0" by default.
In this case, the log will contain only brief messages about the execution stage.
If "1" then the values of the variables for this stage are added (not all).
If "2", then the name of the execution stage function and the place from which it was called are additionally printed.
And then up to the number "7".
But I think this is somewhat superfluous for such a simple script as the armbian build system.

 

2 часа назад, rpardini сказал:

My proposal is to reduce this drastically just to:

 

--> DEBUG: (1:)  Already set BRANCH, skipping interactive [ current ]

 

 and also remove all ANSI-color from the logs so it can be read without a terminal.

This particular message is not necessary at all.

 

# ARGs: 'BOARD=orangepi-r1' 'BRANCH=current' 'RELEASE=bullseye' 'BUILD_MINIMAL=yes' 'BUILD_DESKTOP=no' 'KERNEL_ONLY=no' 'KERNEL_CONFIGURE=no' 'CREATE_PATCHES=no'

This is printed at the very beginning. That's enough.

 

 

If the build was successful, 90% of this log is not needed.
If I got an error, I need this error in the log. I need the name of the function and the file where the error occurred.

And that's probably it.

 

[going]

Probably this message printed once is enough. You have a good tracer.

Error occurred in main shell code 1 at /mnt/data/build-armbian/armbian-next/build/lib/functions/logging/runners.sh:186
 run_host_command_logged_raw() --> ./lib/functions/logging/runners.sh:186
     run_host_command_logged() --> ./lib/functions/logging/runners.sh:169
      aggregate_all_packages() --> ./lib/functions/configuration/aggregation.sh:59
       do_main_configuration() --> ./lib/functions/configuration/main-config.sh:428
prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:93
      cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12
     armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:126
              cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:155
                        main() --> ./compile.sh:52