[01:15] <dan|el> Any idea what's up with this error?
[01:15] <dan|el> Conflict: can't delete lib/js because it is not empty.  Not deleting.
[01:15] <dan|el> Conflict because lib/js is not versioned, but has versioned children.  Versioned directory.
[01:16] <dan|el> why would this even happen?
[01:18] <dan|el> found things here: http://doc.bazaar.canonical.com/bzr.0.92/en/user-guide/conflicts.html
[01:22] <dan|el> fixed
[05:02] <meoblast001> hi
[05:02] <meoblast001> does Bazaar end commit messages with a new line?
[07:42] <spiv> meoblast001: not necessarily, I think.
[07:42] <meoblast001> hm, ok
[17:18] <vila> mgz: If you're around, care to give lp:~vila/bzr/for-babune a host on your windows host ?
[17:21] <vila> mgz: It implements some fixes for the http *thread* leaks (socket leaks will come later) but I'd like some feedback on memory consumption and overall elapsed time (I've got weird results here like it has been running for the last 5 hours while consuming very little CPU)
[17:21] <mgz> branched, I'll hook it up for a full run now.
[17:22] <vila> mgz: oh cool you're there,
[17:22] <vila> so about memory, performance monitor tells me ~150M, is this where you found your 1G figure ?
[17:23] <mgz> hm, exception
[17:23] <mgz> !pastebin
[17:24] <mgz> http://paste.ubuntu.com/445174/
[17:24] <mgz> presume that's a try/except/finally
[17:24] <mgz> which is a 2.4 no-no :)
[17:24] <mgz> ^no, ~150M is about what the right number should be, without horrible leaks messing things up
[17:25] <vila> hmm, thanks fixed (that's what I get from running llucid where py24 is not packaged anymore :-/)
[17:26] <mgz> full testrun working set size prior to r4920 was 177MB, and >500MB after
[17:27] <vila> yeah, but where do I find that ws sizr you're talking about ? Performance monitor ?
[17:27] <mgz> I added a thingy to my script
[17:27] <vila> err, task manager ?
[17:28] <vila> Can it merged into core ?
[17:28] <vila> Can it be merged into core ?
[17:28] <mgz> http://float.endofinternet.org/bazaar/bzrcst/bzrcst/perf.py
[17:28] <mgz> probably, the windows version has an analogue in bzrlib.win32utils anyway
[17:32] <mgz> vila: have you pushed the try/except/finally fix to lp yet? can do it independantly here, but prefer to run off your rev
[17:33] <vila> I'm preparing a version with more fixes included (far less socket leaks)
[17:33] <mgz> yell when pushed and I'll pull and start a run here
[17:34] <vila> yup, I'd like to let mine finish even if it takes a day or some (or not :)
[17:35] <vila> mgz: pushed
[17:37] <vila> mgz: in case it matters, it's based on trunk from a few days/weeks, I don't remember exactly when I last updated my loom
[17:37] <mgz> nope, shouldn't matter
[17:37] <vila> thought so but nobody told me nothin' so I prefer to check :)
[17:38] <mgz> there were some revs around the gio merge that had issues, but runner is resilient to import/syntax issues in tests
[17:39] <vila> hmm, I missed the review window there...
[17:40] <vila> pff, 6 hours for 2000 tests something is very wrong there
[17:40] <mgz> but the tests are still progressing? it's not just hung somewhere?
[17:41] <vila> yeah was progressing (I just killed it)
[17:41] <mgz> because... er... it seems to have hung here already
[17:41] <vila> give it some time
[17:41] <mgz> my hang protection will kick in... just has
[17:41] <vila> I smell some network related timeout from.... some unknown place
[17:41] <vila> try disabling that for once
[17:42] <mgz> ...I really need to get the name of the started test out before running it...
[17:42] <vila> -v
[17:42] <mgz> the test *after* bb.test_branch.TestBranchStacked.test_branch_stacked_from_rich_root_non_stackable at any rate
[17:43] <mgz> lets see if it happens again
[17:43] <mgz> yup.
[17:45] <mgz> bb.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server
[17:46] <mgz> used to leak, now hangs.
[17:46] <vila> pass here
[17:47] <vila> but I've seen weird failures involving the smaer server on windows only
[17:48] <mgz> I'll try running it just from the console and... urk, bb.* so no pdb
[17:48] <vila> shudder
[17:48] <vila> the CPU graph is flat again...
[17:49] <mgz> yup, no ctrl+break
[17:49]  * mgz goes to kill process manualy
[17:50] <mgz> I'll try a full run minus bb.
[17:51] <vila> or if you have data available, just compare -s bt.test_http
[17:51] <vila> and -s bt.per_transport
[17:51] <vila> I think that cover most of the leaks
[17:52] <vila> hmm, anyway, looks like my fixes make a lot of hangs came up,
[17:53] <vila> the ones I've fixed... were all in the server part and have been there for a long time, I don't yet have a good explanation about why my other fixes are shaking them up though, it seem to be an overall effect
[17:54] <vila> .. which in turn means that I need to fix a lot of things together if I don't want to disrupt the whole selftest :-(
[18:00] <mgz> okay, that gave me a whole load of errors
[18:00] <mgz> somehow broke my runner framework (are you now deleting things in cwd somehow?) but get failures run with -x blackbox from console
[18:01] <vila> I delete nothing I can think of
[18:01] <mgz> a bunch from cleanups like:
[18:01] <mgz>   File "C:\bzr\bzr\for-babune\bzrlib\osutils.py", line 2041, in connect_socket
[18:01] <mgz>     for res in socket.getaddrinfo(host, port):
[18:01] <mgz> NameError: global name 'host' is not defined
[18:01] <vila> but I've got some basic error, yeah that noe
[18:01] <vila> one
[18:01] <mgz> also some from threads like:
[18:01] <mgz> error: (10058, "Can't send after socket shutdown")
[18:03] <vila> yeah, smart server, coming from a .recv() call, which is ... ironic :)
[18:04] <vila> I've yet to reproduce them somewhere else, but thanks for feedback, it means it still need to be addressed (I wan't totally sure it was reproducible)
[18:04] <mgz> ah, maybe it's trying to clean up BZR_HOME now
[18:04]  * mgz tries moving that in the runner
[18:10] <vila> one more fix pushed, now it's almost all http/1.1 tests that fail for -s bt.test_http :-/
[18:10] <vila> and stil an almost flat CPU graph
[18:11] <mgz> ha, okay, worked out what the problem was here
[18:12] <mgz> one of the tests was cding somewhere and not cding back
[18:12] <mgz> fixed my isolation on that.
[18:12] <vila> weird, the base test framework should do that for you
[18:13] <mgz> yeah, "should" being the important word there :)
[18:14] <vila> hmm, interesting, I've got thread hung detection triggered here and 10058 cant blah blah too with no smart server involved
[18:16] <vila> mgz: so, sorry for the trouble, I thought things were more stable than that :-/
[18:17] <mgz> http://float.endofinternet.org/xmlbin/for-babune_r5277_A
[18:17] <mgz> got some interesting results before hang there
[18:18] <mgz> not sure why `raise tests.TestSkipped('Not a local URL')` is turning up as an error... probably an exception in another thread or cleanup I'm not recording currently?
[18:18] <vila> mgz: almost all tests seem to be skipped ?
[18:18] <mgz> need to wrestle with testtools some more.
[18:19] <mgz> that was me forcing a blackbox skip to avoid the early hang
[18:19] <vila> hmm, so I should drill down somewhere ?
[18:20] <mgz> click one of the yellow boxes in the last row
[18:20] <mgz> those are thread exceptions + leaks
[18:20] <vila> ha ok, yeah, I got a can't send
[18:21] <mgz> likewise some of the sky-blue (skip + leak)
[18:21] <vila> so, I don't have a fix yet for the smart server threads leaks, so rule them out
[18:22] <vila> the 10058 case... need to be fixed though
[18:22] <vila> ha, cool, I've got -s bt.test_test_server failing 1 errors 2 out of 8 tests :)
[18:23] <vila> including a 10058 and a 10054
[18:23] <mgz> I'll try and get the tracebacks-from-cleanup in there as well, as that's a worry
[18:24] <vila> mgz: try -s bt.test_test_server and look at the tests themselves, some exceptions in the cleanup phase need to be caught but have a simple explanation,
[18:24] <vila> I'm closing sockets from the main thread and the exceptions occur... either there or elsewhere :)
[18:25] <mgz> this hangs for me: test_test_server.TestTCPServerInAThread.test_start_stop(TestingTCPServer)
[18:28] <vila> mgz: interesting... and a bit worrying too :-/ It looks like too many hangs occur that I can't address...
[18:28] <vila> hmm, but start/stop shouldn't be one of them :-/
[18:29] <vila> those are whitebox tests though, can you see which line is hanging under pdb ?
[18:30] <vila> oh, and this one ERROR or FAIL here
[18:30] <mgz> ha, I think I forgot to kill that last run, and it seems to have got past it:
[18:30] <mgz> http://paste.ubuntu.com/445198/
[18:31] <mgz> ERROR   119984ms
[18:31] <mgz> very interesting.
[18:31] <vila> 2mins
[18:31] <mgz> that's just over my hang protection limit
[18:31] <mgz> and probably a socket timeout of some kind
[18:32] <mgz> could explain your six hours too.
[18:36] <vila> yup
[18:37] <mgz> hm... bumping the time wasn't enough to get past my first blackbox hang
[18:38] <vila> hmm, so a bit of explanation of the traceback in your last pastebin, that's an exception crossing the thread boundary (the t.join() line is the boundary)
[18:38] <vila> i.e. an exception occurred in a thread and is re-raised in the main thread
[18:39] <vila> I was post-poning a better mechanism to declare which exceptions should be caught when but it looks I need it *now*...
[18:41] <vila> mgz: I was referring to the first traceback in your pastebin (ending with 10058)
[18:41] <vila> mgz: the second one is similar but for the server thread
[18:41] <vila> whereas the first was for a connection thread in a threading server
[18:42] <mgz> http://float.endofinternet.org/xmlbin/for-babune_r5278_bt.test_test_server#bt.test_test_server.TestTCPServerInAThread.test_start_stop(TestingTCPServer)
[18:42] <mgz> that one, right?
[18:42] <mgz> (bumping the number was enough to get past that hang reliably, it seems)
[18:43] <vila> the last you pasted is from the server thread yes, always search for a .join()
[18:43] <vila> hmm, worth renaming that 't' for the connection threads
[18:50] <vila> mgz: and since there are multiple threads involved but only one exception can be raised, as soon as one is, all bets are off since the overall server shutdown has been interrupted...
[18:51] <vila> the idea is that server bugs are not supposed to occur and should be fixed before anything else... which is what we are encountering here I suspect
[18:51] <vila> and more precisely here, I suspect that windows is raising exceptions that are a bit different and there are holes in my exceptions filters :)
[18:52] <mgz> the socket errors are all a bit different, certainly :)
[18:53] <vila> ...which in turn expose the flaw in my design: the "acceptable" exceptions should be easier to specify
[18:53] <mgz> generally, when ever you catch a en E* you also need to catch a WSAE*
[18:54] <mgz> and sometimes another one as well
[18:54] <vila> the 1005* are WSAE* ?
[18:54] <mgz> yup.
[18:55] <vila> hmm, that's very good to hear
[18:56] <vila> The problems with the actual exception catching are: 1) too many different places in the server code, 2) a mix between exception occurring in the normal usage and in the shutdown phase 3) some windows equivalence missing
[18:56] <vila> back to the drawing board it is...
[20:45] <meoblast001> hi
[20:45] <meoblast001> i'm getting this error with one of my scripts
[20:45] <meoblast001> http://pastebin.com/3df3sReW
[20:46] <meoblast001> the script was tested working locally on this system, and previously worked on my server
[20:46] <meoblast001> i only made on modification (switched a split ('\n') with a splitlines()
[20:50] <mgz> serious import resolution screw up
[20:50] <mgz>   File "/usr/lib/python2.5/site-packages/bzrlib/__init__.py", line 19, in <module>
[20:50] <mgz>     from bzrlib import branch
[20:51] <mgz> that can't happen, did you add it?
[20:51] <meoblast001> ugh, wtf
[20:51] <meoblast001> i remove the script and the old one is running
[20:51] <meoblast001> where else could Bazaar hooks be located?
[20:55] <meoblast001> mgz: this is proving to be much more painful than anticipated
[20:55] <meoblast001> it was supposed to be as simple as move files to bzrlib like always, run, everything is happy
[20:56] <meoblast001> i tested it locally, everything works
[20:56] <mgz> well it looks like you've screwed up your bzr installation somehow
[20:56] <meoblast001> i THOUGHT i overwrote the old files
[20:56] <meoblast001> ok, so i have to uninstall and reinstall Bazaar :/
[20:56] <mgz> removing it all and starting from scratch might be easiest
[20:56] <meoblast001> sudo apt-get purge?
[20:56] <mgz> try it.
[20:57] <meoblast001> mgz: ah thanks
[20:57] <meoblast001> it removed everything but my files
[20:57] <meoblast001> so now i can find where the old ones were
[20:57] <lifeless> mgz: hai
[20:57] <mgz> wotcha lifeless.
[20:58] <meoblast001> hm, didn't realize i have custom repositories for bazaar on my server
[20:59] <meoblast001> considering i'm still running hardy >.>
[21:00] <meoblast001> thanks mgz
[21:00] <meoblast001> seems i did overwrite Bazaar critical files
[21:07] <mgz> paella awaits, back to hack in a little bit.
[21:34] <meoblast001> another Bazaar question... i'm using post_change_branch_tip in my script that announces updates in our source respositories
[21:34] <meoblast001> if the server has to pull somewhere though, it also will announce there
[21:35] <meoblast001> is it possible to make it only call a script if the server has been pushed to?
[21:36] <lifeless> in your script, check the url or config of the branch which changed
[21:45] <meoblast001> lifeless: ok, thanks, good idea
[21:46] <meoblast001> lifeless: i'm having some trouble finding a listing of branch members, you by any chance know where that would be otoh?
[21:47] <meoblast001> wait, think i found it
[21:50] <meoblast001> hm, maybe not, hard to tell
[21:52] <meoblast001> lifeless: is it possible for me to store a file in the .bzr directory of a project and then check it later?
[21:52] <meoblast001> i could create a function bzr <something> where it will then create a file that is checked
[22:09] <meoblast001> when i try to check the location i get bzr: ERROR: exceptions.TypeError: cannot concatenate 'str' and 'NoneType' objects
[22:09] <meoblast001> doing a print "COMMITTING TO: " + result.branch.get_parent()
[22:11] <lifeless> well parent can be None
[22:12] <lifeless> if you want to store a config value use branch.get_config()
[22:12] <meoblast001> well, that seems like the only thing in the docs remotely close to a location
[22:12] <lifeless> oh, the branch itself is branch.base
[22:13] <lifeless> though it will be in a virtual chroot, so not the same path you'd see on disk
[22:14] <meoblast001> lifeless: yeah, i get file:///home/braden/test/
[22:14] <meoblast001> could i just pop the file:// off of it and go with that?
[22:20] <exarkun> Hey, why is the snow leopard bzr installer link a 404?
[22:21] <lifeless> I don't know, why is the snow leopard bzr installer link a 404?
[22:21] <exarkun> http://wiki.bazaar.canonical.com/MacOSXDownloads -> http://launchpad.net/bzr/2.1/2.1.1/+download/Bazaar-2.1.1-2.dmg -> 404
[22:21] <lifeless> looks like duplicated info -> badness
[22:21] <exarkun> Okay, I can get behind that, although I don't really know what you mean.
[22:22] <exarkun> Anyway where can I download bzr 2.1.1 for OS X?
[22:22] <lifeless> have a look at http://launchpad.net/bzr/2.1/2.1.1
[22:22] <exarkun> Okay thanks
[22:23] <lifeless> though 2.1.2 is out now
[22:23] <exarkun> Blech.
[22:24] <exarkun> http://launchpad.net/bzr/2.1/2.1.1/+download/Bazaar-2.1.1-OSX-10.6-3.dmg can't be downloaded with curl.
[22:24] <lifeless> anyway, basically I think the wiki page is stale
[22:36] <exarkun> Okay.  Unfortunately that didn't help.  Is there some way to have libtdb on OS X?
[22:40] <lifeless> hmm
[22:42] <lifeless> you want bzr-svn on macosX, right ?
[22:42] <exarkun> yea
[22:42] <lifeless> is http://edge.launchpad.net/bzr/2.1/2.1.2/+download/Bazaar-2.1.2-OSX-10.6-1.dmg what you grabbed ?
[22:43] <exarkun> I got 2.1.1 I think
[22:44] <exarkun> I can try 2.1.2 though
[22:46] <exarkun> I tried 2.1.2, still no libtdb
[22:46] <lifeless> ok
[22:47] <lifeless> https://edge.launchpad.net/bzr-mac-installers
[22:47] <lifeless> is the mac installer project
[22:50] <lifeless> is bzr-svn bundled in the installer ?
[22:50] <lifeless> or are you installing it separately ?
[22:53] <lifeless> I'm about to go out
[22:53] <lifeless> but I suggest the following:
[22:53] <lifeless>  - if bzr-svn isn't bundled in the installer, you're going to need to roll your own dependency chain
[22:54] <lifeless>  - but I think it is bundled in the installer, so start by filing a bug saying 'its bundled but not working' and work up from there.
[22:54] <lifeless>  - if you're time-sensitive about getting this fixed, or willing to fix it yourself, the home page for bzr-mac-installers seems to describe how to get going with the code to do installs
[22:55] <lifeless> and you could probably figure out whats going on fairly straight forwardly, if you know mac stuff.
[22:59] <exarkun> Okay, I just built libtdb myself and apparently it works although it was a horrible experience.  But now I'll go file a bug against something.
[22:59] <lifeless> please do!
[23:00] <lifeless> https://edge.launchpad.net/bzr-mac-installers is the thing
[23:53] <PsyberS> has anyone created a script(s) that will do a bzr log on every file, gather a list of all committers, and then update the file itself to list them (probably replacing some fixed/annotated block in the comments of the file)?
[23:53] <PsyberS> basically so every source file can have a 'copyright 2010 author1, author2, ...' etc that is automatically updated based on who has committed that file