[00:04] <igc> morning
=== abentley1 is now known as abentley
=== davidstrauss_ is now known as davidstrauss
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
[01:34] <krisfremen> is there a way to get only one file from a revision?
[01:35] <Peng_> krisfremen: "bzr cat -r 123 foo.py"
[01:36] <krisfremen> awesome thanks
[01:44] <AfC> krisfremen: which is also really handy when you have a forest of Branches that do not have Working Trees present with them
[01:44] <Peng_> Indeed.
[01:44] <AfC> krisfremen: and you need one or so files out of it
[01:45] <krisfremen> yes, that's what i need it for
[02:04] <jelmer> igc: hi
[02:04] <jelmer> igc: I've just added http://bazaar-vcs.org/ConvertCommand
[02:04] <jelmer> igc: it touches on upgrade a bit as well, since they might share common code
[02:04] <igc> hi jelmer
[02:05] <igc> jelmer: thanks for the rio stuff
[02:06] <igc> jelmer: one thing that would help though ...
[02:06] <igc> is to move the escape logic down somehow ...
[02:06] <igc> so that knowing whether to xml_escape or not doesn't need to be handled at higher layers multiple times
[02:07] <jelmer> igc: the problem is that we don't know if we're re-serializing an existing revision
[02:07] <igc> I had to tweak fast-import to disable it and I imagine ...
[02:07] <igc> that you'll need to do the same in svn-import, etc.
[02:07] <jelmer> igc: we could always escape in the XML serializer
[02:08] <igc> jelmer: or even the repo layer
[02:08] <igc> I just want to get it out of commit.py, fast-import, etc.
[02:08] <jelmer> igc: yeah, that would be really useful
[02:09] <igc> jelmer: if nothing else, we might need a flag on the format saying whether to escape messages or not
[02:10] <igc> jelmer: btw, I fast-import OOo over the weekend
[02:10] <igc> 36 hours altogether, though only 1 hour for the first 50K so ...
[02:10] <igc> there's room in there to improve things a lot I think
[02:10] <jelmer> igc: into dev6 or into 1.9-rr ?
[02:11] <igc> dev6-rr
[02:13] <jelmer> igc: about the xml char escaping, do you think it would be acceptable to just push it into the serializer and not have commit print warnings about squashed characters?
[02:14] <jelmer> alternatively, I guess we could propagate that number somehow
[02:14] <igc> jelmer: I think the serialiser is the logical place for it but ...
[02:14] <igc> I worry about backwards compatibility
[02:14] <igc> that's why I suggested the repo layer
[02:15] <jelmer> igc: backwards compatibility in what sense?
[02:15] <jelmer> igc: we don't really escape special characters at the moment, we squash them (we don't escape "\" itself)
[02:15] <igc> jelmer: if plugins assume the serialiser does or does not do it
[02:15] <jelmer> igc: it's not a problem if plugins escape too
[02:16] <igc> jelmer: I guess not
[02:17] <igc> jelmer: hopefully our tests we tell us :-)
[02:36] <h6w> Gday.  I have an existing svn+ssh repos, and I've installed bzr-svn.  What would the url be for the bzr exposure of the svn repos?
[02:36] <jelmer> h6w: same URL you would use with svn
[02:36] <h6w> bzr+ssh://.....?
[02:36] <jelmer> h6w: no, svn+ssh://..
[02:36] <h6w> Oh really?
[02:37] <h6w> Sounds a bit confusing, but, oh well.
[02:37] <jelmer> h6w: well, it's the svn+ssh:// protocol that you're using with bzr
[02:37] <jelmer> h6w: bzr+ssh:// would be the bzr protocol
[02:38] <h6w> oic.  I installed the bzr-svn plugin on the server, expecting it to do the translation server-side.
[02:38] <h6w> So I'd just use bzr on my client.
[02:38] <jelmer> h6w: that might work too (with bzr+ssh:// then, but I've never tried it)
[02:39] <h6w> ok, will try that.
[02:43] <jelmer> h6w: looks like that doesn't work for some reason
[02:43] <jelmer> spiv: ping
[02:44] <jelmer> h6w: so you'll need bzr-svn on the client instead and use svn+ssh://....
[02:47] <h6w> ok.  Or else just shift the entire repos.
[02:48] <h6w> The whole point was so that we could do a smooth migration from svn to bzr.
[02:49] <jelmer> h6w: you can do such a smooth migration that way, it's just the URL that's different
[02:50] <jelmer> h6w: if you later convert the repo on the server from svn to bzr using "bzr svn-import" you just adjust the URL and things will still work
[02:50] <h6w> I think that's going to have to be the way to go.
[02:50] <h6w> I was just hoping to have commits and updates work through both protocols while we tested it.
[02:51] <h6w> We have one client (Launchpad) that doesn't do bzr-svn, only bzr.
[02:51] <jelmer> h6w: it's probably an easy fix to support bzr+ssh:// for svn repositories, it's just that nobody has asked for it before
[02:52] <jelmer> lifeless,spiv: ^
[02:52] <lifeless> jelmer: huh?
[02:52] <lifeless> jelmer: do you mean, bzr-svn running on the server?
[02:52] <jelmer> lifeless: yeah
[02:52] <h6w> Yes.
[02:52] <jelmer> lifeless:  the smart server raises NotBranchError for some reason, any idea what could be causing that?
[02:52] <lifeless> doesn't really make, sense that would be a site-to-site thing like 3rd-party ftp
[02:53] <lifeless> or perhaps I don't understnad what you mean
[02:53] <h6w> Serving bzr requests via bzr url and piping them to an existing svn repos on the same server.
[02:53] <jelmer> lifeless: Using bzr+ssh:// to access a Subversion repo on the server
[02:53] <lifeless> jelmer: bzr-svn would need to find an svn repository given a file url
[02:53] <SamB> jelmer: why should that be needed?
[02:53] <jelmer> lifeless: it can do that
[02:53] <lifeless> jelmer: into the repo, not into a tree
[02:54] <SamB> why not just use svn+ssh ?
[02:54] <jelmer> SamB: see above
[02:54] <jelmer> lifeless: yes
[02:54] <lifeless> jelmer: then it should, in principle, just work
[02:54] <jelmer> lifeless: What's the easiest way to debug if it doesn't?
[02:55] <SamB> hmm, how do you break an ssh-started program into a debugger ...
[02:55] <lifeless> jelmer: use raw bzr://
[02:55] <lifeless> jelmer: start a server via bzr serve
[02:56] <lifeless> and then use pdb and or ctrl-\ juidiciously
[02:56] <SamB> oh, I guess that would work ...
[02:56] <SamB> jelmer: why don't you just check ?
[02:56] <lifeless> its exceedingly unlikely that ssh is part of the problem
[02:56] <SamB> oh, you did
[02:56]  * SamB wonders why he said "if"
[03:03] <lifeless> did you?
[03:03] <jelmer> lifeless: it loads the plugin but never even calls the probe function
[03:04] <lifeless> jelmer: the smart server uses the standard interface
[03:04] <lifeless> jelmer: break in bzrlib.smart.bzrdir .. OpenBranch
[03:04] <SamB> lifeless: standard interface ... ?
[03:05] <lifeless> SamB: as opposed to a nonstandard one
[03:07] <SamB> lifeless: do you have a link to the documentation of this interface?
=== Kissaki is now known as Kissaki^0ff
[03:09] <jelmer> lifeless: found the problem
[03:09] <jelmer> lifeless: it only tries to do an open with BzrDirMeta1
[03:09] <jelmer> lifeless: bzrlib/smart/bzrdir.py:52
[03:10] <lifeless> oh
[03:10] <lifeless> fugly
[03:10] <lifeless> iz bug
[03:13] <jelmer> filed
[03:25] <jelmer> lifeless: oh, and ChrootTransport doesn't provide local access?
[03:33] <lifeless> jelmer: no
[03:34] <lifeless> it provides whatever its back on, no more
[03:49]  * SamB wonders what ChrootTransport is ...
[03:56] <AfC> What's the bzr-svn URL now? I have http://people.samba.org/bzr/jelmer/bzr-svn/trunk/ but it's not redirecting anywhere.
[03:56] <SamB> AfC: symlinks don't usually cause HTTP redirection ...
[03:57] <AfC> SamB: apache configurations do, though
[03:58] <SamB> AfC: well, I believe that's always going to be the trunk of bzr-svn, and I don't think it's ever redirected for me unless I left off the /
[04:00] <AfC> SamB: oh; so you believe that URL to be correct?
[04:00] <SamB> AfC: assuming you're not getting an error
[04:01] <SamB> oh ... actually, I'm using http://people.samba.org/bzr/jelmer/bzr-svn/bzr.dev/
[04:02] <AfC> SamB: ok, thanks
[04:02]  * SamB was just confused by AfC's expecting it a redirect
[04:20]  * igc lunch
[05:12] <lifeless> -> spain
[06:34] <poolie> lifeless: ping? still in sydney?
[06:34] <bob2> 14:12:17 < lifeless> -> spain
[06:35] <bob2> poolie: ^
[06:35] <poolie> ah i thought so
[06:58] <lifeless> poolie1: at the airport
[06:58] <lifeless> poolie1: can I do something for you?
[07:00] <lifeless> poolie1: you have a 10 minute window before I'm forcible un-wifi'd
[07:07] <lifeless> ok, boarding call ;)
[07:07] <lifeless> ciao
[07:10] <Peng_> Bye. :)
[07:12] <lifeless> actually, misheard :)
[07:13] <lifeless> 16:30 I have to board
[07:16] <Peng_> 14 minutes from now?
[07:16] <Peng_> Well, enjoy your last 13.5 minutes of wifi. :)
[07:16] <lifeless> yes
[07:16] <lifeless> though pinging my home client could be wrong :)
[07:17] <abeaumont> good luck with jet lag... since it's 8:17am here
[07:18] <Peng_> So, um, why are you guys always flying all over the world?
[07:19] <lifeless> we get together for sprints
[07:19] <lifeless> different areas of the company do this at different times
[07:19] <lifeless> this particular one is everyone in the company, which is way cool
[07:19] <Peng_> Oh, okay.
[07:19] <lifeless> and happens ~ once a year
[07:20] <lifeless> wow, DCO's look evil
[07:20] <poolie1> hello lifeless
[07:20] <poolie1> no, nothing important
[07:20] <poolie1> DCOs?
[07:20] <lifeless> device configuration overlay
[07:21] <lifeless> for vendors that want to sell '60 GB drives' but their supplier gives them 65GB drives.
[07:21] <lifeless> apply a DCO and most everything sees it as 60
[07:21] <lifeless> just reading up on HPA's due to finding the BIOS HPA support on my desktop flaky, I decided I should know more about it
[07:23] <lifeless> and the best doc I've found so far is from the journal of investigative forensics :)
[07:32]  * lifeless waves
[07:39] <poolie1> fly well
[07:40] <Peng_> Fly well? The airline industry is doing so badly that passengers have to flap their arms now?
[08:08] <awilcox> Hi, is there a facility on Bazaar similar to subversion's tags?
[08:08] <awilcox> I would ask my bzr repo's maintainer but he has been offline for quite a while so I cannot
[08:10] <Peng_> awilcox: Bazaar supports tagging, but branches are more similar to svn tags.
[08:10] <awilcox> Ah.
[08:10] <fullermd> Peng_: Well, if you believe the version control/airlines thing...
[08:11] <awilcox> My project is closing in on a release and I'd like to "branch" the tree I guess, so that this version can be out of trunk and be worked on separately
[08:11] <Peng_> awilcox: Then use a branch.
[08:11] <awilcox> That way, last-minute bug fixes can be done by the QA devs on the branch, and me and the rest of the team can be adding shiny new features to 2.0
[08:12] <awilcox> Okay.
[08:12] <fullermd> Have a branch for the release engineering, and tag the release on it, is SOP.
[08:12] <awilcox> fullermd: is there a tutorial for doing this?  Because I looked on the wiki and it does not say how to make a branch
[08:13] <awilcox> I am an utter n00b when it comes to bazaar.  I mean, my repo maintainer taught me how to use checkout and resolved and said "anything else read the manpage"
[08:13] <awilcox> And the manpage doesn't seem to cover tags and just mentions what branches are, not how to to create one =/
[08:13] <fullermd> `bzr branch foo bzr`
[08:14] <fullermd> Aargh.  Dangit.  bar.  bAr.  With an A.
[08:14] <Peng_> :D
[08:14] <awilcox> Hah.
[08:14] <awilcox> So it would be like bzr branch trunk release ?
[08:14] <awilcox> Where do I run that from?  I have ssh to the server...
[08:15] <fullermd> Well, one general way would be to put it right next to trunk.
[08:15] <awilcox> Right.
[08:15] <awilcox> It would be like foo.com/project/trunk  or foo.com/project/release
[08:16] <Peng_> Unless you only want to make one release, it might be better to name the branch "1.2" or whatever.
[08:17] <fullermd> Or better, since you're going on with 2.0, name the branch RELENG_1 or something.  Then you can add branches off that for 1.0.x or 1.1.x releases or whatever's needful later.
[08:17] <awilcox> He said make a branch for releases and tag the release on it
[08:17] <Peng_> Well, it's your choice. Some projects just have one "stable" branch for the current release.
[08:17] <awilcox> Okay so we'll have a RELENG_1
[08:18] <awilcox> Okay I am at /home/awos-bzr/repos/awos
[08:18] <awilcox> I see: branches and trunk
[08:18] <Peng_> This isn't CVS, you don't need to keep caps lock on. :P
[08:18] <awilcox> Do I just cp trunk branches/1.0 ?
[08:19] <Peng_> awilcox: "bzr branch".
[08:19] <fullermd> Well, you maybe _could_, but using 'branch' would be better.
[08:19] <awilcox> Okay
[08:19] <awilcox> bzr branch trunk branches/1.0 ?
[08:21] <Peng_> IMO it's silly to have a "branches" directory, but yes.
[08:21] <fullermd> Users get offended when it's called "oldcrap" instead...
[08:21] <awilcox> Branched 670 revision(s).
[08:24] <awilcox> So now if I commit to the branch, it will have revision 671, and that will be separate from trunk revision 671, yes?
[08:25] <nok4> hi, i don't want bzr to track the file mode/ownership changes, how to do that?
[08:28] <Peng_> nok4: All it tracks is the exec bit. If you want to turn that off, um, I don't know how.
[08:28] <Peng_> awilcox: Yes.
[08:28] <awilcox> Peng_: Awesome
[08:28] <Peng_> awilcox: Y'know, you can merge the release branch back into the trunk when you make changes.
[08:28] <awilcox> Thank you Peng_ and fullermd for your help, it is much appreciated :D
[08:30] <nok4> Peng_: ok, i'll try chmod the x bit to work around it.
[08:46] <Peng_> Why does the index have to be probed to figure out that there's nothing to pull?
[08:54] <thekorn> hi, I've got a question about using hooks: is it possible to ship a hook within a branch?
[08:54] <thekorn> as far as I understand the docs a hook has to be in ~/.bazaar/plugins
[08:55] <thekorn> but I'm looking for hooks on a per branch basis, so something like mybranch/.bzr/hooks
[09:04] <awilcox> Peng_: How do I merge?
[09:04] <Peng_> awilcox: "bzr merge". :D
[09:04] <awilcox> ahhhhhh
[09:04] <Peng_> awilcox: Read the tutorial and/or help.
[09:04] <awilcox> That should have been obvious.
[09:04] <awilcox> :P
[09:18]  * igc dinner
[09:52] <awilkins> thekorn: No, you can't ship hooks in a branch unless you do it and get the users to run a script that installs them
[09:53] <awilkins> thekorn: Bazaar will by design not execute stuff in a branch automatically
[09:54] <thekorn> awilkins, thanks, so it won't make sense to file a wishlist bug, as this is by design, correct?
[09:54] <awilkins> thekorn: I'd agree with that
[10:00] <fullermd> Well, it's probably something we'd like more mechanism for.  So it's wishlist in a sense.
[10:02] <thekorn> it would be nice to have especially for hooks which don't do any harm, like commit_message_template
[10:03] <thekorn> but I can live without it, just curious
[10:15] <pygi> thekorn: plugin plugin plugin
[10:15] <pygi> you can do almost anything in a plugin
[10:16] <thekorn> pygi, I'm sure you can, so write me a plugin which allows me a define a commit_message_template hook within a branch ;)
[10:17] <pygi> thekorn: w00t xD
[10:17] <pygi> catch me during UDS, we might talk if its really something you need
[10:19] <pygi> :p
[10:19]  * pygi hides
[10:20] <thekorn> pygi, ok, ok, I'm also not sure if I really need it
[10:22] <pygi> ehhe
[10:22]  * pygi shoots thekorn 
[10:22] <fullermd> Well, it's kinda a bootstrap problem   :p
[10:22]  * thekorn switches over to git
[10:23] <fullermd> Making a plugin that forces somebody not having the problem to get the plugin has minor temporal difficulties.
[10:23] <fullermd> s/problem/plugin/
[10:25] <thekorn> right, I think I will just trust the contributors to the project to always use the template for commit messages we agreed on
[10:26] <fullermd> Yah.  Social problems are best handled with a cattle prod   8-}
[10:26] <Kinnison> Forcing a given template for commit messages seems a bit draconian. Is this a commercial project?
[10:27] <Kinnison> But as fullermd says, cattle prods are useful.
[10:27] <thekorn> no, I just want them to mention all files they changed
[10:28] <Kinnison> In what sense?
[10:28] <Kinnison> the change surely does that for you.
[10:28] <pygi> thekorn: hm, whats the point if bzr can tell you that for every revision? o.O
=== Kissaki^0ff is now known as Kissaki
[10:35] <thekorn> pygi, I'm using bzr in a computer sience class, and I want the student to actually describe their changes in detail
[10:35] <pygi> thekorn: ah, ok!
[10:35] <thekorn> so just for teaching purposes
[10:37] <Peng_> bzr-gtk has a nice commit UI, doesn't it?
[10:37] <Peng_> I mean, for messages. It's the source of all of those really detailed messages in bzr.dev, isn't it?
[10:43]  * Spaz tickles everyone
[10:43] <Spaz> oops
[10:43] <Spaz> wrong channel
[10:44] <pygi> Spaz: :p
[10:44] <pygi> lol
[10:44] <Spaz> you don't deserve my tickling! >:(
[10:45] <Kamping_Kaiser> :(
[10:47] <fullermd> I always thought commit messages were meant for long rambling harangues about the stupid things the client made you do...
[10:52] <Odd_Bloke> Bonus points for using profanity as shorthand.
[10:57] <awilkins> Bonus points for writing comments that when they are acronymized are an insult to the irritating client that cause the patch to be necessary
[10:59] <awilkins> thekorn: I remember a plugin that automatically listed all changed files in the comment
[10:59] <awilkins> thekorn: Wouldn't be hard to write though
[11:00] <awilkins> thekorn: I remember another one that parsed the --- below here --- part of the comment that was previously ignored and used it as a commit list, so you just deleted the line for any file you didn't want committed
[11:01] <fullermd> I remember _discussion_ about that, but I'm not sure it really exists.
[11:09] <bialix> hi, I have a question about English term. What is blueprint? Re: blueprints at launchpad
[11:10] <fullermd> bialix: A set of plans for construction, as of a building.
[11:11] <bialix> so it's more like "plan"?
[11:11] <bialix> or "planned features"?
[11:11] <bialix> or closer to "specification"?
[11:11] <fullermd> Probably specification.
[11:11] <bialix> I need this for Russian translations
[11:11] <fullermd> "plan" can get too general; a blueprint is a plan for building a specific thing, whereas "plan" could also mean broader what things you want to build.
[11:13] <fullermd> Only downside to 'specification' is that it could also mean a description of something that already exists, rather than the desired specifications for something to be made.
[11:13] <fullermd> But I don't know whether that ambiguity would translate.
[11:13] <bialix> so "blueprints @ launchpad" -- plans?
[11:15] <fullermd> Yeah, that would probably get the right idea across.
[11:15] <bialix> ok
[11:18] <bialix> fullermd: is it somehow related to "request"?
=== Kissaki is now known as Kissaki^0ff
[11:21] <fullermd> bialix: No, it's more like "We've decided to do this (or at least explore it in-depth), here is the behavior the feature should have and something of how we'll implement it at the code-level"
[11:22] <fullermd> So it's more of an "implementation plan", maybe.
[11:24] <bialix> looks good
[11:59] <knielsen> jam: I tried to use bzr merge-into to work-around bug 375898 as you suggested. Unfortunately using bzr merge-into gives the exact same problem :-(
[11:59] <ubottu> Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Undecided,New] https://launchpad.net/bugs/375898
[12:00] <knielsen> jam: I have added to the bug report the exact steps needed to get the error, including the merge-into step and subsequent patches applied.
[13:28] <vila> jam: ping
[13:38] <Peng_> jelmer: ping
[13:38] <jelmer> Peng_: yo
[13:39] <Peng_> Hi! :)
[13:39] <Peng_> Oops, wait, never mind.
[13:40] <beuno> vila!
[13:40] <vila> beuno !
[13:40] <vila> :)
[13:40] <beuno> vila, I'm packing to go see you!
[13:40] <Peng_> jelmer: Sorry. I wanted to mention a little error in bzr-svn, but you've already changed that code and fixed it. Oops, should've checked before pinging you.
[13:41] <vila> beuno: I'll do the same very soon (still a couple of hours hacking while re-checking my survival kit :)
[13:41] <beuno> vila, you've got a slightly shorter flight than I do  ;)
[13:42] <vila> beuno: we should sit and talk again about bzr-upload, I'll took notes last time but I need more details to refresh my memory :-/
[13:42] <vila> beuno: sure thing, the flight is shorter, yet I have to leave in the morning anyway because there isn't a lot of flights from here...
[13:42] <beuno> vila, would be great
[13:42] <beuno> there's that bzr sprint going on during UDS
[13:43] <beuno> I haven'g signed up because I'm over-booked elsewhere
[13:43] <beuno> BUT
[13:43] <vila> yes, hopefully we'll find time in the two coming weeks
[13:43] <beuno> I will run away occasionaly and hang out
[13:48] <jelmer> hmm, bb is down again :-(
=== Kissaki^0ff is now known as Kissaki
=== vila is now known as vila-dentist
=== `6og is now known as Kamping_Kaiser
=== vila-dentist is now known as vila
[15:33] <vila> jam: ping
[15:34] <jam> hi vila
[16:04] <ph8> Hi all, i'm new to bazaar - am actually just trying to checkout a copy of the planet project (planetplanet.org)'s repo - i've used bzr branch http://www.gnome.org/~jdub/bzr/planet/devel/trunk/ ./ - but it seems to be sticking, does it take time to examine files or is it likely my http proxy isn't setup correctly?
=== Spaz is now known as spaz
[17:00] <_amanica_> ph8, it can be your proxy settings
[17:06] <Kinnison> Eww, planetplanet is using an old repo format
[18:14] <Tak> what's the (practical) difference between default-rich-root and rich-root-pack?
[18:17] <jam> Tak: in the future --default-rich-root may point to a different format
[18:17] <jam> --rich-root-pack will always stay the same
[18:18] <jam> as of *today* there is no difference
[18:20] <Tak> hmm - which one would be a better default for a user who's unlikely to know the difference?
[18:50] <jelmer> Tak: where are you using them for?
[18:51] <Tak> I'm looking at adding "init" to md-bzr
[18:51] <jelmer> Tak: --default-rich-root seems like the most sensible choice then
[18:51] <Tak> ok
=== fta_ is now known as fta
[22:31] <las3r> Hello all.  I'm trying to get the bzr "svn" plugin working, but it tells me "No module named filters".  I'm using bzr-svn-0.5.4 w/ bzr 1.13.1 on Fedora.
[22:32] <las3r> And indeed, there is no module bzrlib.filters.
[22:33] <jelmer> las3r: for bzr 1.13.1 you need bzr-svn 0.5.3 (see the bzr-svn wiki page)
[22:33] <las3r> Ah, I see.  I was looking in the "requirements" section, which wasn't so specific.  Now I understand what the release list was telling me.  Thanks!
[22:37] <las3r> Okay.  Now I'm trying to import from an https:// subversion repository using a self-signed cert.  Curl is complaining ("Peer certificate cannot be authenticated...").  Is there any easy to way to pass the equivalent of 'curl --insecure' to this process?
[22:47] <jelmer> las3r: try prefixing the URL with svn+
[22:48] <las3r> jelmer: Huh, seems to work, but with the deprecated warning.  I had just finished patching the code to use connection.setopt(pycurl.SSL_VERIFYPEER,0) and then ran into authentication issues...
[22:48] <las3r> jelmer: Other than using svn+https, is there any way to provide a username/password to svn-import?
[23:08] <las3r> Well, I'll try the mailing list, because it's failed on the next step...
[23:19] <ronny> jelmer: are you doing weird stuff to dulwich? every time try i pull the bzr branch, it tells me "branches diverged"
[23:31] <davidstrauss> I'm getting "bzr: ERROR: Server sent an unexpected error: ('error', "ImportError instance has no attribute 'message'")" when checking out from my server over ssh
[23:34] <Odd_Bloke> davidstrauss: Can you try running a similar operation locally on the server?
[23:34] <jelmer> ronny: Shouldn't have happened recently, I mean, not in the last two weeks
[23:34] <davidstrauss> Odd_Bloke: Works
[23:35] <davidstrauss> (from local access)
[23:36] <Odd_Bloke> davidstrauss: Hmm, that's the only debugging idea I had.
[23:36] <Odd_Bloke> I know nothing about the smart server. :p
[23:37] <Odd_Bloke> davidstrauss: Is this bzr+ssh or sftp?
[23:37] <ronny> jelmer: im not very regular updating, since busy with other stuff
[23:37] <davidstrauss> Odd_Bloke: bzr+ssh
[23:37] <Odd_Bloke> davidstrauss: Try sftp.
[23:37] <davidstrauss> works fine over sftp
=== Kissaki is now known as Kissaki^0ff
[23:39] <jelmer> ronny: So, the rebasing should've stopped by now
[23:39] <jelmer> ronny: it was mainly caused by the fact that dulwich is maintained in both bzr and git
[23:39] <Odd_Bloke> davidstrauss: Right, now I'm out of ideas. :p
[23:40] <jelmer> ronny: and should stop now