Re: RFS: OpenCPN navigation (ITP #538067)
On Monday 16 January 2012 09:09:27 Hamish wrote:
> Hi,
Hi,
(just to summarize the log from IRC session, we had)
> It's been 5 weeks without response, and no luck finding a sponsor on
> IRC, so I'll try a repeat posting. :-)
Yeah, a lot of effort has been put into making this packaged properly (as seen
from the ITP bug), but the package is in very specific niche and possibly only
few interest is provoked amongst DDs, of course the lack of free time is also
a blocker, and last bu not least the whole thing is quite complex.
> As a measure of end-user interest in this program, downloads in the
> last 12 months have averaged about 500/day from the sourceforge d/l site.
> http://sourceforge.net/projects/opencpn/files/stats/timeline?dates=2006-10-
> 26%20to%202011-12-31
the most visible issues, so far:
* modified embedded copies of external projects - nmea (for the main app -
okay; and each plugin, why so?), iso8211, gdal. Maybe all these modifications
are justified, as seen from the ITP, this is best to be sorted out.
* unrelated (wrt Debian archive) binary files (like vc_redist.exe, visual
studio redistributable) are found the the upstream tarball, also removed by
you in the dfsg tarball.
Both of these could be documented within the 'Comment' field of DEP-5,
mentioning the reason for removal and modification. It is good to have them
carefully put together, so that they are traceable at least; these of course
might be solved one way or another in the future versions.
Next,
* long package descriptions should be impoved, and in my opinoin to the point
where a person with a driver license could be comfortable to read and
understand it :) For instance: the bullet list of bullet of features, should
have more explanations; you cold add a sentence or two about the "Route
handling facility".
* get-orig-source, or have a look at DevRef - 6.7.8.2. - Repackaged upstream
source - to at least ease the fetching of your dfsg tarball from alioth.
> * to put "dfsg" in the version number or not?
yes, ...+dfsg-1.
> Hamish wrote:
> >> You'll notice our source tarball is labeled dfsg. This is because
> >> there were some included DLLs to help build the MS Windows
> >> version of the program which we didn't need/want for the Linux
> >> build, the source code itself is untouched.
>
> Paul Tagliamonte wrote:
> > Is the source included for those DLLS?
>
> No. They are 3rd party; specifically Nullsoft's NSIS installer,
> http://nsis.sourceforge.net/License
> and Microsoft's VisualC++ runtime redistributable.
>
> NSIS is permissive FOSS; vcredist is free as in beer.
>
> Without even considering the unused & source-avail-at-sourceforge NSIS,
> I'm pretty certain that free-as-in-beer anything is not allowed to be
> uploaded within src.tar.gz files, so it needs to be repacked anyway.
>
> so it comes down to a trivial adjustment:
> If pbuilder cares that the exact tarball filename matches the version
> in the changelog file it is trivial to edit it in & I would leave that
> to the DD uploader to adjust or not as they see fit.
> For me building with `debuild -i -uc -us -b -j6` there is no issue.
>
>
> aside: Anyone know the redistribution terms for vcredist_x86.exe ?
> MS's download site does not make it obvious and I guess you have to
> actually install it to get the EULA. -> Can a GPL'd Windows program
> validly ship it as part of the install, or must it be left as a "why
> does it fail with Error 14001?" FAQ on the project's homepage?
Whatever, we don't need vc_redist.exe in Debian archive -- at least 300
mirrors will have some disk space trashed for no good reasons.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: