[Pkg-rust-maintainers] Bug#931003: Fixing rust package FTBFS in buster

[peter green]

On 08/05/2021 17:36, Adrian Bunk wrote:
> On Wed, May 05, 2021 at 08:01:13AM +0100, peter green wrote:
>> On 04/05/2021 12:28, Santiago Vila wrote:
>>> On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote:
>>>>> This was automatically closed by ftpmaster because the package was
>>>>> removed from unstable, but this still does not fix the FTBFS problem
>>>>> in stable.
>>>>
>>>> Unfortunately I don't think a proper fix will be forthcoming, upstream
>>>> has abandoned the crate in question.
>>>
>>> It does not need to be a perfect fix. It is enough that dpkg-buildpackage
>>> exits with status 0. If the tests are no longer valid, disabling them
>>> should be much better than nothing, because packages in stable must
>>> build in stable.
>>
>> I'm prepared prepare such uploads if the stable release managers
>> are prepared to accept them.
> 
> Usually they are receptive for reasonable FTBFS fixes,
> and my rust-rustyline bug was part of me doing a find+fix round.
> 
>> ...
>> rust-simd: abandoned upstream, not in testing/unstable probably not properly fixible, could disable test build during package build to fix FTBFS.
>> rust-coresimd: abandoned upstream, not in testing/unstable probably not properly fixible, could disable test build during package build to fix FTBFS.
>> rust-nodrop-union: abandoned upstream, not in testing, broken in unstable probably not properly fixible, could disable test build during package build to fix FTBFS.
> 
> Is it only the test that is broken?
> Or is the test due to some minor functionality breakage?
> In that case, ignoring test problems would be the correct action.
> 
> But if the packages are just completely broken with current rustc,
> then RM bugs against release.debian.org asking for removal in the
> next buster point release would be the correct action for such
> leaf packages.

As best I can tell they are just completely broken with current rustc.

They are not leaf packages (though naive search tools may
think they are because most dependencies between rust packages
go via virtual packages).

The reverse dependency graphs look like

librust-simd-dev -> librust-encoding-rs+simd-accel-dev, librust-encoding-rs+simd-dev
librust-coresimd-dev -> librust-packed-simd+coresimd-dev
librust-nodrop-union-dev -> librust-nodrop+nodrop-union-dev, librust-nodrop+use-union-dev

So before rust-simd, rust-coresimd and rust-nodrop-union could
be dropped it would be nessacery to modify rust-encoding-rs, rust-packed-simd
and rust-nodrop to drop the binary packages that depend on them.

I'm quite prepared to do this if there is consensus to do so
but I'm not going to make unilateral moves here.