going

@ALIGMSTEN If you succeed with the configuration file, I will immediately add to the build system the construction of the current version of the htop package and configure it for our devices.

pkg libsensors-config : /etc/sensors3.conf /etc/sensors.d/ Now that Igor has cleared the repository of broken packages, you can install the system package and try to configure the library using this file

Unfortunately, the system package from this OS will not work properly for CPU temperature and frequency. I learned how to make the latest version from the developer's website: https://github.com/htop-dev/htop/releases/tag/3.2.1 But it shows the processor frequency not constantly, but with some different time intervals. The temperature does not show at all. The situation for today is like this. The old package that currently exists in the build system is either not being built (jammy) or is being built but does not work (Bullseye).

Hello Alistair. What operating system? Just delete this old one and install the one that comes with the system.

I have read the documentation published on the internet for this processor. But I did not find the characteristics of heat dissipation. I just assumed that you were able to find out this experimentally or learned this data from other sources. I also assumed that in the paper documentation attached to the radiator with a fan, the maximum power that it can divert into the air is written. I want to estimate the heat dissipation capacity for this processor before I purchase this device. Up to now, I have made do with simpler solutions for these small boards.

Can you post some technical specifications? The thermal dissipation power of this device. And for comparison, the maximum power allocated on the processor.

What I am observing here is not a lack of support for this particular armhf architecture. This is an incorrectly constructed construction algorithm in the assembly system itself. The analysis of the architecture that needs to be built and the architecture on which the build system started working looks pretty trivial and it already exists. To do this analysis and upload only what is required for this task does not look like something complicated. P.S. This also applies to the master.

Try some image of these: nanopineoplus2/archive

Thank you Oleg. This is the first firm opinion on whether we should create source packages or not. I want to ask everyone who reads this post to write a short message: 1) I don't need the source packages. 2) I need the source package. I use them. It depends on whether I will try to implement it.

Judging by what I got as a result of building the kernel and studying the log of the patch process, this is not the case. the system interferes with patches and changes them itself, without my permission. the build system should not interfere with patches and break their work. patch processing can be performed exclusively in interactive mode, as a separate function. during the build process, patches should not change in any way. Which of you two should I believe? Here I confirm that the script that analyzes patches, separates them and tries to apply them in parts, as well as the script that will create patches or commit to the code in the source repository should never be called during work the build system itself. Such scripts should be located in the tools folder, they should be called as independent and self-sufficient executable files.

We are talking about the kernel (DEB package with the kernel), which is installed in the image during build. Or do you propose to build only ROOTFS in this system ? IMHO this is the wrong approach. We are not building a source package, we are building a ready-made kernel and packaging it correctly in DEB. Here we are talking about all the packages that we collect and then send them to the repository. For a binary package, there must be a source package. And it should be in the repository. And if necessary, it can be uploaded to the native environment on the device or to the native environment that the developer can afford. For example, in a QEMU-based chroot.

lib/functions/host/prepare-host.sh

The problem is that these two people @rpardini, @going develop and implement some algorithms, each in their own sandbox. And this work is not coordinated in any way. When it comes time to show it to the whole community, problems begin. Agree Igor, the time has already been spent. And we have to rework the code. And this is time again. It takes less time to discuss and write documentation.

The target for all these features should be the source package. Next, we simply send it to a pre-deployed clean build environment and assemble binary packages. These are the details. I mean a more complex process. For example, we discuss and then describe in the documentation how the process of creating a log file and displaying it on the screen should look like. The developer who implements the new function reads this file and writes the code in such a way that the log looks as required in the documentation. Even if something is done in a completely different way in existing functions.

We need to describe the basic algorithm that we should approach. Then individual developers will not move in different directions.

Today we don't know how to build source packages. The one that exists for the kernel is not valid.

It looks like this discussion is starting to resemble a discussion of the basic algorithm of the build system? In that case, I will express my opinion. What does an ordinary Linux OS user do when he needs to rebuild a package with his fixes? It downloads the source package. It updates the original source code to a newer one and applies its own fixes. He collects packages. With this build procedure, it only needs dependencies for this package. I hope you understand me.

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.

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>

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"

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

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.

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

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

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?