[Pkg-rust-maintainers] Bug#975191: Bug#975191: Bug#975191: re: rust-js-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Fabian Grünbichler]

On August 31, 2021 9:16 pm, Wolfgang Silbermayr wrote:
> On 8/31/21 4:25 PM, Bastian Germann wrote:
>> On Wed, 2 Dec 2020 02:46:36 +0000 peter green <plugwash at p10link.net> wrote:
>>>  > This will impact quite some other modules.
>>>
>>> I agree that the current autoremoval list looks pretty scary, so I decided
>>> to do some
>>> dependency analysis. It seems there are 5 source packages with direct or
>>> indirect hard
>>> dependencies on rust-js-sys.
>>>
>>> rust-www-sys
>>> rust-ring
>>> rust-rustls
>>> rust-sct
>>> rust-webpki
>> 
>> Hey,
>> 
>> I would like to get rustls migrating to bookworm but this is a blocker for it.
>> Can you please state if you want to fix this or would like help with it? I
>> guess importing the current version will do it.
> 
> Hi Bastian,
> 
> I'd be happy to support getting rustls to migrate as well.
> 
> After taking a look, "just" updating rust-js-sys to the latest version also
> requires an update of the wasm-bindgen related crates to the latest version
> (which currently is 0.2.76 across all of them):
> 
> wasm-bindgen-shared
> wasm-bindgen-backend
> wasm-bindgen-macro-support
> wasm-bindgen-macro
> wasm-bindgen
> 
> I did a quick test run updating all of these, and it basically works, once
> `syn` got updated. For `syn`, we have an RFS note indicating that autopkgtests
> don't work yet with the updated version and need some other packages such as
> `insta` uploaded before. I didn't dig too deeply into that part, but we might
> need to invest some additional work here.
> 
> Within the wasm-bindgen* group, I also stumbled over a few autopkgtest problems:
> 
> wasm-bindgen-macro-support has a few features that fail their tests, but I
> expect that these tests simply aren't intended to be run with only a single
> feature enabled. Would require some investigation and either fixing or marking
> them as broken. The rest of the tests succeeds.
> 
> wasm-bindgen-macro requires wasm-bindgen to be available for the autopkgtest,
> but it should be possible to handle that. In addition, it requires
> wasm-bindgen-futures 0.4, some more about that below.
> 
> wasm-bindgen requires js-sys 0.3 to be available for the autopkgtest, but
> again that can be handled.
> 
> js-sys requires wasm-bindgen-futures 0.4 for the autopkgtest as well.
> 
> Regarding wasm-bindgen-futures, that one has a dev dependency on
> futures-channel-preview in a 0.3 alpha version. We can basically handle that,
> but that crate received its last update about two years ago. At a quick look,
> it seems to be a bootstrapping crate that might be intended to be replaced by
> futures-channel which is available by now, but that didn't happen yet for
> whichever reason. Might be a topic to investigate upstream. That one pulls in
> futures-core 0.3, and thus requires an update of the futures ecosystem from
> 0.1 to 0.3 which by itself is a topic that is much larger than the
> wasm-bindgen topic that I describe here. There was already some preparation
> done by another team member, but I'm not sure when it was the last time
> somebody took a thorough look at what they prepared.

yeah, the -preview crates are relicts from a time when the futures/async 
stuff was not yet written in stone. they are all replaced by the 
non-preview version, in this case futures-channel. I plan on pushing 
forward the futures 0.3 (and related tokio 1.x and hyper/... ecosystems) 
update this fall, but it will be a process spanning months ;)

> 
> I'd love to work on untangling these issues, but once I start working on such
> a group of problematic packages, I usually discover blockers which stop my
> undertaking, and due to being a DM, I need a DD to either grant me upload
> access for the affected crates, or sponsor the upload for me, so it's quite
> tedious to finish such a group of packages, with all the inconveniences that
> come from the delays, such as packages failing to migrate for some time or
> autopkgtests failing until the required dependencies become available. If it
> was for me, we could go forward and upload the updates, but in the past it
> didn't take long until we collected many reports about failing or skipped
> autopkgtests.

the same applies to me modulo not even being a DM yet ;)

> That's what I can tell upfront from my quick evaluation, but speaking from
> experience, I'd expect some unforeseen roadblock to show up when working on it.
> 
> I hope this quick analysis gives you some insight into the overall state, and
> some idea where and how you would like to proceed. In case you need some
> support working on a specific crate, let me know.
> 
> Best regards,
> Wolfgang.
> 
> _______________________________________________
> Pkg-rust-maintainers mailing list
> Pkg-rust-maintainers at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>