Hi, On 2025-01-16 11:02, Simon McVittie wrote: > Control: found -1 2.58.93+dfsg-2 > > On Thu, 16 Jan 2025 at 10:45:28 +0000, Simon McVittie wrote: > > librsvg/2.59.2+dfsg-1 failed to build on mips64el across multiple retries, > > most recently in > > <https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.59.2%2Bdfsg-1&stamp=1736998842&raw=0>. > > This does not seem to be a new problem. Looking back at older buildd logs, > I can see the same error message > > > > error: failed to acquire jobserver token > > > > > > Caused by: > > > Bad address (os error 14) > > in most of the build logs since 2024-08-15: > > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-2&stamp=1723723132&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723726896&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723730758&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723736907&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723739367&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.58.93%2Bdfsg-3&stamp=1723746654&raw=0 > etc. > > So I don't think this is genuinely a regression between testing and > unstable as it would appear to be from librsvg's inability to migrate. > > It seems to happen consistently on mipsel-osuosl-04 and mipsel-osuosl-05 > (Quad Core Loongson 3A3000), with the package building successfully on the > slower buildds -01 and -02 (Rhino Labs UTM8), and inconsistently > succeeding or failing on -03 (another Quad Core Loongson 3A3000). > > As a stopgap to allow librsvg to migrate, please could someone schedule > a build on mipsel-osuosl-01 or mipsel-osuosl-02 and see whether that > succeeds? It'll be more time-consuming but better than nothing.
mipsel-osuosl-01 and mipsel-osuosl-02 have been disabled because they don't boot with the bullseye or bookworm kernels and thus we can't use them in unshare mode. Technically they have not yet been decommissioned, so while we can probably schedule a manual build in chroot mode, it looks wrong to get it uploaded in the archive. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net