Aurelien Jarno:
Hi Niels,On 2025-01-05 13:51, Niels Thykier wrote:Package: release.debian.org Severity: important X-Debbugs-Cc: ni...@thykier.net,debian-ri...@lists.debian.org Hi, I love the idea behind riscv, but I am concerned about riscv's current performance. As an example, the build times for gcc-13/gcc-14 on riscv is measured 5-13 days, which 1-2½ the standard testing delay. https://buildd.debian.org/status/logs.php?pkg=gcc-14&arch=riscv6413 days is specific to version 14.2.0-11, which does not run the testsuite in parallel to debug #1089007. [...] Now that the issue has been fixed, we are back to the 5-7 days area, which we agree is still too long.
Thanks for looking into this.I am glad that the 13 day case was an exceptional one-off and trivially fixed. I had not linked it #1089007.
This slowest seems unsustainable. Consider for pu-uploads, the deadline for uploads are generally a week before the point release and this would still not be sufficient for riscv to build the package in time for the RT to include package into the point release. This might be gcc specific problem or a concrete buildd being inadequate (linux, firefox-esr, and libreoffice seems to show much better build times). Nevertheless, I feel it warrants some analysis of the problem to understand if this will become a problem for Debian post release.We are aware that certain packages take quite long to build on the riscv64 build daemons, the other important known ones are ceph, llvm-toolchain-*, paraview and webkit2gtk.
For the ones following from the side-lines, most of these are in the 1-2 day territory with llvm-toolchain-19 being in the 3-4 from a quick eyeball scan of the buildd times. With gcc-X being about twice as slow as llvm-toolchain-X as noted above.
Related, in #1092155 I proposed we limit the build time to 48 hours (as a conversation starter). Using this as a basis, I would say that only gcc-X and llvm-toolchain-X are "problematic" still though the others are in the "at risk" zone. Though, please note that the 48 hours was a conversation starter for the idea and not a number that I knew every arch could reasonably achieve.
[...] We do have access to faster hardware options, such as Milk-V Pioneer and HiFive Premier P550, both of which offer significantly improved build times. However, these systems currently lack full upstream kernel support, which prevents their use as build daemons. That said P550 systems are already deployed for debci. From our tests these systems would allow us to bring the GCC build time back to reasonable levels, and also to reduce the number of riscv64 build daemons. Upstreaming for the Milk-V Pioneer has already started, but not yet for the HiFive Premier P550. In both cases we expect to be able to support them in a Debian kernel during the beginning of the Forky cycle, when backport kernels closely following upstream kernels will be possible again. [...] Regards Aurelien, for the riscv64 porters
Since I am not part of the RT, then I should not on their behalf of whether this is acceptable for Trixie.
Though, as a personal remark, I think this sounds very promising and if I was on the RT, I would probably consider this an acceptable position for the Trixie release.
I will leave the bug open for the RT to review and close if they agree. Best regards, NielsPS: Aurelien, I would also very much like your feedback on #1092155. Given your work with wanna-build, porting and setting up new architectures, I think you have a better idea about what it is feasible as far as build times go than I have. My "48 hour" conversation starter is from an outsider looking in, but I think you might be able to give a more nuanced perspective as someone, who interacts with the machinery on a much more regular basis.
OpenPGP_signature.asc
Description: OpenPGP digital signature
