[01:34] Hi all. Hope someone can help me here. I upgraded my box, and now I'm having trouble deploying. When I run "bzr revno http://mydomain/myrepos" I get a transport error [01:34] specifically: bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) [01:38] nevermind--this is a capistrano error [03:04] spiv: hai [03:07] Okay, if a merged merge proposal didn't fix an issue, do I submit a new one or just update the existing merge proposal? [03:07] new one [03:07] reference the old if discussion in it is still relevant [03:08] lifeless: Okay, thanks. [03:10] I have a pending merge; I've bzr reverted a file because i needed to temporarily get rid of it. Is there a way to now fetch that file again from the other branch without checking in beforehand? [03:11] awmcclain: yesish [03:11] oh, i like ish. [03:11] awmcclain: first, a note - if you want to temporarily get rid of things like that, use 'shelve' [03:11] lifeless: hey [03:11] e.g. bzr shelve filename --all [03:11] lifeless: Interesting. Even on a pending merge? [03:11] awmcclain: if the file on the other branch wasn't changed in your current branch, you can do 'bzr revert -r branch:pathtootherbranch filename' [03:12] lifeless: That's correct. The file is a new file. [03:12] Introduced by the merge [03:12] awmcclain: if it *was* changed in your branch, you can't trivially get the merge back, but donig the revert above and then looking at the diff would let you figure things out [03:12] No, it wasn't changed. Just added. Ok. Great! Thanks [03:12] awmcclain: yes; shelve filename == revert filename, except you can get it back more easily. [03:13] good to know! [03:13] awmcclain: where shelve != revert, is when you just do 'bzr revert', because that discards the pendnig merge. [03:13] Didn't shelve use to be a plugin? [03:13] awmcclain: yes [03:13] And now is part of bzr? [03:13] yes [03:13] Wonderful. Thank you! [03:14] spiv: fud ? early avo perhaps ? [03:15] Hmm, could work. Here or there? [03:15] lifeless: That revert command worked perfectly. Thank you [03:15] spiv: sure [03:16] spiv: mt colah's food facilities are, uhm, limited ;) [03:16] awmcclain: my pleasure [03:17] lifeless: ok, so Hornsby somewhere. Maybe name a time to meet at the fountain? [03:18] spiv: looking @ train timetables [03:19] dear chityrail, your website is terrible [03:20] 1:30 ? [03:20] Sounds good! [03:59] james_w: patch done [04:09] spiv: omw [04:09] be there in 10-15 [04:10] mwhudson: https://code.edge.launchpad.net/~mkanat/loggerhead/synchronize-lru_cache/+merge/24651 [06:44] spiv: do you need a review on that patch? [06:45] Oh yeah. Just a sec. [06:46] lifeless: [06:52] speaking of cameras [06:52] http://gizmodo.com/5529710/59-fiercely-focus-stacked-photos [06:56] Cute! [06:59] spiv: reviewed. [06:59] I wants tweak. [07:03] lifeless: ok [07:05] you may find (I hope not) that when you add the all_revision_ids call (and presumably one after or something :P) that it breaks. [07:05] spiv: I didn't say this in the review, but hopefully its obvious, that you'll want a commit already present, so actual data merging happens. [07:06] Fair enough. [07:07] I did consider constructing a more evil test where I make stream sink and source, and then arrange for refresh_data (and the concurrent fetch) to be done part-way through inserting the stream. [07:08] But the effort involved didn't seem justified. [07:08] I don't expect that to be interesting [07:08] because the disk atomicity is well established [07:09] and the various bits are pretty well established [07:09] but still - nice thinking ;) [07:10] Right :) [07:37] hi all [07:43] yo vila! [07:47] I get an error when trying to use bzr-git to branch the git repository found on here: http://sourceforge.net/projects/unison/develop [07:47] On that page, the git repo url is "git://unison.git.sourceforge.net/gitroot/unison/unison" [07:47] The command I try is "bzr branch git://unison.git.sourceforge.net/gitroot/unison/unison" [07:48] The error I get is "bzr: ERROR: exceptions.TypeError: expected string or buffer" [07:48] kizzo: file a bug at bugs.launchpad.net/bzr-git [07:48] kizzo: you need a newer version of bzr-git [07:48] [ there is more to the error message, but it just explains that it's an internal error, and how to file a bug. [07:48] kizzo: urllib's behaviour changed in a minor python release and broke bzr-git [07:49] Alrighty, I'll try and update things. [07:53] Hmm, I don't know how I would update that though - I ran aptitude update and aptitude safe-upgrade on my Ubuntu Lucid, but I'm already up to date. [07:58] I guess I'm going to have to grab the latest tarball from the main bzr-git site. [07:58] jelmer: what version fixes it ? [07:59] IIRC 0.5.0 [07:59] I'm not sure - the latest is 0.5.0, and the one installed on my system is 0.4.3 [08:00] jelmer: I suggest you put a SRU for bzr-git together _asap_ then. [08:00] Should I uninstall my version first, before doing "python setup.py install" for the new version? [08:00] kizzo: grab the deb package for bzr-git from debian [08:03] lifeless: I double-clicked the deb file to install it, but it says error: Error: Dependency is not satisfiable: python-dulwich (>= 0.5.0~) [08:03] Boo. [08:04] kizzo: that one too :P [08:04] Yeah I started figuring - dang. [08:09] Things are working now, thanks. [08:09] The command works now. [08:09] lifeless: I won't have time for that before UDS unfortunately. [08:10] jelmer: its actually pretty straight forward to start one - are you positive you don't have time ? [08:11] jelmer: how big is 0.4.3->0.5.0; is grabbing all of it feasible ? [08:13] lifeless: it's probably too big for a SRU [08:13] jelmer: is a backport of that fix feasible ? [08:14] lifeless: it's feasible, but nontrivial. The last SRU I did took me an hour or two that I don't have right now (on leave during the last days of the week). [08:14] sure [08:14] do you remember the bug number of the original report ? or a good search string ? [08:15] actually, bug 556968 is it [08:15] Launchpad bug 556968 in bzr-git "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository" [Undecided,Confirmed] https://launchpad.net/bugs/556968 [08:19] Should I post my solution there? [08:20] no, I'll note that down. [08:20] Just to mention what I did to fix it. [08:20] Alrighty. [08:21] spiv: nb: bzr-git(ubuntu) bugs may not be visible to jelmer - you probably want to 'affects project' on them [08:21] spiv: I refer to https://bugs.edge.launchpad.net/ubuntu/+source/bzr-git/+bug/532192 [08:21] Launchpad bug 532192 in bzr-git "bzr crashed with TypeError in open()" [Undecided,New] [08:22] lifeless: ah right. [08:22] (which I've just done) [08:22] I don't tend to look to closely at if a bug is filed on distro. vs. upstream [08:22] indeed [08:22] [me neither, not explicitly anyhow] [08:45] Hmm, it's unfortunate that a test that does "tree = self.make_branch_and_tree('foo'); tree.commit('blah')" can't simply have self.make_branch_and_memory_tree substituted without adding a few lines of boilerplate. [08:46] spiv: agreed === oubiwann is now known as oubiwann_ [09:26] lifeless: can you think of any decent reason why I can't use bzrlib from jython? [09:27] import bzrlib just worked [09:27] mtaylor: someone is working on it. [09:28] mtaylor: file bugs. [09:28] lifeless: oh neat [09:28] heya [09:28] lifeless: as in "just try to use it normally and file bugs" or - go find the jython-bzr project and file bugs there? [09:28] mtaylor: file them on bzr itself [09:28] cool [09:29] now - to solve jython maven integration... [09:30] hi bialix [09:34] vila: ping [09:34] bialix: pong [09:34] bonjour vila [09:34] I'm not quite understand your review [09:34] bialix: which part ? [09:34] For all *files* you check that the *directory* is not a branch. <-- what do you mean? [09:35] and I don't understand this: The correct way to do this would be to prune the directory and *all* of its content when it's first processed. [09:35] at all [09:35] bialix: if you have a nested branch with thousands of files, they are all included in the list you're processing [09:35] vila: no [09:35] this is not correct [09:36] bialix: you rely on tree.extras() right ? [09:36] only the directory with the branch will be in the list [09:36] bialix: no [09:36] at least I don't think so reading the code [09:36] vila: I'm relying on what clean-tree do before [09:37] tree.extras() filters out all the files present in the inventory but walks the whole tree [09:37] bialix: I didn't say you didn't :) [09:38] vila: http://pastebin.com/WHDxuCc9 [09:38] there is no entries from nested branch [09:39] bialix: re-read my review, I'm not saying your code is incorrect, [09:39] vila: I don't see any reliable way to filter out files, other than using isdir() check [09:39] I say it will process too much [09:39] it will process the list twice [09:39] bialix: once you know a dir is a branch, you don't need to even look at the dir content [09:40] because actual delete code also checks for file/dir [09:40] vila: there is no dir content in the deletables list [09:40] only dir itself [09:41] bialix: ??? you mean if you have '.' you don't have './foo' ? [09:41] http://pastebin.com/1SHdFxaW [09:41] I mean if I have foo, I won't have foo/bar [09:43] bialix: even in deletables ? [09:46] in my understanding bzr won't recurse into ignored/unknown [09:47] bialix: ! [09:47] ? [09:47] bialix: you're right ! [09:48] ok [09:49] bialix: sorry for the noise :) [09:49] bialix: may be worth a comment :) [09:50] bialix: ' bzr won't recurse into ignored/unknown' captures this right [09:51] okay, will do [09:52] * bialix updating the patch based on the review of vila and partm [09:52] vila: what should I do for backporting the patch to 2.1 once it will be approved? [09:52] who is in charge? [09:53] bialix: there's no-one specifically in charge [09:53] bialix: simplest is probably for you to make the backport and propose it for merging. [09:53] so I just will need to file a mp against 2.1, that's all? [09:53] ok [09:53] Right. [09:54] vila: ok, so there is still a problem [09:55] if foo is unversioned, and foo/bzr is a branch then we happily remove it [09:55] foo/bar [09:55] (something strange in the fact that both a and z are so close on the keyboard) [09:56] but I don't think we want to handle this due the performance as you say [09:56] bialix: it would have been better to start by targeting 2.1, releases branches are regularly (handwaving) merged into trunk [09:57] I can rebase, perhaps [09:57] bialix: urgh :) [09:57] :-) [09:57] bialix: kidding, yes, now, rebase is probably the easiest [09:58] but I don't mind just cherrypick patch to 2.1 [09:58] I just cherrypick in that situation. [09:59] bialix: regarding branches 'hidden' below ignored or unversioned, a FIXME would be welcomed as well [09:59] vila: http://pastebin.com/rg9h5F1k [10:00] ? [10:00] bialix: won't skip is unclear, 'we will delete the nested branch' is more explicit [10:01] http://pastebin.com/B3RhHxgh [10:02] vila: should I add note about skipped bzrdirs as partm suggested? [10:02] sorry, parthm [10:05] bialix: well, the second reviewer may have a different opinion but I'll land this proposal and make a new one for that instead... [10:06] bialix: except if it's really trivial to add [10:06] Hi all [10:06] hey GaryvdM ! [10:06] I'm looking at https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537 [10:06] GaryvdM: great [10:06] vila: the problem in the correct wording [10:07] Is there a guide anywhere to runing the test suit under wine? [10:07] *is [10:07] GaryvdM: heya! [10:07] Hi bialix [10:07] Hi vila [10:07] bialix: start with Martin's suggestion (was it bzr control component ?), that can be refined later or even tweaked based on the second review [10:18] I've tested it manuall and I don't like how it mingle with the list of paths to delete [10:20] lp is rwad-only, does it means I can't push my branch? [10:20] lp is read-only, does it means I can't push my branch? [10:23] bialix: yes [10:26] Seem like we can't pull either [10:29] * GaryvdM is running "wine c:\\python26\\python bzr selftest" :-) [10:30] * bialix hopse GaryvdM has very fast hardware, otherwise he can go for lunch and maybe dinner [10:30] ah - with -s bzrlib.tests.test_diff [10:34] Good morning. I recently upgraded to Ubuntu Karmic and bzr 2.0.2. Unfortunately our repository server is stuck on Hardy / bzr 1.3.1. I know find branching and status hellaciously slow. [10:34] apt-get? [10:36] funkyweasel: Are you running a bzr smart server on the Hardy server? [10:36] We're not able to upgrade the repo server at this time. Is it a known issue that newer versions of bzr have difficulty with branches generated by older versions of bzr? [10:37] GaryvdM: No. But it sounds like a good idea when we move the repo server to the new Ubuntu LTS. [10:38] funkyweasel: Please tell us what repo formats the branch on the server is, and the branch on your pc is. [10:39] funkyweasel: bzr info -v [10:41] GaryvdM: repo: Packs containing knits without subtree support, local: Knit repository format 1. Noted that it took about a minute to count the revisions on local. [10:42] funkyweasel: you have old format in local tree [10:42] `bzr upgrade --pack-0.92` on local [10:42] bialax: Yes, I thought that too. But if I upgrade using 2.0.2 it becomes incompatible with the repo server. I can no longer commit. [10:43] funkyweasel: I've wrote format1 plugin that force pack-0.92 as default [10:43] Now that I have not tried. [10:43] funkyweasel: upgrade --pack-0.92 [10:43] there is explicitly defined the format [10:43] you have to avoid upgrade to anything newer than --pack-0.92 [10:44] or --rich-root-pack [10:45] funkyweasel: -bialix: Please will you do me a favor: Please run bzr selftest -s bzrlib.tests.test_diff.TestEncodedDiffFromTool in this branch: lp:~vila/bzr/523746-difftool-file-names [10:45] funkyweasel: Sorry last msg not for you [10:45] bialix: I get this error in wine: http://paste.ubuntu.com/427530/ [10:46] GaryvdM: codehosting is offline [10:46] bialix: oh forgot that. [10:46] bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10061, 'Connection refused') [10:47] bialix: I'm not sure if it's wine specific [10:47] once lp going back online, ping me [10:47] bialix: thanks. [10:48] vila: any idea how to fik http://paste.ubuntu.com/427530/ ? [10:48] *fix [10:48] GaryvdM: let me check, but from memory the last commit in my branch was trying a different approach and didn't pass tests as I wanted some feedback first [10:49] vila: Tests work in ubuntu, but not wine. [10:50] oh, failure while *reporting* the failure, different bug, not sure this branch includes the related fix [10:52] GaryvdM: Hmm, I was thinking about reno 5163 on bzr.dev but the fix seems to be present :-/ [10:53] vila: Ok - If don't know - let me debug a little [10:59] launchpad code hosting back up [11:06] hello [11:08] anddam: hi [11:08] I'm trying to figure out the difference between checkout and branch [11:08] I read "Core concepts" [11:10] http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html#centralized says "They run bzr update to get their checkout up-to-date, then bzr commit" but step 1 is checkout [11:10] is it done only once? [11:10] anddam: checkout are similar to traditional svn checkout [11:10] ok I'm fine with that [11:11] a branch is a "ordered series of revisions", how does that make any difference? [11:11] anddam: when you commit to a checkout, it is committed to the place from where you checked out. branch commit is local. [11:11] so "branch" is like "my own branch" [11:12] yes. branch is your own. checkout is more like central ... with the place from which you checkout being the center. [11:12] while a commit to a checked out working dir would write on main development repository (or wherever the working dir has been checked out from) [11:12] thanks [11:12] yes. [11:13] with checkout you also have the --lightweight option which is very close to svn/cvs [11:13] with a branch you will need to either push, or merge into trunk/mainline. checkout commit goes to mainline by default. [11:14] "bzr help checkouts" [11:17] GaryvdM: I've ran the test; he same error here [11:17] GaryvdM: I've ran the test; the same error here === kgoetz is now known as Kamping_Kaiser [11:22] lifeless: can you think of any decent reason why I can't use bzrlib from jython? <- see https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html [11:23] now I'm off out. [11:25] bialix: thanks. [11:26] hi a212901390231901 Ж-) [11:26] hi a212901390231901 :-) [11:27] that makes a pretty good monster smilie [11:28] I'd say it was insects smilie [11:28] in russian [11:28] bialax: This upgrade is taking an extremely long time. [11:29] poor lp, it seems to be very heavy loaded [11:29] funkyweasel: maybe you have a very big history? [11:29] bialax: I do. But bzr 1.3.1 seemed to cope with it much better. [11:29] it's caught up with bzr.dev but not my branch for review yet [11:30] sometimes it's much easier just to get the new branch from the server, because it seems you have it in decent format there? [11:30] Oh. [11:31] It's spent a while 'checking repository format' [11:31] what? [11:31] That's the stage the upgrade is on. [11:31] do you have local branch, not a checkout? [11:32] bialix, just to clarify on your ctypes-users question, cdll['foo'] code calls getattr which forwards to the same method that cdll.foo uses [11:32] and now I really have to go. [11:32] ok [11:33] bialix: I branched from the local copy and set it upgrading to --pack-0.92 with the intention of then pushing it to the repo server, and binding to that version on the repo server. [11:33] funkyweasel: how many revisions/files in the branch? [11:33] In the vague hope I'll get back the old performance I had a week ago on my hardy/bzr1.3.1 box [11:34] Sadly it's 3976 revisions. It's an old tree. [11:34] it's not very big, I think [11:35] can you look into .bzr.log and see what it doing actually? [11:35] I'm quite frustrated at how the performance has plumeted since upgrade. [11:35] vila: ^ [11:36] any hints? [11:37] bialax: Ah, xxxx.yyy opening working tree '{branch path}' [11:38] xxxx is 3058, yyy is 536, both increasing rapidly. [11:38] I noticed that it seems to go really quick except for the last 900 or so revisions. [11:38] xxxx.yyy is the timestamp [11:39] Not revision number? [11:39] it seems there is multiple opening of working tree. strange. bug? [11:39] bialix: I don't know. Is 2.0.2 buggy then? [11:40] Saddening. [11:40] bzr has revno either NNN or NN.B.K [11:40] there is 2.0.5 released [11:40] It's really impacting my work flow. [11:40] can you upgrade from bzr PPA? [11:40] I don't know. Can I? [11:41] http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu [11:41] At the risk of sounding horribly plaintive - I'd rather like it to work like it used to please. But progress, I imagine... [11:41] I'm on the latest for Karmic, my current distro on local box. [11:42] * bialix is not Ubuntu expert, sorry [11:42] It's taken me nearly all morning to try and get a new branch. This is highly inefficient. [11:43] And this checking process is consuming 100%. Which is also nice. [11:43] upgrade is one time operation [11:44] bialax: True. And it's typically worth it. [11:44] It's odd how repo versions have broken between 1.3.1 and 2.0.2 though. [11:45] I can't comment this [11:45] 1.9 format is very nice [11:46] The latest one is that? [11:47] the latest format is 2a [11:48] No - 2a is the latest format, but it is a rich root format, and so you wont be able to push from a 2a format to the format on your server [11:48] Nice one. [11:49] I think a lot of our problems will be solved once we push our repo server up to the latest Ubuntu LTS and upgrading the branches there. Trick is 1. waiting for the LTS to be post-launch stable and 2. finding time to upgrade our repo server. [11:51] funkyweasel: are you upgrading standalone branch or branch in the sahred repo? [11:52] bialix: Made a local dev branch from the local trunk branch. Upgrading the local dev branch. Which is why I am surprised it's taking so long. [12:00] It's now taken over an hour on this upgrade. Is this normal? === mrevell is now known as mrevell-lunch [12:05] funkyweasel: Are doing "bzr upgrade --pack-0.92" - Is this normal > think so. It's a one time operation. Go get lunch :-) [12:07] GaryvdM: Cheers man, and that's an excellent plan. Unfortunately I have a script that does a mailout that needs to go out as soon as possible - it was due first thing this morning but the format was broken so we've delayed it til it can be fixed. So... spending all morning trying to make bzr work at the speeds it used to has consumed the morning, pretty much. [12:09] funkyweasel: Sorry man [12:10] No worries. I should have known this would take a while and put up with the now-ball-crunching slowness of bzr2.0.2 on pre-RichRoot repos. [12:10] funkyweasel: If you want to stop it, it upgrade creates a backup which you can restor. [12:10] *restore [12:11] The outer thing you can try: [12:11] GaryvdM: True, but it's been going for so long that I don't want to quit it. I've started working on the local copy of thetrunk so I can actually get something out soon. [12:11] mkdir temp [12:11] * GaryvdM rather puts this into paste bin [12:11] funkyweasel: may I ask to send your notes to bzr ML about your experience when it finished? [12:12] feedback ftw [12:13] funkyweasel: You can try this: http://paste.ubuntu.com/ [12:14] bialix: Please check that for me ^ [12:14] GaryvdM: do you want me to pasteyou what? [12:15] Oh - sorry. This: http://paste.ubuntu.com/427580/ [12:15] This will, rather than upgrade the local copy, just refetch from the server, in the same format as the server. [12:16] funkyweasel: ^ [12:16] bialix: Sure thing. Will filter out lightly-stressed incuded btching on my part. :) [12:16] that's correct [12:17] GarvydM: That looks promising. === bialix is now known as bialix-lunch === salgado-afk is now known as salgado [12:54] vila: could you please do a second review on https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483 [12:56] GaryvdM: thanks for the review. [12:57] vila: just wanted to point out that line 64-65: unused "from bzrlib import tests" is now gone. i am waiting for branch refresh. [12:58] parthm: just for context, is there some progress bar shown in that case ? [12:59] vila: Yes, the progress bar shows bellow the message. [12:59] vila: the message (may take time) is shown. and in the next line the usual progress bar 'fetching revisions' etc. is shown. [13:00] parthm: then I think the 'may take some time' is superfluous, do we use this elsewhere ? [13:01] vila: i think the intent is that for the user "checkout" indicates a fast operation (unlike, branch). however as checkouts are heavyweight by default they take the same amount of time. [13:01] vila: hence the message. [13:02] parthm: Maybe: 'Copying history to "test". To checkout with out copying history, use --lightweight' [13:02] *without [13:03] parthm: I like Gary's suggestion. My point was that the progress bar *should* tell the user that it will take some time, and after a few seconds he should even feel how much (better than "some") [13:04] yes. thats fine by me. i will update and push. [13:05] parthm: you have pqm rights now, right ? [13:05] or did I goofed again ? :-D [13:06] vila: yes. thats working fine :) [13:06] vila: :-) [13:06] vila: thanks. [13:06] parthm: cool, so feel free to land [13:06] parthm: I've approved [13:06] vila: sounds fine. i will update the user message and land it. [13:07] vila, GaryvdM: thanks guys. [13:23] when i try to do bzr push, getting an error like bzr: ERROR:parent directory of bzr+ssh:/the/path/of/remote/server/ does not exist [13:23] can anyone give solution for this error [13:24] vila: Should I be going through the "Other reviews I am not actively reviewing" section of activereviews, or should I leave that? [13:25] sangi: Create the parent dir manually. [13:25] sangi: --create-prefix [13:25] GaryvdM, how to create parent dir [13:26] sangi: bzr help push, look for --create-prefix [13:26] GaryvdM: that would be nice [13:26] vila, ok [13:26] vila: oh - I didnot know about --create-prefix [13:27] GaryvdM: haaa, too clikety-click GUI only guys :-P [13:29] vila: all of the mp's that I have looked in that section have a review request to a specific person (typically lifeless.) [13:29] GaryvdM: you're done then :-/ Or you can nudge lifeless :-P [13:30] vila: Ah - found one that needs a second review [13:31] GaryvdM: don't forget to set the status to 'Approved' when you find (or make) one with 2 approved reviews [13:31] vila: Or just submit to pqm ? [13:31] GaryvdM: both :) [13:31] ok [13:35] vila: Don't you have a all hands this week? === bialix-lunch is now known as bialix [13:35] GaryvdM: no [13:36] GaryvdM: there may be a some hands though :) === oubiwann_ is now known as oubiwann === oubiwann is now known as oubiwann_ [13:52] after pushing the edited source to the remote server using bzr push, the changes are not getting effected in the source which is there in the remote server [13:54] sangi: yes, only the branch is updated, not the remote working tree, you want the push_and_update plugin [13:56] vila, how can i install it [13:57] sangi: First, do you have ssh access to the remote server? [13:57] sangi: like all other plugins ?? No wait, what OS are you on, what bzr version are you using ? [13:57] push_and_update requires [13:57] push_and_update requires that.. [13:58] sangi: and yes, Gary is right, do you have ssh access ? [13:59] vila, yes i have ssh access [13:59] bzr version is 1.1 [14:00] vila, using debian [14:01]