On Thu, Dec 03, 2015 at 01:40:15PM +0000, Ghislain Vaillant wrote: > Speaking of potential mistakes, here are a few things that bited me whilst > working on the packaging of ArrayFire: > > - Be sure that you don't need to repack / strip some of the content of the > source tree due to some DFSG-related reason (copyright, embedded > library...). For that, the licensecheck tool comes very handy. > > I found out that using upstream git with submodules + a repack step is not > worth the trouble. For ArrayFire, the introduction of non-free code happened > after the initial upload. If I had known sooner however, I would have used > the standard approach. Dully noted - I'd lean towards believing that in this case there are no DFSG-modifications to be made (the main repository and the C-implementation clearly state BSD-2-clause, and upstream has confirmed me on a private conversation that the test .csvs repository is under the same copyright and license as well; and it does not include or reference any other libraries). I have hopefully reflected this in the debian/copyright file. licensecheck does however complain about most of the files missing a license or copyright header. I'm wondering if they should be patched for the Debian package, or it sufficient to rely on the aforementioned debian/copyright? On a slightly related note (and hoping not to be taking advantage of your willingness to help!): should a patch be provided to make the python files PEP8 compliant and fix the pyflakes, etc. warnings, or is this something that should be handled upstream? I'm asking after noticing some package reviews on the mailing list that point to these errors, such as [1]. > - Be extremely careful when merging new tags in the packaging branch. > Mis-handling of the submodules can happen very fast and lead to a broken > pristine tarball. > > Do really check that the diff between your debian branch and the upstream > tag only shows the debian folder and not a difference between the commit-ids > of the submodules. In case mis-hap, I would advise to start fresh with the > merging of the upstream tag, sort the submodules and rebase any subsequent > work onto that. Thanks again the heads up - so far my tests with git-dpm and conforming to the DEP-14 guidelines have been local, but I will make sure to double check on the mentioned issues. I'm wondering also if there is a recommended way for sharing the latest git-dpm efforts while not having write access to Alioth, perhaps by using github or a similar service? I'm doubtful between focusing my efforts on filling a formal RFS request at this point in time (mainly to initiate code review, and polish the remaining issues), or waiting until I'm more familiar with the git-dpm procedures. Thanks again, Ghislain! [1] https://lists.debian.org/debian-mentors/2015/11/msg00346.html -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
Attachment:
signature.asc
Description: Digital signature