=== FryGuy is now known as FryGuy- [02:38] hiya everybody :) [02:49] Hi :) === MTeck is now known as MTecknology === bob2 is now known as Guest21483 === peitschie1 is now known as peitschie [06:31] mgz: thanks so much for reviewing doxxx's mergetools patch [06:47] vila: I just used run_script for the first time, and it basically Just Worked for me. Nice! [07:26] spiv: cool ! [07:26] hi all ! [07:28] hiya vila :) [07:29] _o/ [08:01] alleluia, bzr-2.2.1 made it into maverick-updates :) [08:08] vila: congrats! was it as painful as it sounds? [08:09] no, not painful, but since I didn't understood the process ,I was impatient :) [08:10] vila: hehe... i understand that feeling :S === FryGuy is now known as FryGuy- [08:23] * KombuchaKip needs get Stallman to consume more raw fruits and vegetables. [08:32] hey.. I screwed up and accidentally pushed a branch I was working on to my projects trunk because its remembered location was the trunk. I then pulled this push from my trunk branch and so I don't have a copy of what the trunk was before I pushed it. Nobody else has pulled this yet, so I'd like to push --overwrite the Launchpad trunk back to what it was. How can I restore my repository to the state it was in at a certain revision-spe [08:33] sorry this is all on Launchpad [08:34] like, in my history the trunk head was 'rryan@mit.edu-20101024063322-8b3jtqyn77k5c32t' [08:36] rryan: bzr push --overwrite -rrevid: rryan@mit.edu-20101024063322-8b3jtqyn77k5c32t [08:36] It seems I can't connect to lp via ssh right now though [08:37] Can anybody confirm or is it only me ? [08:37] right, confirmed in #launchpad [08:54] thanks vila, all better now [10:19] hi vila? [10:20] poolie: hey ! Wow, you're up ? [10:20] yeah, up a bit early === GaryvdM_ is now known as GaryvdM === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [15:05] hi jam? [15:05] hi poolie [15:05] Having a bzr sprint at UDS next spring sounds good. I just need to double check if it overlaps with my wife's travel [15:05] I think that was april, though [15:06] cool, thanks [15:07] Kareem can come :) [15:07] we have plenty of +easy bugs [15:16] :) [15:31] beuno: if you are around, I just checked the meliae dump you sent me, and it only sees 11MB of content... :( [15:32] you seem to have a lot of "function" objects (15k), but that really doesn't explain 1GB of ram [15:35] jam, we don't know either :/ [15:35] beuno: what code is this? (do I have access to it?) [15:37] jam, this is a django server from ubuntu one [15:38] I can surely give you access to it [15:39] beuno: I don't know django code particularly well. I don't see any smoking guns just looking at the memory dump [15:39] meliae could only find about 113k objects, which is pretty small. [15:40] yeah. we are puzzled [15:40] beuno: what version of python? [15:40] I think you mentioned that this is only reproducible on the server/ec2 ? [15:41] I assume this dump is from that process while it was at high mem? [15:41] jam, 2.4, and yes, this dump is from when the usage is high [15:41] beuno: there is a possibility w/ 2.4. Do you do any heavy math? [15:42] integer or floating point? [15:42] IIRC 2.4 allocates integer arenas, and never returns that memory to the os [15:42] so any sort of "do lots of stuff here, and then stop" will still have a lot of memory [15:42] it can be re-used by the process, but it isn't returned to the os [15:43] jam, not really. It's actually pretty simple, we stream files from amazon S3 and do basic db requests to return some data [15:43] beuno: would you be holding the content? [15:44] I certainly don't see big strings here [15:44] Are there any custom extension types? like S3 apis, or db apis, etc? [15:45] I'm assuming the "Method", "InterfaceClass", "Implements", etc classes are all coming from zope.interfaces code? [15:46] we do have custom S3 apis [15:47] I don't think we use any zope [15:47] beuno: are they Python "extensions" ? (C level code, not Python level code) [15:48] jam, nope, this is all python [15:48] we thought about that as well [15:48] but no c extensions [15:48] i _guess_ you could try running it under valgrind [15:48] but i guess it only happens in production? [15:48] beuno: twisted uses zope.interfaces, and you certainly have 'twisted.python.zipstream' loaded [15:49] mwhudson, right, can't reproduce it locally [15:49] jam, right, we may from twisted [15:49] (total of 773 modules loaded, so I don't know everything, but there is certainly a lot loaded) [15:50] beuno: psycopg2.extensions [15:50] yes, we use psycopg2 [15:51] beuno: are you using python2.4 locally as well? [15:51] beuno: you are also using protocol buffers, would those have compiled extensions? [15:52] (it looks like python code, but it is something that might be involved) [15:52] 'ubuntuone.web.musicstreaming.views', sounds like something that could have large content blobs [15:53] jam, no, 2.6 locally [15:53] beuno: that could certainly be the isuses [15:53] issue [15:53] * beuno nods [15:53] protocol buffers could be doing lots of integer ops [15:53] ubuntuone.web.musicstreaming.views accesses S3 to streaming multi-mb files [15:53] aha [15:53] though it should be "peak ops" [15:54] for example, encoding a multi-mb file into a protocol buffer [15:54] would be a lot of 4-byte integers [15:54] beuno: also 64-bit vs 32-bit could be something [15:54] beuno: I also don't 100% guarantee meliae works on python2.4 [15:54] * beuno nods [15:54] ha [15:54] ok [15:55] I know some of the code is 2.5, but I think the scanner is 2.4 safe [15:55] so a good thing to do is push for the lucid upgrade [15:55] beuno: it sounds useful, but I won't guarantee it solves your problems :) [15:56] heh [15:56] uh [15:56] jam, it's a lot of new things to chase, thanks [15:56] protocol buffers might have leaks? [15:56] beuno: my biggest suspect is python2.4 [15:56] mwhudson: python2.4 doesn't return integer allocations back to the os [15:56] so it always allocates the peak integer arena [15:56] which should be reusable (without "leaks") [15:56] but you might have a big peak [15:57] beuno: which would show up as VmPeak being high, but VmRss being much lower [15:57] it does seem like we get peaks, and in fact see some MemoryErrors now and then [15:57] we usually see virtual mem at 1.5gb, and rss at 250mb [15:59] beuno: well, VM includes mmaped files, etc [16:00] I mean 'cat /proc/PID/status' and the VMPeak vs VMSize or VMRss sort of thing [16:00] if python2.6 "fixes it" the Peak would be the same, but the active size would be lower [16:00] * beuno nods [16:00] I'd have to look at it again [16:01] the integer blocks might show up in /proc/$pid/maps? [16:01] i can't remember how all this works [16:01] beuno: you should try using pypy instead :-) [16:03] heh [16:03] I have not written 90% of this code, so it's been intersting trying to debug it [16:03] beuno: so it looks like the Implements and InterfaceClass may be protocol buffers stuff [16:03] beuno: clearly you need to look closely at that 10% then :) [16:03] yes, that makes sense [16:03] jam, heh. It has been failing for over a year [16:04] so the only thing that can be blamed on me is increased usage [16:04] beuno: you've peaked my interest, if you want to give me a peek at the code [16:04] beuno: I can blame anything I want on you. Doesn't mean I'll be correct :) [16:04] heh [16:04] jam, I will add you to the team now [16:06] beuno: so the idea behind python2.4 vs 2.6 is that the actual peak is happening at some point in the past [16:06] and we are just holding on to the memory now [16:06] but it isn't in "active" objects, so meliae can't find it [16:07] I wonder about doing evil hacks and walking the actual PyInt buffers === Ursinha is now known as Ursinha-lunch === Ursinha-lunch is now known as Ursinha === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [20:42] I have been using the bzr_upload plugin, fantastic btw, but I have a problem: the first time I uploaded I used a location that was wrong, now when I specify a new location, then use saved location it uses the old one, how can I change that? [20:43] --remember [20:46] funny post on the mailing list. I wonder how large the set of users is that we render bzr inaccessible to by using such things as 1) configure 2) https 3) the gpl [20:47] it might only be him. [20:51] lifeless: Ah, fantastic. And now I see it in the manpage also, I couldn't find it before. Thanks. [20:53] mgz: 'not using configure' ? [20:54] he even linked us to his website where he explains why he doesn't like configure. [20:54] I... didn't try and understand too hard. [20:54] yeah [20:54] I can understand === Ursinha is now known as Ursinha-brb [21:14] didn't know one had to run ./configure for bzr [21:20] I looked at the message again, and he appeared be be complaining about bzr using python... which uses configure [21:23] ah [21:23] logical [21:23] the taint of configure [22:01] Hi i'm trying to pull a branch of openarena, but i keep getting a permission denied error :( [22:01] Permission denied (publickey). [22:03] Do i need to identify my self or some thing? [22:03] bzr branch lp:ubuntu/maverick/openarena [22:14] AJenbo, hi, there's a bug on the server, it should be fixed soon [22:15] AJenbo, hi, i think it's bug 666642 [22:15] Launchpad bug 666642 in Launchpad Bazaar Integration "incorrect data check branching lp:openobject-addons (affected: 2, heat: 10)" [High,Confirmed] https://launchpad.net/bugs/666642 [22:15] we're going to look in to it [22:18] ok, it's been there for a while now [22:19] any workarounds? [23:30] mornin all :) === Ursinha-brb is now known as Ursinha [23:39] AJenbo: I think poolie may have mixed up two projects with "open" in their name, I can't see how that bug can apply to your issue