Le 3 déc. 2015 18:40, "Diego M. Rodriguez" <diego.pl...@gmail.com> a écrit : > > 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.
Brilliant. > 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? Worth forwarding upstream but not a deal breaker. Again d/copyright should cover these. > 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]. Gianfranco is (rightfully) very thorough. Spell and code checks should be forwarded upstream but the decision of maintaining a patch for these is yours. As long as they don't alter usability of the software obviously. > > - 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. I am not familiar with git-dpm so I cannot comment. You can keep your packaging work hosted on github for instance whilst waiting approval to join a team. Ghis
