Skip to content

passagemath-bliss: Add version 10.8.13 - #4795

Open
luhenry wants to merge 5 commits into
mainfrom
passagemath-bliss
Open

luhenry wants to merge 5 commits into
mainfrom
passagemath-bliss

Conversation

@luhenry

@luhenry luhenry commented Nov 9, 2026 •

Copy link
Copy Markdown
Member

Cython wrapper around bliss, computing graph (iso/auto)morphisms. Upstream publishes no riscv64 wheel.

Mirrors build-passagemath-objects.yml's sdist-then-bdist shape, itself replaying upstream's own build/pkgs/sagemath_bliss/spkg-src.

Differs from upstream

  • Nothing beyond the riscv64 image: EPEL ships no riscv64 repo at all, so build/pkgs/bliss's own cmake source build (its spkg-configure.m4 fallback) is the only option, not a choice.

Testing

  • calls canonical_form() on a minimal duck-typed graph - sagemath-repl/-graphs (the real test extras) are unported

License: Wheel bundles libbliss (LGPL-3.0-or-later); upstream ships no licence text for it or for the package's own GPL-2.0-or-later code, so the build adds both.

Patches

  • 0001-add-the-package-s-own-licence-file.patch - To upstream [not yet submitted]. passagemath-bliss ships no LICENSE for its own declared licence; reproduces off riscv64.
  • 0002-add-the-vendored-bliss-library-s-licence-text.patch - Inappropriate [dependency fetched at build time, not in upstream's sdist]. Nothing else carries bliss's own licence text; reproduces off riscv64.

Split out of the passagemath/passagemath monorepo (a SageMath fork) at
pkgs/sagemath-bliss, tagged passagemath-10.8.13, same shape as
build-passagemath-objects.yml. Vendors bliss (LGPL-3.0-or-later), a
graph-automorphism C++ library pinned to scipopt/bliss commit eddc188
with an already-verified sha256 for its source zip (build/pkgs/bliss's
own checksums.ini pin).

The sdist is built by replaying build/pkgs/sagemath_bliss/spkg-src
(./bootstrap renders pyproject.toml.m4, then python -m build --sdist
--no-isolation --skip-dependency-check against the real upstream
checkout). CIBW_BEFORE_ALL_LINUX replays build/pkgs/bliss/spkg-install.in
(cmake -GNinja -DUSE_GMP=OFF): EPEL ships no riscv64 repo at all, so
bliss-devel is never an option and this always builds from the pinned
source, same as upstream's own spkg-configure.m4 fallback.

Neither passagemath-bliss nor passagemath-objects ships a LICENSE file
for its own GPL-2.0-or-later code (0001, same gap/fix as objects); bliss
itself is LGPL-3.0-or-later (COPYING + COPYING.LESSER, the standard FSF
pair) and is fetched at build time rather than vendored in the sdist, so
nothing carries its licence text either (0002, drops both as
LICENSE.bliss).

sagemath-repl/-graphs (the real test extras) are unported, so
CIBW_TEST_COMMAND calls canonical_form() on a minimal duck-typed graph
instead.
- sage_setup's recursive Cython-module discovery requires an
  all__sagemath_bliss.py marker in EVERY package directory it walks
  (sage_setup.find.find_python_sources / is_package_or_sage_namespace_package_dir),
  not just at the sage/ root; without one in sage/graphs/ the sdist's
  pyproject.toml never even got rendered in the manylinux leg's log, and
  the module would not have been found either way. Added it to the
  sparse-checkout (confirmed present at that exact path in the real
  published sdist on PyPI).
- ./bootstrap's own per-package pyproject.toml.m4 render runs through
  sage-package's xargs-parallelised, ~650-package sweep, which aborts a
  whole batch of 8 if any member fails; sage_conf's own bootstrap always
  fails on this sparse checkout (needs the top-level configure.ac), and
  landed in the same batch as sagemath_bliss, so pyproject.toml was never
  written and the wheel build failed with 'No module named sage_setup'.
  Render this one package's pyproject.toml.m4 directly instead of
  trusting that sweep.
- musllinux (Alpine) has no dnf/no /usr/lib64; dnf install failed
  outright with 'dnf: not found'. Detect apk vs dnf, use Alpine's
  package names, and don't hard-fail if ldconfig isn't present.
bliss's own CMakeLists has no BUILD_SHARED_LIBS, so cmake's default
(static) applies: the build log shows "Linking CXX static library
libbliss.a", and the Cython extension's final link line is
"... -lbliss -o .../bliss.abi3.so" with no separate libbliss.so ever
produced. auditwheel therefore has nothing to vendor on manylinux,
and the post-build check's
`libs = [...]; assert any("bliss" in n for n in libs)` fails because
passagemath_bliss.libs/ never exists there.

The same check happened to pass on musllinux, but not because bliss
was vendored: musllinux's auditwheel policy (unlike manylinux's)
doesn't allowlist libstdc++/libgcc_s, so it vendors the C++ runtime
into that same-named directory regardless (gotcha 409) - and
"passagemath_bliss.libs/libstdc++-*.so.6" matches `"bliss" in n`
purely because the directory name contains the package name. The
check was never actually exercising bliss's own vendoring at all.

Drop it; the extension-exists and licence-text assertions already
cover what the licence actually requires for a statically-linked
dependency.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant