[Debian-on-mobile-maintainers] hexagon-dsp-binaries for DebianOnMobile

Robie Basak robie.basak at oss.qualcomm.com
Thu Apr 23 09:59:50 BST 2026


Hi Arnaud,

Thank you for accepting us into the team!

On Wed, Apr 22, 2026 at 03:17:53PM +0200, Arnaud Ferraris wrote:
> Speaking of branches, I've noticed you don't have a pristine-tar branch.
> Could you please consider creating one? This is common practice across the
> DebianOnMobile team, and ensures every bit of data we need to build the
> packages is present in git.

hexagon-dsp-binaries is modelled on firmware-nonfree, which looks like
it doesn't use pristine-tar either. A couple of difference from other
packaging:

 * They're (non-free-firmware) binary blobs, not useful source that
   users could modify.
 * We'd be checking in these binary blobs to the upstream branch rather
   than the normal expectation of the source tree being in there.
 * They're very large, so pristine-tar and upstream branches would be
   very large. git will cope, but I think it may become unnecessarily
   painful to handle, and I'm not sure who would actually access these
   in practice to make it worth the pain.

Given the above, I'm not sure of the value of managing it this way. For
similar reasons it has a debian/ directory only git tree. I think
firmware-nonfree is an example of the same (unusual) circumstances
resulting in the choice to not keep the upstream "sources" in git.

`uscan --download-current-version` does work (note that repacking is
active via Files-Included/Excluded) and in the worst case scenario,
sorignapshot.debian.org does keep the repacked orig tarballs around for
us.

We _could_ keep an upstream branch, tags, and pristine-tar updated, so
this isn't a blocker or anything. I'm just not sure that there's value
in it, unlike normal packages.

Do you think an exception to normal practice is warranted in this case?

Thanks,

Robie



More information about the Debian-on-mobile-maintainers mailing list