Jump to content

armbian-next development


Recommended Posts

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.

Link to comment
Share on other sites

Armbian Linux community supported weekly builds download

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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!


 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 ;) 

Link to comment
Share on other sites

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.

 

 

 

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 ]
 

Link to comment
Share on other sites

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'

Link to comment
Share on other sites

  • Igor pinned this topic
Quote

 

@rpardini 

 

  • I am still blocked :P 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 ...

Link to comment
Share on other sites

  • Igor featured this topic

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

7th version of rockchip kernel :D?

 

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.

Link to comment
Share on other sites

  • Igor changed the title to armbian-next development
On 4/25/2022 at 6:38 PM, Igor said:

I am still blocked :P 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 :D?

 

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!

 

Link to comment
Share on other sites

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 :P 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.

Link to comment
Share on other sites

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!

 

Link to comment
Share on other sites

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:

 

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. 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...