On Sat, May 16, 2026, at 10:42 AM, Jonas Smedegaard wrote: > Hi Fabian, > > Quoting Fabian Grünbichler (2026-05-16 08:41:18) >> rustc 1.95+ requires a version of wasm-libc that (build)-depends on >> wasm-tools. >> Since stable doesn't yet have that package, I am in need of a >> backport ;) > > Interesting challenge! > > [...] > >> Would you prefer me doing the backport (with minmimal changes if >> required), or would you be willing to take the above three packages >> on yourself? I will take care of the Rust team packages in any case. > > I have my hands full already, and plenty of exciting new packages to > fill any excess time. So I would prefer to not do the backporting > myself, but would prefer that you do it. > > If not too much extra work for you, then I would be quite interested in > making these package as backportable as possible, so please consider > filing bugreports for any changes to the unstable-targeted packages > that you think might make ease your backporting work - i.e. consider > "upstreaming" backporting changes to the main package where it makes > sense.
There's a few low-hanging fruit I think (slight version mismatch between unstable and trixie, but everything compatible) that can be applied for both branches. Then there's slightly annoying things like hashbrown (compatible, but feature needs to be dropped), which can easily be carried as delta for backporting I think. > Most cool, but probably also most challenging, would be patches for > covering both rand v0.8 and v0.10 - if someone figures out the pattern > for doing that (and it isn't super complex to implement), then I am > open to carrying and maintaining that type of patches in the main > package, so that backporting require no patches for that class of > issues. Yeah, I am not sure that will work without introducing artificial Debian-specific features or patching rand 0.10 in unstable to have compat stuff, I think it is probably easier to just undo the upgrade upstream did, it's a single mechanical patch since it is mostly dropping a feature and renaming things. > So what I mean is that I would prefer to not do the *initial* work if > making backports work, nor the housekeeping of ensuring that the > backports are in decent shape. But I don't mind added workload in my > regular maintenance to ease backportability, if offered patched (which > I then don't need to compose but need to maintain). I will submit both what I think makes sense for unstable + trixie-backports, and the changes on top that just make sense for trixie-backports. But it will take a bit ;) Fabian
