[01:05] * spiv waits for the cold&flu pills to kick in fully [01:05] ugh [01:06] I'm definitely doing much better than yesterday. I don't seem to actually have a fever anymore, and I got a proper night's sleep. [01:07] Hooray for ubuflu :/ [01:16] lifeless: re "Where is test_dir being set?", two instances of `self.test_dir = ` in bzrlib.tests both of which are old [01:17] so I presume the change is something to do with how test methods are put on instances in testtools [01:17] mgz: oh wow, that's a shorter nick! [01:17] blame vila! [01:26] morning [01:33] hmmm [01:35] I presume the code was wrong before, but happened to work because no one was checking if the attribute they'd put the directory name in was still a string or whatever [01:39] didn't look too closely once I'd worked out how easy the fix was [01:48] mgz: yeah [03:03] * igc lunch [03:39] I'm having problems with launchpad since yesterday, anyone else? [04:31] can bzr diff compressed files? like can it give intelegable changes between revisions of a docx file? [04:34] Croepha: not as a builtin feature [04:36] Croepha: I think it would be possible to write a plugin to do that, or perhaps you could try "bzr diff --using=..." if you already have a tool for producing readable diffs for that file type. [04:40] nilg: some details please [04:41] Croepha: you can write a plugin to the diff code that examines specific files in a different way [04:41] lifeless: sorry I works actually [07:21] hi all [07:50] heya [08:14] night all [08:15] Hi and Night igc. [08:15] night igc [08:15] morning [08:15] night igc [08:15] hi GaryvdM, gour (and night) [08:16] #541626 makes bzr-fastimprt unusuable for me [08:16] is it just fastimport's problem or affects bzr aswell? [08:16] you should say bug #541626 [08:16] Launchpad bug 541626 in bzr-fastimport "'BTreeBuilder' object has no attribute '_find_ancestors'" [Undecided,Confirmed] https://launchpad.net/bugs/541626 [08:16] bialix: thanks [08:17] our pet bot, good ubottu, take a cookie [08:18] * gour would like to to darcs <---> bzr and use LP [08:18] s/to to/to do [08:19] tailor? [08:19] i'm not sure it can do incremental import and believe fastimport should be better supported...igc takes care for it [08:20] perhaps not today [08:21] vmiklos (who wrote darcs part) recommends it over tailor as well [08:29] bialix: Nudge https://code.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519 [08:30] at evening, sorry, have to work [08:30] bialix: Ok [08:30] * GaryvdM looks at 2 qbzr mps === gour1 is now known as gour === wgrant_ is now known as wgrant [09:44] Hi there! When will 2.1.2 be released? https://launchpad.net/bzr/+milestone/2.1.2 expects it 2010-04-22, and bug #572098 is really annoying. Yes I could work from a snapshot, but I prefer releases for my production work. [09:44] Launchpad bug 572098 in Bazaar "`bzr clean-tree` should not blindly delete nested branch/tree/repo (affected: 1, heat: 6)" [High,Fix released] https://launchpad.net/bugs/572098 [09:45] Got the wrong bug, it's #559436 that's annyoing me personally, but seeing a list of 5 high priority fixes looks like a release might be a good thing. [09:56] bug 559436? [09:56] Launchpad bug 559436 in Bazaar "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 4, heat: 30)" [High,Fix released] https://launchpad.net/bugs/559436 [09:56] Oh. [09:56] Means whenever I switch a branch with local modifications, I get a backtrace... :-( [09:57] s/branch/tree/ [10:01] vila: Who is the rm for 2.1.* ? [10:02] GaryvdM: hmm, I've lost track here, was it igc or poolie ? [10:03] vila: jam did 2.1.0. I can't find the release announcement for 2.1.1 [10:04] GaryvdM: yeah, so poolie was RM for 2.1.1, where are you searching for the annoucement ? lp ? [10:04] vila: yes [10:05] GaryvdM: hmm, he presumably forgot this bit then [10:05] MvG: Out of the people who could be the rm, none of them are online right now, so it may be a good idea to send a mail to the mailing list. [10:05] GaryvdM: OK, will do so. [10:15] GaryvdM: do you remember which toolkit was used for diffamation ? qt ? [10:15] GaryvdM: or was it osx specific ? [10:17] vila: It was written in java. I'm not sure which toolkit [10:17] wow, who said java was slow ? :-P [10:21] for those that couldn't attend UDS, the video is here: http://ubuntudevelopers.blip.tv/file/3617079/ [10:30] does somebody really said that java is slow? he should look at python first [10:33] Heh. [10:33] bialix: some people explained me that they switched from java to python for web apps because python was faster :-P [10:33] ah [10:33] maybe [10:33] but diffamation is desktop thing [10:38] doesn't java have a reputation of slowness just because a lot of people programming in java don't know what they're doing? [10:38] yup, so the key is to focus on the relevant part that needs to be animated, things like shortest edit paths (mentioned in the above presentation) are certainly needed to reduce the data set to process [10:38] (me? feeding the trolls?) [10:39] the same apllies to python really :) [10:39] certainly [10:39] that's where the virtue of brainfuck is [10:40] bad programmers don't go there [10:40] good programmers don't either though [10:43] vila: http://www.aviz.fr/diffamation/ [10:49] indeed diffamation looks cool [10:49] GaryvdM: ecellent, thanks for the url [11:22] did anyone take notes for the "Bazaar/Launchpad healthcheck" session at the recent UDS? I can't find it on gobby [11:23] jml: ouch, ping poolie ? :-/ [11:24] vila: I'll send him an email. [11:24] mgz: in case you're wondering, I've found the problem with babune [11:24] jml: I should have known... [11:25] mgz: the selftest -x option can't be used twice (AFAICS) so TestBreakin and its zombies was back... [11:26] mgz: I've just finished upgrading babune to lucid and relaunch a full set of runs, gentoo has already succeeded [11:26] jml: bazaar-m-healthcheck? [11:26] spiv, ahh, thanks. I was looking for it under the community track [11:26] jml: that would have been logical :P [11:27] jml: pfff, I'm so disappointed :-P [11:27] * vila runs (not only to avoid jml's great vengeance :) [11:29] :D [11:30] vila: Huh, I thought selftest -x could be used twice? [11:30] vila: btw, if you feel inclined, maybe set up a builder for bzr on python2.7? [11:31] (It'll fail to even start tests atm, though, I filed a bug) [12:00] yep, some pages gone from gobby [12:04] jml: that page still there [12:04] titled bazaar-m-healthcheck [12:05] bialix: thanks. [12:05] I guess we should put those pages to wiki [12:06] bialix, yeah. that'd be good. [12:07] bialix, I'm collecting all of the Launchpad-related notes, putting them onto our wiki, then blogging a summary. [12:07] I'm not going to do that for Bazaar though. [12:07] ok [12:07] I'll do that for bzr === radoe_ is now known as radoe [12:28] I've named some of you there, hope you don't mind: http://guij.emont.org/blog/2010/05/18/scratching-an-itch-make-bzr-gtk-collapse/ [12:28] GaryvdM, jelmer and vila [13:00] vila: ping [14:04] nessita: pong [14:05] vila: hi there! I added a comment on https://bugs.launchpad.net/bzr/+bug/581751 [14:05] 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Tue, 18 May 2010 13:05:13 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 581751 is private\n---\n (https://launchpad.net/bugs/581751)' [14:05] vila: lifeless suggested me to ping you, is there any debug we can do together? [14:06] wow, ubottu can't authenticate ? That's weird... [14:06] any extra info I can add? I can reproduce it consistently [14:08] nessita: just sec, let me page in the context [14:08] vila: sure, thanks [14:10] hmm, looks like the nightly hasn't been updated since 2010-03-24, so I'm pretty sure it doesn't have the fix [14:11] nessita: what do you mean by 'split' the bzr command ? [14:11] vila: yes [14:11] nessita: nice host name by the way :) [14:11] heh :-) === CardinalFang_ is now known as CardinalFang [14:15] nessita: sorry for the delay, I've just updated to lucid and my setup is not fully functional yet [14:15] GaryvdM: did you merge annotate_find to trunk ? It seems that branch doesn't work anymore on lucid [14:16] vila: no problem. Just ping me using my nickname and I'll be happy to help debugging [14:16] vila: I have not yet merge annotate_find to trunk, but I have merge trunk in to annotate_find, so annotate_find should work on trunk. [14:16] *should work on lucid [14:16] ok, first I'd like to check if the nightly includes the fix I mentioned [14:17] GaryvdM: Oh, right, you told me that, let me check [14:18] GaryvdM: thanks, that fixed it :) [14:20] nessita: right, the fix is revno 5160 on trunk while the nightly seems to be 5106, right numbers, wrong order [14:20] vila: ok, so, is there any way of getting a newer bzr other that branching trunk? [14:20] nessita: can you run bzr from sources ? [14:21] vila: I guess so :-) [14:21] * nessita branches [14:21] nessita: none of the ppas seems to contain better than nightly, this fix should be in the next releases (2.0.6, 2.1.2, 2.2xxx) [14:23] spiv: (surely too late but anyway) I thought -x could be used twice too, regression ? (-s can ! :) [14:24] nessita: don't forget to run make after branching (hmm, you may need to install some dependencies too, pyrex for one...) [14:25] vila: is there any howto? [14:25] I mean, a list of deps so I install them at once [14:26] * vila looks at the package def [14:26] jeje [14:26] that's cheating! [14:26] :) [14:26] I know we don't have TestDepends but I'm pretty sure we have DevDepends (or whatever the name is) [14:28] * nessita is still branching [14:28] argh, one more regression, can\t switch virtual desktops anymore [14:28] nessita: hmm, first branch ever ? [14:28] yeap [14:29] * nessita sings like a virgin, branching for the very first time [14:31] shift+ctrl+alt+left instead of ctrl+meta-left .... did the design team infected by emacs viruses ? [14:31] nessita: :-) [14:31] argh, keyboard layout bug :( [14:48] vila: how big is a bzr branch? [14:48] history or working tree ? [14:49] history [14:50] vila: it doesn't matter, I was just curious [14:50] this thing is still branching :-) [14:50] nessita: my .bzr shared repo is ~62 [14:50] ghaa 63M [14:51] that should be an upper bound as it contains many revisions that were never (or are not yet :) merged to trunk [14:51] nessita: lag/bandwidth ? [14:52] max download rate is 1M for me [14:52] and the branch is using ti all [14:52] it* [14:53] \ 78155kB 107kB/s | Fetching revisions:Inserting stream and counting [14:53] hmm, 78M already, something weird is going on here :-/ [14:54] not relly? [14:54] nessita@dali:~$ du -sh src/bzr.trunk/ [14:54] 35M src/bzr.trunk/ [14:54] finished! [14:56] nessita: so you used twice the volume of the final branch: something weird happened, can file a bug with these numbers please ? [14:56] nessita: then you can ping lifeless :-) [14:56] ok [14:57] vila: make completed successfully [14:57] nessita: so, run 'make' in the bzr branch [14:57] done [14:57] wow, you rock :) [14:57] heh [14:57] no weird messages about extensions nor zlib ? [14:57] nopes, it failed because of the lack of pyrex, which I installed and re run make [14:57] nessita: just do './bzr info -v' there [14:58] ok, so you should have the other ones already installed (I vaguely remember zlib-dev was required at some point) [14:58] vila: https://pastebin.canonical.com/32382/ [15:00] nessita: cool [15:00] vila: this worried me though https://pastebin.canonical.com/32383/ [15:00] vila: note bzr vs ./bzr [15:00] but versions match? [15:00] nessita: try using this bzr for your previously failing ... let me look ta this pate [15:01] nessita: yes, versions are bumped for release only, nightly are not your usual beast [15:01] ohhhh ok [15:01] vila: shall I redo the splits with the newer bzr? [15:01] but the full output should mention the revno [15:02] nessita: not if the fix apply to your case [15:02] perfect [15:02] nessita: bah, no [15:02] sorry for the convoluted answer [15:02] no problem [15:02] I can do the split again [15:03] shall I branch using newer bzr too? [15:03] nessita: no, just try the failing command with the new bzr [15:03] ok [15:03] either it's fixed or it's a whole new bug anyway [15:04] mgz: babune back in blue, expect for the windows run !! [15:04] it didn't fail! [15:04] vila: nice :-) [15:05] nessita: pfew, I'm so glad about that ! This fix was a real pain :) [15:05] vila: thank you very much for your help! [15:05] nessita: I was afraid you were hitting the same kind of problem only different, luckily it looks to be the *same* :) [15:06] nessita: my pleasure [15:06] seems like it [15:06] vila: have a few more minutes for a follow up question? [15:06] nessita: sure [15:07] vila: so, the merged worked (yey!) but, when applied, it removes some files (because the source branch has those removes in it). Is there any way to avoid/undo certain changes? [15:09] nessita: if the merge remove 'filea', doing 'bzr revert filea' should restore it, you can then commit and the following merges shouldn't delete it again [15:09] vila: yey, you're right [15:10] thanks again! [15:13] nessita: I'll mark the bug as a duplicate then [15:13] vila: please do [15:15] bzr repo on launchpad is nearly impossible to get from china, any knowledge about that issue? [15:18] guijemont: marmitians anonymous, really, you know there are free certificate providers these days ? :-P [15:23] guijemont: and, of course, no problem with your citations :) [15:25] vila: yeah, should handle that one day [15:26] but the big issue is it's a shared server [15:26] ha, yeah, technical problems are so much easier to handle when humans are not involved :-D [15:46] vila: I know you us synergy. Are you aware of this: http://code.google.com/p/synergy-plus/ [15:46] *use [15:48] vila: The old synergy segfaults for me. synergy-plus is more stable for me, but the clipboard is broken. [15:49] GaryvdM: good to see this nice software resurrected, I'll track it to see how it evolve. [15:49] GaryvdM: it's mission critical for me so unless it works better I'll stick with the working one :) [15:51] vila: I see. [15:53] GaryvdM: also, I try to minimize installs from source, so unless it's packaged for lucid... I will wait (if someone proposes it as a ppa though.... I will gladly test it ;-) [15:54] GaryvdM: Oh, and I have a pending bug against virtualbox about the bad interactions between vbox, synergy and the apple magic mouse... [16:01] On a Debian GNU/Linux system, ever bzr command gets this warning: [16:01] /usr/lib/python2.5/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken [16:01] RandomPool_DeprecationWarning) [16:01] But python-paramiko package is up-to-date. Googling does not reveal any obvious fixes, and the URL given in the warning is a 404. [16:01] Any ideas? [16:07] Isn't Crypto a separate download from paramiko? [16:08] what happens when a pack file size gets to the system filesize limit? [16:08] kfogel, the source install docs list http://www.python.org/pypi/pycrypto/ as the place to get pyCrypto [16:08] IslandUsurper: thanks [16:09] kfogel, I would guess there's a different package for it instead of python-paramiko === IslandUsurper is now known as IslandUsurperAFK [16:47] hey all, me again with weird issues. Anyone has a hint how to solve this conflicts? https://pastebin.canonical.com/32393/ [16:58] You know that that's a pastebin most people can't see? [16:59] duh, sorry, pastebin was disabled a few hours ago :) [16:59] oops, still is === salgado is now known as salgado-lunch [17:01] public paste: http://paste.ubuntu.com/435609/ === beuno is now known as beuno-lunch [17:01] maxb: thanks for pointing this out! [17:08] I guess this is a private branch? [17:10] maxb: yes, I split a subtree from a branch and I merged it against another branch in another project [17:10] (using bzr split and bzr merge) [17:10] that sounds... complicated :-) [17:10] yeah [17:10] I'm so frustrated [17:11] but I have to do this, and maintain history === kfogel is now known as kfogel-lunchpad [17:41] GaryvdM: still here? === IslandUsurperAFK is now known as IslandUsurper === IslandUsurper is now known as IslandUsurperAFK [17:43] GaryvdM: maybe I simply should dogfood your bzr-explorer patch? I'm not really wise to easily review your changes === IslandUsurperAFK is now known as IslandUsurper [17:44] about duplication: maybe it's worth to require in explorer trunk compatibility with newer qbzr? and keep explorer 1.0.x as compatible with qbzr 0.18? [17:44] * bialix going to home, will read irclogs later [17:44] ~~~ [17:50] vila: good to know the nix hang problems are not related, was coming to that conclusion here [17:50] I've got some interesting results on the thread leak regression I'll probably post to the mailinglist === kirkland` is now known as kirkland [18:05] can anyone tell me what provides XMLSerializer ? [18:08] nevermind. I see it's part of bzrlib now === beuno-lunch is now known as beuno === luke-jr_ is now known as luke-jr [18:14] mgz: (passing around) regression ? The leaks have been there for... a very long time, what are you comparing to ? [18:14] abentley: bug in lp-submit in pipelines: I just got this error: bzr: ERROR: There is already a branch merge proposal: https://code.edge.launchpad.net/1.0/~mordred/drizzle/pandora-build/+merge/14733 [18:14] abentley: too bad the 1.0 doesn't really belong in that url... [18:15] mgz: the bug itself is very stealth and I have never been able to reproduce it on demand... [18:18] mtaylor, funny, I thought I'd fixed that one. [18:18] vila, that's just it, yes, the leaks have always been there, but they were never fatal for *me* before [18:18] and now I can reliably repo. [18:19] abentley: it's possible I'm running an old version [18:19] vila: I've got a couple of things I'd like you to check if you can === JFo is now known as JFo-afk [18:19] mtaylor, just testing now. It's possible I only fixed lp-propose. [18:20] 1) make really-really sure you're chop-test-run-into-several-smaller-subprocesses workaround is still working, as that should make leaks harmless [18:20] 2) do a full babune test run on r4919 and r4920 [18:23] mtaylor, yeah, that's it. On 2.1, lp-submit will give you that error. On 2.2, you get lp-propose through its lp-submit alias. [18:24] abentley: ok. cool [18:24] abentley: I'll just deal with it then [18:24] it's certainly not borking me :) [18:27] mtaylor, I'll fix it, just not right now. [18:31] bialix: If you read this in the log, I've replied to your questions in the mp. Thanks [18:34] mgz: 1) is demonstrated by babune being almost blue (including some hacks for some slaves to increase BZR_CONCURRENCY *above* the number of available processors) [18:35] For god's sake, let it BREATHE! [18:35] mgz: what do you call a full run ? All slaves ? [18:35] fullermd: funnily enough it's the freebsd8 that needs the hack has running it under vbox with more than two cores lead to far too much crashes :-/ [18:36] s/freebsd8/freebsd8 slave/ and to avoid any misunderstandings, I blame vbox not freebsd (remember the time skew problems I was encountering ? Still there, even worse maybe) [18:37] and babune's fans have been changed for more silent, yet still efficient, ones, so it can breathe and I don't hear it complain anyway [18:37] Obviously, the answer is to make freebsd8 the host rather than the emulated one ;p [18:38] fullermd: all tests are run in slaves, not on host :-P Host is for *my* tests :-) [18:38] so I'll still need to have a freebsd slave ;) [18:39] Daemons don't take well to chains. You're liable to wake up one day to a trident at your throat. [18:39] If you interrupt a bzr-git fetch, will it resume, or restart? [18:40] one more reason to give it only two cores, I may be able to put my neck between the two teeth of the bident :) [18:41] fullermd: and stop complaining, now you can blame the lower number of cores to explain why freebsd is the slowest nix on http://babune.ladeuil.net:24842 :-P [18:41] Ah, yes. Core limits for VM's should be called the Skynet Prevention Program. [18:42] You said the name !!!! [18:42] jaunty isn't a nix? ;p [18:43] hehe, I was waiting for that, check again in a couple of days or drill down for the trend, jaunty and karmic last run are atypical :-P [18:44] Doesn't much matter anyway, since Windows does it in 2 minutes ;p [18:45] no no, 55mins, note the debug :) This one is running only a small subset :) [18:46] * fullermd snorts. [18:46] * vila dinner :) [18:46] You've got a pathetic career as a benchmarker ahead of you if you're gonna get bogged down in irrelevant details like that ;p [18:47] mgz: what do you call a full run ? All slaves ? <- windows only, but all tests (minus bb.test_breakin) [18:47] I'll get my write-up done later, then things might start making more sense === salgado-lunch is now known as salgado [18:50] essenstially, I think things have got worse on the threads-leaked-alive front. [18:51] and it's the fault of testtools, which is becoming something of a mantra for me [18:53] Well, consistency is a virtue, right? === kfogel-lunchpad is now known as kfogel [19:20] can I create a branch on remote host? say I have a bunch of files in a dir. I want to create a branch on the remote host, and check them in there. how would I do it? [19:23] eydaimon, create teh branch locally and push to it [19:23] it will create it [19:25] bzr init . ? [19:25] then bzr push pathname? [19:26] bzr init . [19:26] bzr add [19:26] bzr commit -m [19:26] bzr commit -m'Some message' [19:26] bzr push pathname [19:27] thanks :) [19:27] will the local branch work as a checkout or as a branch? [19:27] youz welcome [19:27] a branch [19:27] can I make it a checkout? [19:28] so Id on't have to keep pushing [19:28] yes, but you will need to checkout from $path [19:28] so first push, then checkout [19:28] bzr doesn't seem to like writing to a dir which already exists [19:33] yeah, it's fussy about that [19:34] eydaimon: You can make your local branch a check out by running bzr bind :push [19:36] cool. thank you [19:38] mgz: hmm, re-trying old revisions on windows with the bug fixes in testtools and subunit may be worth a try, but I won't bet a lot on testtools making things worse [19:42] mgz: keep in mind that the root cause is that transport objects don't close their socket, for http that means keeping the connection alive. The servers have to keep their own connections open. At some point python's gc will finally collect the transports and close the client sockets triggering the server sockets close. [19:43] mgz: But since that take too long, we finally reach the socket/file handle/thread limit [19:45] mgz: now, to fix that, we need to close the socket in either the client or the server, that's where I encountered weird behaviors (uncaught exceptions in the server threads leading to hang threads for once) [19:46] mgz: I have some branches where the servers where almost good and where there were almost no more leaked threads and... get interrupted [19:46] mgz: It's high n my TODO list now so expect some results soon (for handwaved values of soon of course :) [19:50] There's something I really don't understand about bzr-svn: If I do a merge/commit/push, it puts back changes that were already on the svn repo, but makes it look like I just made those changes [19:50] is that really what I should be doing? === tchan1 is now known as tchna === tchna is now known as tchan [20:05] fullermd: benchmarker... OMG what a scary thought... [20:06] * fullermd . o O ( Vilacraft... ) [20:07] vila: shouldn't you be ... not in IRC... by now :) [20:07] Wow, you haven't even started benchmarking, and people are already trying to get rid of you! [20:07] jam :-p [20:08] jam: hey ! Indeed :) [20:08] hi GaryvdM [20:08] Proceed as if I wasn't there :) [20:08] vila: I'm seeing an awful lot of blue on babune :). Though I wonder why selftest-windows isn't, seeing as you worked with Martin all week on it... [20:08] Are there patches pending? [20:08] (At least, I thought you said you got Win32 to pass...) [20:09] jam: AFAIUI, most of them are now due to the infamous "Can't start new thread" [20:10] I thought we add, but for some reasons, not all tests were running and we based our countdown on that. [20:10] * mgz reads log [20:10] mgz had landed further patches I believe so the remaining ones should be fixed when the leaks will [20:11] oh, he's there (mgz) so he can comment :) [20:11] yup, I'm aiming to splat everything that's not a leak [20:11] vila: you know, if you gave that vm 2 cpu's, you're troubles would probably go away... [20:11] including a couple of things I see but babune doesn't [20:11] jam: I can't make XP recognize several cores... [20:11] *your* [20:11] on the leak-as-regression thing, something has gone seriously bad in the past 300 revisions [20:12] vila: my wife runs xp-pro on 2-core [20:12] (business machine) [20:12] leaks are harmless provided there's enough memory to spare for the stack space required by lingering threads [20:12] ha, pro, that should explain it :) [20:12] maybe [20:12] mgz: could be, I can try increasing the memory allocated to the vm [20:13] xp was based on 2k's kernel, IIRC. So maybe xp-home has an explicit deficit, but xp generally can definitely handle multi-core [20:13] between r4919 and r4937 (which is the first post-testtools rev that doesn't corrupt memory), the working set increased two or three fold [20:13] now waitaminute, I'm pretty sure I'm using a pro version... [20:13] and the tests start hanging. [20:14] mgz: working set ? [20:14] corrupt memory ? [20:14] sorry, yes, this is complicated by lots of unrelated things [20:15] hence easier in a big email than on IRC [20:15] ok [20:19] mgz: working set => active memory consumption? [20:20] right, it's one of the measures I get from windows, also, pagefile usage, and I'm not sure how they overlap [20:20] (is the combined value the total memory usage?) [20:25] how to configure pqm plugin to send merge request for 2.1 branch? [20:28] bialix: Change the submit branch in branch.conf. [20:28] e.g.? [20:28] bialix: you probably will not have permissions though. [20:28] boom [20:31] bialix: submit_branch = bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ [20:31] or just [20:32] bzr pqm-submit bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ [20:36] vila: so, I ran the whole testsuite against a bunch of different revisions, summary of the results at [20:37] * bialix rambling on out-of-date hacking.txt instruction re pqm [20:38] the first rev I can test without the crash from r4920 has massive memory usage, and hangs in a threaded test, as does each revision after that [20:39] more recent revisions still have massive memory usage, but run faster (there was a rev aiming to speed up the test suite, right?) and now get various thread-related failures but hang less reliably. [20:40] mgz: yes, lifeless optimized a bunch of tests [20:40] I'm going to run some revs between 4945 and 5200 but it seems to me like the regression is between r4919 (which is fine for me) and r4937 (which is the first post-testtools that I can run) [20:41] hence the request for you to try r4919 on babune, if you can [20:41] I expect zero thread problems. [20:43] (the full results are on my server, but are giant xml files that might hurt unsuspecting webbrowsers) [20:52] mgz: now running [20:54] mgz: that was fast :-/ [20:54] hmm, the qbzr guys are gone for some more vodka I suspect... [20:55] bah, dodgy unicode handling in error messages is historical... [20:56] don't suppose you have python 2.4 on that box? [20:56] mgz: 2.4 2.5 2.6 [20:56] AttributeError: 'BzrAutoTimingTestResultDecorator' object has no attribute '_call_maybe' <- and I got this from subunit, and didn't know what the hell it was [20:57] pretty old bug [20:57] in bzr? that was fixed? [20:57] err wait, you got that *now* [20:57] I might have been trying to test an old revision at the time. [20:57] no, I'd say in testtools [20:58] I can run the testsuite back to at least ~4000 cleanly [20:58]