DFSG NEW Queue

DFSG, Licensing & New Packages Team

Review: golang-github-ibm-go-sdk-core 5.25.1-1

Package Information

Descriptioncore functionality from the IBM OpenAPI SDK Generator (Go library)

This project contains core functionality required by Go code generated by the IBM Cloud OpenAPI SDK Generator (openapi-sdkgen).

The go-sdk-core project supports the following types of authentication: - Basic Authentication - Bearer Token Authentication - Identity and Access Management (IAM) Authentication (grant type: apikey) - Identity and Access Management (IAM) Authentication (grant type: assume) - Container Authentication - VPC Instance Authentication - Cloud Pak for Data Authentication - Multi-Cloud Saas Platform (MCSP) Authentication - No Authentication (for testing)

MaintainerDebian Go Packaging Team <team+pkg-go@tracker.debian.org>
Changed ByDrew Parsons <dparsons@debian.org>
Sponsordparsons@debian.org
Distributionunstable
Architectureall
VCSgit: https://salsa.debian.org/go-team/packages/golang-github-ibm-go-sdk-core.git (browse)
Closes#1151238
Trackerhttps://tracker.debian.org/pkg/golang-github-ibm-go-sdk-core
Uploaded20 days ago

New Package Report

.changes◂
Sourcegolang-github-ibm-go-sdk-core
Version5.25.1-1
Changed-ByDrew Parsons <dparsons@debian.org>
Architecturesource all
Distributionunstable
DateSun, 18 Oct 2026 21:46:25 +0200
Changelog◂
golang-github-ibm-go-sdk-core (5.25.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1151238)
.dsc◂
Package-Listgolang-github-ibm-go-sdk-core-v5-dev deb golang optional arch=all
Sectiongolang
Priorityoptional
Componentmain
debian/copyright◂
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: https://github.com/IBM/go-sdk-core
Upstream-Name: go-sdk-core
Upstream-Contact: IBM Cloud Developers <devxsdk@us.ibm.com>

Files: *
Copyright: 2019 International Business Machines (IBM Corp.)
License: Apache-2.0

Files: debian/*
Copyright: 2026 Drew Parsons <dparsons@debian.org>
License: Apache-2.0
Comment: Debian packaging is licensed under the same terms as upstream

License: Apache-2.0
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at
 .
 https://www.apache.org/licenses/LICENSE-2.0
 .
 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
Comment:
 On Debian systems, the complete text of the Apache version 2.0 license
 can be found in "/usr/share/common-licenses/Apache-2.0".

DFSG Assistant LLM REVIEW 0 blocker, 2 important, 0 minor

This is an LLM based review using a Debian Inference based workflow. It was not written by a member of the DFSG team and has not been checked by one. It is not a decision on the package: it may be wrong, and it may have missed things.

Reviewed 19 days ago.

Report◂

DFSG NEW review for golang-github-ibm-go-sdk-core version 5.25.1-1

Summary

  • Licensing is DFSG-compliant and debian/copyright is accurate: Yes
  • Packaging is of good quality: No
  • Issues: 0 blocker, 2 important, 0 minor
  • debian/watch: version 5
  • debian/copyright: machine-readable
  • Scan before the review: nothing found

Licensing

The source is Apache-2.0 throughout: the root LICENSE is the full Apache License 2.0, and every core/*.go file carries an 'Apache License, Version 2.0' header with an IBM copyright line. The tree contains no third-party or vendored code, no other copyright holders and no other licence terms; the pre-scan's holder check found every holder named. debian/copyright is DEP-5, matches all upstream files with 'Files: ' and the packaging with 'debian/', and gives the Apache-2.0 notice plus a pointer to /usr/share/common-licenses/Apache-2.0. Test fixtures under resources/ are covered by the same stanza.

Packaging

The packaging is mostly conventional (compat 14, dh-sequence-golang, correct package naming for a v5 module, DEP-5 copyright, autopkgtest declared), but it has one functional bug and one test-suite bug. XS-Go-Import-Path omits the module's /v5 major-version element, so dh-golang installs the sources under /usr/share/gocode/src/github.com/IBM/go-sdk-core/core instead of .../v5/core and the -dev package cannot satisfy the import path its consumers use. Separately, every upstream test file is behind a build tag and debian/rules does not pass any, so the build-time tests and autopkgtest-pkg-go run zero tests; enabling them also requires copying resources/ into the dh-golang build tree.

Issues

important packaging 1. XS-Go-Import-Path omits the /v5 module major-version element ◂
  • Files: debian/control, go.mod:1, README.md:50
  • Basis: checked, in the package or with a reference tool
  • Evidence: debian/control: XS-Go-Import-Path: github.com/IBM/go-sdk-core; go.mod line 1: module github.com/IBM/go-sdk-core/v5; README.md line 50: "github.com/IBM/go-sdk-core/v5/core". dh-golang installs and copies sources verbatim under $destdir/usr/share/gocode/src/$ENV{DH_GOPKG} and _build/src/$ENV{DH_GOPKG} (golang.pm, install/configure).
  • Problem: DH_GOPKG is taken verbatim from the first XS-Go-Import-Path entry, so the package installs the library at /usr/share/gocode/src/github.com/IBM/go-sdk-core/core. Nothing is installed at github.com/IBM/go-sdk-core/v5/core, which is the import path of this module (go.mod, README, and the -v5-dev binary package name all say v5), so generated IBM SDKs and any other consumer importing .../v5/core fail to build in GOPATH mode. The binary package ships a library that cannot be imported by the module path it is named for.
  • Fix: Set XS-Go-Import-Path: github.com/IBM/go-sdk-core/v5 in debian/control, rebuild, and check that the package contains /usr/share/gocode/src/github.com/IBM/go-sdk-core/v5/core.
important packaging 2. Build-time tests and autopkgtest run zero tests; resources/ would be missing if enabled ◂
  • Files: debian/rules:1-4, core/*_test.go, core/authenticator_factory_test.go:36, core/container_authenticator_test.go:37, core/config_utils_test.go:37
  • Basis: checked, in the package or with a reference tool
  • Evidence: All 33 core/*_test.go files begin with a constraint such as //go:build all || slow || auth, and AGENTS.md states Running go test without -tags=all ... skips most tests. The golang buildsystem's test stage runs go test -vet=off -v with no -tags (golang.pm, sub test), so no test file is compiled and go test reports no test files. Tests also read ../resources/my-credentials.env, ../resources/cr-token.txt, ../resources/test_file.txt and ../resources/vcap_services.json, but configure copies only .go/.c/.cc/.cpp/.h/.hh/.hpp/.proto/.s, go.mod/go.sum and testdata directories (golang.pm, sub configure); resources/ is never copied into debian/_build/src/.... The package declares Testsuite: autopkgtest-pkg-go.
  • Problem: debian/rules has no override_dh_auto_test, so the upstream test suite is silently skipped both in the build and in autopkgtest: the declared test coverage is vacuous and regressions would not be caught. If -tags=all were added alone, the tests that open ../resources/... would fail because the directory is absent from the build tree.
  • Fix: Add export DH_GOLANG_INSTALL_EXTRA := resources and pass the tags, e.g. override_dh_auto_test: / dh_auto_test -- -tags=all, then verify the tests actually run at build time and under autopkgtest-pkg-go.
Verified ◂
  • Pre-scan: it flagged no files, and its holder check found every copyright holder in the tree named in debian/copyright; no additional holder or licence was found by grepping the whole tree for Copyright/(C)/© and for MIT, BSD, GPL, LGPL, MPL, 'Permission is hereby granted', 'All rights reserved' and SPDX-License-Identifier.
  • LICENSE is the full Apache License 2.0; all 70 files under core/ carry IBM '(C) Copyright IBM Corp. 2019[-2025]' and Apache-2.0 headers; no vendored or third-party code, and go.sum contains only module checksums.
  • resources/ (cr-token.txt, empty-cr-token.txt, ibm-credentials.env, my-credentials.env, test_file.txt, vcap_services.json) are test fixtures with self-declared fake credentials, not shipped in the binary package and covered by the Files: * Apache-2.0 stanza.
  • AGENTS.md, .bob/*/AGENTS.md, .github/, CHANGELOG.md, Authentication.md, Makefile, package.json, .releaserc, .bumpversion.toml, .secrets.baseline, .npmrc, .whitespace, renovate.json and .golangci.yaml are project documentation/configuration under the same Apache-2.0, matched by Files: *.
  • debian/copyright is DEP-5 with Format http://www.debian.org/... 1.0, Files: * and debian/*; the Apache-2.0 paragraph gives the notice and points to /usr/share/common-licenses/Apache-2.0, so no full text is required.
  • Read all of debian/: control, rules, changelog, copyright, source/format (3.0 quilt, no patches), gbp.conf, salsa-ci.yml, gitlab-ci.yml, upstream/metadata; compat is 14, Standards-Version 4.7.4 against Policy 4.7.4.1, no maintainer scripts or patches.
  • The Build-Depends names checked in the archive (golang-github-go-openapi-strfmt-dev, golang-github-onsi-ginkgo-v2-dev, golang-k8s-sigs-yaml-dev) exist; no Build-Depends references a missing file in the tree.
  • dh-golang's build system was read on the reviewing system to confirm how XS-Go-Import-Path, the source whitelist and the test command behave at this compat level.
  • uscan found the packaged version as the newest upstream release (upstream 5.25.1, packaged 5.25.1).
  • Every pointer of debian/copyright to /usr/share/common-licenses names a file that is there (Apache-2.0).
Not confirmed ◂
  • Whether the upstream tests pass with -tags=all and resources/ installed; a build could not be run.
Proposed changes ◂

None.

Uploader's response to the LLM review

The uploader was emailed about the review 19 days ago.

Review Information

accepted — allocated to awm 18 days ago, started 18 days ago, completed 18 days ago.

Final Comment

Hi,

The LLM review about this not being made available on the /v5 seems like it might be something worth looking into. If it's wrong about this please reply so I can give it some feedback...

Thanks!

Back to Dashboard | View all reviews for this package