=== asak_ is now known as asak [00:19] pickscrape: what format branch are you using ? [00:19] mwhudson: actually, its quite easy to beat that :) [00:23] lifeless: default. Branch format strikes me as being a quite scary thing to mess with (coming from an svn/svk background here). [00:25] pickscrape: What version of bzr are you using? [00:26] 1.1.0 [00:34] pickscrape: bzr info will tell you [00:34] pickscrape: I want to know if it says pack-something [00:35] pickscrape: if it does, pushing over sftp rather than bzr+ssh will likely be much faster, for big pushes., [00:42] jam: ping [00:46] lifeless: Knit repository format 1 [00:47] I was actually using sftp before I tried bzr+ssh. It was running slowly too. [00:47] Pushing locally on the server is going much quicker though (obviously) [00:52] you should upgrade to packs [00:52] _much_ faster === kiko-afk is now known as kiko-zzz [01:42] looking for review: http://bundlebuggy.aaronbentley.com/request/%3C1202953186.6790.187.camel@lifeless-64%3E [01:42] abentley: I have a use case to cherry pick against two branches simultaneously :) [02:25] lifeless: err? [02:35] New bug: #191729 in bzr-svn "Initial svn+http repository not remembered" [Undecided,New] https://launchpad.net/bugs/191729 [02:39] abentley: I have two branches which have pending merge requests on bb; I have a third branch based on both, which I'd like to send in for separate review [02:41] I think the best you can do is merge one into the other and then generate a merge directive against that. [02:42] I'm willing to consider the possibility, however slight, that this is not an ideal workflow for some people. [02:42] ;) [02:42] normally I would stack them that way [02:42] this was unplanned [02:44] I'm not sure whether the notion of cherrypicks can be naturally extended to multiple bases. [02:44] so given A,B ->C [02:45] I want a cherrypick of C to have the unique lines added to C but not added to A or B [02:45] clearly it won't apply cleanly to just A, if I alter what B added in C, and vice verca. [02:47] Yeah, I think I understand what you want. I'm not sure what that would require for patch generation or merge application. [02:55] * igc food [02:55] lifeless: I think the technique used to do cherrypicks with knit and LCA merge could be extended to multiple bases. [03:08] wow [03:08] the vim packaging folk really don't like 'Just Works' [03:08] http://pkg-vim.alioth.debian.org/vim-policy.html/ [03:21] New bug: #191731 in bzr-svn "Memory problems prevent branch of large svn repositories" [Undecided,New] https://launchpad.net/bugs/191731 [03:24] Hi [03:24] someone knows an equivalent to "hg incoming" en bzr? [03:24] in* [03:25] javamaniac: bzr missing. [03:25] javamaniac: It does both incoming and outgoing. See "bzr help missing" for args to only show one of them. [03:25] ok, let's see [03:26] javamaniac: If you're planning to pull, you can also do "bzr pull -v" to pull new csets and list them at the same time. [03:31] Peng, in mercurial , there's a -p to show the patch of those "missing" changesets, I can't see something like that in bzr, How can I achieve that? [03:33] bzr diff branch_path [03:38] bzr diff -r ancestor:branchpath is often more what you want === maw is now known as mw [03:43] n [03:43] Sorry, wrong window :) [04:49] ok, I need to do some more upgrade infrastructure [04:49] tomorrow === asac_ is now known as asac === arcsinx is now known as arctanx [05:44] BzrDir.find_branches seems to eat a lot of memory. (I've noticed this with bzr multi-pull and now the bzr-avahi plugin) [05:50] spiv: I used to have my own version of it in bzr-avahi [05:50] by using code from bzrlib, it is magically someone else's problem [05:50] jamesh: :) [05:50] I should play with heapy or similar and find out where the memory is going. === jrydberg__ is now known as jrydberg [07:47] poolie2, poolie__ : hi. It looks like bzr-1.rc1.tar.gz and bzr-1.2 branch do not match [07:48] i think it was rejected [07:48] i'll check [07:48] i'm trying to fix bug 189915 at the moment [07:48] poolie__: kthks [07:48] Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,Confirmed] https://launchpad.net/bugs/189915 [08:05] poolie__: you may find this site amusing: http://www.freerice.com [08:05] man, that reads like spam [08:06] rice rice baby [08:07] hm [08:08] refined carbs/handouts/banner adds/bizarro wristband campaigns/etc [08:09] 1. hoary means: [08:09] 2. urgent [08:09] 3. singsong [08:09] 4. gruesome [08:09] 5. ancient [08:09] 6. Linux Distribution [08:09] 5 [09:58] Should patches that haven't been merged yet move their NEWS entries out of the 1.2 section? === weigon__ is now known as weigo === weigo is now known as weigon [10:16] hi [10:28] Oh no! I typoed a commit message! :( [10:29] then uncommit :P [10:30] It's a few commits old. [10:30] I never noticed, so perhaps no one else will, eh? [10:31] heh... yep... [10:31] and tyops aer cmmoon [10:33] Yeah. === AnMaster_ is now known as AnMaster [11:21] * mvo_ sends a valentines card to bzr shelve/unshelve for being so nice [11:29] hey folks [11:29] how would I resolve a tag conflict? [11:46] hi [11:53] how do I get a changelog when comparing 2 branches? I want to get a list of changes present in one branch, but not in the other ... [11:55] ignas: bzr issing [11:55] ignas: missing, passing --mine-only or --theirs-only as appropriate [11:55] *missing [11:56] thanks [11:58] but it has no "-d" parameter it seems :/ [11:59] this tags stuff seems so weird ... [12:10] solved [12:30] New bug: #191813 in bzr-webserve "Inventory: Pressing a binary file show binary data" [Undecided,New] https://launchpad.net/bugs/191813 [12:34] ubotu: Don't Do That Then ! :) === kiko-zzz is now known as kiko === mvo__ is now known as mvo === mvo_ is now known as mvo === statik` is now known as statik === mrevell is now known as mrevell-lunch === kiko is now known as kiko-fud === maw is now known as mw [16:15] thanks folks for having created that bzr package for dapper :) === mrevell-lunch is now known as mrevell === kiko-fud is now known as kiko [19:15] New bug: #191917 in bzr "bzr cvsps-import crashes with assertion error" [Undecided,New] https://launchpad.net/bugs/191917 === cr3_ is now known as cr3 === cr3_ is now known as cr3 [20:48] Hi - I'm trying to use bzr-svn for the first time. I'm geting this error: http://pastebin.org/19627 [20:48] What am I doing wrong? [20:49] garyvdm: use "bzr svn-push" if you're trying to create a new branch [20:49] Ok [20:49] Whoops, looks like you're not trying to do that... [20:50] Trying to create a local branch [20:50] Not one on svn :-) [20:50] ~/meld = init-repo --subversion [20:51] then you are trying to create a new branch in subversion [20:51] if you want to make a local copy, use init-repo --rich-root-pack [20:51] Oh - ok [20:51] init-repo --subversion creates a subversion repository [20:52] Thanks - its working now. [21:56] poolie__: hi. I'm not sure if you did the upload to the PPA, but it FTBFS again. [21:56] poolie__: from a quick glance it seems that you need to Build-Depend on python-all instead of python. [21:57] poolie__: also, it seems that you may be using python-support, rather than python-central. If you have changed this then you should be aware that last time I looked the plugins and the core had to use the same system otherwise the plugins weren't registered. [21:57] poolie__: if you already know all of this, or it wasn't you then my apologies. [22:13] morning === zmanuel is now known as z-man [22:41] james_w, thanks, i was aware it had probably failed [22:41] https://bugs.edge.launchpad.net/bzr/+bug/189915 [22:41] Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,In progress] [22:41] lamont says that python-central isn't in dapper [22:42] poolie__: exactly [22:42] there was a patch for dapper by jeff licquia [22:42] is python-support? [22:42] but it was so minimal when I read it that I don't know if it was correct [22:42] you *could* try to build the sarge backport [22:42] there is a patch on that bug from lamont [22:43] so can we switch it to python-support on all distros, or do they need to remain different? [22:44] yeah, you could do that. However all plugins would have to be changed at the same time. [22:44] (all packages of plugins I mean) [22:45] poolie__: are you using the bzr-packaging-teams packaging ? [22:45] I was trying to just uupdate from that [22:45] poolie__: if you extended my packages you are [22:46] but i have tried to use the same packaging across all distros, which is the problem [22:46] do they have different branches for each distro? === poolie__ is now known as poolie [22:46] yes [22:46] distro release rather [22:46] there is an etch-backports branch I think, but it doesn't have the changes you need. [22:46] sid & hardy are the same [22:46] and dapper and etch [22:47] I used the patch from the list to convert the hardy branch down to dapper [22:47] dapper != etch [22:47] dato: hmm, true; I'd actually have to go check my branches [22:47] poolie: point is - yes every distro code name had its own branch [22:48] poolie: where the deps and build stuff was the same I pulled between them, when it wasn't I merged changes. [22:48] personally I think not using nor pycentral nor pysupport would be best for dapper [22:49] too many negatives [22:49] using neither you mean [22:49] ok [22:49] Couldn't it just be built for the default python in dapper? [22:50] james_w: dapper is pre the modern python packaging stuff entirely [22:50] right [22:50] yeah, but I mean just don't even try and support more than one python. [22:50] so you just build it the old way [22:51] and it's much easier than sarge because python points to 2.4 and not 2.3, and docutils is already at 4.x [22:51] 0.4 I mean [23:19] poolie: spiv: ping [23:19] igc: file:///usr/share/doc/python2.4/html/lib/standard-encodings.html [23:20] lifeless: pong [23:20] thanks spiv [23:20] can we talk about the network protocol; I've sent mail but I have to assume there is some confusion reigning [23:21] lifeless: sure [23:21] lifeless: it looks like I was unclear in my mail [23:21] I read 'lets not do X because Y, where Y is unrelated' [23:22] lifeless: by "interruption", I mean interruption by the sender, not the receiver. [23:23] lifeless: i.e. "here's a body... *streams* -- Oops! I just exploded, and am aborting the stream." [23:24] lifeless: it's still all half-duplex. [23:24] spiv: which is precisely why I suggested have the tuple stuff exclusively after the body [23:24] lifeless: but requests have the same issue. [23:24] lifeless: they can also stream bodies, and should have a way to explicitly signal "oops, that's not a complete stream because I just blew up." [23:25] spiv: right, symmetry. do it the same way for both directions. [23:25] lifeless: but requests can't have the body come before the verb, because that would force the server to buffer, because it wouldn't know what the body was for. [23:28] spiv: this is true [23:32] spiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client [23:32] spiv: also the client may well be unable to finish the stream without additional structured data. [23:32] spiv: so perhaps saying entity: [*TUPLE|BYTES)+] [23:34] lifeless: you mean rather a body being just a series of byte chunks, make it optionally more structured? [23:35] no, I mean making the entire message a series of things [23:35] where each thing is either a tuple [23:35] or a bytestream [23:35] That sounds like an over-generalisation to me. [23:36] perhaps [23:36] but you are proposing [23:36] TUPLE [BYTES, TUPLE] [23:36] already [23:36] or something like that [23:36] I'm worried that sort of free-form structure would require more complexity than we need... [23:38] Something like that. Basically it's still ARGS [BODY], with the possibility to abort the BODY. [23:38] which means the body is delimited [23:39] and you wanted to add error details when its aborted [23:39] And so far the ARGS + BODY idiom has fit pretty well with what we've wanted to do. [23:39] which means another ARGS [23:39] :) [23:39] Right, those are some of the details. I'm just saying the protocol still conceptually is directly related to what the code does and expects. [23:40] i can't parse [23:40] spiv: so noting that; the situation is not identical because the server doesn't have state but neither does the client [23:40] [(TUPLE|BYTES)+] basically suggests to me a whole extra layer. [23:40] and i'm not sure how that would map into the api [23:41] at the moment, it is: after getting the header, you can read the bytes, but that [23:41] and each call to do so can either 1-return bytes 2-return eof 3-raise an erro [23:41] r [23:41] this seems reasonable for both client and server [23:41] hm [23:42] i guess i can see how the more general structure would work [23:42] allowing the receiver to say, stream some bytes, now read a tuple, etcr [23:43] I don't seee TUPLE [BYTES[TUPLE]] as being any harder than (TUPLE|BYTES)+ [23:45] i guess we could have messages saying, um [23:45] or message types [23:45] Well, we can always use streamed bodies for complex structured data like that. I don't know that that's a common enough case to make it be the overall protocol. [23:46] start of message, parameters, bytes, error, end of message [23:47] Adding flexibility to the protocol has the downside that now you expect the request handlers and response handlers to be able to cope with that flexibility. *Maybe* we can hide most of that in the default base class for request handlers (although we don't really have such a thing for response handlers), but I'm not sure. [23:48] if we had the messages marked that way, and the receiver knew what they expected, then it could be an error for them to get parameters when they expected bytes [23:48] poolie: we already have "start of message, parameters, bytes, error, end of message", we call them requests ;) [23:51] so i think robert is saying [23:52] why not make that ordering a convention rather than a requirement [23:52] so that the api can possibly send more parameters after the body, or some such [23:52] and i guess it'd be an error if the receiver was not expecting it [23:52] I guess because I'm not sure that we'll actually have a use for this complexity. We can always send bencoded structures (and already do), or multiple requests. [23:53] i share that uncertainty [23:53] And degrees of freedom don't come for free, so my inclination is to say YAGNI. [23:53] here is one case, which has an analog in http [23:54] we want to send the contents of a file, and afterwards send its hash for verification [23:54] the sender wants to compute the hash as it's streaming the file [23:55] it would be possible for it to encode that into the stream, but that seems a bit redundant since the protocol already has markers for the byte steram [23:57] Hmm. [23:57] this is a case where the receiver might reasonably read the stream, then ask to read more parameters [23:59] That's true, but I still wonder how common it really is?