Control: tags -1 + patch Dear Maintainer, 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.) Packaging notes: * 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. * 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). * 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. * No debian/patches needed. 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 * Plugin API_VERSION bumped 4 -> 5 upstream; not applicable to this packaging (plugins are disabled via -DWASMEDGE_BUILD_PLUGINS=OFF). 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. Intent: After this lands in unstable, the Ubuntu development series currently carries no delta, so it should auto-sync (or a sync can be requested if a freeze intervenes). A sponsor upload is welcome if more convenient. Happy to adjust anything or push the branch to Salsa once my account is approved. Thanks for maintaining wasmedge! Vincent WasmEdge upstream / Second State
Thanks so much! It's great to see you getting involved :) Yep, finally! This was https://github.com/WasmEdge/WasmEdge/issues/4495, fwiw. Straightforward enough :) Good catch! 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). 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 :) 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 contributing back! Best, Faidon
Hi Faidon, Thanks for the quick and thorough review! On the ABI issue: agreed on all points — rebuilding crun alone doesn't cover partial upgrades or out-of-archive binaries. Symbol versioning is a good suggestion; let's settle the approach in https://github.com/WasmEdge/WasmEdge/issues/4933 as you proposed. I'll follow up there with the other upstream maintainers and keep this bug updated. Thanks for taking care of the test suite run, and for the Debusine pointer — I'll give it a try once my Salsa account is approved (still pending). Enabling plugins does sound like a worthwhile follow-up; I can't promise a timeline, but I'll keep it on my radar once 0.17.0 lands. Thanks again, and looking forward to working together! Vincent WasmEdge upstream / Second State
Hi Faidon, Good news on the ABI question we paused on: it's resolved upstream, and along the lines you suggested. 1) Symbol versioning, not a SONAME bump Upstream adopted symbol versioning. The five "limit" C functions now export a default @@WASMEDGE_0.17 plus a @WASMEDGE_0.16 compat shim, driven by an ELF version script (lib/api/libwasmedge.lds) and .symver aliases in lib/api/wasmedge_compat.cpp: PR: https://github.com/WasmEdge/WasmEdge/pull/4951 (merged) Issue: https://github.com/WasmEdge/WasmEdge/issues/4933 (closed) So the SONAME stays libwasmedge.so.0 and no package rename is needed, while a previously-compiled 0.16 consumer keeps the old ABI. 2) Verified that crun stays safe without a rebuild The subtle part is whether an already-compiled 0.16 binary (which carries an *unversioned* reference, like Debian's crun) binds to the @WASMEDGE_0.16 shim rather than the new @@0.17 default. I tested this empirically: a consumer compiled against Debian's real libwasmedge-dev 0.16.1 headers, run against the new library, round-trips the Limit struct correctly. So partial upgrades are safe; crun does not need a rebuild for correctness (though one is still fine to do). 3) Test suite on the released tarball I ran upstream's test suite (ctest) against the 0.17.1-rc.2 tag, built with the package's own build-deps (LLVM on), in a sid container: ctest: 100% tests passed, 0 tests failed out of 27 (includes the AOT/LLVM tests, e.g. wasmedgeAPIAOTCoreTests; debian:sid, arch arm64) This is arm64, so it's supporting evidence, not the authoritative run — the amd64 run is still yours. Full ctest output is attached (testsuite-rc2-arm64.log). On the integration path, I'd like your preference: (a) Wait for the upcoming 0.17.1 release, which carries the symbol versioning natively, and package that as 0.17.1-1 (no debian/patch needed). 0.17.1 is at rc.2 as of 2026-06-29, so a final tag looks close. (b) Or, if you'd rather not wait, I can package 0.17.0-1 now and carry PR #4951 as a debian/patch in the interim. I lean towards (a) for a cleaner result, but I'm happy to do (b) if you prefer to move sooner. Either way I'll refresh the packaging branch and patch series to match the choice. On Debusine: thanks again for the pointer, but it looks like external login is currently limited to DDs and DMs, so I can't drive it myself as an upstream contributor. I'll rely on your amd64 test run for the authoritative result, as you offered. Thanks again for the guidance on this. Vincent WasmEdge upstream / Second State
Hi Faidon, Quick update: 0.17.1 was released (2026-07-06) and carries the symbol versioning natively, so the a/b question from my last mail is moot -- no debian/patch is needed. I've prepared 0.17.1-1 and opened a Salsa MR: https://salsa.debian.org/debian/wasmedge/-/merge_requests/2 Summary of the update: - Plain 0.17.1-1 (no +dfsg; upstream dropped the only excluded file, so the pristine tarball is DFSG-compliant). - debian/libwasmedge0.symbols regenerated for the symbol-versioned ABI: every export now under @WASMEDGE_0.16, and the five limit functions also export @WASMEDGE_0.17 with an @WASMEDGE_0.16 compat alias. SONAME stays libwasmedge.so.0, so a 0.16 consumer like crun keeps working without a rebuild. - No debian/patches needed. - Built clean in a sid container (arm64): dpkg-buildpackage OK, empty dpkg-gensymbols diff, lintian no E/W. The symbols were regenerated on arm64, so amd64 remains the authoritative run -- yours, as you offered. Ready for your review whenever it suits. Thanks, Vincent WasmEdge upstream / Second State