DFSG NEW review for dune-istl version 2.11.0-2

Summary

• Licensing is DFSG-compliant and debian/copyright is accurate: No
• Packaging is of good quality: Yes
• Issues: 1 blocker, 1 important, 1 minor
• debian/watch: old format (version 4)
• debian/copyright: machine-readable
• Scan before the review: nothing found

Licensing

The tree is uniformly licensed GPL-2 (only) with the DUNE runtime exception, expressed by REUSE-style SPDX-License-Identifier: LicenseRef-GPL-2.0-only-with-DUNE-exception headers, and that licence is DFSG-free and compatible with the GPL-2 the packaging uses; no file is unlicensed and no third-party code is vendored. debian/copyright is DEP-5 and its two stanzas and short name are structurally correct, but it does not describe the licence accurately in two places: it omits two of the holders that upstream's LICENSE.md/COPYING name, and it quotes an older wording of the DUNE exception that exists nowhere in the source.

Packaging

Modern, minimal packaging of a header-only template library: debhelper compat 13 with dh and the CMake buildsystem, arch and indep builds separated (tests only in the arch build), an empty patch series, autopkgtests covering both the C++ headers and the Python JIT use, Vcs-* and upstream metadata, a correct three-way binary split, Rules-Requires-Root: no, and a changelog whose newest entry correctly targets experimental above unstable's 2.11.0-1. Standards-Version 4.7.0 is current against Policy 4.7.4.1. The build and test dependencies named are all satisfiable from the archive (libdune-common-dev 2.11.0-4 and python3-dune-common 2.11.0-4 are present).

Issues

1. [blocker] [licensing] debian/copyright omits the holders Lisa Julia Nebel and Vaishnavi Sanchi named in LICENSE.md and COPYING

• Files: debian/copyright (Files: * Copyright list, lines 6-66); LICENSE.md:41,54; COPYING:41,54
• Basis: checked, in the package or with a reference tool
• Evidence: Upstream's holder list has 2023--2024 Lisa Julia Nebel and 2023 Vaishnavi Sanchi; the Files: * Copyright list in debian/copyright has neither name (grep for Nebel and Sanchi matches only LICENSE.md and COPYING). The per-file notices are SPDX-FileCopyrightText: Copyright © DUNE Project contributors, see file LICENSE.md in module root, so LICENSE.md is the authoritative list of holders for the whole tree.
• Problem: Every file in the source points at LICENSE.md for its holders; a machine-readable copyright that leaves two of them out does not describe the copyright of those files, which is the thing the DFSG and Policy 12.5 require it to do.
• Fix: Add 2023--2024 Lisa Julia Nebel and 2023 Vaishnavi Sanchi to the Files: * Copyright list (alphabetically, after Maikel Nadolski / before Uli Sack).

2. [important] [licensing] debian/copyright quotes an older, different wording of the DUNE exception than the one the source is licensed under

• Files: debian/copyright:85-91; LICENSE.md:74-81; LICENSES/LicenseRef-GPL-2.0-only-with-DUNE-exception.txt:9-16
• Basis: checked, in the package or with a reference tool
• Evidence: debian/copyright says The exact wording of the exception reads as follows: then As a special exception, you may use the DUNE library without restriction. Upstream's text in both LICENSE.md and LICENSES/LicenseRef-GPL-2.0-only-with-DUNE-exception.txt reads As a special exception, you may use the DUNE source files as part of a software library or application without restriction. A grep for you may use the DUNE matches upstream only in those two files, with the longer grant.
• Problem: The copyright file presents as the exact licence text wording that the upstream release no longer uses; the quoted grant is broader than the one actually given (use the DUNE library versus use the DUNE source files as part of a software library or application), so the file misstates the terms of the licence it is meant to describe.
• Fix: Replace the quoted exception paragraph with the current text from LICENSE.md verbatim.

3. [minor] [packaging] debian/watch is in the old version 4 format

• Files: debian/watch
• Basis: found by the review tooling's own checks
• Evidence: version=4
• Problem: Version 5 is the current format of debian/watch.
• Fix: Convert it to version 5; a mechanical conversion is under Proposed changes.

Verified

• Prescan holder report: the DUNE Project contributors, see file LICENSE.md in module root notice is not a separate holder but a pointer to LICENSE.md's holder list; all ~199 files carrying it (CHANGELOG.md:2, CMakeLists.txt:1, README.md:2, cmake/modules/FindSuperLU.cmake, dune/istl/bcrsmatrix.hh, dune/istl/paamg/amg.hh, dune/python/test/bcrsmatrix.py, ...) are covered by the two reported gaps only, i.e. debian/copyright reproduces that list except for Nebel and Sanchi.
• Licence uniformity: grep for SPDX-License-Identifier, GNU Lesser, Apache License, Mozilla Public, public domain, All rights reserved, Redistribution and use, Permission is hereby granted over the whole tree finds only LicenseRef-GPL-2.0-only-with-DUNE-exception; grep for Copyright (C) <year> style individual notices over dune/, python/, cmake/, doc/ and src/ finds none, so there is no file under another licence and no second copyright entity hiding in individual headers.
• LICENSE.md, COPYING and LICENSES/LicenseRef-GPL-2.0-only-with-DUNE-exception.txt are the same GPL-2 text with the DUNE linking exception; GPL-2 is in /usr/share/common-licenses, which the copyright file cites correctly.
• No vendored third-party code: dune/istl/cholmod.hh, superlu.hh, superlufunctions.hh, spqr.hh and eigenvalue/arpackpp.hh are DUNE wrappers whose #include <cholmod.h> / #include <supermatrix.h> sit behind #if HAVE_SUITESPARSE_CHOLMOD / #if HAVE_SUPERLU; SuiteSparse, SuperLU and ARPACK++ are external Build-Depends, not copied in.
• doc/blockstructure.eps is a figure for the manual (doc/istl.tex), has its own REUSE sidecar doc/blockstructure.eps.license with the same copyright/licence lines, and is original artwork, not a built file; the documentation package is built from doc/istl.tex and the doxygen input in this tree.
• doc/istl.bib is a BibTeX bibliography (latin-1, hence not valid UTF-8) with a @Comment SPDX-... header; bibliographic data under the project licence, not a licence problem.
• dune/istl/paamg/test/gr_30_30.mm is a 900x900 MatrixMarket test matrix carrying the project's SPDX header; test data for the AMG tests, not a built artefact.
• dune/istl/test/solverfactorytest.cc.in is a configure_file template with the real test source present, not generated code without input.
• dune/istl/solvers.hh:121 and :417 credit algorithms to the SUMO library and Ronald Kriemanns BiCG-STAB implementation from Sumo in comments; these are provenance notes, not separate copyright notices, and the tree's single project-wide holder list governs.
• Packaging files read in full: control, rules, changelog (all 414 lines), source/format (3.0 quilt), clean, not-installed, both .install files, gbp.conf, salsa-ci.yml, upstream/metadata, tests/control, tests/basic, tests/python-jit, empty patches/series.
• The orig tarball's file list matches the unpacked tree (no files silently dropped, so no Files-Excluded is needed); the .dsc's Build-Depends and version agree with debian/control and debian/changelog.
• debian/tests/control uses the specification's Tests: field with Depends: and Restrictions:; the python-jit test's compiler/cmake/make come in through python3-dune-common's Depends, and python3-venv is listed explicitly.
• debhelper compat 13 with dh; override_dh_auto_test-arch/-indep are valid dh suffixed overrides, and the empty indep override is right because the indep build only produces documentation.
• libdune-istl-dev is Multi-Arch: foreign; I did not treat this as a fault, since Debian's other header-only -dev packages (e.g. libboost-dev) are foreign too despite depending on Multi-Arch: same dev packages.
• uscan found the packaged version as the newest upstream release (upstream 2.11.0, packaged 2.11.0).
• Every pointer of debian/copyright to /usr/share/common-licenses names a file that is there (GPL-2).

Not confirmed

• debian/rules includes /usr/share/dune/dune-debian.mk and dune-debian-python.mk, which come from dune-common and are not installed on this reviewing system, so I could not check how ${dune:doc:Built-Using} is produced, what DUNE_DEBIAN_AUTO_TEST runs, or how the Python module reaches python3-dune-istl (there is no debian/python3-dune-istl.install). A build would show whether dh_missing leaves the cmake-installed python module unassigned.
• The installed generated header dune-istl-config.hh encodes build-time SUPERLU_INT_TYPE (config.h.cmake, FindSuperLU.cmake); if Debian's SuperLU uses a different int_t on some architecture, that file differs per architecture and libdune-istl-dev's Multi-Arch: foreign would be wrong. I could not check SuperLU's int_t per architecture.