On Tue, 30 Sept 2025 at 14:53, Robie Basak <[email protected]> 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
