Re: RFS: opencpn
On Sun, May 1, 2011 at 9:22 AM, Hamish <hamish_b@yahoo.com> wrote:
> this is an update on this from a year ago:
> http://lists.debian.org/debian-mentors/2010/02/msg00115.html
>
> after a while and a fair bit of work upstream* I think we're ready for
> another shot at review. *[mainly hard work by Anton and Dave]
Firstly, I have to thank both of them for their persistence and hard
work! Much appreciated.
> I've done my package building on Squeeze. Maybe package deps have
> changed in sid, maybe not? I haven't set up a sid chroot or VM on
> my new machine yet. I mention this as some gtk issues have been
> reported on Ubu 11.04 in the last days and are currently being
> diagnosed.
Generally one should build and test using the suite you are uploading
to. Most uploads go to sid so they should be built and tested there.
> You guessed well; bzip2 and zlib are there for the MS Windows port [Grib
> plugin]. The cmake rules are patched to use the system's zlib, bzip2 if
> UNIX. It is expected this patch will be applied upstream in the near
> future. Released tarballs are actively targeted at Linux, Mac OSX,
> and MS Windows builds; I am not going to ask upstream to issue a
> special stripped down version of the tarball every release just for us,
> or maintain such a thing myself. If there was some sort of license
> issue I would, but for the sake of an unused 200kb(uncompressed) in
> the .orig.tar.gz, it just ain't worth the effort.
Fair enough. Please remove the embedded code copies before
debian/rules build (or configure) so that the Debian package can never
build against it by accident.
> Grib code has been moved to a plugin. ZyGrib does not supply a lib
> package, nor even use libaries within its main package- it's a stand
> alone binary. So OpenCPN clone some of their reader code. It is beyond
> the scope of this packaging effort to refactor a 3rd party's application.
> (aside: I suspect their debian packaging needs a little work too)
Fair enough I guess. If it isn't possible to use the ZyGrib binary
from the plugin I would suggest to ask ZyGrib upstream to add a
library.
> As for src/mygdal and src/myiso8211, GDAL does supply nice library
> packages but OpenCPN has modified and adapted them. Dave (the OpenCPN
> lead author) had this to say when asked:
Please ask the OpenCPN folks to get their GDAL changes merged
upstream, maybe it will become suitable for OpenCPN use as a result.
> As for src/nmea0183, AFAIK it does not exist in library form elsewhere
> in Debian, and if copyright+Author header comments are anything to go
> by has been specifically tailored/reworked by the OpenCPN lead dev.
Ok. Same comment as for GDAL.
>> src/nmea0183 has no copyright information and this as a license:
>>
>> You can use it any way you like.
>>
>> Unfortunately this does not give Debian permission to copy, modify or
>> distribute.
>
> AFAIU the original author was contacted by upstream, the reply was
> "It is BSD license, do with it what you will"
> which is now given in the header comments there.
Great.
> The tide and current harmonic data contained herein are derived from the
> corresponding XTIDE harmonic data. The file data have been tweaked to
> work nicely in the US, especially fixing current direction reporting. We
> have also added additional global tide stations, and corrected calculation/
> display units where sensible. A generic XTIDE harmonic file set will be
> functional, but less useful than the harmonic data packaged with OpenCPN.
Would it be possible to merge those changes into the xtide version?
> the package is now lintian clean on squeeze.
Lintian has improved a lot since squeeze, always use the
sid/experimental/backports version.
> I have not looked at those, nor know how they could be addressed.
Fix the upstream build system to not link against stuff the app
doesn't use. Probably some of these are wx's fault though.
> I have not attempted to review or address compiler warnings, but note that
> the code has changed significantly since the above, so best to look at a
> fresh build.
Indeed, especially with GCC having gone through several major versions.
> A matter of personal preference IMO, but upstream has now switched to git.
Indeed, excellent.
>> You have enough work above, but have you also considered packaging
>> wxTide, CapCode and other FLOSS nautical apps?
>
> Xtide is already packaged (AFAIK wxTide is a Windows port of it).
> CapCode is alive! http://sourceforge.net/apps/trac/capcode/timeline
Cool.
I'll do another review of the package in the next few hours.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: