going Posted May 6, 2020 Posted May 6, 2020 For the past 10 years, I have been moving evenly and rectilinearly in an inertial frame of reference called OpenSUSE. I had to first read about creating Debian packages and look here: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/ Both Ubuntu and OpenSUSE distributions start with the kernel source package, which contains a set of scripts and rules for further build. This has a sacred meaning. To get started, I took two scripts from the v5.7-rcX core as a basis and put them in packages/armbian/builddeb packages/armbian/mkdebian checked the build process for bionic current core v5.4.y This initial state can serve as a starting point. How it works? In armbian/build git remote add armbian-build https://github.com/The-going/armbian-build.git git fetch armbian-build packaging git checkout -b packaging armbian-build/packaging ./compile.sh NEWPKG="true" NEWPKG="true" - no longer used This repository branch changes its commit history by following the flight of thought and eliminating garbage. Update it with the -f, --force key git pull -f armbian-build packaging Please test and write your wishes and thoughts here. At this stage, we can opt out of general-packaging-5.X.X.patch
going Posted May 11, 2020 Author Posted May 11, 2020 As of today, may 11, the following packages are being built, installed, and uninstalled without errors: 43K - armbian-config_20.05.0-trunk_all.deb 6,2M - armbian-firmware_20.05.0-trunk_all.deb 101M - armbian-firmware-full_20.05.0-trunk_all.deb 56K - linux-dtb-current-sunxi64_20.05.0-trunk_arm64.deb 11M - linux-headers-current-sunxi64_20.05.0-trunk_arm64.deb 29M - linux-image-current-sunxi64_20.05.0-trunk_arm64.deb 1,1M - linux-libc-dev-current-sunxi64_20.05.0-trunk_arm64.deb 123M - linux-source-current-sunxi64_20.05.0-trunk_all.deb 269K - linux-u-boot-current-orangepipc2_20.05.0-trunk_arm64.deb The disk image has been assembled, and the locale with native languages is working. 1000M - Armbian_20.05.0-trunk_Orangepipc2_bionic_current_5.4.38_minimal.img Started checking the health of packages on the Board - linux-source, linux-libc-dev, linux-headers 1
going Posted May 20, 2020 Author Posted May 20, 2020 Redesigned the branch packaging. 'NEWPKG', 'FORCE_CHECKOUT' and 'IGNORE_UPDATES' variables is no longer used. Added a new ability to work offline. ./compile.sh OFFLINE_WORK=yes and sources will simply return to their original state without checking on the Internet.
going Posted December 15, 2020 Author Posted December 15, 2020 Today is December 15, 2020 I brought the code to the top of armbian master. Built for different kernel versions (5.4 5.9 5.10). debs> ls -gGhR .: итого 807M -rw-r--r-- 1 43K дек 15 22:05 armbian-config_21.02.0-trunk_all.deb -rw-r--r-- 1 6,6M дек 15 22:05 armbian-firmware_21.02.0-trunk_all.deb -rw-r--r-- 1 142M дек 15 22:05 armbian-firmware-full_21.02.0-trunk_all.deb drwxrwxr-x 1 0 дек 15 22:05 extra drwxrwxr-x 1 436 дек 15 22:05 focal -rw-r--r-- 1 77K дек 15 22:05 linux-dtb-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 80K дек 15 22:05 linux-dtb-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 57K дек 15 22:05 linux-dtb-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 12M дек 15 22:05 linux-headers-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 12M дек 15 22:05 linux-headers-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 11M дек 15 22:05 linux-headers-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 26M дек 15 22:05 linux-image-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 27M дек 15 22:05 linux-image-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 30M дек 15 22:05 linux-image-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 1,1M дек 15 22:05 linux-libc-dev-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 1,1M дек 15 22:05 linux-libc-dev-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 1,1M дек 15 22:05 linux-libc-dev-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 192M дек 15 22:05 linux-source-5.10.0-dev-sunxi64.deb -rw-r--r-- 1 159M дек 15 22:05 linux-source-5.4.82-legacy-sunxi64.deb -rw-r--r-- 1 190M дек 15 22:05 linux-source-5.9.14-current-sunxi64.deb -rw-r--r-- 1 276K дек 15 22:05 linux-u-boot-current-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 276K дек 15 22:05 linux-u-boot-dev-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 276K дек 15 22:05 linux-u-boot-legacy-orangepipc2_21.02.0-trunk_arm64.deb ./extra: итого 0 ./focal: итого 1,4M -rw-r--r-- 1 162K дек 15 22:05 armbian-focal-desktop_21.02.0-trunk_all.deb -rw-r--r-- 1 405K дек 15 22:05 linux-focal-root-current-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 405K дек 15 22:05 linux-focal-root-dev-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 405K дек 15 22:05 linux-focal-root-legacy-orangepipc2_21.02.0-trunk_arm64.deb without any major changes, the two kernel build scripts (builddeb mkdebian) build different versions in the same way, starting from 5.4 and higher. Changes were required in the part that concerns the 'armbian' build system itself. To be honest, I spent longer looking for places where temporary folders are created, and those places where they should be deleted after completing their function. You can test this approach as before: git remote add armbian-build https://github.com/The-going/armbian-build.git git fetch armbian-build packaging git checkout -b packaging armbian-build/packaging git pull -f armbian-build packaging 1
Igor Posted December 16, 2020 Posted December 16, 2020 15 hours ago, going said: without any major changes, the two kernel build scripts (builddeb mkdebian) build different versions in the same way, starting from 5.4 and higher. Changes were required in the part that concerns the 'armbian' build system itself. Tested, works, but we need more testings of course. I spot one change / correction in the kernel sources package file naming. Its changed but i guess it doesn't play any role. 15 hours ago, going said: To be honest, I spent longer looking for places where temporary folders are created, and those places where they should be deleted after completing their function. Better / worse temp folders handling was needed to support full parallel compilation which is primarily needed internally. Sorry. I don't see any major problems that would prevent this moving to the merge request.
going Posted December 16, 2020 Author Posted December 16, 2020 5 hours ago, Igor said: Tested, works, but we need more testings of course. I spot one change / correction in the kernel sources package file naming. Its changed but i guess it doesn't play any role. While I am working on version 5.9. y, there was an upward movement of 5.9.7 - 5.9.14. How to quickly understand which version is in the package, if the name is the same. I wonder why the package name style was chosen without specifying the trunk version. I keep track of patches for building the kernel (general-packaging -*. patch). Once I tried to fix the installation or removal of a package in a patch. To do this, I had to take the following steps: 1 Assemble the core. - it is necessary that patches are applied. 2 Make changes to the code 3 make the appropriate patch 4 make a commit to the build system 5 Build and install, reinstall. 1-5 was repeated several times. A painful procedure. Most importantly, in a build system commit, it is very difficult to see what changes have been made. Result: In the final, I made a mistake myself, and you had to correct it. This mechanism is a big problem, it stops the development of the kernel build procedure in one place. It is for this reason that the code style is drawn from patches for older kernels. although it is logical to pull down a new style of code from the latest kernel to build older kernels.
Igor Posted December 18, 2020 Posted December 18, 2020 On 12/16/2020 at 7:24 PM, going said: I wonder why the package name style was chosen without specifying the trunk version. I don't understand what you mean by that? Can you elaborate better? I know there were some changes in the packaging, perhaps @5kft can shed some light. He was making last adjustments in this section. On 12/16/2020 at 7:24 PM, going said: although it is logical to pull down a new style of code from the latest kernel to build older kernels. Older kernels can remain on patches and once those kernels (4.4, 4.9) finally becomes obsolete, patches are simply gone. Kernel 5.4.y and up is nice to cover with this new system ...
5kft Posted December 18, 2020 Posted December 18, 2020 14 hours ago, Igor said: I don't understand what you mean by that? Can you elaborate better? I know there were some changes in the packaging, perhaps @5kft can shed some light. He was making last adjustments in this section. @going - are you asking why the kernel packages don't include the specific kernel version in them, like as is the case with a native Debian kernel build? I'm not sure why this isn't the case with Armbian, but I suppose that support could be added - although I'm not sure of the dependencies elsewhere in the build tools (or if there are any).
going Posted December 18, 2020 Author Posted December 18, 2020 18 hours ago, Igor said: On 12/16/2020 at 9:24 PM, going said: I wonder why the package name style was chosen without specifying the trunk version. I don't understand what you mean by that? Can you elaborate better? Name pkg: linux-image-current-sunxi64_21.02.0-trunk_arm64.deb What kernel version does this package contain? Name img: Armbian_21.02.0-trunk_Orangepipc2_focal_current_5.9.14_minimal.img In this title you can see everything. I was just asking. I was hoping that someone would remember the reason why they chose this particular style of name. These package names have been around for quite some time. @5kft I assume this is due to reinstalling the package to a new one. Easy installation instead of the same name. And there is always only one core in the system. If this is indeed the case, then the best option is to leave the naming as it exists. For a source package, it doesn't matter. Yesterday I tested the collected images of a minimal system with different cores. All images are working. The linux-source-5.*.deb, linux-libc-dev-*.deb packages are installed and uninstalled. The problem occurred with linux-headers -*. deb. I did a clean build on the master. Tomorrow I will watch and make a comparison. 1
Igor Posted December 18, 2020 Posted December 18, 2020 36 minutes ago, going said: I was just asking. I was hoping that someone would remember the reason why they chose this particular style of name. These package names have been around for quite some time. 41 minutes ago, going said: If this is indeed the case, then the best option is to leave the naming as it exists. Make it simple for people, yes. Since the very early days. IIRC the reasons was to hid the kernel version behind the branch. To make the actual kernel version less relevant, to not confuse average user with it. Why it find the way into the image name? Because adding this is simple and something average person see. Packages don't. I am not telling this way is the best and I would not change this. Perhaps we change this for common to be armhf / arm64 kernel. Or just leave as is.
going Posted December 23, 2020 Author Posted December 23, 2020 I have given these two files 'packages/armbian/builddeb, packages/armbian/mkdebian' to the current view for today. After I finally check the functionality, I will commit the 'packaging' branch for a while. To build packages in a chroot environment, there are patches, but I don't see a mechanism for applying them. @Igor you can share the development plan for this script.
lanefu Posted December 23, 2020 Posted December 23, 2020 2 hours ago, going said: I have given these two files 'packages/armbian/builddeb, packages/armbian/mkdebian' to the current view for today. After I finally check the functionality, I will commit the 'packaging' branch for a while. To build packages in a chroot environment, there are patches, but I don't see a mechanism for applying them. @Igor you can share the development plan for this script. Hey @going I didn't quite understand this post. Would you mind explaining again?
Igor Posted December 23, 2020 Posted December 23, 2020 3 hours ago, going said: you can share the development plan for this script. We could change current package to meta and have packages with kernel numbers. But we would probably need to discuss the implementation and if do we really need it. Welcome to join anytime on IRC #armbian-devel or just put your idea here. We plan to merge lots of code (from branch "desktop") in about two weeks and stabilizing that is current top priority. Then we could move on this or on another long term tasks: - fix kernel change (critical): https://armbian.atlassian.net/browse/AR-572 - improve or prepare for different boot process - deal with firmware packages (optional) https://github.com/armbian/build/issues/1837
going Posted December 23, 2020 Author Posted December 23, 2020 2 hours ago, lanefu said: Hey @going I didn't quite understand this post. Would you mind explaining again? Yes, I did not write very clearly. To build packages in the chroot environment there are patches for example for htop: packages/extras-buildpkgs/htop/debian/patches But in the build script: chroot_build_packages() there is no mechanism for applying patches. Could this mean that this is part of the future work plan and needs to be added.
going Posted December 23, 2020 Author Posted December 23, 2020 3 hours ago, Igor said: We could change current package to meta and have packages with kernel numbers. But we would probably need to discuss the implementation and if do we really need it. Welcome to join anytime on IRC #armbian-devel or just put your idea here. We plan to merge lots of code (from branch "desktop") in about two weeks and stabilizing that is current top priority. Then we could move on this or on another long term tasks: - fix kernel change (critical): https://armbian.atlassian.net/browse/AR-572 - improve or prepare for different boot process Well. I will think in this direction. My fresh thoughts will be in this branch: wip/packaging
going Posted January 26, 2021 Author Posted January 26, 2021 Good health. I got the problem when I tried to install a new compiled kernel package (5.10.8) to the system where the kernel (5.9.14) and its headers were located. The last two commands in the log .bash_history: sudo dpkg -i linux-dtb-current-sunxi64_21.02.0-trunk_arm64.deb linux-u-boot-current-orangepipc2_21.02.0-trunk_arm64.deb sudo dpkg -i linux-image-current-sunxi64_21.02.0-trunk_arm64.deb The linux-headers-current-sunxi64_21.02.0-trunk_amd64.deb package installation command is already missing in the log. The installation failed with an error: the root partition is read-only. The reboot has become impossible. The "fsck.ext4" command on the host solved the problem. The board began to load. What happened? The inodes of several files, the ones that the package manager was supposed to delete, turned out to be corrupted. And the file system was remounted to read-only mode. What is visible in the file system? The "/boot " folder contains only the new kernel (5.10.8). The /lib/modules folder contains 5.10.8-sunxi64 in its entirety and the 5.9.14-sunxi64 folder which contains only one symbolic link to /usr/src/linux-headers-5.9.14-sunxi64. The /usr/src/linux-headers-5.9.14-sunxi64 folder was partially cleared, only the "scripts" subfolder was deleted by the "prerm" script. The /usr/src/linux-headers-5.10.8-sunxi64 folder seems to be included. But: orangepipc2:~$ dpkg-query -s linux-headers-current-sunxi64 Package: linux-headers-current-sunxi64 !###! Status: deinstall reinstreq half-installed !!!!!!!!! Priority: optional Section: kernel Installed-Size: 76897 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Architecture: arm64 Source: linux-5.9.14-sunxi64 Version: 21.02.0-trunk !###! Config-Version: 21.02.0-trunk Depends: make, gcc, libc6-dev, bison, flex, libssl-dev Description: Linux kernel headers for 5.9.14-sunxi64 on arm64 This package provides kernel header files for 5.9.14-sunxi64 on arm64 . This is useful for people who need to build external modules Homepage: https://www.kernel.org/ And this fact points to a fundamental problem
going Posted January 26, 2021 Author Posted January 26, 2021 Today I have two packages on this SD card. One is not fully installed, the other is not completely removed. Both packages have the same package name: Package: linux-headers-current-sunxi64 Both packages have the same version: Version: 21.02.0-trunk I think it took out the brain and logic of the package manager. It just got confused and crashed. On 12/23/2020 at 6:51 PM, Igor said: - fix kernel change (critical): https://armbian.atlassian.net/browse/AR-572 @Igor I think that this is the same problem that you wrote
going Posted January 26, 2021 Author Posted January 26, 2021 I found a solution. Tomorrow I will write in detail. 1
going Posted January 27, 2021 Author Posted January 27, 2021 I didn't invent a bicycle that someone has been riding for a long time. I downloaded several packages from: focal-updates-kernel My downloads folder contains: kernel> ls linux-{image,source,buildinfo,base}* linux-base_4.5ubuntu3.1_all.deb linux-image-unsigned-5.4.0-64-lowlatency_5.4.0-64.72_amd64.deb linux-buildinfo-5.4.0-64-generic_5.4.0-64.72_amd64.deb linux-image-unsigned-5.8.0-40-lowlatency_5.8.0-40.45~20.04.1_amd64.deb linux-image-5.4.0-64-generic_5.4.0-64.72_amd64.deb linux-source-4.15.0_4.15.0-38.41_all.deb linux-image-5.8.0-40-generic_5.8.0-40.45~20.04.1_amd64.deb linux-source-5.4.0_5.4.0-64.72_all.deb linux-image-generic_5.4.0.64.67_amd64.deb linux-source-5.8.0_5.8.0-38.43_all.deb Consider the file name and its contents, or rather "control". linux-image-5.4.0-64-generic_5.4.0-64.72_amd64.deb control: Package: linux-image-5.4.0-64-generic Source: linux-signed Version: 5.4.0-64.72 Architecture: amd64 Maintainer: Canonical Kernel Team <kernel-team@lists.ubuntu.com> Installed-Size: 11444 Depends: kmod, linux-base (>= 4.5ubuntu1~16.04.1), linux-modules-5.4.0-64-generic Recommends: grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo, initramfs-tools | linux-initramfs-tool Suggests: fdutils, linux-doc | linux-source-5.4.0, linux-tools, linux-headers-5.4.0-64-generic Conflicts: linux-image-unsigned-5.4.0-64-generic Provides: aufs-dkms, fuse-module, ivtv-modules, kvm-api-4, linux-image, redhat-cluster-modules, spl-dkms, spl-modules, virtualbox-guest-dkms, virtualbox-guest-modules, zfs-dkms, zfs-modules Built-Using: linux (= 5.4.0-64.72) Section: kernel Priority: optional Description: Signed kernel image generic A kernel image for generic. This version of it is signed with Canonical's UEFI/Opal signing key. File name: linux-headers-5.8.0-40-generic_5.8.0-40.45~20.04.1_amd64.deb control: Package: linux-headers-5.8.0-40-generic Source: linux-hwe-5.8 Version: 5.8.0-40.45~20.04.1 Architecture: amd64 Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com> Installed-Size: 14323 Depends: linux-hwe-5.8-headers-5.8.0-40, libc6 (>= 2.14), libelf1 (>= 0.142), libssl1.1 (>= 1.1.0) Provides: linux-headers, linux-headers-3.0 Section: devel Priority: optional Description: Linux kernel headers for version 5.8.0 on 64 bit x86 SMP This package provides kernel header files for version 5.8.0 on 64 bit x86 SMP. . This is for sites that want the latest kernel headers. Please read /usr/share/doc/linux-headers-5.8.0-40/debian.README.gz for details.
going Posted January 27, 2021 Author Posted January 27, 2021 Fields that are important when installing and removing packages by the package manager: Package: Here is the package name that consists of two parts: the first and the concatenation with local version, which we form here the second example - the first part: "linux-headers-5.8.0", the second part: "-40-generic" Version: is the package version, which should have an ascending numbering, i.e. different from the previous release. By this field, the package manager uniquely identifies the new release. By this field, the package manager uniquely identifies the new release. It consists of two parts separated by a hyphen (number-number) and can be set using a variable. By and large, this numbering can be any and makes sense only for the person who accompanies the package. example - "5.8.0-40.45~20.04.1". Here the package version included the mainline kernel version and so the file name has an ugly look with repetitions: linux-headers-5.8.0-40-generic_5.8.0-40.45~20.04.1_amd64.deb Provides: This field is needed when we perform a search with a different shortened package name. example - If it contains "linux-headers" or "linux-headers-sunxi64" and you ask the package manager to show it, it will output all packages in which this field contains "linux-headers" or "linux-headers-sunxi64"
going Posted January 27, 2021 Author Posted January 27, 2021 I will summarize the interim results of the problems that need to be solved. 1) If the package "linux-headers - *" is installed, then when deleting the package "linux-image - *" in the folder " /lib/modules/$(uname-r)", the cleanup is not complete. And this requires attention to the "prerm or postrm" scripts. 2) The package file name must be different from the package file name of the previous release. Only for one reason, because they can lie in the same folder. 3) The package name must contain the kernel version and the local version that will exactly match "$(uname-r) " after installation. 4) The package version must have an ascending numbering from build to build for the user by the build system, from release to release. 5) The words of the name (legacy, current, dev) make sense in the scripts of the build system and their presence in the file name does not add information, and sometimes makes confusion. 6) I will have to refine the creation of the "linux-source" package, so that it contains a complete set for the native build.
going Posted January 27, 2021 Author Posted January 27, 2021 list of kernel-related package file name templates: lib/main.sh CHOSEN_KERNEL=linux-image-${DEB_BRANCH}${LINUXFAMILY} build-all-ng.sh linux-image-${BRANCH}-${LINUXFAMILY}.githash CURRENT_VERSION=$(cat VERSION) $(find output/debs/ -type f \ -name "linux-image*${CURRENT_VERSION}*.deb" -printf "%f\n" | sort)" compilation.sh linux-image-${BRANCH}-${LINUXFAMILY}.githash distributions.sh ${CHOSEN_KERNEL}_${REVISION}_${ARCH}.deb ${DEB_STORAGE}/${CHOSEN_KERNEL/image/dtb}_${REVISION}_${ARCH}.deb ${DEB_STORAGE}/${CHOSEN_KERNEL/image/headers}_${REVISION}_${ARCH}.deb linux-image-${BRANCH}-${LINUXFAMILY} linux-image-${BRANCH}-${LINUXFAMILY}*_${ARCH}.deb linux-dtb-${BRANCH}-${LINUXFAMILY} linux-headers-${BRANCH}-${LINUXFAMILY} general.sh find "${DEB_STORAGE}" \( -name "${CHOSEN_KERNEL}_*.deb" -o \ -name "armbian-*.deb" -o \ -name "${CHOSEN_KERNEL/image/dtb}_*.deb" -o \ -name "${CHOSEN_KERNEL/image/headers}_*.deb" -o \ -name "${CHOSEN_KERNEL/image/source}_*.deb" -o \ -name "${CHOSEN_KERNEL/image/firmware-image}_*.deb" \) -delete And it doesn't seem scary to change.
going Posted January 28, 2021 Author Posted January 28, 2021 Names that are obtained on the master branch: linux-dtb-current-sunxi64_21.02.0-trunk_arm64.deb linux-headers-current-sunxi64_21.02.0-trunk_arm64.deb linux-image-current-sunxi64_21.02.0-trunk_arm64.deb Filenames obtained from the packaging branch: linux-dtb-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb linux-headers-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb linux-image-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb linux-libc-dev-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb The number 19 indicates the number of times I built this core The packaging branch currently collects only packages and does not collect the entire image. Only for the test .
Igor Posted February 9, 2021 Posted February 9, 2021 This means only file name is changing, but package logic exits the same apt install linux-image-current-rockchip ?
going Posted February 9, 2021 Author Posted February 9, 2021 This means that the package can be searched in the repository with a short word and the package version will increase up from build to build. > dpkg -I linux-headers-5.10.11-sunxi64_19.21.02.0-trunk_arm64.deb new Debian package, version 2.0. size 11657272 bytes: control archive=363676 bytes. 560 байт(а), 15 строк control 1952003 байт(а), 18755 строк md5sums 296 байт(а), 7 строк * postinst 76 байт(а), 3 строк * prerm Package: linux-headers-5.10.11-sunxi64 Source: linux-5.10.11-sunxi64 Version: 19.21.02.0-trunk Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 77074 Depends: make, gcc, libc6-dev, bison, flex, libssl-dev Provides: linux-headers, linux-headers-sunxi64 <<<= Section: kernel Priority: optional Homepage: https://www.kernel.org/ Description: Linux kernel headers for 5.10.11-sunxi64 on arm64 This package provides kernel header files for 5.10.11-sunxi64 on arm64 . This is useful for people who need to build external modules >sudo apt search linux-headers-sunxi64 ...... >sudo apt search linux-headers ...... In VM (Focal): ~$ sudo apt search linux-image-5.10 Sorting… Done Full-text search… Done linux-image-5.10.0-1008-oem/focal-updates 5.10.0-1008.9 amd64 Signed kernel image oem For me, this is a question about how to design the appearance and how to distinguish between the packages provided by armbian and the user's local builds. That is, it is a matter of simple design and agreement within the armbian club. Implemented here
going Posted February 9, 2021 Author Posted February 9, 2021 There may be such an option: linux-image-5.10.11-sunxi64_21.02.19-armbian_arm64.deb linux-image-5.10.11-sunxi64_21.02.19-trunk_arm64.deb
Igor Posted February 9, 2021 Posted February 9, 2021 4 hours ago, going said: That is, it is a matter of simple design and agreement within the armbian club. @martinayotte @TonyMac32@piter75 @gprovost @5kft @jock@SteeMan@lanefu If we agree, before or after big desktop merge.
going Posted February 10, 2021 Author Posted February 10, 2021 8 hours ago, Igor said: If we agree, before or after big desktop merge. I was waiting for the merge and took my time. *** It is advisable to observe these points Please write here whether or not the current kernel source package is used as a git repository?
Igor Posted February 10, 2021 Posted February 10, 2021 13 minutes ago, going said: I was waiting for the merge and took my time. We have a few things to fix, but generally things are ready. 16 minutes ago, going said: Please write here whether or not the current kernel source package is used as a git repository? What you mean by that? You mean if we want to pack commit history and all that stuff?
Recommended Posts