Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/lcpu-club/loongarch-packages

Loong Arch Linux Patch Set
https://github.com/lcpu-club/loongarch-packages

archlinux linux linux-distribution loongarch patch

Last synced: 4 months ago
JSON representation

Loong Arch Linux Patch Set

Host: GitHub
URL: https://github.com/lcpu-club/loongarch-packages
Owner: lcpu-club
License: gpl-3.0
Created: 2024-07-30T06:25:08.000Z (6 months ago)
Default Branch: master
Last Pushed: 2024-10-18T18:49:24.000Z (4 months ago)
Last Synced: 2024-10-18T22:38:08.854Z (4 months ago)
Topics: archlinux, linux, linux-distribution, loongarch, patch
Language: Shell
Homepage:
Size: 1.43 MB
Stars: 7
Watchers: 3
Forks: 7
Open Issues: 11
Metadata Files:
- Readme: README.md
- License: COPYING

Awesome Lists containing this project

README

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

中文说明从[这里](#arch-linux-loongarch-补丁集)开始。

## When to Submit Code Fixes to Which Repository

Follow the [guidelines](https://github.com/felixonmars/archriscv-packages/wiki/%E5%BC%80%E5%A7%8B%E9%A1%B9%E7%9B%AE%E8%B4%A1%E7%8C%AE%E5%92%8C%E7%A4%BE%E5%8C%BA%E4%BA%A4%E6%B5%81%E5%89%8D%E5%BF%85%E8%A6%81%E5%AD%A6%E4%B9%A0%E7%9A%84%E6%A6%82%E5%BF%B5) similar to the [Arch Linux RISC-V Porting Project](https://github.com/felixonmars/archriscv-packages):

> 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 `` 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/`. On Arch Linux, you can also download them via `pkgctl repo clone ` or view them via `pkgctl repo web `.

## Annotate All Modifications

> 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

> 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

> - 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//----.tar.xz`, and logs can be download as `https://loong-pkgs.lcpu.dev/branch//build-.log`.
- Artifacts of PR can be download as `https://loong-pkgs.lcpu.dev/pr//----.tar.xz`, and logs can be download as `https://loong-pkgs.lcpu.dev/pr//build-.log`.

# Arch Linux Loongarch 补丁集

本仓库包含了 Loong Arch Linux 包的补丁，主要以 patch 的方式，为 Arch Linux 提供 Loongarch64 架构支持。

## 什么时候给什么仓库提交代码修复

遵守与 [Arch Linux RISC-V 移植项目](https://github.com/felixonmars/archriscv-packages)类似的[规则建议](https://github.com/felixonmars/archriscv-packages/wiki/%E5%BC%80%E5%A7%8B%E9%A1%B9%E7%9B%AE%E8%B4%A1%E7%8C%AE%E5%92%8C%E7%A4%BE%E5%8C%BA%E4%BA%A4%E6%B5%81%E5%89%8D%E5%BF%85%E8%A6%81%E5%AD%A6%E4%B9%A0%E7%9A%84%E6%A6%82%E5%BF%B5)：

> 对软件包的 _**源代码**_ 的所有修改都 _**优先**_ 提交给上游，如果上游很活跃，并且在短期合并了这个修复补丁，可以等待上游发版本。
>
> 上游已经长期失联/不积极修复 BUG/发版周期特别漫长/因为特殊原因拒绝了补丁/这个软件包目前作为依赖，卡住了很多其他的软件包的情况下，可以在 PKGBUILD 里引用发给上游的补丁链接，并把这个对 PKGBUILD 的修改发到这个仓库里。

## 维护内容

移植的软件包以补丁的形式维护。每个软件包的补丁都在其对应的 `` 目录下。

- `loong.patch` 是对 Arch Linux 官方的 `PKGBUILD` 的补丁
- 在 `loong.patch` 中请**不要**提交对 `arch` 数组的修改
- 除此之外,我们还可能会维护部分针对上游软件包的补丁或者配置文件，这些文件也会放在相同目录下

对于 Arch Linux 官方的软件包，都可以在 `https://gitlab.archlinux.org/archlinux/packaging/packages/` 找到，在 Arch Linux 上，还可以通过 `pkgctl repo clone ` 下载或者 `pkgctl repo web ` 查看。

## 给所有的修改注释

> 在 commit message，或者 PR 里写清楚修改的原因。比如“这个 PR 能修复什么编译错误”，“为什么要加上这个新的依赖”，“为什么要多加这么一行参数”等等。
> 讲清楚“为什么”属于我们工作流的一部分。一是为了以后方便维护，不会看着一个完全没有注释的修改，摸不着头脑。
> 还有就是能帮助新人，让他们来仓库查相关错误时能通过编译错误，检索到相关的修复方法。
>
> 在 PKGBUILD 中也一定要注释清楚修改原因，比如添加 make 参数，修改 cflags 之类的，添加上“这么做能修好什么”相关的注释。

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

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

### Commit Title

> - 如果当前仓库没有这个包的 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//----.tar.xz`下载，日志可以在 `https://loong-pkgs.lcpu.dev/branch//build-.log`下载。
- PR 的构建完成的包可以在 `https://loong-pkgs.lcpu.dev/pr//----.tar.xz`下载，日志可以在 `https://loong-pkgs.lcpu.dev/pr//build-.log`下载。