Bug#538067: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Andreas:
> 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.
I think the main issue is lack of manpower. Frankie can't
do it all alone. Working on Blends seems like a bonus activity
to me, but there are too many fires to put out and worry about
right now so it doesn't get the attention it might otherwise.
shrug
> and so here I am having a look:
>
> $ uscan --verbose --force-download
...
> 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.
2.5.0 was the new stable version which Anton and me focused on
packaging. OpenCPN has had crazy success (check the SourceForge
download stats, it's not VLC but for a niche software it's doing
15k+ downloads a month)
http://sourceforge.net/projects/opencpn/files/opencpn/stats/timeline?dates=2009-04-10+to+2013-04-19
AFAIK the 2.5.0 package we made is pretty much complete and ready
to go. As mentioned in the last messages of the bug report, I'd
like to get 2.5.0 in as the baseline, and then proceed from
there. 2.5.0 was a really good solid release. In fact I'm
still using it as my day-to-day since it 'just works' for
everything I need to do with it.
The newer versions add OpenGL support and other changes which
mean more work, dependencies, etc. I'd like have 2.5.0 as a
solid delta before destabalizing the packaging effort over that.
The "it's ready as-is now" thinking also makes me a bit anxious
to get it reviewed before sid starts moving quickly and there's
external breakage to deal with, resetting the clock to zero,
again.
> before I go on sponsering I want to make sure I'll grab the
> right package.
In the ITP report I provide the link to the dfsg tarball dir
(hosted on was-alioth) and a link to the debian/ packaging rules
(hosted in DebianGIS's svn on was-alioth). I'm still aiming
at the same version.
> Moreover you have injected a +dfsg suffix that lets me
> assume you are repackaging upstream tarball for some reason.
as noted in the ticket, the original tarball had Microsoft's
Visual C++ runtime redistributable DLLs in it. we don't use that
but Debian can't host a source package containing it.
So that and IIRC some Mac OSX specific stuff got removed.
> If it is simply about removing some files you might like to
> follow the uscan enhancement I proposed[1] which does
> simplify this process for the developer and makes it more
> transparent.
ok, will look into it, but a job for tomorrow. :) (or next week,
I'm just about to jump on a boat)
> As far as I can see (at least from downloading 3.2.0 source)
(I'm still aiming for 2.5.0 for now)
> the "binary without source" in wxWidgets should be removed.
I'm not sure if that's in the 2.5.0+dfsg tarball I prepared,
I'd be rather surprised if it was. (a public script creates that
the tarball (and the md5sum) the way, I think it's on the alioth
site, somewhere. I'm all about the automation..)
> Reading #538067 log it
> seems that the "images without license" issue might be
> solved - but I have not yet inspected the tarball deeply.
AFAIK all known issues were solved. IIRC the images were by
the author and he was responsive in our copyright cleanup
tasks, fixing many of the issues upstream for the then-next 3.0
release.
> 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.
IIRC, I did that to provide some sort of audit trail for edits
to the md5sums, since the tarball downloads (not in svn) were
in a dir which was writable by many more people, with just
the filesystem stat to know who replaced the file there last.
> In short: If you want your sponsor using the same tarball as
> you it is better to provide a link[2] or
> use mentors.debian.net.
We did upload it to mentors. Twice. It just sat there. Too
complicated I guess..
> I for myself
> (and in Debian Med team in general - Debian GIS might be
> different) prefer a recipe who to recreate the tarball.
It's there somewhere hiding in plain sight, sorry I'm out of
time now or I'd hunt down the link.
> Regarding your packaging:
> debian/rules:
> I have read in the log of #538067 you were advised to remove
> third party code in
> override_dh_auto_configure:
>
> 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.
I'm pretty sure the result was multi-entrant. (was doing many
iterations of testing, and I'm pretty sure I would have made
it so if it was a problem. easy enough to add a if [ -e ..] ; rm)
No time left today to check right now.
> 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'll have a look. The hardening rules came in after we thought
we were ready for upload, so was a last minute addition.
> 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.
(2.5.0, thanks)
> > 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 myself.
>
> I wished people would not have a reason to give up.
that it didn't get a second upload before the wheeze freeze was
a bit sad for us. In all fairness we did get a first upload
and review by the ftp masters who noticed a few problems.
> Becoming a DM (first DM than DD) is a good idea anyway.
whatever works.
regards,
Hamish
Reply to: