[02:08] wgrant: nothing blew up with the slave build cookies so far? [03:16] jtv: I haven't tested it aggressively, but it seems to be OK. [03:17] wgrant: cool! [03:17] wgrant: I felt a bit bad about having an extensive national holiday after dropping a potential bombshell into the codebase, but I have have gotten lucky. :) [03:18] jtv: Heh. [07:13] argh, lplib is _so slow_ === almaisan-away is now known as almaisan === almaisan is now known as al-maisan [07:32] high time for lunch! [07:59] morning [09:26] hizello [09:27] Joñeaux! [09:28] Morning [09:33] wgrant: :D [09:34] mrevell: good morning [09:34] How jml [09:36] heyo jml the cruel [09:36] spm: what! I found it for you, didn't I? :P [09:37] lol [09:37] take 3 points for the comment; lose 3 for the cruelty. ;-) [09:40] wuu! it's like Fable 2 [09:40] How is it in the realms of ash today? [09:41] the usual: grey [09:41] but it's been awesome watching the tree outside my window slowly grow leaves and flowers [09:42] Heh. [11:04] Morning, all. [11:28] Hi, intellectronica. I believe bug 566351 might be related to recent bug heat changes. If not, it relates to heat calculation performance work you're doing. [11:28] Bug #566351: Unable to mark a bug as private (times out) [11:29] deryck: ok, will investigate. [11:30] intellectronica, thanks [12:07] deryck: i don't think it's related to that change (which is annoying, because if it isn't then why are we starting to see this now?) [12:08] that is, i don't think it's related to heat at all. the thing that times out is trying to subscribe the person marking the bug as private, and that happens before we do anything heat-related [12:11] intellectronica, I saw those 63 select bugjob statements, which seems to be where the timeout is. So I thought it must be related to heat. Or am I misreading that? [12:14] deryck: ah right, maybe it is heat-related, in that the job creation is triggered by adding a subscription. but it's not related to the immediate heat calculation (also i can reproduce on staging, which still doesn't have this change). [12:15] The distroseries index seems really slow now. [12:15] OOPS-1570EB719 === henninge_ is now known as henninge [12:18] intellectronica, ok, cool. so not new, but perhaps heat related then. [12:18] yes [12:53] bigjools: Bug #253509? [12:53] Bug #253509: Security contact subscribed when moving tasks [12:54] careful, you'll get called mpt soon :) [12:54] Nah, I filed this one. [12:55] yeah was gonna say [12:55] * bigjools sighs at the desktop getting slower the longer it's used [12:55] So, the security notification breakage is being fixed? [12:55] bigjools: Lucid? [12:55] yes [12:55] With a GEM-using graphics driver? [12:55] GEM? [12:56] grep "object bytes" /sys/kernel/debug/dri/0/gem_objects [12:56] no such file ... [12:56] it's nvidia [12:56] OK, so not the big GEM leak then. [12:56] Ah. [12:56] it also decides it can't start when I boot and goes to the "reconfigure X" dialog :/ [12:57] <3 proprietary drivers [12:57] I doubt this is a proprietary driver bug [12:57] it's a setup bug [12:57] the slowness, I dunno, however [13:00] bigjools: Can I somehow get hold of one of the new timestamped cron.publish-ftpmaster logs? [13:01] wgrant: yeah, one sec === mrevell is now known as mrevell-lunch [13:13] james_w, where are you on updating bzr-builddeb to avoid using the 'beta' service? i don't see any recent branches from you for that package [13:14] leonardr: it's done [13:15] james_w: great. do you think we're ready to push the new version of launchpadlib to lucid? [13:15] done as well [13:15] must have dropped you from CC, sorry [13:16] the only issue I've seen is with the launchpad bzr plugin [13:16] its hacked up version of web_link broke [13:18] james_w: is that also fixed? [13:18] not yet [13:18] i'm checking whether the software-properties problem is fixed [13:27] bigjools: Thanks. [13:27] it is fixed, great [13:27] welcome [13:28] bigjools: Also, any progress on the PPA log parser script setup? [13:29] wgrant: waiting on the RT [13:29] bigjools: Ah, great. Thanks! [13:29] will poke some people about that today [13:38] 2010-04-17 23:05:32 DEBUG Sorting sources... [13:38] 2010-04-17 23:07:51 DEBUG Dominating sources... [13:38] Wow. [13:38] That really doesn't need to take more than a second. [13:46] bigjools: Hm, the log stops rather abruptly. [13:46] wgrant: yeah it gets synced over to a different maching, they clashed [13:46] machine* [13:46] Ah :( [13:46] Still, apt-ftparchive is really extraordinarily slow. [13:47] yes, yes it is [13:48] if we can get the soyuz publisher to handle extra overrides, we'd be able to do a direct comparison [13:49] right, lunch time === mrevell-lunch is now known as mrevell [14:00] bigjools: A direct comparison will make you cry. [14:00] NMAF is probably around an order of magnitude slower. [14:05] sinzui, ping [14:05] hi deryck [14:22] bigjools: Shouldn't uploads to obsolete series in PPAs be rejected? [15:06] wgrant: cprov always maintained after you take everything into account, they were comparable [15:07] that's why I want full comparisons :) [15:07] and yes obsolete series should refuse PPA uploads [15:09] It's pretty easy to get NMAF up to around 6000 stanzas per second locally by caching them. But I'm not sure how much of a penalty extra overrides will be -- we can't safely cache them. [15:10] danilos, ping, did you get a chance to try the ec2 test patch? [15:12] mars, yes, see email [15:12] danilos, ah, thanks! [15:13] mars, in short works fine :) [15:13] and a big "ARGH" goes towards my busted mail filters [15:18] sinzui, do you remember what version of zope we were using before the 3.4.??? upgrade? [15:18] sinzui, it was 3.2somethingbeta I believe? [15:18] 3.2 + patches [15:19] mars: it was not an official release [15:19] sinzui, ok, thanks [15:20] wgrant: I expect it can be further improved quite easily, cStringIO etc and other critical parts compiled [15:28] adeuring, so the only surprise from running expiring script on staging was script perms? Does that mean none of the staging bugs got set EXPIRED? === deryck is now known as deryck[lunch] [15:43] gary_poster: ping [15:43] jml: i'd like your opinion on a couple new potential performance improvements [15:44] BjornT: pong [15:44] https://dev.launchpad.net/Foundations/Webservice/Performance#line-184 and the section beneath it [15:45] gary_poster: i'm trying to add http://pypi.python.org/pypi/repoze.sphinx.autointerface/0.3 to our buildout config, so that i can use that plugin in sphinx [15:45] leonardr: thanks. I'll take a look, but I'm on the phone from now until tomorrow :( [15:45] jml, no rush [15:46] gary_poster: however, it requires Sphinx >= 0.6.1, and even though i have 0.6.2 installed in the system python, buildout doesn't find it [15:47] gary_poster: anyway to tell buildout that "i actually have this package already", instead of adding sphinx and its dependencies to buildout? [15:48] BjornT: no, buildout should not use eggs from system Python. It only allows the underlying site-packages to be available. Doing anything else was even more rickety than what we are already doing. So, in this case, either get the repoze package in our PPA or something, or use Sphinx from a package buildout manages [15:49] gary_poster: ok, thanks [15:50] np [15:51] gary_poster: do you know who would be able to package a python module quickly? i guess it should be easy, but slow if you haven't done it before. [15:53] BjornT: I think you are right about "should be easy". :-) and Python packages in particular are tricky, I believe, maybe even esp. those with namespaces. I know U1 does it a lot. Maybe noodles775 would have other ideas? I unfortunately do not have experience with it myself, though I'd like to. [15:57] BjornT: I'd ask someone from U1 === bac` is now known as BradCrittenden === BradCrittenden is now known as bac [16:16] Hi all! Does this ring any bell? [16:16] context = gpgme.Context() [16:16] GpgmeError: (32, 176, 'Unknown error code') [16:16] adeuring: if you will be around in ~45 min, I'd like to talk about getting a good query for persons/teams in https://bazaar.launchpad.net/~kfogel/tuolumne-lp-configs/patches-time-to-closing/revision/40 . [16:17] henninge: nope, sorry [16:17] henninge: yes; it's fixed in lp:~launchpad-pqm/pygpgme/devel, but that hasn't landed yet because of other errors [16:17] jelmer, kfogel: thanks, good to know ;) [16:18] henninge: bzr pull the pygpgme sourcecode [16:18] then run make in the same dir, then in the devel dir, make clean [16:19] then it WFM [16:19] bigjools: cool, thanks [16:25] jelmer: About those other errors - do you have a plan? [16:41] hi leonardr, i'm having problems using lplib against a dev instance. have you seen anything like this before: http://paste.ubuntu.com/418662/ ? === deryck[lunch] is now known as deryck [16:45] bac: no, take a look at how the sock object is created [16:46] leonardr: sorry to bother you [16:46] turns out my apache wasn't running [16:47] ok === matsubara is now known as matsubara-lunch === beuno is now known as beuno-lunch [17:23] adeuring: ping [17:35] hi kfogel. I think he might be unavailable for a little while. [17:36] * deryck pinged earlier forgetting that [17:37] deryck: thx === gary_poster is now known as gary-lunch [18:12] g'night all === matsubara-lunch is now known as matsubara === beuno-lunch is now known as beuno === al-maisan is now known as almaisan-away === gary-lunch is now known as gary-poster === gary-poster is now known as gary_poster === dpm is now known as dpm-afk === salgado is now known as salgado-lunch === matsubara is now known as matsubara-afk [19:53] is make iharness working ? I'm trying to create a view and it enters an infinite loop [20:00] is there anything I could do to help solve https://launchpad.net/bugs/549041 or is that something ubuntu admins need to fix? (I'm not familiar with soyuz in any way [yet].) [20:00] Bug #549041: don't de-index source packages until they're due to be removed from disk === salgado-lunch is now known as salgado [21:05] hi leonardr, i'm trying to write some launchpadlib pagetests and i'm discovering some things that work as expected in an interactive lplib session but do not work in the test environment. [21:05] collection = lp_anon.project_groups.search(text="Apache") [21:05] throws a 405 [21:06] bac, can you paste the full httperror dump? [21:07] http://paste.ubuntu.com/418829/ [21:10] bac: given that 'allow' contains pretty much every http method there's probably something wrong with the http transport [21:11] can you also set httplib2.debuglevel = 1 and see what is sent? [21:11] leonardr: ok [21:14] Is there a non-admin launchpad.dev account that I can log in to? [21:15] I suppose I could just set a password for the cprov account or something like that, right? [21:18] leonardr: here is the output but the httplib2 debug was not generated for the call. it was shown for the call to login_anonymously but not the search. https://pastebin.canonical.com/30870/ [21:21] bac: 1. push your branch so i can try it [21:22] 2. do you know if other launchpadlib actions result in httplib2 dumps? [21:22] leonardr: 2) in the interactive env the search does generated debug output [21:22] 1) will do [21:23] bac: for 2) can you do something other than run this search and see if there's output? [21:24] sure [21:25] leonardr: lp:~bac/launchpad/bug-524778 [21:26] leonardr: bin/test -vv -t lp-proj.txt [21:27] ok [21:27] leonardr: no, i put in just a call to lp_anon.project_groups to get the collection and debug output wasn't shown [21:28] but lp_anon.project_groups worked? [21:29] yes [21:29] it works but the search() does not [21:29] ok [21:36] morning [21:42] bac, i suspect the request is never making it into lazr.restful code. you could test this with breakpoints in HTTPResource.do_GET. i suspect something about the way the test env is hooked up is to blame [21:42] i'm eod but i will look at this tomorrow if you're still stuck. i will probably need to do another launchpad branch [21:43] leonardr: ok, i think you're right. other than your launchpadlib.txt i don't think this has been exercised much [21:43] thanks for your help and i'll talk to you tomorrow [22:19] leonardr: hi [22:19] leonardr: launchpadlib seems to make HTTP requests on every object traversal; is there some way to make it cache things and avoid querying each time ? [22:22] lifeless: yes, at the cost of the client sometimes having out-of-date information [22:22] https://dev.launchpad.net/Foundations/Webservice/Performance#line-184 [22:25] jelmer: Around? (Regarding pygpgme and lucid) [22:25] leonardr: we're in a 1-a-minute cron job, and its doing some absurd amount of lookups - 1000's perhaps. [22:25] bwah === matsubara-afk is now known as matsubara === salgado is now known as salgado-afk [23:32] sinzui: ping [23:33] lifeless: you can try the twisted client, it forces you to request the lookups [23:33] lifeless: it's still experimental though, so it may well require some contribution for it to work for you [23:34] james_w: sounds interesting; at least for now though I can't justify the time - this is a slack-time project to get rid of 'pqm-submit' [23:34] right [23:34] james_w: and production code really wants package deployed dependencies etc [23:35] lifeless: sure, it's not ready yet. However, given that you mentioned async lplib yesterday, and now asked about a feature you get with it, I thought I would mention it :-) [23:40] james_w: I appreciate that [23:40] james_w: where is it btw ? [23:41] lazr.restfulclient.tx [23:41] on a well-known open source hosting platform [23:42] :P [23:47] james_w: what? github? [23:48] mais oui [23:57] buzzword fail! [23:57] james_w: you meant *colloboration* platform! [23:58] except with better spelling [23:58] no, I think I probably meant colloboration, it's late here