内核pkg包能否用github actions来构建

[a520ass]

在aarch64环境下编译内核非常慢，能否写一个github actions来构建内核pkg包

[7Ji]

https://github.com/7Ji/amlogic-s9xxx-archlinuxarm/commit/8e5bcf660296185e9371b2e9b27aa18b8f5a6fd8

你可以回滚这个commit，用-bin的包，那个 -bin包是直接把Armbian项目的内核重新按照alarm的风格再整理起来。

构建的机子可以配置ccache，用其他的x86机子做构建志愿者。速度提升很大。 https://wiki.archlinux.org/title/ccache

Action的话并不能原生构建aarch64的二进制，需要用x86 hosted的aarch64工具链。无论是单个包拆到actions打包再拿回来还是整个项目用actions，都会增加碎片度。整个镜像的构建最后是一定要用到Aarch64上ALARM的root，所以不想增加更多跳来跳去的环节。

我自己倒是有个另外的linux-aarch64-flippy-cross-bin包，是介于linux-aarch64-flippy（原生打包）和linux-aarch64-flippy-bin（从Armbian仓库里搬过来重新打包）之间的，可以用x86机子构建内核以后提供半成品归档再让aarch64的机子整理成最终的Pacman包。之后可以发一下

hefeng @.***> 于 2022年12月28日周三 下午10:19写道：

在aarch64环境下编译内核非常慢，能否写一个github actions来构建内核pkg包

— Reply to this email directly, view it on GitHub https://github.com/7Ji/amlogic-s9xxx-archlinuxarm/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2CYEQ5SSGKACFY5E4YVSLWPRD6LANCNFSM6AAAAAATLJUZ74 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[a520ass]

非常感谢回复，能提供下这个linux-aarch64-flippy-cross-bin吗，目前就是用的你的linux-aarch64-flippy-bin包。

我有个疑问，在archlinux x86环境下使用交叉编译工具，再通过makepkg能生成aarch64的包吗？

[7Ji]

https://github.com/7Ji/linux-aarch64-flippy-cross-bin

上传了，这个库就是在x86下面用脚本构建产生归档以后，aarch64下再重新打成pacman包

[7Ji]

先不要用，刚发现打包流程有bug

[a520ass]

先不要用，刚发现打包流程有bug

好的，等好了我试一下，非常感谢

[7Ji]

好了，可以试了

hefeng @.***> 于2022年12月29日周四 11:42写道：

先不要用，刚发现打包流程有bug

好的，等好了我试一下，非常感谢

— Reply to this email directly, view it on GitHub https://github.com/7Ji/amlogic-s9xxx-archlinuxarm/issues/3#issuecomment-1367051657, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2CYESYEV7AE6LCXBGHF2LWPUCBRANCNFSM6AAAAAATLJUZ74 . You are receiving this because you commented.Message ID: @.***>

[a520ass]

根据你的打包PKGBUILD文件，自己写了一个从armbian官方编译好的内核deb包来生成内核pkg包的PKGBUILD文件，命名为linux-aarch64-meson64-bin，测试了一下没有问题，修改extlinux.conf就能切换回linux-aarch64-flippy-bin的内核

[7Ji]

从 https://github.com/7Ji/amlogic-s9xxx-archlinuxarm/commit/083442052d882c87b23919383be4cb6c3130860a 和 https://github.com/7Ji/amlogic-s9xxx-archlinuxarm/releases/tag/20230205 起，现在发布会一并打包当次构建中使用到的AUR包。并且自 https://github.com/7Ji/amlogic-s9xxx-archlinuxarm/commit/c50813bf6e17113ce2cda183c5f8373e5dd539a5 后，打包也更智能，每次不会重新构建已构建的版本相同的AUR包。

不过这个项目仍然不会使用github actions，因为github actions原生不提供aarch64环境，而我不希望这个项目的构建过程中涉及交叉编译。需要管理工具链的情况下项目体积会急剧膨胀。且现在一次构建在不压缩的情况下只需要几分钟，并不慢。哪怕要从头构建内核，在有哪怕只有一台x86-64的机子作为distcc的志愿者的情况下也只要半个多小时。

[a520ass]

不过这个项目仍然不会使用github actions，因为github actions原生不提供aarch64环境，而我不希望这个项目的构建过程中涉及交叉编译。需要管理工具链的情况下项目体积会急剧膨胀。且现在一次构建在不压缩的情况下只需要几分钟，并不慢。哪怕要从头构建内核，在有哪怕只有一台x86-64的机子作为distcc的志愿者的情况下也只要半个多小时。

我没有archlinux的x86-64机子，不过目前已经实现了在github actions 里构建aarch64 pkg包，使用了QEMU，不过效率比较低，用来编译内核要非常久。 https://github.com/a520ass/Armbian-build/blob/30e15ebfb50a7035b0f4ec97cf1dea2d26c3bda3/.github/workflows/build-archlinux-pkg.yml#L67

[7Ji]

distcc的志愿者不必要一定是x86-64的arch，任何可以提供aarch64编译的设备都可以。x86-64 hosted aarch64 toolchain的ArchLinux可以，x86-64 hosted aarch64 toolchain的其他发行版当然也可以，any hosted aarch64 toolchain都可以，aarch64自己当然也可以。我推荐Arch x86-64作为志愿者主要是有alarm官方维护的aur包可以方便地部署工具链，yay装上启用service就行了。

[a520ass]

distcc的志愿者不必要一定是x86-64的arch，任何可以提供aarch64编译的设备都可以。x86-64 hosted aarch64 toolchain的ArchLinux可以，x86-64 hosted aarch64 toolchain的其他发行版当然也可以，any hosted aarch64 toolchain都可以，aarch64自己当然也可以。我推荐Arch x86-64作为志愿者主要是有alarm官方维护的aur包可以方便地部署工具链，yay装上启用service就行了。

下次我试试用ubuntu作为志愿者，直接在设备上编译内核

[7Ji]

issue无关但作为通知，刚打包了个8189fs的DKMS驱动包，可以在你的r3300l上用： https://aur.archlinux.org/packages/rtl8189fs-dkms-git

[a520ass]

issue无关但作为通知，刚打包了个8189fs的DKMS驱动包，可以在你的r3300l上用： https://aur.archlinux.org/packages/rtl8189fs-dkms-git

这个月才有时间玩这个。8189fs好像有主线驱动，这个有什么区别吗

[7Ji]

8189fs 没有主线驱动，r3300l要用这个dkms模块才能使用无线

[a520ass]

8189fs 没有主线驱动，r3300l要用这个dkms模块才能使用无线

我用的是armbian官方的内核，那就是它编译的时候加过去了

[7Ji]

这两天折腾了一下，整个项目都可以用Github Actions构建了，这意味着可以在每个push的commit的小绿箭头直接下到自动构建的镜像了。不过整个方案相比原生构建绕的弯非常多：

用github actions的x86-64的Ubuntu22.04的环境，起x86-64的ArchLinux的工具链，部署x86-64的ArchLinux用的给ArchLinuxARM的aarch64的目标用的交叉编译工具链，部署Aarch64的ArchLinuxARM的根文件系统，再在aarch64的ArchLinuxARM容器里打包。

顺带的成果是可以在x86-64的Debian/Ubuntu构建ALARM了

[a520ass]

这两天折腾了一下，整个项目都可以用Github Actions构建了，这意味着可以在每个push的commit的小绿箭头直接下到自动构建的镜像了。不过整个方案相比原生构建绕的弯非常多：

用github actions的x86-64的Ubuntu22.04的环境，起x86-64的ArchLinux的工具链，部署x86-64的ArchLinux用的给ArchLinuxARM的aarch64的目标用的交叉编译工具链，部署Aarch64的ArchLinuxARM的根文件系统，再在aarch64的ArchLinuxARM容器里打包。

顺带的成果是可以在x86-64的Debian/Ubuntu构建ALARM了

大佬太厉害了。我的理解，是不是在x64 ubuntu主机上弄了一个x64的archlinux跟一个aarch64的alarm，然后再通过distcc来构建内核包。我用github actions来测试一下

[7Ji]

再通过distcc来构建内核包

内核包是个例外，内核包是先在x64环境里编译完，再在aarch64环境里打包成arch的.pkg.tar。除此外的包都是在aarch64环境里，以x64环境为distcc志愿者，编译的且打包的。因为QEMU的转译效率并不理想，如果内核包也在aarch64里编译，哪怕x64给它当distcc志愿者，整个job也会跑满6小时然后被github强制取消。

[a520ass]

内核包是先在x64环境里编译完，再在aarch64环境里打包成arch的.pkg.tar

qemu好像是比较慢，我之前测试过。这个x64的archlinux不能直接打包archlinuxarm的内核包吗

[7Ji]

内核包是先在x64环境里编译完，再在aarch64环境里打包成arch的.pkg.tar

qemu好像是比较慢，我之前测试过。这个x64的archlinux不能直接打包archlinuxarm的内核包吗

Arch的makepkg非常不喜欢给原生架构以外的架构编译和打包，要再多魔改更多的部分。所以我想尽可能地把所有的用makepkg打包的操作放在aarch64里，确保打出来的包可以正常地被aarch64的pacman管理。这个项目和Armbian不一样，所有额外编译部分都是作为新加包安装进去的，可以被pacman升级和卸载。

[a520ass]

嗯，我看了下脚本，编译内核都是在x64的archlinux下弄的。如果我想自己加一个其他的内核包，直接在build_cross下面加应该不行吧，是不是还需要在build里加一个，这个source.tar.gz 链接到build里面，应该是为了能直接下载源码吧

[7Ji]

build_cross 下存在的包会“替换” （叫替换，是因为确定要构建哪些包是遍历build来决定的，只有需要构建的包才会查找build_cross来确定是否要分阶段构建） build 下的同名包，然后必须存在：

• build.sh 是在x64宿主环境（不是那个ArchLinux x64的root）里构建这个包的步骤。
• PKGBUILD 是在aarch64客户环境里用makepkg打包的配置。

这里面PKGBUILD引用的source都是宿主阶段构建的成果

软链接引用的目的在于不需要独立管理源文件。这个项目交叉构建的时候，在宿主阶段会给所有需要构建的build下面的包下载源文件。只有和普通的aarch64原生编译用到的配置不同的地方才要特意写出来。

我另一个项目也加了github actions的支持，你可以两边对照着看： https://github.com/7Ji/orangepi5-archlinuxarm

[7Ji]

我必须补充一点就是这种我非常不推荐在你同时有x86-64和aarch64硬件的情况下使用这种构建方式，这个构建方式折腾出来的目的是给纯x86-64，且系统局限只能用ubuntu22.04的GithubActions用的。

在GithubActions的双核E5的性能下，构建整个项目需要1小时30分钟左右。而我自己1600x的机子给12个线程这么构建也要40分钟左右。

但如果你有原生的aarch64硬件，在配置好一台哪怕性能不是很好的x86-64机子（我的是一台旧的用1600x做cpu的当服务器的老台机）做distcc志愿者的情况下，不压缩构建成果（compressor=no）的情况下整个构建只要不到20分钟

[a520ass]

只要20分钟，这么快吗。主要是我没有x64的archlinux，现在是用的win11加wsl2 ubuntu 22.04，wsl2的archlinux好像有问题

[a520ass]

distcc好像也能在x64 的ubuntu上使用，使用GitHub actions 是不是可以不需要x64的archlinux

[7Ji]

只要20分钟，这么快吗。主要是我没有x64的archlinux，现在是用的win11加wsl2 ubuntu 22.04，wsl2的archlinux好像有问题

https://github.com/7Ji/alarm-builder-common/blob/3ed98aa3dbafaf4a7be217fe07d292cf62e5468d/functions/cross/start_distccd_and_trap.sh#L4

这里就是直接在Ubuntu22.04的环境里起给alarm用的distccd

distcc好像也能在x64 的ubuntu上使用，使用GitHub actions 是不是可以不需要x64的archlinux

那个x64的archlinux的主要作用只是提供一个宿主环境能用的makepkg，整个构建过程没有用它做过别的事。

[7Ji]

https://github.com/7Ji/amlogic-s9xxx-archlinuxarm/commit/58d4c0417f9496cea2dd00edd52c7e9aee0fd098

不过你提醒了我，这个x64的arch既然只有提供makepkg的库的作用，那可以直接不部署了。因为makepkg是纯用bash写的，架构不敏感，直接用aarch64的alarm里面的makepkg的库是一样的。

[a520ass]

没看懂，这个download_sources是在哪里

[7Ji]

functions/cross -> functions/cross/cross_download_source -> functions/prepare/prepare_pkg/download_source

[a520ass]

https://github.com/7Ji/alarm-builder-common/blob/0aaa1524d1725bde5e465d1de5de374c8bbf5a4b/functions/prepare/prepare_pkg/download_source.sh#L20

这个地方的download_sources，没看到方法在哪

[7Ji]

这个是makepkg的库的一部分，在你的arch/alarm系统的/usr/share/makepkg/source.sh里面，源码在arch的gitlab

https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/libmakepkg/source.sh.in#L36

[a520ass]

这个是makepkg的库的一部分，在你的arch/alarm系统的/usr/share/makepkg/source.sh里面，源码在arch的gitlab

好的，我说怎么搜不到这个方法

[a520ass]

不过你提醒了我，这个x64的arch既然只有提供makepkg的库的作用，那可以直接不部署了。因为makepkg是纯用bash写的，架构不敏感，直接用aarch64的alarm里面的makepkg的库是一样的。

大佬还是厉害，这个需要测试一下吗

[a520ass]

这个GitHub actions的触发，是不是改成手动触发或者打tag之后触发好一些

[7Ji]

这个需要测试一下吗

我本地构建是没问题的，就看actions跑起来有没有改善了

手动触发或者打tag之后

这个每commit触发的CI我是不打算改的，但是打算加上逢tag自动从把前者构建出来的镜像上传到release的actions。这边看起来迭代很快，触发了一堆actions，但是平时的话我也就会把包的版本升一下，这边的actions很少会触发的。

[7Ji]

这个GitHub actions的触发，是不是改成手动触发或者打tag之后触发好一些

哦，如果你是担心你fork以后改动触发一堆，你可以减少push的频率的。这个actions的实际触发点是push，不是commit，若干个commit一次push上来只会触发一次构建的。我之前基本是本地构建完了确定没问题再一次push几个commit过来。

[a520ass]

我本地构建是没问题的，就看actions跑起来有没有改善了

actions编译内核的话，是需要点时间，尤其是启用了这么多模块

[a520ass]

这个GitHub actions的触发，是不是改成手动触发或者打tag之后触发好一些

哦，如果你是担心你fork以后改动触发一堆，你可以减少push的频率的。这个actions的实际触发点是push，不是commit，若干个commit一次push上来只会触发一次构建的。我之前基本是本地构建完了确定没问题再一次push几个commit过来。

那就没什么问题。我自己的actions，一般是手动点的，因为我的加了release