Bug#1101838: ITP: hexagon-dsp-binaries - Qualcomm Hexagon DSP binaries
I've skipped all resolved items below except for ones I wanted to
comment on - thanks! Just two items remaining.
On Fri, Sep 26, 2025 at 07:57:17PM +0300, Dmitry Baryshkov wrote:
> In the package descriptions there are two mentions of Qualcomm:
> - Qualcomm SoCs, which should be fine as it describes the owner of the
> CPUs present in those devices
> - Qualcomm foo bar, which is the commercial name of the device. Devices
> marketed by Thundercomm have that vendor name instead.
>
> Please correct me if I missed something or if I should change anything
> here.
Sorry, I think I missed a previous change. The generated debian/control
descriptions look fine now.
> That's a good point. If fastrpc is split into three daemon packages,
> then each daemon package should 'Suggests: hexagon-dsp-binaries-Ndsp',
> where 'N' is one of 'a', 'c', 'g' or 's', for each kind of DSPs.
>
> WDYT? I can implement that straight away.
I have quite a bit to say on this, but to make progress, let's get
hexagon-dsp-binaries package uploaded first. We don't need the virtual
packages until something is going into Debian that depends on them. This
will probably be fastrpc, and I have an ITP filed for that now, but I'm
not yet ready for a Debian upload.
> > [Needs Information] debian/copyright indicates that WHENCE is under
> > binary-redist-Qualcomm-media. Is that your intention?
>
> From my POV it doesn't contain code, so it's not copyrightable. But
> let's put it under the MIT exclusion together with config.txt
Sui generis database rights might apply even if regular copyright does
not, so it's better to ensure that it is unambiguously distributable
under a suitable licence. If upstream consider that to be MIT then it's
fine to label it as such in debian/copyright, but I think Debian
ftpmasters may still require evidence in the upstream source tree of our
claim in debian/copyright that upstream considers WHENCE to be licensed
under MIT.
[Needs Fixing subject to discussion] Do you think it would be reasonable
for you to arrange for upstream to make this clear to avoid all
ambiguity, please? It would be nice to then get a new upstream release
and update to that.
What I'd like is for the Debian ftpmasters to find, when they review,
that all is in order with everything being stated in debian/copyright
precisely and unambiguously matching what is claimed by upstream in the
source tree itself (preferably verifiable using the licensecheck tool).
> > [Needs Fixing] (for when we pull in a newer upstream)
> > https://github.com/linux-msm/hexagon-dsp-binaries/commit/dfcdfcf0de7f9846cd8274ddba332ce52f840168
> > introduces LICENSE.MIT, but now it isn't clear what the "default" is
> > because both proprietary and MIT licence files are present in the source
> > tree. So which licence applies to
> > `apq8096/Qualcomm/db820c/ADSP.8996.2.7.1-00138/AlacDecoderModule.so.1`,
> > for example, and how would I know that? It's now ambiguous. This relates
> > to the previous point: what licence applies to files that aren't
> > directly marked themselves?
>
> It is described in README.source and (upstream) in the WHENCE file.
> Please provide recommendations on how to express it in a better way.
Sorry, you're right, it is umambiguous in WHENCE. I'm not used to
looking there. Nothing further needed on this point, thanks.
> > > [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?
> >
> > You didn't address this which is fine, but note that commit f1df6 that
> > does this has a typo that you may want to fix.
>
> Fixed, thanks. Yes, I think it's a good idea to prefix all commit
> messages with debian/ or d/
I won't stop you, but I think that because *all* commits to the Debian
packaging branch (that aren't merged in from upstream) are in the
context of Debian packaging, this is redundant context and reduces the
useful available space for a summary. But it's up to you.
> > > [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] Looks like this still needs doing.
>
> Here I followed the firmware-nonfree. I have provided the Source: field,
> which points to the upstream repo with the tarballs in the releases
> field.
I'm happy with this now - thanks!
> > > [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] Looks like this still needs doing.
>
> Adding Disclaimer: to debian/copyright, thank you.
Ack.
> > > [Needs Information]
> >
> > > > # Upstream check.py can't work with Debian's packaging
> >
> > > What do we need to do to get it to work?
> >
> > [Needs Information] Please address this.
>
> I think I provided an explanation inside debian/rules. It requires
> upstream Git repo as it performs checks of WHENCE vs config.txt vs Git.
> These checks are performed when new firmware is being added to the
> archive and they target making sure that the commit is self-consistent.
> There is no need to run them at the packaging time.
Sorry, I missed this change in my previous review. Your updated
explanation is fine - thanks.
> > > [Needs Information] What purposes do the map*.txt files serve? Are
> > > they necessary to be present in the binary packages?
> >
> > [Needs Information] Please address this. If we're going to the trouble
> > of a lintian override, I'd like an explanation of why it is needed to be
> > shipped in the binary package in the first place, why it cannot be in
> > /usr/share/doc/ if it's just users who might want to consult it, or for
> > it to be moved to debian/not-installed if it is not required.
>
> For this question I have no idea, unfortunately. They might be used by
> the SDK or by something else. I have opened an issue at the FastRPC
> project, asking for clarifications. For now I'd prefer to keep them. We
> can drop them later, if FastRPC developers respond that they are
> unnecessary.
>
> For the reference: https://github.com/qualcomm/fastrpc/issues/248
Thank you for checking with upstream. For the time being, given
lintian's sensitivity to this, I don't think I can justify a lintian
override without a direct reason. From an FHS perspective, these
probably belong in /usr/share if they must be shipped, and then they
will break multiarch. So I really need to understand the reason for them
existing to be able to decide if and where they should go.
[Needs Fixing] For now, please move these to debian/not-installed (I
think wildcards should make this possible, otherwise we can find another
way) and remove the lintian override.
It will be easy to figure out what to do with them and update the
package if and when we actually have a failing use case. Removing them
to clean up is more of a pain because we won't know who we might be
breaking.
> > > [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 Fixing] FTR, this is discussed at
> > https://lists.debian.org/debian-devel/2025/08/msg00508.html,
> > https://lists.debian.org/debian-devel/2025/09/msg00215.html and
> > https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/128.
> > OOB, we have agreed to defer this for now while we want for the
> > firmware-nonfree maintainers to respond. So for the time being, please
> > prepare this for upload to experimental instead (suffix the version
> > ~exp1 and change the target suite to "experimental"). That way we can
>
> This is something new. I've changed the suite to experimental, But I
> don't think it's requried or recommended to use ~exp for experimental.
It's only a convention to allow the first unstable upload to use -1, and
perhaps indicate to users the experimental nature of the package
version. -1~exp1 would I think be the most conventional packaging
version to use in this case. But I believe it's fine not to follow it,
especially as the unresolved dependency question doesn't affect users in
its current form, so I leave it to you.
Robie
Reply to: