rpardini

Great, very mature. Congratulations. Keep adding value by doing this, instead of writing 2-3 lines of text contributing something.

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

Hmm. 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. 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.

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.

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.

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

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. 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. 🎇 👍 Thanks for the insistence! 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. 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.

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.

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.

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. True, I've clearly marked commits to revert if this proves pointless / not worth it / too much more work.

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.

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. 🧑‍🚒

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.

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

Great bisect @swordow-- any indications on why those upstream changes break it? possibly, some change has to be done in the DT to accommodate. does 6.1 work? maybe said change is already done. Reverting the changes from upstream would be bad for other boards in the family ofc

Excellent news @usual user. I've bumped Armbian to 6.1 plus the DTS patches. My own image at https://github.com/rpardini/armbian-release/releases/download/20221213a/Armbian_20221213a-rpardini_Odroidm1_kinetic_edge_6.1.0.img.xz Igor has community images too, including desktops... https://github.com/armbian/community/releases (might be some 6.1-rcX still, should be updated the next few days). Any news about ATF and u-boot?

Yeah, you can convince Petitboot to `kexec` into Armbian's kernel. Probably can be done on other Petitboot boards too. By then, vendor's uboot, and vendor's kernel is already loaded, `kexec`'ing then into an Armbian mainline kernel. "It works" until it doesn't...