Re: [Launchpad-dev] RFA: fixing login.launchpad.net
On 12/07/11 00:26, Robert Collins wrote: (Thats request for answers :)) login.launchpad.net is a vhost on login.ubuntu.com, with two key differences: - its visually disturbing (some might say ugly) - it has a more permissive policy for relying parties While in principle we can land changes into the separate canonical-identity-provider tree to update the theme there, that seems a bit awkward. So I'm wondering how we might make it nicer, perhaps get some stats on its behaviour, and also make it easier to update. I think the biggest thing wrong with login.launchpad.net is that it is confusing to users (other than experts aware of canonical-identity-provider's mysterious two-headed nature) - People don't understand that login.launchpad.net isn't actually part of Launchpad. A supplementary problem that should be considered under the heading of fixing login.launchpad.net is that users who have the misfortune to have something go wrong with their SSO account seem to have an absolutely horrible experience getting in contact with someone responsive who can actually fix things, which is only exacerbated by the usual Launchpad means of help having to say the SSO is actually not Launchpad. I do understand the marketing reasons for not forcing the Ubuntu brand on everyone signing in to Launchpad, but in the eagerness to avoid this, another source of pain has been created. Therefore, I think the thing which needs to be fixed is either the SSO team interacting with users better under the aegis of the Launchpad branch, or the SSO should stop masquerading as part of Launchpad. 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] vcs imports email
On 07/06/11 13:55, Jelmer Vernooij wrote: The VCS imports system currently sends a lot of email; at the moment it sends an email every time a vcs import has its import status changed. This makes it very hard to do some (belated) spring cleaning of the existing imports as it means spamming a lot of people. Personally, I only look at the occasional email about an existing import that has started failing or when a new import that requires approval has appeared, and I ignore everything else. Do other team members use them? Would it be reasonable to restrict the emails for the vcs-imports team to just new imports requiring review (i.e. CVS and SVN imports) and imports that have started failing? Branch subscribers could still be sent all status changes. From the perspective of notifications that I actually want to be notified about, your defined set sounds right. However, I have occasionally found myself using my archived folder of vcs-imports mails as an audit log (Who left that unattributed comment in the branch whiteboard?) 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
[Launchpad-dev] Still getting launchpad-bugs@ Your message was rejected junk via ~vcs-imports
Some team with launchpad-bugs@l.c.c is still a member of ~vcs-imports and is causing bouncebacks to me whenever I modify a code import. 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
[Launchpad-dev] bzr-lpreview-body fixed (was: Small issue with Python 2.6 on Natty)
On 26/04/11 23:06, Max Bowsher wrote: On 20/04/11 12:30, Max Bowsher wrote: On 19/04/11 16:07, Deryck Hodge wrote: Hi, all. I had some issues getting python 2.6 installed on natty for Launchpad dev. This was because I had installed bzr from the bzr daily PPA before setting up Launchpad. This was on a new partition, so maybe none of you will hit this if you're upgrading. If you do hit this, uninstall bzr, then install python 2.6, then bzr can install fine. bzr can block installing python 2.6 on natty because it sticks files in site-packages. I filed bug 766149 on bzr to track this. I did some diagnosis on this, and it's actually not bzr or the daily PPA that's the problem here - It's actually bzr-lpreview-body that is not packaged properly (in the Launchpad PPA). I can work up a MP for this if no-one else is already on this? MPed: https://code.launchpad.net/~maxb/lpreview-body/fix-package/+merge/59137 I have fixed the packaging, and packages are now updated in the ~launchpad PPA. Robert reassigned the packaging branch ownership from ~launchpad to ~launchpad-committers so that I could have write access to it: https://code.launchpad.net/~launchpad-committers/lpreview-body/packaging I did also ask for access to the associated recipe, but it appears there is a regression breaking owner changes of recipes, so this couldn't be done. 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] Small issue with Python 2.6 on Natty
On 20/04/11 12:30, Max Bowsher wrote: On 19/04/11 16:07, Deryck Hodge wrote: Hi, all. I had some issues getting python 2.6 installed on natty for Launchpad dev. This was because I had installed bzr from the bzr daily PPA before setting up Launchpad. This was on a new partition, so maybe none of you will hit this if you're upgrading. If you do hit this, uninstall bzr, then install python 2.6, then bzr can install fine. bzr can block installing python 2.6 on natty because it sticks files in site-packages. I filed bug 766149 on bzr to track this. I did some diagnosis on this, and it's actually not bzr or the daily PPA that's the problem here - It's actually bzr-lpreview-body that is not packaged properly (in the Launchpad PPA). I can work up a MP for this if no-one else is already on this? MPed: https://code.launchpad.net/~maxb/lpreview-body/fix-package/+merge/59137 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] Small issue with Python 2.6 on Natty
On 19/04/11 16:07, Deryck Hodge wrote: Hi, all. I had some issues getting python 2.6 installed on natty for Launchpad dev. This was because I had installed bzr from the bzr daily PPA before setting up Launchpad. This was on a new partition, so maybe none of you will hit this if you're upgrading. If you do hit this, uninstall bzr, then install python 2.6, then bzr can install fine. bzr can block installing python 2.6 on natty because it sticks files in site-packages. I filed bug 766149 on bzr to track this. I did some diagnosis on this, and it's actually not bzr or the daily PPA that's the problem here - It's actually bzr-lpreview-body that is not packaged properly (in the Launchpad PPA). I can work up a MP for this if no-one else is already on this? 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
[Launchpad-dev] ~launchpad's launchpad-bugs contact address strikes again
Something has apparently changed recently, and I now get a bounce message from launchpad-bugs-ow...@lists.canonical.com saying Your message was rejected whenever I review a code import (which sends a notification email impersonating the Launchpad user who made the change). Please, can someone fix? Is there no way that the list can be configured to accept all email originating from Launchpad itself? Or, can the list that gets all launchpad bugs be disassociated from the Canonical Launchpad Engineering team? Thanks, 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] [performance] Twisted Exception features
On 28/03/11 16:05, Jonathan Lange wrote: Also, if we dropped the SFTP service, we wouldn't need to use Twisted in our smart-server support. I think we could probably get away with this. I don't use SFTP branch access much, but when something goes awry, it's great to be able to sshfs-mount the branch and copy the content locally to perform repair operations. 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] Your message was rejected back-spam from merge proposals against lp:loggerhead
On 10/03/11 16:42, Gavin Panella wrote: On 10 March 2011 15:52, Max Bowsher m...@f2s.com wrote: Or, decouple the ~launchpad access control team from the launchpad-b...@lists.ubuntu.com mailing list? I suspect that ~launchpad is entangled in a lot of places, so I don't know what further repercussions this might have. Changing the reviewer for lp:loggerhead is probably going to be less invasive. I've created ~loggerhead-reviewers, owned by ~launchpad and with ~canonical-launchpad-reviewers as a member. Changing the owner seems to have also added ~launchpad as a member... anyway, this is now the branch reviewer for lp:loggerhead. If anyone notices any problems with this, the branch reviewer can be reverted to ~loggerhead-team and ~loggerhead-reviewers deleted. Unfortunately this does not seem to have fixed the issue. 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
[Launchpad-dev] Your message was rejected back-spam from merge proposals against lp:loggerhead
I just created several merge proposals against lp:loggerhead, and got a Your message was rejected message from launchpad-bugs-ow...@lists.canonical.com for each one. (The bounced messages reveal that the cause is X-Launchpad-Message-Rationale: Reviewer @loggerhead-team ) Please can someone fix. Thanks, 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] Your message was rejected back-spam from merge proposals against lp:loggerhead
On 10/03/11 15:37, Gavin Panella wrote: On 10 March 2011 14:57, Max Bowsher m...@f2s.com wrote: I just created several merge proposals against lp:loggerhead, and got a Your message was rejected message from launchpad-bugs-ow...@lists.canonical.com for each one. (The bounced messages reveal that the cause is X-Launchpad-Message-Rationale: Reviewer @loggerhead-team ) Please can someone fix. I have seen this too. Could it be because many of the members of ~loggerhead-team are members via ~launchpad, the contact address of which is launchpad-b...@lists.ubuntu.com? Perhaps the default reviewer for lp:loggerhead should be changed to ~launchpad-reviewers or ~canonical-launchpad-reviewers? Or a new team, ~loggerhead-reviewers say, which has one of the two aforementioned teams as a member? Or, decouple the ~launchpad access control team from the launchpad-b...@lists.ubuntu.com mailing list? 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] Retargeting bug task permissions
On 03/03/11 15:01, Gavin Panella wrote: On 2 March 2011 18:29, Curtis Hovey curtis.ho...@canonical.com wrote: ... I favour addressing the second issue to solve the oops reported by the first issue. I think deleting bugtasks would be great, but it is hard to justify with 250+ critical bugs. I believe the rules are more complex than I stated. Preventing under-privileged users from re-targeting bugtasks in specific states may require extra work in terms of conditionally disabling pickers and forms, or, more simply, letting them try and then telling them it can't be done. Either way it's more rules for users to learn, or for us to attempt to make clear in the UI. Making bugtask targets immutable and allowing bugtask deletion will make the UI less noisy and easier to understand, will get rid of the need for the null project, will probably let us simplify a lot of code... with naive optimism I'd like to think that everything will be simpler. Hrm. There are lots of bugs filed on bzr which are actually bugs filed on plugins, and for which it is very natural to retarget. Ditto bugs filed on incorrect Ubuntu packages, for which simply being able to update the package is a common action. Forcing users to add + delete would be somewhat unnatural. In short, please do not make bugtask targets immutable! Regards, 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] Your message was rejected proposing merge
On 07/02/11 14:43, Aaron Bentley wrote: On 11-02-07 09:39 AM, Francis J. Lacoste wrote: On February 7, 2011, Aaron Bentley wrote: Can someone please reset the contact address of Canonical Launchpad Engineering (~launchpad) to not be a mailing list which noisily rejects emails from non-subscribers? That seems like a controversial change. We could just change the default reviewer for lazr-js to ~launchpad-reviewers, as we've done with lp:launchpad. Yep, that's the reason launchpad-reviewers was created (an email sink). Changed. Thanks :-) 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] development focus series for 'Debian' in Launchpad
On 03/02/11 23:57, John Arbash Meinel wrote: There are 2 effects that I know of from dev focus: 1) Stacking target 2) result of 'bzr branch lp:???' ... For Debian, what is the normal starting point for proposing a patch? It sounds like things are generally proposed against sid anyway. Or is sid *too* unstable, and people want to target whatever is currently targetted for release? The former, normally you look at sid as a base for future development. Especially considering the various points in time. What happens at Freeze times, etc. During a Debian freeze, it's generally recommended to still work through the -sid-testing workflow, and try to keep sid from diverging from what would want to go into the release, if possible. It sounds like targetting sid as the dev focus would fit both 1 and 2. With the only caveats a) sid is pretty fixed, so it is easy to create a different shortcut for it (eg, deb-sid:project) b) Are packages taken directly from sid, or is it more a bunch of stuff, and *some* of the patches in the sid code will be pulled into the stable version. (If I'm doing a new patch, do I want sid even though someone else might have broken it, because that's what my patch has to deal with, or do I want squeeze-to-be?) It depends on whether you are doing feature development, or a security / critical bug fix. Then again, I don't think many people are doing UDD for debian branches anyway, so just fixing on sid sounds like a decent way to go. I'd like it if the dev focus was set to sid. It seems incongruous that it isn't. My usual use case for using Debian branches is to inspect history of the Debian packaging, in which case I always want all the history, not just the subset that has entered testing. 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] Headsup: loggerhead format changing to 2a
On 31/01/11 19:30, Robert Collins wrote: Loggerhead trunk is already in 2a format, our sourcecode/loggerhead needs to be upgraded as well. This will have the normal disruption on devpad and developer checkouts (just need to run 'bzr upgrade sourcecode/loggerhead'). I'm going to push this forward today. Besides loggerhead, the following other sourcecode projects have a 1.x format for their lp sourcecode branch, but a 2a upstream branch: bzr-git bzr-svn mailman (checking against lp:mailman/2.1) subvertpy testresources Perhaps it would be worth doing them all, to minimize the individual occasions when people need to think about this? Although, IIRC update-sourcecode automatically handles upgrades, so it shouldn't be that painful? 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] Headsup: loggerhead format changing to 2a
On 31/01/11 23:02, Barry Warsaw wrote: On Jan 31, 2011, at 10:52 PM, Max Bowsher wrote: Besides loggerhead, the following other sourcecode projects have a 1.x format for their lp sourcecode branch, but a 2a upstream branch: mailman (checking against lp:mailman/2.1) All of the upstream mailman branches should be in 2a format. Do you mean the branch of Mailman 2.1 that Launchpad uses? Indeed. I am saying that lp:~launchpad-pqm/mailman/2.1 is pack-0.92 whereas lp:mailman/2.1 is 2a, and thus an upgrade of the ~launchpad-pqm branch would be required if there was a desire to ever update LP's mailman. Further, I'm suggesting that doing an upgrade for all ~launchpad-pqm branches currently in this situation could save some mental effort (it being easier to upgrade 6 branches at the same time, than to recover the mental state and re-coordinate with LOSAs over 6 separate occasions) 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] Launchpad Projects Merge Preview
On 14/12/10 15:53, Francis J. Lacoste wrote: On December 13, 2010, Max Bowsher wrote: Including a The new way to search bugs just within the Soyuz component of Launchpad is ... (etc.) in the blog post would likely make it a lot less likely to make people think negatively about the change. In a way, the fact that all components are part of the same project should help with finding duplicate. Before if you file a bug against the wrong project, you wouldn't find the existing bug whereas now it won't be a problem. There is no real way anymore to search only the Soyuz component, since there isn't such a thing as a 'Soyuz' component. It's really an aggregation of multiple components (publisher, buildd-manager, plus a bunch of web features.) There is the 'lp-soyuz' tag, but these are temporary as they only reflect an arbitrary aggregation of components. The lumping together of all bugs across separate and generally fairly well definable major areas of Launchpad (i.e. Bugs, Code, Soyuz, etc.) feels negative to me. I'd imagine I'm not the only one. Therefore, I think it's very important the rationale for doing so is clearly communicated. 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] Launchpad Projects Merge Preview
On 14/12/10 02:07, Martin Pool wrote: On 14 December 2010 11:03, Max Bowsher m...@f2s.com wrote: On 13/12/10 17:16, Francis J. Lacoste wrote: Hi everyone, Please browse https://bugs.staging.launchpad.net/launchpad for a preview of the future. Staging got rid of the following sub projects: blueprint, launchpad-answers, launchpad-code, launchpad-foundations, launchpad-registry, launchpad-web, malone, rosetta and soyuz. The projects were deactivated. (The launchpad-* aliases will be added on production.) All bugs, questions and faqs were reassigned to the one and only one launchpad project. There's probably a good reason for doing all this, and it may even have been mentioned on this list at some point, but speaking as someone on the periphery of LP development, this feels like a negative step. If I wanted to search for whether a bug was already reported, I used to be able to immediately focus in on just the code, or soyuz, or malone, etc. I would suggest that some mention of this reorganization should probably occur on the Launchpad Blog before it hits production. I think this is a positive step for Launchpad. * time is wasted at the moment re-sorting bugs * other projects need ways to group bugs within a single code base; launchpad shouldn't cheat by using multiple projects * work is underway (iirc) on subscribe-to-tag etc I do agree with Max this ought to be advertised before it's done. There are people (well, at least me) who have things bookmarked, who are subscribed to bugs in particular apps, etc. A one or two paragraph blog post would do, and we don't need to enter into bikeshedding. Including a The new way to search bugs just within the Soyuz component of Launchpad is ... (etc.) in the blog post would likely make it a lot less likely to make people think negatively about the change. 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
[Launchpad-dev] PPA deletion requests
Hi, There is various stuff in the ~launchpad PPA that could/should be deleted: * xulrunner - definitely delete, the binary packages are superseded by the spidermonkey source. * psycopg2 - the need for using Lucid's psycopg2 on Maverick has passed. * python-debian - it is a sourcedep now. 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] vcs-imports: http import from sourceforge.net fails; https succeeds
On 21/11/10 20:06, Robert Collins wrote: Perhaps turn this into a bug? Further experience shows this is a general problem not one with specific branches. I have gardened the list of failing bzr-svn imports and restarted many over https. Bug 682430 filed. 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] Ubuntu developer feedback on Bazaar and Launchpad
On 23/11/10 09:45, Julian Edwards wrote: On Tuesday 23 November 2010 02:28:23 Martin Pool wrote: On 22 November 2010 20:20, Julian Edwards julian.edwa...@canonical.com wrote: Most of the time they're either really impatient people or they've made a mistake in the packaging that means we can't email a response. I think, if it's your first attempt at packaging, those five minutes (not that you know it's only five minutes) pass very slowly as you wonder what happened. Anyone could look very impatient in those circumstances. Hopefully once we get everyone uploading over sftp we will know their email address and therefore will be able to mail them even if they got the package wrong, or indeed we could potentially complain on sftp's stderr with sufficiently advanced magic. (I realize it may take a while...) Yep, that's the plan. We tried to do it with ftp and got something working but it was kind of unreliable. Sftp will make it easier but last time I checked there was some resistance from the Ubuntu team to moving over to it for all uploads. Admittedly, they're far less likely to make packaging mistakes :) Casual users on all but the very fastest internet connections are likely to shy away from sftp uploads until someone manages to give them a progress indication, as ftp does. 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
[Launchpad-dev] vcs-imports: http import from sourceforge.net fails; https succeeds
Hi, I have encountered an oddity worth mentioning. For some time I've been changing Sourceforge imports to use plain http not https as I approve them. I've never noticed any issues from this before. However, someone emailed me yesterday (replying to Launchpad's automated email from when I reviewed the import) reporting that their import wasn't working. I switched it to https... and it worked. So, there's something weird potentially changed about Sourceforge's svn server. The import branch in question is: https://code.edge.launchpad.net/~frechilla/blockem/trunk The failure is: bzrlib.plugins.svn.errors.DavRequestFailed: A Subversion remote access command failed: REPORT of '/svnroot/blockem/!svn/vcc/default': Could not read response body: Connection reset by peer (http://blockem.svn.sourceforge.net) 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
[Launchpad-dev] Heads Up: Code Imports appear broken!
It would appear that, as far as I can see, no code imports have successfully completed since some time on 2010-11-15. The code import machines are all full of running jobs, all of which appear to sit around doing nothing much, until they get canceled an hour after they start. Because every dispatched importd job is now taking 60 minutes, which is much longer than the average when things work properly, there are now *very many* imports which are queuing for an importd execution, hence the web UI is displaying The next import is scheduled to run as soon as possible. for imports which won't actually be attempted for hours? days? (and will then fail.) 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
[Launchpad-dev] Obsoleting the Launchpad PPA on Hardy
The Launchpad PPA on hardy is already 7 versions behind on launchpad-dependencies, so I think the time has come for it to officially designated obsolete. Assuming no objections, please could a member of ~launchpad: 1) Copy all the published hardy packages from launchpad/ppa to launchpad/obsolete (copy including binaries). 2) Delete all the hardy packages in launchpad/ppa. /me goes to hunt references to Hardy on the dev.lp.net wiki. 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] [Launchpad-users] launchpad dev in maverick
On 15/11/10 04:09, Vikram Dhillon wrote: Hi all, Please forgive me if I am mistaken, but launchpad for me currently doesn't work in 10.10. Is it only me who's experiencing this problem? or it this general? Here's the error message I get: - cut Reading package lists... Done Package `launchpad-developer-dependencies' is not installed and no info is available. Use dpkg --info (= dpkg-deb --info) to examine archive files, and dpkg --contents (= dpkg-deb --contents) to list their contents. Installing launchpad-developer-dependencies package... Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: launchpad-developer-dependencies : Depends: launchpad-dependencies (= 0.83) but it is not going to be installed Depends: launchpad-soyuz-dependencies (= 0.83) but it is not going to be installed E: Broken packages Unable to install launchpad-developer-dependencies. --- cut - And also please CC me the messages because I am not subscribed to the list. Thanks a lot. It is advisable to use the launchpad-dev list not launchpad-users for development questions. The problem may well be related to launchpad-dependencies currently depending on a version of python-psycopg2 less than that available in Maverick. (Because Launchpad is currently incompatible with 2.2) I suggest manually installing the .deb of python-psycopg2 from lucid, and trying again. 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] postgresql8.4 migration retrospective (planning for 9)
On 12/10/10 23:26, Robert Collins wrote: Hey Stuart, Gary, I'm wondering if you could put a few hours aside this week or next and have a think about how we can avoid the things that went wrong with the 8.4 migration. Does this mean we're complete, and it's OK to make launchpad-dependencies depend strictly on 8.4 rather than 8.3 | 8.4 ? 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] RFC: Cleaning Launchpad Lucid PPA
I've received one positive comment on IRC, but no other comments. I think this is sane. flacoste/stub: Would one of you be happy to activate a new PPA named obsolete under ~launchpad, and grant me additional archive uploader access, in the same manner as I already have for the ppa PPA? Thanks, Max. On 27/09/10 19:45, Max Bowsher wrote: The Launchpad PPA for Lucid currently contains numerous packages to accommodate Python 2.5. However, ever since the use system python version changes landed, these are not necessary for development. In the interests of not causing future people working on Launchpad, on a current-Ubuntu-LTS system, to install numerous unnecessary customized packages, I propose we clean the Launchpad Lucid PPA of packages which exist there solely for Python 2.5 support. Since it might possibly be premature to delete them outright, I suggest that a ~launchpad admin activate a new obsolete PPA, into which the relevant packages can be copied, and then deleted from the main ppa. The packages concerned are: * distribute - special case, was an attempt to make compatible with python 2.5, but did not work, so just delete this outright, don't copy. * egenix-mx-base * psycopg2 * pycxx * pysvn * python-apt * python-defaults * python-geoip * python-imaging * python-pysqlite2 * python-support * python2.5 * subversion * tickcount Which leaves the following, not related to Python 2.5: * bzr-lpreview-body * bzr-pqm * geoip-data-city-lite * launchpad-dependencies * pocket-lint * postgresql-8.3 * python-debian * slony1 * slony1pg83 * xulrunner It may also be appropriate to move the postgresql-8.3 and slony1pg83 packages to the obsolete PPA now or later. 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] RFC: Cleaning Launchpad Lucid PPA
On 30/09/10 22:36, Francis J. Lacoste wrote: Hi Max, Thanks for suggesting this clean-up. No problem. * distribute - special case, was an attempt to make compatible with python 2.5, but did not work, so just delete this outright, don't copy. * egenix-mx-base * psycopg2 * pycxx * pysvn * python-apt * python-defaults * python-geoip * python-imaging * python-pysqlite2 * python-support * python2.5 * subversion * tickcount All moved to obsolete. Thanks. It may also be appropriate to move the postgresql-8.3 and slony1pg83 packages to the obsolete PPA now or later. I moved those as well. OK. I also deleted all the Karmic packages. Hmm, alright. I don't feel we were at the point where it was onerous to support Karmic yet, though I guess few people would be developing Launchpad on it at this point. Still, when the time came, I was going to suggest that the Karmic packages be moved to the Obsolete PPA rather than deleted outright. I guess they won't have expired from the librarian yet, so we could still copy the former contents of karmic to obsolete? 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
[Launchpad-dev] RFC: Cleaning Launchpad Lucid PPA
The Launchpad PPA for Lucid currently contains numerous packages to accommodate Python 2.5. However, ever since the use system python version changes landed, these are not necessary for development. In the interests of not causing future people working on Launchpad, on a current-Ubuntu-LTS system, to install numerous unnecessary customized packages, I propose we clean the Launchpad Lucid PPA of packages which exist there solely for Python 2.5 support. Since it might possibly be premature to delete them outright, I suggest that a ~launchpad admin activate a new obsolete PPA, into which the relevant packages can be copied, and then deleted from the main ppa. The packages concerned are: * distribute - special case, was an attempt to make compatible with python 2.5, but did not work, so just delete this outright, don't copy. * egenix-mx-base * psycopg2 * pycxx * pysvn * python-apt * python-defaults * python-geoip * python-imaging * python-pysqlite2 * python-support * python2.5 * subversion * tickcount Which leaves the following, not related to Python 2.5: * bzr-lpreview-body * bzr-pqm * geoip-data-city-lite * launchpad-dependencies * pocket-lint * postgresql-8.3 * python-debian * slony1 * slony1pg83 * xulrunner It may also be appropriate to move the postgresql-8.3 and slony1pg83 packages to the obsolete PPA now or later. 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] Updating the Maverick and running Launchpad
On 16/09/10 16:46, Curtis Hovey wrote: Hello rocket scientists. Launchpad Engineers should be updating their systems to Maverick. Aha. We should start being better about keeping the PPA in shape for Maverick, then. I've just gone through and copied lucid versions of pocket-lint, bzr-lpreview-body and launchpad-dependencies (!) to maverick and karmic. Everyone, please remember when you upload to the PPA to take care of all active distroseries, if you can. Also, I note there's a bzr-pqm package for lucid in the PPA - a recipe build(?) by matsubara. Could someone scribble something on https://dev.launchpad.net/LaunchpadPpa about why it's there, so we know whether we need an equivalent for maverick? (And in theory, karmic and hardy). === Adventures in Upgrading to Maverick from a terminal run update-manage -d I experienced this error on all three computers: Key (error): Could not calculate the upgrade An unresolvable problem occurred while calculating the upgrade: E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. This can be caused by: * Upgrading to a pre-release version of Ubuntu * Running the current pre-release version of Ubuntu * Unofficial software packages not provided by Ubuntu This can also be caused by pinning using apt preferences. Which is possibly this bug which has an ongoing list of packages that cause the problem https://bugs.launchpad.net/ubuntu/+source/apt/+bug/614993 I was running Unity from a PPA. Regardless of this error, you can manually resolve the issue by downgrading packages from PPAs. I had to download some of the lucid packages from Launchpad and use dpkg to --force-downgrade because synaptic would not let me choose the alternate package version. Hah. aptitude ftw! 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] Full deployments?
On 10/09/10 00:37, Martin Pool wrote: On 10 September 2010 03:13, Elliot Murphy ell...@canonical.com wrote: The closed source provider was thrown in the trash and replaced with a much better AGPL version. If you notice the footer of login.ubuntu.com and login.launchpad.net you will see they both mention being AGPL and have links to the source code, which is here: https://launchpad.net/canonical-identity-provider/ I don't think there are any missing components. Have fun, let us know how it goes! That's great, and news to me. Just a little while ago someone was complaining the source was not published. It's not, however, very well published. There's sourcecode there, but it's in no way ready to run straight out of the branch. You have to pore over it, realize that the schemaconfig thing is still closed source, find the alternative manage.py elsewhere in the tree, compose your own configuration from scratch, find that the metapackage which is the ISD equivalent to launchpad-developer-dependencies is also closed source, I've yet to make it 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] Developers switch to PostgreSQL 8.4
On 10/08/10 13:37, Julian Edwards wrote: On Tuesday 10 August 2010 11:22:14 Stuart Bishop wrote: 5) Uninstall postgresql 8.3 packages if you want. You can also just disable it on startup by editing /etc/postgresql/8.3/main/start.conf to specify 'manual' instead of 'auto' Uninstalling them results in launchpad-database-dependencies and launchpad- developer-dependencies getting culled as well. I guess we need to update those packages to depend on the newer PG packages? This is not the case on lucid. Are you perhaps still running hardy, which has an outdated version of launchpad-dependencies, and is blocked on sorting out the rabbitmq dependency situation there? Or, do you perhaps the 8.3 flavours but not the 8.4 flavours of these installed: ? postgresql-plpython-8.x postgresql-contrib-8.x postgresql-8.x-slony1 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] Archive deletion strategy - deletion of GPG signing key
On 05/08/10 11:33, Julian Edwards wrote: On Wednesday 04 August 2010 21:16:33 James Westby wrote: On Tue, 3 Aug 2010 11:08:03 +0100, Julian Edwards wrote: I think that's pretty much it, although we need to examine exactly which database rows need to be deleted and under what conditions. I've added some ON DELETE CASCADEs in the past where it's a no brainer but it won't delete everything because of the multiple publication referencing package files issue. Ok, I've been through the schema and I think this is the set of tables chained off archive: # Archive - signing_key - KEEP #signing_key (GPGKey) - ? If it's the Person's last PPA then it should be deleted (keys are shared for all a Person's PPAs). We should also try and revoke the key and remove it from the keyserver. Some points: 1) Some users will love this feature, because it provides a get-out for having a current GPG key with a silly user-id. However, some may find it annoying/surprising. Plus, the current user experience when uploading to a PPA without a generated GPG key is very sub-optimal - your first upload is published unsigned, and the PPA is not signed until it is republished after key generation has finished. Therefore, this feature ought to at least be warned about in the PPA deletion confirm page - if not made optional. 2) Publishing a revocation is mutually contradictory with removing the key from the keyserver :-) 3) You can't remove a key from the global keyservers network - even if you remove it from one, they'll sync with each other, and re-propagate it. 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] Archive deletion strategy - nulling upload_archive
On 05/08/10 11:33, Julian Edwards wrote: On Wednesday 04 August 2010 21:16:33 James Westby wrote: On Tue, 3 Aug 2010 11:08:03 +0100, Julian Edwards wrote: # SPPH - Archive and SPR - DELETE #SPR - Archive - DELETE IF ONLY REFERENCED BY SPPH AND # BUILD ATTACHED TO THIS ARCHIVE. what # about packageuploadsource? That's upload_archive, and this is one of the awkward FKs. We use it to work out if a package was copied by comparing that field to the SPPH.archive. If the original upload archive disappears we should probably NULL this column and fix the code so that it copes with that. OOI, what's the UI going to look here? For example +sourcepub/id/+listing-archive-extra = Publishing details *Published* on -mm-dd *Copied from* an archive which has been deleted Changelog foo (1.0-1) lucid; urgency=low = The loss of information for copied packages troubles me a bit, but I can see there's no nice answer here - people will hate it if copied builds block PPA deletion. 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] Archive deletion strategy
On 02/08/10 21:40, James Westby wrote: Currently any archive can be deleted, by (correct me if I am wrong) 1. PPA: owner or any uploader Empirically, owner only. I have upload access on the ~launchpad PPA, but I don't see the delete link on it. This is as it should be :-) 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] Archive deletion strategy
On 02/08/10 22:09, James Westby wrote: (Note that uploading the same version as before with different contents isn't a problem with apt. Apt will do the right thing and get you the new version, but there may be other tools that break.) Mmm, I disagree. I've observed Apt doing the following: 1) Aha! The package in the archive has changed its metadata! You need to upgrade from version 1.0-1 to version 1.0-1. 2) But, I already have version 1.0-1 in /var/cache/apt/archives/ so I don't need to download it. 3) Oh noes! The installed package is still different from the archive! You need to upgrade from version 1.0-1 to version 1.0-1. ... repeat infinitely, until you manually purge the old version from /var/cache/apt/archives/, so that Apt actually downloads the package, rather than reinstalling the old incarnation of the version number. Basically, reusing a version in anything but very special rebuild test circumstances is bad news. 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] Renaming lp:launchpad to lp:launchpad/10.05 (and the breakages caused)
On 22/07/10 01:36, Tim Penhey wrote: On Thu, 22 Jul 2010 03:14:34 Curtis Hovey wrote: On Wed, 2010-07-21 at 16:55 +0200, Paul Hummer wrote: Hi folks- About 20 minutes ago, jtv and I both noticed it was taking a long time to push to launchpad. I had pushed a non-launchpad branch just fine though. I did some hpss debugging and found I wasn't using stacking, so it was taking a very long time. Upon investigation, I found that someone had taken the db-devel branch and targeted it against the 10.05 (lp:launchpad/10.05) series. Please don't do this. If you want another series branch, create it. Taking away the development focus takes away the stacked on branch. I wonder. I marked the 10.05 series obsolete a few hours ago and made the 10,12 series the current series. I know there is a bug reported about series branches appear to be modified if a series is marked obsolete. Hi Curtis, If you didn't set a series branch for the 10.12 series, then Launchpad would no longer have had a development focus branch. A single branch can be a development focus for multiple series. Perhaps this would fix it too. Perhaps we should create a db-devel pseudo-series, and assign that as the development focus series, to ensure this doesn't happen in the future, and to save someone from needing to update the launchpad development focus series every month? 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
[Launchpad-dev] De-support jaunty as a launchpad development platform
I think the time has come to officially de-support Jaunty as a Launchpad development platform. It now has only 3 months to run before EOL, and I doubt anyone would deem it worthwhile to spend time on validating the launchpad-messagequeue-dependencies stack there. If there are no objections, please would a ~launchpad member delete all Jaunty publications from the Launchpad PPA to clearly represent this / avoid potential confusion. 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
[Launchpad-dev] Continue to maintain python2.5 supporting packages for lucid in launchpad PPA, or not?
Now that Launchpad runs using the default system Python, it's no longer necessary to have rebuilds of many python packages in the Launchpad PPA... unless it's considered desirable to continue to allow a developer on Lucid to test LP against 2.5 via some local hackery. Shall we delete the relevant packages, or keep them up to date? 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
[Launchpad-dev] Older distroseries status of the Launchpad PPA
Karmic: It was broken. I fixed it by copying pocket-lint and launchpad-dependencies from Lucid. Hardy: launchpad-developer-dependencies in Hardy is both outdated and broken - it depends on pocket-lint, which is not available for hardy. Also, hardy does not have rabbitmq-server or python-amqplib, so it'll get more broken if we update launchpad-dependencies there. Options re pocket-lint: 1) Backport it to hardy 2) Do something to pacify the packaging system and assume no-one runs lint on hardy. Options re RabbitMQ: 1) Attempt to backport it - kinda scary?, erlang on hardy is two major versions behind lucid. 2) Migrate the datacentre to Lucid before we start actually using RabbitMQ. Thoughts? 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] Continue to maintain python2.5 supporting packages for lucid in launchpad PPA, or not?
On 22/07/10 16:21, Robert Collins wrote: We should be on lucid fairly soon: until then I think its a good idea to be able to reproduce things as-they-are-on-prod as easily as possible. If its a lot of effort, sure, nuke em, otherwise I'd be happier if we had them for a little while longer. Let's keep them for now, then - the only ongoing effort is noticing an resubmitting no-change rebuilds when updates appear in lucid-proposed/updates/security. The only real downside is that new developer's end up installing quite a few more custom packages than are otherwise necessary. Which is a fairly small downside. 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] rollout changes to reduce downtime - linked to 'release features when they are ready'
On 22/07/10 17:30, Danilo Šegan wrote: [1] https://dev.launchpad.net/Translations/LanguagePackSchedule The distroseries links on that page say on thing in text and link to a different series in their URL. 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] Some Error when Getting Launchpad
On 21/07/10 22:23, Manish Sinha wrote: Hi, I was trying to get Launchpad source using the way mentioned here https://dev.launchpad.net/Getting On the way it tried branching a repo, which failed The error was bzr: ERROR: Not a branch: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/ http://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/. When I tried opening this in the browser as http://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/; all I get is === Unauthorized You are logged in as foo === Probably that repo is private or does not exist. In this case most of the people outside of Canonical can't access it. I am confused why this error is coming. Or there is a minor problem in the rocketfuel-setup ? This error is expected for us non-Canonical people. It is, however, not fatal, and everything should continue to work fine. 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] 2nd opinion on some vcs-import reviews
On 07/06/10 13:40, Max Bowsher wrote: Hi, There are currently a few vcs-imports in pending review that I'm uncertain about: https://code.edge.launchpad.net/~jesterking/blender/win32libs https://code.edge.launchpad.net/~jesterking/blender/win64libs These look fine, apart from being branches entirely dedicated to holding precompiled binaries of other projects. I gather that it's only a convenience measure, to assist in building blender without first tackling a whole dependency tree of builds, but I wasn't confident to approve them without asking. Ping? On one hand, if this was a git or mercurial import, no one would even care, because we wouldn't be checking it. On the other, I don't feel confident approving it, especially after having noticed that the win32libs branch at least contains code of dubious redistributability (namely, msvcrtd.dll). Max. ___ 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] novice question: could not access file $libdir/plpython while executing make schema
On 11/06/10 06:35, Max Bowsher wrote: On 10/06/10 08:56, Davide Galletti wrote: While building, the command make schema fails: createlang: .. ERROR: could not access file $libdir/plpython: No such file or directory On 10/06/10 14:21, Francis J. Lacoste wrote: I think you are missing the postgresql-plpython-8.3 package. I have no explanation on why this wasn't installed as part of launchpad- database-dependencies though. I just ran into this myself. The problem is that launchpad-database-dependencies requires postgresql-8.3, postgresql-contrib-8.3, postgresql-plpython-8.3, BUT utilities/launchpad-database-setup will use postgresql 8.4 if it is found to be installed. It occurs to me that it might be considered a bug that utilities/launchpad-database-setup.py prefers a postgres version different to that pulled in by launchpad-database-dependencies? Max. ___ 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] novice question: could not access file $libdir/plpython while executing make schema
On 10/06/10 08:56, Davide Galletti wrote: While building, the command make schema fails: createlang: .. ERROR: could not access file $libdir/plpython: No such file or directory On 10/06/10 14:21, Francis J. Lacoste wrote: I think you are missing the postgresql-plpython-8.3 package. I have no explanation on why this wasn't installed as part of launchpad- database-dependencies though. I just ran into this myself. The problem is that launchpad-database-dependencies requires postgresql-8.3, postgresql-contrib-8.3, postgresql-plpython-8.3, BUT utilities/launchpad-database-setup will use postgresql 8.4 if it is found to be installed. Max. ___ 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] PPA key generation is currently broken
On 04/05/10 23:28, Julian Edwards wrote: I think this might be related to the pygpgme change that was done recently, but can anyone take a guess at why the script is bailing out with this? 2010-05-04 22:00:41 INFOGenerating signing key for PPA for Kristian Klette 2010-05-04 22:02:32 DEBUG Removing lock file: /var/lock/launchpad-ppa- generate-keys.lock Traceback (most recent call last): File /srv/launchpad.net/codelines/current/cronscripts/ppa-generate- keys.py, line 21, inmodule script.lock_and_run() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/services/scripts/base.py, line 280, in lock_and_run implicit_begin=implicit_begin, isolation=isolation) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/services/scripts/base.py, line 238, in run self.main() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/soyuz/scripts/ppakeygenerator.py, line 62, in main self.generateKey(archive) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/soyuz/scripts/ppakeygenerator.py, line 33, in generateKey archive_signing_key.generateSigningKey() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/archivepublisher/archivesigningkey.py, line 75, in generateSigningKey secret_key = getUtility(IGPGHandler).generateKey(key_displayname) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/canonical/launchpad/utilities/gpghandler.py, line 307, in generateKey secret_keys = list(self.localKeys(result.fpr, secret=True)) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/canonical/launchpad/utilities/gpghandler.py, line 402, in localKeys for key in ctx.keylist(filter, secret): TypeError: first argument must be a string or sequence of strings The new pygpgme's result.fpr is now a unicode object, but apparently the filter argument to keylist is still wanted as a bytestring. Max. ___ 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] Hung test process
On 27/04/10 13:44, Gavin Panella wrote: I have a hung test process on my local machine. Command: bin/test -vvct 'check-?watch|bug-?watch|bug-?track' Michael Hudson Trace: http://pastebin.ubuntu.com/42/ Judging by the presence of spawn_layer_in_subprocess and the general appearance of the stacks to be that of waiting on stdio, I'd suggest that this process is just waiting for communications from the subprocess? GDB Trace: http://pastebin.ubuntu.com/423334/ Only for the main thread - remember to do 'thread apply all backtrace' (or 'thr a a bt'). In gdb, pystack and pystackv never completed (they hung too). I've never got these to work, either. I'd be interested to know if they ever work. 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] ec2 hangs - backtrace tool?
On 21/04/10 04:42, Tim Penhey wrote: Hi people, Today both mwhudson and I had hangs on ec2 where the windmill tests appeared to fail, and then the tests hung. The log files didn't contain complete stack traces, and when we shelled into the instances their load was zero, and using mwhudson's python stack queryer it seems it was just waiting for connections. Where does this rather useful sounding tool live? :-) Max. ___ 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] ec2 hangs - hang 1
On 21/04/10 04:42, Tim Penhey wrote: This process was process running some windmill tests: /usr/bin/python2.5 /var/launchpad/test/bin/test --resume-layer lp.code.windmill.testing.CodeWindmillLayer 12 --subunit -vv ec2t...@ip-10-195-162-31:~/pygdb$ python backtrace.py 14620 Thread 3 #0 0x2b8523165dc2 in select () from None #1 0x2b8527a402c3 in select_select (self=value optimized out, args=value optimized out) from /build/buildd/python2.5-2.5.2/Modules/selectmodule.c /usr/lib/python2.5/asyncore.py (104): poll /usr/lib/python2.5/asyncore.py (181): loop /var/launchpad/tmp/eggs/lazr.smtptest-1.1-py2.5.egg/lazr/smtptest/server.py (107): start /usr/lib/python2.5/threading.py (445): run /usr/lib/python2.5/threading.py (469): __bootstrap_inner /usr/lib/python2.5/threading.py (461): __bootstrap The lazr.smtptest thread is a daemon thread AFAIK, so should be ignorable for the purposes of this debugging. Thread 2 #0 0x2b85227fd7fb in accept () from None #1 0x2b852388f947 in sock_accept (s=0x94409c0) from /build/buildd/python2.5-2.5.2/Modules/socketmodule.c /usr/lib/python2.5/socket.py (167): accept /usr/lib/python2.5/SocketServer.py (374): get_request /usr/lib/python2.5/SocketServer.py (216): handle_request /var/launchpad/tmp/eggs/windmill-1.3beta3_lp_r1440- py2.5.egg/windmill/server/https.py (394): start /usr/lib/python2.5/threading.py (445): run /usr/lib/python2.5/threading.py (469): __bootstrap_inner /usr/lib/python2.5/threading.py (461): __bootstrap This must be the culprit of the hang, it appears similar to one I've been looking at for the Python 2.6 migration. Whatever was supposed to knock this thread out of its accept loop, hasn't. Thread 1 #0 0x2b85227fc991 in sem_wait () from None #1 0x004b371d in PyThread_acquire_lock (lock=0xc220e90, waitflag=1) from ../Python/thread_pthread.h #2 0x004b68d0 in lock_PyThread_acquire_lock (self=0x11de38d0, args=value optimized out) from ../Modules/threadmodule.c /usr/lib/python2.5/threading.py (208): wait /usr/lib/python2.5/threading.py (580): join /usr/lib/python2.5/threading.py (682): _exitfunc This is the main thread calling threading._shutdown to wait for non-daemon non-main threads to exit. ___ 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] ec2 hangs - hang 2
And this one was the app server: /usr/bin/python2.5 -S /var/launchpad/test/bin/run -C configs/testrunner- appserver/launchpad.conf [snipped all but main thread] Thread 1 #0 0x2b60acf52dc2 in select () from None #1 0x2b60b30942c3 in select_select (self=value optimized out, args=value optimized out) from /build/buildd/python2.5-2.5.2/Modules/selectmodule.c /usr/lib/python2.5/asyncore.py (104): poll /var/launchpad/tmp/eggs/zope.app.server-3.4.2- py2.5.egg/zope/app/server/main.py (80): run /var/launchpad/tmp/eggs/zope.app.server-3.4.2- py2.5.egg/zope/app/server/main.py (53): main /var/launchpad/test/lib/canonical/launchpad/scripts/runlaunchpad.py (264): start_launchpad /var/launchpad/test/bin/run (3):module The main thread appears to still be doing business as usual - what's supposed to initiate an appserver stop? Max. ___ 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] Branching Ubuntu, again
On 19/04/10 02:32, Michael Hudson wrote:
to trigger the puller to run. Last time this clogged up the branch
puller queue for several hours, so maybe we should run something like:
update branch set next_mirror_time = CURRENT_TIMESTAMP AT TIME ZONE
'UTC' where id in (select branch from seriessourcepackagebranch where
distroseries in (select distroseries.id from distroseries, distribution
where distroseries.name in ('lucid', 'maverick') and distribution.name =
'ubuntu' limit 500))
every so often until it doesn't update any rows, or something that
spreads next_mirror_time for these branches evenly over the next 10 hours.
I think your limit clause is in the wrong place and you're missing a
qualification to avoid touching branches a previous execution of the
query has already touched.
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
[Launchpad-dev] Please remember that launchpad-dependencies is maintained in bzr
Please remember that launchpad-dependencies is maintained in bzr. I've just imported the uploaded tarball of 0.71 into the bzr branch. (Also, it hadn't been copied to jaunty, so I did that too) 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] Why is lp:launchpad/devel not the development focus?
On 08/04/10 13:42, Jonathan Lange wrote: On Thu, Apr 8, 2010 at 1:26 PM, Maris Fogelsmaris.fog...@canonical.com wrote: Hi, quick question: Today I goofed up a merge proposal created via the web interface because I proposed to merge my branch into the Development Focus, lp:launchpad. It turns out that lp:launchpad is not, in fact, where we do development work. lp:launchpad-devel is. So why isn't lp:launchpad-devel, the branch where we land our code, set as the development focus? Even if just as a convenience to those using the web interface? Because stacking is more efficient on branches that have more revisions, and the development focus determines stacking, and db-devel has the most revisions. Well, 'more revisions' is a bit of an oversimplification. I assume the detail behind the choice is that revisions landed into devel reach db-devel usually in a matter of hours, whereas revisions landed into db-devel only reach devel once a month. Hence, db-devel makes an adequate stacking base for branches off devel, whereas devel is a poor stacking base for branches off db-devel most of the time. Max. ___ 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] New launchpad-dependencies for 10.04 LTS (Lucid)?
Karl Fogel wrote: Thanks, Tom and Aaron. I've updated dev.launchpad.net/Running/Lucid page to try to clarify this stuff. It's hard to make that page be correct for everyone, since people upgrade from different states to different states; if something looks definitely wrong or misleading there, please fix (and let me know). Those instructions are starting to look rather overcomplicated. 1) launchpad-developer-dependencies depends on launchpad-dependencies so there's no purpose to mentioning the latter explicitly 2) Rather than enumerating individual packages that are contained in the PPA for manual upgrade: * the advice should be to upgrade anything upgradable after you've added the PPA and updated your package lists * the dependencies packages should ideally use suitable version clauses to force installation of the PPA versions, where lucid contains an inadequate version 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] Fresh lucid installation issues
On 17/03/10 20:14, Michael Hudson wrote: Julian Edwards wrote: Hey folks I am in the throes of installing LP on a new laptop on which I installed a fresh copy of lucid. Apart from the spidermonkey issue that we already know about, I found another problem when running update-sourcecode: File /usr/lib/python2.5/site-packages/bzrlib/plugins/svn/__init__.py, line 120, in init_subvertpy raise DependencyNotPresent(subvertpy, bzr-svn: %s % e.message) bzrlib.errors.DependencyNotPresent: Unable to import library subvertpy: bzr- svn: It looks like this is down to the fact that update-sourcecode needs subvertpy to run, but subvertpy is built by update-sourcecode ... The lucid python-subvertpy package is only built for python 2.6 and the update-sourcecode script is explicitly using python 2.5. That looks like the packaging is broken somewhere then -- if bzr-svn is installed in the 2.5 area but python-subvertpy is not, which is what it looks like, then that's a bug that has nothing to do with Launchpad. Where are your bzr-svn and python-subvertpy packages from? Moreover, where's your python2.5 bzrlib from? A lucid install shouldn't have one. When I remove that 2.5 to make it use the system python, all seems well. Is there a good reason for this script to use 2.5 or can I commit a change to make it use the system python? Using the system python would probably be OK, but I think finding/fixing the real bug would be better. I've been meaning to propose a branch to change update-sourcecode to use the system python too, for a different reason. As I mention above, a Lucid system doesn't have bzrlib available under /usr/bin/python2.5. I view using the system python as the correct approach for update-sourcecode: Note that in a fresh invocation of rocketfuel-setup, rocketfuel-setup will call rocketfuel-get which will call update-sourcecode BEFORE anything buildout-ish happens. Max. ___ 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] Fresh lucid installation issues
On 17/03/10 20:35, Max Bowsher wrote: On 17/03/10 20:14, Michael Hudson wrote: Julian Edwards wrote: Hey folks I am in the throes of installing LP on a new laptop on which I installed a fresh copy of lucid. Apart from the spidermonkey issue that we already know about, I found another problem when running update-sourcecode: File /usr/lib/python2.5/site-packages/bzrlib/plugins/svn/__init__.py, line 120, in init_subvertpy raise DependencyNotPresent(subvertpy, bzr-svn: %s % e.message) bzrlib.errors.DependencyNotPresent: Unable to import library subvertpy: bzr- svn: It looks like this is down to the fact that update-sourcecode needs subvertpy to run, but subvertpy is built by update-sourcecode ... The lucid python-subvertpy package is only built for python 2.6 and the update-sourcecode script is explicitly using python 2.5. That looks like the packaging is broken somewhere then -- if bzr-svn is installed in the 2.5 area but python-subvertpy is not, which is what it looks like, then that's a bug that has nothing to do with Launchpad. Where are your bzr-svn and python-subvertpy packages from? Moreover, where's your python2.5 bzrlib from? A lucid install shouldn't have one. Oh. Gosh. Somehow, my upgraded Lucid system doesn't have a python2.5 bzrlib, but yes, a fresh install of python2.5-minimal does trigger it to be linked/bytecompiled for 2.5. Right. OK, this all makes sense. Not sure what, if anything, we should do about it, but it makes sense. When I remove that 2.5 to make it use the system python, all seems well. Is there a good reason for this script to use 2.5 or can I commit a change to make it use the system python? Using the system python would probably be OK, but I think finding/fixing the real bug would be better. I've been meaning to propose a branch to change update-sourcecode to use the system python too, for a different reason. As I mention above, a Lucid system doesn't have bzrlib available under /usr/bin/python2.5. I view using the system python as the correct approach for update-sourcecode: Note that in a fresh invocation of rocketfuel-setup, rocketfuel-setup will call rocketfuel-get which will call update-sourcecode BEFORE anything buildout-ish happens. I still think that using the system python for update-sourcecode is the right thing to do. Max. ___ 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] Remove spidermonkey-bin from launchpad-developer-dependencies?
Micah Gersten wrote: Max, Here's the patch you need: http://bazaar.launchpad.net/%7Emozillateam/xulrunner/xulrunner-1.9.2.head/annotate/head%3A/debian/patches/fix-build-glitch.patch Ah, thanks. Matches what I independently came up with :-) I've debugged the underlying cause and will be submitting a patch to make upstream and Debian. Also, are you planning on including this in the archive or just the PPA? For the purposes of the archive, I have this bug open: https://bugs.edge.launchpad.net/ubuntu/+source/xulrunner-1.9.2/+bug/536950 I'd love to not have to maintain this in the PPA, but asac's comment in that bug doesn't sound very positive. Max. On 03/12/2010 08:21 PM, Max Bowsher wrote: Julian Edwards wrote: So it looks like we need to revert to using the slow rhino. I've figured out a evil/clever hack to build a spidermonkey-bin in lucid :-) 1) The Debian packaging of xulrunner is completely unrelated to the Ubuntu packaging. 2) ... and it still builds js/spidermonkey. 3) js/spidermonkey despite building from the xulrunner source, doesn't depend on it. 4) Therefore just build the Debian xulrunner source in Ubuntu, having first hacked out the final building of all the .debs except the spidermonkey ones :-) I'll get it into the Launchpad PPA once I've worked around an architecture-specific bug in make or dash that's causing it to FTBFS on amd64. 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] Remove spidermonkey-bin from launchpad-developer-dependencies?
Francis J. Lacoste wrote: On March 10, 2010, Bjorn Tillenius wrote: On Wed, Mar 10, 2010 at 02:47:41AM +, Max Bowsher wrote: launchpad-developer-dependencies depends on spidermonkey-bin. This package has been removed from lucid. ... Does anyone know why it was added, and if we may remove it? Lazr-js uses it for jslint. It uses it indirectly, though. It uses /usr/bin/js, which points to /etc/alternatives/js, which points to /usr/bin/smjs. Yep, jslint supports the rhino JS interpreter, but it's like 10x slower. I've filed https://bugs.edge.launchpad.net/ubuntu/+source/xulrunner-1.9.2/+bug/536950, lets see what the Ubuntu mozilla team do. Unfortunately, the Mozilla build system is sufficiently baffling that I don't think re-introducing it in the PPA is a workable interim solution. 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] Developping Launchpad on Lucid
Robert Collins wrote: python2.5 is not in Lucid anymore, so I expect that to be an issue for folk :) For now, it's in the Launchpad PPA. But yes, this ups the urgency of moving to Python 2.6. 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] adding PIL 1.1.7 to launchpad-developer-dependencies
Edwin Grubbs wrote: I finally got around to doing this, and I ran into a subtle issue. launchpad-dependencies depends on python2.5-imaging, and the python-imaging package provides python2.5-imaging. However, when I add (= 1.1.7) to launchpad-dependencies' debian/control file, it complains that it python2.5-imaging is not installed. Should python-imaging's Provides list be changed somehow, or should I just change launchpad-dependecies to depend on python-imaging instead of python2.5-imaging? Ah, right, I see what's going on. dpkg only supports versioned dependencies on real packages, not virtual packages declared with Provides. So, what we will need is: Depends: ..., python-imaging (= 1.1.7), python2.5-imaging, ... thus enforcing the version against the real package, whilst also enforcing that it provide for the specific python version we care about. 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] Trouble with initialize-from-parent.py and maybe the sampledata
Max Bowsher wrote: I've prepared a branch: https://code.edge.launchpad.net/~maxb/launchpad/ignored-asserts which fixes some assert statements which were inadvertently having no effect. It fails tests, because an assert which apparently should have been triggering all along now triggers. The problem is the test of initialize-from-parent.py, which is used to test initialization of a new series parented from ubuntu/hoary - except apparently the sampledata ubuntu/hoary has pending builds, which fails the assert. 1) Is there anyone who knows about initialize-from-parent.py and could suggest an alternate series with pending builds that could be used in uh, *without* - oops :-) this test without otherwise sacrificing test coverage? 2) If not, can anyone advise me how best to familiarize myself with the existing Soyuz sampledata, such that I could attempt to fix the test? 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] adding PIL 1.1.7 to launchpad-developer-dependencies
On 04/02/10 19:23, Edwin Grubbs wrote: Hi, PIL will be used for the new script for generating the combined sprite image from the individual image files. python-imaging 1.1.7 provides much better PNG compression than previous versions, and it is already packaged for lucid. I want to add it to the launchpad PPA and then to launchpad-developer-dependencies. Is it still necessary to have launchpad-developer-dependencies support jaunty, or can I just backport PIL to hardy and karmic? If jaunty is no longer supported, I can also remove the other packages for it in the PPA and update the wiki. I'd find it difficult to justify continued support for Jaunty if it was going to require significant effort, but in this case it looks like a no-change upload will suffice for Jaunty and Karmic - I've just done one in https://edge.launchpad.net/~maxb/+archive/launchpad/+packages to test. Therefore, we might consider continuing to support Jaunty until some other issue comes up which makes dropping it worth our while. The Hardy builds however ended up with unsatisfied build-deps, so will need a bit more tweakage. Max. ___ 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 04/02/10 22:03, James Westby wrote: On Mon, 01 Feb 2010 18:32:34 -0800, James Westbyjw+deb...@jameswestby.net wrote: Hi, I'm at the Canonical Ubuntu sprint and we were just discussing python versions. The current plan is that there will only be 2.6 and 3.1 in lucid. python2.5 in lucid is in its final days. In which case, I think we shall raise three cheers for the ability to copy deleted packages from the primary archive into a PPA to resurrect them - At least as a transitional measure for development, anyway :-) Max. ___ 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] adding PIL 1.1.7 to launchpad-developer-dependencies
On 05/02/10 01:54, Michael Hudson wrote: Edwin Grubbs wrote: Hi, PIL will be used for the new script for generating the combined sprite image from the individual image files. python-imaging 1.1.7 provides much better PNG compression than previous versions, and it is already packaged for lucid. I want to add it to the launchpad PPA and then to launchpad-developer-dependencies. Will the results of combining the images be checked into the tree, or something 'make build' does? If the latter, PIL will need to be in launchpad-dependencies, not launchpad-developer-dependencies. Is it still necessary to have launchpad-developer-dependencies support jaunty, or can I just backport PIL to hardy and karmic? If jaunty is no longer supported, I can also remove the other packages for it in the PPA and update the wiki. launchpad-developer-dependencies was uninstallable on Jaunty for a few months until just a few minutes ago I think, and noone complained... OK, so maybe it really is obsolete now :-) Leave it up until the next issue with it arises? Delete it now? I don't really mind. Either way, there are now PIL 1.1.7 packages for hardy jaunty and karmic queued in ~maxb/+archive/launchpad ready for copying across pending a conclusion in this thread. Max. ___ 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] Changing the importer for oauth from cscvs to bzr-svn
On 20/01/10 20:49, Tim Penhey wrote: The oauth project is hosted on googlecode. bzr-svn is better at pulling from there It is easy to register a new import and disable the old one, however launchpad-pqm has its own oauth branch. Can we move to change our launchpad oauth branch to be based on a bzr-svn based import? Do we have much outstanding from trunk? Looking at the loggerhead view, apparently the ~launchpad-pqm branch has never had any off-trunk changes made to it in the first place. Max. ___ 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] How to enable Bugmail in stand-alone installation
On 13/01/10 13:00, Daniel Bültmann wrote: Dear all, I have installed launchpad for internal usage within our organisation. How have you dealt with the restrictive licensing of the branding and images? I'd be quite eager to promote Launchpad usage within my own organization, but have found that to be a complete blocker. Max. ___ 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] Build engineer report, Dec 2009
Maris Fogels wrote: I must often run 'rocketfuel-get', 'link-external-sourcecode', 'make', and 'make schema' to create a branch, and that means five to ten more minutes of waiting to start work on the actual problem. (Unfortunately I can not time those steps right now: perhaps someone else could?) Why are rocketfuel-get and 'make schema' part of your branch creation process? Surely those are more things that need doing every so often rather than things that need doing to start a new branch. 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] Can we drop 'ssh' from launchpad-developer-dependencies?
Max Bowsher wrote: Max Bowsher wrote: Guilherme Salgado wrote: Yeah, but I should've added openssh-client instead of ssh (which brings in the -server package too). I guess no one will object to have lp-dev-deps depend on openssh-client, even though it doesn't seem to be a real dependency, right? Well, if we can produce no rationale for even openssh-client being a dependency, let's just drop it entirely? I've got a test run in progress with openssh-client and openssh-server removed. Let's see what happens. https://code.edge.launchpad.net/~maxb/meta-lp-deps/no-sshd/+merge/16275 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] Can we drop 'ssh' from launchpad-developer-dependencies?
Guilherme Salgado wrote: Yeah, but I should've added openssh-client instead of ssh (which brings in the -server package too). I guess no one will object to have lp-dev-deps depend on openssh-client, even though it doesn't seem to be a real dependency, right? Well, if we can produce no rationale for even openssh-client being a dependency, let's just drop it entirely? 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] Can we drop 'ssh' from launchpad-developer-dependencies?
Max Bowsher wrote: Guilherme Salgado wrote: Yeah, but I should've added openssh-client instead of ssh (which brings in the -server package too). I guess no one will object to have lp-dev-deps depend on openssh-client, even though it doesn't seem to be a real dependency, right? Well, if we can produce no rationale for even openssh-client being a dependency, let's just drop it entirely? I've got a test run in progress with openssh-client and openssh-server removed. Let's see what happens. 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] [Branch ~launchpad-pqm/launchpad/devel] Rev 9943: [r=gary][ui=none] change our sourcecode script to honor revisions;
Aaron Bentley wrote: Max Bowsher wrote: What if we went to sourcecode branches for anything we patch at all *but* we built eggs from them? I don't know what you mean. We already create branches on launchpad like lp:~launchpad/bzr/2.0.0-lp whenever we have to patch, and then we make distribution tarballs out of them. Is that what you mean? I was meaning skip making the tarball, and use the branch directly as the input for buildout to use to populate the eggs/ directory. But you point out lower down that there are speed issues in scanning many branches for updates individually. Hmm. I generally leave a multi-pull running on sourcecode/ and go do something else, so it doesn't bother me all that much. Aaron Bentley wrote: And ultimately, what if we had only a single copy of each package in a given revision? Then the versions.cfg could be replaced with a single revision-id. A caveat: we'd have to branch lp-source-dependencies for every launchpad branch with differing dependency requirements. No, we can just pull to whatever revision we need. Maybe not even that. Depends on how good our tool support is. OK, maybe you don't need more than one branch for devel/db-devel/stable/db-stable all together, but what about developer branches outside the primary four? E.g. during the Python 2.5 sprint, how would that have worked in this system? There's got to be the possibility for divergent evolution of dependency versions - e.g. the Python 2.5 sprint has upgraded Zope to new major versions, and now mainline needs a minor version bump of some Zope module too. 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] [Branch ~launchpad-pqm/launchpad/devel] Rev 9943: [r=gary][ui=none] change our sourcecode script to honor revisions;
Aaron Bentley wrote: Michael Hudson wrote: nore...@launchpad.net wrote: [r=gary][ui=none] change our sourcecode script to honor revisions; change our sourcecode list to include revisions. Yay. I wonder if we should go back to this for bzr, specifically. Using releases is great and all, but we're so tightly bound to this particular project and committing a 5 meg tarball for each patch we find ourselves needing for it doesn't seem sane. I agree that committing a 5 meg tarball for each patch we find ourselves committing doesn't seem sane. But I think that bzr is only an extreme case of a problem that affects the current download-cache design. It is strange to have a branch to which you only ever add files. Why not make that an rsyncable location instead? That would give people a chance to avoid downloading irrelevant tarballs. Is it just that we've got lots of tools for managing branches and few tools for managing rsyncable locations? Better yet, why not take proper advantage of our VCS? If we stored ungzipped tars, the incremental cost of adding a tarball could be quite low, because bzr would be able to groupcompress the tarball against the previous version. Wouldn't taking full advantage of our VCS involve unpacking the tarball, so you can use diff, log on individual files, etc.? Which nicely leads into... What if we went to sourcecode branches for anything we patch at all *but* we built eggs from them? This would require some care in ensuring the internal version numbers were bumped such that the eggs had appropriate versions in their names, and might require some interesting mapping to pull the right rev-id for a given build, *but* would allow us to have eggs, rather than a web of symlinks whilst still retaining full usage of bzr to branch from upstream and apply patches in an obvious, visible, browseable manner. And ultimately, what if we had only a single copy of each package in a given revision? Then the versions.cfg could be replaced with a single revision-id. A caveat: we'd have to branch lp-source-dependencies for every launchpad branch with differing dependency requirements. We could even extract the tarballs-- AIUI directories are acceptable eggs. Do you mean acceptable sourcedists to use to build eggs? Interesting. I think I like the idea, but I think I like putting each distinct project into its own branch more. 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] A picture showing why edge can be slow
Jeroen Vermeulen wrote: Maris Fogels wrote: Note that this picture was taken on edge. On edge we suffer through this with every new revision, as that changes the file URLs and forces us to fetch everything anew. I don't suppose there's some way of cheating our way around that for unchanged files? Embed an md5sum of the file in its filename, and don't include the revision in the url? 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
[Launchpad-dev] When updating meta-lp-deps, please remember....
When updating meta-lp-deps, please remember 1) To copy the package to all supported series. 2) To tag the upload in bzr. You can use bzr mark-uploaded to automatically set a tag named from the top entry in debian/changelog. I've copied the most recent upload to jaunty and added the missing tags for all the recent uploads. 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] Segfault in bin/test? A workaround.
Gavin Panella wrote: Henning and Graham this morning had segfault issues, and Brad did yesterday. Here's a workaround that Brad and I figured out yesterday that seems to work okay: . ~/.rocketfuel-env.sh cd $LP_SOURCEDEPS_PATH/twisted bzr clean-tree --ignored --force make PYTHON=python2.5 The Twisted Makefile has python2.4 hardcoded. This is something we should fix. Anyone want to do that? So do pygettextpo and pygpgme. It's not supposed to matter, because sourcecode/Makefile passes down the appropriate overriding variables. I wonder why that didn't happen. 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] Error during Launchpad environment setup (was Fwd: Traceback)
Jonathan Lange wrote: Hello folks, I've got a USB stick that I'm passing around that will help people get a Launchpad development environment set up. It's got a repository and a slightly modified rocketfuel-setup[1]. The first person to try this version of the stick got as far as a successful 'make schema', but when he tried to 'make run', he got the error below. What's going on? How can we work around this? [1] Footnote is missing. Did you run utilities/launchpad-database-setup ? 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] Python 2.5 upgrade: notes
Gary Poster wrote: (1) Please update launchpad-dependencies on your dev boxes. (2) Staging is running the Python 2.5 branches. If you want to do a bit of QA, poke around! We still need to QA Mailman, which we plan to set up and do tomorrow. (3) Things look good for a merge of the Python 2.5 branches this coming Monday. Please keep an eye for fallout on edge after that, and let us know if you see a related problem. Gary, First, woot! Second, don't forget to also copy launchpad-dependencies 0.56 from karmic to jaunty in the PPA. 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] Proposal: Officially cease support for building Launchpad on Intrepid, or bring the Launchpad PPA up to date
Max Bowsher wrote: I suggest that all packages be deleted from Intrepid in the Launchpad PPA. Given the impending 2.4 - 2.5 move, the intrepid launchpad-dependencies is *really* out of date. I reiterate my suggestion. 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] Proposal: Officially cease support for building Launchpad on Intrepid, or bring the Launchpad PPA up to date
Francis J. Lacoste wrote: On October 6, 2009, Michael Hudson wrote: Max Bowsher wrote: The dev wiki currently claims that you can build LP on Hardy through Karmic. Given the current state of the Launchpad PPA for Intrepid (old launchpad-dependencies version), that's a bit of a fib. We ought to resolve this situation one way or another. From Canonical's POV, I don't think we care at all about Intrepid any more. So it would only be a problem if not supporting Intrepid hindered a community developer -- and it seems reasonably likely that someone ambitious enough to be trying Lauchpad development won't be on Intrepid any more. So I guess that's +1 from me for ceasing to pretend Lauchpad works on Intrepid. Yep, let's drop Intrepid support. We can probably also drop Jaunty support after the next Ubuntu release. All Lauchpad developers should be on Karmic already, but let's give them some breathing space. So, we need to support Hardy (for deployment) and Karmic (for development). We should drop Intrepid support now and Jaunty support in one month. I've edited the wiki to reflect non-support for Intrepid. I suggest that all packages be deleted from Intrepid in the Launchpad PPA. I think we should continue to support Jaunty for a bit longer - perhaps until the release of Lucid, assuming this doesn't require too much work. 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] Workflow broken by different rich-roots
Aaron Bentley wrote: Max Bowsher wrote: Hmm... it would be nifty if bzr init-repo would create a repository with format undecided which would lazily transform into pack-0.92 or 2a depending on the rich-root-ness of the first revision being entered into it :-) undecided repositories would encourage people to stick with pack-0.92, and we don't want that. Having different inventory models in play just leads to pain and format confusion. With the release of bzr 2.0, we signalled that everyone should be using rich-root formats from now on. Our default format, 2a, is rich-root, and has no non-rich variant, deliberately because it's reasonable to have a watershed at 2.0. You should use 2a if you don't need to be compatible with bzr versions older than 1.16. If you need to be compatible with anything since 1.0, you can use rich-root-pack. It's not me making the choice of rich-root or not. The current situation means that EVERY TIME I try to start looking at a new project, I have to first check whether they are rich-root or not BEFORE I can run bzr init-repo. Which is a hideous user experience. 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] Workflow broken by different rich-roots
Barry Warsaw wrote: On Nov 7, 2009, at 10:30 AM, Max Bowsher wrote: The current situation means that EVERY TIME I try to start looking at a new project, I have to first check whether they are rich-root or not BEFORE I can run bzr init-repo. Which is a hideous user experience. Not only that, but there's no clear way to know what the right invocation of init-repo is. If you look at the branch on Launchpad, you see something like Branch metadata Branch format: Repository format: Branch format 6 Packs containing knits without subtree support Hookay... but it says nothing about what option I should give to init-repo. Probably up at the top of the page, Launchpad should say: Get this branch: bzr branch lp:launchpadlib Update this branch: bzr push lp:launchpadlib Create a shared repository: bzr init-repo --pack-0.92 launchpadlib (or whatever) And not only is it rich-root that's the problem. I just got different serializers trying to push a branch of bzrtools. So not only do you need to check if it's rich-root, you also need to take into account 2a vs. knitpack rich-root, such that you create the right kind of repo that will actually allow you to create stackable revisions. 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] How long does it take you to SSH to bazaar.launchpad.net?
Francis J. Lacoste wrote: On October 26, 2009, Guilherme Salgado wrote: Did you have that ControlMaster trick enabled in your ssh config and an open connection to bazaar.lp.net when you got those numbers? I wouldn't be surprised if not, as you were in the London office, but others might have it enabled and have forgotten about it. From my office in West London: 0m0.389s 0m0.320s 0m0.706s 0m0.321s 0m0.225s and with a ControlMaster alive: 0m0.218s 0m0.093s 0m0.100s 0m0.097s 0m0.096s Where is this trick documented again? I don't have it, but it would probably make sense to enable it. man ssh_config, essentially. Basically, you set a ControlPath in your .ssh/config - e.g. like so: ControlPath ~/.ssh/mux...@%h:%p and then when you feel like it, you can fire up a ssh connection like so: ssh -oControlMaster=yes -f -N bazaar.launchpad.net which will be a ControlMaster, by listening on an AF_LOCAL socket and allowing other ssh processes to multiplex their connection requests down the existing tunnel, avoiding TCP and SSH connection setup time. (-f - go to the background after connection established, -N - do not run any command ) It certainly speeds up, say, pulling all the branches in an entire LP sourcecode directory! 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
[Launchpad-dev] Sync request from ~maxb/launchpad to ~launchpad/ppa
Please sync the following from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): python-apt 0.7.13.2ubuntu4launchpad~maxb1 (update tracking karmic) 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] Sync request from ~maxb/launchpad to ~launchpad/ppa
Max Bowsher wrote: Please sync the following from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): python-apt 0.7.13.2ubuntu4launchpad~maxb1 (update tracking karmic) Ignore that. Something unexpected happened and it hasn't built right. 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
[Launchpad-dev] Sync request from ~maxb/launchpad to ~launchpad/ppa
For real this time... Please sync the following from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): python-defaults 2.6.4~rc1-0ubuntu1launchpad~maxb1 (update tracking karmic) python-apt 0.7.13.2ubuntu4launchpad~maxb2 (update tracking karmic) 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] Launchpad development with Atom?
stuart.bis...@canonical.com wrote: Anyone out there doing Launchpad development with an Atom CPU? Does it work ok? Well, it runs fine. But at 9h15m to run the testsuite, you'd better be patient. 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] Call for Suggestions: Making it easier to start hacking on Launchpad
Jonathan Lange wrote: Hey guys, The last time I sat down with a keen potential Launchpad hacker and got them set up with Launchpad, it took about six hours. Granted, this was on Karmic before Max Bowsher et al made it actually possible to use Karmic. But it's still a long time. What can we do to make it easier to go from I want to hack on Launchpad to I have a running development instance of Launchpad? This might be a minority view, but personally I'm of the opinion that getting a Launchpad dev instance up and running is sufficiently simple and documented already. The hard part is not the setup, its learning enough about the code to write useful changes. 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
[Launchpad-dev] Sync request from ~maxb/launchpad to ~launchpad/ppa
Please sync the following from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): python-defaults 2.6.3-0ubuntu1launchpad~maxb1 (update tracking karmic) 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] Proposal: Remove people.canonical.com/~herb/ tarball
Karl Fogel wrote: Max Bowsher m...@f2s.com writes: I think we should remove the people.canonical.com/~herb/ tarball. 1) It's of db-devel, not devel. Not what a beginner developer wants. 2) It's a standalone tree, not a shared repository plus branch, as is customary for LP development. 3) It's badly affected by early 2a fragmentation, a modern bzr version packs that repository down from 219MB to 150MB. 4) It ships a working tree, if the goal is to minimize download size, that's counterproductive. 5) It's sufficiently out of date at this point that you still have ~25MB to pull it up to date. Alternatively we could rectify all of the above and republish it. IMHO, we should remove it simply because it will be ongoing complexity if we don't. Oh, that too :-) Accordingly I've removed the link from https://dev.launchpad.net/Getting. 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
[Launchpad-dev] https://dev.launchpad.net/API Authenticated Access Only needs rationale
Quoting https://dev.launchpad.net/API: Authenticated Access Only By design, there is no anonymous access through the API. You can do read-only access (through a read-only token) but not anonymous access. All API use is accounted to a person. Why? Please feel free to respond in the form of a wiki edit :-) 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] https://dev.launchpad.net/API Authenticated Access Only needs rationale
Karl Fogel wrote: Max Bowsher m...@f2s.com writes: Quoting https://dev.launchpad.net/API: Authenticated Access Only By design, there is no anonymous access through the API. You can do read-only access (through a read-only token) but not anonymous access. All API use is accounted to a person. Why? Please feel free to respond in the form of a wiki edit :-) I'll answer here, and see if anyone follows up with more (or more correct) information, before we put this in the wiki. My understanding is that it's a way to have some safeguard against [possibly accidental] DoS. If all accesses are authenticated, then if someone does something that causes a problem, we can shut off just that person's API access. (Presumably, we'd then try to contact them and figure out a better solution.) The obvious followup question, then, is: Why is this treated any differently to someone abusively screenscraping information from Launchpad webpages? 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
[Launchpad-dev] Sync request from ~maxb/launchpad to ~launchpad/ppa
Please sync the following from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): pycxx 5.5.0-0ubuntu2~launchpad1 (which is itself a copy from ~launchpad/ppa jaunty series) pysvn 1.7.0-1ubuntu3launchpad~maxb1 (update tracking karmic) Max. 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 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] Sync request from ~maxb/launchpad to ~launchpad/ppa
Max Bowsher wrote: Please sync the following from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): pycxx 5.5.0-0ubuntu2~launchpad1 (which is itself a copy from ~launchpad/ppa jaunty series) pysvn 1.7.0-1ubuntu3launchpad~maxb1 (update tracking karmic) Actually make that 1.7.0-1ubuntu3launchpad~maxb2. Seems I was a little too trusting assuming that the package uploaded to karmic primary would actually *work*. 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] Sync request from ~maxb/launchpad to ~launchpad/ppa
Max Bowsher wrote: Max Bowsher wrote: Please sync the following from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): pycxx 5.5.0-0ubuntu2~launchpad1 (which is itself a copy from ~launchpad/ppa jaunty series) pysvn 1.7.0-1ubuntu3launchpad~maxb1 (update tracking karmic) Actually make that 1.7.0-1ubuntu3launchpad~maxb2. Seems I was a little too trusting assuming that the package uploaded to karmic primary would actually *work*. Actually, make that 1.7.0-1ubuntu4launchpad~maxb1, I got rapid sponsorship for upstreaming the fix, so bumping the version number correspondingly. 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] Using reStructured Text instead of moin syntax in the wiki?
Karl Fogel wrote: Barry Warsaw wrote in http://tinyurl.com/n7y27f: Thanks to our fantastic IS department, you can now use reStructuredText markup in our dev and help wikis. I highly encourage you to use reST format instead of moin, as we're standardizing on Python's own de-facto standard of reST markup. This is actually a big change, and we should think about it carefully. I'm fluent in Moin and have never touched reST in my life, so my reaction is pretty much GAH :-(. 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] meta-lp-deps bzr maintenance
Max Bowsher wrote: 2) The non-trunk branches of https://code.edge.launchpad.net/~launchpad/meta-lp-deps are currently broken by https://bugs.edge.launchpad.net/launchpad-code/+bug/377519 Can someone fix this directly or do I need to ask the LOSAs? Yes, it needs LOSA intervention - branch writers can fiddle the sftp-exposed copy, but the http-exposed copy of the branch would remain broken. I've filed a question. 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
[Launchpad-dev] Sync request from ~maxb/launchpad to ~launchpad/ppa
Please sync the following updated versions from ~maxb/launchpad (karmic) to ~launchpad/ppa (karmic): python-apt 0.7.13.2ubuntu2launchpad~maxb2 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
[Launchpad-dev] First meta-lp-deps MP
I've filed the first MP for meta-lp-deps: https://code.edge.launchpad.net/~maxb/meta-lp-deps/ready-for-karmic/+merge/11094 sinzui has kindly given it a review already. We're pretty much making the procedure up as we go along here, but the next steps probably involve: Deciding what level of testing is required before copying the package to jaunty as well as karmic. Getting final signoff from a Launchpad Foundations member. Me then doing s/UNRELEASED/karmic/ on the changelog in the branch, tagging it, uploading it to my PPA, and then a ~launchpad member pull-pushing the branch into trunk and copying the built packages form my PPA to the official one. 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
