going

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?

@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?

This question is for a philosophical conversation. Let's leave it hanging in the air.

For me, it's still vague. The topic requires study for me. I assume that there should be no development packages in the standard image. The fakeroot package alone is a security issue.

This image is assembled incorrectly. This error has been fixed in the build system to date. You need to uninstall the kernel header package. Then install the dependencies necessary for the build. apt-get install build-essential kmod debhelper devscripts After that, install the kernel header package again. @Igor I still have a question about why the kernel headers are installed in the standard image?

@atone The only option for changes can only be if we add an additional global variable that can be defined at the very beginning of the path, instead of having to program the value 500. For your case, 400-450 will be the optimal value. For my case, it will have a different meaning. If you make this fix, then I approve this pull request.

This is not a mistake. This is not a very good way to get around some of the providers' restrictions on the download speed for the end user. If the download speed is less than specified in the limit, then the connection breaks and an attempt is made to download from the following address. We can pre-check the speed of distribution from a specific address, but we will not be able to do a download speed check for your specific provider. For example, a provider can provide a high download speed for the first 50-100 megabytes from the download address, and then reduces the download speed to 20 kilobytes/sec. The existing algorithm in this situation allows for faster loading. The downside of this is getting error messages.

The chip operates at a voltage of 1.1V, and you have applied a voltage of 1.8V or vice versa, you have not applied enough voltage of 0.9V. You are trying to change the mode of operation of the chip and write a value to the register, but the register is mixed up and something else will change. You need to learn how to properly read the user documentation, the schematic diagram of the device. And learn how to compare the documentation and the device tree file. Sorry, the question is general - the answer is general.