Quoting Fabian Grünbichler (2026-05-16 16:37:26) > 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.
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). > > 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 ;) As long as you enjoy the jorney :-) - Jonas -- * 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
signature.asc
Description: signature
