ubuntugis team mailing list archive
-
ubuntugis team
-
Mailing list archive
-
Message #00018
Re: Ubuntu-GIS - how to help?
Cameron Shorter wrote:
> Thanks Alan,
> Your answers are really helping me get up to speed.
> I want to capture some of this in the wiki.
> Comments inline ...
>
> Alan Boudreault wrote:
>> Cameron Shorter wrote:
>>
>>> Alan Boudreault wrote:
>>> <snip>
>>> Open questions for me:
>>> * What are the deadlines for getting packages into the various
>>> Debian/Ubuntu repositories?
>>>
>> I don't think deadlines are very important. We just do the job as soon
>> as we have time to do it.
> Deadlines are not important if you are working on this project in your
> spare time, but they are important in the business world when what you
> are trying to achieve are linked business milestones.
> Eg: Like many on these OSGeo lists, LISAsoft has a business based
> around integrating Open Source Geospatial with other systems. So it is
> in our interests to see Open Source promoted at high profile events
> like FOSS4G (Oct 2009). There will be a LiveDVD built for FOSS4G, and
> the best way to build a LiveDVD is from .deb files, and even better,
> from Ubuntu universe so delegates can go home and try it out on their
> Ubuntu system.
>
> So if I want to have my favorite package in the LiveDVD, or in Ubuntu
> universe for FOSS4G, when do I need to have it packaged by? Once we
> know this date, we can go to the key package owners and encourage them
> to get their projects packaged in time.
I don't know exactly when Ubuntu synchronize packages with those of
Debian unstable. I'd suggest you to go on IRC-freenode: #ubuntu-motu to
ask.
>
>
>> I want to clarify something: i don't really
>> care about the real ubuntu packages status because it will always be out
>> of date. Ubuntu packages are always synced with the debian unstable ones
>> by the Ubuntu maintainers. That's why i prefer to work in parallel with
>> DebianGIS AND upload lastest packages in our ubuntugis repository (on
>> lauchpad). This repository is not related to Ubuntu but will be the
>> official UbuntuGIS repository for those who need up-to-date packages.
>>
> Excellent. That is just the sort of information I was trying to work
> out, and we need to explain on our Ubuntu wiki. Can you please expand
> on this process. Is it:
>
> 1. Extract tar.gz from project's download URL.
> 2. Copy into http://svn.debian.org/wsvn/pkg-grass/packages
> 3. Build .deb release
Ok! 3.1 ENSURE that the package is perfectly built :)
> 4. copy .deb into Debian Unstable (where and how?)
No, we don't have access to commit anything (for the moment) on
DebianGIS. I normally create a bug with the Debian BTS and attach the
patch which is the update of all files in "/theProject/debian"
directory. Someone in DebianGIS will take this patch, test it with the
new upstream and commit in "experimental or unstable".
> 5. optional: Package a latest UbuntuGIS
I don't think it's an optional step. We should do it for both (Debian
and Ubuntu). But for our UbuntuGIS, we will simply upload the packages
in the Launchpad PPA and their system will build the package for us.
(The step 1, 2, 3 and 3.1 should be done locally, off course)
>
> 5.1 copy to UbuntuGIS subversion repository (where?)
I don't know yet... but i'd suggest to just use the bazaar one offered
by Launchpad.
> 5.2 store in a .deb download URL (where?)
We don't need that. We have a ubuntu repository. The .deb will be on
Launchpad server.
> 6. Ubuntu maintainers will copy from debian unstable to next ubuntu
> release
>
>>> * What is the upstream status and versions of all the Ubuntu packages?
>>> How should we maintain this information? (This should be shared
>>> between DebianGIS and UbuntuGIS).
>>>
>> About the upstream status, isn't your thermometer what is actually
>> doing?
>>
> The script automatically extracts the status of packages in debian and
> ubuntu releases.
> What is going to be harder to maintain is the latest release of each
> project because it hasn't been aggregated anywhere.
The only thing i see at the moment is to make a script that will check
every */debian/changelog file of our bazaar repository. Theorically, the
first line is alwas something like:
libparse-debianchangelog-perl
<http://packages.debian.org/src:libparse-debianchangelog-perl>
(1.0-1) unstable; urgency=low
and version is always between ().
>
>
>>> * How should we track issues and status of packaging?
>>>
>> We will need a BTS for sure... we could begin with the lauchpad one. But
>> again, we need a private lauchpad ;)
>>
> ok, I've been doing a lot of reading on launchpad. Seems like a good
> thing if all projects are using launchpad. Unfortunately Debian
> doesn't use launchpad.
>
> Note: issues raised in Ubuntu can't be pushed back to the Debian issue
> tracker.
> Should we consider migrating DebianGIS over to launchpad?
>
It's not very important if DebianGIS use launchpad or not. I'm not sure
to understand the why... ?
>>> * What versioning system should we use?
>>>
>> Lauchpad offers a free Git repository (i think).
> Launchpad apparently uses bazaar rather than git. It seems that bazaar
> can synchronize with svn and cvs repositories, which could be good for
> importing upstream libraries.
>
>
That's good.
>
>> Even if i'm absolutly
>> not familiar with Git.. if we don't have any place to setup a SVN on, we
>> can use the git.
>>
>>> A very high value contribution would be to package one of the java GIS
>>> packages as this has not been done yet and will help open up the whole
>>> java stack to packaging.
>>> Ladon Blake, this might be something you would be interested in, by
>>> packaging Open JUMP?
>>>
>>> <snip>
>>>
>>
>> Alan
>>
>>
>
>
--
Alan Boudreault
Mapgears
http://www.mapgears.com
References