[00:08] jam: good evening! Bug 45719 refers to a branch https://code.launchpad.net/~jameinel/bzr/update-r, which is failing to mirror. Do you still have that branch available? Helping 'bzr up' grow a '-r' option sounds like something I could do in idle time... [00:08] Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] https://launchpad.net/bugs/45719 [00:08] it looks like it must be close to done already too [00:09] htm [00:09] markh: Yeah, LP just didn't like it when I upgraded my repo, and it had to re-fetch everything [00:09] It tends to timeout while downloading a full branch from my server [00:10] markh: you can get it from the source [00:10] A status of " [Medium,Fix committed]" doesn't look correct [00:10] oh - cool [00:10] just make sure you are going into a repo [00:10] http://bzr.arbash-meinel.com/branches/bzr/0.11-working/update-r [00:10] excellent - thanks [00:11] I'm not sure what you mean by "make sure you are going into a repo" [00:11] I can't just branch it? [00:12] markh: branch it into a shared repository, so you don't use up all my upload bandwidth [00:12] you *can* get it without that, but it is *nicer* to me if you do [00:13] * markh feels clueless :) [00:13] I'm not quite sure what you are asking :) [00:13] markh: I'm guessing at some point you did 'bzr init-repo', just make sure you 'bzr branch' underneath that point [00:13] then again, maybe you didnt' [00:13] nope, I didn't [00:14] I think its time I educated myself a little more on a few of these things... [00:14] markh: if you do: "bzr init-repo repo; bzr branch bzr.dev repo/bzr.dev" it will copy revisions into the repo/.bzr/repository, future branches underneath 'repo' will share them [00:14] rather than copying them again [00:14] markh: you can create one later and seed it with data from the original branch, what jam just said [00:15] anyway, family time now, I'll try to get back later to get 1.6rc4 put out tonight [00:15] oh, right - that makes sense. [00:15] hey there [00:16] quick question [00:16] markh: and the relevant point for jam, if you branch update-r it will only download the revisions that you didn't have before, not hammering his upstream :) [00:16] kiko: shoot [00:16] is there a way of saying 'give me the code as it looked in january 1st 2004'? [00:16] my current workflow is, eg, branch bzr.dev into its own folder, then make other branches from that directory. If I followed that workflow, wouldn't I still only download from John's server once? [00:16] using bzr checkout ideally [00:16] kiko: There's a "date:" revspec. [00:16] hey LarstiQ [00:16] aha. date:. [00:16] ie, wound;t a shared repo only save copies between my own local dis directoroes? [00:16] Peng_, thanks! [00:16] :) [00:17] * markh slaps his fingers... [00:17] hi LarstiQ! [00:18] hrm [00:18] markh: if you just branch inside a directory the branches will be all standalone and not sharing any revisions [00:18] or are you saying that I need to have *both* bzr.dev and john's patch in the same shared repo? [00:18] markh: you can confirm that by checking for branch/.bzr/repository/ [00:19] LarstiQ: yeah, but doing that wouldn't hammer upstream any more would it? ie, once I have the upstream copy in my local dir, other branches don't hit upstream at all [00:19] but - is the point to not pull revisions that are also in bzr.dev? [00:20] markh: now, if you are branching something (remote or local), bzr will check which revisions it should get, and if some of those are already present in the target repository, it will not fetch them again. [00:20] markh: true. [00:20] markh: exactly. [00:20] markh: since update-r is largely the same as bzr.dev, you would avoid downloading all those common revisions. [00:20] ok cool - that makes more sense. I thought the advice was to put that branch in its *own* shared repo :) [00:20] which doesn't make much sense ;) [00:20] markh: ah no, that wouldn't help any :_) [00:21] markh: to continue my train of explanation, when your are not branching to a shared repository, there will be no pre-existing target repository, hence no revisions you already have, and you need to get everything again [00:22] markh: if you are however branching into a shared repository, there _might_ be revisions in there that you would otherwise have to fetch. [00:22] LarstiQ: that makes alot of sense - thanks [00:22] markh: since we know update-r and bzr.dev are similar, we can make sure we are branching into a repo that includes bzr.dev's revisions [00:22] and hence, avoid doing more work than we really need to. [00:22] markh: cool [00:23] markh: I personally have a ~/src/bzr/ repository where I have all my bzr branches under. [00:23] now we have stacked branches, would that be the preferred way to make such patches now? [00:24] LarstiQ: yes, I think I need one of them :) [00:24] * LarstiQ is clueless about stacked branches, alas [00:24] from 10,000 feet, I understood a usecase was all about avoiding fetching stuff that is common. [00:25] markh: two effects you should notice after doing that, the size on disk of repo/ with multiple related branches is much smaller than just a directory of related branches [00:25] markh: and, branching within it is much much faster, since you need to do zero moving of revisions [00:25] Stacked branches are sort of like lightweight checkouts, where bzr doesn't download and sae the revisions at all. [00:25] Peng_: ahh, thanks [00:26] markh: oh right. I guess that might work. [00:26] * LarstiQ 's mind is still molded to think of how bzr used to work [00:26] But with stacked branches, it still works like a branch, with local commits and all. [00:26] markh: I have some catching up to do. [00:26] LarstiQ: it hasn't really changed [00:26] LarstiQ: and you make your branches in subdirs under ~/src/bzr? [00:26] markh: yup [00:26] LarstiQ: how are you btw, long time no see [00:27] markh: ~/src/bzr/{bzr.dev,1.5,1.4,bug1234,etc} [00:27] and you still branch "normally" - bzr just magically works things out? [00:27] If you "bzr init-repo", "bzr branch --stacked http://bazaar-vcs.org/bzr/bzr.dev/" and then commit something, the only revision in your local repo will eb the one you committed (or maybe a couple revisions from bzr.dev, I don't remember) [00:27] markh: Was that question directed at me? [00:27] lifeless: long past my bedtime atm :) But otherwise good, had my last exam for a while today, starting september I won't be studying this academic year. [00:27] markh: yup [00:27] Peng_: I think you answered it in the next line anyway :) [00:28] ok great - thanks guys! [00:28] markh: Other than passing "--stacked" to "branch" commands, it'll all magically work. [00:28] I just read the "quick into to bzr.dev" or whatever that doc was called and have stuck with that ever since :) [00:29] lifeless: and I just spent 5 weeks in Finland with my girlfriend, so things are looking good now [00:29] good, but exhausted :) [00:30] nice:) [00:30] lifeless: and as you may have noticed, jam has dragged me back to reading mail again. [00:31] but now I think I'll try to get some sleep. [00:31] markh: you good to go? [00:31] LarstiQ: yeah, thanks for your hel [00:31] p- [00:31] :) [00:32] glad to be of help, bug me anytime (I don't promise to know everything though :) [00:32] thanks! [00:36] thmmm [00:36] Peng_, date: is kinda weird. if the branch checking out hasn't been modified since the date specified, it fails. [00:37] the branch you're checking out [00:37] bzr: ERROR: Requested revision: u'date:2007-01-01' does not exist in branch: BzrBranch5('file:///home/kiko/devel/archives/sourcecode/pygpgme/') [00:37] that fails because pygpgme hasn't been touched in god knows how long [00:37] you might try before:date:2007-01-01 [00:37] if that fails, i think its arguably a bug [00:39] okay, I will try that [00:40] but I think it's weird, and nothing in bzr is weird, usually [00:40] its not entirely satisfactory [00:41] * markh should have known about shared repos long ago :) [02:53] kiko: date is one of those black sheep. we sort of have it, but it has a lot of points where the answer is unclear, so we sort of guess [02:54] beuno: If you get a chance: https://edge.launchpad.net/bzr/1.6/1.6rc4 === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc4! / http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ [02:58] man, I really don't feel like sending *another* email to bazaar-announce .... [03:00] jam, how about tomorrow morning? I'm exhausted now, and will probably mess it up :/ [03:01] beuno: np, you never did write up those better docs :) [03:01] jam, no, but I have notes! [03:01] I will send the patch for that tomorrow [03:01] and, it seems I may have time to try and put a script together during the week [03:02] so hopefuly I'll at least get started [03:22] It must be because it's 3.20am here, but how can a file be in the removed, added and conflicts sections of bzr st? [03:22] When should rc4 make the PPA? === kiko is now known as kiko-zzz [03:24] * VSpike thinks kiko probably has the right idea [03:24] VSpike: if you have files with different file id trying to occupy the same path, i can imagine that happening [03:25] mwhudson: I'm not aware of having done anything unusual [03:25] VSpike, sleeping beats trying to understand pretty much any software artifact. good night! :) [03:28] kiko-zzz: night :) [03:28] meteoroid: how can I resolve the issue? [03:28] mwhudson: ^ sorry [03:29] VSpike: hard to say without knowing more [03:29] VSpike: i suspect it may make more sense after some sleep :) [03:30] Yeah, you're probably right [03:30] Ah well - g'night === VSpike is now known as VSpike-zzz [03:52] Peng_: it sounds like beuno will try to make rc4 => .deb early tomorrow [03:53] Hey loggerhead question--is the front page supposed to have "Exception: name 'url' is not defined" at the top? [03:56] it's a feature! [03:57] mkanat: That was fixed quickly. [03:57] Peng_: its in the 1.6 release tarball [03:57] lifeless: Ah. [03:57] Whoops. [03:57] Peng_: I think [03:57] http://www.squid-cache.org/bzrview/ [03:58] beuno: ^ is da fugly [03:58] mkanat: Where do you see this? What version of LH is it running? [03:59] Peng_: http://bzr.everythingsolved.com/ It's running 1.6. [04:01] Maybe that's a different issue. [04:01] mkanat: If you have a few minutes, could you try running the trunk? (bzr branch lp:loggerhead) [04:02] Peng_: looks the same as the squid copy [04:02] both are 1.6 [04:03] squid is using a loggerhead.conf, which I think is a mistake, but I've mailed beuno already as to why [04:03] 1.6 should have the same 'url' fix as the trunk does. [04:03] mkanat: are you using a loggerhead.conf, or serve-branches? [04:03] conf [04:05] jam: I dunno that much about that bug; the devil told me to mark it crit. Or maybe it was lifeless. One of the two... [04:05] Peng_: do you use a loggerhead.conf? [04:05] Yeah, 1.6 has that fix, so I guess this is a different issue. [04:05] lifeless: Nope, I use serve-branches. [04:06] I'm using hte trunk too [04:06] Peng_: try with a loggerhead.conf file, bet it will cause the problem [04:07] Sorry, but I've never used loggerhead,conf, and I'm lazy. [04:08] You try serve-branches. :P [04:10] :P [04:17] ew, the browse view is sure super hideous [04:45] mwhudson: so loggerhead 1.6.1 soon ? [04:50] i guess [04:50] the listing page is quite a regression [05:18] lifeless: gee, what happened? [05:32] http://www.squid-cache.org/bzrview/ [05:32] thumper: ^ [05:33] :) [05:33] thumper: see the horrible output? [05:34] yes I did [05:34] Has somebody filed a bug? Should they? [05:34] thats loggerhead 1.6 using loggerhead.conf [05:34] mwhudson: have you? [05:35] lifeless: no [05:35] I shall [05:49] bug 259273 [05:49] Launchpad bug 259273 in loggerhead "loggerhead.conf usage borked" [Undecided,New] https://launchpad.net/bugs/259273 [08:16] hi, attempt to merge branch produced with vs import on lp (from cvs) with the branch produced by running tailor on cvs repo gives: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.". by looking at LP, i've found the latest common revision, but the problem is that revision number differ on both branches. how am i supposed to update my local branch (tailor-generated) with the more-up-to-date branch [08:16] from LP (vsc-import-generated) ? [08:19] revision numbers don't matter [08:19] gour: well bzr thinks of them as totally separate [08:19] hmm [08:19] gour: they have different file identity [08:19] lifeless: how is it so? [08:20] gour: because they were separate imports [08:20] but those are same stuff, only one is more up to date [08:20] gour: if you run bzr inventory --show-ids [08:21] gour: you will see that they may have the same paths but are different file ids [08:21] gour: you can force it to merge, but it will conflict across the whole tree [08:21] gour: the question is, have you been committing to your local tailor generated branch ? [08:22] lifeless: ahh, it means that import us useful only as one-time affair? [08:22] lifeless: no, i just imported earlier [08:22] then just replace it with the launchpad one [08:22] ongoing imports are useful, but separate imports generate separate histories [08:22] that i know...i wanted to see how to merge them in case i'd have some local changes [08:23] in particular with CVS, where 'history' is arbitrary anyhow :) [08:23] the branches are at https://code.launchpad.net/gnumed [08:23] heh, that's why i'm pushing GNUmed to adopt bzr :-) [08:25] lifeless: how to force merge? supplying --force does not help [08:25] gour: merge -r 0..-1 [08:25] gour: and then cry [08:26] gour: you could potentially use tailor to transfer the commits from one branch to the other [08:26] :-) [08:26] gour: normally, to deal with a local edit in this situation, you'd generate 'bzr diff -r LAST_FROM_CVS..-1' > some_file [08:26] but it is probably best to pick one CVS -> bzr import as the canonical one [08:26] then bzr patch some_file in the import you're keeping [08:26] jamesh: yeah. [08:28] if my local branch would be older revision of LP's gnumed with local changes, then merge won't be a problem, right? [08:28] the branches would have same ids [08:29] or different vcs import still produces different ids? [08:29] gour: neither tailor or cscvs (what the Launchpad imports use) produce repeatable imports [08:30] they'll have different revision IDs and different file IDs [08:30] both of which are important to "bzr merge" [08:30] jamesh: so, all the imports listed at https://code.launchpad.net/~vcs-imports/gnumed/trunk are not suitable for merge then? [08:31] gour: if you branch from that import and do work, you'll be able to merge newer changes from that same location [08:31] and merge between branches that derive from that import [08:31] the same goes if you used a tailor generated branch as the canonical import [08:31] jamesh: ahh, that's what i wanted to hear [08:32] you'll only see problems when you take branches derived from different imports and try to merge between them [08:32] i can use LP's import, work on the branch and then update from the newer imports which are regularly done [08:33] yes. [08:33] LP does new import every day... [08:33] good [08:33] the Launchpad imports are done incrementally [08:33] ahh, that's the catch ;) [08:33] it doesn't redo the import every day -- it updates the existing import [08:34] similarly, you can maintain a tailor import incrementally [08:34] however, i do not propose this as normal workflow...the idea is to contribute something via bzr to LP's import and prepare devs to migrate to bzr :-) [08:34] right...just not mixed the two :-) [08:39] the Launchpad imports don't really help too much for two-way communication [08:39] you can't move changes back to CVS in a way that will be recognised by the CVS -> bzr importer [08:39] if you're lucky, it'll come up as a null merge [08:40] if you're unlucky it'll be merge conflicts [08:41] well, i'll contribute to bzr branch on LP and let them patch upstream if they don't want to use bzr, but i won't use CVS [08:41] if you're using short term feature branches, this isn't too bad: you can throw away the branch once it gets merged [08:42] btw, does it make sense to sign for Ubuntero for someone not using Ubuntu, but using LP [08:42] it is up to you [08:43] the only things that require it at the moment are becoming an Ubuntu member and getting access to Launchpad's personal package archive feature [08:43] if those don't interest you, then you aren't missing out on anything [08:43] hmm, ppa [08:44] that might be handy [08:44] but that's, again, only ubuntu pkgs, not source releases, right? [08:45] right. [08:45] heh, then i do not need it...which does not prevent me to follow the good codes uven without signing :-) [08:46] *even [09:06] ping bkor === gour is now known as LaskoPivo === LaskoPivo is now known as gour === VSpike-zzz is now known as VSpike [09:51] I'm confused how files can be in the removed, added and conflicts sections of bzr status? [09:51] command output at http://www.pastebin.com/m422b0b96 [09:52] Sorry that should be http://pastebin.com/m422b0b96 [10:06] Hi All. I have a problem with a bzr repository returning a "Revision .. not present in .." error, does anyone have the time to help me out with the problem? [10:20] VSpike: what is confusing? [10:28] lifeless: I don't understand what it is telling me. From my point of view, I have done nothing different other than change the contents of the binary files Bin/Geonix.dll and Bin/Geonix.pdb, which normally results in them showing as changed [10:28] I don't understand how to resolve the conflict and commit the changes [10:33] when I want to install bzr 'aptitude install bzr' it wants to install x-server and so on... ??? [10:33] I only need command line with bzr [10:33] any tips? [10:34] VSpike: so, being in conflict means bzr couldn't decide for you how to do a merge for you [10:34] VSpike: if you see the one file both deleted and added, it means someone had added them in parallel elsewhere, so you have the same file /name/ with two different histories, and you need to choose one [10:34] VSpike: use bzr mv and del to arrange the tree how you want, then bzr resolve NAME [10:35] enquest: uhm, its bzrtools I think [10:35] enquest: it uses graphviz or something, and that pulls in X [10:35] enquest: if you are using aptitude, try going in via the gui [10:36] sudo aptitude [10:36] then /, bzr, i [10:36] and then edit the actions list and change stuff [10:37] enquest: I've solved that problem on a debian server - just trying to remember how [10:37] this is a securtiy problem using bzr on your server... If you not good at managing servers you don't know these things [10:38] enquest: huh? [10:38] aptitude installs recommended packages by default? [10:39] luks: it's configurable [10:39] enquest: try "sudo aptitude install bzr --without-recommends" [10:39] ok I did not know that with apt-get you don't have that problem [10:39] VSpike, thanxs [10:39] enquest: or use the ncurses interface as lifeless suggested [10:44] lifeless: sorry if i'm being obtuse, but I can't see how it got to this state... [10:45] lifeless: I'm working in a single branch, doing modify/commit, modify/commit.. and occasionally modify/commit/push [10:45] lifeless: so there should have been no merges into this branch [10:46] Some sort of file name case wackiness, maybe? [10:48] Peng_: I wondered that, but they show the same in bzr stat at least [10:48] Yeah.. it's still possible though [10:49] The irony is, this is a binary generated by the build of a sub-project [10:49] I only check it in so that I can recreate a past situation exactly, because bzr doesn't allow me to connect the two projects yet [10:50] So if I delete it, it will just get regenerated [10:54] VSpike: could you pastebin the output [10:55] lifeless: of? [10:55] I just did "bzr mv Bin [10:55] I just did "bzr mv Bin\Geonix.dll Bin\Geonix.dll.old" and the same the .pdb file [10:55] But not sure I'm any better off [10:56] lifeless: you want bzr stat --show-ids again? [11:15] VSpike: again? [11:15] VSpike: anyhow, I'm heading off sorry [11:16] lifeless: I posted it back aways... [11:16] VSpike: perhaps Peng_ or someone else still awake can comment on a pastebin output for you [11:16] http://pastebin.com/m422b0b96 [11:17] so [11:17] to get conflicts, you _must_ have done a pull, or merge, or update [11:17] now http://pastebin.com/d49a67117 [11:17] lifeless: anyway I can check that in a log? [11:17] as for the delete + add pairs; simplest thing would be to save the copy you want to keep, bzr rm the new file, bzr revert PATH to restore the old fileid, then copy the one you want back in [11:18] bzr --version will list your log file [11:18] bzr commands are listed in the log [11:18] I must go though - good luck [11:18] thanks! [11:23] Arrgh, rc4 happened while I wasn't looking [11:24] :-) Is BB back up? [11:25] Guess not. [11:25] moin. [11:59] mwhudson: it seems that bzr developers have fixed my bug yesterday, and the fix is going to make it to 1.6rc4 :) [12:00] ignas: i/we found another bug that might mean a 1.6c5 :( [12:00] oh. What's the number? [12:01] ignas: https://bugs.edge.launchpad.net/bzr/+bug/259275 [12:01] Launchpad bug 259275 in bzr "pushing a non-stacking format into a non-repo bzrdir with a default stacking policy creates broken branch" [High,Triaged] [12:04] mwhudson: hmm, not sure I understand what operations I should be avoiding if I don't want to break things... [12:04] ignas: this bug is only likely to affect launchpad, realistically [12:04] should I not try pushing to my remote knit repository from my stacked repository for example? [12:04] no [12:05] no, don't do that, or no, no problem? [12:05] as in, you should be fine [12:05] pfew :) [12:05] english sucks [12:05] hmmm [12:05] bzr st segvs for me in my /etc! [12:05] that is very fun [12:05] kiko_: exciting [12:06] mwhudson, SPEAKING of segvs.. [12:07] #0 0xb7e54cbf in memcpy () from /lib/libc.so.6 [12:07] #1 0x08092895 in PyString_FromStringAndSize () [12:07] #2 0xb7778d4e in ?? () [12:07] from /usr/lib/python2.5/site-packages/bzrlib/_dirstate_helpers_c.so [12:07] mwhudson, I guess this is known..? [12:07] Bazaar (bzr) 1.5 [12:07] kiko_: not by me [12:08] okay, will try and file a bug then [12:08] i can imagine a corrupt dirstate tripping up the c parser or something [13:08] lifeless, ew, template for start-loggerhead seems broken :/ [13:08] * beuno waves [13:10] hi [13:12] beuno: the breadcrumbs branch is ready for a further review [13:13] pickscrape, cool. I'll take a look at it after my coffee :) [13:15] beuno: no rush, just letting you know :) [13:57] Could anyone point me at an explaination of when I need to use the record command when using a loom? [14:38] ok, if my bzr-svn checkout failed (ERROR: revision "blah" already present in "revisions"), is there anything I can do to work around it? [15:34] jam, building rc4 debs now :) [15:35] beuno: before you spend too much time, mwhudson wants an rc5 [15:35] I'd like to at least look at the bug first [15:35] jam, ah, heh, ok. I'll start looking intro scripting then [15:53] mwhudson: ping [15:53] You have a bug, but do you have a possible fix? [15:53] Even just an outline of the fix [15:58] how can I determine to which host bzr launchpad-login is trying to connect exactly? the --verbose flag doesn't show anything and the error says: ERROR: Connection error: while sending GET /%7Ecr3/%2Bsshkeys: (111, 'Connection refused') [15:59] seeing the url, I guess https://launchpad.net. I thought at first it might be the openid url, nevermind [16:01] cr3: default URL [16:01] BZR_LP_XMLRPC_URL=http://xmlrpc.launchpad.net/bazaar/ [16:01] you can set that in your environment, I believe, to override it [16:01] Oops, I'm wrong, it is https://xmlrpc.launchpad.net/bazaar/ [16:02] the 's' is there [16:12] jam: telnet xmlrpc.launchpad.net 443 works, but I'm still getting the same error message [16:13] jam: I then tried setting the environment variable, just in case, same thing === kiorky_ is now known as kiorky [16:27] Is bzr push really really slow over a network share if you have virus checking of network drives on? [16:32] possibly, I know I've had antivirus software cause locking problems for bzr before [16:54] cr3: are you behind a proxy? It is a known problem with python's xmlrpc implementation that it doesn't respect http_proxy [16:55] awilkins: packs or knits? Knits would probably be extra bad because we would touch lots of files [16:55] jam: Packs [16:55] though I could also see a repack of a .pack file causing issues if the software had to virus check the whole pack file [16:55] jam: It's rich-root-pack, 210MB total, largest pack 160MB [16:55] though it is all compressed data [16:55] awilkins: well, we might read *parts* of some files [16:56] which may cause the virus checker to read the whole thing? [16:56] So we might read 100k from your 160MB file [16:56] jam: I wonder if reading multiple regions of that large pack makes it check the whole file each time [16:56] and then your virus checker decides [16:56] it needs to read all 160 MB [16:56] I'll run it with filemon active next time [16:56] also, we may go back multiple times to portions of the file [16:56] which might trigger similar issues [16:57] (one read from 10-100, another at a later time 1000-1100 etc [16:57] I'm note sure it's the vchecker [16:57] I believe I tried it with the service stopped once [16:58] Anyhow, it's nearing 1700, and I need to catch my train [16:58] back-in-a-bit [17:01] kiko_: I just submitted a patch for the dirstate parser which should at least give a proper traceback rather than a segfault. [17:03] jam: I am behind a proxy but I don't have the http_proxy environment variable set and I have an iptables rule explicitly allowing connections to xmlrpc.l.n, bazaar.l.n and l.n [17:04] cr3: can you try it with "bzr launchpad-login -Derror" ? [17:04] that should give you a traceback that you can pastebin for me [17:06] jam: http://pastebin.com/d36c2c2ae [17:08] jam: just to make sure, env | grep -i proxy returns nothing [17:10] jam: also, I'm tailing the logs on the proxy and nothing is appearing when running launchpad-login [17:10] cr3: so, after the xml call, we then do an HTTP fetch, which *does* respect the http_proxy setting [17:10] And that is the point that is failing [17:11] The http fetch is going to https://launchpad.net/~user/+sshkeys [17:11] Try setting http_proxy and see if it works [17:12] I made a branch from a branch located on my local file system... I moved the branch I created and now I can't pull from the original branch... it's saying the parent is not accessible given a base and a relative path... is there a way to fix that? [17:13] jam: worked! [17:19] cr3: so it seems you got the xmlrpc stuff to go through without the proxy, but not https://launchpad.net requests [17:19] mxpxpod: 'bzr pull --remember /new/location' [17:20] jam: ah, thanks... I figured out I can also modify .bzr/branch/branch.conf [17:20] jam: but I figured there was a better way to do it [17:26] hi [17:26] i've just upgraded to bzr 1.5 and i'm getting an error when using the --use-existing-dir option now [17:27] bzr: ERROR: extra argument to command push: use-existing-dir [17:27] couldn't find any notes on the changes to this argument [17:28] this is for the push command of course [17:28] any ideas please? [17:29] is there a way to "force" bzr to invoke bzr-svn for a checkout over http? [17:30] I keep getting "bzr: ERROR: Transport error: Server refuses to fullfil the request" [17:30] alexreg: try it with '--no-plugins' [17:30]