Re: backport of wasm-tools

On Sat, May 16, 2026, at 10:42 AM, Jonas Smedegaard wrote:
> Hi Fabian,
>
> Quoting Fabian Gr=C3=BCnbichler (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 fe=
ature
needs to be dropped), which can easily be carried as delta for backporti=
ng 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 d=
id,
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-backpo=
rts,
and the changes on top that just make sense for trixie-backports. But it=
 will
take a bit ;)

Fabian