Hi, On Fri, Oct 17, 2025 at 05:07:15PM +0000, Debian FTP Masters wrote: > binary:hexagon-dsp-binaries is NEW. > [various others from the same source skipped] > source:hexagon-dsp-binaries is NEW.
Further to developer-reference section 5.1 "If you think your package needs some explanations for the administrators of the NEW package queue" here are some explanations that I think are relevant from my perspective as I'm sponsoring this package, but aren't relevant to go into the packaging itself eg. debian/README.source. "Is it worth including it in the archive?" from NEWChecklist: there's quite a complex software stack involved here. This non-free package is only part of it. Further up the stack there's fastrpc (Debian ITP bug 1116042) and further up still we have packages like tensorflow that are DFSG licensed. Ultimately this will allow such DFSG software to take advantage of Qualcomm hardware acceleration. This package is part of the story as we work our way towards that goal. I believe this fits the spirit of the non-free archive area in a way that will benefit Debian users. I wondered whether this belongs in non-free-firmware or non-free. This package ships object code for loading into the DSP for execution there, not the host CPU. In that sense it's firmware. However, I'm told it application code from the DSP's perspective rather than firmware, which is why it's not included upstream in linux-firmware (Debian src:firmware-nonfree). For this reason, it has been named hexagon-dsp-binaries, not hexagon-dsp-firmware. There is currently a hard version dependency on linux-firmware I'm not happy about. There's a thread on debian-devel[1][2] and a Salsa MR against firmware-nonfree[3] currently open for discussion, and I've asked for this upload to go to experimental for now to give the firmware-nonfree maintainers a chance to opine. For now and for this reason I've left "firmware-qcom-soc (>> 20250917), firmware-qcom-soc (<< 20250917.0)" as-is (I'm not keen on this >>/<< .0 business either). There are some other oddities in the packaging that are following patterns set by src:firmware-nonfree that I've left in place on the basis that these are already established there. The license that is intended to apply to the WHENCE has been clarified by upstream[4] on my request. I did wonder if Architecture: all or Architecture: arm64 (with Multi-Arch: foreign in the latter case) would be appropriate, given that only arm64 SoCs have a relevant DSP. On asking around there should be no functional difference so I have accepted this as-is for sponsorship. I'm not sure dpkg-build-api (=1) is necessary for anything newly added to >= trixie, but it doesn't cause any harm and sponsorship reviews were taking long enough so I left this as-is. We intend to move this to team maintainence but that is another thing to organise and I want to make progress without blocking on it. Thanks, Robie [1]: https://lists.debian.org/debian-devel/2025/08/msg00508.html [2]: https://lists.debian.org/debian-devel/2025/09/msg00215.html [3]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/128 [4]: https://github.com/linux-msm/hexagon-dsp-binaries/blob/trunk/WHENCE#L8
