Wasm module is now not built for Amazon Linux 2, Debian 11 and Ubuntu 2.0.04, since it requires cmake version newer than what's available on those OSes. wasm-wasi-component is not affected.
It's possible to have two versions of the same package installed on
debian-based multiarch systems - e.g. i386 alongside amd64. This means
that when getting the package status through dpkg-query we'd get a
duplicated string:
% dpkg-query -f '$${db:Status-Status}' -W libssl-dev
$installed$installed
% dpkg -l | grep libssl-dev
ii libssl-dev:amd64 3.0.11-1~deb12u2 amd64 Secure Sockets Layer toolkit - development files
ii libssl-dev:i386 3.0.11-1~deb12u2 i386 Secure Sockets Layer toolkit - development files
The fix is to explicitely check for the main architecture and, in case
for noarch (or rather all-arch in debian terms) packages, check for
special :all architecture as well.
The default on Ubuntu 24.04 and newer is now -D_FORTIFY_SOURCE=3 which clashes with our definition. We shouldnt be setting it for Ubuntus anyway since _FORTIFY_SOURCE=2 for older distros is already handled by the defaults in their gcc builds.
dpkg-query -W will show information about the package if any other package references it, even when the queried package is not installed. The fix is to query for an actual status of a needed build dependency.
Forgotten in bf3d5759e and 260494626.
This extends the approach used for debian-based packages in 3f805bc64e28 to rpm as well. Notable change for both deb and rpm packaging is to use CFLAGS as defined in the build/Makefile, and not pass them from the environment which might not be there (as is the case for rpm). While at it, stop passing CFLAGS in the install phase, as it should no longer invoke builds (see d54af163c46b). The rpm part was overlooked in 7a6405566c0, since testing was not done on the platforms where problem manifested itself, notably Amazon Linux 2023 and Fedora 38+.
We need to redefine CFLAGS to drop missing-prototypes as warning since third-party code such as wasmtime fails to build from source when building a debian package. This happens only for packages because we use DPKG_EXPORT_BUILDFLAGS=1 propagating build flags to the environment, so cargo build picks it up as well. Since we have no control over third-party code, the easiest solution is to disable this warning.