Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
On Fri, Apr 19, 2013 at 03:10:20AM -0700, Hamish wrote:
> > Do you need a sponsor for your work?
> if you have any spare time, I've been trying to get the finalized
> OpenCPN package sponsored by someone for almost a year.. (ITP# 538067)
Uhmm! That's a real shame. My main point behind the Blends concept was
to create teams inside Debian who work together in specific user
interests. This fact proves somehow my suspicion that this idea is not
fully implemented in Debian GIS. To stick to my word from regarding
"Sponsering of Blends" I see that both criterions are fullfilled:
and so here I am having a look:
$ uscan --verbose --force-download
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
-- Found the following matching hrefs:
Newest version on remote site is 3.2.0, local version is 2.5.0+dfsg
(mangled local version number 2.5.0)
=> Forcing download as requested
-- Downloading updated package OpenCPN-3.2.0-Source.tar.gz
I just want to know whether upstream has just moved forward over this
longish (and admittedly frustrating time for you) or whether you
intentionally decided to package 2.5.0. I would not question the later
because I admit I'm not that deep into GIS to know the differences but
before I go on sponsering I want to make sure I'll grab the right
Moreover you have injected a +dfsg suffix that lets me assume you are
repackaging upstream tarball for some reason. Usually this is
accompanied by some get-orig-source target in debian/rules to enable
others reproducing this step. If it is simply about removing some files
you might like to follow the uscan enhancement I proposed which does
simplify this process for the developer and makes it more transparent.
As far as I can see (at least from downloading 3.2.0 source) the "binary
without source" in wxWidgets should be removed. Reading #538067 log it
seems that the "images without license" issue might be solved - but I
have not yet inspected the tarball deeply.
I also noticed that you have put some MD5SUM files into the tarballs
directory in SVN. Please note that it is close to impossible to have
MD5SUM identical tarballs when changing anything in a tarball. (There
was some relevant discussion on firstname.lastname@example.org.) In other words:
Somebody who re-runs your (to be provided) get-orig-source target will
get a different MD5SUM (even if the untared dirs are byte identical).
In short: If you want your sponsor using the same tarball as you it is
better to provide a link or use mentors.debian.net. I for myself
(and in Debian Med team in general - Debian GIS might be different)
prefer a recipe who to recreate the tarball.
Regarding your packaging:
I have read in the log of #538067 you were advised to remove third party
Just for the record: I do not fully support this way because the
package will fail to build twice in a row because of the removed files.
So the cleanest way would be to move the files in
override_dh_auto_configure: out of the way and restore them if needed
in override_dh_auto_clean:. I will not insist on this nitpicking,
just mentioning it.
I noticed your commented flags to enable hardening. IMHO you could
safe a lot of this stuff by using debhelper compat level 9 which
cares for hardening automatically.
I was able to build the package with no lintian issues (except
hardening) and if you confirm the proper version you want me to sponser
I would have a more detailed look.
> I'd pretty much given up trying until the release freeze was over,
> the fastest option was looking like me going through the DD process
I wished people would not have a reason to give up. Becoming a DM
(first DM than DD) is a good idea anyway.