Bug#1101838: ITP: hexagon-dsp-binaries - Qualcomm Hexagon DSP binaries
On Tue, 30 Sept 2025 at 14:53, Robie Basak <robie.basak@oss.qualcomm.com> wrote:
> On Fri, Sep 26, 2025 at 07:57:17PM +0300, Dmitry Baryshkov wrote:
> > 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.
The 'hexagonrpcd' package is already a part of Debian.
> > > [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.
Is the following PR enough from your POV? If it looks good, I will merge it.
https://github.com/linux-msm/hexagon-dsp-binaries/pull/18
>
> 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 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.
Ack, dropping them for now.
> > > 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.
I've seen enough unstable uploads which don't start from -1 (e.g.
https://tracker.debian.org/pkg/gcc-14). So I'd leave the version
intact for now.
--
With best wishes
Dmitry
Reply to: