[00:51] <jam> hi poolie, still a bit in-and-out. K still sick, though looking better. Working a bit in the evening to make up for it.
[00:51] <poolie> hi there
[00:51] <poolie> glad to hear that
[00:52] <poolie> so you're going pretty soon?
[00:52] <jam> I probably won't be around for a long time right now
[00:53] <jam> though maybe 10 min or so
[00:53] <poolie> oh, i meant moving
[00:53] <poolie> if you had more specific dates you could post them
[00:53] <poolie> (or maybe you did)
[00:53] <jam> I don't have exact dates yet. I'll post when I have more concrete stuff. Roughly late Feb. They want us to be there by March 1st, but we don't have the visas yet to actually travel.
[00:54] <jam> (when applying for a work visa, you're not allowed to get a travel visa anymore, etc.)
[00:55] <jam> technically, I'm not allowed into Europe until we sort through it, but it's not an issue since we don't have any plans to be there for a while.
[01:01] <jam> poolie: anyway, I did do some digging, and get_known_graph_ancestry really looks to be the only api not handling recursive fallbacks, because it is the only one that doesn't recurse via a public api
[01:06] <poolie> hm, and it looks like the knowngraph thing would make it a bit hard to do so?
[01:06] <poolie> and adding a .update() method to them would be possible but slightly nontrivial because it has a compiled implementation
[01:10] <jam> poolie: right, it is actually going via find_ancestry, though, which *is* composable, because it just returns dicts and sets
[01:10] <jam> but it is an Index level api, which doesn't know about fallbacks
[01:11] <jam> but if you promote find_ancestry to a VF attribute, that just thunks to self._index.find_ancestry and handles fallbacks, then get_known_graph_ancestry just becomes a thin shell over aggregating it
[01:11] <jam> not that it is worth doing for older bzr's
[01:12] <poolie> i was a bit concerned about the performance impacts
[01:12] <poolie> do you think we could prune some of these methods?
[01:12] <poolie> there seem to be a lot of similar ones
[01:15] <jam> poolie: what would you prune?
[01:15] <jam> I'm happy to have names changed to protect the innocent :)
[01:17] <jam> I certainly wrote a fair amount of it, and I'm happy to discuss why, and open to suggestions for improvements
[01:18] <poolie> i haven't got to real specifics yet
[01:19] <poolie> there just seem a fair number of interfaces that give you similar data in different forms
[01:19] <poolie> i think that combines poorly with having multiple implementations of a class
[01:19] <poolie> because it can look like N*M different methods
[01:20] <jam> poolie: so there isn't anything you can do here that you couldn't do with get_parent_map calls. The main difference is that it is just a *lot* faster when you are going to get the whole ancestry.
[01:20] <jam> I would like to see leaner classes as well
[01:21] <poolie> perhaps it's better to have just one method on the implementation and then wrappers that redo it
[01:21] <jam> Part of that is trying to break Abstraction issues.
[01:21] <poolie> as someone said in dallas (?) "Let's remember functions are pythonic too"
[01:21] <jam> poolie: so the issue is that at least part of the functional code is all the way down at BtreeGraphIndex
[01:21] <jam> because that is where the peek-ahead code lies
[01:22] <jam> then you aggregate that up through about 4 levels of abstraction
[01:22] <jam> Repository.get_known_graph calls into VF.get_known_graph_ancestry with a wrapper
[01:22] <jam> which calls self._index. do something
[01:22] <jam> which is actually a CombinedGraphIndex
[01:22] <jam> which then needs to collect information from each actual index object
[01:23] <jam> sorry, there is one more level in there
[01:23] <poolie> :)
[01:23] <jam> VF._index is actually a VFIndex
[01:23] <jam> (GCGraphIndex, KnitGraphIndex, etc.)
[01:23] <jam> poolie: and only at the VF and Repo levels do they know about fallbacks
[01:31] <poolie> so jam i was hoping to provoke you into making it more obvious :)
[01:31] <poolie> or deleting some stuff
[01:31] <poolie> perhaps it's fine as it is
[01:31] <poolie> or could just do with some discussion in the developer oveview
[01:32] <jam> poolie: it doesn't help that there are also compiled vs pure python code in the stack :)
[01:32] <poolie> anyhow, you're +1 on landing this change to 2.3?
[01:32] <jam> poolie: yeah, fine with me for 2.3
[02:03] <jam> poolie: any update on the status of lp-forking-service in production?
[02:04] <jam> you were talking with spm about it, just wondering if you heard anything
[02:07] <poolie> jam, it's going to be rolled out in about 21h from now
[02:07] <poolie> wallyworld_ and spm will be doing it and i'll help if anything is needed
[02:07] <poolie> we're going to do a dry run today
[02:08] <wallyworld_> poolie: /me will be watching :-) don't know how much help i'll be
[03:37] <kkrev> is there any way to concatenate revisions?  like you have three incremental revisions you want to roll together before commiting to a central repository?
[03:38] <bob2> bzr-rewrite is a way
[03:39] <lifeless> or just merge; revert --forget-merges
[03:44] <kkrev> revert --forget-merges sounds scary.  rebase looks like the way to roll together local changes.
[03:51] <kkrev> I don't think I get how this is supposed to work.  I made a branch and committed two revisions.  I say "bzr rebase" and it says "no revisions to rebase".
[03:52] <kkrev> I just want to roll those two revisions into a single revision for cleaner version history.  They're incremental work on a single task.
[03:53] <bob2> well, if you go back to the branch point, you can do what lifeless said (which is simple and non-scary)
[03:53] <bob2> bzr-rewrite probably has a way for you to do that without moving the branch but I don't know it
[03:59] <kkrev> it's a local branch off a remote repository and neither rebase nor --forget-merges seem to do anything, even if I manually specify a revision.  rebase says "no revisions to rebase".  revert just silelently doesn't do anything.
[03:59] <bob2> ?
[03:59] <bob2> merge needs to be run on the branch point so there is something to merge
[04:00] <kkrev> bzr merge says "nothing to do".  The only changes are in the local branch (not a checkout)
[04:03] <spiv> kkrev: they way to use revert --forget-merges to do this is "bzr branch trunk new-branch; cd new-branch; bzr merge ../local-changes; bzr revert --forget-merges; bzr commit"
[04:03] <spiv> kkrev: (assuming 'trunk' is the branch you want to add this one new commit to, and that 'local-changes' is the branch where you have made your local commits)
[04:04] <spiv> kkrev: does that make sense?
[04:05] <kkrev> I think so.  if the docs were a wiki I'd paste that in.
[04:11] <kkrev> all clear now.  much thanks.
[04:32] <poolie> and now bug expiry kicks off
[04:36] <lifeless> *boom* :P
[04:38] <spiv> poolie: should the single ` in NEWS of 715000-stacking be double?
[04:40] <poolie> we're a bit inconsistent
[04:40] <poolie> to me it seemed better rest to use single ticks for program identifiers
[04:40] <poolie> in some configurations it highlights them differently
[04:41] <spiv> I think single backticks have special meaning in ReST?  http://docutils.sourceforge.net/docs/user/rst/quickref.html#inline-markup
[04:43] <spiv> I guess it probably renders ok, but I get the impression from the ReST docs it's a bit semantically strange to use it like that.
[04:44] <spiv> Hmm, apparently the "default default role" for single backticks without an explicit :role: suffix/prefix is http://docutils.sourceforge.net/docs/ref/rst/roles.html#title-reference
[04:44] <spiv> In short: I don't think we should use `single backticks` :)
[04:45] <maxb> right, 2.3.0 is out in the main PPA
[04:46] <maxb> and on that note, sleeeep
[04:46] <spiv> Tangentially, it'll be really nice when we can depend on just sphinx and drop the docs-plain target.
[05:43] <poolie> wow 2.2 is so slow to get through pqm compared to 2.5
[06:17] <vila> poolie: try 2.0 ! :D
[06:17]  * vila back to coffee
[06:23] <poolie> hi vila; you're early
[06:32]  * poolie is merging 2.2-2.3-2.4
[07:13] <vila> hi all !
[07:14]  * fullermd . o O ( Obviously, the cofffee worked... )
[07:14] <vila> hey ! I put only 2 f there !
[07:14] <fullermd> I know.  I thought you might be running out, so I gave you an extra one there.
[07:14] <fullermd> Don't say I never gave you anything   :
[07:14] <fullermd> p
[07:15] <vila> ha cool, now I can type uck without being gross :)
[07:16] <fullermd> It's good to know I provide a valuable service to the community like that   :p
[07:25] <vila> spiv: yup, single backticks are for url refs AIUI
[07:28] <vila> poolie: so what's up with the p-i and bug #715000 ? Do we still wait to restart it ?
[07:29] <poolie> vila, it's waiting on the lp deployment of the fixed bzr
[07:29] <vila> ok
[07:30] <vila> poolie: are you asking for a review of lp:~mbp/bzr/integration-2.3 or will you just land it ?
[07:31] <poolie> you could just check it quickly
[08:42] <poolie> ok, good night vila
[08:42] <vila> poolie: g'night
[08:43]  * vila back to bed
[08:43] <vila> err, wait !
[08:43] <mr-russ> Hi, I'm coming from SVN and would like a central repository area for developers to push/pull from for updates.  I'd like it to be over http, I've read http://doc.bazaar.canonical.com/latest/en/tutorials/centralized_workflow.html and http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/http_smart_server.html#running-a-smart-server
[08:43] <mr-russ> What I don't understand is is a shared tree setup kind of like the SVNParentPath, group of repositories type setup.
[08:44] <mr-russ> Is there a preferred way to get that kind of setup?
[08:45] <poolie> vila, can you help, i need to go
[08:46] <mr-russ> k, thanks for responding.
[08:47] <poolie> mr-russ, as far as i can tell you just need to export that directory
[08:47] <poolie> i don't think you need any special setup with bzr
[08:48] <mr-russ> Also to add to that, I'm wanting loggerhead to allow viewing the repository groups, hopefully without addition config for each set of branches.
[08:48] <mr-russ> what i mean is make the bzr server structure appear like svn as a set of repositories.
[08:48] <mr-russ> and not have to maintain config for each one.
[08:50] <mr-russ> also, don't forget you need to go poolie :)
[09:17] <maxb> mr-russ: As far as hosting multiple projects and branches thereof is concerned, Bazaar works on the principle (whichever access method you use) of exposing a portion of the directory tree, under which you can put as many branches as you like
[09:18] <maxb> Loggerhead supports basic browsing of the directory tree containing branches, and then switches to the interface that is familiar from bazaar.launchpad.net when you enter a given branch
[09:24] <maxb> Example of what loggerhead looks like in this scenario: http://bzr.maxb.eu/
[09:36]  * maxb glares at recipe builds
[09:59] <mr-russ> maxb: do you setup a project that is a shared directory of branches?
[09:59] <mr-russ> maxb: Then that just works with the standard push/pull
[10:06] <vila> mr-russ: sorry, my chat notifications broke again
[10:07] <vila> mr-russ: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief explain some concepts that will make the discussions easier
[10:07]  * fullermd dreams of the day he can bury this !#&$ project and maybe have time to polish up those sow's ears...
[10:08] <maxb> mr-russ: Basically, a project is just a convention of keeping related branches in a directory - ideally having made the shared directory a Bazaar shared repository so that revision data is shared between all branches under it
[10:08] <vila> exactly
[10:08] <maxb> But that's a time/bandwidth/diskspace optimization rather than a necessity
[10:14]  * vila scratches head
[10:15] <vila> maxb: why is 'rmadison bzr' showing 2.3.0 for natty source but 2.3.0~beta5 for amd64 and i386 ?
[10:15] <maxb> vila: Because the binaries are stuck in the NEW queue?
[10:16] <vila> maxb: stuck as in: too much load on same server or there is a problem waiting for a fix ?
[10:16] <vila> maxb: and is there some way to consult this NEW queue ?
[10:16] <vila> s/same/some/
[10:17] <maxb> Jelmer split out python-bzrlib as a separate .deb in this release. A new binary package name requires ack-ing by an archive admin before the packages enter the archive.
[10:17] <maxb> https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=bzr
[10:17] <mr-russ> Thanks, I think I get it.  I just need to go setup the structure on the server and it will just work.
[10:18] <vila> mr-russ: that's the idea, come back for more help if needed
[10:18] <maxb> This has comically caused the main bzr package to shrink to 38 kB :-)
[11:18] <Decorian> hi, bazaar is asking me to file a bug report, thought i'd just mention it here first as I don't know much about the crash so I can't effectively write a bug report.
[11:19] <Decorian> it crashed whilst doing a push to a bzr+ssh server (run by me) that worked 20 mins previously, and the other repository on the same server works.
[11:20] <Decorian> pastebin of the output bzr explorer gave http://pastebin.com/Gzh73z3U, I'd be gratefull if anyone has any ideas, even if it's 'file a bug report anyway'
[11:22] <spiv> Decorian: probably the server got a MemoryError.  I'd file a bug report anyway :)
[11:22] <Decorian> ok, is that something to do with my configuration of the server, and how would i work around it
[11:23] <Decorian> i could always wipe the server's repository, and do a fresh push from my most up to date local one.
[11:23] <Decorian> I'll file a bug report anyway, with as much information as i know (which unfortunately isn't much).
[11:23] <spiv> Decorian: I'd check the .bzr.log on the server
[11:23]  * spiv -> bed
[11:24] <Decorian> is that .bzr/.log?
[11:24] <Decorian> thank you spiv
[11:24] <spiv> No, probably ~/.bzr.log
[11:24] <Decorian> ok thank you.
[11:26] <Decorian> yes, it's a MemoryError.
[11:26] <Decorian> does it still need a bug report, or is this known?
[12:36] <vila> Decorian: file a bug report anyway :) With the relevant excerpt from .bzr.log
[12:36] <vila> Decorian: there is little that can be said without that
[12:37] <Decorian> vila: Ok, I will, I'll attach a few excerpts from .bzr.log because I tried again a few times and sometimes got a pipe failed or something problem
[12:38] <Decorian> I tried working around it by choosing to create a new repository in a different directory on the server, but it still failed.
[12:38] <Decorian> i'll report what i found.
[14:09] <shakaran> Hi, I have this error doing a bzr upgrade:
[14:09] <shakaran> bzr: ERROR: Cannot convert from format Remote: Branch format 7 to format <class
[14:09] <shakaran> 'bzrlib.branch.BzrBranchFormat7'>.    No converter
[14:10] <vila> o_O
[14:10] <shakaran> How I can solve? I need upgrade for make a bzr unbind on a lightweight checkout
[14:10] <vila> O_O
[14:10] <shakaran> I am saying weird things?
[14:10]  * fullermd pokes vila in the O
[14:11] <vila> You can't unbind a lightweight checkout
[14:11] <shakaran> $ bzr unbind
[14:11] <shakaran> bzr: ERROR: To use this feature you must upgrade your branch at bzr+ssh://bazaar
[14:11] <shakaran> .launchpad.net/~shakaran/ea/angel/.
[14:11] <shakaran> how to upgrade then?
[14:12] <vila> bah, unhelpful error message
[14:12] <vila> you want to turn your lightweight checkout into a regular branch
[14:13] <vila> bzr reconfigure --help
[14:14] <vila> shakaran: please file a bug explaining your misunderstanding, this error message needs to be fixed
[14:14]  * fullermd wishes reconfigure had more choice of modalities   :|
[14:16] <shakaran> vila: I will fill a bug. I did previously on ask here a: bzr reconfigure --unstacked
[14:16] <shakaran> so, previously to ask I can commit and push
[14:17] <shakaran> but when I commit, directly push the commit, so for that reason I looking for a unbind
[14:17] <vila> shakaran: right, it seems to me you want a regular branch not a lightweight checkout
[14:18] <shakaran> I could take the right way. Delete the branck, and make a regular checkout, but my curiosity wants to know because the problem
[14:23] <vila> err, delete the checkout and make a regular branch
[14:24] <vila> unbind is for... bound branches, a lightweight checkout is not a bound branch, that's the bug, unbind should warn about that, not suggesting upgrade
[14:25] <vila> a bound branch ensures that commits happen on the msater branch before they happen on the local branch (the local and master branches are bound)
[14:25] <vila> a lightweight checkout doesn't have a local branch, only a master one
[14:26] <vila> this is a confusing UI and one of the cause is that lightweight checkouts and bound branches are generally used by different people because they match different workflows
[14:27] <vila> shakaran: so use whatever works for you, which seem to be the regular branches
[14:27] <vila> s/regular/standalone/
[14:28]  * vila slaps fingers for using the wrong word when trying to clarify a confusing UI
[14:31] <fullermd> Actually, you were probably right the first time, with 'standalone' generally being a term of art for describing its state relative to a shared repo..
[14:32]  * vila looks at bialix postcard...
[14:32]  * vila looks at bialix's postcard...
[15:22] <catsup> how do i check out a revision by revno?
[15:24] <catsup> that
[15:25] <catsup> that's probably unclear; i mean, i have downloaded a repo with bzr branch, and now i want to get a particular version into my working directory so that i can apply a patch to it
[15:25] <fullermd> And then commit it?
[15:26] <catsup> i don't know, maybe
[15:26] <fullermd> If you just wanna look at it, you can use update.  If you want to commit it, you'll need a branch for that.
[15:27] <fullermd> ... well, I guess you COULD do it all via update, but you'd be gambling that it goes smoothly.
[15:29] <catsup> i'm very confused, from update -h, how you would do that
[15:29] <fullermd> bzr update -rX
[15:29] <catsup> oh.  -r isn
[15:29] <catsup> t listed there
[15:29] <fullermd> What version do you have?
[15:30] <catsup> bzr: ERROR: no such option: -r
[15:30] <catsup> Bazaar (bzr) 2.0.3
[15:30] <Peng> Well, it's there in newer versions.
[15:31] <fullermd> In 2.1 and newer.
[15:31] <Peng> You could "bzr revert -r 123".
[15:31] <fullermd> revert would be OK for looking at it, but you wouldn't have any chance of getting it committable from that.
[15:31] <Peng> Right.
[15:31] <Peng> Look but don't touch. :D
[15:32] <Peng> "bzr update -r 123" makes bzr check out the older revision. "bzr revert -r 123" is like applying a massive patch to the currently checked out revision that coincidentally makes it look like revision 123.
[15:33] <Peng> Which is just fine for looking at it, but would be a horrible thing to commit.
[15:33] <Peng> If you want to commit anything, you need to use a new branch.
[15:35] <catsup> ok, i got that figure out
[15:37] <catsup> figured*
[15:38] <yshavit> Hi all. Sometimes when I'm reviewing a largish diff on launchpad, I like to load it up in my IDE. To do that, I 1) create a new local branch from trunk, 2) merge in (but don't commit) the proposed branch. That way I can see the changed files in my IDE. Obviously these aren't a lot of steps, but I was wondering if there's a single bzr command that does it? I wrote a really small shell script, I'm just curious to see if there was a better way.
[15:40] <vila> yshavit: I use: http://paste.ubuntu.com/565025/
[15:41] <vila> yshavit: this gives me a new branch which is a mirror of the submitter's one
[15:42] <vila> yshavit: I then use: alias bzr-review='. `which bzr-review.sh`'
[15:42] <yshavit> vila: ah, okay. Yeah I like to have not a mirror but a diff from trunk to submitter's, so I can see just the proposed changes. Or is that what you're doing and I'm missing it?
[15:42] <vila> yshavit: so I can issue 'bzr diff -rsubmit:' right away
[15:42] <Peng> yshavit: bzr merge --preview?
[15:43] <yshavit> vila, Peng: ah, didn't know about either of those options! I'll take a look now
[15:43] <Peng> yshavit: ...except that would just produce the diff seen on lp
[15:43] <yshavit> Peng: ah, okay.
[15:43] <catsup> ok, i just issued bzr merge, got a conflict, resolved it by editing the file...  how do i finish the merge?
[15:43] <vila> yshavit: Peng solution is one shot only, having a mirror also allows you to look at the history and better understand the final result
[15:43] <yshavit> Peng, vila : Do either of you have any best practices for looking at largish (~1500+) diffs?
[15:44] <vila> yshavit: shoot the submitter gives good results
[15:44] <yshavit> vila: :D
[15:44] <vila> yshavit: the following submissions are smaller (on average)
[15:44] <catsup> oic, bzr resolve
[15:45] <fullermd> vila: No no no, you injure them, you just make the responses slower.  Kidnapping family members and/or pets focuses their attention much more usefully.
[15:45] <yshavit> vila: my company's still new with bzr, so we're learning to get our diffs down to size. I'm guilty of it, too... just dropped a 2400er on a colleague :(
[15:45] <fullermd> Ah.  VCS MAD   :p
[15:46] <vila> yshavit: seriously, for large diffs, hopefully there are several commits with smaller diffs...
[15:46] <Peng> yshavit: When I see a large diff, I run away and hope someone else handles it.
[15:46] <yshavit> vila: yes, that there are. I hadn't actually considered looking at it diff-by-diff, that's a good idea.
[15:46] <Peng> yshavit: Fortunately I'm only involed in FOSS. :D
[15:47] <vila> yshavit: if not, then, yeah, you're kind of doomed, but asking for reviews and not recommending frequent commits... won't fly
[15:47] <yshavit> Peng: hippy! ;-)
[15:55] <jam> vila: can I get a second review on: https://code.launchpad.net/~eric97/bzr/dump-btree-traceback/+merge/49002
[15:55] <jam> it is pretty small
[15:56] <vila> jam: morning jam !
[15:56] <vila> eric's one ? Oh, right, 2 reviews needed, well let me check again but I think I was fine, just forgot to vote ;-/
[15:58] <vila> jam: done, want me to land it ?
[15:59] <jam> vila: sure
[17:14] <henninge> Hi abentley!
[17:14] <henninge> How do I merge two pipes?
[17:14] <henninge> i.e. the next one into the current one.
[17:15] <thumper> bzr merge :next
[17:15]  * henninge thought he had tried that
[17:16] <henninge> I had not.
[17:16] <henninge> thumper: thanks!
[17:16] <abentley> henninge, you can also just use the branch locations.  The only thing special about merging pipes is that --uncommitted works with uncommitted changes in a pipe.
[17:17] <henninge> oh right, I think I have used that before
[17:17] <henninge> thanks
[18:29] <zooko> Hi folks! This web page https://code.launchpad.net/txaws tells me to run "branch lp:txaws", but when I do it says:
[18:29] <zooko> HACK Zooko-Ofsimplegeos-MacBook-Pro:~/playground$ bzr get lp:txaws
[18:29] <zooko> /Library/Python/2.6/site-packages/pycrypto-2.3-py2.6-macosx-10.6-universal.egg/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
[18:29] <zooko>   RandomPool_DeprecationWarning)
[18:29] <zooko> Permission denied (publickey).
[18:29] <zooko> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[18:30] <zooko> Hm, I have bzr 2.3b1.
[18:30]  * zooko upgrades to 2.3b4.
[18:33] <maxb> zooko: This is a known issue with paramiko. The bzr developers have set a patch to paramiko, but paramiko's upstream are being rather slow to apply it
[18:34] <maxb> The warning is not usually an issue because bzr suppresses all deprecation warnings when it is a final (non-beta) release
[18:34] <vila> ...but the patch is carried by the OSX installer IIRC, at least for the most recent versions
[18:34] <maxb> Also, 2.3b4 is an odd thing to upgrade to. 2.3.0 final is out
[18:34] <maxb> and there was a 2.3b5 in between
[18:34] <vila> and anyyway it's a warning you can ignore, you problem seem to be the 'Permission denied (publickey)'
[18:36] <zooko> Ah, I assumed that it didn't need any credentials of mine since this is a public repo.
[18:37] <zooko> But... if it is trying to use my ssh key then that probably explains the problem...
[18:38] <maxb> zooko: Connections to launchpad lp: URLs prefer SSH because Launchpad providers the Bazaar smart server over ssh, but only dumb serving via http
[18:38] <maxb> Therefore, ssh is often a lot faster
[18:38] <lifeless> s/lot/massively/
[18:38] <lifeless> maxb: consider pinging robey on twitter
[18:40] <zooko> Hm, no my ssh public key *is* already registered in launchpad.
[18:40] <zooko> Can I get bzr to tell me more about what is going wrong?
[18:40] <zooko> Or test the ssh interface with the ssh client directly?
[18:49] <maxb> zooko: "ssh your-lp-id@bazaar.launchpad.net" should print "No shells on this server."
[18:59] <zooko> Thanks! Fixed. (I didn't have my current ssh key registered after all.)
[19:13] <shakaran> vila: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/716006 the file bug as you requested
[20:22] <kkrev> is there supposed to be a way you make bzr launch kdiff automatically for needed manual merges: bzr usekdiff myfile.cpp ?  Or do you really have to manually run kdiff3 and then mark resolved?
[20:25] <kkrev> it just seems like a very annoying bit of typing to have to specify 'kdiff3 myfile.BASE myfile.THIS myfile.OTHER -o myfile' every single time a manual merge is needed.
[20:27] <jam> kkrev: there is the plugin bzr-extmerge, but I don't fully remember how to invoke/configure it
[20:28] <mgz> also Gordon Tyler's mergetools stuff on trunk addresses this problem no?
[20:35] <kkrev> extmerge looks perfectly good, but is there a trick to making plugins work on windows?  It works from cygwin, but from the dos shell "bzr extmerge" just says "unknown command"
[20:47] <kkrev> For some reason it doesn't like living in %HOME%/.bazaar/plugins on windows.  I had to put it in /program files/bazaar/plugins to make it work.
[20:59] <poolie> hi jam, jelmer
[20:59] <jam> hi poolie
[20:59] <jam> how did the dry-run lp-forking service stuff go?
[20:59] <jam> I saw the lead-up conversation, but none of the final stuff
[20:59] <jelmer> hi jam, poolie
[20:59] <jam> I did land lp-production-configs since spm approved it
[20:59] <poolie> ah, good
[20:59] <jam> hopefully that doesn't mess up the ordering you proposed
[20:59] <poolie> i didn't hear him specifically reach a conclusion
[20:59] <poolie> maybe he was interrupted
[21:00] <poolie> i wasn't sure if you were going to land it or him, but it's good it's done
[21:00] <poolie> we have a udd meeting now in #ubuntu-meeting
[21:03] <poolie> jam, can you join us?
[21:36] <maxb> jelmer: Do you happen to be around?
[21:36] <jelmer> maxb: somewhat
[21:37] <jelmer> maxb: got a bad case of the flu, so I'll disappear after the udd meeting
[21:37] <maxb> jelmer: Hi, could you go here: https://code.launchpad.net/~bzr/+recipe/bzr-dbus-daily and trigger some builds? I am not allowed to view the page because it contains a deleted PPA in the last 5 builds list
[21:37] <jelmer> maxb: done
[21:37] <maxb> oh dear - get well soon!
[21:37] <maxb> yay, and now I can view the page
[21:37] <jelmer> thanks :)
[21:38] <jelmer> maxb: is there a lp bug about that?
[21:38] <maxb> bug 715325
[21:38] <jelmer> maxb: you rock, thanks
[21:59] <mgz> ha, bzr-git update means I've finally got a repo on bug 393038
[22:00] <mgz> it's basically what I had before, must have been masked by the other breakage.
[22:02] <maxb> Can someone suggest how to start_bzr_subprocess *and* ensure that the plugin you're currently testing is available to be loaded by the subprocess?
[22:02] <poolie> maxb, what are you trying to test?
[22:02] <poolie> hi guilhembi
[22:03] <maxb> poolie: I'm trying to repair the bzr-dbus testsuite
[22:03] <poolie> and it needs to run in a test suite?
[22:03] <poolie> blah
[22:03] <poolie> in a subprocess
[22:03] <poolie> you could try setting BZR_PLUGINS_AT to something handcrafted to work
[22:07] <maxb> [  646] 2011-02-09 22:06:22.571 WARNING: bzrlib.plugins.dbus cannot be loaded from ['/home/maxb/wc/bzr/bzr-dbus/unstable']
[22:07] <maxb> bzrlib.plugins.dbus cannot be loaded from ['/home/maxb/wc/bzr/bzr-dbus/unstable']
[22:07] <maxb> right path.... shame it doesn't say *why* it can't be loaded :-/
[22:13] <maxb> ah....
[22:13] <maxb> actually, no, I don't have a path starting ['.... :-)
[22:40] <poolie> john, with the fallback mps
[22:40] <poolie> most of them are superseded
[22:41] <poolie> lp doesn't send mail when that happens apparently
[22:41] <poolie> i was trying things out to get a good diff showing only the changes since 2.3
[23:19] <mgz> jam/poolie: do you have any feelings about whether I should reopen bug 77657 and dupe bug 715547 against it, or treat the second as a new thing?
[23:20] <mgz> ...thanks ubot5.
[23:20] <poolie> haha
[23:20] <poolie> it's probably also a bug that failed api calls return html
[23:20] <mgz> as far as I can tell, the exact problem the first (and many of its dupes) was never actually fixed, but a different path was.
[23:21] <mgz> the associated branch touched workingtree, but not mutabletree
[23:21] <poolie> on the whole in that case i would just go with the new bug
[23:21] <poolie> and maybe post a note on the old bug for people who are still affected by it
[23:21] <mgz> okay, will do.
[23:22] <poolie> i think generally speaking having bugs cycle open-fixed is just confusing y
[23:22] <poolie> if we just fixed it and then discovered we didn't that's different
[23:24] <jam> mgz: I think it is a new bug
[23:25] <mgz> well, the root issue is sorted(os.listdir(...)) which has been in smart_add all along, and is unsafe in those circumstances.
[23:25] <mgz> it's easy to move this kind of bug around though, it could well have been failing somewhere else for a bit.
[23:25] <mgz> just changing the mutabletree code may well move the problem somewhere else.
[23:28] <mgz> I'll play around and see where I get.