Sign me up Login

Details about package hexagon-dsp-binaries

Name: hexagon-dsp-binaries
Uploader: Dmitry Baryshkov <dbaryshkov@gmail.com> (Debian QA page)
Description: hexagon-dsp-binaries - Hexagon DSP binaries and libraries
hexagon-dsp-binaries-apq8096-qualcomm-db820c - Hexagon DSP binaries and libraries for Qualcomm db820c
hexagon-dsp-binaries-sdm845-thundercomm-db845c - Hexagon DSP binaries and libraries for Thundercomm db845c
hexagon-dsp-binaries-sm8250-thundercomm-rb5 - Hexagon DSP binaries and libraries for Thundercomm RB5
hexagon-dsp-binaries-qcm2290-thundercomm-rb1 - Hexagon DSP binaries and libraries for Thundercomm RB1
hexagon-dsp-binaries-qrb4210-thundercomm-rb2 - Hexagon DSP binaries and libraries for Thundercomm RB2
hexagon-dsp-binaries-qcm6490-thundercomm-rb3gen2 - Hexagon DSP binaries and libraries for Thundercomm RB3gen2
hexagon-dsp-binaries-sa8775p-qualcomm-sa8775p-ride - Hexagon DSP binaries and libraries for Qualcomm SA8775P-RIDE
hexagon-dsp-binaries-qcs8300-qualcomm-qcs8300-ride - Hexagon DSP binaries and libraries for Qualcomm QCS8300-RIDE

Package uploads

Upload #4

Information

Version: 20250808-1
Uploaded: 2025-09-05 16:30
Source package: hexagon-dsp-binaries_20250808-1.dsc
Distribution: unstable
Section: non-free-firmware/libs
Priority: optional
Homepage: https://github.com/linux-msm/hexagon-dsp-binaries/
Vcs-Browser: https://salsa.debian.org/lumag/hexagon-dsp-binaries
Vcs-Git: https://salsa.debian.org/lumag/hexagon-dsp-binaries.git
Closes bugs: #1101838

Changelog

 hexagon-dsp-binaries (20250808-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1101838)

QA information

Comments

No comments

Upload #3

Information

Version: 20250808-1
Uploaded: 2025-08-20 09:29
Source package: hexagon-dsp-binaries_20250808-1.dsc
Distribution: unstable
Section: non-free-firmware/libs
Priority: optional
Homepage: https://github.com/linux-msm/hexagon-dsp-binaries/
Vcs-Browser: https://salsa.debian.org/lumag/hexagon-dsp-binaries
Vcs-Git: https://salsa.debian.org/lumag/hexagon-dsp-binaries.git
Closes bugs: #1101838

Changelog

 hexagon-dsp-binaries (20250808-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1101838)

QA information

Comments

No comments

Upload #2

Information

Version: 20250808-1
Uploaded: 2025-08-20 00:29
Source package: hexagon-dsp-binaries_20250808-1.dsc
Distribution: unstable
Section: non-free-firmware/libs
Priority: optional
Homepage: https://github.com/linux-msm/hexagon-dsp-binaries/
Vcs-Browser: https://salsa.debian.org/lumag/hexagon-dsp-binaries
Vcs-Git: https://salsa.debian.org/lumag/hexagon-dsp-binaries.git
Closes bugs: #1101838

Changelog

 hexagon-dsp-binaries (20250808-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1101838)

QA information

Comments

No comments

Upload #1

Information

Version: 20250808-1
Uploaded: 2025-08-18 18:44
Source package: hexagon-dsp-binaries_20250808-1.dsc
Distribution: unstable
Section: non-free-firmware/libs
Priority: optional
Homepage: https://github.com/linux-msm/hexagon-dsp-binaries/
Vcs-Browser: https://salsa.debian.org/lumag/hexagon-dsp-binaries
Vcs-Git: https://salsa.debian.org/lumag/hexagon-dsp-binaries.git
Closes bugs: #1101838

Changelog

 hexagon-dsp-binaries (20250808-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1101838)

QA information

Comments

  1. Overall this looks good, but there are quite a few complexities due to the generated sources and the nature of this being non-free firmware which means there are quite a few requests for change below. I'm struggling to ensure to give you a complete review due to this; I think I may find more on a second review iteration.

[Needs Fixing; subject to discussion] It seems odd to put "-binaries-' in the package names. And all binary Debian packages are binary :)  I don't think this will give a typical user any further information on what the binary package does, so I'd like to avoid using this word there. I think "hexagon-dsp-" is fine as a prefix, but it'd be nice to use something more specific than "binaries". Maybe "apps"? "tools"?

[Subject to discussion] Given developer reference 6.2.1, 2 and 3, is "Qualcomm" a necessary part of the package description? Can we make it more understandable by users? How are they going to determine which package to install?

[Subject to discussion] Is package splitting really necessary? We don't split linux-firmware or alsa-ucm-conf, and splitting here has resulted in a bunch of extra generated files related pain. How will depending packages depend on the correct binary package here? What's the user story on how they're going to get the correct packages installed?

[Needs Fixing] debian/copyright: Makefile, scripts/install.sh and dist.sh are clearly marked MIT and need to be marked accordingly in debian/copyright. config.txt, scripts/check.py and scripts/filter_whence.py need their licences clarified upstream. Ideally there would be clarity from upstream in the source tree itself on what the licence is for source files not specifically marked.

[Needs discussion] debian/copyright debian/*: there's a convention to use the same licence for debian/* as the upstream, to avoid conflicts when upstreaming patches or other packaging also useful to upstream, especially if somebody else contributes them. I'm not sure how this works with non-free. I'm surprised at your choice of GPL-2+ here though.

[Needs Information] debian/copyright debian/*: are you doing this in your own time, or as a Qualcomm employee? Who owns the copyright on your packaging work? If Qualcomm, then you likely cannot claim the copyright for yourself personally (or are you saying that, exceptionally, you can?), and they need to sign off on your choice of GPL-2+ for your packaging.

[Needs Fixing] lintian tag new-package-uses-date-based-version-number seems valid; please drop it and use the 0~ prefix as advised by https://lintian.debian.org/tags/new-package-uses-date-based-version-number.html 

[Needs Fixing] debian/upstream/metadata: why the commented out fields?

[Needs Information for the eventual uploader] Vcs-Browser: Where's our goal for where this will be maintained eventually? Are you planning to move this to a team on Salsa?

[Fix if you like, or not] Commit 84fd741: if the packaging git repository is only ever going to contain a debian directory, are you planning on prefixing all commits with 'debian/'? What does that achieve?

[Fix if you like, or not] Convention is to use .in for the source of generated files, so maybe you could use lintian-overrides.in instead of lintian-template?

[Needs Fixing] README.source: Debian Policy 12.5 says the explanation of where the upstream sources were obtained must be specified in the copyright file, so this seems like the right place to put this information instead. Please move this information from debian/README.source to debian/copyright under a Header stanza Comment field.

[Needs Fixing] Debian Policy 12.5 says: "Packages in the contrib or non-free archive areas should state in the copyright file that the package is not part of the Debian distribution and briefly explain why.". I think this is intended to include non-free-firmware too, which is newer. Please add this statement and explanation.

[Needs Fixing; subject to discussion] The final Debian source package upload is required to have debian/control even though it is generated. The conventional hack is to actually check it in to git. That way the git tree will match the source package exactly. Otherwise a future sponsor will have difficulty in getting from the git repository to an uploaded package. This is subjective and not a Debian requirement, but I think it makes sense to follow existing convention here. See for example src:golang-1.24 and src:llvm-toolchain-19 as examples of where debian/control is generated. Therefore, please check in the generated files. In this case, since you're generating files that change name, it might be an idea to also add some tooling to clean up all generated files as a separate built target. Sorry this is ugly. I suspect this might mean that you will want to refactor the generation mechanism, so I haven't reviewed it in detail and will do that on the next review iteration.

[Needs Fixing] Noise from packaging templates should be removed, as explicitly mentioned in https://ftp-master.debian.org/REJECT-FAQ.html. At least the template comments and unused examples in debian/rules.

[Needs Fixing] lintian-template typos: "out expectations", "data"

[Needs Information]

> # Upstream check.py can't work with Debian's packaging

What do we need to do to get it to work?

[Fix if you like, or not] I suggest that this would be cleaner:

-# Debian doesn't want extra license files
-override_dh_auto_install:
-       dh_auto_install
-       find debian/tmp/usr/share/qcom -name "LICENSE.*" -delete
+# Licences are already being provided via debian/copyright
+override_dh_install:
+       dh_install -XLICENSE.\*

[Needs Fixing] README.source typo: "tin the"

[Needs Fixing] /usr/share/qcom seems like an odd choice of namespace for the installed firmware files themselves. Can we use a namespace that is based on the package name instead? That will avoid collisions against other unrelated packages.

[Needs Information] What purposes do the map*.txt files serve? Are they necessary to be present in the binary packages?

[Needs Information] The ITP mentions: "With this in place packagers can require that the version of the DSP binary package must match the linux-firmware-qcom-soc package version."; does this need implementing? I don't see the mentioned linux-firmware-qcom-soc package.
    Needs work Robie Basak at Aug. 19, 2025, 4:24 p.m. 
  2. Hey, Dmitry also asked me to take a look to get more eyes on this package.

Robie already did a detailed review, so I'll share my drive-by notes:

1) it's kind of weird that the binary packages and source packages are named differently; I would personally lean with either sticking to the upstream name or using firmware in the package names, but I understand why the current compromise was reached

2) I am not a fan of usr/share/qcom either; while it seems to be designed to allow sharing different types of objects there, it's kind of surprising as a top-level; perhaps this is useful to preserve practice across OSes (e.g. Yocto images) and there's some usefulness to preserving cross-OS alignment on this tree? would be nice to state this

3) gencontrol.sh uses tabs and spaces inconsistently

4) saw same typo in README.source (tin)

5) lintian template is not autogenerated, but contains the autogenerated mention; instead, gencontrol could add it just like it does for install files

6) in gencontrol, I would name debian/tmp-control debian/control.tmp and follow the same strategy for the other generated files, then list debian/*.tmp in clean

7) gencontrol should perhaps be named differently since it generates more than the control file

8) rather than disabling dh_dwz, dh_strip, dh_shlibdeps, I would personally just exclude usr/share/qcom file patterns instead; this would be a smaller hammer

9) shellcheck suggests a few light, mostly quoting related improvements for gencontrol.sh; nothing major

10) Overall, I found the package more complex than I expected for a data package, but it's relatively elegant in using autogeneration to avoid repeating data. I did briefly research whether the dh autogeneration features could be used, but dh_lintian doesn't support templating. Install files could use a template, that would require defining #target# for each package. It's probably simpler to leave things as is though.
    Needs work Loïc Minier at Aug. 28, 2025, 5:21 p.m.