Arch Linux Loongarch Patches

This repository contains patches for Loong Arch Linux packages. These patches are used to provide support for the Loongarch64 architecture in Arch Linux.

中文说明从这里开始。

When to Submit Code Fixes to Which Repository

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.

Maintenance Content

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 official PKGBUILD
  • Please do not submit modifications to the arch array in loong.patch
• 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>.

Annotate All Modifications

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

Some Formatting Considerations for Submitting PRs

Follow the guidelines similar to the Arch Linux RISC-V Porting Project:

1. Create a new branch from the head of the master branch for each modification, usually naming the branch after the package.
2. 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.
3. Follow the above specifications, carefully commit, and initiate a PR.

Commit Title

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, use qemu-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.

Version control requirements

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 and logs download

• 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 as https://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 as https://loong-pkgs.lcpu.dev/pr/<pr-number>/build-<unix-time-stamp>.log.

Arch Linux Loongarch 补丁集

本仓库包含了 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 之类的，添加上“这么做能修好什么”相关的注释。

提交 PR 的一些格式注意事项

遵守与 Arch Linux RISC-V 移植项目类似的规则建议：

1. 每一次修改都从 master 分支的头创建一个新的分支，通常我们用包的名字来当分支名。
2. 创建一个和包名字同名的文件夹。把 git diff 生成的，对 PKGBUILD 的补丁放进名为 riscv64.patch 文件，并放入这个文件夹里。对源码修改的 patch 也放进这个文件夹里。
3. 按照上面的规范，认真做好 commit 并发起 PR

Commit Title

遵守与 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下载。