[00:16] BasicOSX: So, 1.14 tonight? 8) [00:23] BasicOSX: yes, because whatever is going on is parallelisable fixable between spiv and I [00:23] BasicOSX: waiting on the release for it won't make it get fixed faster, and whatever the issue is 1.13 already has it [00:25] I'm working 1.13.2 and 1.14final in parallel [00:25] jelmer ? [00:41] bug 368932 [00:41] Launchpad bug 368932 in bzr "FAIL: test_no_color (bzrlib.plugins.bzrtools.tests.shelf_tests.ShelfTests)" [Undecided,New] https://launchpad.net/bugs/368932 [00:44] BasicOSX: WARNING Installed Bazaar version 1.13.2 is too old to be used with plugin [00:44] "Bzrtools" 1.14.0. [01:09] lifeless: I said as much in the bug report, justl ooking for confirmation [01:12] BasicOSX: I've marked it invalid already :) [01:21] Just being extra careful ... doing 2 releases is hectic [01:39] BasicOSX: oh sure [02:23] spiv: ping [02:24] lifeless: pong [02:24] how are you going on the ACF stuff [02:24] do you want me to jump in? [02:26] lifeless: so the key problem seems to be distinguishing "ghost" from "missing-but-required" in the sink. [02:26] Or I suppose "will cause ACF errors later" from "won't cause errors". [02:31] ACF? [02:31] absent content factory [02:31] spiv: so the sink has two cases, stacked-without-basis and stacked-with-basis [02:31] spiv: in *both* cases we want to end up with the same behaviour [02:32] thats a likely bug at the moment [02:32] The sink doesn't necessarily know if there is stacking, though. [02:32] right [02:32] stacked-without-basis won't 'know' [02:33] we will have to unwind some of the 'support' in knit.py for stacking to let the sink figure out it needs various inventories, or something along those lines [02:35] spiv: ok, case one, without basis [02:35] we'll see N revisions [02:35] thats what the user *wants* us to have [02:35] we want all adjacent inventories [02:35] inventories that we can't get are either corrupt branch symptoms, or ghosts [02:38] what if you tried to access the branch a remote branch is stacked on ... but the url was only good over there ? [02:39] SamB: stacking is a client side thing, basically [02:39] in the former, we will either be unable to reconstruct some inventories[existing checks should handle this], or we can reconstruct but the union of deltas for inventory will reference texts we can't access [02:39] SamB: I don't understand the question [02:43] so, if we have an inventory parent missing, can reconstruct the inventory, then we can do a delta against all the parents we *did* get, and check that every text added is available locally [02:43] thats basically the logic in find_file_ids_altered again [02:45] Right. [02:45] So basically requiring adjacent parents is too strict. It's sufficient but not necessary. [02:48] Each parent we have cuts down the set of texts that we require. [02:49] We don't even *need* any parents for some inventory so long as we have every text referenced by that inventory. [02:51] right, though every parent we miss is more data we'll send [02:51] Right. [02:52] Ok, I think I know how to rework this. It's a shame it's so complex. [02:54] It'd be nice to have a nice helper object for tracking the set of "key A needs keys X, Y, Z", which I could just feed newly seen keys and their dependencies into... [02:54] ugh, this is weird [02:54] I do bzr add and nothing happens [02:54] bzr status shows the directory I'm trying to add as unknown [02:55] bzr 1.13.1 [02:55] cody-somerville: that does sound odd [02:56] aw, I see why from bzr.log [02:56] cody-somerville: is it ignored [02:56] ? [02:56] no [02:56] nested bzr tree [02:56] mwhudson: "unknown" implies "not ignored" [02:56] oh right, you said that already :) [02:57] removing the .bzr in the directory resolves the issue [02:57] However, its odd that bzr doesn't say something more meaningful than just nothing [02:57] spiv: right [02:58] cody-somerville: file a bug. The nested tree stuff isn't fully mature yet. [02:58] will do [02:58] actually [02:58] its deliberate [02:59] we don't auto-add nested trees or child trees [02:59] there are separate commands for that [02:59] still a bug that no error is given when I specifically try to add it [02:59] In this case, I didn't intend for it to be a nested or child tree [03:00] lifeless: oh? Hmm, I guess I can see that. Sounds like the current UI is confusing enough that we should do something differently, though. [03:01] cody-somerville: 'bzr add tree' will add *in that tree* [03:02] bzr help add doesn't mention that [03:02] lifeless: should say SOMETHING if you explicitly mention one, though [03:03] like "not adding nested tree blah blah blah because blah blah blah" [03:03] or whatever [03:03] cody-somerville: its a bit of a theme in bzr that when you give it a path it acts on the tree the path is in [03:04] SamB: it *never* sees that its a nested tree [03:04] SamB: because its been given the root of a tree [03:04] Thats not quite what .bzr.log suggested [03:04] lifeless: well, it should say that it's not doing anything [03:04] Let me add that to my bug report [03:05] oh wait [03:05] nvm [03:05] SamB: its the same as 'bzr add' isn't it? [03:05] SamB: that already says " [03:05] ignored 702 file(s). [03:05] If you wish to add some of these files, please add them by name. [03:05] " [03:05] oh, wait, why does "bzr add tree" do an add in that tree ... that sounds pretty wierd [03:06] SamB: same reason that 'bzr commit /path/to/tree' commits in that tree [03:06] these commands are too context-dependent :-( === BasicPRO changed the topic of #bzr to: Bazaar version control system | 1.13.2 released 28 April, 2009 | 1.14rc2 released 20 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [03:12] The question is, does 1.13.2 go before or after 1.14rc2 in NEWS? [03:12] And I bet I could find out in about 15 seconds. :P [03:14] Yes :p [03:14] hmm, so should NEWS be a directed graph instead of a linear history ? [03:16] no [03:16] its a flattened traversal of all releases done for convenience [03:16] 'trunk' has never been released [03:19] spiv: so if you're not needing help with acf stuff, I'll keep pushing round trips down [03:19] Trunk is not released. It escapes. [03:21] * SamB steals trunk [03:25] lifeless: sure [03:33] SamB: Now you have to be PQM. :P [03:34] * SamB puts the tags back in and lets trunk escape again === arjenAU2_ is now known as arjenAU [04:08] I have make a local branch of trunk at rev 2376, then I committed with unchange , the revision goes to 2377. After I used *bzr rebase lp:project* , now the revision is 2467, anctually the revision of trunk is 2466 now. When I use *bzr push*, it shows * bzr: ERROR: These branches have diverged. Try using "merge" and then "push".* How should I do now? [04:09] you have to use --force after rebasing [04:10] because rebasing looks to bzr like you have created new unrelated history [04:11] when I pushed the to my branch but not the trunk [04:12] thats right [04:12] if you want to rebase you'll have to --force always [04:12] and some one told me use the *bzr rebase lp:mybranch* to have a try [04:12] because rebase breaks the links that let bzr know what you have done built on something you'd pushed earlier [04:13] you mean I shoud use it like *bzr rebase --force*? [04:13] xiaohui: maybe you just shouldn't use it ;-P [04:14] it IS rather destructive [04:14] have you read what Linus has to say about it? [04:14] you probably should [04:14] Out of curiosity, is it at all likely that when I installed 1.13 over an existing installation recently it either failed to overwrite my installation of bzr-svn or installed the wrong one...or did I probably just accidentally tell it not to include the core plugins? [04:14] no, SamB [04:15] SamB: what the Linus said? [04:15] Kilroo: I would guess you didn't tell it to include the plugins [04:15] xiaohui: 'rebase turns tested code into untested code' -- Linus [04:15] I suspected as much. [04:16] so ,lifeless how should I do now.I have no idea [04:17] xiaohui: use --force when you push, or don't use rebase. [04:19] so use the *bzr rebase lp:trunk*, and *bzr push --force * to my branch [04:19] I see, thank you lifeless [04:24] oh, it doesn't work [04:29] xiaohui: this is what I meant: http://lwn.net/Articles/328438/ [04:29] it took me a while to find it again [04:30] I wonder how I got to it the first time ... [04:31] thanks ,SamB [04:31] there are some more terrible problem *bzr: ERROR: Could not acquire lock "(remote lock)"* [04:33] I use the * bzr break-lock lp-140409033803088:///~xiaohui/opencog/moses/.bzr/branch/lock * and it return the ERROR of *bzr: ERROR: Unsupported protocol for url "lp-140092643935568:///~xiaohui/opencog/moses/.bzr/branch/lock"* [04:35] how to break the remot lock? [04:37] xiaohui: bzr break-lock lp:~xiaohui/opencog/moses [04:40] :), [04:50] ping igc1 [04:52] Sorry Ian - I got to run - I'll send my question in a mail. [05:19] Bug 304883 is fix released, but I do not see it in NEWS or find a log of it [05:19] Launchpad bug 304883 in bzr "Handling of carriage return character across platforms" [High,Fix released] https://launchpad.net/bugs/304883 === BasicPRO is now known as BasicOSX [05:19] but it is tagged 1.14 [05:19] The other 2 bugs tagged for 1.14 have NEWS entries and I find them in the logs [05:22] wow, hadn't heard of it even [05:24] I've PQM'd 1.14 with bug 364900 and bug 358037 to keep the ball rolling [05:24] Launchpad bug 364900 in bzr "pure python Groupcompressor failure" [Critical,Fix committed] https://launchpad.net/bugs/364900 [05:24] Launchpad bug 358037 in bzr "Revision not in bzrlib.groupcompress.GroupCompressVersionedFiles" [Undecided,Fix released] https://launchpad.net/bugs/358037 [05:25] Looks like 358037 was in 1.14rc2, so but result is the same [06:20] lifeless: advise on bug 304883? Wait on it or push 1.14 out the door? [06:20] Launchpad bug 304883 in bzr "Handling of carriage return character across platforms" [High,Fix released] https://launchpad.net/bugs/304883 [06:20] lifeless: or as RM my call? :-) [06:20] your call [06:21] I would get 1.14 out [06:22] brb, getting a coin [06:24] BasicOSX: see also igc's reply to your mail on the list === chandlerc__ is now known as chandlerc === dereine[OFF] is now known as dereine [06:56] later, all, started early this morning [06:56] Is "getting a coin" a slang term I don't know, or did you actually get a small amount of money? [06:56] Peng_: to flip [06:57] Ahhhh. Thanks. :) [06:57] one flips coins to make binary decisions [06:57] Y'know, 1d2 ;) [06:57] Yes, in the rock I've been living under we used a piece of bark. [07:00] Isn't there a virtual coin flip website? [07:00] Who trusts other people's entropy? === dereine is now known as dereine[OFF] [07:04] theres a sshkeygen website [07:05] There is? [07:05] They even encourage you to enter your username and hostname for the comment. It's brilliant. [07:05] Wow. [07:05] The internet has ruined my ability to take minor joy in imagining spectacularly bad ideas :( [07:05] Where does the guy who runs it even get enough entropy? Maybe the website gives out the same keys every time. [07:06] Oh, that's easy. Any amount of entropy automatically contains some unknown multiple of the amount of entropy it contains! [07:06] fullermd: http://www.sshkeygen.com/ <- :) [07:07] Oh! It defaults to 512-bit keys! WTF? [07:08] "upswing isodialuric overbray 92580" is a great suggested passphrase. [07:08] Crap. Now I have to change all my keys... [07:13] hi all [07:14] vila: hi, your ssh fix, is it blocked? [07:16] lifeless: not reviewed so far AFAIK [07:16] vila: is the bug in 1.14? [07:16] as mentioned in the cover letter, no, only in bzr.dev [07:17] but the NEWS file is a bit misleading in that reagard [07:17] regard even [07:22] It works for me... [07:25] fullermd: what ? Changing all your ssh keys ? [07:26] That would be a slightly different definition of 'work' ;) [07:28] fullermd: so, you mean you tested my patch ? [07:28] * fullermd nods at vila. [07:28] fullermd: thanks [07:29] I now get "that's not a branch, wtf are you smoking" instead of "Password: ] bzr+ssh < 0KB 0KB/s |" [07:29] Which actually might be a really good password, come to think of it, but... [07:30] jamesh: docs for gnome-keyring via python, where would I find? [07:40] BasicOSX: Dear RM, how about defining a 1.15 series and a 1.15rc1 milestone so that we can target bugs ? Thanks in advance :) [08:04] lifeless: I don't know if there are specific docs, but the module is gnomekeyring, and the API is almost identical to the C API [08:04] lifeless: with the exception that the async interfaces have not been wrapped [08:08] argh [08:08] I want a place to store a aws key id and secret key [08:13] jamesh: but no async api means blocking the ui, doesn't it ? [08:13] lifeless: yes. [08:14] sadness [08:14] but it is usually pretty quick ... [08:14] is it trivial to wrap the async interface and simply laziness, or are there complications [08:14] provided it doesn't ask the user for authorisation before returning the data [08:15] jamesh: given I don't want to depend on something as complex to rebuild as pygnome, for now I'll used sync apis [08:15] wrapping the async interface involves lots of callback wrappers, so it probably is laziness [08:15] you've seen my ec2 client? [08:16] lifeless: nope. How does it differ to pyboto? [08:16] python-boto, that is. [08:16] jamesh: two ways, its a gui, and its async [08:16] lp:txaws [08:17] it'd be really nice if twisted.defer was part of the Python standard library [08:17] I mean twisted.internet.defer [08:17] yes [08:17] someone should propose it [08:17] I hear people can commit stuff to python [08:17] then it wouldn't be controversial to wrap async APIs like gnome-keyring using deferred objects [08:18] jamesh: I wrote this because I spent 50% more than our monthly cap developing the bzr ec2 test support [08:18] jamesh: and I didn't want to accidentally leave an instance running overnight ;) [08:19] you could just set up a cron job to kill all ec2 instances on the hour. [08:19] kindof expensive [08:19] and nowhere near as useful [08:19] that'd also encourage test suites to take less than an hour to execute [08:19] bzr's is < 2 minutes if you throw enough instances at it :) [08:19] so its lp's [08:19] s/its/is/ [08:23] having an easy API for deferred objects in C would also help [08:24] even if it is just a bunch of PyObject_CallMethod() wrappers [08:26] agreed [08:26] I have one I'm piecing together in libvfs [08:50] igc1: btw, you need to enlarge your 'open data format' stuff a _lot_ - last I read it it looked like handwaving : 'we' have spent a lot of time considering extension points for the core store and not found any that were satisfactory in the general case [08:51] igc1: [and a general mechanism is by definition the general case] [08:52] lifeless: Can you point me to mailing list discussions that I ought to read/re-read? === igc1 is now known as igc === bob2_ is now known as bob2 === bob2 is now known as Guest49921 [08:53] igc: versioned properties discussions right from the start basically [08:54] igc: various challenges exist - consistency, updating, schema, validation, check, reconcile, propogation, merge, [08:54] indexing [08:55] and performance === Guest49921 is now known as bob2 [08:56] igc: more broadly, one needs to consider how things will degrade for clients not supporting $extension, and if the answer is 'they do the wrong thing', then a repo with that extended data in it is broken for clients [08:56] which is arguably identical to our current behaviour [08:57] In general terms, I think the question is about 'is it possible' not 'how to make it happen', for a safe extensible format [08:58] lifeless: it's software - anything is possible :-) :-) [08:59] lifeless: seriously, I like your list [08:59] lifeless: I don't expect the core to solve every problem for every type of data [09:00] lifeless: I do expect it to provide plumbing where it can and delegate things it can't to the plugin/code registering the extended data [09:00] I'd be delighted to make sure fetch calls hooks to let people add data and recieve extended data [09:01] lifeless: there will be limitations but I don't believe that means we should throw the baby out with the bathwater and say "it can't be done" [09:01] I'm not at all sure that the _storage_ of said data should be in .bzr/repository [09:03] igc: I think there is a different between an extensible store, and hooks allowing plugins to do what they want to alongside core operations [09:04] igc: I argue that there isn't a difference at the user level, but there is a vast difference for the programming and performance implications we face [09:05] we consider very carefully where *our* data goes and what it implies; is it a column store or row store, how long does it take to do X, or Y. [09:06] someone storing a mime type per file could easily add 50% to the raw storage size of inventories [09:06] and writing a general purpose, high performance, tuning-free, self-maintaining database, while extremely interesting, isn't really what we're here to do [09:06] IMO [09:07] I hope I'm making sense [09:07] lifeless: you are and I agree with most of what you're saying [09:08] lifeless: but ewe need a better answer than "new format required" when code/a plugin wants a small amount of data managed for it [09:09] igc: I think plugins should maintain their own stores [09:09] lifeless: it one thing to say "one format only during the life of 2.0" [09:09] in db terms they should get their own shard, and do what they want with it [09:10] lifeless: it implies though that only people running the development format get to see any data-dependent new features until 3.0 is released [09:11] it comes back to definitions [09:11] I don't think replacing format with 'schema version' makes things better [09:11] lifeless: which, IMO, means 3.0 is back to "big bang" releasing with lower quality (as a rule) [09:12] if something is -truely- safe to add to the data existing code processes it can be added to an existing format with todays mechanisms [09:13] I think we're trying to cross the chasm at the moment [09:13] and fast incremental releases are giving our non early adopters problems [09:13] lifeless: but we seem to do that extremely rarely because format bumps are our only instrument for code-data alignment protection [09:14] lifeless: I think branch dpeendency rules will help here [09:14] we'll be having a sprint [09:16] I am not against achieving safe finer granularity; I'm against making the system more fragile, [09:16] and I think that adding more stores is a better approach than a single 'extensible' store, for a number of reasons [09:16] those above [09:17] plus separation of core and non core data [09:17] see for instance the long desired 'file graph is a cache' one [09:17] I like the multiple stores approach - it's what I was getting at with the baggage idea [09:17] bzr-search is an example of this [09:18] living breathing working without needing changes to bzr itself [09:18] lifeless: right, so we need the rules on how to do that better documented and explained [09:19] sure [09:19] lifeless: I need to head to dinner [09:19] And a lot more hooks, sounds like. [09:19] I'll copy-and-paste this conversation into the spec so it doesn't get lost [09:20] I sure [09:20] what else [09:20] oh, right - I disagree with one format, no schema changes implying big-bang [09:20] it just means we have more time spent stewing it in beta [09:21] and we should allow for that [09:24] * igc dinner === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.13.2 released 28 April, 2009 | 1.14 released 29 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [09:56] Yay! [09:56] * fullermd watches the tarball trickle in from LP at 27 kBps. [10:04] BasicOSX: Congrats on the release. :) [10:04] ty [10:05] BasicOSX: yes, congrats and thanks! [10:05] BasicOSX: woo hoo! [10:06] now the scary part, merge back to trunk [10:07] I need some assistance, "You should also merge (not pull) the release branch into lp:~bzr/bzr/current, so that branch contains the current released code at any time." [10:07] I keep getting "Transport operation not possible: readonly transport " [10:08] Can someone tell me the command I should be using? Or can verify I still have write access to that branch? [10:11] BasicOSX: anyone in the ~bzr team should be able to, I think... [10:12] BasicOSX: and you are, so that's a bit odd. You have a checkout or branch of lp:~bzr/bzr/current that you're trying to merge into, and then getting that error when you push/commit that? [10:12] yes [10:13] Maybe you haven't do "bzr launchpad-login tanner"? Seems a bit unlikely though... [10:14] re-trying using 1.14/bzr vs bzr.dev/bzr [10:15] I doubt that'll make a difference (I certainly hope it doesn't!) [10:15] 4:15am, I'm desperate :-) [10:15] Which transport / URL is that error about? [10:16] lp:~bzr/bzr/current [10:16] I'm going http now [10:16] for branch [10:16] That's an alias, not a URL, technically... [10:16] oh, ok, umm, https+urllib://code.launchpad.net/%7Ebzr/bzr/current/ [10:16] It translates to either http://... or bzr+ssh://... depending on if you did lp-login or not. [10:17] Ah, right, so you *haven't* done "bzr launchpad-login" then. [10:17] I tried to branch with lp, got dreaded AbsentContentFactory [10:17] I'm branching via http now, will do login and push next [10:17] It doesn't matter how you branch (do whatever works), it's how you push that I'm interested in. [10:18] I'd like to branch via lp: seems faster, but routinely fails on most branches on lp [10:18] Pretty much any stacked branch that has a merge, yeah :( [10:19] Now that 1.13.2 is out that should be less of a problem. [10:19] I blame the Republicans [10:22] hmph, branch segfaulted! [10:22] BasicOSX: Use nosmart+lp: to still use bzr+ssh, but avoid AbsentContentFactory. (It uses the VFS, so it's basically equivalent to sftp.) [10:23] nice, I'll note that [10:28] Peng_: oh, does the nosmart+ prefix survive the translation from lp: to bzr+ssh: ? That's handy. [10:29] it worked for me, xfer much faster, still taked long time for inserts :-) [10:30] spiv: Surprising, huh? I only found out yesterday. [10:33] bah [10:33] bzr branch nosmart+lp:~bzr/bzr/current [10:33] bzr: ERROR: Revision {[('john@arbash-meinel.com-20050711051006-2d11704675600e95',)]} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()), )". [10:35] I thiiink that's a known bug? Like when you branch --stacked either into a shared repo or a standalone repo? [10:36] standalone [10:36] going back to http [10:36] BasicOSX: that's with bzr.dev? [10:36] yes [10:37] BasicOSX: ok, known bug, introduced in r4307 [10:37] (bug 368418) [10:37] Launchpad bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] https://launchpad.net/bugs/368418 [10:38] Which you should recognise, because you reported it ;) [10:38] BasicOSX: This is random, but thanks for being the release manager. You've been doing a good job, and you've helped improve the release process for every future RM. [10:38] I'm working on it right now. I think I have a functioning fix, just crossing the "t"s and dotting the "i"s. [10:39] (I certainly have a branch that works with the ghosts in bzr.dev) [10:44] (Not sure why it's taking so long for you to branch though... don't you have a shared repo?) [10:44] I always do standalone [10:45] most of my work is done in a pbuilder chroot, so pristine enviro [10:45] Oh, that's a shame. Perhaps prime it from a more local branch to save time? [10:47] I read releasing doc as pull from LP each time, but that might have been my noob eyes first time I read it and dumb brain for not re-thinking it [10:48] Yeah, that sounds like something that wastes a fair bit of time for not much gain. [10:48] BasicOSX: Fresh 1.14 RPMs for bzr and bzrtools: http://fourkitchens.com/blog/2009/04/29/bazaar-114-rpms-rhel-5-centos-5 [10:49] not sure I wanna pollute my ubuntu system with rpms :-P [10:49] BasicOSX: They're not for Ubuntu ;-) [10:52] BasicOSX: Any objection to linking to my RPMs from the official download page? [10:52] I see someone found the 1.15rc1 milestone [10:53] davidstrauss: not really my call [10:54] It is a wiki tho, so I'm sure the powers that grant edit access could let you maintain your own section [10:58] davidstrauss: I'm pretty much done for the day, but if all else fails mail the list to let people know about them. [12:00] jelmer_: hello, did you get my email? [12:10] yo [12:10] is there any specific reason why bzr < 1.14 doesnt seem to be installable via easy_install? [12:32] lifeless: can you guys make it possible to easy-install older versions of bzr, too? [14:09] jam, lifeless, vi, ping? [14:09] vila even [14:10] bzr just dies with a traceback [14:10] and it's still streaming content [14:30] beuno: what's up? [14:31] (I'm not 100% here, but I can try to help) [14:31] jam, hi [14:31] still feeling sick? [14:31] beuno: yeah [14:31] mostly a bad cough [14:31] :/ [14:31] well, I already killed the process [14:31] but, bug 369242 [14:31] Launchpad bug 369242 in bzr "bzr keeps streaming content after crashing" [Undecided,New] https://launchpad.net/bugs/369242 [14:31] never happened to me [14:31] so I wasn't sure how to best debug it [14:32] beuno: so it sounds like the *local* client is dying, but it isn't killing the ssh process, and the remote server is stil sending data [14:32] however, I would be surprised if the local ssh client would buffer forever [14:32] right, I waited for 5-10 minutes, and it was still chewing up all my bw [14:33] maybe it would of died at some point, but it seemed excesive [14:35] well, 5-10 minutes of your whole bandwidth seems like a lot of data to me [14:35] I have to wonder where it all went [14:36] I was wondering as well :) [14:36] so.. you have "after crashing" [14:36] does that mean the bzr process was dead? [14:36] yes [14:36] or just gave a traceback, but was still running? [14:36] traceback [14:36] because after that you say "bzr streaming content" [14:36] and I think the process was ssh [14:37] may be the wrong wording [14:38] jam, either way, bug reported, can be followed up at any time [14:38] wanted to see if someone was interested in debugging it "live" [14:38] go back to resting :) [14:38] thanks [15:58] this is odd, trying to easy_install bzr 1.14 in jaunty and getting a problem with not being able to find zlib.h [16:06] jelmer: i think you manage the download files for bzr-svn in too many locations... out of sync ;) [16:14] does bzr 1.14 work ok on py2.6 or is it still not officially supported? [16:14] rocky, I think it does just fine? I'm using jaunty with 2.6 with no problems [16:18] Hi - I've just installed bzr, and am having trouble checking out through a http proxy. I have tried ; export http_proxy=www-proxy.:8080 ; bzr checkout . I'm getting connection refused. Can anyone help === beuno_ is now known as beuno [16:18] ? [16:24] jim6: http_proxy=http://ww-proxy.:8080 [16:24] s/ww/www/ [16:24]