DFSG NEW review for libhandlegraph version 2024-11-22-1

Summary

• Licensing is DFSG-compliant and debian/copyright is accurate: Yes
• Packaging is of good quality: Yes
• Issues: 0 blocker, 1 important, 0 minor
• debian/watch: version 5, refused by the checks made before uscan is run
• debian/copyright: machine-readable
• Scan before the review: nothing found

Licensing

The entire tree is MIT-licensed: upstream LICENSE (Copyright (c) 2014 Erik Garrison) covers the project, and no source file carries its own copyright/licence header, so the whole tree falls under the single project-wide MIT licence. debian/copyright is in DEP-5 (Format 1.0) and accurately covers it: Files: * / MIT / 2014 Erik Garrison, Files: debian/* / MIT / 2026 Andreas Tille, with the full MIT text included (MIT is not in /usr/share/common-licenses). The prescan's author check scanned all 77 files and found every copyright holder already named in debian/copyright. No non-free terms, no built or unmodifiable files, no vendored third-party code, so the licensing is DFSG-compliant.

Packaging

Clean, conventional debhelper compat-14 packaging: dh $@ --buildsystem=cmake with DEB_BUILD_MAINT_OPTIONS=hardening=+all; debian/patches adds a proper SONAME (VERSION 1.0.0, SOVERSION 1) and moves CMake config files into the multiarch CMAKE_INSTALL_LIBDIR, without which the shared library could not be packaged as libhandlegraph1; libhandlegraph1 (shared lib) / libhandlegraph-dev (headers, static lib, .so symlink, CMake files) split matches the .install globs; both Multi-Arch: same with an in-line libhandlegraph1 (= ${binary:Version}) dev dependency, following established practice; autopkgtest smoke test exercising find_package + link + ldd is coherent; changelog version, source version and install files all agree; Standards-Version 4.7.4 against current Policy 4.7.4.1 is fine. No policy violations or sponsor-blocking problems found.

Issues

1. [important] [packaging] debian/watch was refused by the checks made before uscan is run

• Files: debian/watch
• Basis: found by the review tooling's own checks
• Evidence: - it contains a "transport::address" style git URL
• Problem: These checks refuse what is not plausibly a watch file, and the values known to make uscan do something other than look at an upstream site. uscan was not run, so the file is untested.
• Fix: Read debian/watch and correct it. If uscan is run on it by hand, do that with caution.

Verified

• debian/copyright is machine-readable (Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/): Files: * / Copyright: 2014 Erik Garrison / License: MIT; Files: debian/* / Copyright: 2026 Andreas Tille <tille@debian.org> / License: MIT; standalone License: MIT paragraph reproduces the full MIT text.
• upstream LICENSE: The MIT License (MIT), Copyright (c) 2014 Erik Garrison, matching the Files: * stanza holder and year.
• Prescan account: its only finding is the author check, which scanned all 77 files and reports every holder found is named in debian/copyright; nothing else in prescan.md.
• Full-tree licence grep (Copyright, (c), (C), ©, SPDX, Licensed under, GPL, Apache, MPL, public domain, All rights reserved) found licence text only in LICENSE and debian/copyright; no .cpp/.hpp carries a per-file header, so every file is governed by the project MIT licence and matched by Files: *.
• Tree (77 files) holds only C++14 sources, headers, CMake files, README, .gitignore and LICENSE; no minified/js/jar/class/so/pdf data, no fonts/images, no embedded third-party code; nothing to exclude via Files-Excluded.
• debian/rules (compat 14): dh $@ --buildsystem=cmake, override_dh_auto_configure passes -DCMAKE_INSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH), hardening=+all exported; consistent with the CMAKE_INSTALL_LIBDIR-relative ConfigPackageLocation introduced by the patch.
• Patch debian/patches/soname-and-cmake-path.patch is needed and correct: without the SONAME there is no versioned shared library to package, and without the CMake-dir change the config files would land in non-multiarch lib/cmake. DEP-3 headers present (Description, Author, Last-Update).
• Binary split consistent: libhandlegraph1.install (usr/lib/*/libhandlegraph.so.*) vs libhandlegraph-dev.install (usr/include/handlegraph, usr/lib/*/libhandlegraph.a, usr/lib/*/libhandlegraph.so, usr/lib/*/cmake/libhandlegraph); every cmake-installed artifact is claimed by a glob.
• libhandlegraph-dev Depends: libhandlegraph1 (= ${binary:Version}) on a Multi-Arch: same runtime lib without an :any qualifier matches established archive practice (e.g. libjson-c-dev, Multi-Arch: same, depends unqualified on libjson-c5 (= ...)); semantically right because the dev package's static library is architecture-specific.
• autopkgtest debian/tests/control (Tests: smoke, Depends: @, build-essential, cmake) and debian/tests/smoke are coherent: smoke builds with find_package(libhandlegraph REQUIRED) (found via the multiarch cmake dir), links libhandlegraph::handlegraph_shared, uses header-only as_integer(net_handle_t&) (inline in src/include/handlegraph/util.hpp) and operator== from types.cpp, then checks ldd for libhandlegraph.so.
• debian/changelog: libhandlegraph (2024-11-22-1) unstable, valid version (upstream 2024-11-22, revision 1), matches debian/watch's mangle target and the orig tarball name; Standards-Version: 4.7.4 is current (Policy 4.7.4.1 by the policy tool).
• Marriage of package name and SONAME: upstream version 1.0.0, SOVERSION 1 and binary package libhandlegraph1 agree.
• Build-Depends debhelper-compat (= 14), cmake resolve in the archive; only arch:any packages, so Build-Depends (not -Indep) is right; ${shlibs:Depends} on libhandlegraph1 is correct (harmlessly redundant at compat 14, which applies substvars itself).

Not confirmed

• Actual install layout (exact .so symlink chain and generated libhandlegraphTargets.cmake) and an actual build/autopkgtest run were not verified here (read-only review, no build allowed); no cause to suspect a failure was found in the packaging, so nothing is reported on that basis.

Proposed changes

None.