Open GoogleCodeExporter opened 9 years ago
pyChess is a Python project that is listed in the Ubuntu package manager, I
guess we
could ask them how they did it...
Original comment by heldersepu
on 15 Oct 2009 at 2:15
Attachments:
pi3orama created a bug on lauchpad:
https://bugs.launchpad.net/ubuntu/+bug/452190
help should be on the way!
Original comment by heldersepu
on 15 Oct 2009 at 2:32
An Ubuntu volunteer is called to do the work.
1. adjusts the GMapCatcher package to meet the debian requirement:
https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage
2. package GMapCatcher:
https://wiki.ubuntu.com/PackagingGuide/Basic
3. Upload the package to Ubuntu (How to upload?)
4. Wait for an Ubuntu archive team member to review it.
Original comment by pi3or...@gmail.com
on 15 Oct 2009 at 3:05
We are going to need an icon, we could start from this one
Original comment by heldersepu
on 20 Oct 2009 at 8:25
Attachments:
sounds worthwhile; it seems I should already have dpkg-deb plus friends, so
I'll see what that leads to :-)
One aspect to think of when involving the project in the occasionally slow
business of package approvals, is some way of quickly changing url patterns
without changing the code version - a pattern list wiki file similar to the
version wiki file could be the way to manage that
Original comment by Mark111...@gmail.com
on 15 Jul 2010 at 12:29
Original comment by Mark111...@gmail.com
on 15 Jul 2010 at 5:59
now at debian - quicker approval / virtually a superset of ubuntu packages
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589254
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 6:57
so it's looking good;
I need as many people as possible to test the .deb at
http://gmapcatcher.googlecode.com/svn-history/r901/trunk/mapcatcher_0.7.2.0-1_al
l.deb
please,
so as to give ourselves a good name at debian :-)
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 12:25
Testing in a virtual machine
OS = Kubuntu 8.04.1
Getting Error: Dependency is not satisfiable: python
But I'm able to run it directly from the sources
Original comment by heldersepu
on 16 Jul 2010 at 12:54
Attachments:
from the looks of it 8.04 - hardy - is python 2.5, although it may be 2.5.2
http://packages.ubuntu.com/hardy/python/python
should we change our minimum python version to 2.5?
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 1:02
It installs in Ubuntu 10.04
Original comment by heldersepu
on 16 Jul 2010 at 1:08
Attachments:
I'm looking at how to upload the .deb, it seems the main hurdle is authorization
http://wiki.debian.org/DebianMaintainer
do we know people who know people? :-)
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 1:13
one more resource that could be of assistance
http://revu.ubuntuwire.com/
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 2:08
Testing in Debian5...
debian:/home/user/Desktop# dpkg -i mapcatcher_0.7.2.0-1_all.deb
Selecting previously deselected package mapcatcher.
(Reading database ... 69877 files and directories currently installed.)
Unpacking mapcatcher (from mapcatcher_0.7.2.0-1_all.deb) ...
dpkg: dependency problems prevent configuration of mapcatcher:
mapcatcher depends on python (>= 2.6); however:
Version of python on system is 2.5.2-3.
mapcatcher depends on python-support (>= 0.90.0); however:
Version of python-support on system is 0.8.4.
dpkg: error processing mapcatcher (--install):
dependency problems - leaving unconfigured
Processing triggers for man-db ...
Errors were encountered while processing:
mapcatcher
debian:/home/user/Desktop#
Original comment by heldersepu
on 16 Jul 2010 at 2:18
Downloaded all the sources in Debian5 and it's working properly, maybe we
should put Python >= 2.5 & python-support >= 0.8.4
Original comment by heldersepu
on 16 Jul 2010 at 2:24
Attachments:
again, Lenny - debian 5 - is debian stable, we're thinking of debian unstable;
it would potentially be possible to change the deps, although that may need
more in-depth testing
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 2:27
so the bug report at http://code.google.com/p/gmapcatcher/issues/detail?id=149
that seems to say hardy's 2.5 causes errors may be ignored?
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 3:00
it should be said that it looks as though that particular grammar has gone from
the project for now; so we'll say 2.5 then - may lead to more testing when the
code is improved although I seem to think testing makes you happy :-)
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 3:06
let's keep lenny happy at least :-)
http://gmapcatcher.googlecode.com/svn-history/r905/trunk/mapcatcher_0.7.2.0-1_al
l.deb
see how that works
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 3:34
Yes, I guess that Issue 149 can be safely ignored, the Linux machine that I've
been testing all along is using Python 2.5, the same one from my very first
Screen-shot.
Any specific scenarios that I should retest?
Original comment by heldersepu
on 16 Jul 2010 at 3:34
well aside from the occasional faults from the download window that are mainly
an independent matter, I'd say it should mostly be self-evident;
it looks as though calling mapcatcher from the menu should be similar to
calling it directly;
worthwhile moving your .googlemaps to check all the config is working properly
from fresh;
I've not tested download.py - mapdownloader - really at all
try to uninstall then reinstall so we're clear the version number of
python-support is unimportant
those would be my suggestions :-)
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 3:42
I notice hardy's python-support is 0.7.5
http://packages.ubuntu.com/hardy/python/python-support
so worthwhile trying
http://gmapcatcher.googlecode.com/svn-history/r906/trunk/mapcatcher_0.7.2.0-1_al
l.deb
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 3:50
:(
dpkg: dependency problems prevent configuration of mapcatcher:
mapcatcher depends on python-support (>= 0.8.4); however:
Version of python-support on system is 0.7.5ubuntu1.
Original comment by heldersepu
on 16 Jul 2010 at 3:56
I'm ahead of you there :-D
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 3:59
Yes I guess we are working at the same time & did not refresh the page
Original comment by heldersepu
on 16 Jul 2010 at 4:04
my guess is that the reason is that it's installed directly from a .deb rather
than from a repo - it wouldn't appear in synaptic for instance - although the
'Ubuntu software center' seems to have hidden itself from my desktop :-)
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 5:33
found it :-)
it looks reasonably clear the software center is organised according to
software repos / sources found in /etc/apt/sources.list so when debian approve
us we'll appear there
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 5:44
Attachments:
Bad News! testing in Debian5 I can not install the package
debian:~/Desktop/Downloads# dpkg -i mapcatcher_0.7.2.0-1_all.deb
Selecting previously deselected package mapcatcher.
(Reading database ... 68968 files and directories currently installed.)
Unpacking mapcatcher (from mapcatcher_0.7.2.0-1_all.deb) ...
Setting up mapcatcher (0.7.2.0-1) ...
Usage: update-python-modules [-v] [-c] package_directory [...]
update-python-modules [-v] [-c] package.dirs [...]
update-python-modules [-v] [-a|-f|-p]
update-python-modules: error: /usr/share/python-support/mapcatcher.public is
not a directory
dpkg: error processing mapcatcher (--install):
subprocess post-installation script returned error exit status 2
Processing triggers for man-db ...
Errors were encountered while processing:
mapcatcher
debian:~/Desktop/Downloads#
After that the icon gets created but it does run, and if I try to uninstall, I
get something similar...
debian:~# dpkg -r mapcatcher
(Reading database ... 69064 files and directories currently installed.)
Removing mapcatcher ...
Usage: update-python-modules [-v] [-c] package_directory [...]
update-python-modules [-v] [-c] package.dirs [...]
update-python-modules [-v] [-a|-f|-p]
update-python-modules: error: /usr/share/python-support/mapcatcher.public is
not a directory
dpkg: error processing mapcatcher (--remove):
subprocess pre-removal script returned error exit status 2
Usage: update-python-modules [-v] [-c] package_directory [...]
update-python-modules [-v] [-c] package.dirs [...]
update-python-modules [-v] [-a|-f|-p]
update-python-modules: error: /usr/share/python-support/mapcatcher.public is
not a directory
dpkg: error while cleaning up:
subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
mapcatcher
debian:~#
Original comment by heldersepu
on 16 Jul 2010 at 6:53
that'll be python-support; so it looks as though there's a reason debuild was
adding 0.90
Original comment by Mark111...@gmail.com
on 16 Jul 2010 at 6:57
looking into it further it looks as though we'll need 2 .deb versions; one
should be built in debian unstable to add to the repos - then kept up to date;
one should be for legacy systems, built for instance from hardy, kept as a
download from the website; although it *may* be possible to build from hardy
for maverick/squeeze, it's looking as though it'll need 2 distinct .debs; watch
this space! :-)
Original comment by Mark111...@gmail.com
on 18 Jul 2010 at 4:58
all sorted now; version 0-0 should be right for hardy/lenny, while 0-1 works
for the more recent distributions;
now to try to arrange debian approval
Original comment by Mark111...@gmail.com
on 19 Jul 2010 at 9:49
right, so debian is in progress
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=mapcatc
her
http://mentors.debian.net/debian/pool/main/m/mapcatcher/
Original comment by Mark111...@gmail.com
on 19 Jul 2010 at 1:45
right so it looks as though we're making progress at least :-)
there's an incipient legal discussion at
http://lists.debian.org/debian-legal/2010/07/msg00034.html - plus follow-ups -
that's worth your while to make such comments as you feel appropriate
the main request for sponsorship is at
http://lists.debian.org/debian-mentors/2010/07/msg00271.html plus follow-ups;
most messages are now being cross-posted; so chip in :-)
Original comment by Mark111...@gmail.com
on 21 Jul 2010 at 4:48
Hi,
I tried to contact the authors by email, but no luck, so lets try here :)
I've proposed a package at the above ITP :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589254
And requested a sponsor here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709547
I've stripped out all the things that should cause problems with debian's legal
process. In the process I seem to have broken the oneDirPerMap == 0 option.
I've also had to do a lot of component and web-service replacements.
Anyway, I would like to know if you (the authors) had some comments on the
packaging.
Original comment by debian.m...@gmail.com
on 25 May 2013 at 1:24
Hello debian.mapcatcher
I'm sure "debian's legal process" will complain about the fact that it has a
different name (mapcatcher) when the application is GMapCatcher.
You might want to add a patch with all "stripped things" so we can review it
and see why the oneDirPerMap is broken.
Original comment by heldersepu
on 25 May 2013 at 1:31
Hi!
I must admit the package naming was not clear to me - I just named it after the
latest tarball and main python script "mapcatcher". This can be changed with
relative ease.
I've attached the patch that is the difference between the 0.8.0.0 tarball, and
the debian ".orig.tar.gz" as used to populate the above git repository. The
dynamically applied patches (applied during the build), are located in the
debian/patches folder of the git archive link I posted before.
Some (much?) of these alterations could be moved into a dynamically applied
patch. A few things, like the cloudmade key, probably can't. For ease of
trying to get the program into debian, I outright removed mapdownloader and
removed map providers who don't have a clear free licence that I can find. Ive
also stripped pyGPSD, as this is already packaged in debian.
The dynamic patching does things like adds geonames searching, and removes the
non-free LRU cache (I replaced LRU with a free one), and adds open transport
map.
---
The following map providers have a policy that is incompatible with mapcatcher
(eg no GPS clauses (anyone who uses NAVITEQ data)) or no storage, or no bulk
download
- Eniro [http://www.esri.com/legal/third-party-data]
- Seznam [http://napoveda.seznam.cz/cz/mapy-licencni-podminky.html]
- Google search has a no non-google map data clause in their TOC.
[https://developers.google.com/maps/terms]
- Nokia has several clauses that forbid use.
[http://www.developer.nokia.com/Develop/Maps/TC.html], such as no integration
with vehicles, providing enhanced service, mashup or location plotting
- Yandex has a no-saving, no copying and no usage in traffic routing/control
clauses.
I'm unclear about these providers:
- Skyvector : I can't seem to locate licencing online. All I can find is a
quoted patent, and a hint that they will sell you their content.
[http://www.flightprep.com/rootpage.php?page=license,
http://skyvector.com/forum/%5Btitle-raw%5D-12 ]
- Information freeway "informationfreeway.org" seems to be querying the
openstreetmap tilesevers??
- Stamen's tileserver might be free, but I can't seem to find information on
the server itself - there's lots of info on the tiles though.
- Refuges info doesn't seem to work (on mapcatcher or online) - their
tileserver appears to be broken?
Thanks for the comment!
Original comment by debian.m...@gmail.com
on 26 May 2013 at 12:25
Attachments:
Original issue reported on code.google.com by
heldersepu
on 15 Oct 2009 at 2:06