DFSG NEW review for golang-github-moby-moby-api version 1.56.0-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
• debian/copyright: machine-readable
• Scan before the review: nothing found

Licensing

debian/copyright is DEP-5 (exact 1.0 Format URL) with three Files stanzas (*, templates/*, debian/*) and one stand-alone Apache-2.0 paragraph pointing at /usr/share/common-licenses/Apache-2.0. Everything in the tree is Apache-2.0: the only licence text is the module's own root LICENSE (plain Apache-2.0, appendix left unfilled, no holder named in it), no other file carries a copyright or licence notice, and the three templates/*.gotmpl are Moby's modified copies of go-swagger v0.33.1 templates, which the later stanza correctly attributes to go-swagger maintainers as well as Docker, Inc. The holder of the rest, Docker, Inc., appears in no file of the module itself, but the copyright Comment states exactly where it comes from (the repository's top-level LICENSE/NOTICE, outside the exported api/ subdirectory) and why, which is the one judgement call and is documented. The GPL strings licensecheck reports are container-label sample data, not licence terms. No non-free terms, no file without a licence, no missing licence text, and the generated go-swagger types ship their generator input and templates. The licensing is DFSG-compliant and the copyright file describes the tree accurately.

Packaging

Good quality: debhelper compat 14 with dh-go (the package that now provides the golang addon and buildsystem), one Architecture: all / Multi-Arch: foreign dev package, correct Go layout and XS-Go-Import-Path, every runtime dependency present in the archive, pgregory.net/rapid correctly kept to Build-Depends as a test-only import, Standards-Version: 4.7.4 (current Policy 4.7.4.1), a first-upload changelog against unstable, no patches, and the unusual choices (dh-go rather than dh-golang, dpkg-build-api (= 1), the two lintian overrides, the orig-tarball repacking) each justified in comments or README.source. The one thing a sponsor would ask to be fixed is the build directory in debian/rules, which is not the default that the declared autopkgtest-pkg-go test uses (see the issue); nothing else rose above a nit.

Issues

1. [important] [packaging] debian/rules passes --builddirectory=debian/_build, which the declared autopkgtest (dh_golang_autopkgtest) does not use

• Files: debian/rules:4; /usr/bin/dh_golang_autopkgtest (dh-go 1.69)

• Basis: inferred from what was read, not seen directly

• Evidence:

  debian/rules: dh $@ --builddirectory=debian/_build --buildsystem=golang --with=golang. dh-go's autopkgtest runner, which is what Testsuite: autopkgtest-pkg-go runs, replaces the configure step of the package under test with:

  APT_BDIR := $(shell env --unset=DH_VERBOSE perl -w \
  	-MDebian::Debhelper::Dh_Buildsystems \
  	-e 'buildsystems_init(); print load_buildsystem("golang")->get_builddir()')
  
  override_dh_auto_configure:
  	mkdir -p "${APT_BDIR}"
  	find "${APT_BDIR}" -type l -exec rm "{}" \;
  	cp -a /usr/share/gocode/src "${APT_BDIR}"
  

  That perl sees no command-line options, so it returns the buildsystem's default build directory, _build (Buildsystem::golang DEFAULT_BUILD_DIRECTORY at compat 14, since the module's constructor calls prefer_out_of_source_building / _set_builddir with no builddir). /usr/bin/dh deletes DH_INTERNAL_OPTIONS before it runs an override target (# Don't pass DH_ environment variables, since this is a fresh invocation of debian/rules and any sub-dh commands. / delete($ENV{DH_INTERNAL_OPTIONS});), so the override cannot see --builddirectory=debian/_build either. dh's own buildsystem, however, gets builddir debian/_build from the command line, sets GOPATH to it (golang.pm _set_gopath), and runs go list / go install from it (golang.pm build/get_targets).

• Problem: The installed Go sources are copied into _build, while the rebuild looks in debian/_build: go list finds no packages, and dh_auto_build then does chdir("debian/_build"), which its overridden configure step never created, so the run fails (Dh_Lib print_and_doit: chdir($dir) or error(...)). The package therefore declares a test that cannot pass, which keeps it out of testing; the archive build itself is unaffected, and only a non-default build directory triggers this.

• Fix: Drop --builddirectory=debian/_build from debian/rules (at compat 14 the golang buildsystem's default is already _build, which is what dh_golang_autopkgtest computes), or state --builddirectory=_build; alternatively ship a real debian/tests/control instead of relying on autopkgtest-pkg-go.

Verified

• Tree inventory: 206 files, all text (.go, .md, .yaml, .gotmpl, .sh, .toml, plus root Makefile/Dockerfile/LICENSE); no archives, compiled objects, minified JS/CSS, fonts or images, and the only licence text in the tree is the root LICENSE (202 lines, unmodified Apache-2.0, appendix still Copyright [yyyy] [name of copyright owner]).
• The pre-scan listed nothing to account for: dfsg-author-check scanned 206 files and found every holder named in debian/copyright (findings: [], prescan.md's author check).
• The GPL that licensecheck reports is sample data, not a licence: com.example.license: "GPL" (container Labels examples) at swagger.yaml:5838 and :8482 and in 39 files under docs/ (e.g. docs/v1.18.md:64), exactly as the copyright Comment says.
• A case-insensitive whole-tree grep for Copyright, (C), ©, SPDX-License-Identifier, Licensed under, Permission is hereby granted, GNU General Public, GNU Lesser, Apache License, Mozilla Public, public domain, All rights reserved, and a second for licence/@license/permission to/copies of the, match only LICENSE, debian/copyright and templates/server/operation.gotmpl:11 ({{ if .Copyright -}}); i.e. no file carries a notice of its own, and no separate vendored license needs its own stanza.
• Each of the three templates names its origin (The orignal template can be found at https://github.com/go-swagger/go-swagger/blob/v0.33.1/generator/templates/...), matching the templates/* stanza that credits go-swagger maintainers; the stanza's pattern reaches templates/server/operation.gotmpl too.
• The 45 files starting // Code generated by go-swagger; DO NOT EDIT. (all under types/) are the module's own API types; their inputs are in the tree (swagger.yaml, swagger-gen.yaml, templates/, and the generator call in scripts/generate-swagger-api.sh), so the preferred form for modification is present.
• Dependencies exist and match the imports: apt-cache shows golang-github-docker-go-units-dev 0.5.0-1, golang-github-moby-docker-image-spec-dev 1.3.1-2, golang-github-opencontainers-go-digest-dev 1.0.0-2, golang-github-opencontainers-image-spec-dev 1.1.1-3, golang-pgregory-rapid-dev and dh-go 1.69. The first four are imported by non-test code (e.g. types/container/hostconfig.go github.com/docker/go-units), so Depends is complete.
• pgregory.net/rapid is imported only by types/plugin/capability_test.go, and dh-golang's test step runs go test, so Build-Depends is the right place for it and its absence from Depends is not a fault.
• Build-Depends: dh-go with --with=golang is correct: apt-cache shows dh-go 1.69 has Conflicts: dh-golang and no Provides: dh-sequence-golang, and dh-go ships the golang sequence addon (/usr/share/perl5/Debian/Debhelper/Sequence/golang.pm) and buildsystem; the source lintian override for missing-build-dependency-for-dh-addon golang is justified.
• dpkg-build-api (= 1) is the documented way to declare build-API level 1 (dpkg-build-api(7), dpkg >= 1.22.0); level 1 requires all debian/rules targets to exist, which the %: rule provides.
• Standards-Version: 4.7.4 against the reviewing system's Policy 4.7.4.1 — current, not an issue.
• At compat 14 dh_missing's default source directory is debian/tmp, which this package does not create, so dh_missing exits 0 (read from /usr/bin/dh_missing); upstream files that dh-golang does not install (docs/, swagger.yaml, README.md) are therefore not a problem.
• Testsuite: autopkgtest-pkg-go is a known testsuite (lintian data/testsuite/known-testsuites) and autodep8's Go generator detects golang-any in Build-Depends (/usr/share/autodep8/support/go/detect), so a debian/tests directory is not needed and the generated test's Depends: @, @builddeps@ carries the test-only rapid.
• changelog: 1.56.0-1, distribution unstable, urgency medium, Closes: #1149066, date Sat 26 Sep 2026 (a Saturday), matching the upstream module tag api/v1.56.0 (major 1, so no /vN module-path suffix is needed).
• No debian/patches and an empty quilt series; the tree is upstream's api/ subtree at tag api/v1.56.0 as described in debian/README.source, and debian/get-orig-source.sh shows the repacking. debian/copyright has no Files-Excluded and needs none, since only api/ is shipped.
• I read all of debian/ in full, every root-level file, the templates, and the complete directory listings of types/ (including build/), docs/, pkg/, scripts/, validate/, releases/; the 200-name limit on glob was reached once and worked around by listing types/ separately. I did not read every one of the 206 files: the large docs/*.yaml, docs/CHANGELOG.md and swagger.yaml were searched and sampled, not read end to end.
• uscan found upstream releases with debian/watch; a newer upstream version is available (upstream 1.56.1, packaged 1.56.0), which is not a fault of the package.
• Every pointer of debian/copyright to /usr/share/common-licenses names a file that is there (Apache-2.0).

Not confirmed

• No build and no autopkgtest could be run here, so build- and test-time behaviour was not observed directly; the failure predicted in the issue about --builddirectory=debian/_build is a reading of dh-go's and dh's code, and an autopkgtest run (or autopkgtest --test-name=dh-golang-autopkgtest . on the source package) would show whether the rebuild indeed fails.
• File permissions are not visible to the reading tools used here, so I could not check that debian/get-orig-source.sh is executable.
• Why the model asked for what a review has no use for. During this review it asked once for something outside the package and the reviewing system (another file of the sandbox, or a URL), or was given part of the review tooling's own configuration, and that was refused or withheld. A model does this when something it has read tells it to, so look in the package for text addressed to a reviewing program, and treat this report with suspicion. Refused: read: "/review/../nonexistent" is not a file of the package or of the reviewing system.

Proposed changes

None.