On 2014-10-01 02:36:24, Andreas Tille wrote:
> Hi Antoine,
>
> On Tue, Sep 30, 2014 at 11:58:53PM -0400, Antoine Beaupré wrote:
>> I think the major issue that Andreas mentionned there is the
>> "DFSG-tarball" generation: the script should be in the debian/ directory
>> so the source can be regenerated easily without requiring access the SVN
>> repo. The script I could find is this:
>>
>> http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/get_latest_from_git.sh?view=co&revision=HEAD&content-type=text%2Fplain
>>
>> .. but that script seems to generate a tarball based on the git
>> repository, and doesn't seem to checkout any specific tag, so I doubt it
>> will work unmodified.
[...]
> I admit the request for sponsoring was sooooo long ago that I do not
> remember and I see no value to think about aged code. I'd perfectly
> agree if the current source for 3.2.2 would be used for packaging. I'd
> recommend to use Files-Excluded if any files need to be stripped from
> this source tarball (but I did not inspected it regarding this issue).
I'm not familiar with this mechanism - but it certainly looks
interesting!
https://wiki.debian.org/UscanEnhancements
Am I correct in understanding this would only simplify the
get-orig-source target, not replace it?
>> There were also issues with the debian/rules targets for repeated
>> builds.
>>
>> Andreas, was there other things you were thinking should be fixed with
>> the package?
>
> Since there are several upstream releases inbetween I would need to have
> another look. Since you obviously had a more recent look and you do
> not need a sponsor I'd trust your insight if you say it is OK.
I don't think it's okay - it doesn't even build at that stage,
especially because we strip so much off the tarball.
>> Finally, did anyone take a look at that PPA? Why aren't we just using
>> that debian package??
>>
>> https://launchpad.net/~opencpn/+archive/ubuntu/opencpn
>
> I personally did not. The only thing I could say that it always heats
> my temper a bit if I learn about another instance of failed
> communication between people working on free GIS software. I wonder
> why we are not able to catch all those people into our common project
> and do not reinvent the wheel over and over. :-(
The PPA is from upstream, and is fairly minimal: it doesn't split the
code in multiple packages (though I'm not sure why *we* do that in the
first place) and doesn't attempt to deduplicate code.
>> Thanks for the feedback,
>
> As you asked for in your other mail I added you to pkg-grass on alioth
> (even if Bas mentioned that this is not really needed for DDs). Since
> you seem to be Git affine I would suggest the following: Either convert
> the current
>
> svn://svn.debian.org/svn/pkg-grass/packages/opencpn/trunk/
>
> to Git or create a new Git repository which is compliant to Debian GIS
> policy[1] (fetch the tarball via uscan and use
> git import-orig --pristine-tar
> to inject the source.
Ugh.. pristine-tar... Why do we need this if we're going to strip out
half the tarball anyways?
> Designe the debian/ dir according to your insight
> as a DD (may be ask for review here - but I'm no GIS expert and thus I
> can only check packaging details).
Well, I'm not sure I'll have much more time to fight for this one - it's
a huge mess, that upstream, in terms of licensing and binary data...
> Please also get the person responsible fpr the PPA involved and invite
> him to join the project offering him cooperation to work on this
> repository. This should support his goal to make OpenCPN available in
> Ubuntu way better than some random PPA.
It's not exactly a random PPA: it's upstream running their own official
PPA...
A.
--
"Faith" means not wanting to know what is true.
- Friedrich Nietzshe
Attachment:
pgpT10etlBrks.pgp
Description: PGP signature