[00:00] Morning. [00:00] hello lifeless, spiv [00:04] spiv: we really need to finish that fix off; will it benefit from pairing [00:08] lifeless: just paging it back in after the break... [00:08] spiv, lifeless, i'm planning to be pretty short with mail this morning and then do fetch progress and bugs [00:20] lifeless: so I'm about to send the client-side fix to the list for review; it's basically the same patch as before, but the fix is duplicated to InterDifferingSerializer too. [00:20] ok [00:20] lifeless: (I'm not thrilled by the duplicated code in InterDifferingSerializer, but then I'm not thrilled about InterDifferingSerializer existing in the first place) [00:21] lifeless: and I have the server-side fix that I need to add tests for [00:22] merging/pulling in changes that delete directories sucks. [00:22] lifeless: the big outstanding item is NoSuchRevision errors from the server when doing recreate_search on a vanilla SearchResult [00:22] spiv: ack on both points about IDS [00:23] lifeless: I haven't yet dug into exactly what's going on there, maybe these patches will fix it, but I suspect they might not. [00:23] spiv: indeed [00:23] lifeless: it appears there's a problem that the client, which sees the full graph, has a different len(included_keys) to the server [00:23] spiv: that would make sense [00:24] if the search spans the stacking boundary. [00:24] the client knows where the keys came from; it could choose to split the search differently [00:25] I'm not sure what we should do there; perhaps in the client, if the server is stacked and the server gives NoSuchRevision, it could switch to asking for the ancestry-of the heads and then fetch the missing bits elsewhere? [00:25] Or as you say ask only for the right keys in the first place. [00:25] spiv, hi. Do you have any news on bug 354036? [00:25] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 [00:26] lifeless: so I'm not sure that pairing is necessary, but if you want to start tackling that part while I finish off the bits I've got, that would be extremely helpful. [00:27] lifeless: What I have should fix initial pull, but I'd expect the NoSuchRevision flavour could happen if there's already a local repo... I suppose a workaround would typically be "update your trunk branch in that repo then try pull/update of the affected branch again". [00:28] lifeless: Also, while it's a related bug, I'm going to give the NoSuchRevision bug its own bug report I think. [00:28] beuno: that's just what we are talking about right now :) [00:28] beuno: its been easter [00:31] beuno: in short: I have a candidate fix to stop the client creating broken branches, and also another fix for the server to stop unfixed 1.13 (and 1.14rc1) smart clients from making broken branches. [00:32] yay [00:32] thanks [00:32] I keep having to downgrade to 1.13 to work on launchpad [00:38] So... debian updated my bzr/bzrtools, and now I have the new shelf format.. how do I get at my old shelved data? :) [00:42] LeoNerd: shelve1 [00:42] Ahhh... [00:45] lifeless: I've filed bug 360791 [00:45] Launchpad bug 360791 in bzr "get_stream on stacked branch causes "Error received from smart server: ('NoSuchRevision',)"" [Undecided,New] https://launchpad.net/bugs/360791 [00:45] rockstar, if you're around. Do you know what this would be happening with bzr-autoreview? http://paste.ubuntu.com/150478/ [00:45] beuno, jaunty [00:46] rockstar, python 2.6? [00:46] lifeless: Having written that bug report I'm pretty much certain its a separate bug introduced by the get_stream verb. [00:46] beuno, yeah, it's python 2.6's fault. [00:46] rockstar, is it launchpadlib? [00:47] spiv: yes, I agree [00:48] beuno: "apt-cache policy python-httplib2"? [00:49] james_w, Installed: 0.4.0-1 [00:49] 0.4.0-0ubuntu2 0 [00:49] 500 http://archive.ubuntu.com jaunty/universe Packages [00:49] beuno: err, where does it say 0.4.0-1 comes from? [00:50] james_w, ah. Launchpad deps [00:50] PPA [00:51] please let whoever controls that PPA know about best versioning practices [00:51] james_w, ironically, it's celso :) [00:51] you can "sudo apt-get install python-httplib2=0.4.0-0ubuntu2" for now [00:51] heh :-) [00:53] james_w, thanks [00:53] works now [01:11] spiv: I think I'll do for BzrDir.get_config what I did for Branch.get_config [01:12] spiv: to keep moving the ratchets [01:31] morning all [01:32] hiya igc [01:34] hi beuno [01:35] how's it going igc? [01:37] beuno: pretty tired actually - slept most of the last 4-5 days [01:38] jelmer: why do your branches for bzr-svn have to have version numberes? [01:38] er. numbers. [01:39] igc, sorry to hear that :/ [01:39] will we be seeing you at all hands? [01:39] moin [01:40] SamB: ? [01:40] jelmer: apparantly I've been stuck on the 0.5 branch without realizing it! [01:40] SamB: ah, you mean the release series? [01:40] SamB: you can use the 'bzr.dev' branch, which symlinks to whatever release series works with bzr.dev [01:41] do I just use --overwrite with pull to switch? [01:41] considering that I have no local commits? [01:41] beuno: no unfortunately - I'm still unable to travel for a while [01:41] hi jelmer [01:41] SamB: yeah, and --remember [01:42] jelmer: why not have lp:bzr-svn -> lp:~jelmer/bzr-svn/bzr.dev ? [01:43] besides the fact that that's a bad URL [01:45] jelmer: what's a URL that will always be for bzr.dev ? [01:45] SamB: lp:bzr-svn already points at the 0.6 branch [01:45] SamB: but bzr stores the expanded URL, not the short one [01:45] exactly [01:46] SamB: what URL lp:bzr-svn points at depends on the active release series [01:46] SamB: and there is no 'bzr.dev' release series, only 0.4, 0.5, 0.6, etc [01:46] SamB: anyway, http://people.samba.org/bzr/jelmer/bzr-svn/bzr.dev should always works [01:47] heh [01:47] jelmer: so ... why *don't* you have a bzr.dev series ? [01:48] bzr does [01:50] spiv: happy birthday to mary (i think) [01:51] SamB: because I don't actually have a separate 'main development' branch like bzr [01:52] you could just split off your numbered branches after release ;-P [01:53] SamB: but I do actually keep working on these branches for a while when I do minor release [01:53] I noticed [01:53] otherwise I wouldn't have needed --overwrite ;-P === mario__ is now known as pygi [01:55] hmm ... I'm still getting asked for username/password :-( [01:56] SamB: see the recent thread on the mailing list [01:56] SamB: bzr does a POST request to the HTTP server first [01:56] and the server replies with a 401 Auth required reply [01:57] jelmer: oh, I thought you said it should be fixed? [01:57] SamB: where did I say that ? :-) [01:58] SamB: you can work around the issue by removing get_smart_medium() at bzrlib/transport/http/__init__.py:142 [01:59] SamB: should be fixed now (0.6 branch) [01:59] about 12 hours ago, I think? [01:59] SamB: ah, that was the prefix issue for svn-import [02:00] oh! [02:00] heh [02:01] did you know that jelmer sometimes says ambiguous things? you should fix that ;-P [02:06] poolie: yes :) [02:08] SamB: :-P [02:29] * SamB wishes firegpg wouldn't invoke gpg --import synchronously ... [02:30] or whatever that option actually is [02:40] lifeless: so, now that it's tuesday.. [02:41] lifeless: Any chance you can have a look at my InterBranch.pull() patch ? :-) === jamesh_ is now known as jamesh [02:54] jelmer: what do you mean? it won't be tuesday for about two hours and 6 minutes yet! [02:55] jelmer: yes, I will try to [03:02] spiv, do you want me to review your bug 354036 patch? or is lifeless going to? [03:02] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 [03:03] poolie: I hope lifeless will, but another pair of eyeballs is certainly welcome! [03:05] spiv: done [03:12] lifeless: thanks [03:14] lifeless: it's not immediately obvious to me how to make a good helper function, because the I find the parents in the two different code paths is pretty different. [03:15] the variable names, or the data? [03:15] lifeless: in RepoFetcher we just ask the target after we've inserted the stream, but in InterDifferingSerializer it's a bit messier... perhaps it doesn't need to be. [03:16] In InterDifferingSerializer I reuse the Revision objects that we already have (in pending_revisions), for instance. [03:16] parent data should be either cheap, or cached [03:16] I'd use the same code [03:17] And also I'm doing this before the revision objects are inserted. [03:17] uhm [03:17] Which has the nice property of making sure all the inventories are there before the revisions that depend on them. [03:18] But perhaps that's not so important? [03:18] interdiffering topological anway [03:18] bah, insert missing words [03:18] And letters ;) [03:20] But even working topologically, if we do "insert inventories; insert revisions; insert the other inventories needed by those revisions", then there's a window when we have nearly-but-not-quite complete data there. [03:20] indeed, and agreed [03:20] Which maybe doesn't matter, because probably if anything goes wrong it'll abort the write group, etc. [03:20] can't depend on write groups in this code [03:20] uhm [03:20] ok, go without a helper [03:21] but we want to get to pre-checking it everywhere, or something like that [03:21] Yeah. [03:22] any idea about [03:22] SmartMessageHandlerError: The message handler raised an exception: [03:22] Traceback (most recent call last): [03:22] File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 1034, in done [03:22] self.message_handler.end_received() [03:22] File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/message.py", line 161, in end_received [03:22] self.request_handler.end_received() [03:22] File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/request.py", line 345, in end_received [03:22] self._run_handler_code(self._command.do_end, (), {}) [03:22] AttributeError: 'NoneType' object has no attribute 'do_end' [03:22] Huh, no. [03:23] Something is resetting _command prematurely? [03:24] dunno yet [03:26] File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 893, in accept_bytes [03:26] _StatefulDecoder.accept_bytes(self, bytes) [03:26] File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 388, in accept_bytes [03:26] self.state_accept() [03:26] File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 998, in _state_accept_expecting_message_part [03:26] self.done() [03:26] I think its the unknown verb handling on the server [03:26] Hmm, it could be, yeah. [03:26] I thought that was tested, but perhaps there's a gap. [03:28] * SamB ponders the various difficulties sure to be involved in any attempt to use bzr-svn in DOS ;-> === bob2 is now known as Guest28280 === Guest28280 is now known as bob2 [03:49] igc: Composite tree review pring [03:49] s/pring/ping/ [04:02] hi thumper [04:02] thumper: I'm half way through - hope to finish today [04:02] igc: that's great, thanks [04:03] I'm still really unsure that a different tree class is the right approach [04:03] it just seems to move the complexity around [04:03] and adds to it [04:06] lifeless: in which case you really need to talk with abentley and others about this [04:06] I don't know enough to give intelligent answers [04:07] but I want to make sure we have a good story here [04:10] thumper: I have talked to aaron about it; we disagree [04:10] doing it with an external object means we have to have a index for subtrees, and that adds complexity. [04:10] iMNSHO [04:11] OTOH aaron has working code and thats important [04:11] the big thing is to make sure that there are no performance regressions as the changes land in trunk [04:11] I think that we are in agreement on that last point [04:50] * igc lunch [05:40] spiv: branch done [05:40] spiv: onto the next one after a short break [06:44] spiv: man, I found another cheap win [06:51] lifeless: hooray [06:52] on the order of 12 round trips [06:52] ! [06:52] running the full test suite now to find issues [07:04] well, some stuff breaks [07:08] lifeless: what are you working on that you found 12 round trips? [07:09] hi all [07:11] performance [07:17] thumper: I don't have enough info to answer what I think you are asking [07:18] lifeless: on the order of 12 round trips [07:18] lifeless: HPSS something or other> [07:18] ? [07:19] well yes, everything is hpss [07:19] lifeless: I'm just curious [07:19] lifeless: just wondering if push/pull is going to get faster [07:19] thumper: thats the idea :) [07:19] * thumper pokes lifeless in the eye for being obtuse [07:20] lifeless: it seems you are trying to read too much into my curiousity [07:20] thumper: it will get faster as we fix more things; I'm investigating a possible improvement at the moment; it doesn't work so its not an improvement [07:20] and I *don't know* what it changes [07:20] that seems kinda weird [07:20] that I don't know? [07:21] Pshaw. This is software; since when is 'working' a necessary ingredient? [07:21] fullermd: when you have users [07:22] thumper: I don't know because we still have over 50 different method calls on common use cases [07:22] thumper: and its hard to tell what actually changes when you tweak something and 10 or so dissapear [07:22] I specifically moved around the set_parent method on Branch, thats all [07:23] until I diff the network traffic, complete the test run, and so on - its all speculation; and I try to avoid speculating [07:24] thumper: also please, enough with the eyepoking, its unpleasant imagery [08:09] thumper: so I can answer now, while I still don't know why, getting rid of the set_parent method on RemoteBranch gets rid of 6 hpss calls in our same server use case [08:09] and in our push --stacked use case === serg_ is now known as serg [08:26] lifeless: Regarding https://blueprints.launchpad.net/bzr/+spec/merge-commit-reuses-log are you willing to guide me where to start, and hopefully I could contribute with code some day? [09:17] * igc dinner [10:48] hmm, I'm going to write some code [10:49] speakman: well, I'd start with a plugin myself, because I could create a new command, tweak it until it does what I want and get some people to try it out [10:49] if its liked, the logic can be yanked out as a patch for bzr itself [10:52] plugin sounds like a good idea. But I've never written anything for bzr(lib), so is there any existing plugin you'd recommend tweaking instead of start a new from scratch? [10:54] uhm [10:54] my plugin-info plugin is nice and small [10:54] you could use that as a template for a plugin [10:55] and grab the code from bzrlib.builtins.cmd_commit as a starting point for your own command [10:56] https://edge.launchpad.net/bzr-plugin-info is the plugin I'm referring to [10:58] spiv_: didn't you do a coverage option for selftest? [11:34] speakman: there's actually a hook to seed the commit message offered to you in the editor [11:34] so you could create a plugin to provide that hook, and then plain "bzr commit" would offer you an editor with that message that you could edit to your liking [11:34] would that suit you? [12:01] I'm sorry for beeing a bit off, but I'm currently at work [12:02] lifeless: I'll definitly check that plugin out! Thanks alot! [12:02] james_w: Sorry for not understanding, but what is "seed the commit message" really? [12:02] and "the editor"? [12:03] oh, the diff and stuff of course. [12:03] when you run "bzr commit" with no "-m" argument you are given an editor window to provide the commit message [12:03] that editor can be "seeded" with a message, but normally isn't [12:03] --with-diff does seed it? [12:03] nope [12:04] that makes changes below the "Everything below this line will be ignored line" [12:04] (i'm not really sure what "seed" really means. I'm no english expert :) ) [12:04] speakman: 'prepare' [12:04] you can also make changes above it [12:04] lifeless: okay! thanks! [12:04] so that if you do nothing and save and quit the message that was "seeded" will be used [12:05] james_w: wow! is there anything that utilize this already? [12:05] bzr-builddeb is the only thing that I know about [12:06] But then again; I have no clue how hooks works in bzrlib, and I'm pretty short of sparetime for a while :( [12:06] http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py [12:06] the "debian_changelog_commit_message" function [12:09] Great thanks! I really hope to contribute more self-going in the feature. People are talking about bzrlib as an example how beatiful Python code could be. I probably have alot of thing to learn when getting me into the bzrlib code. [12:10] moin [12:10] speakman: something like http://paste.ubuntu.com/150747/ [12:10] morning jelmer [12:11] speakman: save that code as ~/.bazaar/plugins/merge_commit.py and give it a test [12:11] speakman: oh, it needs "from bzrlib import msgeditor" at the top [12:12] lifeless: the coverage option is global, not specific to selftest [12:13] james_w: great thanks! I'll try it as soon as my job ends for the day. [12:13] vila: yes I've found it. Its now what I want [12:14] *not* [12:14] ok === `6og is now known as Kamping_Kaiser [12:18] * vila goes back to tweaking pronto.tell_me_what_tests_run_me() === bob2 is now known as Guest77410 === AfC1 is now known as AfC === bob2 is now known as Guest92688 [13:44] lifeless: no, I did a global --coverage option === spiv_ is now known as spiv [13:45] (it was originally just for selftest, but it was simpler to as a global, and potentionally useful too) [13:58] spiv: do you happen to know of code to go from line number in a py file to method ? [14:05] night all, I'll finish this tomorrow I think [14:07] lifeless: possibly the inspect module has something, otherwise I don't know of any off-hand. [14:09] spiv: not needed [14:09] trace has what I wanted, just different params [14:09] lifeless: cool [14:09] at least for this part of my plugin [14:09] I'm generating an index of function -> test [14:10] its a little long to do lineno->test [14:11] anyhoo, will finish tomorrow [14:17] lifeless: you do that for all functions or just on demand [14:21] vila: selftest --index [14:21] vila: then selftest --changes uses the index [14:22] changes since the last --index ? [14:24] since the last commit [14:24] must go, very tired === beuno_ is now known as beuno [14:46] Wanna get your pic on magazine cover??? http://techbuddha.blog.co.in/2009/04/14/wanna-get-your-pic-on-magazine-cover/ -- http://techmaharshi.blogspot.com/ [14:59] "K-lined" : not seen that in a while [14:59] Ha-ha beuno: is there any loggerhead release in the pipeline? [15:02] jelmer, oh, I really do want to make a release [15:02] beuno: including the start-loggerhead -> serve-branches transition? [15:03] jelmer, that's the blocker. No config yet [15:03] beuno: ahh [15:03] beuno, I have a secret plan to re-write large parts of loggerhead. [15:03] beuno: any rough idea on when that would be possible? [15:03] beuno: (one of the alioth maintainers is asking me for a backport) [15:03] jelmer, I could make a release anyway [15:04] beuno: well, I'm mainly interested in doing the backport *after* the changes [15:04] rockstar, I hear that, really looking forward to it [15:04] as they will affect users [15:04] jelmer, after the start -> serve migration? [15:04] beuno: yeah [15:04] jelmer, ok. I have had zero time to work on that :( [15:04] beuno, you heard already? I guess it's not a secret plan then. [15:05] rockstar, well, unless it's something different than the wholehistory and revnocache bits [15:05] beuno: no worries, I was just wondering what the status was on that [15:05] it can be *our* secret [15:05] jelmer, "stalled", but mwhudson and rockstar are working on all kinds of places [15:05] beuno, drastically different. wholehistory is not going to be trivial to remove without ripping out all sorts of things. [15:06] rockstar, oh! interesting [15:07] beuno: ah, thanks [15:08] rockstar: wholehistory? [15:09] jelmer, wholehistory cache is the bane of loggerhead's existence. [15:11] ah, teh cache [15:14] jelmer, I'm almost positive that it's the reason loggerhead leaks memory. === abentley1 is now known as abentley === nevans1 is now known as nevans [17:26] rockstar: well, IIRC when talking with mwh at pycon, we found the problem wasn't strictly the whole-history cache, as much as the 3-4 copies of it [17:27] which is some of the stuff we uncovered with the memory_dump stuff [18:03] whoa [18:04] merge pulls the revisions for the other tree into the this repo [18:07] jelmer: uh? [18:08] if you run "bzr merge" in a subversion working copy (with .svn directories) [18:08] it will push the pending merges into the repository, but that happens to be a remote svn repository [18:09] and revisions are always visible in svn === abentley1 is now known as abentley [19:44] doh [19:45] I imported a git branch to bzr [19:45] and its clearly missing files and whole directories :/ [19:46] cody-somerville: how did you import it? [19:46] jelmer, git fast-export --all | (cd ../.bzr-repo; bzr fast-import - &> /dev/null) [19:47] ok, no clue then [19:48] Is there another way to do it? [19:48] cody-somerville: bzr-git [19:50] Is there a package in Ubuntu with that? [19:52] not yet [19:54] there is an archlinux package however :p [19:54] that doesnt fix all the other reasons for not using archlinux [19:55] lol [19:55] ronny, :P [19:55] ronny, like what? :D [19:55] well, they ship a broken gvim since years [19:56] it'd take you 5 secs to fix it... whats the problem exactly? [19:56] and there have been other incompetence issues - like the package manager doing silent corruption [19:56] pygi: the vim people told them many times, they dont fix [19:56] ronny, o.O [19:57] ronny, could you pm me, so I can do it? [19:57] the main issue is that their custom gvimrc breaks all colorshemes [19:57] (not in official repos tho) [19:58] every few weeks we get a unhappy pida user cause of this, and god knows how many dont even ask [19:59] ronny, I am just looking at the package... [19:59] ronny, it ships with gvimrc_example.vim from vim tarball as gvimrc? [20:01] pygi: last time i brothered /etc/gvimrc or /etc/vim/gvimrc was a custom mess of color hacks in archlinux [20:01] the fix was to just delete it [20:01] rockstar, ok, at least now it doesn't seem to be [20:02] pygi, please watch your tab completion. [20:02] rockstar, ups, I did that yesterday too, no? :D [20:02] ronny* [20:02] well, shortly after that the archlinux package-manager silently corrupted my install and the package db due to absolute ignorance of a filled harddisk [20:03] ronny, right :) [20:04] well, end of the story is - i discourage everyone from using arch [20:04] hehe nice :) [20:05] do I have your forgiveness for using it then? :P [20:05] i just discourage fro using it [20:05] but i might commit hate-crimes against rpm based things === abentley1 is now known as abentley === beuno_ is now known as beuno [21:48] vila: hi [22:01] jelmer, new bzr git requires 1.15? [22:02] w00t? :D [22:03] pygi: yeah, bzr.dev [22:03] meh, so I have to install that too [22:03] so un-cool xD === _thumper_ is now known as thumper === Guest92688 is now known as bob2 [23:26] lifeless: ping [23:55] jelmer: pong [23:57] lifeless, jelmer, hi