[Launchpad-dev] RFC on build from branch UI
Hi all, I've been putting together some mockups for the build-from-branch UI work (with the help of jml, wgrant and mwhudson), and would love to hear ideas on how they could be improved or re-worked etc. You can see the details at: https://dev.launchpad.net/BuildBranchToArchiveUI The Balsamiq mockups are all available in a branch if you have some inspiration too :) (linked on the page). And there is a list of questions at the bottom of the page that may answer initial thoughts. Thanks in adavance, -Michael BTW: Working through the UI workflow with the current schema/code brought up a few bugs that we'll need to work on (or clarify as invalid), so if you think you might be able to clarify them: = Our current schema doesn't support scheduling of builds (ie. daily builds) = https://bugs.edge.launchpad.net/launchpad-code/+bug/515923 = We're not passing the recipe's source package name or suite through to dailydeb = https://bugs.edge.launchpad.net/soyuz/+bug/515918 = Recipe has sourcepackagename before upload = This one might be invalid - I just wasn't sure why we're not using the normal process of processing an upload to create a SPN (rather than potentially creating the SPN record for the recipe). https://bugs.edge.launchpad.net/launchpad-code/+bug/515581 ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Python2.6
On Feb 2, 2010, at 9:39 AM, Max Bowsher wrote: Muharem Hrnjadovic wrote: On 02/02/2010 03:32 AM, James Westby wrote: Beta 1 of lucid is scheduled for March 18th. That's the point at which we want to start widespread testing, and so would be a perfect target for launchpad to run on 2.6. That work is not scheduled for this date, for the reasons Muharem and Max said. I expect we'll be pursuing 2.6 about half-way through the year. My current thought is that we would switch to 2.6 in the same cycle that the data center would switch to Lucid, but maybe we want to divide up the changes for risk management. I need to coordinate with the LOSAs. I do agree that we should target having Launchpad runnable on Lucid by that date (and it sounds like maxb and wgrant have already done some or all of the necessary work). IIRC this was discussed extensively in Barcelona last year and the agreement was to include python2.5 in Lucid as well. Wasn't doko supposed to prepare a PPA that would facilitate the installation of python2.5 on Lucid systems? That was my understanding as well. I'm pretty sure it already exists, but I'm not sure where it is. python2.5 is already not a supported version in lucid, which means various python module packages are no longer built to support it. I'd assumed the python2.5 interpreter itself would remain in universe for lucid. As for the various module packages which have dropped support, between myself and wgrant, we already have the ~launchpad PPA for lucid up and running on this basis. Great to hear. Gary ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFC on build from branch UI
On Tue, Feb 2, 2010 at 10:01 AM, Michael Nelson michael.nel...@canonical.com wrote: You can see the details at: https://dev.launchpad.net/BuildBranchToArchiveUI Hi Michael, this looks great. I've gone through the document and have a few questions to raise. General impressions: - In target user audiences, I wonder why you left out Project maintainers. It seemed like one of the primary users for this. I'm also a bit confused as to whether the target audience is for people who will use the feature (the ones who will interact with the UI) or people who will benefit from this feature (this would just be people installing PPAs) - Reading through this document ah brought back the itching need to link PPAs to projects. Many things would be much easier! - It seems to me from the UI, that I won't be able to easily say build this every day in Lucid, Karmic, Jaunty and Hardy. I feel that's the way many people are using it today Manual build of the latest branch revision: - I understand it as as a one-off action, I think we should show what specific revision you're building, and maybe a link to it - I wonder why the packaging branch isn't something you can search for and change. IIRC, there are some advanced use cases where you use more voodoo, but the common case would be marvelously simple if you would just select a packaging branch to create a recipe - I'm not sure if start build is the right wording, as it may take hours to build :) Maybe just Build? - When you expand the recipe, it seems as though you can edit it right there. There's may be some confusion involved in whether you're just editing it for that build, or editing the recipe all together - I'm not sure what the # bzr-builder... text is above the textarea - The Need help creating a recipe? link would probably be useful in the unexpanded area - What's the UI for when I want to build but there are no recipes? I imagined that will be the first experience for everybody, so we should really nail that Daily builds: - I wonder if we could use a drop down instead of an expander with options like Build revision XXX and Build daily Phew, sorry it got long. I wanted to give a quick turnaround. cheers, -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] (spurious?) Failure on ec2: test_pottery_detect_intltool
I've tried to run lp:~salgado/launchpad/bug-515494 twice through ec2 and got identical failures on test_pottery_detect_intltool[1], which I can't reproduce locally. It seems to be failing because of a missing /usr/bin/intltool-update. Does anybody have any idea what's going on there? [1] http://paste.ubuntu.com/367691/ -- Guilherme Salgado salg...@canonical.com signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] (spurious?) Failure on ec2: test_pottery_detect_intltool
And it only fails when running the full test suite -- if I tell ec2test to run just the failing test, it passes. On Tue, 2010-02-02 at 14:46 -0200, Guilherme Salgado wrote: I've tried to run lp:~salgado/launchpad/bug-515494 twice through ec2 and got identical failures on test_pottery_detect_intltool[1], which I can't reproduce locally. It seems to be failing because of a missing /usr/bin/intltool-update. Does anybody have any idea what's going on there? [1] http://paste.ubuntu.com/367691/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp -- Guilherme Salgado salg...@canonical.com signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] The with statement
Barry Warsaw wrote: A common question is whether to use these to manage transactions. Jeroen and I have debated this one. It's worked well for me in my Storm-based non-Launchpad applications, but Jeroen doesn't like their semantics for this. I'll let him take it from there. I've got nothing against the keyword per se. The common, simple free my resource use-case will be convenient. Using it for that has my unreserved blessing. (Irrelevant gripes: it's a thin layer of sugar; it doesn't scale well for more than resource; cleanup requirements should be encapsulated in the type not the using code; phew, that's off my chest). My objections relate to how exception handling is designed into the protocol. It basically assumes that the code inside the with block is written to suit the resource's wishes, not the other way around. I would very much like us to stay away from any use of with beyond a substitute for finally. If that becomes impossible, we should figure out some very limited usage patterns that work well for us. The with blocks should always do something that we can understand and predict. The language does not enforce that, and I see that as a maintenance risk. Rant follows; most people will want to stop reading here. To me, the way the protocol deals with exceptions smells of over-specific design. An API like that can trick people into unnecessary complexity when they should be ignoring the extra knobs and dials. It's like the Unmount / Eject / Safely remove drive options in Nautilus: in theory they let you do it just right, but in practice it all depends on the specific device and you just get more ways to do it wrong. The justification for this design was transactions: it lets you write transaction classes don't need explicit commits or aborts, because they can see for themselves if the code block exits normally or with an exception. That is not a design I like. Maybe it's just because I'm Dutch, but commit should be explicit. That's your finish line. You may have separate exception handling around it depending on special needs in your code. Aborts can safely be implicit, partly because they shouldn't raise exceptions anyway, and you may want to do them even when no exception comes up. So the primary use-case is one that may seem sensible, but definitely not an approach I'd take. I'd go for an explicit commit; the with exit handler would abort if commit was not reached, regardless of exceptions. The design in the PEP makes the finish line invisible, but at the same time stakes everything on whether you cross that invisible line normally or by exception. And possibly the type of the exception. And possibly other details of the exception object. Or maybe it just inspects your call tree and figures out what it thinks you wanted. This adds a whole new dimension to a simple API that sits in your error-handling paths (traditionally the most numerous and least well-tested paths in an application) and that needs to be carefully designed and documented, not yet supported by documentation tools AFAIK, all justified by a doubtful use-case. And then on flip side of the coin, the with keyword also implicitly swallows or propagates exceptions, at the resource's discretion. Say you have a transaction manager that commits if your with block exits normally, or aborts if it raises. Now, what does this code do? with my_transaction_manager(): with some_resource(): foo() Will the transaction abort when foo() raises an exception? It also depends on the handler for some_resource, and how it feels about the exception. To deal with that properly, a resource should probably have custom exception types to signal different exit conditions to its own with handler. But even then: def foo(): with some_resource() as x: bar(x) def bar(x): with some_resource() as y: x.splat() y.splat() Say one of the splat()s raises a custom exception. How sure are you that it gets to the right cleanup? It could be handled by y, or by x and y both; the language doesn't say. Which behavior do you want? That depends on the code in foo and bar, but it's actually dictated by some_resource. It's up to some_resource to implement and document something sensible: handle-and-raise, handle-and-swallow, raise up to the handler for either x or y depending on which raised the exception and either swallow there or raise a different exception type, etc. Whatever it chooses to do may or may not be what you need in your particular piece of code. Actually the 3rd case is probably the most sensible, but the with API discourages that one compared to the other two. The author of some_resource may go with one of the easy options and come up with a better one later, breaking your code. So if you use the exception-handling parts of the protocol, with is basically an alias for multiple different control structures. It
[Launchpad-dev] ./utilities/update-sourcecode breaks if bzr-explorer is installed
For some strange reason, I could not run ./utilities-update-sourcecode with bzr-explorer installed. It would complain, telling me I needed QBzr even though that was also installed. Here is the output: jfana...@its-4l devel: ./utilities/update-sourcecode Sourcecode: ./sourcecode Config: ./utilities/sourcedeps.conf Bazaar Explorer requires QBzr. Please install it and try again. Removing bzr-explorer fixes this issue. I just wanted to note this in case anyone else has this problem, and also because it is a strange issue. Thanks. -- Jamal Fanaian ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] ./utilities/update-sourcecode breaks if bzr-explorer is installed
On 2 February 2010 17:29, Jamal Fanaian jamal.fana...@gmail.com wrote: For some strange reason, I could not run ./utilities-update-sourcecode with bzr-explorer installed. It would complain, telling me I needed QBzr even though that was also installed. Here is the output: jfana...@its-4l devel: ./utilities/update-sourcecode Sourcecode: ./sourcecode Config: ./utilities/sourcedeps.conf Bazaar Explorer requires QBzr. Please install it and try again. Removing bzr-explorer fixes this issue. I just wanted to note this in case anyone else has this problem, and also because it is a strange issue. Thanks. Please file a bug against https://launchpad.net/bzr-explorer Does standalone 'bzr' work ok? -- Martin http://launchpad.net/~mbp/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] (spurious?) Failure on ec2: test_pottery_detect_intltool
Am 02.02.2010 18:03, Guilherme Salgado schrieb: And it only fails when running the full test suite -- if I tell ec2test to run just the failing test, it passes. On Tue, 2010-02-02 at 14:46 -0200, Guilherme Salgado wrote: I've tried to run lp:~salgado/launchpad/bug-515494 twice through ec2 and got identical failures on test_pottery_detect_intltool[1], which I can't reproduce locally. It seems to be failing because of a missing /usr/bin/intltool-update. Does anybody have any idea what's going on there? Here is what's going on: I created a new ec2 image to include the new launchpad-developer-dependencies that pull in intltool. The new image has the number 114. In order for everybody else to be able to use my image I had to add my account to the list of valid accounts. That change went in together with the code that depended on the new image. Your local devel branch was not up-to-date, so ec2test did not use my new image while it still branched the latest devel to run the tests on. Solution: merge the latest devel and all is well. ;-) ec2test should now be using image 114. Background info on how to update the image for ec2: https://dev.launchpad.net/EC2Test/Image Henning ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Python2.6
On Feb 02, 2010, at 07:33 AM, Muharem Hrnjadovic wrote: IIRC this was discussed extensively in Barcelona last year and the agreement was to include python2.5 in Lucid as well. Wasn't doko supposed to prepare a PPA that would facilitate the installation of python2.5 on Lucid systems? Not quite. I remember the decision differently, and I'm verifying it here right now with doko and others at the platform sprint. Doko agreed to backport Python 2.6 to Hardy, which is what the DC runs now. The plan was to get Launchpad running on 2.6 on Hardy so that a dist-upgrade to Lucid would go smoothly (in that regard). We spent 3 engineers x 2 weeks trying to get Launchpad on 2.6 but only succeeded in getting us to 2.5, understanding that we would have to make another push before Lucid to get Launchpad on 2.6. The key thing I've learned here is that there's only about a month before we have to complete this work. Lamont tells me that the first DC machines will be upgraded to Lucid when it goes beta, in about a month. The main consideration for having at least one python interpreter version shared by Hardy and Lucid was to provide LTS customers with a migration path for their python applications. Right, but that Python version is going to be 2.6. There's consensus here that it's much better to support a backported PPA of 2.6 for Hardy than to put Python 2.5 back in Lucid. So, this is not just about Launchpad (although we do have a vested interest :) James checked with Jamu about Landscape. They're still on 2.5 but he apparently does not think getting to 2.6 is going to be difficult for them. I'm not sure about U1. If we shipped only python2.6 with Lucid: what would be the official Hardy-Lucid migration story for LTS customers? Start by porting to 2.6 on Hardy using the PPA before you upgrade to Lucid. -Barry signature.asc Description: PGP signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] [Fwd: Test results: FAILURE]
I received got these test failures, related to translations. can anybody give me a clue what's going on there? (I don't think that my branch messed with the affected code in any way...) Abel ---BeginMessage--- Tests started at approximately Tue, 02 Feb 2010 15:01:46 UTC bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/, revision 10248 Merged with bzr+ssh://bazaar.launchpad.net/~adeuring/launchpad/bug-172501, revision 10110 (commit message: trunk merged) DEPENDENCY BRANCHES USED - dulwich bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/dulwich/devel/ 415 - cscvs bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad-cscvs/devel/ 430 - bzr-hg bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/bzr-hg/devel/ 281 - mailman bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/mailman/2.1/ 976 - bzr-git bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/bzr-git/devel/ 249 - shipit bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/ 8901 - old_xmlplus bzr+ssh://bazaar.launchpad.net/~launchpad/dtdparser/trunk/ 4 - pygettextpo bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/pygettextpo/trunk/ 23 - subunit bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/subunit/trunk/ 61 - bzr-svn bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/bzr-svn/devel/ 2706 - launchpad-loggerhead bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad-loggerhead/devel/ 54 - pygpgme bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/pygpgme/devel/ 48 - bzr-loom bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/bzr-loom/trunk/ 47 - canonical-identity-provider bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/canonical-identity-provider/trunk/ 8901 - subvertpy bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/subvertpy/trunk/ 2040 - testresources bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/testresources/dev/ 16 - loggerhead bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/loggerhead/devel/ 174 - bzr-builder bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/bzr-builder/trunk/ 63 - lpreview bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/bzr-lpreview/devel/ 23 TEST RESULTS FOLLOW rm -f lib/canonical/launchpad/icing/build/launchpad.js rm -f -r lazr-js/build make -C sourcecode/pygettextpo clean make[1]: Entering directory `/var/launchpad/tmp/sourcecode/pygettextpo' rm -rf build dist gettextpo.so gettextpo.html make[1]: Leaving directory `/var/launchpad/tmp/sourcecode/pygettextpo' # XXX gary 2009-11-16 bug 483782 # The pygettextpo Makefile should have this next line in it for its make # clean, and then we should remove this line. rm -f sourcecode/pygpgme/gpgme/*.so if test -f sourcecode/mailman/Makefile; then \ make -C sourcecode/mailman clean; \ fi find . -path ./eggs -prune -false -o \ -type f \( -name '*.o' -o -name '*.so' -o -name '*.la' -o \ -name '*.lo' -o -name '*.py[co]' -o -name '*.dll' \) \ -print0 | xargs -r0 rm -f rm -f -r bin rm -f -r parts rm -f -r develop-eggs rm -f .installed.cfg rm -f -r build rm -f thread*.request rm -f -r lib/mailman rm -f -rf lib/canonical/launchpad/icing/build/* rm -f -r /var/tmp/bazaar.launchpad.dev rm -f lib/canonical/launchpad/apidoc/wadl-development.xml lib/canonical/launchpad/apidoc/index.html rm -f bzr-version-info.py rm -f _pythonpath.py rm -f -rf \ /var/tmp/builddmaster \ /var/tmp/bzrsync \ /var/tmp/codehosting.test \ /var/tmp/codeimport \ /var/tmp/fatsam.appserver \ /var/tmp/launchpad_mailqueue \ /var/tmp/lperr \ /var/tmp/lperr.test \ /var/tmp/mailman \ /var/tmp/mailman-xmlrpc.test \ /var/tmp/ppa \ /var/tmp/ppa.test \ /var/tmp/zeca scripts/update-bzr-version-info.sh Creating bzr-version-info.py at revno 10248 utilities/shhh.py PYTHONPATH= python2.5 bootstrap.py\ --ez_setup-source=ez_setup.py \ --download-base=download-cache/dist --eggs=eggs utilities/shhh.py PYTHONPATH= ./bin/buildout \ configuration:instance_name=development -c buildout.cfg utilities/shhh.py make -C sourcecode build PYTHON=python2.5 \ PYTHON_VERSION=2.5 LPCONFIG=development utilities/shhh.py LPCONFIG=development /var/launchpad/test/bin/py -t buildmailman.py LPCONFIG=development /var/launchpad/test/bin/py ./utilities/create-lp-wadl.py lib/canonical/launchpad/apidoc/wadl-development.xml.tmp mv lib/canonical/launchpad/apidoc/wadl-development.xml.tmp lib/canonical/launchpad/apidoc/wadl-development.xml bin/apiindex lib/canonical/launchpad/apidoc/wadl-development.xml lib/canonical/launchpad/apidoc/index.html.tmp Unknown entry
Re: [Launchpad-dev] [Fwd: Test results: FAILURE]
Abel Deuring wrote: I received got these test failures, related to translations. can anybody give me a clue what's going on there? (I don't think that my branch messed with the affected code in any way...) I go these failures too. I suspect a test-ordering thing, but haven't really looked at it in any detail... no failures on buildbot, fwiw. Cheers, mwh ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Python2.6
On Tue, 2010-02-02 at 12:05 -0800, James Westby wrote: On Tue, 2 Feb 2010 10:12:26 -0800, Barry Warsaw ba...@canonical.com wrote: Start by porting to 2.6 on Hardy using the PPA before you upgrade to Lucid. Dumping here as there isn't a better place right now. In order to run launchpad on a PPA that provides a python not in the base release the following packages must be rebuilt in that PPA. [...] python-codespeak-lib This was added as a dependency to run the SQLObject tests, but we don't use SQLObject anymore, so it might be possible to remove it from lp-deps and avoid having to port it. -- Guilherme Salgado salg...@canonical.com signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [Fwd: Test results: FAILURE]
Am 02.02.2010 20:05, Abel Deuring schrieb: I received got these test failures, related to translations. can anybody give me a clue what's going on there? (I don't think that my branch messed with the affected code in any way...) Please merge current devel and be happy ... ;-) I am a little surprised that my branch and image update caused so much problems. I *always* merge the current devel before sending a branch off to ec2, at least to catch any merge conflicts. Doesn't everybody else? Henning ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Python2.6
On Wed, Feb 3, 2010 at 3:05 AM, James Westby jw+deb...@jameswestby.net wrote: On Tue, 2 Feb 2010 10:12:26 -0800, Barry Warsaw ba...@canonical.com wrote: Start by porting to 2.6 on Hardy using the PPA before you upgrade to Lucid. Dumping here as there isn't a better place right now. In order to run launchpad on a PPA that provides a python not in the base release the following packages must be rebuilt in that PPA. postgresql-plpython-8.4 We are not on PostgreSQL 8.4 yet (need Slony-I backported to Hardy PG 8.3 + PG 8.4). I wouldn't worry about postgresql-plpython-8.3 either as it doesn't really matter to us what version of Python is embedded (there is not much Python to fix if it is an issue). -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Python2.6
On Wed, 3 Feb 2010 06:27:02 +0700, Stuart Bishop stuart.bis...@canonical.com wrote: We are not on PostgreSQL 8.4 yet (need Slony-I backported to Hardy PG 8.3 + PG 8.4). I wouldn't worry about postgresql-plpython-8.3 either as it doesn't really matter to us what version of Python is embedded (there is not much Python to fix if it is an issue). Yeah, sorry, this was a list with alternative packages substituted for comparison with my installed system. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Python2.6
James Westby wrote: On Tue, 2 Feb 2010 10:12:26 -0800, Barry Warsaw ba...@canonical.com wrote: Start by porting to 2.6 on Hardy using the PPA before you upgrade to Lucid. Dumping here as there isn't a better place right now. In order to run launchpad on a PPA that provides a python not in the base release the following packages must be rebuilt in that PPA. postgresql-plpython-8.4 python-apt python-celementtree python-codespeak-lib python-geoip python-imaging python-magic python-openssl python-psycopg2 python-pysqlite2 python-sqlite python-subversion python-svn python-tickcount python-zope.interface python-celementtree is only applicable to Python = 2.4. Its presence in this list is therefore erroneous. I'd consider the launchpad-dependencies package to be the canonical representation of the list - if it's installable, Launchpad should run. Max. signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] ./utilities/update-sourcecode breaks if bzr-explorer is installed
Jamal Fanaian wrote: For some strange reason, I could not run ./utilities-update-sourcecode with bzr-explorer installed. It would complain, telling me I needed QBzr even though that was also installed. Here is the output: jfana...@its-4l devel: ./utilities/update-sourcecode Sourcecode: ./sourcecode Config: ./utilities/sourcedeps.conf Bazaar Explorer requires QBzr. Please install it and try again. Removing bzr-explorer fixes this issue. Is QBzr itself working? Maybe there's a subdependency like Qt or PyQt4 missing. Ian C. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
