This repository contains patches for Loong Arch Linux packages. These patches are used to provide support for the Loongarch64 architecture in Arch Linux.
中文说明从这里开始。
Follow the guidelines similar to the Arch Linux RISC-V Porting Project:
All modifications to the source code of the package should preferably be submitted upstream. If the upstream is active and merges the fix patch in the short term, you can wait for the upstream to release a new version.
If the upstream has been unresponsive for a long time, is not actively fixing bugs, has a particularly long release cycle, has rejected the patch for special reasons, or if this package is currently a dependency blocking many other packages, you can reference the patch link sent upstream in the PKGBUILD and submit this modification to this repository.
Ported packages are maintained in the form of patches. Each package's patches are in its corresponding <package-name>
directory.
loong.patch
is a patch for the Arch Linux officialPKGBUILD
- Please do not submit modifications to the
arch
array inloong.patch
- Please do not submit modifications to the
- Additionally, we may maintain some patches or configuration files for upstream packages, which will also be placed in the same directory
For Arch Linux official packages, you can find them at https://gitlab.archlinux.org/archlinux/packaging/packages/<package-name>
. On Arch Linux, you can also download them via pkgctl repo clone <package-name>
or view them via pkgctl repo web <package-name>
.
Follow the guidelines similar to the Arch Linux RISC-V Porting Project:
Clearly state the reason for the modification in the commit message or PR. For example, "This PR fixes a compilation error," "Why this new dependency is added," "Why this additional parameter is needed," etc. Explaining "why" is part of our workflow. Firstly, it helps with future maintenance, so we won't be confused by a completely uncommented modification. Secondly, it helps newcomers, allowing them to find relevant fixes when they encounter related errors in the repository.
In the PKGBUILD, also clearly annotate the reasons for modifications, such as adding make parameters, modifying cflags, etc., and include comments on "what this fixes."
Follow the guidelines similar to the Arch Linux RISC-V Porting Project:
- Create a new branch from the head of the master branch for each modification, usually naming the branch after the package.
- Create a folder named after the package. Put the patch generated by git diff for the PKGBUILD into a file named riscv64.patch and place it in this folder. Also, put patches for source code modifications in this folder.
- Follow the above specifications, carefully commit, and initiate a PR.
Follow the guidelines similar to the Arch Linux RISC-V Porting Project:
- If the current repository does not have a patch for this package, use
addpatch: pkgname
as the title- If this PR is a modification to an existing package, use
upgpatch: pkgname
as the title- If this PR is to delete a patch from the repository, use
rmvpatch: pkgname
as the title- If this PR is a modification to
qemu-user-blacklist.txt
, useqemu-user-blacklist:
followed by the specific modification, e.g.,qemu-user-blacklist: add pkgname
Please note that there should be a space around the colon in the title before writing the package name. It is also strongly recommended not to use
git commit -m "title"
alone; it is recommended to clearly state the content and reason for the modification in the commit body.
If version control is needed for the ported packages, the pkgrel
field in the PKGBUILD
file can be modified. The modified pkgrel
field should follow the format of major.minor
, where major
must remain consistent with the upstream, and minor
is used for version control of the ported package. The modification to the pkgrel
field should be exported in loong.patch
along with other changes to the PKGBUILD
.
- Artifacts of single commit and branches not for PR can be download as
https://loong-pkgs.lcpu.dev/branch/<branch-name>/<pkgname>-<pkgver>-<pkgrel>-<arch>-<commit-hash>.tar.xz
, and logs can be download ashttps://loong-pkgs.lcpu.dev/branch/<branch-name>/build-<unix-time-stamp>.log
. - Artifacts of PR can be download as
https://loong-pkgs.lcpu.dev/pr/<pr-number>/<pkgname>-<pkgver>-<pkgrel>-<arch>-<commit-hash>.tar.xz
, and logs can be download ashttps://loong-pkgs.lcpu.dev/pr/<pr-number>/build-<unix-time-stamp>.log
.
本仓库包含了 Loong Arch Linux 包的补丁,主要以 patch 的方式,为 Arch Linux 提供 Loongarch64 架构支持。
遵守与 Arch Linux RISC-V 移植项目类似的规则建议:
对软件包的 源代码 的所有修改都 优先 提交给上游,如果上游很活跃,并且在短期合并了这个修复补丁,可以等待上游发版本。
上游已经长期失联/不积极修复 BUG/发版周期特别漫长/因为特殊原因拒绝了补丁/这个软件包目前作为依赖,卡住了很多其他的软件包 的情况下,可以在 PKGBUILD 里引用发给上游的补丁链接,并把这个对 PKGBUILD 的修改发到这个仓库里。
移植的软件包以补丁的形式维护。每个软件包的补丁都在其对应的 <package-name>
目录下。
loong.patch
是对 Arch Linux 官方的PKGBUILD
的补丁- 在
loong.patch
中请不要提交对arch
数组的修改
- 在
- 除此之外,我们还可能会维护部分针对上游软件包的补丁或者配置文件,这些文件也会放在相同目录下
对于 Arch Linux 官方的软件包,都可以在 https://gitlab.archlinux.org/archlinux/packaging/packages/<package-name>
找到,在 Arch Linux 上,还可以通过 pkgctl repo clone <package-name>
下载或者 pkgctl repo web <package-name>
查看。
遵守与 Arch Linux RISC-V 移植项目类似的规则建议:
在 commit message,或者 PR 里写清楚修改的原因。比如“这个 PR 能修复什么编译错误”,“为什么要加上这个新的依赖”,“为什么要多加这么一行参数”等等。 讲清楚“为什么”属于我们工作流的一部分。一是为了以后方便维护,不会看着一个完全没有注释的修改,摸不着头脑。 还有就是能帮助新人,让他们来仓库查相关错误时能通过编译错误,检索到相关的修复方法。
在 PKGBUILD 中也一定要注释清楚修改原因,比如添加 make 参数, 修改 cflags 之类的,添加上“这么做能修好什么”相关的注释。
遵守与 Arch Linux RISC-V 移植项目类似的规则建议:
- 每一次修改都从 master 分支的头创建一个新的分支,通常我们用包的名字来当分支名。
- 创建一个和包名字同名的文件夹。把 git diff 生成的,对 PKGBUILD 的补丁放进名为 riscv64.patch 文件,并放入这个文件夹里。对源码修改的 patch 也放进这个文件夹里。
- 按照上面的规范,认真做好 commit 并发起 PR
遵守与 Arch Linux RISC-V 移植项目类似的规则建议:
- 如果当前仓库没有这个包的 patch,标题用
addpatch: pkgname
- 如果这个 PR 是对原有包的修改,标题用
upgpatch: pkgname
- 如果这个 PR 是删除掉仓库内的 patch,标题用
rmvpatch: pkgname
- 如果这个 PR 是对
qemu-user-blacklist.txt
的修改,标题用qemu-user-blacklist:
加上具体修改内容,例:qemu-user-blacklist: add pkgname
请注意标题里的冒号附近需要空一格,再写包名。 同时强烈建议不要只用
git commit -m "title"
,建议在 commit body 里写清楚这次修改的内容和原因。
如果需要对移植的包进行版本控制,可以修改 PKGBUILD
文件中的 pkgrel
字段,修改后的 pkgrel
字段需要满足 major.minor
的格式,其中 major
必须与上游保持一致,minor
用于移植包的版本控制。对 pkgrel
字段的修改与其他 PKGBUILD
的改动应一并导出到 loong.patch
中。
- 单个提交和非 PR 的分支的构建完成的包可以在
https://loong-pkgs.lcpu.dev/branch/<branch-name>/<pkgname>-<pkgver>-<pkgrel>-<arch>-<commit-hash>.tar.xz
下载,日志可以在https://loong-pkgs.lcpu.dev/branch/<branch-name>/build-<unix-time-stamp>.log
下载。 - PR 的构建完成的包可以在
https://loong-pkgs.lcpu.dev/pr/<pr-number>/<pkgname>-<pkgver>-<pkgrel>-<arch>-<commit-hash>.tar.xz
下载,日志可以在https://loong-pkgs.lcpu.dev/pr/<pr-number>/build-<unix-time-stamp>.log
下载。