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==--