On Wed, 2022-11-02 at 12:30 +0800, Bo YU wrote: > Recently I have a help/requests from one group that focuses on > testing most Linux distros about RISC-V. Debian welcomes people who want to contribute by testing things: https://www.debian.org/intro/help#testing I think it is very important for users of Debian riscv64 to test the port, report issues in the appropriate way and or contribute fixes. The first thing for testers to note is that all issues they find on riscv64 should be checked on other Debian arches like amd64 or arm64 too, since the issue might not be specific to RISC-V. When the issue is not specific to riscv64 they should report issues to generic channels. If it isn't clear where the cause of the issue is or the people who found it don't have enough knowledge, then it would be a good idea to contact the #debian-riscv IRC channel or this list asking for help and we will reply with suggestions, links and debugging ideas. Since many of the people involved in Debian are volunteers and or have limited time available, it is important for testers to be willing to follow up on the suggestions to figure out the issue and learn from the suggestions, so that they are able to figure out the next issue they find on their own and directly report issues and or send fixes. When the cause of the issue is clear but the issue is complex enough to make it hard to fix or the people who found the issue don't have enough knowledge to fix it, reporting a clear bug either upstream or to Debian (with CC debian-riscv and severity normal) is the way to go. Once a fix for the issue has been created, the best option is to contribute it to the upstream project for the affected package (so that all distributions benefit), or to the Debian packaging where that is the cause of the issue. Contributing the fix to Debian instead is good for when the issue needs backporting while waiting on an upstream release or if upstream is taking some time to accept the fix. > I can imagine the scenario from my personal experience: These are all great things for contributors to test manually, but eventually it would be good to have automated testing. > 1. system boot (verify kernel), Automated testing of this might be possible if ci.debian.net supported the isolation-machine autopkgtest restriction, but that would need additional work in the service itself and also require a variety of hardware to submit tests, possibly at different hosting. In addition the LAVA tool by Linaro for ARM hardware was created for automated verification of low level software like bootloaders and Linux. It would be great to see RISC-V hardware vendors using it. https://validation.linaro.org/ > 2. daily upgrade system on sid and to see what breaks something, Automated testing of this can be done using the piuparts tool. Unfortunately the Debian piuparts service only supports one architecture, it needs work on the codebase before workers from additional arches can be added. https://piuparts.debian.org/ > 3. normal login from DM. Automated testing of this (and desktop apps) can be done using the openQA tool, but this is currently amd64-only. https://openqa.debian.net/ -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part