On 2019-08-08 17:01, Ximin Luo wrote: > 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".
It's not possible to use an amd64 buildd, as it will result in a cross-built binary, which is not allowed as explained above. I am not sure if using a mips64el chroot and using --host=mipsel would work. In that case is the testsuite run anyway? > >> 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. Ok, then it might have just been chance :( > 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. Thanks! -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
