[00:13] <mwhudson> hm
[00:14] <mwhudson> why are the only calls to bzrdir.clone() with preserve_stacking=True in the branch_implementations tests?
[00:14] <mwhudson> hm
[00:14] <mwhudson> i guess a branch is certainly involved if there is stacking going on
[00:19] <lifeless> mwhudson: push --stacked uses clone, no ?
[00:19] <mwhudson> lifeless: i guess i should have inserted the word 'direct' into my sentence somewhere
[00:19] <spiv> "Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)" :)
[00:20] <mwhudson> spiv: and the format is actually development1 ?
[00:20] <spiv> mwhudson: no, it actually is one of those
[00:20] <mwhudson> ok
[00:20] <mwhudson> spiv: https://bugs.edge.launchpad.net/bzr/+bug/250422
[00:20] <mwhudson> spiv: instant thoughts?
[00:24] <spiv> mwhudson: "that sounds like a bug"
[00:24] <mwhudson> spiv: i'm glad you think so
[00:24] <spiv> mwhudson: A -Dhpss trace might be interesting.
[00:25] <spiv> mwhudson: a wild guess is that RemoteRepository doesn't look at the stacking policy?
[00:26] <lifeless> I din't want to invent ftp
[00:26] <lifeless> so the client is meant to resolve $shit
[00:27] <mwhudson> spiv: the problem is that i don't know which piece is _supposed_ to look at the stacking policy
[00:27] <mwhudson> i guess i should read through cmd_push
[00:33] <lifeless> so I'm thinking for marks
[00:39] <spiv> mwhudson: me either :)
[00:41] <mwhudson> hmmmm
[00:44] <mwhudson> spiv: the problem seems like it might be RemoteBzrDir.get_config not doing the right thing
[00:49] <spiv> mwhudson: I can certainly believe that.
[00:49] <mwhudson> spiv: i commented on the report
[00:50] <spiv> mwhudson: if you implement a "def get_config(self): self._ensure_real(); return self._real_bzrdir.get_config()" does that fix it?
[00:50] <mwhudson> spiv: let's find out
[00:51] <mwhudson> spiv: no
[00:52] <mwhudson> though, um
[00:52] <mwhudson> spiv: if you add it to the right class, yes, that seems to help
[00:52] <mwhudson> :)
[00:54] <spiv> mwhudson: that's good to know.  Send a patch to the list :)
[00:54] <mwhudson> spiv: where should a test go?
[00:56] <mwhudson> er
[00:56] <mwhudson>         config = my_dir.get_config()
[00:56] <mwhudson>         if config is None:
[00:56] <mwhudson>             self.assertFalse(isinstance(my_dir, bzrdir.BzrDirMeta1))
[00:56] <mwhudson>             raise TestNotApplicable(
[00:56] <mwhudson>                 'This BzrDir format does not support configs.')
[00:56]  * mwhudson objects, furiously
[00:56] <lifeless> IsNotInstance ?
[00:56] <lifeless> hmm, I want a composer
[00:57] <spiv> lifeless: I suggest Bach
[00:57] <lifeless> EDEAD
[00:58] <lifeless> in this regard, I'm a vitalist
[00:59] <mwhudson> so what are BzrDirFormat5 and BzrDirFormat6 ?
[00:59] <lifeless> bzr 0.5 and 0.6
[00:59] <lifeless> they are all-in-one formats
[01:01] <mwhudson> so caring about them is not at all encouraged?
[01:01] <lifeless> we upgrade from them
[01:02] <lifeless> 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] <mwhudson> ok cool
[01:05] <lifeless> that test wants a whitelist not a blacklist because of e.g. bzr-svn etc
[01:05] <lifeless> its an /interface/ test not an implementation test.
[01:08] <ppires> hi :-)
[01:08] <mwhudson> lifeless: whitelist as in "these formats are allowed to not do get_config" ?
[01:09] <lifeless> 09:56 < mwhudson>             self.assertFalse(isinstance(my_dir, bzrdir.BzrDirMeta1))
[01:09] <lifeless> thats a whitelist
[01:09] <lifeless> these formats are required to do it
[01:09] <mwhudson> oh, ok
[01:09] <lifeless> ppires: hi
[01:10] <lifeless> 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] <mwhudson> lifeless: right, fair enough
[01:10] <ppires> do i need bzr installed in order to use something like bzr-eclipse plug-in?
[01:11] <lifeless> ppires: yes
[01:11] <lifeless> ppires: there is a faq for installing bzr-eclipse
[01:12] <ppires> yes there is lifeless, but as i'm having some issues with the plug-in itself just wanted to double check. thanks
[01:12] <lifeless> Verterok: ^
[01:12] <lifeless> Verterok is the author
[01:12] <mwhudson> lifeless: it wasn'
[01:13] <mwhudson> 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] <lifeless> mwhudson: I don't actually know what it does offhand :P
[01:13] <mwhudson> though i guess set_default_stacked_on is part of the config interface...
[01:17] <jelmer> lifeless: it returns an object that converts some svn file properties to bzr settings
[01:17] <bob2> 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] <jelmer> in particular the mergeWithUpstream property used by svn-buildpackage, which is convert to the equivalent for bzr-builddeb
[01:18] <mwhudson> hmm
[01:18]  * mwhudson appears to be unable to drive send
[01:18] <jelmer> mwhudson: why does that matter?
[01:18] <mwhudson> bzr send -o- produces something reasonable
[01:19] <mwhudson> but 'bzr send' doesn't attach anything to the mail
[01:19] <Verterok> lifeless: thanks
[01:19] <mwhudson> jelmer: because of the way the test for bzrdir.get_config() is written
[01:20] <Verterok> ppires: if you have any issues with the plugin, maybe I can help
[01:21] <lifeless> Verterok: I demoed bzr-eclipse at lugradio live too FWIW
[01:21] <Verterok> ppires: also I'm going to release a new build in the next few days (hope I can get it for tomorrow)
[01:21] <Verterok> lifeless: yay! :)
[01:22] <ppires> hi Verterok i'm here looking how to install plug-ins. http://bazaar-vcs.org/UsingPlugins is not very clear about it
[01:22] <ppires> i mean, they talk about folders, but not how to install them. should they be compiled somehow?
[01:23] <Verterok> ppires: which OS?
[01:23] <ppires> http://bazaar-vcs.org/XMLOutput only offers the source-code.
[01:23] <ppires> Linux, Ubuntu 8.04 to be more precise
[01:24] <Verterok> ppires: bzr branch lp:bzr-xmloutput/0.4 $HOME/.bazaar/plugins/xmloutput
[01:24] <Verterok> ppires: that should do the trick :)
[01:24] <mwhudson> is there a convention for including bug numbers in merge requests?
[01:24] <Verterok> ppires: or you could do a checkout:  bzr co lp:bzr-xmloutput/0.4 $HOME/.bazaar/plugins/xmloutput
[01:25] <ppires> lp is a shortcut to launchpad?
[01:26] <spiv> Yep.
[01:26] <ppires> cool!
[01:26] <lifeless> bye guys
[01:27] <ppires> Verterok: i'm using eclipse ganymede (3.4) and bzreclipse leaves some "unable to staisfy dependency" in the Error log
[01:28] <igc> morning
[01:28] <Verterok> ppires: I'm not sure if it works with 3.4, let me check (I'm still with 3.3)
[01:29] <Verterok> mornin' igc
[01:29] <igc> hi Verterok
[01:30] <ppires> i cannot reach "Console" and "Decorators" tabs. eclipse complains about invalid values
[01:30] <ppires> bye lifeless and thanks
[01:31] <ppires> morning igc
[01:31] <Verterok> ppires: you must configure the location of the bzr executable
[01:32] <Verterok> ppires: in the "Bazaar" pref. page
[01:32]  * Verterok launching Eclipse 3.4
[01:32] <mwhudson> spiv: sent to the list
[01:40] <Verterok> ppires: I can't even start 3.4 :( (I think I should download the final release :P )
[01:40] <ppires> you were right Verterok
[01:41] <Verterok> ppires: it's working? if not, could you pastebin the error?
[01:41] <ppires> eheh, i'm running the latest stable release
[01:42] <ppires> Verterok: this is a lamme question, but are Decorators the ability to mark graphically resources like files?
[01:42] <ppires> and folders..
[01:43] <spiv> mwhudson: thanks
[01:43] <Verterok> ppires: yes, to show the status of the file/folder/project
[01:44] <ppires> ok, i answered this one and i was in doubt. https://bugs.launchpad.net/bzr-eclipse/+bug/160907
[01:45] <ppires> wow cool bot!
[01:46] <Verterok> ppires: right, the files/folders are flagged with the db-like orange icon (like in the CVS plugin)
[01:47] <ppires> never used cvs. anyway, Verterok does this plug-in support bzr+ssh?
[01:48] <Verterok> ppires: it should, because it uses bzr to execute the commands
[01:49] <ppires> i'm not used to bzr that's why this may sound a bit confusing to me.
[01:49] <Verterok> ppires: be carefull with the authentication, check Bug #121936
[01:52] <ppires> ic, tks!
[01:52] <Verterok> ppires: for workaround until I fix it, look the Authentication section in http://bazaar-vcs.org/BzrEclipse/Installation
[01:52] <ppires> now i'm going for bed. work tomorrow. tks a lot Verterok! i'll keep in touch ;-)
[01:53] <Verterok> 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] <cody-somerville> +
[02:08]  * emgent thinking to sleep.
[02:40] <mwhudson> 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
[05:47] <mwhudson> huh how bizaare
[05:48] <mwhudson> beuno: still here?
[05:48] <beuno> mwhudson, yeap
[05:48] <beuno> despite my ISPs attempt to make me got to sleep
[05:48] <mwhudson> i have this pair of branches where merging a into b gives 'nothing to do' and merging b into a gives conflicts
[05:48] <mwhudson> wtf??
[05:55] <mwhudson> what now?? http://pastebin.ubuntu.com/29210/
[05:56] <mwhudson> what now?? http://pastebin.ubuntu.com/29210/
[06:15] <spiv> mwhudson: that's an unexpected traceback.
[06:15] <mwhudson> yeah
[06:15] <spiv> It makes about as little sense to me as it does you :
[06:15] <spiv> :)
[06:16] <mwhudson> it happens with the installed 1.6b3, not bzr.dev
[06:16] <mwhudson> i guess it's a circular import
[06:17] <mwhudson> and one of my plugins happens to import branch earlier or something
[06:17] <mwhudson> spiv: does it happen for you?
[06:17] <mwhudson> it's very quick, obviously, before even the check that '.' is a branch
[06:18] <spiv> mwhudson: nope, but I only have bzr.dev
[06:19] <mwhudson> 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] <mwhudson> one of you guys has to change his name, i think
[06:56] <spm> mwhudson: put forward the request in #canonical-sa's?
[06:57] <mwhudson> spm: maybe
[07:02] <kiorky> jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/250706
[07:33] <jml> I want a programming language / refactoring tool / editor / vcs that understands itself.
[07:33] <jml> and a pony.
[07:35] <spiv> A self-aware pony?
[07:36] <jml> maybe.
[07:37] <jml> It's hard to say. I so rarely use ponies to make changes to things.
[07:38] <mwhudson> jml: i'm sure you can still get a LispM from somewhere
[07:39] <jml> mwhudson: do you reckon they'd integrate with my freerunner?
[07:39] <mwhudson> jml: they would probably destroy it quite thoroughly if they fell on it
[07:39] <jml> haha
[07:39] <jml> freedom prevails.
[07:40] <mwhudson> my word, you can still buy genera
[07:42] <mwhudson> or pirate it, apparently: http://www.advogato.org/person/johnw/diary/12.html
[07:52]  * mwhudson wallows in computing nostalgia
[07:53] <jml> mwhudson: heh
[07:54] <mwhudson> on http://en.wikipedia.org/wiki/HyperCard now
[07:54] <jml> 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] <mwhudson> jml: someone has been talking about this sort of thing on the rope-dev mailing list recently i think
[07:55] <jml> mwhudson: glyph mentions this sort of thing from time to time.
[07:55] <jml> oh wow. rope isn't brm.
[07:56] <mwhudson> 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] <jml> *nod*
[07:56] <mwhudson> yeah, rope looks a little interesting
[07:56] <mwhudson> but, sigh, time
[07:56] <bob2> wonder what "Mercurial, GIT and SVN (pysvn library) support in refactorings" means
[07:57] <mwhudson> also i entirely failed to get ropemacs to work at all last time i used it
[09:58] <kiorky> jelmer_: for the auth problem, somehow some branch.conf werent wearing the good url, fixing it fixes auth cache.
[09:59] <kiorky> jelmer_: can we use svn urls and rely on svn cache, without having to put url with creds inside ?
[09:59] <kiorky> jelmer_: i mean urls in the branch.conf
[10:23] <poolie> night
[10:25] <Peng_> Good night.
[10:45] <colbrac> 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] <colbrac> ult_location() don't need a lock?
[10:46] <colbrac> * the mentioned set_push_location()
[11:06] <Peng_> 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] <colbrac> 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] <Peng_> I think many operations take out locks themselves and some require you to do it, but I don't know.
[11:28] <Pieter> Does Bazaar have something like Git's merge diff view?
[11:32] <Jc2k> what is special about gits merge diff view o_O
[11:32] <Jc2k> i've never seen it
[11:32] <Pieter> it shouws two columns of ++'s
[11:39] <Pieter> as with http://ss.frim.nl/==814 for example
[11:41] <Jc2k> no idea personally
[11:41] <Jc2k> is that a gitk feature, or a git feature?
[11:41] <Jc2k> (can i do it in a shell)
[11:41] <Pieter> git feature
[11:42] <Pieter> gitk just adds some colors
[11:42] <james_w> is that the same as "git diff --cc" ?
[11:44] <Pieter> more like -c, I think
[11:44] <Pieter> but it's the same as "git show <merge>"
[11:44] <james_w> I don't think we have that, would you care to file a bug?
[11:45] <james_w> I think it would be good to have for those that want it.
[11:45] <Pieter> sure
[11:46] <james_w> 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] <Pieter> igc: your merge seems fine, and git-bzr still works as first :)
[11:47] <igc> Pieter: ok, thanks for the test
[11:49] <mwhudson> there is merge --preview, is that anything like the git feature?
[11:50] <Pieter> I don't know.. can I use it on an existing merge?
[11:51] <james_w> mwhudson: I don't think so.
[11:51] <mwhudson> ok
[11:52] <james_w> I think the git feature allows you to attribute changes to each side of the merge.
[11:52] <igc> night all
[11:52] <james_w> night igc
[12:06] <Pieter> james_w: #250783
[12:06] <james_w> thanks
[12:24] <mark1> 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?
[12:24] <Odd_Bloke> Moin.
[12:31] <Odd_Bloke> markh: Possibly.  What are the questions? :)
[12:32] <markh> 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] <markh> so the question is "what am I missing?" :)
[12:33] <markh> 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] <markh> actually, I think I know...
[12:37] <markh> I did "bzr merge ..\orig_branch\filename.py"
[12:37] <markh> I imagine I needed to do lots of individual "merge -r ..." commands to get what I was after
[12:38] <markh> manually extract them from the log I guess...
[12:39] <Odd_Bloke> 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 <filename>'.
[12:44] <jelmer> kiorky: bzr-svn already uses the svn cache but it doesn't write to it
[12:46] <markh> 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] <markh> 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] <Peng_> (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] <jamesh> 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] <jamesh> 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] <LarstiQ> oh hey, loom, I forgot that as a solution.
[12:51] <markh> yeah, but often working towards one feature means editing 4 files - which logically break down as 2 patches for review
[12:52] <markh> 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] <jamesh> 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] <markh> a patch is obviously fine, but a bundle seems hard
[12:52] <markh> yeah - I'm not familiar with loom yet :(
[12:53] <jamesh> start with two threads: the upstream trunk and your combined branch
[12:53] <jamesh> create a thread in between them for the first change, moving the relevant work down from the top thread
[12:53] <jamesh> then merge up again (which should be a null merge due to the changes already being present)
[12:53] <jamesh> repeat until you're finished and discard the top thread
[12:54] <markh> thanks for the tip!  I'll have a read up on it...
[12:56] <Odd_Bloke> markh: Shelve from bzrtools would also allow you to do something like this (shelve one reviewable set of changes, commit, unshelve, commit).
[13:02] <markh> 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] <markh> shelve is closer to mercurials "queues" iirc?
[13:03] <Odd_Bloke> I'm not sure, but it does sound like looms would work better for you. :)
[13:04] <LarstiQ> markh: from my understanding, you would do one merge -r range for each range you want to include in the logical patch
[13:04] <Peng_> Shelves aren't the same thing as mq.
[13:04] <markh> LarstiQ: hi!  and commit each one?
[13:04] <markh> bugger :)
[13:05] <Peng_> Shelve is just for letting you temporarily remove changes from the working tree, and then put them back.
[13:05] <LarstiQ> markh: you could do that if you wanted that granularity, or just commit one thing if that is ok to you
[13:05] <Peng_> You could probably use it as a really poor man's mq, but not very well.
[13:05] <Peng_> (Since you can have multiple different shelves.)
[13:06] <bob2> what are queues more like then?  looms? branches?
[13:06] <markh> 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] <LarstiQ> 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] <LarstiQ> markh: correct.
[13:07] <LarstiQ> markh: well, content changes even, it doesn't bring across revisions.
[13:07] <markh> I guess I meant "and commit messages" :)
[13:07] <LarstiQ> markh: untill someone makes it so that cherry picks get recorded fully.
[13:08] <markh> 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] <LarstiQ> 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] <LarstiQ> 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] <LarstiQ> in my current knowledge, for that workflow
[13:10] <LarstiQ> looms might be better
[13:10] <LarstiQ> markh: not sure if the foreach plugin would help there
[13:10] <markh> would that include the original author of the patch?
[13:11] <LarstiQ> markh: no, it would take as committer whatever is set for the one doing the new commits.
[13:11] <LarstiQ> could be done too of course
[13:11] <markh> 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] <LarstiQ> but I have to get back to my exercises with ambigous notation :/
[13:12] <markh> no probs - thanks!
[13:12] <LarstiQ> markh: the "real" solution is making cherry picks record the fact.
[13:12] <markh> (in my case, for my recent patch, bzr-orthogonal-patches.html is actually a better answer - I'm just curious)
[13:12] <LarstiQ> imo.
[13:12] <markh> LarstiQ: right - just making sure I understand things as they are now - its all getting clearer each day :)
[13:13] <LarstiQ> markh: I'm not well versed enough in looms to answer that unfortunately.
[13:14] <LarstiQ> 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] <LarstiQ> markh: did I tell you I had gotten python-nautilus running?
[13:16] <LarstiQ> pygi: you were still going to tell me about Novell's plans on nautilus integration btw.
[13:16] <markh> no!  I also found myself cringing at some windows specifics I forgot about when taling to you :(
[13:18] <markh> 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] <LarstiQ> 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] <LarstiQ> markh: oooh
[13:18] <LarstiQ> markh: have fun, and I look forward to checking out the qbzr stuff :)
[13:20] <pygi> LarstiQ, you must be joking :)
[13:40] <Pilky> Looking at qbzr has really made me want to start working on BazaarX again
[13:40] <Pilky> I just need to find the time from somewhere
[14:33] <rjek> Hi.
[14:34] <rjek> 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] <rjek> (well, it does find bzrlib, just the ancient one that's installed system-wide)
[14:39] <rjek> Additionally, is it the case that the current stable bzr-svn requires a non-stable release of bzr to run?
[14:39] <rjek> 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] <rjek> (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] <Odd_Bloke> rjek: Try prefixing the bzr command with 'PYTHONPATH=~/opt/bzr-1.5/lib/python:$PYTHONPATH'
[14:41] <rjek> 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] <Odd_Bloke> rjek: Well, if you installed anything in a non-standard location, expecting it to 'just work' is optimistic.
[14:43] <rjek> Not when there's an install script!
[14:44] <rjek> 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] <jelmer> rjek: you need a released version of bzr-svn for bzr 1.5
[14:44] <rjek> I was kinda expecting a tool called "setup" to set it up for use, rather than just copying it somewhere.
[14:45] <Odd_Bloke> 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] <rjek> Odd_Bloke: Quite.  However, rewriting a bit of the (trivial) bzr launcher script it puts in bin/ seems like an ideal approach.
[14:46] <rjek> 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] <radix> 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] <rjek> 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] <radix> (i.e., make install)
[14:46] <rjek> Yes.  And in general, they do.
[14:46] <jelmer> rjek: It's on the bzr-svn wiki page, http://bazaar-vcs.org/bzr-svn
[14:47] <radix> not if you specify a prefix like ~/opt/bzr-1.5
[14:47] <rjek> jelmer: That page doesn't exist.
[14:47] <rjek> radix: `./configure --prefix=~/opt/foo && make install` almost always works.
[14:47] <radix> 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] <jelmer> rjek: sorry, http://bazaar-vcs.org/BzrSvn
[14:48] <rjek> I don't understand why "./setup.py install --home ~/opt/foo" should be any different.
[14:48] <rjek> radix: I've not suggested that it should.
[14:48] <rjek> jelmer: Thanks,
[14:48] <radix> 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] <radix> at least that's my understanding of what you've been saying.
[14:48] <rjek> Erm.
[14:49] <rjek> 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] <radix> ok, I don't get it. how does that work?
[14:50] <LarstiQ> radix: rjek's point is rewriting the bzr script at install time.
[14:50] <radix> LarstiQ: yes, I understand that feature request
[14:50] <radix> but "./configure; make install" never made that just work for software I've installed
[14:50] <jelmer> rjek: "./configure --prefix=~/opt/foo && make install" doesn't work either in a lot of cases
[14:50] <Kinnison> For pure apps it would.
[14:50] <Kinnison> for apps which contains libraries, it may not
[14:50] <radix> heh, "pure". yes, right
[14:50] <Kinnison> depending on what the app does wrt. building hard paths into its link
[14:51] <rjek> I can't think of an application I've installed that way that didn't work.
[14:51] <radix> so yes, if it's only a binary, and you absolutely specify the binary, it'll run the app
[14:51] <radix> rjek: any app which exposes most of its functionality through a library which the main binary links with
[14:51] <radix> I've dealt with some recently, actually
[14:52] <rjek> 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] <radix> rjek: yes, I understand that, and bzr should be wonderfully awesome and easy to use
[14:52] <Kinnison> Odd_Bloke: Not for someone who didn't know how.
[14:52] <rjek> 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] <radix> 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
[14:53]  * rjek sighs.
[14:53] <radix> :(
[14:53]  * Kinnison looks on, distinctly unimpressed
[14:53] <Kinnison> never mind, eh?
[14:53] <LarstiQ> Well, we could have handled that better.
[14:54] <radix> yeah, sorry.
[14:54] <radix> I'm trying to make amends.
[14:54] <LarstiQ> radix: thanks.
[14:57] <Kinnison> Interestingly we already put this effort in for Windows
[14:57] <Kinnison> we create a customised bzr.bat
[14:58] <radix> ok, I think I've proven to him that I'm way more of an ass than anyone else here
[14:58] <Kinnison> :-)
[14:58] <radix> and, now I'm filing a bug about the problem
[14:59] <Odd_Bloke> < ubottu> Launchpad bug 250789 in bzr "radix is an ass" [Undecided, New]
[14:59] <Odd_Bloke> ^_^
[15:00] <radix> that's "radix is an ass" in Japanese
[15:00] <radix> "radikusu issu an assu"
[15:06] <radix> bug #250826 (or does the bot automatically find new bugs?)
[15:31] <Peng_> Yay, I restarted Loggerhead with only 0.994 seconds of downtime. :)
[15:42] <Stavros_> hello
[15:43] <Stavros_> i tried to install bzr in freebsd from sources but the command bzr is not found
[15:43] <Stavros_> any idea what might be wrong?
[15:43] <Peng_> The 'bzr' script isn't in your PATH?
[15:43] <Stavros_> this is possible
[15:43] <Stavros_> wouldn't the installer do that?
[15:44] <Peng_> You did a "setup.py install"? Its output should say where it went.
[15:44] <Stavros_> ah
[15:44] <Stavros_> hmm, it shows site-packages
[15:44] <Peng_> Well, it went in the same directory as "python" is in, unless you told it not to.
[15:45] <Stavros_> ah
[15:45] <Peng_> Stavros_: That's bzrlib, not the "bzr" script.
[15:45] <Stavros_> indeed, i'm looking for the script
[15:45] <Stavros_> it turns out that it works in bash
[15:47] <Stavros_> thanks
[15:52]  * Kinnison attaches a possible fix bundle to https://bugs.launchpad.net/bzr/+bug/250826
[15:52]  * Kinnison goes back to work now
[16:14] <jam> mwhudson: ping
[16:15] <jam> rjek, radix, Odd_Bloke: Of course, even easier is to just do
[16:15] <jam> py setup.py build_ext -i
[16:15] <jam> ln -s ~/bin/bzr $PWD/bzr
[16:16] <jam> I think I have the order backwards there
[16:16] <jam> but you get my idea
[16:16] <jam> :)
[16:17] <radix> ah, because it does the magic when it knows its in a development environment?
[16:18] <jam> radix: no because python always imports from the local directory of the script
[16:18] <jam> arguably, *python* does the magic
[16:18] <radix> yeah, but the bzr script isn't in the same place that bzrlib is, right?
[16:18] <radix> or maybe it is
[16:18] <radix> I thought it was in a 'bin' or 'scripts' directory or something
[16:19] <radix> oh, there it is
[16:22] <Kinnison> jam: But that's not the instructions we specify in INSTALL
[16:22]  * Kinnison has punted a patch to the bug
[16:22] <Kinnison> it's not ideal (lacks NEWS etc) but it does the job I think
[16:27] <jam> radix: no, some of the other canonical projects (like PQM) use a 'bin', but bzr does not
[16:27] <jam> Kinnison: yeah, I commented on it already
[16:27] <radix> Kinnison: thanks
[16:28] <Kinnison> jam: I wonder where the mail from LP is then :-(
[16:28]  * Kinnison pokes dejectedly at his maildir
[16:30] <jam> Kinnison: lp delays emails for a few minutes
[16:30] <Kinnison> oh
[16:30] <jam> because sometimes you make multiple changes
[16:30] <jam> and it wants to batch them together
[16:32] <Kinnison> fair enough
[16:32]  * Kinnison has responded to your comment anyway
[16:33] <slangasek> supposing I have created a bzr repo using bzr cvsps-import
[16:33] <slangasek> and I now want to push the lot to a public server
[16:33] <slangasek> what's the best way to do that?
[16:38] <slangasek> (noting also that this is a live CVS repo, so I don't intend this to be a one-time import; so I need to stow it in such a way that I don't lose any other branches that I add over time)
[17:01] <LarstiQ> slangasek: does cvsps-import create multiple branches?
[17:01] <slangasek> yes
[17:02]  * pickscrape is migrating his IT department from svk to bzr *tonight*
[17:03]  * pickscrape stresses
[17:05] <kiorky> uhm, is that possible to pull changes from smoewhere but without updating the working copy yet, like with hg pull
[17:06] <LarstiQ> slangasek: the repo-push plugin?
[17:08] <slangasek> LarstiQ: well, I think my larger concern is not "how do I push it?", but "how should I lay things out so that the cvsps imported branches co-exist with my bzr-only branches?"
[17:09] <Pilky> do people know that the bzr website seems to be messed up?
[17:10] <jam> kiorky: generally no, though if you have a shared repository you can
[17:10] <jam> cd ..
[17:10] <jam> bzr branch OTHER_PERSONS_STUFF
[17:10] <jam> and then you'll have it locally but not merged
[17:10] <Pilky> as it seems to be showing a bunch of directories for users rather than the site itself
[17:11] <jam> Pilky: yeah, the wiki seems to be down
[17:11] <jam> I'll ask
[17:11] <LarstiQ> Pilky: hmm, non frontpage still seems to work
[17:12] <pickscrape> Down for me
[17:12] <Pilky> ah, back up now
[17:12] <pickscrape> Yep
[17:12] <jam> yeah, back up now
[17:13] <LarstiQ> slangasek: I have no cvsps experience, how would they not co-exist?
[17:14] <dash> hi. anybody know of a guide for getting started with bzrlib? i'm looking at the api docs now, just wondering if there's some description of good starting points for common tasks
[17:15] <pickscrape> dash: this has become my bible: http://bazaar-vcs.org/Integrating_with_Bazaar
[17:16] <dash> thanks!
[17:16] <dash> that looks exactly like what I want. :)
[17:16] <pickscrape> dash: along with this: http://starship.python.net/crew/mwh/bzrlibapi/moduleIndex.html
[17:32] <pygi> pickscrape, aha, I found a bug on the page!
[17:32]  * pygi hides
[17:36] <pickscrape> :)
[17:36] <pickscrape> I think I was told it was a bit out of date when I was first pointed at it
[17:36] <pickscrape> What bug did you find?
[17:36] <pickscrape> I wish it explained more (i.e. something) about locking.
[17:37] <slangasek> LarstiQ: cvsps-import creates a "Bazaar-NG meta directory, format 1".  If I add my own branches inside of that tree, will future cvsps-import runs clobber them?  And if I don't, will I have inferior performance?
[17:38] <slangasek> if nothing else, I can take the cvsps-imports and stick them in an "upstream" tree on my server, and build a "debian" tree next to it
[17:41] <LarstiQ> pickscrape: individual functions will try to take out a lock when they need to, but there are cases where it is better to take out a lock yourself.
[17:41] <is_null> hello everybody, is it possible to track a remote subversion repository in a subfolder, and branch it? I'd like to track the framework used in an application and be able to maintain a branch of it
[17:42] <pygi> pickscrape, a missing ")" :P
[17:43] <LarstiQ> slangasek: the meta directory doesn't tell me much, but assuming it is a repository you can add your own branches under that, I'm fairly confident to say cvsps-import will not clobber even if I don't know it.
[17:43] <slangasek> LarstiQ: ok, guess I'll test :)
[17:43] <LarstiQ> slangasek: but you could add your own branches under repo/vorlon for example, I doubt it will touch that :)
[17:44] <LarstiQ> is_null: part of what you want to do sounds like bzr-svn
[17:44] <pickscrape> LarstiQ: yes, I was aware of commands taking the lock themselves. However, I'm not sure sure about what when it is better to do the locking yourself.
[17:44] <slangasek> LarstiQ: ok, confirmed that it doesn't clobber it, thanks
[17:45] <is_null> LarstiQ, i've read this: http://bazaar-vcs.org/BzrForeignBranches/Subversion but it doesn't say about tracking *in* a subfolder of the bzr repo
[17:45] <slangasek> LarstiQ: now, the question is whether that's the layout I /want/, since everything imported by cvsps-import has rather ugly names, and I'm thinking it might be nice to have that off in its own namespace :)
[17:46] <is_null> now i've read the faq as well ;)
[17:47] <LarstiQ> slangasek: right, that might be done by cvsps, no clue :/
[17:48] <slangasek> ?
[17:48] <LarstiQ> is_null: well, you would convert the svn branch into a bzr one first, and then track a bzr branch normally (if that worked, sigh)
[17:48] <LarstiQ> slangasek: bzr cvsps-import --layout-as-i-want
[17:48] <slangasek> LarstiQ: er, heh
[17:49] <LarstiQ> slangasek: you have by far more cvsps knowledge than I by now though, so :)
[17:49] <slangasek> LarstiQ: I'm pretty much stuck with the CVS tag and branch names if I want to be able to use it, so I would argue that the ugliness is inherent :)
[17:49] <is_null> LarstiQ, i mean, can bzr track the svn branch in a sub-directory of the bzr repo?
[17:49] <is_null> like git-submodule (which does not support svn)
[17:50] <slangasek> is_null: 'bzr join'
[17:50] <slangasek> is_null: I think that's what you're after
[17:50] <slangasek> it's good and evil :)
[17:50] <LarstiQ> is_null: in bzr terms, a repository and a branch are different things.
[17:50] <LarstiQ> is_null: I don't know what git-submodule does.
[17:51] <LarstiQ> is_null: but tracking a svn branch by having a bzr branch in a bzr repo is no problem at all, I just think you are using different terminology.
[17:51] <is_null> LarstiQ, bzr repo: /myapp, svn repo: svn://foo, i'd like to track svn://foo in /myapp/framework
[17:52] <LarstiQ> is_null: is /myapp something you created with 'bzr init-repo'?
[17:52] <is_null> LarstiQ, yes
[17:52] <LarstiQ> is_null: ok, no problem then.
[17:52] <is_null> nice, thanks
[17:52] <LarstiQ> well, at least for the 'tracking in a subdir' part.
[17:52] <LarstiQ> is_null: it could be svn://foo does really funky stuff and bzr-svn will be need to taught that
[17:53] <LarstiQ> is_null: but give bzr-svn a try with svn://foo and let us know how it went
[17:54] <is_null> what package is bzr-svn part of?
[17:54] <LarstiQ> is_null: bzr-svn
[17:54] <LarstiQ> is_null: http://bazaar-vcs.org/BzrForeignBranches/Subversion
[17:54] <is_null> thanks again!
[18:05] <bartt5> When using bzr shelve in shell inside Emacs, the carriage-return isn't automatically added when pressing y, n. q, etc
[18:05] <bartt5> Does anyone now how to instruct Emacs to add a carriage-return in this case?
[18:25] <is_null> bzr-svn is not up to date with installed bzr version 1.6b3.
[18:25] <is_null> There should be a newer version of bzr-svn available.
[18:25] <is_null> bzr: ERROR: exceptions.ImportError: cannot import name make_file_knit
[18:26] <is_null> with bzr and bzr-svn from the gentoo overlay
[18:26] <LarstiQ> is_null: I think I saw someone mention before that there was something wrong with the gentoo overlay
[18:31] <LarstiQ> is_null: gentoo aside, I'd either match up bzr 1.5 and bzr-svn 0.4.10 (from memory, the page lists which version match), or go with bzr.dev and lp:bzr-svn/0.4
[18:31] <Peng_> LarstiQ: You're correct.
[18:31] <Peng_> (with those versions)
[18:32] <is_null> ok! thanks
[18:35] <is_null> same problem when trying to run tests: http://nopaste.com/p/a8I2lKBYG
[18:36] <is_null> with versions dev-util/bzr-1.5, dev-util/bzr-svn-0.4.10, dev-util/bzr-rebase-0.2
[18:37] <beuno> hrm, anyone know why I would be getting this: http://paste.ubuntu.com/29354/
[18:37] <LarstiQ> is_null: with bzr 1.5 and bzr-svn 0.4.10 you get a message complaining something doesn't match with _1.6b3_ ?
[18:38] <is_null> LarstiQ: http://nopaste.com/p/aghDKt9Mg
[18:39] <beuno> I moved around branches inside my shared repo, but I don't see why that would make it explode
[18:43] <LarstiQ> is_null: that is very weird. bzr-svn 0.4.10 has cache.py with CacheTable right there
[18:44] <LarstiQ> is_null: can you confirm /usr/lib64/python2.5/site-packages/bzrlib/plugins/svn/cache.py exists?
[18:45] <is_null> 07bd547b639ef507eb603dc85a342a04  /usr/lib64/python2.5/site-packages/bzrlib/plugins/svn/cache.py
[18:47] <LarstiQ> is_null: that is correct.
[18:48] <is_null> anything else i can do?
[18:50] <LarstiQ> is_null: you could run that with BZR_PDB=1 set, only helpful if you know python/pdb
[18:51] <LarstiQ> is_null: ah, hmm
[18:52] <LarstiQ> is_null: please do do that, and then type in 'import cache' 'p cache.__path__'
[18:54] <LarstiQ> is_null: I think I know what the problem is, namely there being a 'cache' module/package on sys.path that bzr-svn isn't expecting there. To be more precise, it is only expecting to be run from a bzr source tree I think.
[18:55] <is_null> LarstiQ, true
[18:55] <is_null> /usr/lib64/portage/pym/cache
[18:55] <LarstiQ> is_null: right
[18:55] <is_null> seems like a minor bug
[18:56] <LarstiQ> is_null: is this something that the gentoo packaging runs automatically?
[18:56] <is_null> LarstiQ, "this"?
[18:56] <LarstiQ> is_null: bzr-1.5 selftest svn
[18:57] <LarstiQ> is_null: or did you run it seperately yourself?
[18:57] <is_null> i do it, but the ebuild can do it as well, i'm not re-installing it each time
[18:58] <is_null> change from cache to: from bzrlib.plugins.svn.cache import CacheTable now a new problem: http://nopaste.com/p/aaUuwowFob
[18:58] <is_null> the same problem
[18:58] <LarstiQ> right, I expect more problems of the same sort
[18:58] <LarstiQ> is_null: so, two things.
[18:59] <LarstiQ> is_null: if you are interested in the results of running the tests, I suggest for that to cd to the bzr 1.5 sourcedir, and run ./bzr selftest svn
[18:59] <LarstiQ> is_null: for the larger problem, I think a bug filed against bzr-svn saying that its importing style is fragile in the face of same named modules on the path is fair.
[19:00] <LarstiQ> is_null: if you want to attach a patch to that bug, I don't think jelmer will have a problem with that ;)
[19:00]  * LarstiQ is called to dinner.
[19:00] <LarstiQ> is_null: I'll see how far you are when I get back.
[19:00] <is_null> LarstiQ, thanks a lot for you support!
[19:05] <is_null> now i have https://bugs.launchpad.net/bugs/246683 :)
[19:06] <slangasek> hum, anyone here know bzr-email?
[19:07] <slangasek> more to the point, does it actually work for anyone?
[19:07] <jelmer> is_null: you need a newer version of bzr-svn
[19:07] <jelmer> slangasek: yep
[19:07] <jelmer> slangasek: what's not working?
[19:07] <slangasek>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/email/smtp_connection.py", line 213, in send_text_and_attachment_email
[19:07] <slangasek> jelmer: that
[19:07] <jelmer> LarstiQ: the imports have already been fixed in bzr-svn's branch
[19:07] <slangasek>     assert isinstance(attachment_text, str)
[19:07] <slangasek> AssertionError
[19:08] <jelmer> slangasek: can't remember seeing that before; any chance you can file a bug?
[19:08] <slangasek> yep
[19:09] <james_w> slangasek: running under BZR_PDB=1 and getting type(attachment_text) would be useful
[19:09] <james_w> my guess is unicode
[19:11] <LarstiQ> jelmer: hmm, but there is no bzr-svn with those fixes compatible with bzr 1.5 is there?
[19:13] <slangasek> jelmer, james_w: bug #250901 filed; I'll try with BZR_PDB=1 on my next commit
[19:15] <jelmer> LarstiQ: only the one in Debian has them
[19:15] <jelmer> slangasek: thanks
[19:15] <slangasek> (Pdb) type(attachment_text)
[19:15] <slangasek> <type 'NoneType'>
[19:15] <slangasek> james_w: ^^
[19:16] <slangasek> anything else I should check before dropping out of the debugger?
[19:16] <is_null> jelmer, you ad
[19:16] <is_null> jelmer, you advice to use which version of svn, bzr and bzr-svn please?
[19:17] <jam> beuno: check your plugins for bug #250514
[19:17] <jam> beuno: sorry, bug #250893
[19:17] <jam> :)
[19:17] <jelmer> is_null: in general, I would recommend bzr 1.5 and bzr-svn 0.4.10
[19:17] <jam> beuno: at least, auditing the code here, everything looks like it should be fine
[19:18] <beuno> jam, I'll try with --no-plugins
[19:18] <jelmer> is_null: however since you're hitting those two bugs I would recommend bzr.dev and bzr-svn from the 0.4 branch in your case
[19:18] <beuno> jam, same with --no-plugins
[19:18] <is_null> jelmer, with svn 1.5.0?
[19:19] <jam> beuno: can you look at your /...pythonpath/site-packages/bzrlib/bundle/__init__.py file
[19:19] <jam> and see if read_mergeable_from_url takes possible_transports?
[19:19] <jam> It certainly does in bzr.dev
[19:19] <jelmer> slangasek: looks like this is a bug if no diff should be sent
[19:20] <jelmer> e.g. if difflimit = 0
[19:20] <slangasek> jelmer: well, I /want/ a diff to be sent; I thought difflimit = 0 meant unlimited
[19:20] <slangasek> :)
[19:20] <jam> beuno: my best guess after plugins is that the install packaging isn't properly overriding the bzrlib/bundle/ sub-package
[19:20] <jam> beuno: another thing to check is the timestamps on the __init__.py file and the __init__.pyc files
[19:21] <jam> if the .pyc is newer, it won't get rebuilt
[19:21] <slangasek> jelmer: btw, does anyone have a post-commit hook that will tag bugs 'pending' in the Debian BTS? :-)
[19:21] <beuno> jam,
[19:21] <beuno> lrwxrwxrwx 1 root root    45 2008-07-22 02:17 __init__.py -> /usr/share/pyshared/bzrlib/bundle/__init__.py
[19:21] <beuno> -rw-r--r-- 1 root root  2872 2008-07-22 02:17 __init__.pyc
[19:21] <jam> beuno: can you check: /usr/share/pyshared/bzrlib/bundle/__init__.py
[19:22] <jelmer> slangasek: not yet afaik, but I agree it would be nice to have such a thing :-)
[19:22] <jam> beuno: though it certainly looks like it is *today* :)
[19:22] <slangasek> damn, I just volunteered myself, didn't I
[19:22] <jam> beuno: and the contents of __init__.py ? does it have possible_transports?
[19:22] <beuno> jam, hm, no
[19:23] <jam> beuno: .... :(
[19:23] <jam> beuno: so, do you want to try uninstalling and re-installing?
[19:23] <beuno> and, surprise surprise, it has an older timestamp
[19:23] <jam> obviously something weird
[19:23] <beuno> I just did: setup.py install   in bzr.dev
[19:23] <jam> beuno: also, how do you have bzr 1.6b4 ?
[19:23] <jelmer> slangasek: :-)
[19:24] <beuno> shouldn't that overwrite everything?
[19:24] <jam> ah, but did you uninstal the system package first?
[19:24] <jam> beuno: I can't say how smart the python installer is
[19:24] <slangasek> jelmer: do you think this should be a feature of bzr-email, or a new post-commit hook?
[19:24] <jam> as debs verses setup.py install
[19:24] <beuno> jam, ah, I didn't
[19:24] <slangasek> (I guess I could just wrap the 'bts' command...)
[19:24] <jam> beuno: kind of like the old case of "./configure; make; make install' versus "apt-get install"
[19:24] <jam> they don't *talk* to eachother
[19:24] <jam> beuno: we can certainly update the bug to say that "setup.py install" doesn't overwrite the existing install cleanly.
[19:25] <beuno> jam, right, I can't remove the package because it will remove:
[19:25] <beuno> launchpad-dependencies
[19:25] <beuno> launchpad-developer-dependencies
[19:25] <jam> though 'bzr' may punt and point fingers at disutils
[19:25] <beuno> which I sort of need
[19:25] <jam> beuno: isn't there a remove-force but don't remove dependencies?
[19:25] <jelmer> slangasek: I would say it should be a feature of a new post-commit hook, perhaps part of bzr-builddeb (though James is perhaps a better person to decide that)
[19:25] <jam> I don't know apt very well
[19:26] <Odd_Bloke> jam: 1.6b4 is what bzr.dev is currently marked as.
[19:26] <slangasek> james_w: your thoughts?
[19:26] <jam> Odd_Bloke: no, I know that, I thought beuno installed from a package, and we've never released a b4 package
[19:26] <beuno> jam, I can't seem to get it to go away on it's own. It insists on taking others with it
[19:27] <Odd_Bloke> jam: Ah, OK.  I only glanced over the scrollback. :)
[19:28] <jam> beuno: well, I'm at the limit of my understanding of apt-get without a command line (currently logged into win32)
[19:28] <jam> LarstiQ, jelmer: ^^ do you have an idea how to apt-get remove without taking all dependencies with it?
[19:28] <jam> Odd_Bloke: ^^
[19:29]  * Odd_Bloke doesn't know.
[19:29] <jelmer> jam: aptitude unmarkauto <package> I think
[19:30] <beuno> jam, that doesn't seem to do anything for me
[19:31] <beuno> uhm, jelmer
[19:31] <jelmer> beuno: if you run that on the dependencies and then deinstall the package itself
[19:31] <jelmer> it shouldn't take the dependencies with it
[19:31] <beuno> jelmer, ah, thanks
[19:32] <james_w> slangasek: I agree that it appears to be a difflimit = 0 bug. I also think that there should be a special value for no limit, perhaps 0 or -1
[19:32] <james_w> slangasek: or did you mean on tagging things pending?
[19:32] <slangasek> james_w: ah, I'd moved on, I was asking about tagging things pending :)
[19:33] <james_w> I think something separate to bzr-email would be better. Using bts or tagpending will probably reduce the work.
[19:34] <slangasek> right
[19:35] <is_null> i don't understand this error when trying to checkout bzr-svn: http://nopaste.com/p/aFhoMZdbP
[19:36] <LarstiQ> is_null: svn co?
[19:36] <is_null> yes
[19:36] <LarstiQ> is_null: on a bzr branch? :)
[19:37] <is_null> my bad ... i got a little confused
[19:38] <Odd_Bloke> doko: o/
[19:41] <allee> email plugins problem:  with bzr push sftp://foo@bar/path/to/repo  and  a ~foo/.bazaar/locations.conf on host bar, neither the settings in [/path/to/repo] nor [sftp://foo@bar/path/to/rep/] are used here :(    Is it my fault?  Or are plugins on the repo server ignored?
[19:41] <jelmer> allee: the email plugin only triggers on commit, not on push
[19:42] <slangasek> doh, I think that was about to be my next question
[19:43] <slangasek> jelmer: is this a limitation of the post-commit hook logic?
[19:44] <jelmer> slangasek: it's an implementation choice in the email plugin
[19:45] <jelmer> slangasek: it only triggers on commit because if you also trigger on push that means you could be sending the notification email more than once (once on commit, once on every push)
[19:46] <jelmer> It would be nice to allow the user to decide when to trigger the notification email though
[19:46] <slangasek> jelmer: but in theory, there might be different audiences who would be interested in receiving mail about it at different points...
[19:46] <allee> jelmer: uhm, not good. I prefer not to use a leight-weight checkout, but only stuff that pushed to the 'authoritive central' repo matter.   IMHO push IS A commit-in-one-go ;)    Is there already a tool that handles push e-mail too?
[19:46] <slangasek> i.e., I really want to generate email when I've pushed to a repo on alioth, not just when I've committed locally
[19:48] <jelmer> slangasek: yeah, I agree it would be nice to support email on push as well
[19:48] <slangasek> wishlist against bzr-email?
[19:48] <jelmer> slangasek: yeah
[19:50] <allee> ah clarification from my side:  I don't need a push configured locally, but once on the repo server so everyone push/commit to the central repo triggers it.
[19:51] <allee> slangasek: can you post the bug/with id here?   I would like to subscribe
[19:52] <slangasek> allee: well, the latter relies on your server side having some smarts, because the only way to configure this right now is via ~/.bazaar
[19:52] <slangasek> allee: yes, I'll post the bug # here
[19:54] <allee> oh, I naively assume bzr sftp:// does it like rsync: start a remote bzr and talk to it
[19:55] <Odd_Bloke> allee: bzr+ssh:// does do that.
[19:57] <allee>  Odd_Bloke: bzr+ssh (e-mail) triggers also (e-mail) plugins this way?
[19:57]  * allee tries ...
[20:01]  * allee failed
[20:03] <ppires> hi there :-)
[20:05] <Odd_Bloke> allee: Sorry, I meant bzr+ssh starts a remote bzr, not that it does any of the email stuff.
[20:06] <allee> Odd_Bloke: no problem.  It was worth a quick try ;)  Thx.
[20:32] <ppires> allee: shouldn't that plug-in be installed in the remote bzr?
[20:33] <ppires> i'm totally newb at this, but that's my logic. if you call remote bzr, then commits are made in the remote bzr instance, and so triggering any plug-ins there and not on your machine. perhaps i'm wrong
[20:34] <Odd_Bloke> ppires: The issue here is that the email message is wanted on push to branches on that machine, not on commits to branches on that machine.
[20:34] <allee> ppires: yes, I did.  but e-mail plugin is only called on a) commit and b) on the host bzr does run
[20:34] <allee> .. not the remote repo server
[20:35] <Odd_Bloke> allee: If you were bound to a remote branch using bzr+ssh, I would expect commits to trigger on the remote host.
[20:36] <allee> Odd_Bloke: mhmm, I've to leave now.   I'll try your workaround tomorrow.  Thx again
[20:38] <Odd_Bloke> allee: That would still be individual commits and not pushes though.
[20:47] <ppires> Odd_Bloke: ic
[20:50] <slangasek> allee: bug #250934
[20:51] <mwhudson> jam: hi
[20:51] <allee> slangasek: thx
[20:51] <jam> mwhudson: hi, just wondering if you had PQM rights to merge your earlier patch
[20:52] <mwhudson> jam: no
[20:55] <cjwatson> hi, I'm trying to sort out problems with lp:~ubuntu-core-dev/casper/trunk
[20:55] <cjwatson> also mentioned in https://answers.launchpad.net/launchpad-bazaar/+question/39693
[20:55] <cjwatson> trying to branch this locally says:
[20:55] <cjwatson> $ bzr get casper test
[20:55] <cjwatson> bzr: ERROR: Revision {Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--base-0} not present in "x_Matt_Zimmerman_<matt.zimmerman@canonical.com>_Sun_Mar_13_00:51:19_2005_1366.3".
[20:56] <cjwatson> bzr reconcile crashes:
[20:56] <cjwatson> Reconciling repository file:///home/cjwatson/src/ubuntu/casper/bzr/casper/
[20:56] <cjwatson> bzr: ERROR: exceptions.KeyError: 'Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21'
[20:56] <jam> mwhudson: I forgot to check, but isn't there an associated bug for that fix?
[20:56] <jam> or was this a drive-by fix?
[20:56] <cjwatson> lifeless tried to help me at the distro sprint, but we only really succeeded in making things worse
[20:56] <cjwatson> so I'd appreciate expert help :)
[20:56] <cjwatson> (not that lifeless isn't. er. I'll shut up now)
[20:56] <mwhudson> jam: it was drive-by in fixing some other bug
[20:57] <mwhudson> bug 250418 in fact
[20:57] <mwhudson> there's a fix for that one to review too :)
[20:57] <jam> cjwatson: 'reconcile' complaining is a known issue, I would have thought "bzr branch" was already fixed in the last beta release
[20:57]  * mwhudson goes to have breakfast
[20:58] <cjwatson> jam: the branch has been a bit buggered for a long time, though
[20:58] <cjwatson> it's worked fine for those of us who already have copies of it ...
[21:00] <jam> cjwatson: well, when I look at it, I see nothing in the repository there
[21:00] <jam> and the last revision shows up as "NULL"
[21:00] <jam> http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/.bzr/branch/last-revision
[21:01] <jam> cjwatson: is it supposed to be a hosted branch, or a mirrored branch?
[21:01] <jam> cjwatson: ah, it looks like it might be a hosted branch, and the branch mirror script is borking on the missing mainline revision?
[21:02] <jam> mwhudson, jml: Can you shed more light on what is going on?
[21:02] <jam> cjwatson: so are you branching from "lp:casper" which actually means you are using bzr+ssh most of the time?
[21:03] <cjwatson> jam: I branched from it approximately a zillion years ago
[21:03] <cjwatson> I think at the time it was hosted on rookery
[21:03] <cjwatson> right now, bzr info says: checkout of branch: bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/casper/trunk/
[21:03] <jam> cjwatson: well, my current comment is that it is the bazaar-launchpad guys and their custom mirroring stuff
[21:04] <cjwatson> jam: mwhudson asked me to come here ...
[21:04] <jam> I would guess that the bzr+ssh side is working okay
[21:04] <jam> though "bzr reconcile" would still bork
[21:04] <cjwatson> it should be a hosted branch, yes
[21:04] <jam> and the mirror script is broken for fetching branches that have ghosts in their mainline
[21:04] <jam> They might then chose to kick it back to us, because of some fetch api they are using that breaks for them.
[21:04] <jam> but I'll let them debug that side of it.
[21:08] <cjwatson> jam: 'bzr push' fails on the same branch, FWIW
[21:08] <cjwatson> sftp://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/ seems to work, at least for log
[21:09] <cjwatson> ah, but branch still fails, meh
[21:10] <cjwatson> I've put the branch at http://people.ubuntu.com/~cjwatson/tmp/casper/trunk/.bzr/ in case it's useful
[21:23] <mwhudson> jam: ghosts on mainline sounds like a recently fixed bzr bug
[21:23] <mwhudson> at least there was some problem with them recent
[21:23] <mwhudson> ly
[21:23] <mwhudson> maybe this will go away when we update bzr on the codehosting systems?
[21:26] <jam> mwhudson: if wishes were fishes, we'd all eat a lot of fish
[21:26] <jam> but yeah, maybe
[21:26] <jam> reconcile still has a problem
[21:26] <jam> and check probably does too
[21:44] <muffinresearch> I writing something where I need to get the last rev for a specific file through the bzrlib api. Looking at the API I can see two ways to do it. Either subclass log.LogFormatter and stash revision.revno or to use log.find_touching_revisions. Am I missing a more direct approach?
[21:44] <mwhudson> muffinresearch: yes
[21:47] <mwhudson> though i forget what the best way is
[21:47] <mwhudson> one way is to load an inventory and look at the InventoryFile for the file
[21:47] <jam> muffinresearch: try this
[21:47] <jam> First ,do you have a Branch or WorkingTree ?
[21:47] <jam> but something like:
[21:48] <muffinresearch> Can get either
[21:48] <jam> wt, relpath = bzrib.workingtree.WorkingTree.open_contaning(path)
[21:48] <jam> wt.lock_read()
[21:48] <jam> file_id = wt.path2id(relpath)
[21:48] <jam> ie = wt.inventory[file_id]
[21:48] <jam> sorry scratch that
[21:48] <jam> basis_tree = wt.basis_tree()
[21:49] <jam> basis_tree.lock_read()
[21:49] <jam> ie = basis_tree.inventory[file_id]
[21:49] <jam> last_modified_revision = ie.revision
[21:49] <jam> basis_tree.unlock()
[21:49] <jam> wt.unlock()
[21:49] <muffinresearch> yep that seems much more direct
[21:50] <muffinresearch> thanks!
[21:50] <jam> if you only have a branch, you would do something more like
[21:50] <jam> rev_tree = branch.repository.revision_tree(branch.last_revision())
[21:50] <jam> ie = rev_tree.inventory
[21:50] <jam> etc
[21:50] <jam> ie = rev_tree.inventory[file_id]
[21:59] <muffinresearch> @jam: cheers for your help
[22:12] <pickscrape> Are bzrlib's progress bars generically usable from within plugins?
[22:20] <jam> pickscrape: "generically" I suppose
[22:20] <jam> using
[22:20] <jam> pb = bzrlib.ui.ui_factory.get_nested_progress_bar()
[22:20] <jam> ...
[22:20] <jam> pb.finished()
[22:20] <pickscrape> jam: thanks, I'll look into it :)
[22:34] <colbrac> jelmer: Which command can I use to test the tick addition?
[22:58] <beuno> mwhudson, just finished fixing everything in your review, and replied to your email with comments
[22:58] <mwhudson> beuno: excellent
[22:58] <beuno> now, I've been poking at my evil fill_div function
[22:58] <beuno> I've started and abandoned a few approaches
[22:59] <Peng_> Ooh, what's going on now?
[22:59] <beuno> do you have something specific in mind?
[22:59] <beuno> Peng_, shhhh, it's secret    :)
[22:59] <beuno> and it's like 7k diff, that's all I'm saying about it
[22:59] <Peng_> Adding Mercurial support?!
[22:59]  * Peng_ runs away.
[23:00] <beuno> :p
[23:00] <pickscrape> They're making a merge algorithm that *never* results in any conflicts
[23:00] <jelmer> colbrac: I was using some experimental bzr-svn stuff, not sure what else uses it
[23:02] <Peng_> pickscrape: It uploads your merge to MTurk?
[23:06] <beuno> mwhudson, ^  on the fill_div bit
[23:07] <mwhudson> beuno: it was just that the code in the function was a bit nonsensical
[23:07] <mwhudson> beuno: on the phone now
[23:08] <beuno> mwhudson, right. I kept running into problems with types, so it ended up looking like that.  I'm obviously missing something very simple.  No hurry though, waiting on the phone is always more annoying then waiting on irc  :p
[23:37] <igc> morning
[23:37] <Jc2k> evening
[23:39] <beuno> afternoon
[23:43] <emgent> night.
[23:44] <pickscrape> evening
[23:47] <Peng_> That about covers it.
[23:47]  * fullermd has a nice diurnal anamoly.
[23:48] <pickscrape> That sounds painful. You should get it seen to
[23:56] <poolie> hi
[23:57] <jelmer> colbrac, I'm upgrading the format of the trunk bzr-gtk branch atm, please don't push anything; it may be discarded
[23:57] <jelmer> 'morning poolie
[23:57] <colbrac> ok
[23:58] <colbrac> Actually I'm puzzled atm why the 'Merged!' mails from BB show the wrong previous status
[23:58] <jelmer> which ones in particular?
[23:59] <colbrac> Fix lp115...bla and Remove olive.glade -take2 have semi-approved
[23:59] <colbrac> while Fix lp115.. is approved, and Remove.. conditionally approved