Re: RFS: opencpn
Paul W wrote:
> 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.
This possibility is not something which would keep me awake at
night, but no harm in it, so will do.
Hamish:
> > 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.
ok, versions only differ by 0.0.1, will do.
> > 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
Have a look at the file(s) in question, I'm fairly sure that's
a false positive.
> > 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?
http://gpsd.berlios.de/protocol-transition.html
> > 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,
http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2011-June/010184.html
I feel your cringe, but we need a stable, controlled place with
history to house the dfsg version of the source tarball; so
$alioth is it. We could check it in uncompressed, but as the
versioned release is static and should be immutable, and all we
want is the tarball, it would seem to me that the current
solution's benefits outweigh its shortcomings.
> >> 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.
ok, so noted as a last-minute todo once everything else in the
review is checked off. (I'd like it as the most modern thing
in the changelog once the package is ready for upload / don't
like crossing things off before they are done)
> > 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?
prebuilt graphics are a heck of a lot easier to review, modify,
and adapt than auditing and hex-editing binary executables? (well,
you asked..)
It's really the added weight of Inkscape et al. as build-deps
which makes me not mind the risk of slightly stale icons too much.
> Thanks for pushing this ITP forward.
ditto,
Hamish
Reply to: