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 <plugw...@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-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers >