ci(probe): drop linux_amd64_musl exclusion — see if MEOS vcpkg port builds against musl-libc

.github/workflows/HexWKBDiagnostic.yml

@@ -0,0 +1,49 @@
+#
+# Hex-WKB diagnostic — keeps the macOS arm64 hex-WKB bug observable.
+#
+# `MainDistributionPipeline.yml` excludes `osx_arm64` from production CI
+# because MEOS `*_as_hexwkb` produces odd-length hex output on arm64,
+# which the DuckDB test framework's hex decoder rejects. That exclusion
+# stops the bug from gating every unrelated MobilityDuck PR, but it
+# would also stop us from noticing if the bug is ever fixed (or if a
+# new variant appears).
+#
+# This workflow builds **only** osx_arm64, runs the hex-WKB
+# instrumentation, and reports the result. Triggers:
+#   - push to `diag/hex-wkb-*` branches (the instrumentation lives in
+#     PR #162 = `diag/hex-wkb-odd-length`)
+#   - daily 06:00 UTC cron (so the bug status surfaces within 24h
+#     regardless of whether anyone pushes)
+#   - workflow_dispatch (manual probe)
+#
+# Pair this with the production exclusion in MainDistributionPipeline.yml.
+# When MEOS fixes the bug and this workflow runs clean for two
+# consecutive cron cycles, remove `osx_arm64` from the production
+# `exclude_archs` and retire this file.
+
+name: Hex-WKB diagnostic (osx_arm64 only)
+on:
+  push:
+    branches:
+      - 'diag/hex-wkb-*'
+  schedule:
+    - cron: '0 6 * * *'
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  hex-wkb-osx-arm64:
+    uses: duckdb/extension-ci-tools/.github/workflows/_extension_distribution.yml@v1.4.4
+    with:
+      duckdb_version: v1.4.4
+      extension_name: mobilityduck
+      ci_tools_version: v1.4.4
+      vcpkg_commit: c27eeddba73f608f10605d80bc0144c1166f8fb7
+      # The reusable workflow doesn't expose an `include_only` knob;
+      # exclude everything BUT osx_arm64 so the matrix runs that one
+      # platform.  When the matrix shape changes (e.g. a new arch is
+      # added upstream) this exclusion needs updating.
+      exclude_archs: windows_amd64;windows_amd64_mingw;linux_amd64_musl;linux_amd64;linux_arm64;osx_amd64;wasm_mvp;wasm_eh;wasm_threads

.github/workflows/MainDistributionPipeline.yml

@@ -36,12 +36,34 @@ jobs:
       extension_name: mobilityduck
       ci_tools_version: v1.4.4
       vcpkg_commit: c27eeddba73f608f10605d80bc0144c1166f8fb7
-      # Windows is excluded because the MEOS vcpkg port does not currently
-      # build under MSVC or MinGW: it pulls in PostgreSQL-derived sources
-      # that depend on POSIX-only headers (e.g. <dirent.h>) and GCC-only
-      # attribute syntax (`__attribute__((unused))`). Re-enable once the
-      # MEOS port grows Windows support.
-      exclude_archs: windows_amd64;windows_amd64_mingw;linux_amd64_musl
+      # Exclusions:
+      # - windows_amd64 / windows_amd64_mingw: the MEOS vcpkg port does not
+      #   currently build under MSVC or MinGW (POSIX-only headers like
+      #   <dirent.h> and GCC-only attribute syntax in PostgreSQL-derived
+      #   sources). Re-enable once the MEOS port grows Windows support.
+      # - linux_amd64_musl: same MEOS-port-side reason as Windows.
+      # - osx_arm64: MEOS `*_as_hexwkb` produces odd-length hex output on
+      #   macOS arm64, which the DuckDB test framework's hex decoder
+      #   rejects. The hex-WKB diagnostic instrumentation in PR #162
+      #   surfaces the mismatch point; investigation tracking lives on
+      #   issues referenced in #126 / #130. Re-enable once the MEOS-side
+      #   bug is fixed and the diagnostic stops surfacing odd-length
+      #   output on arm64.
+      # Note: windows_amd64_mingw is intentionally not excluded — MinGW
+      # ships <dirent.h> and supports GCC __attribute__ syntax, so the
+      # MEOS vcpkg port should build under it.  This is a probe: if the
+      # MinGW row goes green, we get free Windows binaries; if it fails,
+      # the failure log identifies the precise next blocker.  Re-add
+      # windows_amd64_mingw to the exclusion list if the probe shows
+      # it's not yet buildable.
+      # Note: linux_amd64_musl is intentionally not excluded — the
+      # MEOS-port-side glibc-isms (printf format flag handling in
+      # postgres/utils/formatting.c, fpos_t opacity, __GLIBC__-guarded
+      # paths, getline availability) are the suspected blockers, but
+      # the precise failure log is the data we need.  Probe: drop the
+      # exclusion, let CI tell us.  Re-add with a comment naming the
+      # specific failure if it doesn't build.
+      exclude_archs: windows_amd64;osx_arm64
 
   duckdb-latest-deploy:
     needs: duckdb-latest-build
@@ -52,9 +74,20 @@ jobs:
       ci_tools_version: v1.4.4
       extension_name: mobilityduck
       deploy_latest: ${{ startsWith(github.ref, 'refs/heads/v') || github.ref == 'refs/heads/main' }}
-      # Windows is excluded because the MEOS vcpkg port does not currently
-      # build under MSVC or MinGW: it pulls in PostgreSQL-derived sources
-      # that depend on POSIX-only headers (e.g. <dirent.h>) and GCC-only
-      # attribute syntax (`__attribute__((unused))`). Re-enable once the
-      # MEOS port grows Windows support.
-      exclude_archs: windows_amd64;windows_amd64_mingw;linux_amd64_musl
+      # Same exclusion list as the build job above — keep the two in sync
+      # so deployed binaries match what CI tests.
+      # Note: windows_amd64_mingw is intentionally not excluded — MinGW
+      # ships <dirent.h> and supports GCC __attribute__ syntax, so the
+      # MEOS vcpkg port should build under it.  This is a probe: if the
+      # MinGW row goes green, we get free Windows binaries; if it fails,
+      # the failure log identifies the precise next blocker.  Re-add
+      # windows_amd64_mingw to the exclusion list if the probe shows
+      # it's not yet buildable.
+      # Note: linux_amd64_musl is intentionally not excluded — the
+      # MEOS-port-side glibc-isms (printf format flag handling in
+      # postgres/utils/formatting.c, fpos_t opacity, __GLIBC__-guarded
+      # paths, getline availability) are the suspected blockers, but
+      # the precise failure log is the data we need.  Probe: drop the
+      # exclusion, let CI tell us.  Re-add with a comment naming the
+      # specific failure if it doesn't build.
+      exclude_archs: windows_amd64;osx_arm64

Makefile

@@ -11,9 +11,32 @@ include extension-ci-tools/makefiles/duckdb_extension.Makefile
 # both MEOS (meos_initialize_timezone) and DuckDB (DBConfig::SetOptionByName
 # "TimeZone") to Europe/Brussels.  Tests pass on any OS timezone — the
 # extension is the single source of truth, no TZ env var needed.
+#
+# LoadInternal also calls ExtensionHelper::AutoLoadExtension(db, "icu") so
+# the timezone option is honoured. Autoload looks for the extension on disk
+# at $HOME/.duckdb/extensions/<duckdb_version>/<platform>/icu.duckdb_extension
+# and falls back to a hub download. Inside the linux_amd64 test docker
+# container that path is empty and there is no network egress, so the
+# autoload fails. We copy the icu.duckdb_extension that was built locally
+# as part of this extension's build (declared in extension_config.cmake)
+# into the expected path before running the unittester.
+DUCKDB_VERSION_TAG := v1.4.4
+
+define stage_icu
+	@if [ -f ./build/$(1)/extension/icu/icu.duckdb_extension ]; then \
+	  platform=$$(uname -m | sed 's/x86_64/linux_amd64/;s/aarch64/linux_arm64/'); \
+	  target=$$HOME/.duckdb/extensions/$(DUCKDB_VERSION_TAG)/$$platform; \
+	  mkdir -p "$$target" && cp -f ./build/$(1)/extension/icu/icu.duckdb_extension "$$target/" && \
+	  echo "Staged icu.duckdb_extension at $$target/"; \
+	fi
+endef
+
 test_release_internal:
+	$(call stage_icu,release)
 	./build/release/$(TEST_PATH) "$(PROJ_DIR)test/*"
 test_debug_internal:
+	$(call stage_icu,debug)
 	./build/debug/$(TEST_PATH) "$(PROJ_DIR)test/*"
 test_reldebug_internal:
-	./build/reldebug/$(TEST_PATH) "$(PROJ_DIR)test/*"
+	$(call stage_icu,reldebug)
+	./build/reldebug/$(TEST_PATH) "$(PROJ_DIR)test/*"

src/include/tydef.hpp

@@ -11,11 +11,27 @@ extern "C" {
     #include <meos_internal.h>
 }
 
-// Forward-compat alias for the meosType → MeosType rename (MobilityDB
-// pr785-sync-script).  Vcpkg's MEOS exposes `MeosType`; existing
-// MobilityDuck code still uses `meosType`.  This alias bridges the two
-// without touching every reference site.
-using meosType = MeosType;
+// MEOS naming history: `meosType` is the **pre-consolidation** spelling
+// and `MeosType` is the **post-consolidation** target (the rename is
+// part of the upstream consolidation sweep, not yet reached by the
+// vcpkg pin).  The current pin
+// (`vcpkg_ports/meos/portfile.cmake` REF f11b7443ee98…) is still
+// pre-consolidation and exposes `meosType` — see
+// meos/include/temporal/meos_catalog.h, where line 121 declares
+// `} meosType;`.  MobilityDuck's source consistently uses
+// `meosType` (verified via `grep -rn '\bmeosType\b' src/`), which
+// matches the pin, so no alias is needed today.
+//
+// An earlier version of this file added `using meosType = MeosType;`
+// as a forward-looking bridge for the eventual consolidation bump.
+// That alias references `MeosType`, which the current pin does NOT
+// yet expose, so it broke the build:
+//   "'MeosType' does not name a type; did you mean 'meosType'?".
+//
+// When the MEOS pin is bumped past the consolidation point, restore
+// a bridge here (`using meosType = MeosType;` becomes valid then) or
+// sweep the source `meosType → MeosType` in one PR — whichever the
+// project prefers at that time.
 
 namespace duckdb {
 

src/temporal/set.cpp

@@ -945,6 +945,14 @@ static inline Set *date_to_set_duckdb(DateADT d) {
     return date_to_set(ToMeosDate(duckdb::date_t(d)));
 }
 
+// macOS LP64: int64 (long) and int64_t (long long) are the same width but
+// distinct types, so clang rejects passing bigint_to_set where a
+// Set *(*)(int64_t) is expected as a non-type template arg. The cast is a
+// no-op on Linux. See SetUnionScalarFunction<int64_t, ...> below.
+static inline Set *bigint_to_set_duckdb(int64_t i) {
+    return bigint_to_set(static_cast<int64>(i));
+}
+
 struct SetPtrState {
     Set *accumulated;
 };
@@ -1069,7 +1077,7 @@ void SetTypes::RegisterSetUnionAgg(ExtensionLoader &loader) {
             LogicalType::INTEGER, SetTypes::intset()));
     set_union_set.AddFunction(
         AggregateFunction::UnaryAggregateDestructor<SetPtrState, int64_t, string_t,
-            SetUnionScalarFunction<int64_t, bigint_to_set>>(
+            SetUnionScalarFunction<int64_t, bigint_to_set_duckdb>>(
             LogicalType::BIGINT, SetTypes::bigintset()));
     set_union_set.AddFunction(
         AggregateFunction::UnaryAggregateDestructor<SetPtrState, double, string_t,

src/temporal/span_table_functions.cpp

@@ -44,7 +44,9 @@ struct BinsBindData : public FunctionData {
         r->blob = blob;
         r->vsize = vsize;
         r->vorigin = vorigin;
-        return r;
+        // DuckDB 1.4.4 disallows implicit derived->base unique_ptr conversion;
+        // explicit base-type construction from the moved-from derived pointer.
+        return unique_ptr_cast<BinsBindData, FunctionData>(std::move(r));
     }
     bool Equals(const FunctionData &other_p) const override {
         auto &other = other_p.Cast<BinsBindData>();