[00:08] doctormo, launchpadlib is pretty shallow [00:08] basically what robert said: " should be pretty straight forward with liboauth and libjson & libcurl to write a client" [00:09] poolie: Would it be dynamic or would it have to shadow the api? [00:09] what do you mean? [00:09] orthogonally, when you say 'python is slow' i'd like to know which bits in particular [00:10] it certainly can be slow [00:10] but wrt talking to launchpad, the network is almost certainly going to be the slow bit, not the python [00:13] poolie: The network is the slow bit, python just gets slow when your starting apps. The rest is fairly ok. [00:13] poolie: Did the launchpad guys figure our their indexing/searching issues for bugs? [00:13] load time is annoying in bzr [00:14] i'm surprised it shows up for a gui [00:14] poolie: I don't understand [00:15] " python just gets slow when your starting apps" -- i'm surprised that it's noticeable starting a gui [00:15] 500ms for a command-line thing shows up; for launching a gui i think it would not be noticeable [00:15] or is it much more? [00:17] 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] the most* [00:17] And that's all due to threading issues with gnome [00:17] So I'm trying to look at the problem from new angles. [00:26] doctormo, wow, that certainly sounds like it would suck [00:26] * poolie is curious about the bug [00:55] doctormo: we're still gathering feedback [00:55] 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] 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] lifeless: Yes, at the moment it's nonsensicle to hammer your server. [02:06] lifeless: Although I'm curious as to why your going for the java lucene instead of the python ready xapian. [02:06] doctormo: lucandra [02:07] doctormo: we have 250GB of content to index [02:07] doctormo: and enough load to keep 32 cores busy - today. [02:07] doctormo: thats db only, ignoring front end, ppa, imports etc. [02:08] lifeless: They're both comparable for speed/size. Lucandra looks like Solr, so still java based. [02:08] doctormo: right, and pysolr is the client we'd use. [02:08] Fair enough [02:08] 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] doctormo: final selection hasn't been done but: [02:09] - u1 are moving on cassandra [02:09] - xapian has no clustering story that I'm aware of [02:10] - and I know we need multiple machines capacity from day one [02:10] -1 for 'story' buzzword [02:10] shrug [02:12] lifeless: But yes, Xapian isn't threadsafe and has harsh write locks. [02:13] 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] doctormo: we'll be starting search work late 2011 I suspect [02:14] doctormo: current search is sql queries + tsearch2 [02:14] lifeless: I'll let you know if I get hit by a bus then in the meantime ;-) [02:14] thanks :) [02:14] SQL search, yum. === Ursinha is now known as Ursinha-away === bilalakhtar_ is now known as cdbs [09:53] hey guys i have a quick ppa question. is it possible to upload a .deb file directly to a ppa? [09:53] no [09:53] source only [09:54] :-/ ok [09:54] what would i need to do to upload a package to my ppa [09:54] https://help.launchpad.net/Packaging/PPA === Ursinha-away is now known as Ursinha [10:13] oh my, lp once again ate all my translations :P [10:18] :( [10:51] 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] 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 === matsubara-afk is now known as matsubara [13:26] hi, can someone delete this spam comment? https://bugs.launchpad.net/landscape-client/+bug/522668/comments/8 [13:27] losa: ^^^ [13:30] ahasenack: done [13:30] mthaddon: thanks [13:35] and another: https://bugs.launchpad.net/ubuntu/+source/rbot/+bug/604102/comments/5 [13:36] I'm getting bizarre errors when trying to run 'bzr up' on LP-hosted branches: http://paste.ubuntu.com/564441/ [13:36] does anyone know what might be going on here? [13:37] (AFAIK I don't have stale processes talking to that branch, and 'bzr break-lock' doesn't help) === oubiwann is now known as oubiwann_ [13:41] 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] 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] maxb: I have tried breaking the lock and it reoccurs [13:59] 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] Hm, that's pretty weird [14:01] 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] 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] grr, is fscking [14:30] cjohnston: ahahaha, I had a hunch, and it was right! [14:30] oops [14:30] cjwatson: [14:30] The problem is the URL-encoded ~ character in your branch path [14:30] Something in bzr must be comparing URLs as strings, and getting it wrong where non-canonical forms are used [14:31] However, my natty installation doesn't get those ImportWarnings, so something else is broken on yours [14:33] (no such warning here either) [14:42] maxb: it's been continuously upgraded, probably some python problem; I doubt it's relevant to this [14:42] maxb: so should I just rebind and let bzr recompute the branch path? [14:42] this has worked for ages [14:42] Yes (or just hack .bzr/branch/branch.conf) [14:43] It's clearly a bzr bug. it would be interesting to discover what broke it [14:43] 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] Out of 1029 .bzr/branch/branch.conf files on my system, 251 contain the string %7E [14:51] * cjwatson applies sed === matsubara is now known as matsubara-lunch === Lcawte|Away is now known as Lcawte [15:42] hey. when I try to do 'bzr update' on my bound branch of lp:ubuntu-qa-tools, I get: [15:42] $ bzr update [15:42] Unable to obtain lock held by jdstrand@bazaar.launchpad.net [15:42] at crowberry [process #29404], acquired 9 seconds ago. [15:42] See "bzr help break-lock" for more. [15:43] bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/ [15:43] if I do 'break-lock' and try again, I get the same thing [15:43] I had someone else try it as well, and they have the same problem [15:43] I'm on natty, and not sure if this is a bzr problem or launchpad problem [15:50] jdstrand, an hour ago, cjwatson reported something similar (here) [15:50] jdstrand: 'bzr bind lp:ubuntu-qa-tools' to fix up [15:50] jdstrand: apparently something is getting confused by URL-encoding [15:51] and rebinding (or sed -i 's/%7E/~/g' .bzr/branch/branch.conf) works around that [15:51] but i'm not seeing this (yet?) on my hundreds of active branches [15:51] i have a bunch of %7E too [15:51] fta: it was 251 out of 1029 for me, so it may depend on the version of bzr that bound them? [15:52] cjohnston, ok, i guess i know the workaround now, in case i hit this in the coming days :) [15:53] huh [15:54] interesting [15:54] cjwatson: thanks! === matsubara-lunch is now known as matsubara [16:06] uggh [16:29] 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] 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] maxb: I suppose I have to keep waiting till the delete takes affect === beuno is now known as beuno-lunch [17:12] benji, i would like the ability to use python-keyring to remove a password from the keyring. is this a feasible addition? [17:12] i find myself frequently removing passwords by hand so that i can test launchpadlib [17:13] leonardr: it should be; I think all the available backends have the ability to remove passwords [17:13] 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] maybe so === benji is now known as benji-lunch === dpm_ is now known as dpm === deryck is now known as deryck[lunch] === sinzui changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: sinzui | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ [17:57] hey [17:57] I've some trouble to push some branches (software-center ones and oneconf particularly) since the last hour [17:57] is there a known bzr hosting issue? [17:58] 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] sinzui: bing, since you're in the topic :-) [18:00] * sinzui looks [18:00] maxb, I can see the page so I may be able to help [18:01] just to confirm what didrocks experienced, I had the same problem earlier on today (I could not push a branch) [18:01] sinzui: ok, seems you miss my message ^^ [18:01] didrocks, dpm: What was the nature of the failures? Do you have an error message? [18:02] maxb: it's just stucking when pushing [18:02] didrocks: I know of may failures, but no operational issues at this time [18:02] like if the connexion had some issue [18:02] 2kB 0kB/s / [18:02] my I can ssh to even canonical servers without any issue, doesn't seem to be my connexion [18:03] so now, I can't even bzr break-lock bzr+ssh://bazaar.launchpad.net/~ubuntu-desktop/oneconf/trunk/ [18:03] maxb: can you see this https://code.launchpad.net/~jelmer/+archive/bzr-dailies [18:03] the command runs and stucked [18:03] same here on bzr push lp:~dpm/po2xpi/lucid-mozilla-upstream-locales [18:03] * sinzui thinks deleted archives break daily builds [18:03] sinzui: no, I can't [18:04] max okay I will look for a bug on this. [18:04] Write failed: Broken pipe -> this time on bzr break-lock [18:04] 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] maxb: I was thinking the same. We need two more requests [18:05] maxb: Or I cross my finders and toes and make you a member of ~registry [18:05] sinzui: heh. Well, it would come in useful for setting vcs-imports dev focus branches :-) [18:07] 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] sinzui: I have no problem with waiting, if you'd like to ask for permission instead. [18:07] ok, ssh people.canonical.com is also having issues now [18:08] dpm: same for you? [18:08] 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] didrocks: I will create a quick fork of the SC branch to see what happen when I push [18:09] sinzui: thanks [18:09] oh. It would appear that ~registry isn't the magic bit that lets you see it, then [18:09] sinzui: sometimes I can connect, slowly… [18:10] I have also some evo issue sometimes to connect to IMAP, seems all to be related to the DC connection === beuno-lunch is now known as beuno [18:10] all the rest is fine on my connexion. I can ssh on my own servers reliably, listen to radio/see online video [18:10] didrocks, p.ubuntu.com was slow for me as well, but I gave up thinking they were networking issues on my side [18:10] dpm: maybe not, see ^^ [18:11] hm, I see [18:11] let me try the earlier push again... [18:12] didrocks,dpm: the problem is apparently that something doesn't like URL-encoding in .bzr/branch/branch.conf [18:12] replace %7E with ~ in that file in your branch and it should work [18:12] oh, wait, I'm misreading, sorry [18:12] that problem doesn't explain a hang on push [18:13] cjwatson: I have ~ in it, not %7E there [18:14] ok, was able to push this time [18:15] will tell if the ssh connexion is still flacky there (and will try a network cable tomorrow to ensure) [18:15] time for dinner, see you :) [18:16] (and thanks!) === benji-lunch is now known as benji === zyga is now known as zyga-afk === Meths_ is now known as Meths === deryck[lunch] is now known as deryck [19:26] Trying to branch anything results in the following error [19:26] bzr: ERROR: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Bad status line received [19:26] Is that a known issue [19:29] kim0: what was your command that returned that error? [19:30] bzr branch lp:cloud-init [19:30] * sinzui tries [19:33] kim0: It works for me what do you get when you run `bzr launchpad-login` [19:34] bzr: ERROR: Connection closed: curl connection error (Proxy CONNECT aborted) [19:34] hmm I think it's an issue on my side then [19:35] 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] sinzui: nah, it seems I had a proxy defined .. that's it [19:36] sinzui: thnx, it's all good now [19:36] okay === matsubara is now known as matsubara-afk [21:56] 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] hm im getting: laudio_0.4-1.dsc: Version older than that in the archive. 0.4-1 <= 0.4-beta10-1 [22:01] Raydiation: 0.4-beta10 > 0.4-1. You probably wanted to use 0.4~beta10, as '~' < ''. [22:02] oh :/ [22:02] can i delete packages from launchpad? [22:02] You can, but that doesn't help the people who have already downloaded it. [22:02] apt will see that the new version is older, and not try to upgrade it. === smokex_ is now known as smokex [23:07] jwal: hi [23:07] jwal: most probably [23:09] 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] jwal: to be honest, I don't have any good ideas that don't add a lot of complexity to the system [23:12] 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] or perhaps we could require that certain tags be set [23:13] tags? [23:14] yes, bzr tags in the upstream branch [23:16] Have you considered whether substvars might help? [23:16] i.e. allowing debian/rules to make the version number [23:19] jwal: that doesn't work, as debian/rules doesn't get executed when we build the source package [23:24] Ok [23:26] So there aren't any existing hooks when building a source package? [23:35] jwal: no - all the information we have about building a source package is in the recipe [23:36] 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] jwal: that's just an idea - but yeah, the source tree would be readonly [23:38] 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] jwal: that wouldn't allow us to update the build dependencies in an automated fashion [23:39] Interesting, you are thinking that the build-dependencies should be derived from the upstream sources too? [23:39] there's a separate (but related) bug open about that [23:40] the build dependencies shouldn't necessarily be derived from the upstream sources but optionally be updated based on them [23:43] In that case, I think your original suggestion is probably the best solution. Sorry I caused so much confusion. [23:43] Who needs more than python anyway? [23:43] :) [23:44] heh [23:44] well, there are some fairly complex build systems out there, and extracting data from them might be nontrivial with just python [23:45] I also worry about dictating python be used [23:45] 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] The ability to install additional packages prior to this step could still be added later. Any ideas on the syntax for this step? === sinzui changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ [23:51] ...in the recipe [23:52] jwal: I'm worried about making the process to complex - we'd end up with three sets of dependencies [23:52] *too [23:55] three? is that somewhere between 2 and N? [23:55] jwal: one for the recipe, one for the source package and one or more for the binary packages [23:56] 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] jwal: that's what you're essentially proposing by putting it in the recipe