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

[Ximin Luo]

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