rubberband_4.0.0-1

rubberband: update from 3.3.0 to 4.0.0

quill_7.4.0-1

rubberband: update from 3.3.0 to 4.0.0

zlib-ng_2.2.2-1

zlib-ng: add

Based on zlib.wrap and zlib-ng's CMake build.

The wrap omits these upstream features:

- Support for building without optimizations (WITH_OPTIM=OFF), with
  -march=native (WITH_NATIVE_INSTRUCTIONS=ON), without new strategies,
  without runtime CPU detection, or with reduced memory requirements
- Support for building as C99
- Configurable API function name prefix
- Forcible override of optimization levels greater than 2, enablement of
  -fno-semantic-interposition, and use of software floating point on
  32-bit ARM.  It's not the build system's job to override the user's
  settings.  We do forcibly disable LTO to prevent it potentially merging
  blocks built for different CPU subarches.  (GCC, at least, won't do that
  in any case.)
- Defining HAVE_SYMVER (optional, and currently a no-op)
- Defining ZLIB_DEBUG in debug builds.  Wrap users probably don't want
  this.
- Naming the static build "zlibstatic" on Windows
- Maintainer warnings
- Sanitizers, fuzzers, benchmarks, coverage, and most tests

Also, the exact build logic differs from upstream in a number of small
details.

The wrap always uses the dependency name "zlib-ng", even when building in
zlib-compat mode.  Meson will not allow zlib and zlib-ng to share the
dependency name "zlib" within WrapDB.  Parent projects can invoke
meson.override_dependency('zlib', ...) if desired.

wayland-protocols_1.38-1

wayland-protocols: fallback to wayland wrap for wayland-scanner

sdl2_image_2.6.3-3

zlib-ng: add

Based on zlib.wrap and zlib-ng's CMake build.

The wrap omits these upstream features:

- Support for building without optimizations (WITH_OPTIM=OFF), with
  -march=native (WITH_NATIVE_INSTRUCTIONS=ON), without new strategies,
  without runtime CPU detection, or with reduced memory requirements
- Support for building as C99
- Configurable API function name prefix
- Forcible override of optimization levels greater than 2, enablement of
  -fno-semantic-interposition, and use of software floating point on
  32-bit ARM.  It's not the build system's job to override the user's
  settings.  We do forcibly disable LTO to prevent it potentially merging
  blocks built for different CPU subarches.  (GCC, at least, won't do that
  in any case.)
- Defining HAVE_SYMVER (optional, and currently a no-op)
- Defining ZLIB_DEBUG in debug builds.  Wrap users probably don't want
  this.
- Naming the static build "zlibstatic" on Windows
- Maintainer warnings
- Sanitizers, fuzzers, benchmarks, coverage, and most tests

Also, the exact build logic differs from upstream in a number of small
details.

The wrap always uses the dependency name "zlib-ng", even when building in
zlib-compat mode.  Meson will not allow zlib and zlib-ng to share the
dependency name "zlib" within WrapDB.  Parent projects can invoke
meson.override_dependency('zlib', ...) if desired.

nanobind_2.2.0-2

nanobind: compile nanobind lib with -DNB_FREE_THREADED with nogil pyt…

cpr_1.11.0-1

cpr: update to 1.11.0

sqlite3_3.47.0-1

sqlite3: update to 3.47.0

glib_2.82.2-1

glib: update from 2.82.1 to 2.82.2

cpp-httplib_0.18.1-1

cpp-httplib: update from 0.18.0 to 0.18.1