Le 3 déc. 2015 18:40, "Diego M. Rodriguez" <diego.plan9@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