Re: backport of wasm-tools

Jonas Smedegaard <[email protected]> Sat, 16 May 2026 16:42:34 +0200
Newsgroups gmane.linux.debian.rust,gmane.linux.debian.backports.general
Message-ID <[email protected]>
--===============4797606176237513266==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Quoting Fabian Gr=C3=BCnbichler (2026-05-16 16:37:26)
> 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.
>=20
> There's a few low-hanging fruit I think (slight version mismatch between
> unstable and trixie, but everything compatible) that can be applied for b=
oth
> branches.
>=20
> Then there's slightly annoying things like hashbrown (compatible, but fea=
ture
> needs to be dropped), which can easily be carried as delta for backportin=
g I
> think.
>=20
> > 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.
>=20
> 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 di=
d,
> it's a single mechanical patch since it is mostly dropping a feature and
> renaming things.

Oh, I certainly did not mean to suggest we deviate API from upstream.

I agree that rand changes are unlikely to be backportable, just used it
as an example. I see now that it was more confusing than helping :-/

> > 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).
>=20
> I will submit both what I think makes sense for unstable + trixie-backpor=
ts,
> and the changes on top that just make sense for trixie-backports. But it =
will
> take a bit ;)

As long as you enjoy the jorney :-)

 - Jonas

--=20
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
--===============4797606176237513266==
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmoIglcACgkQLHwxRsGg
ASFAUg//T0Nf8x/mppC9Z5PN0aNlgojkXRWt0B/1Mc0EIFD6CB/W9mUdXZQyro6w
/cNS5wjxxNISGmtD3fTiQm9nThfrn9Pv4akpXlmqqOXeWap4qKBeOqaBwZgv3bTo
VikNqaAINwkEwmoAOH6sjYpVgEvpH0IMssB36EV+lwtyooQ2FhP5sx3OzKnR2JP6
gecqZ8p5uO3yjAfrHqqVrDCEQY0he4ybyFmmm4ApKex5C8LhNitJVHOmA+XUEs31
zxvKk5AhTd8zBfN9fbSD4KzbNkMKZCEAe57Mp1xo1+1g5QiwW4ZmI9OsH/qCqNO9
N2HY1xmkM+4QM4ZYPWpYlLQU4Fc6V1A+yQxkeetRdZKE/bVnHoLWzBmrc5amNXvR
5BCu1/LxuaNQrNawtLsuRa58Gh+H6lxgXZdiIxQhfPxrRl5HY3FoH4NUaOk5kT7G
bia7l+cyJNJeA8aGyVw3/EypKEs5fSNKjMP3IYPQm2FEy367v5K7ot2S2Qtv8Q4R
2YOnZ9fcZlnWxu9ZImL497Q/pIKzK0puLGL0QDwZt2jcMhLqbjkm1Iagif+tzAaF
Q13A5E1rk/0OqIhW0/Vk1STrswTZE0pUL555HZnzxky12rtE6qbk7k8OUekLDOQR
4QIOSYUGRtP3mRY2vyX5eSNlVO2RSvT9HdQwygDfqpapgSmyCi4=
=3z4L
-----END PGP SIGNATURE-----

--===============4797606176237513266==--