Re: RFS: opencpn
On Sat, Jun 18, 2011 at 3:29 PM, Hamish <hamish_b@yahoo.com> wrote:
> mmph, IMO .orig should mean "orig", and the .diff should take care of
> the cleanup needed for Debianization. (the exception being dfsg
> incompatible stuff) Lintian will alert us if a change in the cmake rules
> re-embed the libs. (which are supplied for building the MS-Windows/Mac ports)
I wasn't talking about repacking the tarball, but adding "rm -r
path/to/embedded/code/copies" to debian/rules build. This ensures that
the package will never build against the embedded code. You can never
be sure if the person doing the upload will run lintian, nor that
lintian knows about the specific embedded code copies you are using.
Think of it as an additional safety net.
>> Please ask the OpenCPN folks to get their GDAL changes merged
>> upstream, maybe it will become suitable for OpenCPN use as a result.
>
> AFAIU, the changes are not considered useful/desired for others, so
> intentionally not pushed upstream to GDAL.
Hmmm.
>> > The tide and current harmonic data [...]
>> Would it be possible to merge those changes into the xtide version?
>
> It would be nice, but probably not. They have their own ideas and goals,
> and have implemented them. AFAIU OpenCPN has decided something else is
> needed, and to take it on their own path with that.
>
>
>> Lintian has improved a lot since squeeze, always use the
>> sid/experimental/backports version.
>
> ok, sid's lintian now reports:
> E: opencpn-data: helper-templates-in-copyright
> E: opencpn: embedded-library usr/bin/opencpn: tinyxml
> E: opencpn: helper-templates-in-copyright
> E: opencpn-doc: helper-templates-in-copyright
>
> tinyxml: not sure, exists to be embedded? suggestions to fix that welcome.
Build-Depend on libtinyxml-dev and add any patches needed to build
against the system version.
> helper-templates-in-copyright x3: I don't see what it's talking about, the
> debian/copyright files are custom crafted.
http://lintian.debian.org/tags/helper-templates-in-copyright.html
> yeah I know. It's there as an explicit reminder that there'll likely be
> trouble when the upcoming libgps20 is transitioned into sid.
What kind of issue?
> An .orig tarball with the dll and exe ms-windows port binary stuff removed
> can now be found here:
> http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/
Hmm, a tarball in SVN,
> It is likely this area can be further automated.
> I would still aim the watch file at the official SourceForge site.
Definitely.
>> debian/changelog does not close the ITP.
>
> I consider that a last-minute task for when we have passed review and are
> ready to submit for upload.
Eh? It wouldn't pass review without it.
> I think the only one left which isn't wholly about conforming to Debianisms
> is the location of the plugins lib dir. Suggested on the upstream forums but
> no feedback to report yet --anyway, low priority and the difference is noted
> in the README.Debian file.
> I tried that on my 6-core Squeeze box, but it did not change build time
> at all, so I've left it "clean". It would be nice to have working though.
> ??
I guess the upstream build system does not support it.
> avoiding those as build-deps seems to outweigh the possibility of stale
> xpm/png files. FWIW all generated files seem younger than 8 weeks, so I
> suspect are kept up to date with regularity.
I don't think graphics should be treated any differently to programs
wrt building and source code. We don't ship precompiled executables
in/from source packages, why should graphics be any different?
Thanks for pushing this ITP forward.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: