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