linux-orangpei-3b: improve compability and stick closer with upstream

Use sha256sum instead of md5sums for all sources and set them up correctly.
Sort variables in the order defined by official PKGBUILD doc.
Drop unneeded makedeps.
Simplify srcname. vercmp 6.6.1 > 6.6, just use a pkgver without the redundant .0 suffix if you want to cover that.
Simplify prepare() and build() routine, record version to avoid calling make kernelrelease later.
Drop interactive kernel config, this should not be done inside makepkg routine. A PKGBUILD should be static and a snapshot in time.
Drop cross-compile related stuffs, makepkg is never for cross-compiling. A "successful" cross-compiling on an x86_64 host carries x86_64 hosted bins targetting aarch64 thus header package breaks a lot, and utterly wrong metadata in the result package breaking the reproducibility.
Explicitly list the patches to be applied.
Install the kernel image to /usr/lib/modules/[kernel]/vmlinuz so it would be automatically picked up by mkinitcpio/booster/dracut's hooks.
Drop the unneeded hooks and the install file, and change the preset as a result of the last change.
Install the DTBs to /boot/dtbs/[kernel] to avoid conflicting with other kernel packages, and only install the DTB for 3B.
Do not provide linux nor linux-aarch64 any more, and do not conflict with them.

A lot of changes, thanks! I will review them ASAP.

Drop cross-compile related stuffs, makepkg is never for cross-compiling. A "successful" cross-compiling on an x86_64 host carries x86_64 hosted bins targetting aarch64 thus header package breaks a lot, and utterly wrong metadata in the result package breaking the reproducibility.

Could you elaborate this? I am relying on this cross-compiling method in my workflow to build and debug kernel modules, and this change will break it.

I was supposing that aarch64-linux-gnu-* would target at aarch64, set its compiler options to emulate an aarch64 environment and thus Makefile would produce the same header files?

Since this package is adapted from other's repository, some detail in PKGBUILD still remains mystery to me.

aarch64-linux-gnu-* would target at aarch64, set its compiler options to emulate an aarch64 environment and thus Makefile would produce the same header files

The problem here is that the headers package does not contain only the headers, they also contain other stuffs, among them are the scripts, and some of the scripts are compiled on host.

Check what's packed in a supposedly aarch64 package:

nomad7ji@ms5 /t/o/u/l/m/5/b/scripts> for file in $list
                                         file $file | grep ELF
                                     end
./asn1_compiler: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ad4ec033ca3f5ea8fb49ac205fc1cebcdf74b723, for GNU/Linux 4.4.0, stripped
./basic/fixdep: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=40cc6a93896ce77e15618886c3c5dc2e687f724a, for GNU/Linux 4.4.0, stripped
./dtc/dtc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ad015df31fe9cc00c5c236024c44a0e569fb5c34, for GNU/Linux 4.4.0, stripped
./extract-cert: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=aba10178ddeb0b9031a4573e4d940051fb112554, for GNU/Linux 4.4.0, stripped
./genksyms/genksyms: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=5aaacb712bbdf615ea0700d63fff1d5022bb4b53, for GNU/Linux 4.4.0, stripped
./kallsyms: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6c61cfc9ab7b6574708667f95e38ea391b66ff27, for GNU/Linux 4.4.0, stripped
./kconfig/conf: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3c0df22e47a757062600b4edae7705ee6ab5719b, for GNU/Linux 4.4.0, stripped
./mod/mk_elfconfig: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=5466b6e804217e3f93d58da38722d106c5ad7daa, for GNU/Linux 4.4.0, stripped
./mod/modpost: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=27f6095642925bf8ae5e1af6dbf229dbc2a70828, for GNU/Linux 4.4.0, stripped
./resource_tool: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7b6f0916c04325de96259f708efaf6cf596a1380, for GNU/Linux 4.4.0, stripped
./selinux/genheaders/genheaders: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6920451081a1e49df2f73aa0354196fb45418928, for GNU/Linux 4.4.0, stripped
./selinux/mdp/mdp: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=575571f324a13bef3efd6e13cef1d066579d8c90, for GNU/Linux 4.4.0, stripped
./sorttable: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0c1d162844a5d9515a851a37b529a867dfe93d5e, for GNU/Linux 4.4.0, stripped

Whenever you would need to compile an out-of-tree module using the headers on the actual aarch64 platform, these binaries won't work at all and would break the build.

Another thing is that an Arch package contains more than just these artifacts. They contain three metadata files: .BUILDINFO, .MTREE and .PKGINFO. Among them .BUILDINFO is necessary for reproducible builds, but with a setup like that the reproducibility is no longer possible.

If you really want that part back I could re-add them, but my recommendation would be to set up your x86_64 device as a distcc volunteer for your board. Makepkg + cross-compiling never works, it appears to work simply because the PKGBUILD was hacked in a specific way to make it appear to work, it breaks immediately if you build it in a clean chroot, as you've never declared the right dependencies (the cross toolchain, but even that would be wrong, as ALARM has their own official toolchain, different from the one released as aarch64-linux-gnu-gcc by Arch). If you try that for any package with a real dependency they would break, as you cannot possibly get an aarch64 dependency onto you x86_64 build environment.

Makepkg + cross-compiling never works, it appears to work simply because the PKGBUILD was hacked in a specific way to make it appear to work, it breaks immediately if you build it in a clean chroot, as you've never declared the right dependencies

Thanks for your explanation! Then I would rather run a VM to do compiling stuffs. Merge this.

run a VM to do compiling stuffs

You don't need to let the AArch64 SBC/ QEMU VM do all the work. As I said you could run distccd on a powerful x86_64 machine, which would speed up the compiling speed dramatically. For an ALARM aarch64 client + Arch x86_64 server combination, just install distcc on both, install aur/distccd-alarm-armv8 on x86_64 then enable its service, then configure aarch64 client's system-wide makepkg.conf to enable distcc and add the x86_64 server as one of the DISTCC_HOSTS. Your aarch64 client then only needs to do pre-processing and linking by itself.

And FYI I've added this PKGBUILD to my build list: https://github.com/7Ji/archrepo/commit/6d717e0adddf1383eb02a9e20f1283284934a71d , it should be built and uploaded by my build cluster in the very next hourly build.

w568w / alarm_repo

linux-orangpei-3b: improve compability and stick closer with upstream #1