[00:36] good, thanks [00:40] question, how much processing does a "bzr branch" do, as opposed to essentially transporting files and unpacking? [00:46] hm [00:46] well, --lsprof-file will tell you quantitatively 'how much' [00:47] it does, for instance, look at the revisions and trees you're pulling across to identify which file texts to send [01:23] ok thanks cool i'll check lsprof. i was also looking for a way to validate a repo, bzr check seems to do this... [01:43] poolie, lsprof is perfect, thanks [02:07] Hello all. When I do "bzr new --colocated-branches --format 2a" from the Windows GUI client to initialize a new repo, it faisl, but it works via a command line on the server (Linux) [02:07] is the version bazaar explorer is using matches the one that the cli one is using? [02:08] Bazaar Explorer is 1.2.1 [02:08] check the about thingy [02:08] and see what version of bzr [02:08] bzrlib 2.4.2 [02:08] this is all on the client [02:09] whats the other version [02:10] and i THINK that colocated branches [02:10] doesn't exist until bzr 2.5 [02:10] and the one you are using is from the bzr-colo plugin [02:10] the bzr about windows says... [02:12] Bazaar Explorer 1.2.1...QBzr 0.21.1, bzrlib 2.4.2, PyQt 4.8.4, Qt 4.7.2, Python 2.6.6 [02:12] so both are 2.4.2 [02:12] im not sure why its not working, but i know i was messing with colocated stuff and its not 'offically' supported yet [02:12] bazaar explorer is just using the bzr colo plugin [02:13] gotcha [02:13] basically what it is right now is just a lightweight checkout [02:13] that points to a branch/repo inside .bzr [02:14] i am lookign in the logs and I think the first line is: [02:14] File "bzrlib\commands.pyo", line 946, in exception_to_return_code [02:14] last line is the most recent call [02:14] paste that [02:17] last line before a generic syntax error is.... [02:17] File "C:/Program Files (x86)/Bazaar/plugins\explorer\lib\workspace_models.py", line 287, in build [02:19] helpful? [02:19] not really haha [02:20] that command works for me on windows [02:22] just doing it througn bzr explorer? [02:22] command line [02:22] I'm doing it through bzr explorer using bzr+ssh connecting to a remote server [02:22] which is on my LAN [02:22] that works for me too on bzr explorer [02:27] I'm doing it through bzr explorer using bzr+ssh connecting to a remote server [02:27] using Pageant for authing to the server [02:27] i dont know why its not working, its working for me :< [02:28] and bzr+ssh shouldn't affect it. i do that all the time [02:35] do you want me to pastebin some stuff? [02:35] sure [03:15] Still here? [03:16] I made a paste but I dunno if you can view it if I set it to private [03:16] http://pastebin.com/bumhufUb [03:16] i can see it [03:17] File "C:/Program Files (x86)/Bazaar/plugins\explorer\lib\workspace_models.py", line 287, in build [03:17] WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: u'bzr+ssh://wolf@10.8.31.188:8888/sopa/.bzr' [03:17] it seems to be working but it is failing on a directory [03:17] like it cant find the file or something [03:22] it's really weird [03:23] might actually be a bug, i dunno if any of the developers are on atm [03:28] by what it spits out, it's looking for the .bzr directory, but it has yet to create it as that's what that command does [03:30] or something, its trying to access the directory but it says the url is invalid [03:32] if I run that command directly on the server it works though [03:32] "cd sopa" then [03:33] bzr new --colocated-branches --format 2a [03:33] yeah, it might be a bug then >.> [03:35] thanks! see ya! [04:46] does nayone know how to make the list of locations in bazaar explorer more..useful? then just "trunk" 20 times [07:56] Hi - I've just upgraded my second machine to precise, and bzr is completely broken for me - i.e.- I get ConnectionReset whenever I try and do anything that involves talking to launchpad. [07:57] I'd submit a bug to LP, but it seems like I must have done something wrong, otherwise someone else would have found this already - any ideas? [07:58] Try ssh/sftp'ing manually and see what happens. [07:58] for example: http://pastebin.com/X5y5AXPF [07:58] fullermd: I'll try that.... [07:58] Permission denied (publickey). is the tipoff. [07:58] Means you don't have the ssh key LP is expecting. [07:59] I thought Bazaar used theanonymous transport when that happened? [08:00] as in: it would fall back to anonymous transport?' [08:00] No, at that point there's nothing to fall back on. [08:00] When you haven't lp-login'd, it uses http instead of bzr+ssh. But once you have, it does. [08:01] ahh, and there's no 'lp-logout' [08:03] Don't think so, no. [08:03] cool - that works now, I had the wrong key in my LP account. Thanks for your help. [08:06] hi all ! [08:06] Oh, figures. I solve the problem, _then_ vila appears. Typical. [08:07] hehe [08:08] lp-logout is spelled: 'bzr config --scope bazaar --remove launchpad_username' [08:09] for recent enough bzr versions [08:09] but yeah, the best way to debug this sort of issues is 'ssh -vv' [08:13] * fullermd gets a little crosseyed. [08:13] Are you sure the first word of that command isn't "git"? [08:14] yup, what makes you think otherwise ? [08:14] too complex ? [08:18] Oh, no. I'm sure it'll be perfectly clear after a weekend course and an hour or two of meditation. [08:21] hi guys. [08:22] haha. [08:22] I have a checkout of a repository from box A at box B [08:22] I want to run uncommit on box A. [08:23] what do I need to do on box B so they are in sync ? [08:23] a pull or an update ? [08:25] fullermd: one hour in the morning and one hour in the evening, best results guaranteed ! === Merwin_ is now known as Merwin [08:28] sbarcteam: it's hard to talk about 'sync' when one side has uncommitted changes in the tree [08:29] sbarcteam: it's easier to commit on one side and then pull from the other side with --overwrite if needed [08:33] vila, since uncommitted changes are local, and by "sync" I mean update/pull I think the question is well defined. [08:34] if the answer is not well defined, this means: either there is a bug in bzr behaviour, or the answer is wrong :) [08:34] since if I am doing an uncommit, bzr branch knows it is bound. [08:35] and if I am doing update from a bound location, it should be in sync to the latest (or what I specified) [08:35] I experienced another behaviour. [08:35] that the checked out repo had remainders of the uncommitted revisions. [08:35] wow, no offense intended, but thanks for mentioning you're using a bound branch [08:35] yep. [08:35] sorry. [08:35] Oh look, another round of bound checkouts screwing things up. [08:36] He said 'checkout' right at the start... [08:36] So, what I am saying here: [08:36] fullermd: I know and couldn't resolve the inherent ambiguity :-/ [08:36] IS the branch that has been checked out NOT supposed to be doing "uncommit" ? [08:36] sbarcteam: so, you have a working tree on both sides ? [08:37] if by working tree you mean files except .bzr, then yes. [08:37] and the working tree on the other side not being updated is what you're not expecting ? [08:37] sbarcteam: The issue is that after the uncommit, your local branch is 'ahead' of the remote. And bzr has no way of knowing whether that's because something is supposed to be backed out, or you did something locally that hasn't made it to the remote yet. [08:37] (the latter is assumed) [08:37] fullermd, you mean: when I am running update against the branch I checked out, and I'm ahead of it ? [08:38] Right. [08:38] and that my bzr doesn't know if this has been committed with --local. [08:38] (technically, "I have something the remote doesn't"; 'ahead' is technically imprecise, but colloquially useful) [08:39] yes, but in that case I'd expect MERGE behaviour to reproduce, or a statement "man, you've got some stuff we don't... beware the jabberwack!" [08:39] You presumably got the "standard" behavior, of the commit you have locally turning into a pending merge. [08:42] fullermd, I had the pending merge. I then ran merge, but was missing files. [08:43] as a result, I got panicked, got back to the checkout branch, ran uncommit there, then re-did the merge again, and then committed. the missing files appeared. [08:43] ouch [08:43] As you can imagine, finding out the files were missing was not much fun. [08:44] Up to now our uncommit attempts did not render such a heart attack. [08:44] sry for that, but when you have pending merges, you should either commit or revert, doing a merge there is... asking for trouble unless you really know what you're doing (bzr should tell you to use merge --force in this case, didn't it ?) [08:45] fullermd, is there a way to know the changelist is coming from a remote checkout branch ? [08:45] (I mean within python code of bzrlib) [08:46] yes, a 'master branch' is involved in this case (from the bound branch side of course) [08:46] from the remote side, no [08:47] so it would be "nice to have" a message BEFORE doing the change stating: this uncommit has changes from non-master branches. you better run uncommit on the specific branch it was added at [08:48] does this make any sense ? [08:49] not sure. Can you elaborate on 'change' and 'specific branch' ? (remote/local ?) [08:49] (maybe the message should be phrased otherwise, but suggesting to run uncommit on the committing branch seems to me a good idea of having less gray hair) [08:49] ok, in terms of A and B. [08:49] A has a master branch. [08:49] B is a checkout branch [08:49] I want to uncommit something. [08:50] :-/ uncommitting a shared branch is always tricky if you don't control who has already copied the revision you're about to remove from a branch history [08:51] vila, uncommit command doesn' [08:51] all users will need to 'pull --overwrite' at some point [08:51] t say it is tricky. [08:51] true [08:51] and pull --overwrite can do even more damage. but that's another story. [08:51] I say it is easier to have a simple paragraph in uncommit help, than to add code to change the behaviour. [08:52] Also, take into the account, the person doing the uncommit, is not always aware of everything in question. [08:52] and ALL the aspects. [08:53] A tool would be a more robust tool if it prevented the user from wrongdoing by instruction.... [08:53] anyway, I had to rant a bit. [08:54] right, so you want a big flashing warning when uncommit is ran right ? [08:55] sbarcteam: care to file a bug about it ? [08:55] where to ? [08:55] https://bugs.launchpad.net/bzr/+filebug [09:10] morning [09:55] mgz: morning ! [10:00] hey vila [10:01] lp fdt alwasy comes just when I need something [10:04] done, let's try again [10:39] Hi! I'm blocking on : bzr: ERROR: Connection closed: Connection lost while sending request. 5/36719 [10:39] Whil doing a pull, always at 5/, that's strange [10:40] against what sever? [10:40] *server [10:41] running with the debug flags for the protocol used set then looking at .bzr.log may help [10:43] On launchpad [10:43] response = self.retry_or_raise(http_class, request, first_try) [10:44] ConnectionReset: Connection closed: Connection lost while sending request. [10:44] Hum, seems to be launchpad which have problems ? [10:45] they had fdt and were back up at 10:04 [10:45] and also a few issues before then [10:46] if the timestamp on your disconnect is after that, they'll probably be interested === Quintasan_ is now known as Quintasan [12:32] couple of pypy windows specific issues cause a lot of failures [14:22] "An operation was attempted on something that is not a socket" ... EBADF ftw [14:24] any ideas on that one? the listdir+unicode one is just the pypy _os module isn't very good === gthorslund_ is now known as gthorslund [14:44] which one ? [14:45] EBADF not being raised ? [14:45] most probably pypy should be fixed to raise it instead of the windows immoral equivalent [14:47] ah, er... so all those large number of failing tests expect EBADF and the error is just escaping? [14:47] alternatively we may recognize 10038 as meaning EBADF everywhere we catch EBADF but.... will be invasive and risky [14:47] yup [14:47] well, I'm 99% sure [14:48] but the message itself pretty much describes what EBADF is about: the object has been a socket, it's not anymore [14:49] well, not a 100% accurate description but in all cases I've encounter EBADF the object was a socket and the socket has been closed (which in Cpython implementation means the methods are re-bound and raise this exception) [14:50] EBADF means the kernel doesn't think what you have is a file descriptor at all [14:51] * vila nods [14:51] yup, looks possible [14:51] the Cpython implementation uses this for _closedsocket() objects [14:51] sock.fileno() here is -1 [14:51] see socket.py line ~170 [14:52] and it got past self.ignored_exceptions [14:52] right, you can add it there but that won't cover the client side [14:53] EBADF is part of ignored_exceptions right ? [14:54] errno.WSAEBADF is 10009 [14:54] we have errno.WSAENOTSOCK [14:54] O_o and what is 10038 then ? [14:55] adding that gets the test through to a ValueError on select because -1 is invalid [14:56] remove the select [14:56] :) [14:57] seems like something fundamental has gone wrong earlier though [14:57] I was half joking though, mixing explicit blocking ops and select.... [14:57] we shouldn't be trying things on invalid sockets [14:57] we can't know if the socket is valid until we try [14:58] there will always be a race [14:58] -1 is always invalid [14:58] getting EBADF is expected though [15:00] IIRC when you call shutdown() one side is already blocked and will receive EBADF [15:00] wgz: what is 10038 ? [15:01] WSAENOTSOCK, it's what gets raised if the fileno is -1 [15:01] it's possible this is basically a refcount bug [15:02] adding it to the ignored list at least gets some tests further through or with different errors [15:04] wow, ENOTSOCK exists... never seen it before === mgedmin_ is now known as mgedmin [15:05] It's what you get for socket-only calls like send/recv/setsockopt/... on valid file descriptors that aren't sockets. [15:05] Because they're still valid FDs, EBADF isn't appropriate [15:07] hmm, thanks LeoNerd [15:08] wgz: we should not encounter this at all, may be something bad happened earlier [15:09] * vila suggests comparing socket implementations or failing tests between python and pypy [15:09] python tests that is, not bzr tests [15:16] with the code added to ignored ones: [15:18] modified-2.7 ? [15:18] note, still hangs, and still has some failures [15:18] ^pypy change the stdlib a bit [15:19] ... [15:19] but I don't see why their socket module gets a _sock object that contains a bzrlib.transport.http._urllib2_wrappers.Response instance [15:19] which is what's blowing up there [15:19] other way around [15:19] the response reads the body from a socket [15:19] through a makefile() object for that matter [15:20] the AttributeError message has it all wrong it appears [15:21] pdb agrees with the diagnosis [15:21] but that doesn't really help with the cause [15:21] pdb says what ? [15:22] -> self._sock._decref_socketios() [15:22] (Pdb) self [15:22] [15:22] (Pdb) self._sock [15:22] [15:22] (diagnosis is ? self._sock is a Response or AttributeError message is borked ?) [15:22] O_O [15:23] ._. [15:23] serious breakage [15:24] I suspect their changes to urllib2 and the _urllib2_wrappers need serious looking at [15:24] will probably resolve the http hangs though [15:24] they changed that too ??? [15:24] and httplib also ? [15:26] yup, though we're not really ones to complain [15:26] I don't follow [15:26] understand [15:27] we also modified the stdlib in pretty invasive ways [15:27] naaah [15:27] :) [15:28] I don't think we monkey patch anything in socket or urllib2, we use them and derive a lot though :) [15:30] WSAECONNABORTED also gets propogated by a few tests. [15:31] hmm [15:31] anyway, enough fun, I'll do another reduced run and see how far it gets before hanging, and get back to other things [15:31] the memory usage is pretty appalling [15:32] wgz: don't you think you should separate windows specific issues from the rest ? Or are all the tests already passing on ubuntu with pypy ? [15:32] http was hanging, but there's no way I can run the suite under pypy on my nix boxes [15:33] :-/ [15:33] certainly there are fewer issues on nix, but the hang looks cross-platform :) [15:34] . o O (perhaps related to the hang we were seeing with https?) [15:34] the one LarstiQ mentioned yesterday wasn't diagnosed properly, the traceback he pasted hinted that the first request failed for a reason I'd like to know [15:34] jelmer: nah, that one is yet another cause (but also involves retry_or_raised though) [15:36] i.e. first request failed, second request (same) retried by retry_or_raised hangs because the server doesn't expect another request [15:37] that's crystal clear for LarstiQ case, less clear for the https case, but we already know that in the https case the first request failed because the cert couldn't be verified (which is certainly not the case for LarstiQ ) [15:38] * vila should get rid of all the self._debug stuff and use the debug http flag instead for retry_and_raise, seriously [15:39] wgz: in the mean time, you could set DEBUG to >= 2 in _urllib2_wrappers and get more details [15:41] issue is we don't get the log from hung tests [15:41] any more. [15:41] because it just goes to a StringIO on the case, not to disk [15:42] it's probably possible to break in and poke it, on nix at least [15:42] DEBUG relies on 'print' [15:43] which is why I wanted to use debug.flags instead, but it would harm you there ;) [15:43] to stdout? [15:43] bare print, so yes [15:43] hm, may be helpful then. [15:44] no flush() though [15:52] okay, that bigger run completed, and is greener [15:57] looks a lot like random failures no ? [15:58] (I looked at the test_http ones and there is no clear pattern) [15:59] 'Terminated due to possible deadlock' sounds... weird, what do you mean by 'possible' ? Either you see a deadlock or you don't, if you're not sure, let it go ;) [15:59] it's a timeout. [16:00] pypy adds a watchdog thread ? [16:00] the parent process gives the child a limited amount of time before killing it off [16:00] it's in my test runner. [16:00] ha [16:00] for each test ? [16:00] with DEBUG=2, hang looks like [16:00] ^yup [16:01] seems odd that the problem test gets the status line but then no headers [16:02] could be a flush issue I guess, but stdout should be, and looks, line buffered [16:02] yup, same thing again [16:03] hmm [16:04] so, debug output is splitted between self._debuglevel (from DEBUG) and http in debug.flags [16:04] if you want the full monty you need to set both, I mentioned DEBUG for the retry_or_raise specific output, sry I was unclear [16:05] but retry_or_raise doesn't seem to be involved in your case [16:06] which means you're not on the same track than LarstiQ yesterday ? [16:06] possibly not, the cases are different at least [16:06] may still have an underlying cause alike [16:07] yeah, having makefile() suddenly get a Response instead of socket strongly suggest that sockets can get out of sync between server and client, from there hangs are bound to happen === iBasic is now known as BasicOSX === zyga_ is now known as zyga === deryck is now known as deryck[lunch] === zyga is now known as zyga-break [17:53] vila: still there? [17:54] enough but by much ;) [17:54] meh, s//not/ :) [17:54] vila: we seem to be relying on bzrlib.initialize being called again [17:54] really ? [17:54] where ?? [17:55] vila: e.g. clouddeck fails to start here, because: [17:55] exceptions.AttributeError: 'NoneType' object has no attribute 'cmdline_overrides' [17:55] meh [17:55] tarmac seems to be hitting the same [17:55] complete traceback ? [17:55] bzr version ? [17:55] the only relevant bit from bzr is: [17:56] File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1074, in run_bzr [17:56] bzrlib.global_state.cmdline_overrides._from_cmdline(override_config) [17:56] vila: bzr.dev, 6440 [17:57] same in lp:bzr/2.5 :-/ [17:58] most probably a code path we haven't encountered yet [18:01] Yo [18:01] Hey Gustavo [18:01] Quickie: is there an easy way to tell the revision of a tree, without bzr | grep | sed? [18:02] niemeyer: of a tree specifically, or of a branch? [18:02] jelmer: A branch should work too [18:02] jelmer: It's for juju's charm store [18:02] jelmer: I have to import a bunch of branches from lp onto a db [18:02] jelmer: and tag them with their respective revids [18:03] niemeyer: that should be really easy with bzrlib - are you doing this from Python? [18:03] jelmer: No, from Go/cmdline [18:03] niemeyer: ah [18:03] jelmer: But.. python -c is not too hard either :) [18:03] jelmer: I'd prefer a command line, but happy with python -c too if there's no easier way [18:03] niemeyer: 'from bzrlib.branch import Branch; Branch.open(url).last_revision()' is the python way [18:03] jelmer: Hah, brilliant, thanks! [18:04] niemeyer: otherwise, cut -d " " -f 2 .bzr/branch/last-revision [18:04] jelmer: Ohhh.. that sounds nice too [18:04] jelmer: Since I can bring the logic into the code itself [18:04] niemeyer: (-f 1 for the revno) [18:04] niemeyer: the only issue with that is that it's less robust against format changes [18:04] jelmer: I'll follow up with the python -c trick since I'm doing a spike/experiment at the moment, but probably introspect the rev file down the road [18:05] niemeyer: not that changes in this particular bit of the format are likely [18:05] jelmer: Yeah, understood [18:06] jelmer: Hmm.. breaks with lightweight checkouts too, of course.. [18:07] niemeyer: yeah, though you could look at the tree revision instead. That's in .bzr/checkout/dirstate and a bit harder to extract [18:07] jelmer: the fix for bug #863401 missed this case, if you can file a bug with the failing script (probably import bzrlib; run_bzr(...))that would be nice [18:07] Launchpad bug 863401 in Bazaar "library state will require explicit initialisation (but not yet)" [Critical,Fix released] https://launchpad.net/bugs/863401 [18:07] vila: ok [18:08] jelmer: Cool, I'll probably stick to the Python stuff for now [18:08] jelmer: Future generations will likely thank me for that ;) [18:08] why is `bzr revno --tree` not the right thing? [18:08] niemeyer: :) [18:08] mgz: That's a revno, not a revid [18:09] mgz: That said, you have a point there.. this is a pretty fundamental piece of information. Having "bzr revid" would be nice [18:09] worth adding a --show-ids param there (I'm gone for good now ;) [18:09] niemeyer: there is 'bzr revision-info', but that shows the revno too [18:09] vila: +1 [18:09] niemeyer: so 'bzr revision-info | cut -d ' ' -f 2' will work [18:09] jelmer: Oh, that sounds good [18:10] jelmer: I'll go with that.. I can easily do the cut part with code [18:10] jelmer: Thanks! [18:17] vila: hmm, it seems pretty hard to fix this properly [18:18] vila: I think we'll have to require library state in order to run run_bzr === deryck[lunch] is now known as deryck [18:23] jelmer: the best way to cover all cases may be to call bzrlib.initialize(setup_ui=False) unconditionally ? Not sure about the fallouts but I'd rather fix them once and for all, document it and see if the import load is tolerable [18:23] jelmer: (but I should really go now ;) [18:58] manual rebasing time.. [19:08] hi jelmer, poolie [19:08] hi Noldorin_ [19:08] how's it going? :-) [19:13] jelmer, ^ [19:13] Noldorin_: alright, how are you? [19:13] good thanks [19:13] jelmer, been doing much bzr work lately? [19:16] So if bzr blame says a change occurred in rev 96.4.29... how do I see what revision the change *actually* occurred in? [19:17] Noldorin_: some - mostly related to colocated branches and HPSS [19:17] cody-somerville: you mean, what mainline revision? [19:17] jelmer, aye [19:17] jelmer, ah ok cool [19:17] jelmer, so when can i next pester you to fix the bzr-git bug? ;-) [19:21] cody-somerville: use -rmainline:96.4.29 [19:22] cody-somerville: e.g. "bzr revno -rmainline:6037.1.4" [19:22] cody-somerville: or if you care about the commit message, "bzr log -rmainline:6037.1.4" [19:22] Noldorin_: heh [19:23] Noldorin_: same as always, it's on my todo list but I haven't gotten to it yet [19:24] heh okay [19:24] yeah, it's a blocking issue for me but otherwise low priority :-( [19:24] jelmer, do i have to create loads of fake user accounts and report as blocking issue? ;-) [19:43] Hello all. Found a bug in Bazaar I think. Thorws the wrong kind of error: http://pastebin.com/feLzywii [19:44] The issue was that I forgot to load my private key so it couldn't connect, but it threw something else [19:45] File "bzrlib\smart\medium.pyo", line 968, in __init__ TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://wolf@10.8.31.188:8888/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. [19:45] that happened when trying to commit === mwhudson_ is now known as mwhudson [19:51] BlindWolf8: hi [19:51] hey again! [19:51] BlindWolf8: that does indeed look odd - can you file a bug? [19:52] I'll have to file one later as I'm in the middle of some things...doing a SOPA Game Jam :-) [19:54] heh, ok [20:00] jelmer, cool, thanks. === yofel_ is now known as yofel [20:40] This might be more a launchpad problem, but I want to delete this branch: https://code.launchpad.net/~clint-fewbar/charm/oneiric/nova-cloud-controller/trunk .. but it says there are 3 branches using its revisions. Is there a way I can redirect their stacking elsewhere? [20:43] delete them [20:44]