[00:08] <poolie> doctormo, launchpadlib is pretty shallow
[00:08] <poolie> basically what robert said: " should be pretty straight forward with liboauth and libjson & libcurl to write a client"
[00:09] <doctormo> poolie: Would it be dynamic or would it have to shadow the api?
[00:09] <poolie> what do you mean?
[00:09] <poolie> orthogonally, when you say 'python is slow' i'd like to know which bits in particular
[00:10] <poolie> it certainly can be slow
[00:10] <poolie> but wrt talking to launchpad, the network is almost certainly going to be the slow bit, not the python
[00:13] <doctormo> poolie: The network is the slow bit, python just gets slow when your starting apps. The rest is fairly ok.
[00:13] <doctormo> poolie: Did the launchpad guys figure our their indexing/searching issues for bugs?
[00:13] <poolie> load time is annoying in bzr
[00:14] <poolie> i'm surprised it shows up for a gui
[00:14] <doctormo> poolie: I don't understand
[00:15] <poolie> " python just gets slow when your starting apps" -- i'm surprised that it's noticeable starting a gui
[00:15] <poolie> 500ms for a command-line thing shows up; for launching a gui i think it would not be noticeable
[00:15] <poolie> or is it much more?
[00:17] <doctormo> poolie: I think it's the part where gc 1.x has to re-authenticate each time your press a button that agrivates users.
[00:17] <doctormo> the most*
[00:17] <doctormo> And that's all due to threading issues with gnome
[00:17] <doctormo> So I'm trying to look at the problem from new angles.
[00:26] <poolie> doctormo, wow, that certainly sounds like it would suck
[00:26]  * poolie is curious about the bug
[00:55] <lifeless> doctormo: we're still gathering feedback
[00:55] <lifeless> doctormo: on the technical side, we can clearly go and implement something to make substring matching work - e.g. wildspeed/pg_trg etc.
[00:56] <lifeless> doctormo: long term we're going to implement lucene, but  the big question is whether the current search rule /makes/ sense: and theres considerable evidence that it doesn't
[02:06] <doctormo> lifeless: Yes, at the moment it's nonsensicle to hammer  your server.
[02:06] <doctormo> lifeless: Although I'm curious as to why your going for the java lucene instead of the python ready xapian.
[02:06] <lifeless> doctormo: lucandra
[02:07] <lifeless> doctormo: we have 250GB of content to index
[02:07] <lifeless> doctormo: and enough load to keep 32 cores busy - today.
[02:07] <lifeless> doctormo: thats db only, ignoring front end, ppa, imports etc.
[02:08] <doctormo> lifeless: They're both comparable for speed/size. Lucandra looks like Solr, so still java based.
[02:08] <lifeless> doctormo: right, and pysolr is the client we'd use.
[02:08] <doctormo> Fair enough
[02:08] <doctormo> I had to hack Solr to get it to do what I wanted, but perhaps it'll be good for your data sets.
[02:09] <lifeless> doctormo: final selection hasn't been done but:
[02:09] <lifeless>  - u1 are moving on cassandra
[02:09] <lifeless>  - xapian has no clustering story that I'm aware of
[02:10] <lifeless>  - and I know we need multiple machines capacity from day one
[02:10] <doctormo> -1 for 'story' buzzword
[02:10] <lifeless> shrug
[02:12] <doctormo> lifeless: But yes, Xapian isn't threadsafe and has harsh write locks.
[02:13] <doctormo> lifeless: If you want, I can peer review your search and index filters and parser configuration. Assumign you're writing one for multiple fields?
[02:13] <lifeless> doctormo: we'll be starting search work late 2011 I suspect
[02:14] <lifeless> doctormo: current search is sql queries + tsearch2
[02:14] <doctormo> lifeless: I'll let you know if I get hit by a bus then in the meantime ;-)
[02:14] <lifeless> thanks :)
[02:14] <doctormo> SQL search, yum.
[09:53] <eagles0513875|2> hey guys i have a quick ppa question. is it possible to upload a .deb file directly to a ppa?
[09:53] <bigjools> no
[09:53] <bigjools> source only
[09:54] <eagles0513875|2> :-/ ok
[09:54] <eagles0513875|2> what would i need to do to upload a package to my ppa
[09:54] <bigjools> https://help.launchpad.net/Packaging/PPA
[10:13] <fta2> oh my, lp once again ate all my translations :P
[10:18] <dpm> :(
[10:51] <fta2> dpm, it's with a feedback loop, (i'm re-injecting the strings at each cycle), yet they still disappeared. maybe the next cycle will be ok. if not, i give up.
[10:54] <fta2> dpm, btw, i'm now able to land upstream (almost) everything for new langs. look at gl/eu/ug: http://people.ubuntu.com/~fta/chromium/translations/trunk/converter-output.html
[13:26] <ahasenack> hi, can someone delete this spam comment? https://bugs.launchpad.net/landscape-client/+bug/522668/comments/8
[13:27] <ahasenack> losa: ^^^
[13:30] <mthaddon> ahasenack: done
[13:30] <ahasenack> mthaddon: thanks
[13:35] <tumbleweed> and another: https://bugs.launchpad.net/ubuntu/+source/rbot/+bug/604102/comments/5
[13:36] <cjwatson> I'm getting bizarre errors when trying to run 'bzr up' on LP-hosted branches: http://paste.ubuntu.com/564441/
[13:36] <cjwatson> does anyone know what might be going on here?
[13:37] <cjwatson> (AFAIK I don't have stale processes talking to that branch, and 'bzr break-lock' doesn't help)
[13:41] <cjwatson> I don't think it's all branches though; I committed stuff to lp:~ubuntu-core-dev/netcfg/ubuntu earlier with no problem.  But lp:~ubuntu-core-dev/debian-installer/ubuntu has the same problem.
[13:57] <maxb> cjwatson: Have you tried breaking the lock? Does the problem re-occur? Are you able to state what operation left the lock behind?
[13:58] <cjwatson> maxb: I have tried breaking the lock and it reoccurs
[13:59] <cjwatson> maxb: the lock is very recent, as you can see in the log; AFAIK it must be being created during that same 'bzr up' itself
[14:00] <maxb> Hm, that's pretty weird
[14:01] <maxb> What bzr version, ooi? Also, those ImportWarnings suggest *something* is broken, though it's a bit of a long shot to suggest that they are related
[14:07] <cjwatson> maxb: up-to-date natty; bzr 2.3.0~beta5-1
[14:08]  * maxb fires up natty netbook to check for getting the same ImportWarnings or not
[14:13] <maxb> grr, is fscking
[14:30] <maxb> cjohnston: ahahaha, I had a hunch, and it was right!
[14:30] <maxb> oops
[14:30] <maxb> cjwatson:
[14:30] <maxb> The problem is the URL-encoded ~ character in your branch path
[14:30] <maxb> Something in bzr must be comparing URLs as strings, and getting it wrong where non-canonical forms are used
[14:31] <maxb> However, my natty installation doesn't get those ImportWarnings, so something else is broken on yours
[14:33] <fta2> (no such warning here either)
[14:42] <cjwatson> maxb: it's been continuously upgraded, probably some python problem; I doubt it's relevant to this
[14:42] <cjwatson> maxb: so should I just rebind and let bzr recompute the branch path?
[14:42] <cjwatson> this has worked for ages
[14:42] <maxb> Yes (or just hack .bzr/branch/branch.conf)
[14:43] <maxb> It's clearly a bzr bug. it would be interesting to discover what broke it
[14:43] <cjwatson> OK, that successfully works around the problem, thanks, but bzr put this there in the first place so I imagine you'll get more reports
[14:49] <cjwatson> Out of 1029 .bzr/branch/branch.conf files on my system, 251 contain the string %7E
[14:51]  * cjwatson applies sed
[15:42] <jdstrand> hey. when I try to do 'bzr update' on my bound branch of lp:ubuntu-qa-tools, I get:
[15:42] <jdstrand> $ bzr update
[15:42] <jdstrand> Unable to obtain lock  held by jdstrand@bazaar.launchpad.net
[15:42] <jdstrand> at crowberry [process #29404], acquired 9 seconds ago.
[15:42] <jdstrand> See "bzr help break-lock" for more.
[15:43] <jdstrand> bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/
[15:43] <jdstrand> if I do 'break-lock' and try again, I get the same thing
[15:43] <jdstrand> I had someone else try it as well, and they have the same problem
[15:43] <jdstrand> I'm on natty, and not sure if this is a bzr problem or launchpad problem
[15:50] <fta> jdstrand, an hour ago, cjwatson reported something similar (here)
[15:50] <cjwatson> jdstrand: 'bzr bind lp:ubuntu-qa-tools' to fix up
[15:50] <cjwatson> jdstrand: apparently something is getting confused by URL-encoding
[15:51] <cjwatson> and rebinding (or sed -i 's/%7E/~/g' .bzr/branch/branch.conf) works around that
[15:51] <fta> but i'm not seeing this (yet?) on my hundreds of active branches
[15:51] <fta> i have a bunch of %7E too
[15:51] <cjwatson> fta: it was 251 out of 1029 for me, so it may depend on the version of bzr that bound them?
[15:52] <fta> cjohnston, ok, i guess i know the workaround now, in case i hit this in the coming days :)
[15:53] <jdstrand> huh
[15:54] <jdstrand> interesting
[15:54] <jdstrand> cjwatson: thanks!
[16:06] <cjohnston> uggh
[16:29] <ChogyDan> I accidentally misversioned an upload to high to my ppa.  I deleted, and it still won't accept a fixed upload.  Will launchpad eventually recognize that the other upload is deleted, and accept the new upload?
[16:52] <maxb> ChogyDan: I believe it's supposed to accept lower versions if the higher has been deleted (but never duplicate versions with something already uploaded, even if they are deleted)
[16:53] <ChogyDan> maxb: I suppose I have to keep waiting till the delete takes affect
[17:12] <leonardr> benji, i would like the ability to use python-keyring to remove a password from the keyring. is this a feasible addition?
[17:12] <leonardr> i find myself frequently removing passwords by hand so that i can test launchpadlib
[17:13] <benji> leonardr: it should be; I think all the available backends have the ability to remove passwords
[17:13] <benji> it might be easier for you to write a little utility script that would just do what you want for your testing needs
[17:15] <leonardr> maybe so
[17:57] <didrocks> hey
[17:57] <didrocks> I've some trouble to push some branches (software-center ones and oneconf particularly) since the last hour
[17:57] <didrocks> is there a known bzr hosting issue?
[17:58] <maxb> https://code.launchpad.net/~bzr/+recipe/bzr-dbus-daily  <--- "Not allowed here" for me!   Can someone with superpowers (registry admin?) take a look and figure out what private object is bogusly leaking into that page?
[17:59] <maxb> sinzui: bing, since you're in the topic :-)
[18:00]  * sinzui looks
[18:00] <sinzui> maxb, I can see the page so I may be able to help
[18:01] <dpm> just to confirm what didrocks experienced, I had the same problem earlier on today (I could not push a branch)
[18:01] <didrocks> sinzui: ok, seems you miss my message ^^
[18:01] <maxb> didrocks, dpm: What was the nature of the failures? Do you have an error message?
[18:02] <didrocks> maxb: it's just stucking when pushing
[18:02] <sinzui> didrocks: I know of may failures, but no operational issues at this time
[18:02] <didrocks> like if the connexion had some issue
[18:02] <didrocks>      2kB     0kB/s /
[18:02] <didrocks> my I can ssh to even canonical servers without any issue, doesn't seem to be my connexion
[18:03] <didrocks> so now, I can't even bzr break-lock bzr+ssh://bazaar.launchpad.net/~ubuntu-desktop/oneconf/trunk/
[18:03] <sinzui> maxb: can you see this https://code.launchpad.net/~jelmer/+archive/bzr-dailies
[18:03] <didrocks> the command runs and stucked
[18:03] <dpm> same here on bzr push lp:~dpm/po2xpi/lucid-mozilla-upstream-locales
[18:03]  * sinzui thinks deleted archives break daily builds
[18:03] <maxb> sinzui: no, I can't
[18:04] <sinzui> max okay I will look for a bug on this.
[18:04] <didrocks> Write failed: Broken pipe  -> this time on bzr break-lock
[18:04] <maxb> hmm, so we can probably work around this by asking jelmer to request enough builds of the recipe that any reference to his old archive falls out of the top 5 :-)
[18:04] <sinzui> maxb: I was thinking the same. We need two more requests
[18:05] <sinzui> maxb: Or I cross my finders and toes and make you a member of ~registry
[18:05] <maxb> sinzui: heh. Well, it would come in useful for setting vcs-imports dev focus branches :-)
[18:07] <sinzui> maxb: I will as for forgiveness. Since you have more experience than the Ubuntu council members on the team, I will assume the ~registry team will want a rule permit cases such as yourself
[18:07] <maxb> sinzui: I have no problem with waiting, if you'd like to ask for permission instead.
[18:07] <didrocks> ok, ssh people.canonical.com is also having issues now
[18:08] <didrocks> dpm: same for you?
[18:08] <sinzui> maxb: We have made people temporary members in the past. You are a temporary member now. I will discuss the issue with the Lp team
[18:09] <sinzui> didrocks: I will create a quick fork of the SC branch to see what happen when I push
[18:09] <didrocks> sinzui: thanks
[18:09] <maxb> oh. It would appear that ~registry isn't the magic bit that lets you see it, then
[18:09] <didrocks> sinzui: sometimes I can connect, slowly…
[18:10] <didrocks> I have also some evo issue sometimes to connect to IMAP, seems all to be related to the DC connection
[18:10] <didrocks> all the rest is fine on my connexion. I can ssh on my own servers reliably, listen to radio/see online video
[18:10] <dpm> didrocks, p.ubuntu.com was slow for me as well, but I gave up thinking they were networking issues on my side
[18:10] <didrocks> dpm: maybe not, see ^^
[18:11] <dpm> hm, I see
[18:11] <dpm> let me try the earlier push again...
[18:12] <cjwatson> didrocks,dpm: the problem is apparently that something doesn't like URL-encoding in .bzr/branch/branch.conf
[18:12] <cjwatson> replace %7E with ~ in that file in your branch and it should work
[18:12] <cjwatson> oh, wait, I'm misreading, sorry
[18:12] <cjwatson> that problem doesn't explain a hang on push
[18:13] <didrocks> cjwatson: I have ~ in it, not %7E there
[18:14] <didrocks> ok, was able to push this time
[18:15] <didrocks> will tell if the ssh connexion is still flacky there (and will try a network cable tomorrow to ensure)
[18:15] <didrocks> time for dinner, see you :)
[18:16] <didrocks> (and thanks!)
[19:26] <kim0> Trying to branch anything results in the following error
[19:26] <kim0> bzr: ERROR: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Bad status line received
[19:26] <kim0> Is that a known issue
[19:29] <sinzui> kim0: what was your command that returned that error?
[19:30] <kim0> bzr branch lp:cloud-init
[19:30]  * sinzui tries
[19:33] <sinzui> kim0: It works for me what do you get when you run `bzr launchpad-login`
[19:34] <kim0> bzr: ERROR: Connection closed: curl connection error (Proxy CONNECT aborted)
[19:34] <kim0> hmm I think it's an issue on my side then
[19:35] <sinzui> kim0: possibly. I expected to see your Launchpad Id which I think is "kim0" and I see that profile as ssh keys registered
[19:35] <kim0> sinzui: nah, it seems I had a proxy defined .. that's it
[19:36] <kim0> sinzui: thnx, it's all good now
[19:36] <sinzui> okay
[21:56] <jwal> jelmer: Hi, are you the jelmer I have been discussing bzr recipe build version numbers with?  https://bugs.launchpad.net/launchpad/+bug/685571
[22:00] <Raydiation> hm im getting: laudio_0.4-1.dsc: Version older than that in the archive. 0.4-1 <= 0.4-beta10-1
[22:01] <wgrant> Raydiation: 0.4-beta10 > 0.4-1. You probably wanted to use 0.4~beta10, as '~' < ''.
[22:02] <Raydiation> oh :/
[22:02] <Raydiation> can i delete packages from launchpad?
[22:02] <wgrant> You can, but that doesn't help the people who have already downloaded it.
[22:02] <wgrant> apt will see that the new version is older, and not try to upgrade it.
[23:07] <jelmer> jwal: hi
[23:07] <jelmer> jwal: most probably
[23:09] <jwal> So, any ideas what could be done to fix the bug?  How do you think we might allow dependencies to be installed to help derive the "upstream" version number?
[23:12] <jelmer> jwal: to be honest, I don't have any good ideas that don't add a lot of complexity to the system
[23:12] <jelmer> jwal: I guess one of the options would be to just provide a reasonable set of dependencies by default and hope that's sufficient for the user to write a script that produces the upstream version string
[23:13] <jelmer> or perhaps we could require that certain tags be set
[23:13] <jwal> tags?
[23:14] <jelmer> yes, bzr tags in the upstream branch
[23:16] <jwal> Have you considered whether substvars might help?
[23:16] <jwal> i.e. allowing debian/rules to make the version number
[23:19] <jelmer> jwal: that doesn't work, as debian/rules doesn't get executed when we build the source package
[23:24] <jwal> Ok
[23:26] <jwal> So there aren't any existing hooks when building a source package?
[23:35] <jelmer> jwal: no - all the information we have about building a source package is in the recipe
[23:36] <jwal> jelmer: In your original bug report, you mention a script that prints the version number to stdout as a possibility.  Would this script be prevented from modifying the source tree somehow?
[23:37] <jelmer> jwal: that's just an idea - but yeah, the source tree would be readonly
[23:38] <jwal> jelmer: I guess we could install the build-dependencies after merging the branches but before running this script you suggest.  Would that work?
[23:38] <jelmer> jwal: that wouldn't allow us to update the build dependencies in an automated fashion
[23:39] <jwal> Interesting, you are thinking that the build-dependencies should be derived from the upstream sources too?
[23:39] <jelmer> there's a separate (but related) bug open about that
[23:40] <jelmer> the build dependencies shouldn't necessarily be derived from the upstream sources but optionally be updated based on them
[23:43] <jwal> In that case, I think your original suggestion is probably the best solution.  Sorry I caused so much confusion.
[23:43] <jwal> Who needs more than python anyway?
[23:43] <jwal> :)
[23:44] <jelmer> heh
[23:44] <jelmer> well, there are some fairly complex build systems out there, and extracting data from them might be nontrivial with just python
[23:45] <jelmer> I also worry about dictating python be used
[23:45] <jelmer> otoh, perhaps this is overengineering to make sure we can deal with every single weird package out there - rather than actually making something that works for 95% of everybody
[23:50] <jwal> The ability to install additional packages prior to this step could still be added later.  Any ideas on the syntax for this step?
[23:51] <jwal> ...in the recipe
[23:52] <jelmer> jwal: I'm worried about making the process to complex - we'd end up with three sets of dependencies
[23:52] <jelmer> *too
[23:55] <jwal> three?  is that somewhere between 2 and N?
[23:55] <jelmer> jwal: one for the recipe, one for the source package and one or more for the binary packages
[23:56] <jwal> You think that a separate set of build dependencies will be needed for the version number as for the binary package build dependencies?
[23:57] <jelmer> jwal: that's what you're essentially proposing by putting it in the recipe