[00:24] hi all [00:28] * fullermd waves. [01:27] poolie: why isn't --forward the default for bzr log? normally one wants to see the last revisions and it's easier if the earlier ones scroll off the top of one's terminal and the latest ones are what's seen [01:29] i guess normally people run it with |less [01:30] or --limit [01:30] it would be a waste to print the whole history just so you see the last few bits, i suppose [01:31] sure, valid points. but log is fast and for files with shortish histories, it's easier OOTB to just 'bzr log' rather than bzr log|less or bzr log --limit xx and the like [01:49] Backward through less makes it easy to go as far as you need back without knowing in advance how far that is. [01:49] 's also why every other VCS back to RCS and probably beyond runs that way. [02:09] fullermd: using less i can see how it is better. running without less in a terminal it is easier by far to use forward. so i just use an alias :-) [02:12] trouble with using less through is that when you quit out, all the logs also disappear [02:12] so you are forced to run log again to look at something else if you need to [02:13] eg i often want to log at the log and use info from there to run another bzr command. but it's harder to do if i am forced to use less since i can't start typing the command and then look back at the log [02:15] Only if you're on Linux, or some other system with broken termcap ;p [02:16] them there are fighting words :-) [02:17] i would have thought the vast majority of bzr users are on linux anyway :-) [02:17] Yeah, that's kinda what I do 8-} [02:18] i am surprised that more folks on linux don't have the same issues as me with using less and bzr log [02:18] In fairness, I should note that I often use my 'flog' alias. [02:20] yeah, it's easy to set up an alias; i just would have thought that the OOTB defaults would make the majority use case, and given the issues with less, i would have thought --forward would be the most desirable [02:20] Generally, it's only useful when you're specifying a -r anyway. Otherwise you sit a long time watching 5 year old revs fly by. [02:21] (or 20 year old revs, depending on the project...) [02:21] true. i normally want to use it with -r [02:22] but that's what --limit is for [02:22] and my brain prefers to look upwards to see earlier revs [02:23] You could setup an alias to make log use --forward, and then have a blog alias or something to switch to backward. [02:23] (my flog actually has --forward and --short) [02:24] yeah, i've got all the aliases set up for me. i was just musing as to why the defaults are the way they are [02:24] after all, anyone who doesn't work like me is clearly wrong :-P [02:25] Oh, so YOU'RE the one who stole my line. [02:26] yep :-) [02:26] Right. That does it. You're on my list. [02:26] Not the top, sadly. But I can slot you in right behind "the entire western hermisphere". [02:27] where you from? [02:27] Well. The western hemisphere. [02:27] hah [02:27] That just makes it convenient, see. No long travelling :) [02:27] i like travel [02:28] although it took 50 hours door-door to get home from budapest this week [02:28] Anyway. I don't think there was every any long public discussion about default direction. But the (AFAIK, exceptionless) universality of future->past in every VCS suggests it's largely approved of. [02:28] well they are all clearly doing it wrongly :-) [02:29] In general, of course. But not in this case, 'cuz I'm happy with it ;p [02:29] well at least it can be easily configured to suit one's tastes, unlike certain other products that shall remain nameless [02:30] Pfui. Other products are easier to configure. You don't need to mess with aliases, you just write a simple little kernel module, and... [02:32] Hey [02:34] I want translate the doc "Bazaar in five minutes". Who should I contact? [02:35] poolie: can you help? ^^^^^^^ [05:23] Hi guys. I've got a problem with a src tree I copied over from another machine. It's stuck on an older revision, when I do `bzr up`, it says it's up-to-date with rev. 1280, but on LP, I see that the repo is already up to rev. 1300. What do I need to change so that it sees the correct location? [05:26] If it's an independent branch, wouldn't you want to use 'pull' to update it relative to the branch on LP? [05:27] fullermd: Yes, you are correct. That did the job. Thanks a lot! [07:03] pre-morning all [07:44] hola people [08:19] morning all! === Quintasan_ is now known as Quintasan [09:07] mgz: morning [09:07] vila: thanks for merging! [09:07] LarstiQ: my pleasure ! [09:07] vila: do you have any hints on how to dig deeper into the hanging http requests? [09:08] yup, let me scollback [09:08] No, he only handles the htpp requests... [09:08] tsk tsk hhtp [09:08] LarstiQ: in case your read the log, I suspect you're re-trying a request that failed, we want the first failure as the server is not supposed to receive more than one request which is probably why it's hanging [09:09] LarstiQ: but talk to wgz/mgz too who did some experiments yesterday [09:11] I could suggest a few things, if you start by getting a minimal set of tests you can get the hang with, [09:11] then we can do some of the debugging things vila tried with me yesterday [09:12] mgz: any issues with the windows installer for 2,5b5 ? [09:12] s/,/./ [09:13] not tried it yet [09:14] need to find out how/if bzr-svn is borked [09:18] mgz: -Dhttp / setting DEBUG in _urllib2_wrappers? [09:19] mgz, vila: I did a full run excluding a couple of tests, and that completed (failures=54, errors=8476, known_failure_count=28) [09:19] next thing is to see if running those excluded tests by themselves hang all the time [09:21] IIRC, you identified a single tests that was hanging when retrying a request. The BadStatus server expects a single request so we know why it hangs. Why the first request failed is the interesting bit [09:21] right [09:23] LarstiQ: so, something like `./bzr -Oselftest.timeout=0 selftest -s bt.test_http` with the debug stuff set, then breaking in and getting the test log may be useful [09:24] also, if you kept the log of that full run and have a few classes of failure/error from it, file bugs tagged pypy [09:24] I had a couple of commonly occuring ones yesterday [09:24] * LarstiQ nods [09:24] mgz: I have some select(-1) too [09:25] mgz: but the vast majority seem to hit the limit for amount of open files [09:25] right, I get that too, so it's worth a bug [09:26] jelmer: Are you working on #917733 or can I steal it ? I think I have a low-risk simple fix for 2.5 and I'm working in this area for trunk anyway ? [09:26] s/?$// [09:26] hm... fd limits... I got massive mem usage, so we may need to check trunk to see if test cleanup is still working [09:30] hrmf [09:31] another option is to hack in a gc.collect() after each test and see if that helps [09:32] bzr has too many cyclic objects [09:32] switching DEBUG from 0 to 2 lets it complete [09:32] at least, when I run only TestBadStatusServer.test_http_has [09:33] probably just slows it down enough to avoid a race [09:33] try with -s bt.test_http. [09:33] which would imply that pypy introduced a new one :-( [09:34] or that refcounting saves us from other issues [09:34] mgz: now it hangs indeed [09:34] ok, I bite, why are you talking about ref counting here, pypy changed something in this area ? [09:34] it doesn't refcount vila. [09:35] different gc algorithm ? [09:35] vila: yeah [09:35] it has several different pluggable gcs, the main one is... [09:35] whatever the name is for a gc that relocates objects [09:36] vila: http://doc.pypy.org/en/latest/garbage_collection.html fwiw [09:36] and you're suspecting that we run into a case where our tests succeed because an object is *not* gc'ed ??? [09:37] (our: cpython) [09:38] we have a bunch of subtle assumptions about object lifetimes still, one of these may cause this issue, or it might be something else entirely [09:39] running _just_ `../pypy-1.7/bin/pypy ./bzr -Oselftest.timeout=0 selftest -s bt.test_http bzrlib.tests.test_http.TestPost.test_post_body_is_received` hangs too [09:39] LarstiQ: set a breakpoint in retry_or_raise and check the first failure [09:40] mgz: The only part of the code matching this pattern I can think of is the smart server and its daemon threads... (Not involved here) [09:40] vila: hmm [09:41] vila: afaics it doesn't get to that point [09:42] can you get back to the BadStatus test hanging ? [09:42] vila: http://paste.debian.net/152791/ is all the output [09:42] vila: sure [09:43] DEBUG alone gives incomplete and possibly confusing output, you probably want -Dhttp and the magical thingy that allows such flags to get passed for selftest [09:45] hm, thinking about the fd limit again, if enough tests fail, that have self.branch or similar, they all end up in a list and will be kept for the whole run, so without refcount to close fds that could run us out. [09:46] the general testcase cleanup seems to be working, but I could fix a few more cases [09:47] mgz: iirc the last time I only looked at blackbox tests because my hardware couldn't run more than that [09:48] mgz: it looks like at least some non-blackbox tests do things like file(foo).read() [09:48] LarstiQ: vila means `bzr -Oselftest.timeout=0 -Dhttp -Eallow_debug selftest ...` [09:48] yeah, that ! :) [09:48] LarstiQ: right, and my change since then should have improved things somewhat [09:49] * vila rings jelmer's alarm clock [09:49] vila: but that only adds stuff to the testcase log, so LarstiQ would also need to break into a hung test, go up till he gets back to the test case, then print self.get_log() to some file [09:49] * LarstiQ gives -Eallow_debug to selftest instead of bzr :) [09:50] right, that :) [09:50] hehe, one more hint that this worked at some point in the past... [09:50] vila: it doesn't hang with DEBUG higher than 0 by itself. Not sure having pdb break in retry_or_raise will hide the race or not [09:50] mgz: ha crap, yeah [09:51] LarstiQ: waiting for the hang, then doing ctrl+\ and using pdb should work [09:51] to see the log/symptoms at least, if not to observe the actual problem [09:51] LarstiQ: get rid of DEBUG then, I'm not chasing the race by itself but I'd like to know why it fails for the first request [09:52] mgz: I'm not sure you can still get enough details about the first failure by waiting for the hang [09:52] by first failure, do you mean in a seperate test? [09:53] the preceeding test was passing for me [09:53] no [09:53] first http request failure? [09:54] then the request will be in the log at least, if not in enough detail [09:54] the BadStatus hang occurred when re-trying a request (when LarstiQ first talked about it), I'm talking of the first http request against the server [09:54] LarstiQ: yup [09:55] vila: breaking in on the hang, going up the stack, retry_or_raise is called with first_try=True [09:56] so, what is exc_type, exc_val, exc_tb [09:57] Excitement by type, excitement by value, and excitement by tuberculosis? [09:57] vila: , 'HTTP/1.0 0 Bad status\n\r' (guessing at the whitespace), [09:57] hehe [09:58] * vila blinks [09:58] \r\n according to the repr [09:58] ... [09:59] yup. [10:00] httplib.BadStatusLine is caught and... calls retry_or_raise without changing first_try ? O_o [10:00] meh, scratch that [10:00] vila: well then it gets into reuqest.connection.close(); response = self.do_open(http_class, request, False) on line 575 [10:00] yeah, misread [10:00] (with a commented out pdb, so probably line 574) [10:02] right, so, my first intuition was wrong [10:02] the test *relies* on the fact that the request *is* retried [10:03] but the server asks for the connection to be closed so the second request should open a new connection ? [10:06] * LarstiQ acts on a hunch unimpeded by knowledge of what he is doing [10:06] "... unencumbered by the thought process..." [10:10] LarstiQ: is there an easy way for you to try this with a bzr based on a revno < 6000 ? [10:10] vila: bzr branch -r 5999 is simple enough, sure [10:11] fullermd: "niet gehinderd door enige kennis van zaken" is the original [10:17] can someone check out this bzr failure in a recipe build please? https://launchpadlibrarian.net/90383865/buildlog.txt.gz [10:18] vila: backtracee seems the same [10:19] mgz, vila: so just before the breakin, it does return self._sock.recv(buffersize, flags=flags), with buffersize=65536 and flags=0 [10:19] bigjools: sounds like a known issue, but bzr-2.4.0 ? [10:19] I don't know what the semantics are supposed to be, but could it be waiting till it has enough data till it can return buffersize bytes? [10:20] bigjools: bug 915505 [10:20] Launchpad bug 915505 in Launchpad Auto Build System "bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split'" [High,Triaged] https://launchpad.net/bugs/915505 [10:20] hehe, he's even faster than me asking him :) [10:21] needs python-debian update on buildds [10:21] :)( [10:21] grar [10:22] thanks [10:22] could work around in bzr-builddeb, but then we'd just need a builddeb update insteat [10:22] LarstiQ: no, most of the responses are far shorter [10:23] mgz: is someone working on rolling a new buildd? [10:23] LarstiQ: that recv is fine, it returns when it gets something, rather than looping and trying to fill the buffer like higher level read calls [10:24] bigjools: good question... probably not? [10:25] mgz: I've upped it to critical. I'll help push it through if someone can tell me what needs changing [10:25] LarstiQ: have you dumped the log from the hung test yet? [10:26] mgz: http://paste.debian.net/152798/ [10:27] bigjools: looks like we don't have an rt for updating it yet [10:28] will check with jelmer later today and get back to you. [10:31] LarstiQ, vila: I wonder if we can get log from the test http server too? [10:33] LarstiQ: I think the next thing that would be useful here is to file bugs [10:33] so we don't lose track of what we know about the issues [10:34] mgz: I'll try to do that now before lunch [10:34] jelmer, mgz: https://code.launchpad.net/~vila/bzr/917733-cmdline-overrides/+merge/89216 up for review, blocking for tarmac AIUI [10:35] tested manually with http://paste.ubuntu.com/809507/ which is a bit silly as the default ui is SilentUiFactory so no output is produced but it doesn't traceback anymore with the fix [10:36] Hi all. has anybody tried to use bzr and kdiff3 in combination to preview merges, in the spirit of http://wiki.bazaar.canonical.com/qbzr/Blueprint/diffmerge ? how to do that? [10:39] I mean, ok for THIS and OTHER, but I would need to get BASE too (which is computed internally by 'bzr merge') to have input to feed to kdiff3 [10:40] qbzr supports external merge tools as far as I know [10:40] I don't know where this is documented though [10:40] vila: yes that's what I read everywhere, but i didn't find any practical example (in the cut-and-paste sense of the term :-) [10:41] http://wiki.bazaar.canonical.com/QBzr/ExternalMerge#KDiff3 [10:42] hmm, not sure it's up to date [10:42] ggherdov: what bzr/qbzr versions are you using ? [10:42] vila: thx a lot. Actually interesting. How to get BASE ? bzr version: checking... [10:43] 2.2.1 [10:43] qbzr: checking... [10:43] with versions recent enough, I think you just need to say you use kdiff3 and the command template is already included [10:43] 0.19 [10:44] ok i'll give it a try. I am not familiar with the GUI, I always use cmd line, so maybe that's why I missed that. [10:44] you need to update your bzr version really, a neater way of configuring was landed since then [10:44] mgz: thx. checking that. [10:44] right, mgz is always faster ;) [10:45] but I concur with the advice, my remark is based on this proposal (and probably some later tweaks) [10:47] thx guy, updating bzr. Actually this imply updating my obsolete fedora 14 to 15... gosh this issue is a fractal. [10:47] mgz: thanks. If a new buildd is rolled, does it just need to pick up the latest python-debian? [10:47] guys* [10:52] ggherdov: you could probably get the extmerge plugin working instead if updating bzr is hard [10:52] bigjools: not sure, will find out. [10:53] mgz: good hint. By the way, do you know the 'oldest' stable release that includes the new mergetools stuff you were pointing in lounchpad? [10:53] launchpad* [10:54] the linked bug 489915 says fixed in 2.4b1 [10:54] Launchpad bug 489915 in QBzr "[master] external diff/merge configuration needs serious rework" [High,Fix released] https://launchpad.net/bugs/489915 [10:54] mgz: ok [10:57] mgz: filed bug 918624 [10:57] Launchpad bug 918624 in Bazaar "some test_http hangs under pypy" [Undecided,New] https://launchpad.net/bugs/918624 [10:57] and nwo I really need to eat something [10:58] LarstiQ: enjoy [10:59] no way , fedora 15 has bzr 2.3 . extmerge is my only way to go. [11:00] uuu, I see, this is ugly, run_bzr really shouldn't be a public function [11:06] mgedmin: well, tarmac will cry if we remove it, just found it imports it so I confirm that's how it triggers the bug (and that my fix covers it) [11:07] it also calls ui.make_ui_for_terminal directly [11:08] ?mg [11:08] ha, not vi [11:08] which reinforces the idea that importint bzrlib should provides sane defaults triggering the least possible amount of IOs [11:08] s/importint/importing/ [11:09] I take it that was targetted at me vila? [11:09] xchat bad habbit of forgetting my settings for completion is really... yes, was for mgz ;) [11:14] mgz: landing on 2.5 ?? [11:14] it's not an api change :) [11:15] seems odd to have all the new config pain for 2.5 but none of the fewer-writes benefit [11:15] hmm, strictly speaking, that's true [11:16] I've got worse things that need to land on 2.5 [11:17] the annoying bit is that it means plugins won't have a beta test period for that so 2.5.0 can be more brittle that our stable-uber-alles users may expect... [11:17] plugins are always borked on our .0 releases anyway [11:17] * mgz takes the cynical view :) [11:19] * vila as RM feels he will have to accept this as a reality [11:19] If you release 2.5.-1 instead, things should work well with .0 a month or two later... [11:21] That's a good option and I'd love it if installers builders follow this trend but we're not fully there yet. I'll try to make it clear in the 2.5b5 announcement [12:42] mgz: regarding 'ValueError: file descriptor cannot be a negative integer (-1)', the amount of tests and the precise tests that fail varies from run to run [12:43] mgz: should I file a bug with that info, and then say "might be a race, might be exhausting filedescriptors"? [12:44] if you can do a reduced run that fails with on select with -1 (should be possible, pick a test subset), [12:44] I'm pretty sure that's an independant issue from the fh exhastion [12:45] likewise, any other failures on reduced runs probably warrant bugs [12:46] and an overall bug for running out of fds on the full testrun with pypy seems reasonable, though the exact tests that fail aren't relevent [12:49] * LarstiQ nods [12:49] will do [12:55] vila: hmm, has your cmdline_overrides patch landed yet? [13:00] (almost there finishing lunch) [13:00] jelmer: yes, on 2.5, any issue with it ? [13:02] vila: Sorry, PEBKAC [13:04] hi! I'm confused by how to specify dates in bzr cat [13:04] I have two revisions that happened at these times: [13:04] revision 4 @ timestamp: Thu 2012-01-19 12:40:06 +0000 [13:04] revision 3 @ timestamp: Wed 2012-01-18 17:58:31 +0000 [13:04] vila: actually, there is [13:04] vila: line 1087 uses config, but it's never imported [13:05] and I do bzr cat -r date:2012-01-19 [13:05] but I get revision 4, instead of revision 3! [13:05] even if I do bzr cat -r date:2012-01-19,00:00:00 [13:05] am I doing something wrong? or is it a bug in bzr? [13:05] * vila blinks [13:06] how on earth did my test succeeded then... [13:06] vila: not sure :) [13:06] pfarrell: that sounds like a bug [13:07] ok, thanks [13:08] pfarrell: if you have a moment, it would be great if you could file a bug report. what version of bzr are you using? [13:08] 2.2.4-0ubuntu1 [13:09] in natty [13:09] yep, I'm just writing it now [13:09] jelmer: ok, reproducced [13:10] pfarrell: it might be fixed in newer versions, I can't easily reproduce it with current trunk [13:10] I wonder is it related to https://bugs.launchpad.net/bzr/+bug/131273 [13:10] Launchpad bug 131273 in Bazaar ""date" revisionspec not returning exact revision when revision time zone differs from local time zone" [Wishlist,Confirmed] [13:10] jelmer: and fixed [13:10] jelmer: would you mind trying it on my specific repository, if I pm you the details? [13:10] pfarrell: that might indeed be relevant. Are r3 and r4 in different timezones from you? [13:10] pfarrell: sure [13:11] er, no, it's all London time, I think [13:12] but maybe the launchpad server is in another timezone ? [13:15] it's located in London too (but its timezone shouldn't be relevant) [13:20] out of curiosity, where in London? [13:21] I have no idea :) [13:29] vila: thanks! [13:30] jelmer: will land when you leave pqm breathe ;) [13:30] vila: :) [14:34] Hi all. About the extmerge plugin http://doc.bazaar.canonical.com/plugins/en/extmerge-plugin.html , something that wasn't clear to me at first: you run 'bzr merge /otherbranch/' and --then-- you call 'bzr extmerge /somefile/' , is that right? [14:35] I thought that extmerge was somehow a substitute of the 'bzr merge' command [15:24] ggherdov: nope, the phrasing is indeed ambiguous on this page but this kind of tool just can't replace bzr merge [15:24] jelmer: progress on urllib-verifies-ssl-certs, [15:26] the http tests don't hang anymore (they needed the right ssl.ca_certs) and I've fixed some more in test_https_urllib ;) [15:26] running a full suite now [15:28] ha, more hanging tests in per_transport, of course [15:31] vila: thx, i figured that out :-) Anyway: my first day with bzr extmerge + kdiff3, I am totally in love <3 [15:31] \o/ [15:33] vila: \o/ [15:35] I missed handling the wrong retry_or_raise call, any cert exception should be propagated, never re-raised... [15:35] should inherit from connection error maybe ? [15:46] vila: it's an error that comes from the ssl module; perhaps we should just be always letting those thorugh? [15:46] yeah, both [15:47] err [15:47] waitasec [15:47] what's the purpose of match_hostname then ? [15:48] vila: the ssl module verifies the certificate and then returns the certificate info [15:48] vila: match_hostname then verifies that the certificate has the same hostname as what we connected to [15:48] ha right, sry, haven't followed the python imp closely enough, yeah, people complained in the past about the hostname not being verified [15:51] great, tests are properly failing now [15:51] SSLError: [Errno 1] _ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [15:52] not super user-friendly, worth re-raising as a CertificateError instead ? [15:53] vila: not sure, do you have a good way of extracting a user-friendly message from the SSL error? [15:54] I think printing the SSL error is probably nicer than just saying "Something went wrong in the SSL handshake" [15:54] k [15:54] wfm, can be refined later, my changes so far are pretty clear so it won't be hard to find the right place back [15:55] so, the config trick is really a hack that don't work for all cases, I think we want dedicated parameters (still defaulting to the config options) for all tests and provide a test_permutation like we do for pycurl [15:57] yeah, and you already provide some context when they occur [15:57] so, 58 failures for a full test run so far [16:05] bzr: ERROR: exceptions.AssertionError: get_next() called when there are no chars left [16:05] what did we decide was the right answer when bzr st says that (2.3.4-0ubuntu1) [16:07] lamont: isn't it a symptom of a broken dirstate file ? (more traceback can help) [16:07] lamont: `bzr repair-workingtree` [16:07] vila: I can beleive that. how do I fix it? [16:07] bzr repair-workingtree [16:07] bzr: ERROR: unknown command "repair-workingtree" [16:07] I shall see if 2.4.0 has that [16:08] https://answers.launchpad.net/bzr/+faq/940 [16:09] is the shortest I can come with, repair-workingtree uses a slightly shorter implementation IIRC [16:10] I need to make 2.4 install in my little silly world [16:14] vila: turns out that just branching and smacking .bzr/checkout over the top of the old branch seems to be sufficient to my needs [16:14] lamont: right, and you can run 'bzr st' to refresh it [16:17] this is nearly the exact same conversation we had last time [16:19] yup :) [16:22] yeah. it fell out of brain-cache [17:09] jelmer: more progress... the *server* was hanging too because an exception was raised about an unknown ca [17:09] so, yeah, getting details from ssl errors is hard, python seem to just rely on openssl and that's where the errors are coming [17:11] I don't quite get why the server complains about the ca... but it does so only when the client do the handshake... [17:12] it's a bit like: (client) oooh, this server is bad, (server) OMG a client said I'm bad !! [17:12] what's the point ? [17:12] anyway, down to 22 failures and no more hangs [17:14] vila: \o/ [17:16] vila: what are the remaining 22 errors? [17:20] [Errno 1] _ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [17:20] because the *transport* don't use the right ssl.ca_certs config option, mentioned earlier [17:21] but I wanted to fix the server hangs first (we're not supposed to encounter them anymore by the way...) [17:21] not sure I will be able to finish tonight but I know where to dig [17:23] basically the config should be used as a fallback as it requires disk resources which led to my own bazaar.conf being erased.. endless fun and some wtf moments :) [17:23] hehe === yofel_ is now known as yofel [18:21] jelmer: gotta go, only one test still failing: bzrlib.plugins.launchpad.test_lp_directory.TestXMLRPCTransport.test_direct_request(https) [18:21] will have to inject the right server and transport there, not the default ones [19:55] * LarstiQ grumbles at blackbox tests leaving 120 open files [19:56] LarstiQ: I bashed all the non-test-specific ones I could find a while back [19:56] but at that point there was no need to go through and edit tests to do file handling sensibly when refcounting works [19:57] * LarstiQ nods === deryck is now known as deryck[lunch] [20:06] hi all [20:18] hey poolie [20:18] heya poolie [20:20] LarstiQ: so, the yellow here should correspond with your issues [20:20] What kind of server-side hooks are available when not using the smart server? [20:20] if you click on one and it says 'unclosed file' that's a likely issue on pypy [20:20] exarkun: none? [20:21] LarstiQ: Why the "?"? [20:21] exarkun: I'm not sure I understand the context [20:21] exarkun: everything that's not a smart server hook, but they get run on the local machine against the remote object [20:22] exarkun: the nature of dumb servers make it impossible to do server side hooks [20:22] hi poolie, wgz, LarstiQ, exarkun [20:22] Say I'm developing an application in a bzr branch and I want to update the deployment of the application by pushing the branch to the deployment environment. [20:22] Should I achieve the effect some other way? [20:23] exarkun: ah, that way [20:23] exarkun: a smart server can do that for you, or you could have the client do it if you're not using a smart server [20:23] exarkun: specifically for that usecase there is bzr-upload [20:24] wgz: thanks! test_merge is not as yellow as I'd expect it [20:24] I don't really know anything about smart servers, except I guess there is some special software implementing at least one kind (the one launchpad uses). It seems like maybe I'd rather avoid having to deploy one of those. [20:24] exarkun: usually it's just bzr [20:24] LarstiQ: Hm. I probably need to restart a process on the server, so it uses the updated code, so I don't know if bzr-upload is sufficient. [20:24] LarstiQ: that's useful to know, implies an actual behaviour difference, what are the files you get leaked there? [20:25] LarstiQ: Oh. Maybe I misunderstood, then. How do I know if there is a smart server or not? [20:25] exarkun: all a smart server over ssh needs is having bzr installed on the remote side [20:25] exarkun: if you're using bzr+ssh:// you're using the smart server [20:25] exarkun: if you can use bzr+ssh:// [20:25] Oh, okay, well that's pretty easy then. [20:26] exarkun: (or well, you could do smart server over http, but bzr+ssh is the most common) [20:26] wgz: let me see about gathering that [20:26] So I can use the SmartServerHooks... Perhaps "server_stopped" is a good one to use for this use-case? [20:27] exarkun: or any of the other hooks, installed server side [20:27] wgz: Oh [20:28] Any of them, really? Like "post_push"? [20:28] that wouldn't be relevent if the server is being pushed to. [20:29] it would run when bzr on the server pushes to some other location though :) [20:29] exarkun: something like the post branch tip change hook should work [20:29] jelmer: Ah [20:29] Any reason to prefer that over server_stopped? [20:29] (it sounds nicer, I want to prefer but, but I don't know why) [20:30] exarkun: if nothing gets changed, no need to restart the process [20:30] post_branch_change_tip is what's normally used [20:30] otherwise your code runs if someone does `bzr log bzr+ssh://...` [20:30] etc. [20:30] Ah, I see. [20:30] oh, that's a good reason too :) [20:31] exarkun: and it doesn't matter if it's push/pull/uncommit, same hook [20:31] with a difference between those on _where_ the hook runs [20:31] jelmer: can you give LarstiQ any hints on debugging fd exhaustion issues? [20:32] wgz: I've got a list now [20:32] * LarstiQ cleans it up [20:35] heh, my check for pypy not having the pythonapi was wrong [20:36] wgz: http://paste.debian.net/152865/ gathered from running "ls /proc/`pgrep pypy`/fd" once a second [20:38] wgz: ooh, the Unclosed file: bits are really spiffy [20:38] okay, niece fed, now it's my turn, will be back shortly === deryck[lunch] is now known as deryck [21:31] jelmer: hey, you might know this [21:32]