On Fri, Jun 05, 2026 at 03:42:33AM +0800, Zigang Lin wrote: > Upstream WasmEdge 0.17.0 was released on 2026-05-18: > https://github.com/WasmEdge/WasmEdge/releases/tag/0.17.0 > > I am a WasmEdge upstream developer (Second State). I have prepared and > validated a packaging update to 0.17.0-1 and attach the changes as a git > format-patch series against debian/latest. (I intended to open a Salsa MR, > but my Salsa account is still pending admin approval; I will reference > this bug from the MR once that clears.)
Thanks so much! It's great to see you getting involved :) > * Drop the +dfsg repack: upstream removed the only excluded file > (utils/android/app/gradle/wrapper/gradle-wrapper.jar), so the pristine > tarball is DFSG-compliant. Repacksuffix dropped from debian/watch, > Files-Excluded dropped from debian/copyright. uscan with the updated > watch file produces wasmedge_0.17.0.orig.tar.xz directly. Version > ordering is safe (0.17.0-1 > 0.16.1+dfsg-1), no epoch needed. Yep, finally! This was https://github.com/WasmEdge/WasmEdge/issues/4495, fwiw. > * debian/libwasmedge0.symbols updated from the dpkg-gensymbols diff: > 12 new C symbols @0.17.0 (RunMode, Limit-context and > RegisterImportWithAlias families); 3 C++ WasmEdge::Allocator symbols > changed uint32 -> uint64 (Memory64 support). Straightforward enough :) > * debian/rules: generate a VERSION file from DEB_VERSION_UPSTREAM before > configure (removed in clean), so `wasmedge --version` reports the real > version instead of "0.0.0-unreleased". This also affects the current > 0.16.1+dfsg-1 package in unstable. Good catch! > ABI/API impact (please review): > > * SONAME is unchanged: libwasmedge.so.0 (upstream WASMEDGE_CAPI_SOVERSION > is still "0"; the release notes' "SOVERSION bumped to 0.1.1" actually > refers to WASMEDGE_CAPI_VERSION, the file version). No package rename. > * However, upstream made breaking C API changes under the same SONAME: > the WasmEdge_Limit struct was replaced by a limit context, and several > functions keep their symbol names with changed signatures. The C++ > Allocator symbols changed as noted above. crun (the only external > reverse dependency of libwasmedge0) should be rebuilt and checked after > acceptance. As an upstream developer I have raised the need for a > proper SONAME bump on C API breaks with the project: > https://github.com/WasmEdge/WasmEdge/issues/4933 This is actually problematic. Rebuilding crun alone isn't enough - we'll need to add Breaks here to ensure that partial upgrades work, as well as testing migration etc. This would also break other code that users may have. Thanks for raising this in the upstream bug tracker. I've just offered an alternative there (symbol versioning). We can discuss that there for a bit before proceeding here. We could pursue that in the Debian package through debian/patches if upstream decides to push that to a later version (or not implement at all). > * Plugin API_VERSION bumped 4 -> 5 upstream; not applicable to this > packaging (plugins are disabled via -DWASMEDGE_BUILD_PLUGINS=OFF). Ack. If you're looking for your next project, enabling plugins has been a long-standing TODO item of mine and I just haven't found the time :) > Validation performed: > > * dpkg-buildpackage -us -uc -b in a debian:sid container (arm64): clean > build from a pristine tree; all 5 binary packages built. > * lintian on the .changes: no findings. > * Smoke test: installed wasmedge + libwasmedge0; `wasmedge --version` > prints "wasmedge version 0.17.0"; the new --run-mode flag is present. > * Limitations: this was not a clean sbuild chroot, the build arch was > arm64 (not amd64), and the test suite was skipped > (DEB_BUILD_OPTIONS=nocheck). An sbuild run on amd64 with tests is still > advisable before upload. Test suite is a must! I'll take care of that. Once you get your Salsa account, you could also use Debusine[1] for pre-testing uploads (before uploading)[2] across both amd64 and arm64. (Enabling riscv64 is also another project I haven't found the time for, 1: https://wiki.debian.org/DebusineDebianNet 2: https://debconf25.debconf.org/talks/29-using-debusine-to-pre-test-your-unstable-uploads/ btw.) > Thanks for maintaining wasmedge! Thanks for contributing back! Best, Faidon
