[00:13] hm [00:14] why are the only calls to bzrdir.clone() with preserve_stacking=True in the branch_implementations tests? [00:14] hm [00:14] i guess a branch is certainly involved if there is stacking going on [00:19] mwhudson: push --stacked uses clone, no ? [00:19] lifeless: i guess i should have inserted the word 'direct' into my sentence somewhere [00:19] "Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)" :) [00:20] spiv: and the format is actually development1 ? [00:20] mwhudson: no, it actually is one of those [00:20] ok [00:20] spiv: https://bugs.edge.launchpad.net/bzr/+bug/250422 [00:20] Launchpad bug 250422 in bzr "pushing over hpss ignores stacking policy" [Undecided,New] [00:20] spiv: instant thoughts? [00:24] mwhudson: "that sounds like a bug" [00:24] spiv: i'm glad you think so [00:24] mwhudson: A -Dhpss trace might be interesting. [00:25] mwhudson: a wild guess is that RemoteRepository doesn't look at the stacking policy? [00:26] I din't want to invent ftp [00:26] so the client is meant to resolve $shit [00:27] spiv: the problem is that i don't know which piece is _supposed_ to look at the stacking policy [00:27] i guess i should read through cmd_push [00:33] so I'm thinking for marks [00:39] mwhudson: me either :) [00:41] hmmmm [00:44] spiv: the problem seems like it might be RemoteBzrDir.get_config not doing the right thing [00:49] mwhudson: I can certainly believe that. [00:49] spiv: i commented on the report [00:50] mwhudson: if you implement a "def get_config(self): self._ensure_real(); return self._real_bzrdir.get_config()" does that fix it? [00:50] spiv: let's find out [00:51] spiv: no [00:52] though, um [00:52] spiv: if you add it to the right class, yes, that seems to help [00:52] :) [00:54] mwhudson: that's good to know. Send a patch to the list :) [00:54] spiv: where should a test go? [00:56] er [00:56] config = my_dir.get_config() [00:56] if config is None: [00:56] self.assertFalse(isinstance(my_dir, bzrdir.BzrDirMeta1)) [00:56] raise TestNotApplicable( [00:56] 'This BzrDir format does not support configs.') [00:56] * mwhudson objects, furiously [00:56] IsNotInstance ? [00:56] hmm, I want a composer [00:57] lifeless: I suggest Bach [00:57] EDEAD [00:58] in this regard, I'm a vitalist [00:59] so what are BzrDirFormat5 and BzrDirFormat6 ? [00:59] bzr 0.5 and 0.6 [00:59] they are all-in-one formats [01:01] so caring about them is not at all encouraged? [01:01] we upgrade from them [01:02] but clearly they cannot support stacks because their repository is not modular - you can't change the repository logic without stopping it being a bzrdirformat5 or whatever [01:04] ok cool [01:05] that test wants a whitelist not a blacklist because of e.g. bzr-svn etc [01:05] its an /interface/ test not an implementation test. [01:08] hi :-) [01:08] lifeless: whitelist as in "these formats are allowed to not do get_config" ? [01:09] 09:56 < mwhudson> self.assertFalse(isinstance(my_dir, bzrdir.BzrDirMeta1)) [01:09] thats a whitelist [01:09] these formats are required to do it [01:09] oh, ok [01:09] ppires: hi [01:10] mwhudson: installing bzr-svn won't magically change a static list like that, and it doesn't have a full plain text format [01:10] lifeless: right, fair enough [01:10] do i need bzr installed in order to use something like bzr-eclipse plug-in? [01:11] ppires: yes [01:11] ppires: there is a faq for installing bzr-eclipse [01:12] yes there is lifeless, but as i'm having some issues with the plug-in itself just wanted to double check. thanks [01:12] Verterok: ^ [01:12] Verterok is the author [01:12] lifeless: it wasn' [01:13] t immediately clear to me that bzr-svn's bzrdir should return None from get_config as opposed to a config that had no values set [01:13] mwhudson: I don't actually know what it does offhand :P [01:13] though i guess set_default_stacked_on is part of the config interface... [01:17] lifeless: it returns an object that converts some svn file properties to bzr settings [01:17] is it a known bug that merging a bundle based on a revision you don't have causes a traceback (couldn't find it on lp but want to double check). [01:17] in particular the mergeWithUpstream property used by svn-buildpackage, which is convert to the equivalent for bzr-builddeb [01:18] hmm [01:18] * mwhudson appears to be unable to drive send [01:18] mwhudson: why does that matter? [01:18] bzr send -o- produces something reasonable [01:19] but 'bzr send' doesn't attach anything to the mail [01:19] lifeless: thanks [01:19] jelmer: because of the way the test for bzrdir.get_config() is written [01:20] ppires: if you have any issues with the plugin, maybe I can help [01:21] Verterok: I demoed bzr-eclipse at lugradio live too FWIW [01:21] ppires: also I'm going to release a new build in the next few days (hope I can get it for tomorrow) [01:21] lifeless: yay! :) [01:22] hi Verterok i'm here looking how to install plug-ins. http://bazaar-vcs.org/UsingPlugins is not very clear about it [01:22] i mean, they talk about folders, but not how to install them. should they be compiled somehow? [01:23] ppires: which OS? [01:23] http://bazaar-vcs.org/XMLOutput only offers the source-code. [01:23] Linux, Ubuntu 8.04 to be more precise [01:24] ppires: bzr branch lp:bzr-xmloutput/0.4 $HOME/.bazaar/plugins/xmloutput [01:24] ppires: that should do the trick :) [01:24] is there a convention for including bug numbers in merge requests? [01:24] ppires: or you could do a checkout: bzr co lp:bzr-xmloutput/0.4 $HOME/.bazaar/plugins/xmloutput [01:25] lp is a shortcut to launchpad? [01:26] Yep. [01:26] cool! [01:26] bye guys [01:27] Verterok: i'm using eclipse ganymede (3.4) and bzreclipse leaves some "unable to staisfy dependency" in the Error log [01:28] morning [01:28] ppires: I'm not sure if it works with 3.4, let me check (I'm still with 3.3) [01:29] mornin' igc [01:29] hi Verterok [01:30] i cannot reach "Console" and "Decorators" tabs. eclipse complains about invalid values [01:30] bye lifeless and thanks [01:31] morning igc [01:31] ppires: you must configure the location of the bzr executable [01:32] ppires: in the "Bazaar" pref. page [01:32] * Verterok launching Eclipse 3.4 [01:32] spiv: sent to the list [01:40] ppires: I can't even start 3.4 :( (I think I should download the final release :P ) [01:40] you were right Verterok [01:41] ppires: it's working? if not, could you pastebin the error? [01:41] eheh, i'm running the latest stable release [01:42] Verterok: this is a lamme question, but are Decorators the ability to mark graphically resources like files? [01:42] and folders.. [01:43] mwhudson: thanks [01:43] ppires: yes, to show the status of the file/folder/project [01:44] ok, i answered this one and i was in doubt. https://bugs.launchpad.net/bzr-eclipse/+bug/160907 [01:44] Launchpad bug 160907 in bzr-eclipse "When creating new classes in Eclipse it would be nice if they were automatically added to bazaar" [Undecided,Incomplete] [01:45] wow cool bot! [01:46] ppires: right, the files/folders are flagged with the db-like orange icon (like in the CVS plugin) [01:47] never used cvs. anyway, Verterok does this plug-in support bzr+ssh? [01:48] ppires: it should, because it uses bzr to execute the commands [01:49] i'm not used to bzr that's why this may sound a bit confusing to me. [01:49] ppires: be carefull with the authentication, check Bug #121936 [01:49] Launchpad bug 121936 in bzr-eclipse "Eclipse hangs in bazaar operations that require user input" [High,Triaged] https://launchpad.net/bugs/121936 [01:52] ic, tks! [01:52] ppires: for workaround until I fix it, look the Authentication section in http://bazaar-vcs.org/BzrEclipse/Installation [01:52] now i'm going for bed. work tomorrow. tks a lot Verterok! i'll keep in touch ;-) [01:53] ppires: np, sleep well, see y'later [01:54] * Verterok running out of battery, be back in while [01:56] * mwhudson lunches [02:02] * beuno dinners [02:03] + [02:08] * emgent thinking to sleep. [02:40] this is a little surprising: http://pastebin.ubuntu.com/29167/ [02:58] * mwhudson digs [04:28] * spiv -> lunch [05:00] * mwhudson is probably done pelting the bazaar list with merge requests now === beuno_ is now known as beuno [05:47] huh how bizaare [05:48] beuno: still here? [05:48] mwhudson, yeap [05:48] despite my ISPs attempt to make me got to sleep [05:48] i have this pair of branches where merging a into b gives 'nothing to do' and merging b into a gives conflicts [05:48] wtf?? === sdboyer is now known as menu_system === menu_system is now known as sdboyer [05:55] what now?? http://pastebin.ubuntu.com/29210/ [05:56] what now?? http://pastebin.ubuntu.com/29210/ === beuno_ is now known as beuno [06:15] mwhudson: that's an unexpected traceback. [06:15] yeah [06:15] It makes about as little sense to me as it does you : [06:15] :) [06:16] it happens with the installed 1.6b3, not bzr.dev [06:16] i guess it's a circular import [06:17] and one of my plugins happens to import branch earlier or something [06:17] spiv: does it happen for you? [06:17] it's very quick, obviously, before even the check that '.' is a branch [06:18] mwhudson: nope, but I only have bzr.dev [06:19] fair enough [06:41] * mwhudson corrects the mail he's about to send from going to Martin Pool to going to Martin Albisetti [06:41] one of you guys has to change his name, i think [06:56] mwhudson: put forward the request in #canonical-sa's? [06:57] spm: maybe [07:02] jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/250706 [07:02] Launchpad bug 250706 in bzr-svn "branching locally tries to reach forward svn server" [Undecided,New] [07:33] I want a programming language / refactoring tool / editor / vcs that understands itself. [07:33] and a pony. [07:35] A self-aware pony? [07:36] maybe. [07:37] It's hard to say. I so rarely use ponies to make changes to things. [07:38] jml: i'm sure you can still get a LispM from somewhere [07:39] mwhudson: do you reckon they'd integrate with my freerunner? [07:39] jml: they would probably destroy it quite thoroughly if they fell on it [07:39] haha [07:39] freedom prevails. [07:40] my word, you can still buy genera [07:42] or pirate it, apparently: http://www.advogato.org/person/johnw/diary/12.html [07:52] * mwhudson wallows in computing nostalgia [07:53] mwhudson: heh [07:54] on http://en.wikipedia.org/wiki/HyperCard now [07:54] mwhudson: so, the thing that provoked this outburst of mine was thinking that I was saying "extract method foo from bar" twice: once in emacs and once in my bzr log [07:54] jml: someone has been talking about this sort of thing on the rope-dev mailing list recently i think [07:55] mwhudson: glyph mentions this sort of thing from time to time. [07:55] oh wow. rope isn't brm. [07:56] but he's not been being very clear and i haven't put the effort in to really understand what he's on about [07:56] *nod* [07:56] yeah, rope looks a little interesting [07:56] but, sigh, time [07:56] wonder what "Mercurial, GIT and SVN (pysvn library) support in refactorings" means [07:57] also i entirely failed to get ropemacs to work at all last time i used it === doko_ is now known as doko [09:58] jelmer_: for the auth problem, somehow some branch.conf werent wearing the good url, fixing it fixes auth cache. [09:59] jelmer_: can we use svn urls and rely on svn cache, without having to put url with creds inside ? [09:59] jelmer_: i mean urls in the branch.conf [10:23] night [10:25] Good night. [10:45] Changing an unlocked branch through bzrlib doesn't set a lock right? (for example branch.set_push_location(location)). I wonder how bzr-gtk should behave regarding setting and releasing locks on branches. I assume you only read_lock when it takes a little while to read out all the stuff you need and want a consistent set and set a write_lock if you want change stuff that takes a little while, while changing small bits like the mentioned set_defa [10:45] ult_location() don't need a lock? [10:46] * the mentioned set_push_location() [11:06] Bazaar takes out a write lock for a moment when it renames a modified pack-names into place. It's the right thing to do. [11:21] but fully handled by bzrlib.. I guess bzr-gtk has to be checked that in all cases a lock is set it is released asap. [11:22] * Peng_ shrugs. [11:22] I think many operations take out locks themselves and some require you to do it, but I don't know. [11:28] Does Bazaar have something like Git's merge diff view? [11:32] what is special about gits merge diff view o_O [11:32] i've never seen it [11:32] it shouws two columns of ++'s [11:39] as with http://ss.frim.nl/==814 for example [11:41] no idea personally [11:41] is that a gitk feature, or a git feature? [11:41] (can i do it in a shell) [11:41] git feature [11:42] gitk just adds some colors [11:42] is that the same as "git diff --cc" ? [11:44] more like -c, I think [11:44] but it's the same as "git show " [11:44] I don't think we have that, would you care to file a bug? [11:45] I think it would be good to have for those that want it. [11:45] sure [11:46] and if you can explain the use case, rather than just saying that we should clone the git feature that would be appreciated. [11:46] igc: your merge seems fine, and git-bzr still works as first :) [11:47] Pieter: ok, thanks for the test [11:49] there is merge --preview, is that anything like the git feature? [11:50] I don't know.. can I use it on an existing merge? [11:51] mwhudson: I don't think so. [11:51] ok [11:52] I think the git feature allows you to attribute changes to each side of the merge. [11:52] night all [11:52] night igc [12:06] james_w: #250783 [12:06] thanks [12:24] is anyone familiar enough with http://research.operationaldynamics.com/blogs/andrew/software/version-control/bzr-orthogonal-patches.html to answer a couple of questions related to it? === mark1 is now known as markh [12:24] Moin. [12:31] markh: Possibly. What are the questions? :) [12:32] the article mentioned keeping the revision history for the underlying changes as a motivation - but once you get to the end of his article (ie, after the final commit), a "bzr log --long" only shows a single revision for the merge - not the smaller revisions that you merged from the initial tree. [12:32] so the question is "what am I missing?" :) [12:33] so the "bundle" and everything else described works as advertised - but the point about the revision history isn't mentioned after the introduction [12:37] actually, I think I know... [12:37] I did "bzr merge ..\orig_branch\filename.py" [12:37] I imagine I needed to do lots of individual "merge -r ..." commands to get what I was after [12:38] manually extract them from the log I guess... [12:39] So I'm not really familiar enough with the article to help after all. But you probably do want several 'merge -r's rather than a 'merge '. [12:44] kiorky: bzr-svn already uses the svn cache but it doesn't write to it [12:46] actually, it appears I'm missing the point :) The conclusion says "Contributors meanwhile can create all the private revisions they ever wanted, and don’t have to forecast which are going to be publicly visible and which aren’t. So they can leave off worrying about a proper commit messages, etc, until they actually go to create and submit an orthogonal patch." [12:48] ok, I see where I got confused now :) The person putting the patch together makes the commits, then sends them upstream - but its still only those explicitly committed in the patch creation process that are included, not all the original checkins that went towards it. [12:49] (Off-topic) This is odd. markh's second-to-last line wraps to three lines, and on the second one, a bit of the blank space just shows whatever was last on the screen. Another blank spot doesn't. [12:50] I generally try to keep my branches focused so I don't have to try and reverse engineer a single branch into feature branches [12:51] if they are orthogonal, then I can usually work on them independently. If they are not orthogonal, then the loom plugin can help. [12:51] oh hey, loom, I forgot that as a solution. [12:51] yeah, but often working towards one feature means editing 4 files - which logically break down as 2 patches for review [12:52] then you have 1 tree, with 4 files with mixed up checkins. Its seems very hard to create a bundle from just 2 of those files for review [12:52] if you do have a single branch and the changes you want to separate are related the loom plugin can still be useful [12:52] a patch is obviously fine, but a bundle seems hard [12:52] yeah - I'm not familiar with loom yet :( [12:53] start with two threads: the upstream trunk and your combined branch [12:53] create a thread in between them for the first change, moving the relevant work down from the top thread [12:53] then merge up again (which should be a null merge due to the changes already being present) [12:53] repeat until you're finished and discard the top thread [12:54] thanks for the tip! I'll have a read up on it... [12:56] markh: Shelve from bzrtools would also allow you to do something like this (shelve one reviewable set of changes, commit, unshelve, commit). === serg_ is now known as serg [13:02] Odd_Bloke: thanks, but I think that might be slightly different - each of the files had already been locally committed many times. loom sounds like it might be closer (not that I've looked yet...) [13:02] shelve is closer to mercurials "queues" iirc? [13:03] I'm not sure, but it does sound like looms would work better for you. :) [13:04] markh: from my understanding, you would do one merge -r range for each range you want to include in the logical patch [13:04] Shelves aren't the same thing as mq. [13:04] LarstiQ: hi! and commit each one? [13:04] bugger :) [13:05] Shelve is just for letting you temporarily remove changes from the working tree, and then put them back. [13:05] markh: you could do that if you wanted that granularity, or just commit one thing if that is ok to you [13:05] You could probably use it as a really poor man's mq, but not very well. [13:05] (Since you can have multiple different shelves.) [13:06] what are queues more like then? looms? branches? [13:06] when I initially read the article, I thought it would bring across each of the initial commits, with their original message. I now (think I!) understand it only brings across the explicit commits you make in that "cherry-pick" branch. [13:06] markh: say you want to create a bundle to just review a cog change, and have relevant changes in revisions 1, 2, 4, 6 and 7. [13:06] markh: correct. [13:07] markh: well, content changes even, it doesn't bring across revisions. [13:07] I guess I meant "and commit messages" :) [13:07] markh: untill someone makes it so that cherry picks get recorded fully. [13:08] I was talking with you about this exact issue at eurocon. So IIUC, loom is the only reasonable way to magically create a bundle that did include both changes and checkin messages? [13:08] markh: (continueing my example) you would then 'bzr merge -r 1..2; bzr merge --force -r4; bzr merge --force -r6..7; bzr commit' Assuming I'm not off by one, and you want to create one revision. (Depends on how big the changes are I guess) [13:10] markh: ah, if you want to recreate the revisions more or less exactly, I would do 'foreach rev: do bzr merge -rrev; bzr ci -m `bzr log -rrev path/to/orig`; done' [13:10] in my current knowledge, for that workflow [13:10] looms might be better [13:10] markh: not sure if the foreach plugin would help there [13:10] would that include the original author of the patch? [13:11] markh: no, it would take as committer whatever is set for the one doing the new commits. [13:11] could be done too of course [13:11] I see a good use case for the bzr-orthogonal-patches.html, but just checking loom is probably the only good solution if I want the "full history"? [13:12] but I have to get back to my exercises with ambigous notation :/ [13:12] no probs - thanks! [13:12] markh: the "real" solution is making cherry picks record the fact. [13:12] (in my case, for my recent patch, bzr-orthogonal-patches.html is actually a better answer - I'm just curious) [13:12] imo. [13:12] LarstiQ: right - just making sure I understand things as they are now - its all getting clearer each day :) [13:13] markh: I'm not well versed enough in looms to answer that unfortunately. [13:14] markh: The for loop with the ci -m `bzr log -r` trick is what I practically do right now if I find myself in that situation. [13:16] markh: did I tell you I had gotten python-nautilus running? [13:16] pygi: you were still going to tell me about Novell's plans on nautilus integration btw. [13:16] no! I also found myself cringing at some windows specifics I forgot about when taling to you :( [13:18] but I've a really nice tbzr build, with the very nice qt4 based qbzr, and largely working! But I must go and re-acquaint myself why my girlfriend for a while... [13:18] markh: I really really have to kick myself back to studying now or I'll avoid studying all day long, but I will check back on tortoise status later today, and try to publish something that works with nautilus. [13:18] markh: oooh [13:18] markh: have fun, and I look forward to checking out the qbzr stuff :) [13:20] LarstiQ, you must be joking :) [13:40] Looking at qbzr has really made me want to start working on BazaarX again [13:40] I just need to find the time from somewhere [14:33] Hi. [14:34] Is it a bug or an unwarrented expectation of mine that using setup.py to install bzr into ~/opt/bzr-1.5/ yeilds something that won't work because it can't find bzrlib? [14:34] (well, it does find bzrlib, just the ancient one that's installed system-wide) [14:39] Additionally, is it the case that the current stable bzr-svn requires a non-stable release of bzr to run? [14:39] I ask this question due to receiving this error: bzr: ERROR: Installed bzr version 1.5 is too old to be used with bzr-svn, at least 1.6 required [14:39] (I did a lightweight checkout of http://people.samba.org/bzr/jelmer/bzr-svn/stable/ and bzr was obtained from the release tarball) [14:40] rjek: Try prefixing the bzr command with 'PYTHONPATH=~/opt/bzr-1.5/lib/python:$PYTHONPATH' [14:41] Odd_Bloke: Sure, I've been informed about that solution. But as a non-Pyton user who just wants to use bzr (with no regard of what it's written in) I was a bit surprised that it didn't "just work". [14:43] rjek: Well, if you installed anything in a non-standard location, expecting it to 'just work' is optimistic. [14:43] Not when there's an install script! [14:44] If all it was doing is just copying files to a directory, what's wrong with the common makefile with an install target? [14:44] rjek: you need a released version of bzr-svn for bzr 1.5 [14:44] I was kinda expecting a tool called "setup" to set it up for use, rather than just copying it somewhere. [14:45] rjek: But you don't want a tool called 'setup' to monkey around with your shell environment, because it will almost certainly do something wrong. [14:45] Odd_Bloke: Quite. However, rewriting a bit of the (trivial) bzr launcher script it puts in bin/ seems like an ideal approach. [14:46] If the setup tool isn't actually going to set it up then, perhaps changing its name to something that doesn't suggest that it will would be wise, to avoid confusion for people like me who have no interest in Python? [14:46] rjek: wouldn't you expect a command that involved the word "install" (instead of, say, "copy") to actually make it usable in the installed environment? [14:46] jelmer: Where can I obtain this from? The plugins page on bazaar-vcs.org doesn't mention anything other than the stable branch. [14:46] (i.e., make install) [14:46] Yes. And in general, they do. [14:46] rjek: It's on the bzr-svn wiki page, http://bazaar-vcs.org/bzr-svn [14:47] not if you specify a prefix like ~/opt/bzr-1.5 [14:47] jelmer: That page doesn't exist. [14:47] radix: `./configure --prefix=~/opt/foo && make install` almost always works. [14:47] rjek: maybe you use a different version of 'make' than I do, but it certainly won't set up my PATH and LD_LIBRARY_PATH on my system [14:47] rjek: sorry, http://bazaar-vcs.org/BzrSvn [14:48] I don't understand why "./setup.py install --home ~/opt/foo" should be any different. [14:48] radix: I've not suggested that it should. [14:48] jelmer: Thanks, [14:48] It's _not_ any different from that. you're complaining that it doesn't do _more_ than the usual 'configure; make' dance because it's named differently. [14:48] at least that's my understanding of what you've been saying. [14:48] Erm. [14:49] I'm saying `./configure --prefix=~/opt/foo && make install` yeilds something that just works, and `./setup.py install --home ~/opt/foo` does not. [14:49] ok, I don't get it. how does that work? [14:50] radix: rjek's point is rewriting the bzr script at install time. [14:50] LarstiQ: yes, I understand that feature request [14:50] but "./configure; make install" never made that just work for software I've installed [14:50] rjek: "./configure --prefix=~/opt/foo && make install" doesn't work either in a lot of cases [14:50] For pure apps it would. [14:50] for apps which contains libraries, it may not [14:50] heh, "pure". yes, right [14:50] depending on what the app does wrt. building hard paths into its link [14:51] I can't think of an application I've installed that way that didn't work. [14:51] so yes, if it's only a binary, and you absolutely specify the binary, it'll run the app [14:51] rjek: any app which exposes most of its functionality through a library which the main binary links with [14:51] I've dealt with some recently, actually [14:52] I don't give a toss if it exposes a library - I'm wanting to install bzr to use bzr :) [14:52] * Odd_Bloke notes that "echo PYTHONPATH=$HOME/opt/foo/lib/python:$PYTHONPATH >> ~/.bashrc" would have been much quicker than this conversation. :) [14:52] rjek: yes, I understand that, and bzr should be wonderfully awesome and easy to use [14:52] Odd_Bloke: Not for someone who didn't know how. [14:52] radix: Your sarcasm suggests that it's not important for bzr to be easy to use. [14:52] * Kinnison thinks that having the setup.py somehow modify the incoming bzr driver script to stuff the right pythonpath on the front wouldn't be *too* hard [14:53] I also don't give a toss when I'm using an application that has 'configure; make' and it doesn't work, which actually happens === sdboyer is now known as sdboyer|at_work [14:53] * rjek sighs. [14:53] :( [14:53] * Kinnison looks on, distinctly unimpressed [14:53] never mind, eh? [14:53] Well, we could have handled that better. [14:54] yeah, sorry. [14:54] I'm trying to make amends. [14:54] radix: thanks. [14:57] Interestingly we already put this effort in for Windows [14:57] we create a customised bzr.bat [14:58] ok, I think I've proven to him that I'm way more of an ass than anyone else here [14:58] :-) [14:58] and, now I'm filing a bug about the problem [14:59] < ubottu> Launchpad bug 250789 in bzr "radix is an ass" [Undecided, New] [14:59] ^_^ [14:59] Launchpad bug 250789 in bbs2ch "旧仕様の定数値を参照している" [Undecided,New] https://launchpad.net/bugs/250789 [15:00] that's "radix is an ass" in Japanese [15:00] "radikusu issu an assu" [15:06] bug #250826 (or does the bot automatically find new bugs?) [15:06] Launchpad bug 250826 in bzr "setup.py should rewrite bin script when installed to a non-standard location so it can be run without specifying PYTHONPATH" [Undecided,New] https://launchpad.net/bugs/250826 [15:31] Yay, I restarted Loggerhead with only 0.994 seconds of downtime. :) [15:42] hello [15:43] i tried to install bzr in freebsd from sources but the command bzr is not found [15:43] any idea what might be wrong? [15:43] The 'bzr' script isn't in your PATH? [15:43] this is possible [15:43] wouldn't the installer do that? [15:44] You did a "setup.py install"? Its output should say where it went. [15:44] ah [15:44] hmm, it shows site-packages [15:44] Well, it went in the same directory as "python" is in, unless you told it not to. [15:45] ah [15:45] Stavros_: That's bzrlib, not the "bzr" script. [15:45] indeed, i'm looking for the script [15:45] it turns out that it works in bash [15:47] thanks [15:52] * Kinnison attaches a possible fix bundle to https://bugs.launchpad.net/bzr/+bug/250826 [15:52] Launchpad bug 250826 in bzr "setup.py should rewrite bin script when installed to a non-standard location so it can be run without specifying PYTHONPATH" [Undecided,New] [15:52] * Kinnison goes back to work now [16:14] mwhudson: ping [16:15] rjek, radix, Odd_Bloke: Of course, even easier is to just do [16:15] py setup.py build_ext -i [16:15] ln -s ~/bin/bzr $PWD/bzr [16:16] I think I have the order backwards there [16:16] but you get my idea [16:16] :) [16:17] ah, because it does the magic when it knows its in a development environment? [16:18] radix: no because python always imports from the local directory of the script [16:18] arguably, *python* does the magic [16:18] yeah, but the bzr script isn't in the same place that bzrlib is, right? [16:18] or maybe it is [16:18] I thought it was in a 'bin' or 'scripts' directory or something [16:19] oh, there it is [16:22] jam: But that's not the instructions we specify in INSTALL [16:22] * Kinnison has punted a patch to the bug [16:22] it's not ideal (lacks NEWS etc) but it does the job I think [16:27]