launchpad development|
Size: 1374
Comment:
|
Size: 3555
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| As mentioned on [[Getting]], Launchpad is not currently supported on Ubuntu Karmic Koala, primarily because it currently has a hard dependency on Python 2.4, which is no longer included in Karmic. | This page is a place to collect notes written for and by people living on the bleeding edge and developing Launchpad on Karmic. |
| Line 3: | Line 3: |
| This page is a place to collect notes written for and by people living on the bleeding edge and attempting to get Launchpad working on Karmic / Python 2.5 | It has also become slightly co-opted as a place to manage the migration towards compatibility with the newer Python versions which Karmic prefers by default. |
| Line 5: | Line 5: |
| == launchpad-dependencies == First, there is the issue that the ~launchpad PPA doesn't have any packages for Karmic. I (maxb) have tweaked the launchpad-dependencies package to have a first approximation of suitable dependencies for Python 2.5, and uploaded it to my PPA [[https://launchpad.net/~maxb/+archive/ppa]], and copied the geoip-data-city-lite package from the ~launchpad PPA there as well for convenience. |
See also the PythonMigrationStatus for information on running Launchpad on Python 2.5 and 2.6. |
| Line 8: | Line 7: |
| == Launchpad code itself == https://code.launchpad.net/~maxb/launchpad/python2.5 contains a few fixes: * Adjusting the Python version in the Makefiles * Adjusting import statements to handle the built-in location of cElementTree in Python 2.5 |
= PPA Dependencies = The [[https://launchpad.net/~launchpad/+archive/ppa|Launchpad PPA]] now contains a complete set of packages for the Karmic series. |
| Line 13: | Line 10: |
| == Launchpad source dependencies - Zope == https://code.launchpad.net/~maxb/zope3/launchpad-3.4-py2.5 contains backports of some changes to zope.proxy and zope.security in post-3.4 Zope releases which are required for Python 2.5 compatibility (possibly only on 64-bit architectures). Without these, Launchpad produces perplexing MemoryErrors. |
= Launchpad on Karmic with Python 2.4 = It works pretty much, but there's an unresolved issue wherein setuptools' way of supporting Python namespace packages tends to leave you using the lazr.* packages installed into the system site-packages directory, despite the Launchpad buildout's best efforts. This manifests as the following test failures: * Problems importing `lazr.enum`: * lp.codehosting.puller.tests.test_scheduler.!TestPullerMasterIntegration.test_mirror * lp.codehosting.puller.tests.test_scheduler.!TestPullerMasterIntegration.test_mirror_with_destination_self_locked * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_hosted_branch_stacked_on_mirrored_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_manual_stacking * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_mirror_hosted_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_mirror_hosted_loom_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_mirror_imported_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_mirror_mirrored_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_mirror_private_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_remirror_hosted_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_stack_mirrored_branch * lp.codehosting.puller.tests.test_acceptance.!TestBranchPuller.test_stack_mirrored_branch_onto_private * lp.services.scripts.tests.test_all_scripts.!ScriptsTestCase.test_scripts * Unicode vs. bytestring issues: * eggs/launchpadlib-1.5.1-py2.4.egg/launchpadlib/docs/people.txt * eggs/launchpadlib-1.5.1-py2.4.egg/launchpadlib/docs/toplevel.txt Workaround: Remove the symlinks at `/usr/lib/python2.{4,5}/site-packages/lazr.*-nspkg.pth` and trust to the fact that Karmic's default Python is 2.6 to hopefully not break anything on your system that wanted to use them. = Problems = barry has found that `make schema` is flakey. Occasionally I'm getting these errors: {{{ make -C database/schema make[1]: Entering directory `/home/barry/projects/launchpad/devel/database/schema' $user,public,ts2 * Using launchpad-2109-00-0.sql as baseline * If this fails you need to run as the postgresql superuser * eg. sudo -u postgres make create * Creating database "launchpad_empty". Giving up waiting for connections to template1 to drop. 1 connections by postgres to template1 make[1]: *** [create] Error 10 make[1]: Leaving directory `/home/barry/projects/launchpad/devel/database/schema' make: *** [schema] Error 2 }}} Note that the `sudo` command has to be run from `database/schema` but does not seem to help. Note too that sometimes `/etc/init.d/postgresql-8.3 restart` fixes the problem, but not always. maxb says: Surely the answer is simply to find what's maintaining the open connection and stop it? |
This page is a place to collect notes written for and by people living on the bleeding edge and developing Launchpad on Karmic.
It has also become slightly co-opted as a place to manage the migration towards compatibility with the newer Python versions which Karmic prefers by default.
See also the PythonMigrationStatus for information on running Launchpad on Python 2.5 and 2.6.
PPA Dependencies
The Launchpad PPA now contains a complete set of packages for the Karmic series.
Launchpad on Karmic with Python 2.4
It works pretty much, but there's an unresolved issue wherein setuptools' way of supporting Python namespace packages tends to leave you using the lazr.* packages installed into the system site-packages directory, despite the Launchpad buildout's best efforts.
This manifests as the following test failures:
Problems importing lazr.enum:
lp.codehosting.puller.tests.test_scheduler.TestPullerMasterIntegration.test_mirror
lp.codehosting.puller.tests.test_scheduler.TestPullerMasterIntegration.test_mirror_with_destination_self_locked
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_hosted_branch_stacked_on_mirrored_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_manual_stacking
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_mirror_hosted_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_mirror_hosted_loom_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_mirror_imported_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_mirror_mirrored_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_mirror_private_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_remirror_hosted_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_stack_mirrored_branch
lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_stack_mirrored_branch_onto_private
lp.services.scripts.tests.test_all_scripts.ScriptsTestCase.test_scripts
- Unicode vs. bytestring issues:
- eggs/launchpadlib-1.5.1-py2.4.egg/launchpadlib/docs/people.txt
- eggs/launchpadlib-1.5.1-py2.4.egg/launchpadlib/docs/toplevel.txt
Workaround: Remove the symlinks at /usr/lib/python2.{4,5}/site-packages/lazr.*-nspkg.pth and trust to the fact that Karmic's default Python is 2.6 to hopefully not break anything on your system that wanted to use them.
Problems
barry has found that make schema is flakey. Occasionally I'm getting these errors:
make -C database/schema make[1]: Entering directory `/home/barry/projects/launchpad/devel/database/schema' $user,public,ts2 * Using launchpad-2109-00-0.sql as baseline * If this fails you need to run as the postgresql superuser * eg. sudo -u postgres make create * Creating database "launchpad_empty". Giving up waiting for connections to template1 to drop. 1 connections by postgres to template1 make[1]: *** [create] Error 10 make[1]: Leaving directory `/home/barry/projects/launchpad/devel/database/schema' make: *** [schema] Error 2
Note that the sudo command has to be run from database/schema but does not seem to help. Note too that sometimes /etc/init.d/postgresql-8.3 restart fixes the problem, but not always.
maxb says: Surely the answer is simply to find what's maintaining the open connection and stop it?
