Hi Hamish,
On Fri, Apr 19, 2013 at 07:02:29AM -0700, Hamish wrote:
> > 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.
ACK.
> Frankie can't
> do it all alone.
Fully ACK. Same was for me in Debian Med so I actively cared for
convincing people to join. If you want to see some graphs that
show this you might like to compare:
http://debian-med.debian.net/
http://blends.debian.net/gis/
In the Debian Med case you notice that the discussion between several
people leads to an increase of people who are doing actual work (VCS
commits, Uploads, bugs closed). In Debian GIS there is not so much
discussion (explaining, inviting newbies etc.) which leads to the fact
of a very few and actually very busy people. So because Frankie can
not do it all alone (and I admit he does a great job) people could
assist him in inviting newcomers to increase the team.
> 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
IMHO the numbers prove you wrong that Blends activities are a bonus but
rather a precondition to attract more people. I consider Free Software
in medicine as *way* *less* populated than GIS - so if we even succeed
to attract a strong team here - why shouldn't this work for GIS? Not
caring for the number of people and than using the excuse that you are
only a few people does not sound very logical to me.
> 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.
OK, lets stick to 2.5.0 for the moment - perfectly fine for me.
> > 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.
I've got the tarball from there.
> > 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.
Fine - but just looking at the debian/ dir undocumented.
> > 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)
Not particularly needed - just a hint to simplify things.
> > As far as I can see (at least from downloading 3.2.0 source)
>
> (I'm still aiming for 2.5.0 for now)
OK.
> > 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..)
I've seen the script in SVN you are mentioning in your other mail - but
we shold formalise this *inside* the debian/ dir. I'm fine if you call
this script inside a get-orig-source target.
> > 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.
OK.
> > 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.
That's why I would like to recreate directly from upstream tarball to
control the download process myself.
> > 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..
OK, did not checked mentors because it was not mentioned in the bug
report.
> > 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.
Just take your time.
> > 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.
Well, it changes the directory content compared to the tarball. Usually
debuild does not like this. It is fine with pbuilder who is working on
a copy.
> > 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.
Hardening is no hard criterion for letting me sponsoring. However,
enabling it if it comes cheap it does not harm.
> > 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.
Any link to the rejection mail to verify that we do not bother them
twice with the same problem?
> > Becoming a DM (first DM than DD) is a good idea anyway.
>
> whatever works.
IMHO DM and afterwards DD is the usual procedure.
Kind regards
Andreas.
--
http://fam-tille.de