DFSG NEW review for ohr version 0.0.1

Summary

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

Licensing

The licence terms are DFSG-free and consistent. debian/copyright is DEP-5 (correct Format URL) with a single Files: * stanza naming both holders (Thomas Goirand, Infomaniak), GPL-2.0-or-later with the full terms and a pointer to /usr/share/common-licenses/GPL-2. Every one of the 71 files that carries a notice (all ohr/**.py, setup.py, bash-completion/ohr) has the same two holders and the same "version 2 or any later version" grant; the top-level LICENSE is the verbatim GPL-2; a grep for BSD/MIT/Apache/MPL/LGPL/CC/public-domain wording finds nothing else. The 19 scan-listed .bin files are upstream unit-test data and ohr-tui.png is a screenshot of the program itself, both covered by the same stanza. One provenance problem is reported as an issue: the source comments say several byte layouts and field offsets were reconstructed from a Ghidra decompilation of the proprietary vendor CLI, while README.md and the package Description assert a clean-room process and that the binary was not decompiled; debian/copyright does not mention that derivation.

Packaging

Packaging is conventional and in good shape: debhelper compat 13 with the dh sequencer, pybuild and python3, all runtime imports covered (cliff plus stdlib; ${python3:Depends} and ${misc:Depends} present), Architecture: all for a Python CLI, the manpage generated from the shipped docs/ohr.1.rst with python3-docutils, bash completion installed through ohr.install, an autopkgtest stanza that has a real test script (debian/tests/unittests) running the upstream unit suite, Standards-Version 4.7.4 against Policy 4.7.4.1, a sane single-entry 0.0.1/unstable changelog, correct Vcs-* fields and a complete Description. There are no patches, no maintainer scripts and no build-dep on anything absent from the archive (openstack-pkg-tools 158 satisfies the (>= 123~) requirement).

Issues

important licensing 1. README.md and the Description claim the vendor binary was not decompiled, while the source names Ghidra decompilation output as the basis of its layouts ◂

• Files: README.md:230-232; debian/control:41-43; ohr/mfi/codes.py:19-22; ohr/mfi/cfg_write.py:19-23; ohr/mfi/adapter.py:391-407; ohr/cli/commands.py:253-258
• Basis: checked, in the package or with a reference tool
• Evidence: README.md: "no code from the proprietary software was used and the binary was not decompiled: this tool is an original clean-room reimplementation based on observing the protocol"; debian/control: "established by clean-room reverse engineering of the documented behaviour of the hardware interface"; ohr/mfi/codes.py: "Sources (GPL-2.0, verbatim-derivable): ... the reference CLI 7.2508 decompilation where the driver stays silent"; ohr/mfi/cfg_write.py: "Byte layout reconstructed from the reference CLI's decompiled MfiData::fillWrConfigStructForSpan (ghidra-out fn_0074c2aa) and MfiData::CreateSvd (fn_0074bfa4)"; ohr/mfi/adapter.py: "decompiled RmDataMfi::importFrnCfg, ghidra-out/the reference CLI-pass3/fn_00752380.c"; ohr/cli/commands.py: "The field offsets are pinned by the MegaCLI 'Default Settings' renderer (ghidra-out/megacli/fn_004ed720.c ...)"
• Problem: debian/copyright licenses the whole tree as the GPL-2.0-or-later work of two authors, and both the README's legal-basis section and the binary Description tell Debian that no vendor binary was decompiled. The shipped source says the opposite in five places, naming decompiled vendor functions and their Ghidra output. A sponsor and the archive cannot assess the provenance of what is being distributed from a copyright file and Description that contradict the code, and if any vendor expression (rather than interface facts) was carried over, those files are not the authors' to license and cannot be GPL-2.0-or-later.
• Fix: Reconcile the statements: describe the decompilation actually performed (and the interoperability basis relied on) in README.md and the Description, or drop the comments if the layouts were in fact derived from captures only. If any vendor expression was reused, record it and its licensing status in debian/copyright (a separate Files stanza or a Comment) and resolve it with the rights holder before upload.

important packaging 2. uscan found no upstream version ◂

• Files: debian/watch
• Basis: found by the review tooling's own checks
• Problem: uscan ran without an error but found no upstream release with debian/watch.
• Fix: Correct debian/watch so that uscan --report finds the upstream releases.

minor packaging 3. 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 ◂

• All 19 files the scan lists under ohr/tests/unit/fixtures/ are raw MFI response buffers consumed as test data by the unit tests (e.g. the _fixture() helper at ohr/tests/unit/test_bbu.py:36-38, test_cfg_read.py:32, test_enclosure.py:26); they are protocol dumps taken on the authors' own controller, not built artifacts, and the tree contains no generator for them and needs none.
• ohr-tui.png is the curses-TUI screenshot embedded by README.md (![ohr TUI](ohr-tui.png)), rendered from ohr itself by its authors; it is not installed and is covered by the Files: * stanza.
• LICENSE is the verbatim 280-line GPL-2 text, consistent with the GPL-2.0-or-later stanza's reference to /usr/share/common-licenses/GPL-2.
• Every file carrying a copyright notice was checked: all files under ohr/, plus setup.py and bash-completion/ohr, carry the identical two-line header (Thomas Goirand; Infomaniak) with the GPL-2 "or any later version" grant; no other holder or licence was found by grepping the tree for BSD, MIT, ISC, zlib, Apache, MPL, LGPL, CC0/CC-BY, Artistic, public domain and All rights reserved.
• README.md, docs/ohr.1.rst, setup.cfg, test-requirements.txt and .stestr.conf carry no notice of their own; they are covered by Files: *, whose holders are the ones the rest of the tree names, and the prescan's holder check agrees that every holder found is named.
• debian/copyright Files: * covers debian/ itself and, being *, every file at any depth including dotfiles, so no file falls outside it.
• Build dependencies all exist in the archive: openstack-pkg-tools 158 (rules requires >= 123~), python3-cliff 4.16.0 (which pulls python3-autopage, python3-cmd2, python3-prettytable), python3-docutils, python3-stestr/fixtures/testtools, subunit; rst2man takes <source> <destination>, as used in rules.
• debian/ contents were all read (changelog, control, copyright, ohr.docs, ohr.install, ohr.manpages, rules, salsa-ci.yml, source/format, tests/control, tests/unittests): no patches, no maintainer scripts, no gbp.conf or upstream/metadata; single 0.0.1 initial-packaging changelog entry in unstable; Standards-Version 4.7.4 against the reviewing system's Policy 4.7.4.1; debian/tests/control names unittests and the script exists.
• Every pointer of debian/copyright to /usr/share/common-licenses names a file that is there (GPL-2).

Not confirmed ◂

• ohr/mfi/cfg_read.py:19-21 and ohr/mfi/bbu.py:19-21 say the payloads "mirror"/"follow" struct mfi_config_data from FreeBSD's BSD-licensed sys/dev/mfi/mfireg.h; if protectable text from that header were copied rather than the layout reimplemented, debian/copyright would need the LSI/FreeBSD BSD notice. The comments describe layouts, so nothing was confirmed.
• ohr/mfi/codes.py:19 calls its Linux driver source "GPL-2.0" while the file and debian/copyright are GPL-2.0-or-later; if literal code from a GPL-2.0-only megaraid_sas.h had been copied the "or later" grant would be wrong, but the content is numeric MFI enums and the kernel header is not readable here.
• The contents of openstack-pkg-tools' pkgos.make and pkgos-dh_auto_test (not installed on the reviewing system) could not be read, so how pbr obtains the version for a native tarball and exactly how the test wrapper runs stestr were not verified.