going

Thanks. Did you mean a workable header package? I'll check it out tomorrow.

linux-mainline/orange-pi-5.12$ git diff scripts/package/builddeb ... With the patch, some of the archiving processes fail with an error and this can be seen in the compilation log. Somewhere at the very end.

@Igor I corrected the previous post. Now everything is in our hands. We can edit scripts right on the spot.

For me, this process was a few seconds. It is installed in the configuration: I ran a test build to check it. @Igor I picked up the stopwatch. P.S. The process took 1 min 39 sec. VM 6 threads 3.4 Ghz [ o.k. ] Done building [ /home/leo/build/output/images/Armbian_21.08.0-trunk_Bananapim64_focal_edge_5.12.6_minimal.img ] [ o.k. ] Runtime [ 26 min ] [ o.k. ] Repeat Build Options [ ./compile.sh BOARD=bananapim64 BRANCH=edge RELEASE=focal BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes COMPRESS_OUTPUTIMAGE=sha,gpg,img ] Check the contents of the archive file: /sys/kernel/kheaders.tar.xz Just compare the sizes for 5.10 and 5.12 I don't need it. I use the linux-headers-*package. That's the reason I didn't pay attention. I'll try to figure it out. The first suspicion is that in addition to archiving, there is also a process of recompilation for the target architecture in the scripts folder in one thread.

For comparison, two packages: linux-libc-dev, linux-headers ubuntu <-> AR-746

In AR-746 For packages linked by the same variable '$BRANCH', the three fields look like this: debs> for file in linux-*; do echo "$(dpkg -f $file | awk -v f=$file '/Package:|Version:|Provides:/{printf " %-31s", $2" "$3" "$4}')"; done linux-dtb-edge-sunxi64 21.08.0-trunk armbian-edge, linux-dtb, linux-dtb-armbian linux-headers-edge-sunxi64 21.08.0-trunk armbian-edge, linux-headers, linux-headers-armbian linux-image-edge-sunxi64 21.08.0-trunk armbian-edge, linux-image, linux-image-armbian linux-libc-dev-edge-sunxi64 21.08.0-trunk armbian-edge, linux-kernel-headers, linux-kernel-headers-armbian linux-u-boot-orangepipc2-edge 21.08.0-trunk armbian-u-boot I think it will be good to bring this to a single unified style.

Looking ahead a bit, I want the build system to learn how to build complex projects. Such as Xenomai and Evl. Example of evl core latency: leo@orangepipc2:~$ uname -a Linux orangepipc2 5.10.19-evl-sunxi64 #trunk SMP IRQPIPE Sat Mar 6 16:34:02 MSK 2021 aarch64 aarch64 aarch64 GNU/Linux leo@orangepipc2:~$ sudo cyclictest -t -p80 --clock=1 WARN: cyclictest was not built with the numa option # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.04 0.01 0.00 1/117 2389 T: 0 ( 2386) P:80 I:1000 C: 17866 Min: 6 Act: 7 Avg: 7 Max: 45 T: 1 ( 2387) P:80 I:1500 C: 11911 Min: 6 Act: 14 Avg: 7 Max: 28 T: 2 ( 2388) P:80 I:2000 C: 8933 Min: 7 Act: 8 Avg: 7 Max: 42 T: 3 ( 2389) P:80 I:2500 C: 7146 Min: 7 Act: 7 Avg: 7 Max: 28 To date, this is the only option for the arm architecture.

I'm sorry. These are rhetorical questions. I can't get used to articulating thoughts in the style of English grammar so that the automatic translation looks correct. In fact, I am an experienced user and will find any information. But if we give the user the ability to search, update, or reinstall by key tags, it will be very good. sudo apt search armbin This command will display the full list of packages provided by armbian. sudo apt search armbin-edge This command will only show packages for $BRANCH It is the word combination that is important here armbian-$BRANCH sudo apt reinstall armbian-current This command will actually do a package update for the $BRANCH Here we not only take care of the user, but also improve the armbian. @Igor Yes, but only for those packages that contain programs, libraries that have their own version. This is necessary to correctly register the mutual dependencies. And this is especially true for the kernel and libraries that use the functionality of this particular kernel. The final version can be formed by concatenating the original version and the armbian version.

I didn't even know this information existed. Thanks. I am a regular ubuntu user. I built or downloaded a mini system image for the board. What other packages does armbian provide? What versions do these packages have? How can I find out this information in a simple way using the apt service? We need to add key tags to the "Provides:" field. In all packages provided by armbian. Logically, this implies another point - the Version field. How justified is Version: $REVISION ?

Very well. But I want to say: Today I'm testing a few different options for the kernel. File control of the last option: Package: linux-image-5.10.33-sunxi64 Source: linux-5.10.33-sunxi64 Version: 21.05.6 Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 124084 Provides: linux-image, linux-image-armbian, linux-image-sunxi64 Section: kernel Priority: optional Homepage: https://www.kernel.org/ Description: Linux kernel, armbian version 5.10.33-sunxi64 current This package contains the Linux kernel, modules and corresponding other files, version: 5.10.33-sunxi64. The description field contains information about $BRANCH, but apt will not respond to it, it just outputs the first line as text information for the user. If the "Provides:" field is in this version: Provides: linux-image, linux-image-sunxi64, linux-image-armbian, linux-image-armbian-current We will be able to search by tags like this: sudo apt search linux-image-armbian-current

In the previous answer, I seem to have overreacted. Here it matters in which case we want to give the message to the user. If only when installing the package, then the postinst script is possible. But, but I don't remember today what I installed in the system yesterday and check using the package manager. For example, now there is a ubuntu or debian system on the board. How can I find out what is installed from the provided armbian? sudo apt search linux-image-current sudo apt search armbian-current ..... sudo apt search armbian armbian-config/focal,focal 21.02.3 all Armbian configuration utility armbian-firmware/now 21.05.0-trunk all [установлен, локальный] Linux firmware armbian-firmware-full/focal,focal 21.02.3 all Linux firmware-full armbian-focal-desktop/focal,focal 21.02.2 all Armbian desktop for Ubuntu focal armbian-focal-desktop-gnome/focal,focal 21.02.3 all Armbian desktop for Ubuntu focal armbian-focal-desktop-xfce/focal,focal 21.02.3 all Armbian desktop for Ubuntu focal linux-focal-root-current-bananapi/focal 21.02.3 armhf Armbian tweaks for focal on bananapi (current branch) ..... linux-focal-root-current-orangepipc2/now 21.05.0-trunk arm64 [установлен, локальный] Armbian tweaks for focal on orangepipc2 (current branch) ..... linux-focal-root-* Armbian tweaks for focal on * Armbian tweaks for focal on orangepipc2 (current branch) - Probably this line is the correct option. In other packages, the keywords 'edge current armbian' must be present in this I agree with you.

My God, with this reworking of patches, I completely forgot about the main task of building kernel packages. Experience in rpmbuild suggests that you need to take the native kernel build system and fix it a little for our tasks. Yes, it is an independent build system for building packages from kernel sources. Documentation: .https://wiki.ubuntu.com/Kernel/Dev https://wiki.ubuntu.com/KernelTeam/KernelMaintenance Based on this git repository. I'll see what happens tomorrow.

@Igor Unfortunately, there are many such moments today.

Deleted the erroneous message

The answer is NO. This script is intended for actions after installing the package. To do this, we have a special file "changelog". This file contains a list of the changes made by the debian maintainer, the person who made the package packaging. Here is an example of my first proper library package: libevl (0~210316-1) UNRELEASED; urgency=low * Initial release (Closes: #7777) * This is my first Debian package. * Adjusted the Makefile to fix $(DESTDIR) problems. -- The-going <48602507+The-going@users.noreply.github.com> Tue, 16 Mar 2021 12:42:00 +0300 libevl - Source package name 0~210316 - Source package version 1 - Debian package version UNRELEASED - is replaced by xenial|bionic|focal|groovy|hirsute, armbian-current P.S. Or am I wrong somewhere?

This file was created by you at a time when it did not exist in the kernel. But in the current version 5.10.31 it exists. They differ. Obviously, we need to combine the functionality of both files and make a patch. Then check the performance on the board. I don't have this board and if I do the necessary things I still won't be able to verify the correctness. Today, the file "arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts" is being replaced. And the patch piece creates an extra line in the Makefile. Which is a gross mistake. This is just one example. I have to read the final file corrected by the patch very carefully. And I changed this line: # detect and remove files which patch will create lsdiff -s --strip=1 "${patch}" | grep '^+' | awk '{print $2}' | xargs -I % sh -c 'rm -f %' to this: # Detect and remove files as '*.patch' which patch will create. # So we need to delete the file before applying the patch if it exists. lsdiff -s --strip=1 "$bzdir/$p" | \ awk '$0 ~ /^+.*patch$/{print $2}' | \ xargs -I % sh -c 'rm -f %' Now only the patch files created by other patches are deleted. In itself, the fact that there are patches that create other patches is very controversial. This is definitely not necessary for creating kernel packages. They are needed for use in the build system itself.

This line " lsdiff -s --strip=1 "${patch}" | grep '^+' | awk '{print $2}' | xargs -I % sh -c 'rm -f %' " In this revision, if any file already exists and the patch creates this file, the file will be deleted before the patch is applied. Keyword any file. This is not correct.

Based on the results of yesterday's work: In some patches that fix the '*.dts *. dtsi ' files, individual chunks are applied with fuzz 2 and introduce bugs. Two lines of code are placed in another function. And this situation requires special attention. These patch files have no context.

Yes, that's the way it is. And it already exists in armbian. userpatch_create() { # create commit to start from clean source git add . git -c user.name='Armbian User' -c user.email='user@example.org' commit -q -m "Cleaning working copy" ..... git commit -s -m "$COMMIT_MESSAGE" git format-patch -1 HEAD --stdout --signature="Created with Armbian build tools https://github.com/armbian/build" > "${patch}" PATCHFILE=$(git format-patch -1 HEAD) ..... My work today on patch processing uses this git tool. Step by step, I check how each patch is applied. apply_patches () { local t_dir="${1}" local series="${2}" local bzdir="$(dirname $series)" list=$( gawk '{ if($1 ~ /s/) print $2 if($0 !~ /^#.*|^-.*|^s.*/) print $0 }' "${series}" ) skiplist=$(gawk '$0 ~ /^-.*/' "${series}") stop=$(gawk '$1 ~ /s/{print $2}' "${series}") # TODO cd "${t_dir}" || exit 1 for p in $list; do echo "I try to apply $p" patch --dry-run -N -p1 -i $bzdir/"$p" flag_p=$? if [ "$flag_p" == "0" ]; then echo "I apply it $p" git am $bzdir/"$p" flag_a=$? if test "$flag_a" == "0"; then git_obj=$(git -C ${t_dir} log --format="%H" -1) fi echo "" if [ "$flag_a" != "0" ]; then echo "Error flag [$flag_a] $p" echo "I apply it..." patch --no-backup-if-mismatch -p1 -N -i $bzdir/"$p" echo -e "\n\t Edit it" kwrite $bzdir/"$p" & wait At the end, a simple command "git format-patch <revision range> -o <dir>" And we have a good series of patches. This situation is not considered an error: patching file fs/proc/task_mmu.c Hunk #2 succeeded at 1866 (offset 8 lines). But in this case: Hunk #1 succeeded at 2184 with fuzz 1. the git am command considers it an error Yesterday, I had one hunk applied with fuzz 3 And this generated an error in the source code. If we regularly skip the entire set of patches in a circle (patch --dry-run, git am, git format-patch), we will make our life much easier. P.S. I wrote it in detail to avoid ambiguous machine translation.

Yes! I read the documentation here: https://www.debian.org/doc/devel-manuals#policy https://www.debian.org/doc/manuals/debmake-doc/#what-debmake https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#what-debuild The "git am" command is more strict than the built-in "debuild", which means that patches will be guaranteed to be applied. I will write more details later. This requires neatness. And working with patches should not be part of the build system itself, but only a nice addition in the form of separate scripts that are typical for armbian for manual work, for example, in a separate tools folder.

True. But it need to have a name Sorry. I meant that the need to name patches to put in the right place in the queue.... We can do anything. The main thing is to adhere to the logic of building packages by the debuild build system itself. First we need to build the source package as it requires debuild. Why is this necessary? So that users do not ask questions - "How do we build this directly on the board?". Download the source package as described in the instructions and follow the steps.... After that, the armbian build system will only need to build binary packages for the architecture and board according to the standard procedure. It is assumed that we have compiled the correct debian source package. I believe that we simply take the original archive from the site kernel.org one way or another, but patches (patches and not files), we will first have to decompose them into thematic folders (group). Next to each folder, we will create a small thematic file of the series. For example: patches.orangepi-5.10/ series.orangepi-5.10.conf patches.armbian/ series.armbian.conf patches.drivers.extrawifi/ series.extrawifi.conf We put the patch that fixes wifi in the theme folder, and not somewhere at the end of the list at the time when it came. And added a line in the series file. Patches should be applied without errors by the 'git am' command. In order for the armbian build system to be able to make a git source repository.

The need to name patches is a big drawback. The user should only apply their patches last, otherwise they will get problems. And this is not the primary problem. Let's look inside the 'debuild' logic of the build process: ..... At some stage, we need to put all the patches in the '${kerneldir}/debian/patches/' folder. ..... How can we do this? Next, part of the formatted patch application log: ??????>>>>>> patch/misc/general-packaging-5.10.y.patch patch/misc/bootsplash-5.8.10-0001-Revert-vgacon-remove-software-scrollback-support.patch patch/misc/bootsplash-5.8.10-0002-Revert-fbcon-remove-now-unusued-softback_lines-curso.patch patch/misc/bootsplash-5.10.y-0003-Revert-fbcon-remove-soft-scrollback-code.patch patch/misc/0001-bootsplash.patch patch/misc/0002-bootsplash.patch patch/misc/0003-bootsplash.patch patch/misc/0004-bootsplash.patch patch/misc/0005-bootsplash.patch patch/misc/0006-bootsplash.patch patch/misc/0007-bootsplash.patch patch/misc/0008-bootsplash.patch patch/misc/0009-bootsplash.patch patch/misc/0010-bootsplash.patch patch/misc/0011-bootsplash.patch patch/misc/0012-bootsplash.patch patch/misc/kali-wifi-injection-1-v5.9-post.patch patch/misc/kali-wifi-injection-2.patch patch/misc/kali-wifi-injection-3.patch cache/sources/aufs5/aufs5.10/aufs5-kbuild.patch cache/sources/aufs5/aufs5.10/aufs5-base.patch cache/sources/aufs5/aufs5.10/aufs5-mmap.patch cache/sources/aufs5/aufs5.10/aufs5-standalone.patch patch/misc/wireless-rtl8811cu.patch patch/misc/wireless-rtl8188eu.patch patch/misc/wireless-rtl8723ds.patch patch/misc/wireless-rtl8723du.patch ??????<<<<<< patch/kernel/sunxi-current/0001-Fix-broken-ethernet-on-Orangepi-2.patch patch/kernel/sunxi-current/0001-Revert-leds-axp20x-Support-charger-LED-on-AXP20x-lik.patch patch/kernel/sunxi-current/0001-arm64-allwinner-a64-enable-Wi-Fi-for-Pine64.patch You can't see adding files from third-party git repositories here. These added files introduce errors in the compilation process and patches that fix problems are located in different places and are applied in an arbitrary order. The only way to solve this problem is to add additional code to the build system, which creates a commit at each iteration of adding files and applying each patch. And then 'git format-patch v5. 10. 28..HEAD -o ${kerneldir}/debian/patches/' Everything is simplified if you have a separate repository for the final set of patches, where there are branches of sunxi-5.10, etc.

Good. You're right. There are two lines of action: 1) Rules and procedures for the maintainer, which have two main goals. - First of all, this is the correct operation of the build system, which makes the right packages. - And only secondarily the functionality of the programs contained in the package. 2) Rules and procedures for the user who decided to add functionality or fix an error. Let's assume that you are the maintainer, and I am the user. I found and fixed the bug, made a patch and return it to you with the name zzz-0001-NAME_BUGFIX. patch. It is clear that the patch is applied last, but I have informed you that this is a fix for a patch that adds functionality and is applied (queued) at number 65. You will probably want to put this patch in the queue with the number 66. And if the build is successful, combine 65 and 66 using the combinediff command. Or ask me to fix another problem related to the file that is being modified. Normal current work. A much worse situation is when there was a big wave of changes in the source repository, the build system tracked it and all our patches are floating in different directions. I accepted all your comments and take off my T-shirt with the inscription "user". I'll put on my maintainer uniform and continue.

Yes, you're right. This should be checked. I have not used this functionality once. I have my own more complex system of working with numerous patches. This option, which is intended only for debugging, I have shown as desirable in the future. The mechanism using the 'series' file has a number of advantages. By editing a single file, we can change the sequence of applying patches, disable some, and leave comments. This is convenient and it is used when creating packages, both 'deb' and 'rpm'. But this assumes that everything is working flawlessly and a lot of work has been done. Your 'advanced_patch' function works brilliantly. I sincerely admire its functionality. But it is less strict than the one used in debuild or rpmbuild. Maybe try to provide a choice. If the file 'series.conf' exists then the new option, if it doesn't, then the current one?

Continuation of the conversation and implementation of the plan. @Igor, I reworked the 'megause' patches from the orangepi-5.10 branch and implemented their use in my repository. They're here. On the wip/rework_kernel_compile branch, all patches are applied without errors to the v5.10.26 kernel versions. Partially fixed warnings and errors in whitespace characters. Added a new apply_patch_series function that uses the series.conf file. Build Options ./compile.sh BOARD=orangepipc2 BRANCH=current RELEASE=focal BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=yes KERNEL_CONFIGURE=yes lib.config: KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git' KERNELBRANCH=tag:v5.10.26 KERNELPATCHDIR="sunxi-5.10.26" Next steps: - Complete set of patches ready for packaging. - Creating a kernel source code package for sunxi. Then I will build binary kernel packages from this package. This approach ensures that the build results are repeatable.