Aurelien Jarno: > On 2019-08-08 16:02, Ximin Luo wrote: >> Ivo De Decker: >>> Hi, >>> >>> On Thu, Jul 25, 2019 at 06:47:47PM -0700, Ximin Luo wrote: >>>> Hi, rustc is currently blocked from migration: >>>> >>>> https://qa.debian.org/excuses.php?package=rustc >>>> >>>> <adsb> no, the issue is >>>> <adsb> Not built on buildd: arch mips binaries uploaded by infinity0 >>>> <adsb> Not built on buildd: arch mipsel binaries uploaded by infinity0 >>>> <kibi> if in doubt → https://release.debian.org/britney/excuses.yaml look >>>> for source: rustc and verdicts for that stanza. >>>> >>>> <infinity0> is that a recent change in policy? >>>> <adsb> it was announced on dda >>>> <adsb> in the most recent release team post there (the one just after >>>> release) >>> >>> The policy that checks if a package is built on the buildds is new. >>> >>> However, the policy that packages must be built natively (NOT cross-built), >>> even when they are uploaded by maintainers, and that it must be possible to >>> build packages on the buildds has existed for a very long time. Your >>> upload(s) >>> violate this. >>> >>> This makes your uploads RC-buggy. >>> >>> An exception will not be granted. >>> >> >> Do you have a link to a document describing this very old policy? I couldn't >> find a reference to it. >> >> It is possible in theory to build the packages on the buildds, by >> cross-compiling them with the --host flag to sbuild. The technical support >> for this is not part of dak. > > What do you mean exactly? Building it using the mips64el chroot, but > targeting mipsel? In that case I don't think the issue is dak, but > rather wanna-buildd/buildd/sbuild. >
I see ok, yes I'm not familiar with how those tools interact. The important thing is using --host it can be cross-compiled from any build architecture, I use amd64 because that's what I have. On the buildds, there would need to be some annotation along the lines of "for rustc:mips don't use an actual mips buildd but use a amd64 buildd and pass --host=mips". >> Your decision effectively forces us to file a RM request to FTP masters for >> all rust mips packages. There is no other feasible way we can satisfy your >> requirements. > > I have been able to build rustc on eller (same hardware than most of the > build daemons), by adding "export MALLOC_ARENA_MAX=1" to debian/rules. I > am not sure if it has a real effect or if I just got lucky. My theory is > a bad interaction between the rustc system allocator (glibc) and rustc > jemalloc allocator. They do not talk to each other, so there are not > able to reclaim memory that is available on the other side. > We disable jemalloc for Debian's rustc so everything should already be going through the glibc allocator. The native build does very occasionally succeed with enough memory on the buildds, but I don't know what affects this: 1.36.0+dfsg1-1 mips 1.34.2+dfsg1-1 mips 1.32.0+dfsg1-3 mips mipsel 1.32.0+dfsg1-1+b12 mips mipsel 1.32.0+dfsg1-1+b1 mips mipsel https://buildd.debian.org/status/logs.php?pkg=rustc > Maybe it's worth trying a last upload with this option enabled on > mips and mipsel before filing a RM request? Nowadays removing all > rust packages basically means dropping the architecture. > OK I can try that. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
