[Pkg-rust-maintainers] Bug#933045: release.debian.org: rustc can only be cross-compiled on mips; please override "Not built on buildd" blocker

[Aurelien Jarno]

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
aurelien at aurel32.net                 http://www.aurel32.net