[Debian-med-packaging] would like some help getting started

[Mike Dupont]

Well the source code of the GTM code for the XAPI is here
https://github.com/fosm/xapi it is from 80n and licenced under the AGPL. I
am learning the code and trying to help maintain it.

I am interested in packaging that as a debian package once we have the GTM
as a basis.

About the fork, well I dont want to go into to much detail, but lets put it
this way, the fosm project is to maintain the huge amount data that will be
lost after the re licensing and for people who would like to continue
business as usual to continue with the same well understood cc-by-sa
license.

I am interested in the technical aspects, and want to create tools for
dealing with GIS data in a distributed manner. I think that GT.m is a great
tool for doing so and am looking forward to people able to run many
different gtm nodes that work together. Ideally we wont need to have a big
central monolithic servers like what is being done with current railsport
and mapnik solution.

thanks
mike

On Thu, Mar 15, 2012 at 1:41 PM, Andreas Tille <andreas at an3as.eu> wrote:

> Hi Mike,
>
> On Thu, Mar 15, 2012 at 11:59:02AM +0100, Mike Dupont wrote:
> > Thanks,
> > I have already given a patch to luis, and have been able to compile his
> > code.
>
> Great.
>
> > a little background, I am working on fosm.org
>
> Ahhh, OSM fork.  While I also use OSM for navigation and provided some
> data to OSM I wonder what the motivation of forking OSM might be (but
> please answer in private to this question to not blur this list with OT
> stuff).
>
> > which is using gt.m for the
> > geo data server.
> > https://github.com/fosm/FOSM-Gt.m-extractor I have built a simple json
> api
> > server using perl and a command line gtm c program.
>
> I was not aware that FOSM is using GT.M.  Is this also true for OSM?
> I'm just asking because there is also a Debian GIS Blend (unfortunately
> not that strictly maintained like Debian Med, but I'd love to support
> this as well a bit) and once we might have packaged GT.M you might like
> to include GIS related software depending from fis-gtm straight into
> Debian under the umbrella of Debian GIS team.  I'd really welcome and
> support this.
>
> > I am really interested in learning more about this gtm and will be
> reading
> > the mails as you have given me, thanks
>
> Please be warned: They are longish and very verbose about some packaging
> issues definitely not specific for fis-gtm packaging.  In case you are
> losing patience over it try to concentrate on getting the cmake build
> work properly and the build will become way more easy - so perhaps there
> is no real need to read them all.  The interesting bits are in those
> mails were we are discussing strategic issues like when we turned from
> the initial plan
>
>  1. build a bootstrapping package first and use this to do the
>     final packaging over
>
>  2. Try to avoid the bootstraping process by delivering the files
>     needed as a patch for the downloadable source and finally
>     ending up in
>
>  3. Rewrite the build system with cmake.
>
> If you mind reading these mails and ignore those mails discussing
> details about plain packaging issues with debuild/pdebuild, lintian etc.
> this could be quite helpful to hear another opinion.
>
> Kind regards and to say it again: I'm very happy to have another helper
> to finally get fis-gtm packaged
>
>      Andreas.
> --
> http://fam-tille.de
>



-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20120315/f653a610/attachment.html>