[00:36] <ubotu> New bug: #53948 in bzr-email "Ability to rewrite URLs" [Wishlist,Triaged] https://launchpad.net/bugs/53948
[01:06] <mtaylor> jelmer: mtaylor@solace:~/src/pkg-mysql/trunk$ bzr merge
[01:06] <mtaylor> Merging from remembered location svn+ssh://mtaylor-guest@svn.debian.org/srv/svn.debian.org/svn/pkg-mysql/trunk
[01:06] <mtaylor> Nothing to do.
[01:06] <mtaylor> mtaylor@solace:~/src/pkg-mysql/trunk$ bzr push
[01:06] <mtaylor> Using saved location: svn+ssh://mtaylor-guest@svn.debian.org/srv/svn.debian.org/svn/pkg-mysql/trunk
[01:06] <mtaylor> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[01:06] <mtaylor> aaeero?
[01:06] <jelmer> mtaylor: "bzr status" ?
[01:07] <mtaylor> mtaylor@solace:~/src/pkg-mysql/trunk$ bzr status
[01:07] <mtaylor> unknown:
[01:07] <mtaylor>   debian/changelog.orig
[01:07] <mtaylor>   debian/changelog.rej
[01:07] <mtaylor>   debian/control.orig
[01:07] <mtaylor>   debian/control.rej
[01:07] <mtaylor>   debian/rules.orig
[01:07] <jelmer> hmm, no pending merges..
[01:07] <jelmer> mtaylor, what version of bzr-svn is this?
[01:07] <mtaylor> hm... easy way to tell?
[01:07] <jelmer> bzr plugins
[01:08] <jelmer> (as a command)
[01:08] <mtaylor> seems to be 0.4.1-1
[01:08] <mtaylor> from gutsy
[01:09] <mtaylor> yes. it is, in fact, 0.4.1
[01:11] <spiv> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ seems to be several revisions behind what I'm seeing in your bazaar-commits email
[01:12] <jelmer> arg, looks like I unbound at some point
[01:13] <jelmer> whoops
[01:16] <jelmer> fixed
[01:19] <spiv> jelmer: thanks!
=== mw is now known as mw|out
[02:08] <mtaylor> I've got a FAQ here... what's the magic incantation required to fix this: ERROR: Repository KnitRepository() is not compatible with repository KnitRepository3()
[02:09] <mtaylor> if I remember correctly, I have to specifiy something that is not KnitRepository3, right?
[02:09] <poolie> mtaylor, is one of them from a bzr-svn branch maybe?
[02:09] <poolie> i think you need to upgrade the older-version one
[02:09] <poolie> probably with bzr upgrade --format pack0.92-subtree
[02:11] <jelmer> rather --rich-root-pack, since that is not experimental
[02:11] <jelmer> while all the subtree formats are
[02:11] <poolie> thanks
[02:11] <mtaylor> poolie: well, one of them is a branch of a bzr-svn branch, in the same repo as the bzr-svn branch
[02:11] <poolie> jelmer, do you think we can have that in the default format sometime?
[02:11] <mtaylor> jelmer: so if I bzr upgrade --rich-root-pack, that isn't going to bork my bzr-svn repo?
[02:12] <poolie> by which i suppose i mean, does aaron or anyone have objections to it being on by default?
[02:12] <jelmer> mtaylor, nope, that should be fine
[02:12] <jelmer> poolie: Nope, there is no reason for rich-root-pack not being the default
[02:12] <jelmer> IIRC Aaron has already mentioned he would be in favor of doing so
[02:13] <mtaylor> jelmer: neither bzr upgrade --rich-root-pack or bzr upgrade --format rich-root-pack work for me
[02:13] <docgnome> When using subversion I can do an in place commit by checking out an empty repo and then adding specific files from it. Is there a way to do this with bazaar if i have a centralized repo?
[02:13] <poolie> hm, if it's empty where are you adding the files from?
[02:14] <jelmer> mtaylor: what about "bzr upgrade --pack0.92-subtree" ?
[02:14] <docgnome> from the directory where I checked out the repo
[02:14] <mtaylor> bzr: ERROR: no such option: --pack0.92-subtree
[02:14] <mtaylor> jelmer: bzr too old?
[02:14] <jelmer> ahh, this is not 1.0
[02:14] <jelmer> try --dirstate-with-subtree
[02:15] <docgnome> in this case my home directory. I want to place .emacs and .elisp/ under version control so I can synchronize it between several machines
[02:15] <poolie> docgnome, oh i see - you moved the .svn directory, or you moved the files into the same checkout?
[02:15] <poolie> yes, the same thing wil work with bazaar
[02:16] <mtaylor> jelmer: bingo. that worked...
[02:16] <docgnome> poolie: Hrm... sort of. I made a repo with svnadmin then i check it out without doing an import then i did svn add .emacs and so forth and then a commit
[02:16] <mtaylor> jelmer: and now, I'm going to go figure out why I'm not on 1.0 already
[02:20] <mtaylor> jelmer: not to be a pest - but do you know when bzr-svn will be uploaded to http://bazaar-vcs.org/releases/debs/gutsy ?
[02:20] <poolie> mtaylor, i'm updating the packages
[02:20] <mtaylor> ok,
[02:20]  * mtaylor will now shut up
[02:20] <poolie> i haven't got to bzr-svn yet, though it should be straightforward
[02:20] <jelmer> poolie, Are you also going to upload bzr-svn and bzr-rebase?
[02:20] <poolie> no problem
[02:21] <poolie> jelmer, i hope to, i haven't built debs in a few years so i'm paging it back in
[02:21] <poolie> also trying out https://edge.launchpad.net/~bzr/+archive to build them
[02:21] <jelmer> poolie: Basing it off the version in the Debian pkg-bazaar branches?
[02:21] <poolie> for bzr 1.0 i just carried across the diff
[02:21] <poolie> where is that branch?
[02:22] <jelmer> http://bzr.debian.org/pkg-bazaar/
[02:22] <jelmer> we use bzr-builddeb for everything, already up to date for the latest versions
[02:22] <mtaylor> jelmer: hmm... so bzr-buildeb is stable enough for everyday use? I thought it was "experimental"
[02:23] <jelmer> yeah, I use it for all my Debian work
[02:23] <mtaylor> and can people who aren't you host stuff on bzr.debian.org?
[02:23] <mtaylor> awesome!
[02:23] <mtaylor> I'm going to start using it right now
[02:23] <jelmer> mtaylor: Nope, but there's nothing special about bzr.debian.org.. any bzr-accessible location will do
[02:24] <mtaylor> jelmer: sure... but I was thinking about trying to convince pkg-mysql to move to bzr... not that I expect to make success the first time I suggest it
[02:24] <mtaylor> jelmer: but if there were already an "official" deb place for that stuff...
[02:25] <jelmer> mtaylor: yes, bzr.debian.org is open to everybody with access to alioth
[02:25] <mtaylor> ah. ok. great
[02:25] <mtaylor> good to know
[02:33] <poolie> do you know of any tool to mirror packages from one apt archive to another
[02:41] <mtaylor> jelmer: ROCK!
[02:41]  * mtaylor is VERY happy now
[02:42] <mtaylor> poolie: apt-mirror?
[02:44] <poolie> hm, i think that might overwrite the destination, but i want to combine them...
[02:45] <mtaylor> hm
[02:45] <mtaylor> poolie: I was looking for a tool to make a local apt repos at one point and found one that did what you want
[02:45] <jelmer> mtaylor: ? what made you happy? :-)
[02:45] <mtaylor> jelmer: bzr-builddeb
[02:45] <mtaylor> jelmer: it's my daddy
[02:45] <jelmer> (-:
[02:45] <mtaylor> it is doing _exactly_ what I wanted it to do
[02:47] <mtaylor> poolie: look at reprepro?
[02:47] <mtaylor> and now I don't have to keep 2 different bzr repos and make tarballs for myself
[02:47] <poolie> ah that looks interestning
[02:51] <jelmer> poolie, I'm not sure how important Debian packages on bazaar-vcs.org are
[02:51] <poolie> because they're quickly built into unstable?
[02:51] <jelmer> Since packages are already uploaded to sid
[02:51] <jelmer> yep
[02:52] <poolie> how about people on old releases? would they be built on debian backports?
[02:52] <jelmer> I think there were backports at some point, but bazaar-vcs.org never had anything built for Debian releases afaik
[02:52] <mtaylor> jelmer: I use bazaar-vcs.org to keep current with bzr
[02:52] <mtaylor> oh
[02:52] <mtaylor> nm
[02:53]  * mtaylor is on gutsy... misread statement
[02:53] <jelmer> in fact, it looks like the sid bit of bazaar-vcs.org/releases/debs hasn't been updated since 0.91
[02:54] <lifeless> jelmer: had build problems
[02:55] <lifeless> jelmer: anyhow the point of a debian repo is more important for dailies, but also for when we run ahead of debian (which we do every release cycle)
[02:56] <jelmer> lifeless: right, but that's only relevant for releases, not for sid, no?
[03:03] <abentley> lifeless: Are you still on vacation?
[03:06] <mtaylor> jelmer: bzr-builddeb is making package great - but I'm getting bzr: ERROR: [Errno 13] Permission denied: '../build-area/ndb-connectors-0.5.1.22.18/debian/python-ndb/usr/share/doc/python-ndb/README'
[03:07] <mtaylor> whenever it tried to clean up
[03:07] <mtaylor> is this fixed when I install bzr 1.0 / bzr-svn that comes with it?
[03:07] <poolie> abentley, he is, or is meant to be
[03:07] <poolie> http://bazaar-vcs.org/releases/debs/ says
[03:07] <poolie> >For the current development Ubuntu (aka "sid"), the correct sources.list lines are:
[03:07] <poolie> i guess that's a type
[03:07] <poolie> typo
[03:08] <fullermd> Either that, or you slept through about 15 releases...
[03:08] <poolie> hm, so we don't actually publish packages for older debian anyhow
[03:09] <poolie> jelmer, so what do you suggest we do for debian there?
[03:11] <jelmer> mtaylor: Not sure, I've never seen that error
[03:11] <mtaylor> awesome
[03:11] <jelmer> poolie: support for sid seems pointless to me, if there are already up-to-date packages in sid itself
[03:11] <mtaylor> jelmer: well, I'll see if the new version fixes it, and if not, I'll file a bug
[03:11] <poolie> and for other releases?
[03:12] <jelmer> poolie: for other releases, it would be useful I think, though relying on Debian backports may also be an option
[03:13] <jelmer> poolie, I think the important bit is having the Ubuntu packages up to date
[03:24]  * igc lunch
[03:25] <mtaylor> jelmer: ok. you've solved all the rest of my bzr problems... let me see if you've got this one licked...
[03:26] <mtaylor> jelmer: I've got a repos of debian packaging. I'm going to build packages based on this packaging for dapper, feisty and gutsy
[03:26] <mtaylor> if I make branches for each, I've got to deal with merging the changelog - and that's the only thing that would be different...
[03:27] <mtaylor> is there a better workflow there I'm missing? (I've been editing the changelog by hand for the release, then reverting after debuild -S)
[03:27] <jelmer> nope, can't think of anything, sorry :-/
[03:32] <abentley> ubotu: paste
[03:32] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[03:33] <mtaylor> oh well
[03:33] <mtaylor> 99 out of 100 is still pretty good
[03:34] <abentley> I've gotten a traceback that I think may indicate a bug in the locking code: http://paste.ubuntu-nl.org/48803/
[03:34] <abentley> Could anyone with dirstate knowledge assist me?
[03:35]  * poolie looks
[03:37] <abentley> poolie: It's the sole test case failure I get on this branch: http://code.aaronbentley.com/bzr/bzrrepo/hardlinks
[03:37] <poolie> hm
[03:37] <poolie> it's not obvious to me what wouldbe causing that
[03:37] <poolie> what did you change? :-)
[03:37] <abentley> I made build_tree be able to use a working tree to shortcut retrieving files from the repo.
[03:39] <abentley> It improves best-case branching by something like 6x.
[04:25] <poolie> jelmer, a few people talked about the difficulty of installing bzr-svn because of it needing very recent svn releases
[04:25] <poolie> i guess this is mostly because you're finding bugs in svn or the bindings
[04:25] <poolie> is that right? is there anything we could do?
[04:26] <jelmer> poolie: python-subversion in Ubuntu feisty, gutsy and hardy is recent enough
[04:26] <poolie> oh, ok
[04:26] <poolie> that's great
[04:27] <jelmer> the Ubuntu/Debian packages contain a patch
[04:27] <poolie> people say there's something similar with bzr-gtk?
[04:27] <jelmer> poolie, ?
[04:28] <jelmer> poolie: bzr-gtk should be trivial to install on any Linux system
[04:28] <poolie> ok
[04:28] <poolie> i would have thought so too
[04:28] <jelmer> it's a bit hard on Windows because there are a lot of dependencies to install
[04:28] <jelmer> libglib
[04:28] <jelmer> libgtk
[04:28] <poolie> maybe that was it
[04:29] <jelmer> pygtk
[04:29] <jelmer> gnomesourceview, python-gnome2, etc
[04:29] <poolie> so i guess there the best thing would be an all-
[04:29] <poolie> in-one installer?
[04:29] <jelmer> yep, I think so
[04:30] <jelmer> we'dneed a maintainer for that though..
[04:30] <abentley> A maintainer would be nice, but I'd settle for a test suite that passes.
[04:31] <abentley> The use of _ for i18n makes it blow up for me all the time.
[04:32] <jelmer> bzr-gtk's testsuite?
[04:32] <abentley> yes.
[04:32] <abentley> I have to run bzr selftest -x gtk to avoid spurious failures in my test runs.
[04:32] <jelmer> I'm sure you explained this before, but why is _ a problem?
[04:33] <poolie> the thing i know of is that the python interpreter and debugger use it themselves
[04:33] <poolie> there might be more
[04:33] <abentley> I have no idea, but it's assigned to something that's not a function.
[04:33] <abentley> Tuples, iirc.
[04:44] <abentley> poolie: I've been thinking about the new annotate merge.
[04:44] <abentley> Currently, it looks at all intermediate ancestors to determine whether a line is new or not.
[04:44] <abentley> But perhaps it only needs to look at the border common ancestors?
[04:45] <poolie> yes, i think that might be enough
[04:45] <poolie> it doesn't seem to matter just when it was changed
[04:45] <abentley> That's what I think, too.
[04:45] <poolie> you'd need to be careful to define where that border is though
[04:45] <poolie> if there are multiple common ancestors
[04:45] <poolie> well, you know
[04:46] <abentley> That gets awfully close to the alternate merge3 algorithm I described to you once.
[04:46] <poolie> rigth
[04:47] <abentley> You certainly would need to be careful, but you'd get:
[04:47] <abentley> 1. high performance
[04:47] <abentley> 2. more similarity to merge3 behavior
[04:53] <abentley> jelmer: http://paste.ubuntu-nl.org/48810/
[04:54] <abentley> poolie: In fact, for the non-criss-cross case, it essentially becomes alternate-merge3
[04:55] <abentley> Because you only have one border ancestor, the lca
[04:55] <jelmer> abentley: whoa, odd :-/
[04:56] <jelmer> I'll ask phanatic if he knows a way around it
[04:56] <abentley> jelmer: I'm surprised you haven't encountered it yourself.
[04:58] <abentley> It only happens to me if I run the full suite
[04:59] <abentley> If I only run the gtk tests, they're fine.
[04:59] <jelmer> ah
[04:59] <jelmer> I never ever run the full suite
[04:59] <jelmer> because bzr-builddeb's testsuite fails an import somewhere
[05:00] <jelmer> and bzr-svn's testsuite takes up to half an hour
[05:04] <abentley> I don't have bzr-svn installed, partly for that reason.
[05:04] <poolie> i'm going to take a break as i have calls late tonight
[05:04] <poolie> will be back in an hour or so
[05:06] <bac> jelmer: what is the status of bzr-gtk?  can trunk be made to work with bzr 1.0.-2?
[05:07] <jelmer> bac: trunk works ok with 1.0
[05:08] <bac> jelmer: hmm.  when i try 'bzr viz' i get errors from 'import about'.  any idea what i may have done wrong?
[05:09] <spiv> bac: your bzr-gtk is old
[05:09] <spiv> bac: are you pulling from http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk/ ?
[05:10] <bac> spiv:  yes
[05:10] <Peng> Would running "bzr --no-plugins selftest" avoid running bzr-svn and bzr-builddeb tests?
[05:10] <spiv> bac: not /~bzr/bzr-gtk/trunk?  It moved a while ago.
[05:10] <Petrichor> Hello, I'm fairly new to bzr and am looking for help with bzr-svn. Specifically, how to put my local svn copy under bzr. I was hoping to be able to make regular local commits to my copy and forward the major changes to the svn repository.
[05:11] <jelmer> bac: are you sure it's not http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk ?
[05:11]  * bac looks again
[05:11] <spiv> bac: andrew@steerpike:~/code/bzr-gtk$ bzr revision-info
[05:11] <spiv>  418 daniel.schierbeck@gmail.com-20071211232142-p1ryrdx0jkuoy39f
[05:11] <bac> ah, you're right. it was ~bzr not ~bzr-gtk
[05:12] <nDuff> $ bzr update -> bzr: ERROR: Tree transform is malformed [('non-directory parent', 'new-2801')]
[05:12] <jelmer> Petrichor, simply use "bzr branch"
[05:13] <bac> jelmer, spiv: but i followed the directions here: http://bazaar-vcs.org/bzr-gtk
[05:13] <bac> they need updating
[05:14] <spiv> bac: updated, thanks
[05:14] <nDuff> is there anything I can do to track down this issue? I could very much believe that my working tree is funky -- has a symlink somewhere upstream specifies a directory, or such.
[05:14] <bac> spiv: cool.  thanks.
[05:16] <nDuff> ...hrm; looking at the traceback, MalformedTransform() is being raised from bzrlib.transform.resolve_conflicts (bzrlib/transform.py:1783)
[05:20] <abentley> nDuff: I believe you have found one of the few un-handled conflict cases.
[05:21] <Petrichor> jelmer: so would that be something like >bzr branch svn+ssh://svn.host/repo/path ./
[05:21] <Petrichor> I tried it and it seemed to work
[05:21] <jelmer> Petrichor: Yep, though you would usually specify a directory name as target rather than the current directory
[05:22] <Petrichor> it required that I enter my ssh password 8 times
[05:22] <abentley> nDuff: there's probably a way to determine the relevant file.
[05:22] <nDuff> abentley: hrm. since the only ID I get is "new-2801", and it doesn't correspond with anything in "bzr inventory --show-ids"... where do I go in trying to figure out at least where in my tree this is happening?
[05:22] <jelmer> Petrichor: Yeah, you'd probably want to use a ssh agent
[05:22]  * nDuff doesn't know how to get to the filename from transform.py:1913, where the conflict is detected.
[05:23] <nDuff> (these are bzr-1.0 line numbers)
[05:23] <nDuff> :vs
[05:23] <abentley> path = FinalPaths(self).get_path(trans_id)
[05:23] <nDuff> oops
[05:24] <Petrichor> jelmer: Thanks
[05:25] <nDuff> abentley: ahh.
[05:25] <nDuff> abentley: that gives me exactly what I needed; thanks.
[05:25] <nDuff> abentley: might be useful to make the error message more user-friendly, though. Should I file a ticket?
[05:26] <abentley> Please do.  This should not fail at all, just produce a conflict.
[06:22] <nDuff> hrm.
[06:24] <nDuff> so -- I've got an empty directory as part of my tree. Then someone checks in a revision that changes it to a symlink (and does a lot of other, more desirable things). How do I do a new revision that effectively makes the directory's history contiguous with its old existance? I tried checking out that old tree and re-adding it with --no-recurse --file-ids-from=../old_version, but that yields...
[06:24] <nDuff> ..."bzr: ERROR: File id {p2p_content-20060919172116-lwxfsb0nagsrz1s8-2} already exists in inventory as InventoryLink('p2p_content-20060919172116-lwxfsb0nagsrz1s8-2', u'p2p_content.OTHER', parent_id='var-20060817100627-jl0lksuhbljmn0jt-1', revision=None)"
[06:28] <nDuff> abentley: failure-when-it-should-be-a-conflict issue reported as https://bugs.launchpad.net/bzr/+bug/177390
[06:28] <ubotu> Launchpad bug 177390 in bzr "MalformedTransaction raised in resolve_conflicts()" [Undecided,New]
[06:30] <gdoubleu> should I be able to do a "bzr st -r branch:../upstream" to see what's changed in the branch?  Currently it raises an exception.
[06:32] <fullermd> gdoubleu: Known bug; see bug 144421 and 144300
[06:32] <ubotu> Launchpad bug 144421 in bzr "Using branch: revspec in stat blows up" [Undecided,Confirmed] https://launchpad.net/bugs/144421
[06:32] <ubotu> Launchpad bug 144300 in bzr "bzr log -r branch|ancestor attempt to fetch data in a read only transaction" [High,Triaged] https://launchpad.net/bugs/144300
[06:35] <ubotu> New bug: #177390 in bzr "MalformedTransaction raised in resolve_conflicts()" [Undecided,New] https://launchpad.net/bugs/177390
[06:38] <Snowmotion> Good evening, gentlemen.  I was trying to download the latest bzr 1.0 release via my Ubuntu Feisty installation and Update Manager is giving me the following error:  http://bazaar-vcs.org/releases/debs/feisty/./Packages.gz: MD5Sum mismatch.  Any advice?
[08:03] <docgnome> is there an equivalent in bzr to svn import?
[08:05] <docgnome> I mean... I'd like to have bzr commit make it's commit to another location
[08:05] <TFKyle> bzr add should add all unversioned files in the dir iirc
[08:06] <docgnome> yeah it will add it to the local repo in the .bzr directory right?
[08:06] <TFKyle> (and files in dirs recursively)
[08:06] <docgnome> aye
[08:06] <TFKyle> ah, yeah
[08:06] <docgnome> yeah, I'd like to commit it to another server
[08:06] <TFKyle> not sure how to do it without moving/copying the files
[08:07] <TFKyle> hmm, would pushing to the server work?
[08:07] <docgnome> what I don't know is if after a push doing bzr commit will make the changes to the server
[08:07] <docgnome> guess i should just try it :-)
[08:08] <TFKyle> it won't, if you have a local branch the work flow is typically commit locally then push those commits to the server, you can also do checkouts (see bzr help checkout and bzr help bind) which will send to the server automatically
[08:09] <TFKyle> (oh, and bzr help checkouts of course)
[08:11] <docgnome> ah ha. bind is what i want
[08:11] <docgnome> hrm bzr add said it didn't add 71 files... but it doesn't say what files.. that's not cool.
[08:12] <TFKyle> bzr st should say :)
[08:12] <fullermd> No, it probably won't.  You want 'bzr ignored'.
[08:12] <docgnome> ah ha. it doesn't like object files
[08:13] <docgnome> and... it shouldn't really.
[08:13] <fullermd> That's why they're ignored   :)
[08:13] <TFKyle> oops, read that as "it said it did add 71 files" :)
[08:14] <docgnome> i mean... who wants someone else's object files?
[08:22]  * igc dinner
[08:24] <vila> lifeless: 'Allow arbitrary parameteriZation of tests cleanly' sent to pqm
[09:53] <awilkins_> Anyone here working on the replay branch of bzr-svn?
=== awilkins_ is now known as awilkins
[10:15] <jelmer> awilkins, hi
[10:16] <jelmer> awilkins: Not really atm
[10:16] <jelmer> awilkins: replay wouldn't gain bzr-svn a lot, it's just a minor performance improvement
[13:16] <Verterok> moin
[13:30] <ubotu> New bug: #177454 in bzr "error with checkout" [Undecided,New] https://launchpad.net/bugs/177454
[13:40] <boncola_> try www.montoya.in
[13:41]  * mtaylor whines any complains...
[13:41] <mtaylor> any update on bzr-svn for bzr 1.0 going on to bazaar-vcs.org/gutsy apt?
=== shenson_not_here is now known as shenson
[14:00] <mtaylor> nm... pulling from samba.org
=== mw|out is now known as mw
[16:09] <mtaylor> jelmer: I'm probably  being annoying... but I still love bzr-builddeb. So thanks again for that.
[16:34] <mtaylor>  bzr upgrade --dirstate-tags sftp://monty@bazaar.launchpad.net/%7Endb-connectors/ndb-connectors/devel/
[16:34] <mtaylor> should that really be taking hours?
[16:34] <mtaylor> and what happens if I abort it at this point - is anything  b0rked?
[16:35] <unenough> hi, is there a visual studio integration for bzr?
[16:35] <unenough> i guess there is this: https://code.launchpad.net/bzr-visualstudio
[16:36] <mtaylor> unenough: that would be it, afaik
[16:37] <unenough> is it good?
[16:37] <mtaylor> don't know
[16:37] <mtaylor> it's probably reasonably young
[16:37] <mtaylor> but I haven't tried it
[16:38] <unenough> ok, thanks
[16:39] <orospakr> argh, bzr-svn isn't working: http://pastie.caboo.se/130532
[16:43] <mwhudson> orospakr: well, that looks like you don't have the subversion python bindings installed
[16:43] <orospakr> well, that's what I thought, so I installed them. No joy.
[16:43]  * orospakr checks again, though.
[16:44] <orospakr> yeah, I have both python-svn and python-subversion installed.
[16:45] <orospakr> via ubuntu packages, of course.
[16:51] <ubotu> New bug: #177500 in bzr "Traceback if a command doesn't have a docstring" [Medium,Triaged] https://launchpad.net/bugs/177500
=== phanatic_ is now known as phanatic
[17:21] <jelmer> orospakr, Do you have bzr-svn installed as 'svn' ?
[17:21] <mwhudson> ah haha
[17:21] <jelmer> it looks like you have it as 'bzr_svn'
=== shenson is now known as shenson_not_here
[17:27] <orospakr> ah!
[17:28] <orospakr> yup, all fixed. :)
[17:33] <orospakr> ugh.
[17:33] <orospakr> it still leaks memory all over the place.
[17:35] <orospakr> https://bugs.launchpad.net/bzr-svn/+bug/54253
[17:35] <ubotu> Launchpad bug 54253 in bzr-svn "Excessive memory usage in python-subversion" [Unknown,Confirmed]
[17:36] <orospakr> neat.
[17:38] <jelmer> orospakr: What version are you running?
[17:39] <orospakr> latest of bzr and bzr-svn, but the bug is in svn itself.  I have that from gutsy.
[17:39] <jelmer> the version in gutsy doesn't contain the fixes for the leak yet
[18:03] <orospakr> jelmer, yeah.
[18:03] <orospakr> will it, though?
=== shenson_not_here is now known as shenson
[18:19] <jelmer> orospakr: Hardy will contain the fixes, perhaps those .debs will install on gutsy as well
[18:22] <orospakr> hmm
[18:23] <orospakr> what upstream svn version has the new fixes?
[18:23] <orospakr> the bug on their bug tracker says what revision it's in, not which release. :P
[18:32] <jelmer> there's no release that has the fix yet
[18:32] <jelmer> 1.4.7 will hopefully have it
[18:33] <jelmer> this bug was fixed within the last 24 hours
[18:33] <LarstiQ> "Oh.  That is *so* not permissible.  We'll have to do better than that."
[18:33] <LarstiQ> nice quote
[18:34] <jelmer> hey LarstiQ!
[18:34] <jelmer> How've you been?
[18:35] <LarstiQ> jelmer: Quite unexpectedly ended up in a hospital in Finland to get my appendix removed, now I'm back in The Netherlands and taking it slowly.
[18:35] <LarstiQ> jelmer: probably will not go to the CCC. How about you?
[18:35] <fullermd> Ugh.
[18:35] <jelmer> ouch
[18:35]  * fullermd did that about 10 years ago   :|
[18:36] <LarstiQ> fullermd: the good thing is it isn't supposed to ever get infected again.
[18:37] <LarstiQ> or if it is, it's no longer in my body anyway ;)
[18:37] <fullermd> Well, that's the theory.  I'm sure if there is a way, I'll find it...
[18:37] <fullermd> When it happened, I lived a good thousand miles thataway (*vague gesture*).  I'm hoping it won't be able to track me down.
[18:37] <jelmer> LarstiQ: Not sure yet. I'm going to Germany anyway in the next couple of days and have some deadlines to make before the end of the yet.
[18:38] <LarstiQ> jelmer: that was also a more general, how are you doing :)
[18:39] <LarstiQ> fullermd: ah yes, in my case I'm afraid I'll return to the area where I left it, no safety in distance then.
[18:39] <jelmer> LarstiQ: ah :-) I'm ok, happily trying to fix bugs in various pieces of software
[18:39] <jelmer> LarstiQ, and trying to finish those last few courses...
[18:40] <jelmer> s/yet/year/
[18:40] <LarstiQ> jelmer: eek, courses :(
[18:45] <orospakr> LarstiQ, yeah, that was pretty funny.
[18:45] <orospakr> but what I don't get is, this bug has been around for more than 6 months.
[18:45] <orospakr> April/May, at least.
[18:47] <jelmer> it's been around a lot longer than that actually
[18:47] <jelmer> lots of bugs are that old...
=== Verterok is now known as Verterok_
[19:49] <orospakr> jelmer, do you figure hardy's debs already have the fix?
[19:54] <jelmer> orospakr: No, they don't have them yet afaik
=== mw is now known as mw|food
=== mw|food is now known as mw
=== Verterok_ is now known as Verterok
[22:45] <MisoGEN> What's the correct connection string for bzr+ssh over a non-standard port? It's on windows.
[23:12] <igc> morning
=== Verterok is now known as Verterok_
[23:28] <lifeless> poolie: sorry about going quiet there; ELOCAL :)
[23:34] <poolie> np
[23:35] <lifeless> anyhow, as I was saying - merry chrismas and new years, to you & steph.
[23:37] <poolie> thanks, and to you