Jump to content

creating packages in the armbian build system


Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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"

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 .

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines