+ "content": "Licensing . The wheels built by the python-wheels project use a variety of open-source licenses. Since RISE is the distributor of riscv64 wheels in the corresponding package registry, we must ensure that the wheels adhere to each project’s licensing requirements. More specifically, check: . | The built wheel contains one or more LICENSE files corresponding to those contained in the upstream project source. | If the wheel ships any statically- or dynamically-linked libraries from other projects, the licensing requirements for those projects are also correctly addressed. | . If either point is not met, we should follow the Patching a Project process for patching our build, and submit an issue and/or PR upstream to help them comply with license requirements as well. Publishing GPL Sources . Some builds statically or dynamically link against GPL-licensed components that aren’t part of the upstream project itself, but come from our build environment - most commonly the toolchain baked into the manylinux_riscv64 container (e.g. gcc). As the distributor of the resulting wheel, we need to make the corresponding source available permanently, not just for as long as a CI job’s artifacts happen to be retained. Use the collect-gpl-sources action in a job alongside build_wheels to pull the same container image and bundle the source RPM(s) for one or more installed packages into a gpl-sources.tar artifact: . gpl_sources: name: Collect GPL sources (gcc) for <package> $ runs-on: ubuntu-24.04-riscv steps: - name: Collect gcc source RPM from manylinux_riscv64 uses: riseproject-dev/python-wheels/actions/collect-gpl-sources@main with: image: $ packages: gcc output: gpl-sources.tar - uses: actions/upload-artifact@v7 with: name: <package>-$-gpl-sources path: gpl-sources.tar if-no-files-found: error . Pin MANYLINUX_RISCV64_IMAGE as a workflow-level env and pass it to both CIBW_MANYLINUX_RISCV64_IMAGE in the build job and this job, so the sources collected actually correspond to the toolchain that produced the wheels (see build-numpy.yml for a complete example). Then add gpl_sources to the publish job’s needs:, and pass the artifact through to publish-wheels: . gpl-sources-artifact: <package>-$-gpl-sources gpl-sources-release-tag: <package>-v$ gpl-sources-description: gcc . publish-wheels publishes the tar as a permanent asset on a GitHub Release (created if it doesn’t already exist) and passes its download URL to ci_scripts/update_doc.py, which renders it as a comment: on the new version entry automatically - no manual doc edit needed. Adding Builds for Rust Packages . Modules which are cross-compiled from Rust to Python typically use maturin. This greatly simplifies building binary wheels for riscv64, but there is a pitfall here to watch out for - many projects use a matrix definition looking like: . matrix: platform: - runner: ubuntu-22.04 target: x86_64 - runner: ubuntu-22.04 target: x86 - runner: ubuntu-22.04 target: aarch64 - runner: ubuntu-22.04 target: armv7 - runner: ubuntu-22.04 target: ppc64le . For riscv64 and some other architectures, the rustc toolchain target name does not follow this simple pattern (i.e. the arch part of the triple is not exact): . tgamblin@alchemist ~/workspace/baylibre/rise/python-wheels (tgamblin/dev-guide)$ rustup target list | grep riscv64 riscv64a23-unknown-linux-gnu riscv64gc-unknown-linux-gnu riscv64gc-unknown-linux-musl riscv64gc-unknown-none-elf riscv64imac-unknown-none-elf . Simply adding a new line with target: riscv64 will lead to build failures. The recommended approach here is to make the matrix more explicit, then add riscv64, so that each entry looks like: . - runner: ubuntu-24.04-riscv target: riscv64gc-unknown-linux-gnu arch: riscv64 . Note that doing so typically requires a tweak to an Upload wheels step or similar, so that it uses the arch field: . - name: Upload wheels uses: actions/upload-artifact@v4 with: name: wheels-linux-$ path: dist . GCC Version Mismatches . Some packages may require GCC 14 or later to compile for riscv64. If your build requires GCC 14, ensure that you are either using a cibuildwheel container approach, or (if the project doesn’t use cibuildwheel) have an appropriate workaround in place, since the RISC-V runners currently ship GCC 13 by default. Upstream Status Tags . We use a pattern established by the Yocto Project for indicating the purpose and status of custom patches which we carry for various projects. Each tag should be specified in the patch file’s commit message like so: . Upstream-Status: <type> [reason and/or link] . There are five valid Upstream-Status types for the python-wheels repository: . | Issue: An issue has been opened on the upstream project to indicate a bug was found during build/test. The issue link should be included. | Submitted: A change was submitted to fix an issue upstream, but we are carrying the patch ourselves until it’s merged and released in a future version. Include a link to the upstream PR and/or merged commit. | To upstream: The patch needs to be submitted upstream, but submission is blocked. Include an explanation of why it can’t be submitted upstream yet. | Inappropriate: The patch includes changes which are necessary for riscv64 builds and/or our infrastructure, but are not relevant upstream. Include a short description of why. | Backport: The patch includes a fix which is already merged in an upstream release version, but not in the version we’re trying to build. Include a link and short description of the problem. | . Including an Upstream-Status tag is a baseline requirement for custom patches, and it is automatically searched for by the ci_scripts/check_patch.py script when submitting a PR. However, any additional detail which can be provided in each patch’s commit message is helpful for maintenance. ",
0 commit comments