[00:00] <lifeless> hi
[00:00] <uws> Ok, so I'm trying to branch mysql-server/5.1 from launchpad
[00:00] <uws> I've set my launchpad login using "bzr lp-login" previously
[00:00] <uws> but now the branching fails with a   Permission denied (publickey)    error message
[00:01] <uws> I just want a checkout, nothing fancy.
[00:01] <lifeless> uws: its using bzr+ssh
[00:01] <uws> so?
[00:01] <Jc2k> uws: the lp: foo doesnt know whether your pulling or pushing, so always goes through bzr+ssh
[00:01] <lifeless> uws: and your public key is either not registered with lp, or no available to your local ssh
[00:02] <uws> note that I'm not involved with mysql, is that a requirement?
[00:02] <lifeless> no
[00:02] <mwhudson> mkanat: having fun yet?
[00:02] <mwhudson> uws: not at all
[00:02] <lifeless> uws: 09:01 < lifeless> uws: and your public key is either not registered with lp, or no available to your local ssh
[00:02] <uws> mwhudson: I thought it might be trying my login first, and failing in falling back to anonymous checkout.
[00:02] <uws> anyway, I'll check my ssh keys\
[00:04] <uws> ah, there we go. Launchpad only knew about my laptop's ssh key
[00:04] <uws> thanks
[00:05] <mwhudson> cool
[00:16] <lifeless> _argh_ evolution
[00:17] <awilkins> gcc -version
[00:17] <awilkins> oops
[00:19] <awilkins> jelmer: Those C extensions are not compiling for me.
[00:21] <lifeless> poolie_: I'm going to try to finish stacking-kints today
[00:25] <jelmer> awilkins: what errors do you get?
[00:26] <lifeless> mwhudson: I get
[00:26] <lifeless> Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
[00:26] <awilkins> initializer element is not constant
[00:26] <jelmer> lifeless: Hmm, looks like it's failing to do proper caching in the case of bzr-search
[00:26] <lifeless> mwhudson: when trying server-branches
[00:26] <jelmer> lifeless: Looking into it further...
[00:26] <lifeless> jelmer: thanks
[00:26] <lifeless> jelmer: its lock_read'd, and fast on bzr branches
[00:26] <mwhudson> lifeless: hm
[00:26] <lifeless> 500MB/hour now
[00:26] <awilkins> jelmer: core.c (73) ; looks like it doesn't like the sizeof call setting the initial value
[00:27] <awilkins> jelmer: This is gcc 3..4.5
[00:27] <mwhudson> lifeless: more details?  which directory are you running from, what url are you trying to view?
[00:27] <lifeless> mwhudson: http://www.robertcollins.net/
[00:28] <lifeless> mwhudson: I cd'd to that dir on the fs; ran python ~/source/loggerhead/bzr-search.integration/serve-branches.py;
[00:28] <lifeless> mwhudson: clicked on config-manager
[00:28] <lifeless> (note my html pages are woefully old; ignore that aspect :P)
[00:29] <lifeless> config-manager/ has a subdir trunk that is a branch
[00:29] <lifeless> config-manager/ is not a repository
[00:29] <mwhudson> i wonder if this is dir -> dir/ redirection going strange then
[00:30] <poolie_> lifeless: hi
[00:30] <lifeless> the url that it wanted was config-manager/, yes
[00:30] <lifeless> poolie_: ho
[00:30] <jelmer> awilkins: Hmm, that's an old version
[00:30] <jelmer> awilkins: core.c is not there anymore
[00:30] <jelmer> awilkins: What branch are you using?
[00:30] <awilkins> lp:bzr-svn
[00:30] <jelmer> awilkins: the mirror is probably out of date
[00:31] <jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.4
[00:31]  * awilkins pulls
[00:31] <mwhudson> lifeless: i can't reproduce here
[00:32] <mwhudson> lifeless: are there proxies involved or anything?
[00:33] <lifeless> http://rafb.net/p/q5BkUZ65.html
[00:33] <lifeless> mwhudson: not yet
[00:34] <awilkins> jelmer: Darn, more setup.py blues
[00:34] <mwhudson> lifeless: paste version?
[00:35] <lifeless> feisty
[00:35] <mwhudson> lifeless: as in, which version of python-paste
[00:35] <mwhudson> hmm
[00:35] <awilkins> jelmer: apr-config naturally doesn't run on Windows so I have this awesomely bad patch to make it work :-|
[00:35] <lifeless> mwhudson: 1.1.1-1
[00:35] <mwhudson> ok, that's definitely older than what has been tested so far
[00:35]  * mwhudson goes to try to find a changelog
[00:36] <lifeless> its on my todo to upgrade
[00:36] <lifeless> but, time.
[00:36] <mwhudson> yeah
[00:38] <awilkins> jelmer: Right, It's too late to hack this into shape, I'll get back to it. Gnight
[00:38] <mwhudson> lifeless: changes from 1.1 -> 1.2:
[00:38] <mwhudson> * Regression in 1.1 fixed, where Paste's HTTP server would drop
[00:38] <mwhudson>  trailing slashes from paths.
[00:39] <lifeless> mwhudson: fuckers.
[00:39] <lifeless> why can't all software have /tests/
[00:51] <mwhudson> like loggerhead, for example...
[00:53] <lifeless> mwhudson: this is a bit of a show stopper though ;P
[00:53] <mwhudson> lifeless: i don't really have any good ideas
[00:54] <lifeless> for starters, document paste 1.1 as fuxored and check it at startup
[00:54] <mwhudson> python-paste is pure python, there's a good chance the deb from hardy will install fine i guess
[00:54] <lifeless> mwhudson: na-uh, python-central
[00:54] <lifeless> mwhudson: pure python doesn't mean what you think it does in a binary distribution world
[00:55] <mwhudson> well, perhaps
[00:56] <mwhudson> but getting a newer version installed somehow shouldn't be difficult
[00:57] <lifeless> it would be a backport
[00:58] <lifeless> I'm not terribly interested in doing that; I'll just not play with loggerhead for a while
[00:58] <mwhudson> 'for a while' -- until you get around to dist-upgrade?
[00:58] <lifeless> yes
[00:58] <lifeless> probably august or so
[01:04] <lifeless> doing an adhoc backport is a nuisance; its a local delta, the package manager will try to uninstall it under various circumstances, i need to setup a temp archive, or build it in a ppa
[01:05] <mwhudson> well, you could probably just untar a paste release and use PYTHONPATH
[01:05] <lifeless> which then becomes a sysadmin thing-to-remember
[01:06] <lifeless> and for my home server I want as close to 0 of them as possible
[01:06] <lifeless> its not a _high_ burden, but they sum
[01:06] <lifeless> and it deifnitely raises the effort past what I'm willing to do to experiment with loggerhead
[01:07] <lifeless> - its not 'easy' at this point
[01:09] <mwhudson> well, ok
[01:09] <lifeless> mwhudson: I guess I should note that having spent days+ of effort on loggerhead for squid-cache.org, I'm not enthused about more time
[01:09] <mwhudson> i can't really see anything i can do to help here
[01:09] <lifeless> mwhudson: as a consumer of it, its a different feel to a developer
[01:10] <lifeless> mwhudson: I don't think there is much to do; I guess loggerhead could in theory ship a fixed paste function and monkey patch affected versions; but thats quite a lot gross
[01:11] <mwhudson> gutsy has paste 1.4 that i suspect will work
[01:11] <mwhudson> _my_ interest in supporting feisty is not so large
[01:11] <lifeless> I have a sinking feeling about freebsd though
[01:12] <lifeless> I'm not looking forward to finding out what version it has
[01:12] <lifeless> fullermd: feel free to give me good news about now
[01:12] <fullermd> [19:12:09] mortis:/usr/ports/www/py-paste                                       (ttyp9):{550}% make -V PORTVERSION
[01:12] <fullermd> 1.6
[01:12] <lifeless> ok, thats good news
[01:13] <fullermd> It's usually pretty good about being up-to-date on things.  It's just the occasional exceptions like TG that really monkeywrench things   :|
[01:13] <mwhudson> i'd like to monkeywrench tg
[01:13] <lifeless> fullermd: to be fair, I suspect that's tg's fault
[01:13] <mwhudson> i guess it's not a problem for me any more
[01:13] <lifeless> mwhudson: what would it take to make bb not need tg ? :)
[01:14] <mwhudson> lifeless: oof
[01:14] <mwhudson> don't know, probably quite a bit i guess
[01:14] <lifeless> because BB is still not properly operational for squid
[01:21] <abentley> lifeless: It would require an alternative identity layer.
[01:21] <mkanat> mwhudson: Sorry, was away for a bit there.
[01:21] <mkanat> mwhudson: I'm back now, I'll try that patch.
[01:21] <lifeless> abentley: thats a tg supplied thing ?
[01:22] <abentley> Yes, it handles users, groups, permissions, passwords, that sort of thing.
[01:22] <lifeless> k
[01:23] <abentley> lifeless: believe me, I've thought about it.
[01:23] <lifeless> abentley: :>
[01:24] <mkanat> mwhudson: Yep, that does it. I have to make webpath = '', though, not actually comment it out.
[01:25] <mwhudson> mkanat: hm, strange, but glad you've got something working
[01:26] <Verterok> mornin'
[01:27] <mkanat> mwhudson: Without it I get: http://pastebin.ubuntu.com/22252/
[01:28] <mwhudson> mkanat: with this patch? http://pastebin.ubuntu.com/22228/
[01:29] <mkanat> Oh, hmm.
[01:30] <mwhudson> but anyway, it works, good :)
[01:30] <mkanat> mwhudson: Ah right, when I use teh *actual* patch it works, yes. :-)
[01:31] <mkanat> Now let's see if I can figure out what's causing those tracebacks.
[01:37] <mkanat> mwhudson: Unfortunately GoogleBot doesn't send referers. :-(
[01:37] <mwhudson> mkanat: yeah :/
[01:38] <Verterok> abentley: hi, did you notice the mail/branch about BB on mysql? :-)
[01:38] <mwhudson> mkanat: can you see what the file id in the url is for?
[01:38] <abentley> Verterok: I see it now.
[01:39] <Verterok> abentley: in case you want to migrate it to mysql, I already have the env setup, etc...and I'm willing to do it ;-)
[01:39] <abentley> Verterok: I want to migrate to postres
[01:39] <Verterok> ups :P
[01:39] <mkanat> mwhudson: It's for a file.
[01:40] <mwhudson> mkanat: any particular one?
[01:40] <Verterok> I can abstract the scripts to have multiple dest. engine
[01:40] <mwhudson> or is it a variety?
[01:40] <mkanat> mwhudson: It's a variety.
[01:40] <mwhudson> hum
[01:40] <mkanat> mwhudson: However, they're all in the same branch, which might actually have errors in it, since it was made by cvsps-import.
[01:41] <mwhudson> i can't really imagine how a branch could be _this_ broken :)
[01:42] <markh> abentley: re that "Trivial UI Change" patch - it seems to me that the 2 strings are actually 2 params - so the spacing was correct in the initial patch
[01:42] <mkanat> mwhudson: Hmm, might be a race condition--I can open that URL fine.
[01:42] <mwhudson> mkanat: ??
[01:43] <mwhudson> but i thought you said it was a file id for a file?
[01:43] <abentley> markh: You're right.  I saw what I expected to see, not what was there.
[01:43] <mkanat> mwhudson: I picked out one of the URLs that caused a traceback, and when I open it, there's no problem.
[01:43] <markh> and while I'm here :)  In my case at least, that message really means "your bzr package is missing something that allows you to do successful ssh" - but strangely, the log in that case does mention that the 'ssh implementation is Putty's plink.'
[01:44] <markh> if I use a bzr.exe from a binary package, it works correctly
[01:44] <mwhudson> mkanat: that's really odd
[01:44] <mkanat> mwhudson: Hmm, or something is wrong with logging--my on-disk debug.log contains no tracebacks, I only saw them with -f -- that could be coincidental, though.
[01:44] <markh> my bzr is probably not finding paramiko - is there a recommended way to enable debugging messages for that kind of thing?
[01:45] <abentley> markh: So the problem is that the orig_error param is being misused.
[01:45] <markh> abentley: yes, that that seems true
[01:46] <markh> well, that is *a* problem, not *the* problem ;)
[01:46] <abentley> markh: There are other problems remaining?
[01:47] <mkanat> mwhudson: Well, it's not causing any visible problem anyhow.
[01:47] <mwhudson> mkanat: ok
[01:47] <markh> well - the original problem was simply the recommendation to "-D..." - thats independent of the orig_error abuse :)
[01:47] <markh> A possible remaining problem is that bzr is being less than helpful - the problem appears to be some inability to auth or otherwise do something related to ssh.
[01:47] <mkanat> mwhudson: So let's take the one last visible problem that I see--my auto_publish branches have their on-disk path as their bzr URL on the frontpage.
[01:48] <mkanat> mwhudson: My non-auto-publish branches have the correct URL.
[01:48] <markh> I do see a message "No supported authentication methods left to try!" so putty is trying to do someting
[01:48] <mkanat> mwhudson: Because I specified it, of course.
[01:48] <markh> but my "connectivity and permissions" are fine (which is what bzr suggests I check)
[01:49] <mwhudson> mkanat: this is probably my url_prefix fix being wrong
[01:49] <markh> abentley: so even if that isn't really a bug in bzr, any suggestions how I can diagnose what is missing myself?
[01:51] <markh> (to be clear - putty etc is all setup fine - it works perfectly if I use 'bzr.exe' instead of a source distro)
[01:54] <lifeless> have you tried -Dtransport?
[01:54] <markh> hi lifeless - tried nothing yet, still fishing for clues.  I'll try it!
[01:56] <markh> Output appears identical with -Dtransport
[01:56] <markh> log too
[01:56] <lifeless> ok
[01:56] <lifeless> uhm
[01:56] <lifeless> python -c 'import paramiko'
[01:56] <markh> yeah, I'm confident that will fail
[01:57] <markh> but how could I have bzr tell me that? :)
[01:57] <markh> ie, I'm not sure what else I don't know I don't have!
[01:58] <abentley> markh: the suggestion to use D... was orig_error abuse.
[01:59] <markh> abentley: yeah - I was just saying that the original error was the text itself with is largely independent of the abuse that was uncovered while looking at it
[01:59] <mwhudson> mkanat: try this: http://pastebin.ubuntu.com/22255/
[02:00] <markh> as usual, take one bug, get a few for free!
[02:01] <abentley> markh: If you want to act clever, that's fine.  But I don't need to be involved.
[02:01] <markh> abentley: sorry, that wasn't my intent
[02:02] <mkanat> mwhudson: Yes, that works! :-)
[02:03] <mwhudson> mkanat: cool, i'll commit it then
[02:03]  * markh gets back in his box...
[02:03] <abentley> markh: If you want to diagnose why putty can't make a connection, I'd start by running putty.
[02:03] <mwhudson> mkanat: i'll try to work on the server.webpath thing too, that's going to take a bit more thinking though i expect
[02:03] <markh> putty can connect fine
[02:04] <mkanat> mwhudson: No, that works.
[02:04] <mkanat> mwhudson: I just had read the patch wrong (I did it manually).
[02:04] <abentley> markh: I wasn't even aware that putty could be used for this.  I would have thought plink
[02:04] <mwhudson> mkanat: i'd like to remain compatible with old loggerhead.conf files
[02:05] <mkanat> Ahh.
[02:05] <abentley> But I guess the next step would be to find out what line bzr is emitting to connect.
[02:05] <markh> yes, putty's plink
[02:05] <abentley> So to be clear: plink can connect just fine?
[02:07] <markh> yes, plink can connect fine.  Putty's pageant is the only program with my ssh key loaded
[02:08] <markh> so when bzr.exe successfully does ssh, I expect that is also via plink
[02:08] <markh> but when 'python bzr' does not connect via ssh, the bzr log still indicates it is using putty's plink
[02:09] <abentley> markh: I wouldn't be surprised if bzr.exe is using paramiko.
[02:09] <abentley> bzr can use pagent.
[02:10] <markh> yes, which uses plink :)  I'm not aware of enough of the internals to know if bzr will attempt to use putty *without* paramiko.  I'm not even 100% sure paramiko missing is the problem :)  I was hoping to find something that might tell me so I'm not playing a game of trial-and-error is all.
[02:11] <lifeless> markh: we use paramiko for sftp logic, not encryption
[02:12] <abentley> markh: What makes you say pagent uses plink?  I would have assumed that plink uses pagent, not the other way around.
[02:12] <markh> I meant paramiko uses plink (or at least it has *some* interaction with putty's suite - it talks to pageant's window iirc)
[02:13] <abentley> markh: It interacts directly with pagent AIUI.
[02:13] <abentley> It does not have to invoke plink to do it.
[02:14] <markh> ok - but I'm confident pageant/plink/putty etc are all configured correctly
[02:15] <lifeless> abentley: how does make_mpdiffs returning a dict sound to you?
[02:15] <lifeless> abentley: (that or (key, diff) tuples)
[02:17] <abentley> lifeless: I'd prefer key, diff tuples, so the API doesn't demand loading many file versions in memory at once.
[02:19] <lifeless> abentley: ok
[02:19] <abentley> markh: So you probably want to look at bzrlib.transport.ssh.PLinkSubprocessVendor
[02:19] <lifeless> abentley: I won't guarantee to get to it; but it irritated me to have to zip() in bzr-search over the weekend
[02:19] <lifeless> abentley: and as we have a massive api break occuring this would be timely
[02:22] <abentley> lifeless: If we're breaking the API, maybe it should accept keys instead of revision ids.
[02:48] <lifeless> hmm
[02:48] <lifeless> poolie_: can I call ?
[02:49] <lifeless> hmm EAFTP I guess :P
[03:34] <ToyKeeper> What's this?  API changes which could reduce memory use?  :)
[03:34] <ToyKeeper> (last time I did a "bzr branch lp:bzr", it failed until I allocated 200+MiB RAM for it)
[03:35] <lifeless> ToyKeeper: heh. I have test cases that chew up 3-4GB of ram
[03:41] <ToyKeeper> I finally got around to setting up a bzr server on my openvz host, and was surprised to see branching fail due to memory limits.
[03:41] <ToyKeeper> It's easy to bump up the limit, at least.  :)
[03:55] <beuno> hey mwhudson_
[03:55] <mwhudson_> hi beuno
[03:55] <beuno> I did notice it. Scratched an itch I had  :)
[03:55] <beuno> how was your weekend?
[03:56] <mwhudson> fine, fine
[03:56] <mwhudson> we're moving this week, so lots of packing and tidying
[03:56] <beuno> ah, and maybe a better ISP?   :)
[03:56] <mwhudson> we shall see
[03:58] <mwhudson> beuno: i played with the merge proposal stuff in launchpad, you probably got some mails about that
[03:58] <beuno> mwhudson, ah, yes. I was about to ask if you really wanted me to review it or it was a proof-of-concept
[03:58] <mwhudson> beuno: i'd like you to look at it, yes
[03:59] <lifeless> so
[03:59] <lifeless> the big thing remaining for gnome seems to be branding?
[03:59] <lifeless> Jc2k: ^?
[04:00] <beuno> mwhudson, cool. That reminds me, now that I can commit to trunk, how would you like the workflow to be?  Commit trivial stuff directly, review bigger changes?  Review everything?  I don't want to step on any toes  :)
[04:01] <mwhudson> beuno: i think trivial stuff is ok to push directly, but if in doubt get it reviewed
[04:01] <mwhudson> (not necessarily by me, i suppose)
[04:01] <Suigintou> anyone have any experience serving a repository over bzr+ssh on a chrooted shell?
[04:02] <lifeless> not directly; but in theory yes
[04:02] <lifeless> whats up
[04:03] <Suigintou> I tried setting it up with jailkit, but bzr doesn't like the new root directory permissions enforced by jailkit (the root dir must be owned by root)
[04:03] <lifeless> I don't see why bzr would care about that
[04:04] <Suigintou> me neither, hehe
[04:06] <lifeless> well, why do you think it is the root dir owner thats the problem?
[04:06] <Suigintou> I was getting an error message along those lines in auth.log
[04:07] <Verterok> jelmer: around?
[04:07] <lifeless> whats auth.log
[04:07] <lifeless> its not a bzr file
[04:07] <Suigintou> it's the log file that ssh logs error messages to, located in /var/logs
[04:08] <Suigintou> er, /var/log
[04:08] <beuno> mwhudson, I get OOPS-905EB7 when reviewing your merge request  :)
[04:08] <lifeless> sounds like ssh is having the problem then
[04:08] <mwhudson> beuno: :)
[04:08] <lifeless> [I need more detail - I can't guess at what an error message I haven't seen means]
[04:09] <beuno> mwhudson, seems it works if I specify the *optional* subject
[04:09] <mwhudson> beuno: oh that
[04:09] <lifeless> poolie_: ping
[04:09] <mwhudson> it's a known bug, to be fixed soon
[04:10] <beuno> does this merge automagically?
[04:10]  * igc lunch
[04:10] <mwhudson> beuno: no
[04:11] <mwhudson> oh, this does remind me
[04:11] <mwhudson> serve-branches.py currently just sticks the cache in some temporary directory
[04:11] <mwhudson> this probably isn't totally smar
[04:11] <mwhudson> t
[04:12] <beuno> serve-branches.py doesn't use anything from loggerhead.conf, right?
[04:13] <Suigintou> haha
[04:13] <Suigintou> now that I'm looking through auth.log, I see that someone has been trying to brute force their way into my server, time to run ssh on a non standard port :)
[04:14] <mwhudson> beuno: right
[04:15] <beuno> mwhudson, is that out of choice or just "was faster at the time"?
[04:15] <mwhudson> beuno: a bit of both, but mostly the former
[04:17] <beuno> so the plan is to use something else for configuration?
[04:17] <Suigintou> co
[04:17] <mwhudson> beuno: you perhaps do me a bit too much credit to assume i have a plan :)
[04:18] <beuno> hahaha
[04:18] <beuno> I may be still a bit naive, I'll get over it eventually
[04:18] <mwhudson> wee
[04:18] <mwhudson> well
[04:18] <mwhudson> i guess the first thing to decide, in fact, is: what configuration do we actually need?
[04:19] <mwhudson> s/we/people/
[04:19] <beuno> what port to run, where to cache, and what to publish, for starters
[04:20] <beuno> I suppose then it would get expanded to *what* to cache (search, ie), and new features like exporting tarballs and serving repos
[04:20] <mwhudson> proxying details
[04:21] <beuno> is there something very wrong about the current conf file?
[04:22] <jamesh> maybe it still has some turbogears stink on it
[04:22] <mwhudson> i find it's way of listing which branches to show and where in the url hierarchy to show them to be almost entirely bogus
[04:23] <mwhudson> i think that's my main complaint
[04:23] <mwhudson> and yeah, it's a bit tg-ish
[04:25] <beuno> right. I've been avoiding getting into some parts of the new code because I'm not sure where it's headed.  Is there some config file you where thinking of making it similar to?
[04:25] <mwhudson> no
[04:25] <mwhudson> to be honest, the main use cases i've been thinking around are
[04:26] <mwhudson> ...
[04:27] <beuno> uhm, my X restarted for no apparent reason
[04:27] <mwhudson> beuno: wb
[04:27] <beuno> L)
[04:27] <beuno> so, last I read was what you where thinking of
[04:28] <mwhudson> (1) zero configuration (serve-branches.py)
[04:28] <mwhudson> (2) Launchpad (custom WSGI glue)
[04:28] <mwhudson> i'm less sure of a good answer for a middle ground
[04:29] <mwhudson> someone who has a bunch of branches they want to serve using ProxyPass from their site and who doesn't really want to write code
[04:31] <beuno> I think that's a bit too drastic. It should be easy to enable/disable certain features, at least if we want to keep building on top of it
[04:32] <lifeless> poolie_: whhat do you think; committing against a revision only present in a stacked-on repository; should it delta [always], delta[usual algorithm], never-delta?
[04:32] <beuno> adding per-branch configurations seems to me like a normal operation
[04:32] <mwhudson> hmm?
[04:32] <beuno> (2) Implies coding, right?
[04:33] <beuno> tweaking a .py file?
[04:34] <mwhudson> i'm not saying that these are the only things we should support
[04:34] <mwhudson> but rather that these two cases are where the bulk of my thinking has gone so far
[04:34] <beuno> ah, ok. Well, maybe we can work something out on a wiki page or something
[04:35] <beuno> zero configuration is good to have, will get people using it faster
[04:46] <mwhudson_> sigh
[04:46] <lifeless> mwhudson_: I believe you can buy it in a box
[04:58] <beuno> it's a bit odd to get an email for a merge request, and then for a review request
[04:58] <beuno> isn't a merge request a review request by itself?
[05:03] <igc> reviewing jam's iter_references patch now
[05:03] <beuno> mwhudson, LH is misbehaving in LP again.  "Please try again" pretty often
[05:04] <lifeless> 14:03 < beuno> mwhudson, LH is misbehaving in LP again.  "Please try again" pretty often
[05:04] <lifeless> mwhudson_: who is your ISP
[05:04] <mwhudson> lifeless: ihug
[05:05] <lifeless> oh
[05:05] <mwhudson> i think it's problems with the line, but i'm moving in three days
[05:05] <lifeless> I don't know that it is :P
[05:06] <mwhudson> hm, it's codehosting that's bashing vostok currently
[05:08] <mwhudson> beuno: so re bug 240512, i think your change will sort symlinks after directories and files
[05:08] <mwhudson> beuno: is that what we want?
[05:08] <mwhudson> beuno: and also, i don't think we want to still put directories first when the user is trying to sort by name
[05:08] <lifeless> I don't think we want that
[05:09] <jml> So I've been working on a thread in a loom.
[05:10] <jml> And I've realised that the top thread should actually be the next-to-bottom thread.
[05:10] <lifeless> make a new thread over it it
[05:10] <lifeless> merge -r thread:thing..thread: . into it
[05:10] <lifeless> commit
[05:10] <beuno> mwhudson, well, ideally, no. A more complex ordering way would be better, but I cherrypicked that off my new-theme branch, since it's so ugly to see it ordered as currently. Nautilus orders directories before files by name ordering, so that seemed natural to always have
[05:10] <lifeless> combine-thread the one you want to get rid of
[05:10] <lifeless> up-thread and commit till its all resolved
[05:11] <lifeless> get on wif ur life
[05:11] <lifeless> hmm
[05:11] <jml> lifeless: that merge will lose my commit history, right?
[05:11] <lifeless> actually, I think you need to do a reverse merge too into the one you're removing the change from
[05:11] <lifeless> there is a TODO about making this easier
[05:11] <lifeless> jml: yes, see under 'its a cherrypicking problem'
[05:12] <jml> lifeless: just checking. I'm ok with losing history this time, I think.
[05:13] <mwhudson> beuno: well i think that's crazy :)
[05:13] <lifeless> I think matching nautilus is ok
[05:13] <beuno> mwhudson, all other applications I've fired up do it that way
[05:13] <beuno> what kind of ordering is "directories first then"?
[05:14] <beuno> as in, how would I go back to it once I order by name?
[05:14] <mwhudson> the finder doesn't put folders first :)
[05:14] <mwhudson> but i guess i don't care very much
[05:15] <beuno> mwhudson, it doesn't order directories first by default?
[05:15] <mwhudson> no
[05:16] <beuno> and that doesn't feel wrong to you?
[05:16] <mwhudson> when you order by name, it put things in ... name order
[05:16] <beuno> and how do you go back to ordering by directory-first?
[05:16] <mwhudson> i have to admit, i don't use a graphical file browser very much at all on any system
[05:16] <mwhudson> beuno: you don't
[05:17] <beuno> that's what I was worried about  :p
[05:24] <poolie_> lifeless:  oh my client had disconnected that's why i didn't see it
[05:24] <lifeless> poolie_: ah
[05:24] <lifeless> poolie_: you use a irc poxy?
[05:24] <poolie_> ssh to a server
[05:24] <poolie_> running screen
[05:25] <thumper> how do I make a thread in a loom between two?
[05:25] <thumper> does create-thread make it directly above the current thread?
[05:25] <lifeless> yes
[05:26] <thumper> ta
[05:28] <Peng> With PrefixMiddleware in serve-branches.py, shouldn't there be arguments passed to it? Is it just example code?
[05:30] <mwhudson> Peng: no, it works off x-forwarded-server
[05:31] <mwhudson> you might need to add a prefix
[05:31] <Peng> Oh.
[05:31] <Peng> Yeah.
[05:31] <Peng> I am using a prefix.
[05:31] <mwhudson> then yeah, you need to edit code
[05:32] <mwhudson> if you can tell me how you'd like to specify this sort of thing, then i can see what i can do :)
[05:33] <Peng> Oh, I dunno.
[05:33] <Peng> Maybe just a "prefix = None" line you can edit.
[05:34] <Peng> Though, since I need the prefix middleware, I'd probably take out the try...except to force it to error out so I'd see it.
[05:35]  * Peng wanders off. 24 is on!
[05:35] <thumper> when I up-thread in a loom, should I commit?
[05:35] <thumper> hmm
[05:35] <thumper> status seems to indicate I should
[05:36] <lifeless> if there were unintegrated changes, yes
[05:36] <lifeless> up-thread is 'switch and then merge '
[05:36] <Suigintou> ahh, I fixed my problem with getting bzr+ssh working from a chrooted shell, I forgot to make python available to the shell, lol
[05:38] <lifeless> Suigintou: that would cause bzr some trouble, yes.
[05:38] <thumper> lifeless: I am quite enjoying my first use of looms-in-anger
[05:38] <lifeless> thumper: great
[05:38]  * thumper makes note to write about it
[05:53] <igc> looking at spiv's patch re Remote-2 tests now
[06:27] <beuno> mwhudson, sorry for the spam on merge-proposals. It confuses me a lot
[06:45] <Peng> Hmm, I think the latest changes caused Loggerhead to use more RAM on startup.
[06:46] <Jc2k> morning lifeless
[06:46] <beuno> Peng, how "latest"?
[06:46] <Jc2k> the guadec-web module seemed to choke bzr index - it was at it all night
[06:46] <Peng> beuno: trunk as of an hour ago vs. trunk as of...a few hours ago.
[06:48] <Peng> r166 vs. r171.
[06:49] <beuno> Peng, interesting. Can you revert to 169 and see if the problem persists?
[06:49] <lifeless> Jc2k: interesting. how big is that modules .bzr/repository ?
[06:49] <Peng> Urgh.
[06:52] <Peng> beuno: It used to use 11856 KB. 171 uses 12544 and 169 uses 12244.
[06:53] <spiv> igc: thanks for the review
[06:53] <igc> spiv: no problem
[06:53] <beuno> hrm, so it's not the author bit. mwhudson_, any idea what could of caused the jump since rev166?
[06:54] <beuno> maybe urlparser import, but 1mb is quite a jump
[06:55] <Peng> This is odd.
[06:55] <Peng> 166 is using 12244 too.
[06:55] <beuno> did your repos get bigger?
[06:55] <Peng> Does Loggerhead end up importing Bazaar's plugins?
[06:56] <lifeless> yes
[06:56] <lifeless> I don't think it loads them all
[06:56] <lifeless> but it will try for ones it uses itself
[06:57] <Peng> I upgraded bzr-svn recently..
[06:57] <Peng> Nothing else though,
[06:57] <Peng> Anyway, there was still a 300 KB increase between 169 and 171, I think.
[06:58] <beuno> it may be due to trying to get the author, if there is one. It may be a fair tradeoff  :)
[07:00] <beuno> I'm off to bed
[07:00] <beuno> g'night everyone
[07:01] <Peng> It's right after startup, without any hits.
[07:01] <Peng> Good night. :)
[07:02] <vila> beuno: don't go to bed yet ! Just send me a quick reply :)
[07:03] <Peng> Did someone forget to write a template for the directory index page?
[07:03] <beuno> damn! I knew I should of closed the laptop  :p
[07:03] <Peng> :D
[07:03] <beuno> vila, I'll get to it now
[07:04] <beuno> Peng, directory index?
[07:04] <vila> beuno: great :)
[07:04] <beuno> vila, chmod bits?
[07:04] <vila> yup, working version already pushed
[07:04] <Peng> beuno: Like, when you're outside of a branch, and it just lists directories. http://bzr.mattnordhoff.com/loggerhead/
[07:04] <igc> that's it for me today - off to see a doctor
[07:05] <igc> see you all tomorrow
[07:06] <beuno> Peng, ah, that's mwhudson_'s black magic. We probably will need to wrap that around a template
[07:06] <Peng> loggerhead.apps.filesystem.BranchesFromFileSystemServer.directory_listing
[07:10] <beuno> vila, sent
[07:10]  * beuno is off
[07:11] <lifeless> bye beuno
[07:11] <beuno> Peng, could you file a bug for that
[07:11] <lifeless> beuno: also any word on theming for gnome-mirror?
[07:11] <Peng> beuno: okay
[07:11] <vila> beuno: thanks, sleep well :)
[07:12] <Jc2k> lifeless:
[07:12] <Jc2k> x469yq@isshin:/srv/bzr/guadec-web/.bzr$ du -s repository/
[07:12] <Jc2k> 338308  repository/
[07:12] <beuno> lifeless, not yet. It turns out that the current theme is a bit sucky to edit. I will get something reasonable in the next few days, if Jc2k can wait that long  :)
[07:12] <lifeless> beuno: cool
[07:12]  * Jc2k can't wait
[07:12] <Peng> Theme of what?
[07:13] <lifeless> Jc2k: how many commits is that in ?
[07:13] <mwhudson_> Peng: the directory listing was written at about 1am i think :)
[07:13] <lifeless> Jc2k: (bzr revno in the branch you were indexing)
[07:13] <Peng> mwhudson_: Heh.
[07:13] <Jc2k> lifeless: only 962
[07:13] <lifeless> Peng: loggerhead, for http://bzr-mirror.gnome.org
[07:13] <Peng> mwhudson_: Want me to file a bug?
[07:13] <Peng> lifeless: Ah.
[07:13] <mwhudson_> yes please
[07:13] <Peng> ok
[07:14] <Jc2k> lifeless: 964, even. but still. it indexed gtk+ with ease, and just gets stuck with no progress bar on guadec-web.
[07:15] <lifeless> so, it was indexing 300MB of content in one go
[07:15] <lifeless> Jc2k: try dropping the group count down to 100
[07:15] <lifeless> that will give it 30MB chunks
[07:15] <Jc2k> kk
[07:16] <lifeless> (roughl)
[07:16] <Jc2k> lifeless: not right now, the git stuff is repacking so they can claim its "smaller and more efficient"
[07:16]  * Jc2k skuttles off to make an lzma(7z?) repository format for bzr
[07:17] <lifeless> Jc2k: :P
[07:17] <Peng> Jc2k: With no fulltexts!
[07:17] <Peng> Filed as bug 242270.
[07:17] <lifeless> meh, we will do better on size over time; but I really find it hard to credit that that is a significant objection
[07:17] <lifeless> because, its like claiming gnome 1.2 is what gnome should be judged on
[07:18] <Jc2k> yeah
[07:18] <lifeless> rather than (e.g.) focus on usability, direction, responsiveness
[07:19] <Jc2k> you would think that bzr would be GNOMEy
[07:19] <Jc2k> i mean it just works
[07:20] <Jc2k> if GNOME had as many dials and sharp edges as Git, for example, the HIG people would cry.
[07:20] <lifeless> right
[07:20] <Jc2k> (actually, someone had the nerve to complain that bzr-gtk could do more to adhere to the hig :P)
[07:20] <lifeless> and if you want contributors to a friendly system, I think its reasonable to expect the toolchain to be friendly too
[07:20] <lifeless> Jc2k: turn it into a bug :)
[07:22] <Jc2k> i think if bzr had rebase -i and the everything-in-one-dir repository format, we could turn a few big names at guadec.
[07:22] <Jc2k> regardless of whether they are good ideas or not.
[07:24] <lifeless> jelmer: ^ what are your thoughts on -i?
[07:24] <lifeless> Jc2k: how hard is -i?
[07:25] <Jc2k> lifeless: i dont think too hard. the rebase plugin generates a script - we just need to make the script human readable on the -i path and have actions like edit, squash and kill
[07:25] <lifeless> so,
[07:25] <Jc2k> lifeless: if you edit though.. you need to be able to commit
[07:26] <Jc2k> so you can break a commit up in to pieces
[07:26] <lifeless> I'd like to have everything that gnome folk are calling showstoppers filed as bugs
[07:26] <lifeless> on the relevant bzr components
[07:26] <Jc2k> kk
[07:26] <lifeless> if you think its a good idea, also tag them gnome
[07:26] <Jc2k> i was just going to say :)
[07:26] <lifeless> but if we have the bugs, we can track their acceptance/progress more coherently
[07:28] <Jc2k> i have to head off in a bit, first day at codethink woo, but i'll make sure its done before sleepy time
[07:28] <lifeless> cool
[07:41] <mwhudson_> Peng: thanks for the bug, but if you think loggerhead's current look is nice and slick i want some of what you're smoking :)
[07:51] <Peng> mwhudson_: Hahah.
[07:51] <Peng> a
[07:51] <Peng> mwhudson_: Want me to change it to "hideous, overcomplicated, bloated and slow"? :)
[07:55] <Peng> In all seriousness, I do like Loggerhead's theme.
[07:55] <Peng> But, I like hgweb's too.
[09:08] <eMBee> good afternoon
[09:12]  * eMBee is looking for help on using bzr on an svn repo. is there a howto or manual somewhere? (i am new to bzr)
[09:13] <RAOF> eMBee: Hi!  It should be pretty simple.
[09:14] <eMBee> my main concern is that i need to get the trunk and a branch from the svn repo, then commit my changes to the branch and then merge into the trunk (all on svn side)
[09:14] <RAOF> Hah!  there it is. http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn
[09:14] <RAOF> That should work, with the bonus that you get to use bzr for the merge :)
[09:15] <eMBee> oh, nice
[09:15] <eMBee> is there a way to get all branches from the svn repo?
[09:15] <RAOF> I don't believe so, no.  Unless the multi-pull plugin works with bzr-svn.
[09:16] <eMBee> ah, ok, so at least bzr knows about the concept :-)
[09:16]  * eMBee is used to git, where this is the default
[09:17] <RAOF> Right.  Whereas bzr has quite a different idea.
[09:17] <RAOF> You really, really want to create a repository to store the branches you check out from svn, though.
[09:18] <RAOF> (Basically bzr-init repo svn-branches-go-here; cd svn-branches-go-here; bzr branch svn://mysvn.com/svn/branches/foo)
[09:19] <eMBee> so i make one repo, and add the branches as i need them?
[09:19] <eMBee> and then they all live in the same place
[09:19] <RAOF> The bzr repository is just a space and time saver.  You don't _have_ to have one, but they make it much faster and much smaller.
[09:20] <RAOF> Branches are everything, one branch per directory.
[09:20] <eMBee> yes, well, i like the idea of having everything in one repo. that's one thing that is nice about git
[09:20] <eMBee> can you explain this: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn#python-subversion-1-5
[09:21] <eMBee> what does that mean? (don't answer if it's in the faq, didn't read that yet)
[09:21] <RAOF> Wheras I really dislike git's branch handling :)
[09:21] <eMBee> ok, i don't want to do a git-bzr comparison now, just enough to get me started with bzr :-)
[09:21] <RAOF> That's about bugs in subversion's python bindings.  Particularly, there's a huge memory leak IIRC.
[09:22] <lifeless> jelmer just committed branch new python svn bindings to bzr-svn trunk
[09:22] <RAOF> Oh, that's right, true.
[09:23] <lifeless> eMBee: bzr svn-import will get all branches
[09:23]  * gour dislike git's all-in-one as well
[09:23] <eMBee> oh
[09:23] <RAOF> lifeless: Cool.  Learn something new every day :)
[09:23]  * eMBee will leave the git-vs-bzr discussion for another day :-)
[09:24] <RAOF> Awww :)
[09:24] <lifeless> eMBee: please excuse us vis-a-vis that discussion; we get some advocates here that are +convinced+ there is only one true way
[09:25] <lifeless> eMBee: svn-import will give you all the branches, and I think it creates everything sensibly for you - e.g. cd /tmp; bzr svn-import svn://blag output
[09:27] <RAOF> Gah.  Why must clutter's svn be down when I want to branch clutter-sharp?
[09:28] <lifeless> is clutter gnome?
[09:28] <eMBee> lifeless: i prefer to convince myself of the better way after i have tried all of them
[09:28] <RAOF> No, but it might be soonish.
[09:28] <eMBee> or at least studied someone else try
[09:28] <lifeless> RAOF: it might be on bzr-mirror.gnome.org
[09:28] <lifeless> eMBee: I think thats a good idea
[09:29] <RAOF> lifeless: No, but thanks :(
[09:34] <strk> help help help !  :)
[09:34] <lifeless> hi
[09:34] <strk> moving from cvs to bzr for gnash project
[09:34] <strk> lifeless: glad to see you up :)
[09:34] <lifeless> whats up?
[09:35] <strk> so, I used your suggested init-repo; checkout
[09:35] <strk> then I've been offline
[09:35] <strk> so I tought to try 'unbind'
[09:35] <strk> to commit locally
[09:35] <strk> and I did
[09:35] <strk> now (I guess) my changes are in my local repo, right ?
[09:35] <lifeless> yes
[09:35] <strk> bzr status doesn't tell me anymore what's different between my copy and the online one
[09:35] <lifeless> local branch specifically, because you've unbound
[09:35] <lifeless> as you're working in a checkout style, you should bind again
[09:36] <lifeless> (just 'bzr bind')
[09:36] <strk> bzr: ERROR: No location supplied and no previous location known
[09:36] <lifeless> ok, bzr bzr bzr+ssh://..../trunk
[09:36] <strk> can it --remember ?
[09:36] <lifeless> it will after this
[09:37] <lifeless> (note that you could just have done 'commit --local'
[09:37] <strk> but it *was* bound before...
[09:37] <strk> why did it discard in the first place ?
[09:37] <asabil_> strk: you can use bzr missing in unbound mode
[09:37] <lifeless> yes, I smell a bug I think :P
[09:37] <lifeless> asabil_: thats more of a branch-branch workflow
[09:37] <strk> ah, maybe it's bound already
[09:37] <lifeless> asabil_: strk is just been thrown in the deep end :P
[09:37] <strk> after 'bind bzr+ssh...'
[09:37] <strk> if you 'bind' again (no args)
[09:38] <strk> it'll give you taht message
[09:38] <asabil_> lol ok :)
[09:38] <lifeless> strk: ok
[09:38] <strk> confusing message
[09:38] <lifeless> strk: so, 'bzr update; bzr commit'
[09:38] <strk> request-for-improvement: could it tell you 'already bound to xxxxy' ?
[09:38] <lifeless> strk: sure; care to file a bug?
[09:38] <strk> url ?
[09:38] <lifeless> https://launchpad.net/bzr/
[09:39] <strk> rob suggested 'pull' in the past, what's the difference between 'pull' and 'update' ?
[09:40] <lifeless> pull maintains a mirror
[09:41] <lifeless> but you have local changes
[09:41] <lifeless> so you need to integrate those with trunk
[09:42] <_zou> how to uninstall bzr? I'v no experience with python.
[09:42] <lifeless> there are two ways to integrate - 'update' when you have a checkout(aka bound branch), and 'merge' when you have separate branches
[09:42] <lifeless> _zou: setup.py uninstall I think. Not sure how good it is
[09:42] <lifeless> _zou: if you installed via apt/synaptic/rpm use the package managers method for uninstalling
[09:42] <strk> lifeless: after 'update' I got that message telling me that local commits are now shown as changes, and I have to commit. sounds good.
[09:43] <strk> problem is, I seem to have 'pending merges'
[09:43] <strk> no idea what they are
[09:43] <lifeless> strk: thats your local commit
[09:43] <lifeless> strk: do 'bzr st'
[09:43] <gour> jelmer: there will be new bzr-svn release soon?
[09:43] <_zou> I installed it with "python setup.py install".  "python setup.py uninstall" doesn't work.
[09:43] <strk> lifeless: unfortunately not only
[09:43] <strk> I issues a 'merge' before, and got something else
[09:44] <strk> (things from nelson)
[09:44] <strk> lemme pastebin 'bzr status' output
[09:44] <_zou> error: invalid command 'uninstall'
[09:44] <lifeless> _zou: oh.
[09:44] <strk> http://rafb.net/p/Kdt8Bz59.html
[09:45] <lifeless> _zou: you can just remove the bzrlib directory it created, and the bzr binary then
[09:46] <_zou> can I just reinstall again? I just want to do a uninstall + reinstall.
[09:46] <strk> lifeless: from that output above, modified and added are my duty, pending merges I'd like to ignore :)
[09:46] <lifeless> _zou: sure, just install
[09:47] <lifeless> strk: ok; uhm.
[09:47] <strk> except for a thing: pending merge include (twice) my own commits :?
[09:47] <lifeless> strk: I think update should warn then :P
[09:47] <strk> file another bug ?
[09:47] <lifeless> strk: lets dig a little deeper irst
[09:47] <lifeless> you are Sandro ?
[09:47] <strk> FYI: bug for the other is https://bugs.launchpad.net/bzr/+bug/242284
[09:47] <strk> yes, I'm Sandro
[09:48]  * strk belives he made too much noise shooting in the dark
[09:48] <lifeless> so
[09:49] <lifeless> I think we should peek behind the scenes a little
[09:49]  * strk is all ears
[09:49] <lifeless> can you start up python?
[09:49] <lifeless> $ python
[09:49] <lifeless> >>> from bzrlib import workingtree
[09:49] <lifeless> >>> tree = workingtree.WorkingTree.open('.')
[09:49] <lifeless> tree.lock_read()
[09:49] <strk> yep
[09:49] <lifeless> print tree.get_parent_ids()
[09:50] <strk> ['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv']
[09:50] <lifeless> strk: ok, you are suffering a bug that is fixed in trunk
[09:50]  * strk has no idea how did the nelson's desktop got in
[09:50] <lifeless> tree.unlock()
[09:50] <lifeless> strk: it was committed to trunk already
[09:50] <strk> what was committed ?
[09:50] <lifeless> strk: nelson's change
[09:51] <lifeless> strk: 'bzr log bzr+ssh://bzr.savannah.gnu.org/gnash/trunk -r -1
[09:51] <lifeless> strk: bet you his change is the most recent
[09:51] <strk> ehm... I'm on a gprs connection, would rather avoid bandwidth intensive things
[09:51] <lifeless> strk: anyhow, see the three duplicates - thats the symptom of the bug, it should just be: ['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv']
[09:52] <lifeless> strk: shouldn't be that intensive :P
[09:52] <lifeless> anyhow
[09:52] <lifeless> do this
[09:52] <lifeless> tree.unlock()
[09:52] <lifeless> tree.lock_write()
[09:52] <strk> ops, got out of python
[09:52] <strk> doing the 'log' thing
[09:52] <lifeless> tree.set_parent_ids(['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv'])
[09:52] <lifeless> tree.unlock()
[09:52] <lifeless> ^D
[09:53] <eMBee> in order to branch from svn i need to prefix the svn url with svn? or will the original svn url (which is https://...) do?
[09:54] <strk> ok, killed the log and did the set_parent_ids
[09:54] <lifeless> eMBee: for most svn repositories the original url will do
[09:54] <strk> nelson things are gone from 'status' now
[09:54] <eMBee> most? :-)
[09:54] <lifeless> eMBee: sometimes (due to bugs/code interactions) you need svn+
[09:54] <strk> pending merges only contain my own now
[09:54] <lifeless> strk: 'bzr commit'
[09:54] <strk> why are then nested ? (mine)
[09:54] <eMBee> so the svn+ can't hurt? how will i know if it fails?
[09:54] <strk> http://rafb.net/p/zvJQ3Z11.html <-- this is output
[09:54] <lifeless> eMBee: it will error at you
[09:55] <lifeless> strk: they are nested because they are from one parent
[09:55] <lifeless> strk: if you had two parents, with 5 each you'd see
[09:55] <lifeless> merge1
[09:55] <lifeless>   nested2
[09:55] <lifeless>   nested3
[09:55] <lifeless>   nested4
[09:55] <lifeless>   nested5
[09:55] <lifeless> merge2
[09:55] <lifeless>   ...
[09:55] <lifeless> etc
[09:55] <eMBee> hmm: bzr: ERROR: Unsupported protocol for url "svn+https://...
[09:55] <eMBee> am i missing the bzr-svn plugin?
[09:55] <lifeless> you have more than 2 parents when you do what git calls an octopus merge
[09:56] <lifeless> eMBee: do 'bzr help svn'
[09:56] <eMBee> this is debian etch with bzr from backposrts
[09:56] <eMBee> backports
[09:56] <eMBee> no help found, looks like it's missing
[09:56] <strk> lifeless: I find that indenting confusing too :)
[09:56] <eMBee> where do i get the svn plugin for etch/backports?
[09:56] <strk> it looks like 'nested2' is somewhat 'contained into' 'merge1'
[09:57] <lifeless> strk: hmm, we'll need to look at making it better. but that is what it means
[09:57] <lifeless> strk: merge1 is the tip of the branch being merged; neste2..nested5 are other commits on that branch
[09:57] <strk> but the change log for first-level (what you call 'merge1') only talks about a change which is on the same level of the change advertised in log for 'nested2'
[09:58] <lifeless> strk: topologically, merge1 is a child of nested2; and nested2 is being indirectly merged, rather than directly referenced
[09:58] <eMBee> looks like bzr-svn is not in backports yet. can i risk installing the lenny version?
[09:58] <strk> indeed 'Add test for global/local registers
[09:59] <strk> was committed locally *after* 'Make registers access safer and more general
[09:59] <lifeless> eMBee: I would say it should be fine; you'll want svn too
[09:59] <lifeless> strk: right
[09:59] <lifeless> strk: thats what its showing you
[09:59] <eMBee> lifeless: what do you mean? i want to update svn?
[10:00] <strk> confusingly :)
[10:00] <lifeless> eMBee: bzr-svn needs certain versions of the svn python bindings; many bugs in those were found while writing the plugin
[10:00] <eMBee> ah, right, i was asking about that earlier (maybe missed the reply then)
[10:01] <lifeless> if you are running packaged bzr-svn, its dependencies sould force this update anyway
[10:01] <eMBee> right
[10:01] <eMBee> thanks
[10:01] <lifeless> np
[10:03] <strk> commit is taking a lot, should transfer ~ 120 kb for a new file and 4/5 Makefile.am change
[10:03] <strk> and, mmm.. I guess 2/3 lines of commit log
[10:03] <lifeless> strk: check ~/.bzr.log
[10:03] <_zou> What I did at step1: bzr branch  bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunck
[10:03] <_zou> step2: I modified a local file named MatrixTest.cpp
[10:04] <lifeless> strk: there is a thing called autopack which will kick in about 1 time in 10 (and in the next release of bzr hopefully never)
[10:04] <lifeless> strk: that may have occured
[10:04] <_zou> step3: bzr commit MatrixTest.cpp (seems succeeded)
[10:04] <strk> 63.403  Using fetch logic to copy between KnitPackRepository('file:///home/strk/src/gnash/bzr-local-repository/.bzr/repository/')(<RepositoryFormatKnitPack1>) and KnitPackRepository('bzr+ssh://strk@bzr.savannah.gnu.org/gnash/.bzr/repository/')(<RepositoryFormatKnitPack1>)
[10:04] <lifeless> strk: oh yeah, waht version of bzr do you have ?
[10:04] <strk> _zou: I guess you've committed to local branch, not remote
[10:05] <strk> _zou: bzr info should tell you the kind of tree you have
[10:05] <strk> lifeless: 1.3.1
[10:05] <lifeless> strk: right, 1.5 is substantially faster; 1.6 should be even more so
[10:05] <_zou> strk: "Committed revision 9422"   I guess so, I haven't see any mail notifications.
[10:06] <lifeless> that reminds me
[10:06] <strk> _zou: mail notification doesn't work yet it seems
[10:06] <lifeless> I was going to nag
[10:06] <lifeless> spiv: ping
[10:06] <spiv> lifeless: pong
[10:06] <lifeless> strk: centralised ones are tricky, *decentralised* work just fine - the bzr-email plugin :)
[10:06] <lifeless> spiv: ^ email notifications && smart server && HOWTO
[10:06] <strk> _zou: I guess you should 'bzr bind' to make commits go to the master repo
[10:07] <strk> lifeless: I don't have a working outputing mail system
[10:07] <strk> it's easier when done centralized...
[10:07] <lifeless> strk: sure, and there are a couple of answers for it
[10:07] <strk> we likely don't want to get mail on each local commit anyway
[10:07] <lifeless> first I interrogate spiv
[10:07] <spiv> lifeless: first server-side notifications need to work :(
[10:07] <lifeless> spiv: you had a patch I thought ?
[10:08] <spiv> They're close, but when I did a quick experiment they aren't there yet.  Probably fixed by accident by one of my push-acceleration patches in BB atm though.
[10:08] <lifeless> spiv: ah
[10:08] <_zou> strk: There should be a commands list to follow. And some feedbacks to confirm if I have done it successfully.
[10:08] <spiv> (IIRC the current problem is that the client does not actually invoke a set_last_revision RPC)
[10:08] <lifeless> strk: I'll mail rob and sylvain the alioth solution tomorrow
[10:09] <strk> _zou: we're all trying to find out :)
[10:09] <strk> _zou: the simplest seems to be 'checkout; add; commit;'
[10:09] <spiv> lifeless: the next issue after that is making sure the configuration isn't terrible :)
[10:09] <strk> _zou: warranty void since you did 'branch' instead of 'checkout' I guess :P
[10:09] <lifeless> spiv: I want it to be 'install bzr-email on the server; set a config just like you would on your own machine'
[10:10] <spiv> lifeless: me too, I think.
[10:10]  * strk commit is still hung with high network traffic
[10:11] <lifeless> I think mtaylor has some stuff for email on push/pull with bzr-email
[10:11] <spiv> lifeless: I'm sure that's a great first cut at least, and no doubt user feedback will help refine from there.
[10:11] <_zou> strk: "bzr branch  bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunck" that's what I did.
[10:11] <strk> is an upgrade of bzr planned in Feisty ?
[10:11] <lifeless> strk: we'll probably get something into a backport
[10:11] <strk> _zou: that should have created a local repository, to which your commit would go (I think)
[10:11] <lifeless> strk: but we already offer a ppa
[10:11] <lifeless> _zou: that has made a new branch
[10:11] <strk> ppa?
[10:12] <lifeless> _zou: and your commits are isolated in that branch until you merge them into trunk
[10:12] <lifeless> _zou: to merge them into trunk:
[10:12] <lifeless> 'bzr co bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunk trunk; cd trunk; bzr merge OTHERBRANCH; bzr commit'
[10:13] <lifeless> _zou: or, do exactly what I did with strk above - bind the branch, then update and commit
[10:13] <strk> ouch, sounds expensive
[10:13] <_zou> lifeless: tree.lock()?
[10:13] <lifeless> strk: well, a shared repository - which you all should have - means that that has almost no network overhead
[10:13] <strk> _zou: no, that's just debugging stuff
[10:13] <strk> _zou: bzr help; bzr help bind;
[10:13] <lifeless> _zou: what bzr version do you have
[10:14] <lifeless> http://bazaar-vcs.org/Download
[10:14] <strk> bzr bind bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunk
[10:14] <_zou> lifeless: 1.5
[10:15] <strk> argh!
[10:15] <strk> 956.587  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x85efbcc>, which has 33 pack files, containing 9971 revisions into 26 packs.
[10:15] <strk> it kicked in, it's my day !
[10:15] <lifeless> strk: congrats, you get a prize
[10:16] <lifeless> strk: its going to be combining 7 packs, should be 1 commit each and small - but if you want to cancel, just hit ctrl-C
[10:16] <lifeless> strk: actually, don't
[10:16] <_zou> lifeless:  "bzr merge OTHERBRANCH" I don't know any other branches. I want my commit to be in head.
[10:16] <lifeless> strk: I just remembered, you're commiting :)
[10:16] <lifeless> _zou: you made a new branch when you ran 'bzr branch'
[10:16] <lifeless> _zou: the 'branch' command always makes a new branch
[10:17] <strk> lifeless: how should the /etc/apt/source.list line look like to get a new version ?
[10:17] <strk> deb https://launchpad.net/~bzr/+archive <-- this is reported to be malformed, never learned exact format
[10:18] <strk>  http://bazaar-vcs.org/DistroDownloads <-- this page doesn't tell exactly
[10:18] <lifeless> strk: click on the ppa repository link
[10:18] <strk> beta ?
[10:18] <lifeless> no
[10:18] <strk> k
[10:18] <lifeless> 'ppa repository' I think it says
[10:19] <strk> the intrepid stuff ?
[10:19] <lifeless> well, there is a drop-down
[10:19] <lifeless> change the drop-down to feisty :)
[10:19] <strk> is that 'bzr' specific ?
[10:20] <strk> or would I get new versions of other packages too ?
[10:20] <strk> or, what does 'ppa' stands for ? :)
[10:21] <Kinnison> personal package archive IIRC
[10:21] <Peng> indeed
[10:21]  * strk Committed revision 9422. (hurray)
[10:24]  * strk_ hates gprs ...
[10:24] <strk_> 9422 committed ...
[10:25] <strk_> so, I was asking, will the ppa addition in source.list pull-in other experimental packages beside bazaar ?
[10:26] <lifeless> strk: no
[10:26] <lifeless> strk: only what we upload there, and we only put bzr + plugins
[10:26] <strk_> is there a way to tell apt-get update to only fetch from the new url (to reduce bandwidth)
[10:27] <lifeless> strk: no, but it does HEAD's anyway
[10:27] <strk_> ok
[10:27] <strk_> safe to upgrade to 1.5 ? any preparatory work I need ?
[10:28] <lifeless> go for it
[10:28] <strk_> uhm... Get:6 http://us.archive.ubuntu.com hardy-updates/main Packages [258kB] <--- my day.. taking time
[10:28] <strk_> is it normal to have 'hardy' stuff in a 'feisty' system btw ?
[10:29] <lifeless> strk_: uhm, thats unusual indeed
[10:29] <lifeless> strk_: are you sure you haven't upgraded to hardy already ? :)
[10:29] <lifeless> strk_: 'lsb-release -a'
[10:33] <strk_> uhm...
[10:33] <strk_> I guess I did, I tought feisty was more recent
[10:34] <strk_> what's this fever to give releases a name ?! gah
[10:34] <lifeless> 'f', 'g', 'h'
[10:34] <lifeless> you should use the hardy line for the ppa too :P
[10:34] <strk_> oh, that helps, thanks :)
[10:35] <strk_> alright, I hope it won't break everything (pm are so weak)
[10:36] <strk_> 30minutes to go...
[10:37] <strk_> so, about 'bind/unbind' .. is that a good habit for switching between online-offline work ?
[10:37] <lifeless> its designed to support that
[10:37] <lifeless> a better one would be to create a new branch
[10:37] <lifeless> and work in the branch all the time
[10:37] <lifeless> then when you are online and ready to put your work in trunk
[10:37] <lifeless> cd $trunk
[10:37] <lifeless> bzr update
[10:37] <lifeless> bzr merge ../your-other-branch
[10:37] <lifeless> bzr commit
[10:38] <strk_> good. I guess the alternative would be keeping two different trees, which would mean reconfiguring all build trees
[10:38] <strk_> bzr merge $mybranch.
[10:38] <Ng> if I have two branches, one of which is suppoesd to be a clone of the other but has somehow diverged, can I get some useful information as to how they have diverged? or should I just diff them?
[10:38] <lifeless> Ng: bzr missing
[10:38] <strk_> right
[10:38] <lifeless> Ng: bzr diff -r branch:other
[10:38] <lifeless> Ng: bzr merge --preview other
[10:38] <strk_> but all the build trees point to a single source tree
[10:39] <Ng> lifeless: hmm, missing is interesting, thanks :)
[10:39] <lifeless> strk_: ok
[10:40] <strk_> if I have the build trees point to my own branch I'll have to keep it up to date too when it seems safe. sounds too complex atm.
[10:40] <lifeless> strk_: you might find having the build tree not be a branch at all
[10:40] <lifeless> strk_: consider this:
[10:40] <lifeless> ~
[10:40] <lifeless> repo/trunk
[10:40] <lifeless> repo/mybranch
[10:40] <lifeless> source/working
[10:41] <lifeless> build/treea,treeb etc etc
[10:41] <strk_> working symlinking to trunk/mybranch as needed ?
[10:42] <lifeless> if you create source/working by doing 'bzr checkout --lightweight
[10:42] <lifeless> and in repo/trunk and repo/mybranch there is no source code files at all
[10:42] <lifeless> you would use the 'bzr switch' command to point working at either trunk, or mybranch, as you desire
[10:42] <bob2> lifeless: how crack-headed do you think a git-ish-all-branches-in-one-dir repo format would be?
[10:43] <lifeless> bob2: I don't think its crack-headed, but I think its really less nice to work with
[10:43] <Kinnison> bob2: my 2¢ is that it'd be nasty :-)
[10:43] <strk_> I don't get the 'no source code files at all' part
[10:44] <lifeless> strk_: ok
[10:44] <strk_> you mean no 'working' files, but 'in-repo' only ones ?
[10:44] <lifeless> strk_: I think doco is the best thing at this point
[10:44] <lifeless> bzr help working-trees
[10:46] <lifeless> strk_: I mean that there would only be a .bzr diredctory at repo/trunk and repo/mybranch
[10:47] <strk_> there would be two repos with no working trees in them
[10:47] <lifeless> strk_: 1 repo. 2 branches. no working trees
[10:48] <strk_> or, two branches
[10:48] <lifeless> it might be easiest to show you
[10:48] <lifeless> you made a repo already correct?
[10:49] <strk_> yes, and I just tried 'remove-tree'
[10:49] <strk_> unfortunately, it didn't clean everything up (./autogen.sh created files left)
[10:49] <strk_> would a rm -Rf * be safe ?
[10:50] <lifeless> yes (as long as .bzr stays around, its fine)
[10:50] <strk_> then I'm doing:
[10:50] <strk_> cd ../gnash-head; bzr checkout --lightweight ../bzr-local-repository/trunk
[10:50] <strk_> bzr-local-repository/trunk
[10:50] <strk_> gnash-head
[10:50] <lifeless> right
[10:50] <strk_> ok
[10:50] <strk_> now, the local branch
[10:51] <strk_> cd bzr-local-repository; bzr branch trunk mybranch ?
[10:51] <lifeless> yes
[10:51] <lifeless> exactly in fact
[10:51] <lifeless> because your repository is set to create trees you'll want to remove-tree right away
[10:51] <strk_> k
[10:51] <strk_> ops
[10:51] <strk_> what tells me when the repository is set to create trees ?
[10:51] <strk_> and how to change it ?
[10:52]  * strk_ running remove-tree in 'mybranch' meanwhile
[10:52] <lifeless> touch .bzr/repository/no-working-trees
[10:52] <strk_> alright, I have trunk and mybranch with no working trees now
[10:52] <lifeless> ok
[10:52] <lifeless> and your builds all can point at gnash-head. (actually I'd rename it gnash-working or something)
[10:53] <strk_> I'll need multiple 'working' trees
[10:53] <lifeless> strk_: you will?
[10:53] <strk_> with cvs, I had one each branch
[10:53] <lifeless> (I got the impression you wanted just one)
[10:53] <strk_> usually only using head and release branch
[10:53] <strk_> well, just one each 'set' of build trees
[10:54] <strk_> I usually work with 2 ones, head and release branch
[10:54] <lifeless> you can have as many working trees as you want
[10:54] <strk_> actually, I also have a third one, which I used to call 'gnash-head-backup'
[10:54] <strk_> that's for when I made local changes and wanted to use plain trunk
[10:54] <lifeless> now there is a new command that you can use
[10:54] <lifeless> cd to the working tree
[10:55] <lifeless> and run 'bzr switch mybranch'
[10:55] <strk_> ok, gnash-head is now my working tree:
[10:55] <strk_> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
[10:55] <strk_> Switched to branch: /home/strk/src/gnash/bzr-local-repository/mybranch/
[10:55] <strk_> Switched to branch: /home/strk/src/gnash/bzr-local-repository/trunk/
[10:55] <strk_> nice :)
[10:55] <lifeless> now when you commit the commits will go to mybranch
[10:55] <lifeless> and now trunk
[10:56] <lifeless> so to work offline:
[10:56] <lifeless> switch mybranch
[10:56] <lifeless> hack commit hack commit hack commit
[10:56] <lifeless> come oneline
[10:56] <lifeless> bzr shelve/revert/commit (so that 'bzr st' shows no changes)
[10:56] <lifeless> bzr switch trunk
[10:56] <lifeless> bzr update
[10:57] <lifeless> bzr merge ../bzr-local-repository/mybranch
[10:57] <lifeless> (run any tests etc)
[10:57] <lifeless> bzr commit
[10:57] <lifeless> make sense?
[10:57] <strk_> I guess so
[10:57] <strk_> this is assuming 'commit' on a trunk-bound working tree will push online ?
[10:58] <lifeless> yes
[10:58] <strk_> even if 'trunk' is local...
[10:58] <lifeless> its assuming trunk is still a bound branch
[10:58] <strk_> trunk info: Repository bound branch (format: pack-0.92)
[10:58] <lifeless> yup
[10:58] <strk_> mybranch info: Repository branch (format: pack-0.92)
[10:58] <strk_> bzr @ 1.5 now
[10:59] <strk_> now, lemme try to do the 'gnash-head-backup' equivalent
[10:59] <strk_> that'd be a working tree bound to the local 'trunk' which is bound to the online 'trunk'
[10:59] <strk_> which I'll use for in-source-tree building
[10:59] <strk_> still --lightweight ?
[10:59] <lifeless> yes
[11:00] <strk_> bzr checkout --lightweight bzr-local-repository/trunk
[11:00] <strk_> can I give an additional arg to name the created dir ?
[11:00] <strk_> bzr checkout --lightweight bzr-local-repository/trunk gnash-head-backup ?
[11:00] <lifeless> yes
[11:04] <strk_> I guess last thing would be release branches
[11:04] <strk_> is there a command to query a repository for the list of branches available there ?
[11:04] <lifeless> bzr branches
[11:04] <lifeless> (with URL for a remote list)
[11:05] <strk_> with no URL what does it use ?
[11:05] <lifeless> '.'
[11:05] <lifeless> hmm, probably could give it some heuristic love
[11:05] <lifeless> make it aware of being in a checkout
[11:05] <strk_> mmm... I guess I have no branches locally, since I only have trunk...
[11:06] <lifeless> strk_: and mybranch
[11:06] <strk_> oh
[11:06] <strk_> still bzr branches lists nothing when issued inside 'trunk' or inside the working tree
[11:06] <lifeless> yeah, its a very literal commanda t the moment
[11:06] <strk_> it does when isued from top-level dir
[11:06] <strk_> makes sense
[11:07] <strk_> trying it remotely
[11:08] <strk_> sloooow :(
[11:09] <strk_> bzr branches bzr+ssh://strk@bzr.savannah.gnu.org/gnash
[11:09] <strk_> isn't it just 10/15 strings to transfer ?
[11:09] <lifeless> there is no specific RPC for it yet
[11:09] <lifeless> so its listdir + open_branch per dir
[11:10] <lifeless> which is another way of saying 'no but it will be in the future'
[11:15] <strk_> still not done fetching branches...
[11:15] <strk_> 6 minutes later
[11:15] <lifeless> its recursed into the tags and branches dirs
[11:16] <lifeless> you're paying GPRS latency :(. This is all predictable (and frustrating)
[11:16] <strk_> ? how many ssh connections ?
[11:16] <lifeless> one connection
[11:16] <lifeless> and it should be one round trip per branch/tag
[11:17] <lifeless> back in a sec
[11:17]  * strk_ realizes he didn't pipe to less :!
[11:17]  * strk_ gets the videocam ready ;P
[11:18] <strk_> nah, I kill, don't care about branches now anyway
[11:20] <strk_> thanks for your time lifeless, I'll be offline
[12:09] <shai_hulud> hi. how do I merge pending merges. I did bzr merge --pull <repo> and had a conflict on the way. now I'd like to continue merging, but I get a message that i have uncommited changes
[12:27] <mlh> what's 1.6 got over 1.5?
[12:27] <mlh> I'm about to d/l for windows and curious about the difference 1.5 -> 1.6b2
[12:27] <mlh> and didn't find release notes / roadmap
[12:31] <mlh> hrm, never mind, there is no 1.6b for win
[12:33] <lifeless> :P
[12:38] <mlh> :-)
[12:38] <mlh> you just got mail on a trivial wiki change
[12:38] <mlh> Bialix's last name
[13:12] <jelmer> Verterok: hi
[13:39] <Verterok> jelmer: hi
[13:41] <jrb_> In a shared repository if I don't need some branch anymore: is it enough to just delete the branch (rm) to remove all traces of the branch?
[13:41] <radix> jrb_: the revisions that the branch pointed to will still be in the repository
[13:42] <radix> jrb_: mostly that's fine since generally those revisions become a part of trunk or whatever
[13:42] <Verterok> jelmer: while playing with bzr-svn new bindings (I must say, cool!), before building the mac OSX package/installer I encountered with a known bzr tests problem in os x, http://rafb.net/p/MbdV9D77.html
[13:42] <radix> if you've got a branch with a commit of a 8GB file and you don't want that sitting in your repository, though, it can be a problem
[13:43] <jrb_> radix: So what happens if I create a branch with the same name later on? Is there no remove-branch command?
[13:43] <radix> jrb_: the name of the branch won't matter at all
[13:43] <lifeless> jrb_: just delete the directory, that gets rid of teh branch
[13:44] <radix> jrb_: what's your concern, exactly?
[13:44] <nysin> Is there a way to bzr diff (without making basically a shell program to use --using or --diff-options with) ignoring certain files and directories? Mainly certain big ones that are in one branch but not another and just clutter up a diff uninterestingly.
[13:45] <jrb_> since the name of the branch does not matter it isn't much of a problem to me. I was just wondering.
[13:45] <lifeless> nysin: well you can use filterdiff
[13:45] <radix> jrb_: cool
[13:45] <nysin> oh IIRC in difftools or something, a separate package, right?
[13:45] <lifeless> nysin: but there is a bug option to support --exclude or some such as part of bzr diff
[13:46] <nysin> Ah, well, I look forward to that, in the meantime I'd forgotten about filterdiff
[13:46] <jrb_> radix: thanks for the info and bye
[13:47] <nysin> lifeless, have a link to that bug?
[13:47] <lifeless> nope, just remember someone talking about it last week
[13:48] <nysin> okay
[13:48] <lifeless> nysin: if you can't find it, feel free to open another
[13:48] <jelmer> Verterok: what sort of thing were you pushing?
[13:48] <nysin> yup; I'm sure someone will mark it as a dupe, but that's just as good
[13:49] <Verterok> jelmer: the bzr-eclipse, just for testing....it contains ~160 mainline commits
[13:49] <nysin> https://bugs.launchpad.net/bzr/+bug/53992
[13:50] <jelmer> Verterok: you seem to've hit an endless loop somehow
[13:50] <jrb_> radix: oh wait. one more question. since the history of the deleted branch is still available in the repository how can I get it back after I have deleted the branch. just in case I ever need that.
[13:50] <jelmer> Verterok: _dir_process() should be run for each level of directories that's being committed
[13:51] <lifeless> jrb_:  there is a heads() plugin
[13:51] <radix> jrb_: If you've merged the branch into another, it's much easier
[13:51] <radix> oh
[13:51] <radix> or maybe you can use something called the heads() plugin, but I have no idea what that is.
[13:51] <lifeless> jrb_: you can just run heads --all (IIRC) and it will list the revision ids
[13:51] <radix> I know how to get a branch that's been merged into another
[13:51] <jrb_> lifeless: okay I look into that, thx
[13:51] <lifeless> jrb_: I think there is an option to list only the invisible heads, which will be your deleted branch
[13:52] <Verterok> jelmer: oh, I see. bzr-eclipsse structure conatins lots of empty and nested, directories, i.e: core/org/vcs/bazaar/eclipse/foo/bar,java
[13:53] <Verterok> jelmer: could that be a problem?
[13:56] <jelmer> Verterok: that probably explains why svn needs that many open file handles
[13:57] <jelmer> Verterok: if your limits are very conservative atm you may want to consider increasing them
[13:58] <Pilky> is bzr pull --overwrite just meant to replace what is on my branch with whatever is on the branch I'm pulling from?
[13:58] <Pilky> because I tried it yesterday but got conflicts
[13:59] <lifeless> Pilky: you shouldn't have, unless a directory with non-versioned files in it was deleted
[14:00] <Verterok> jelmer: ok, thanks. I'll try to increase the limits
[14:00] <Pilky> lifeless: all I'd done was change some files, and then want to replace them with the ones on my server
[14:00] <lifeless> Pilky: had you committed those changes?
[14:01] <Pilky> nope
[14:01] <lifeless> then thats why
[14:01] <Pilky> ah
[14:01] <lifeless> pull preserves local edits
[14:01] <lifeless> they were local edits (as opposed to commits which can be overriden)
[14:01] <Pilky> so in future, revert and then pull
[14:01] <Pilky> if I want to replace what I have
[14:01] <lifeless> for this scnenario, yes
[14:03] <Pilky> ok, thanks
[14:06] <nysin> It appears that using --diff-options doesn't even work
[14:06] <nysin> because bzr seems to special-case new files
[14:07] <nysin> so if e.g. I tell it to use --using=cat, then most files are just cat'd, but wholly new files are done internally (because they still look vaguely diff-like)
[14:07] <lifeless> uhm
[14:07] <lifeless> --using
[14:07] <lifeless> and --diff-options
[14:07] <lifeless> are mutually exclusive options
[14:07] <nysin> oh
[14:08] <lifeless> --diff-options says 'pass these options to diff'
[14:08] <Verterok> abentley: the script to move from sqlite, now also works in postgres :-)
[14:08] <lifeless> --using says 'use this script to do diffs'
[14:08] <nysin> Er, right. Whoops. Well right now I'm acutally only specifying --using
[14:08] <nysin> So my comment above still applies except just to --using I guess
[14:08] <lifeless> I'm not sure they /should/ be mutually incompatible, but thats what I recall reading in a bug report
[14:08] <Verterok> abentley: sorry, to move BB db from sqlite
[14:16] <jelmer> beuno: hi
[14:16] <nysin> And --diff-options seems problematic because it (as determined by forcing it to throw an error to see commandline) uses randomly named files in /tmp and just --labels them so -x and -X don't seem to work (I've tried the very simplest cases, where it's not in a directory, has no spaces in the filenames, etc)
[14:17] <Jc2k> beuno, lifeless: lo
[14:17] <Jc2k> i was talking to robtaylor and we wondered....
[14:17] <Jc2k> could we have a "wall of outstanding"
[14:18] <Jc2k> e.g. get all fixmes in the whole of gnome :p
[14:18] <Jc2k> laggy laggy
[14:19]  * Jc2k back to work
[14:23] <abentley> lifeless: Well --diff-options is unnecessary when using --using
[14:23] <abentley> And what are you doing up?
[14:48] <mlh> is there anyway to get a branch over http if the http server hides dot files?
[14:48] <mlh> (Im thinking maybe bzr has an alternate name for .bzr - _bzr perhaps?
[14:49] <jelmer> Jc2k: that sounds like a nice idea
[14:50] <mlh> if not,  thats ok , I can get via ftp with password
[15:03] <nysin> (filterdiff ended up working fine, though there would be substantial network win if the filtering could be done before retrieving megabytes of stuff...)
[15:03] <nysin> doing it locally for the moment means it doesn't really matter though
[15:29] <Pieter> is bzr under windows really slow or is it possible it hangs without giving any output?
[15:49] <jelmer> mlh: you should be able to fetch that branch even if it's not included in directory listings
[16:01] <Peng> mlh: Server-generated directory listings really don't matter. They're nothing magic, just another HTML page. Of course, the server could actually access to dot files too...
[16:25] <beuno> jelmer, hey
[16:28] <jelmer> beuno: I'm still interested in uploading bzr-upload's Debian package
[16:28] <beuno> jelmer, ah, yes. I have an email about no bein able to branch that...  can you give me the URL again?
[16:32] <jelmer> http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable
[16:32] <jelmer> e.g. bzr builddeb http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable
[16:33] <james_w> you might need nosmart+ to access bzr.debian.org until 1.6 is out.
[16:33] <james_w> hi jelmer
[16:33] <james_w> hi beuno
[16:33] <beuno> howdy james_w
[16:33] <beuno> jelmer, thanks, I'll pass that on now
[16:34] <jelmer> hi James
[16:49] <jelmer> james_w: Ah, bzr builddeb nosmart+http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable fails for me atm because the tree isn't locked
[16:49] <james_w> ok
[16:51] <jelmer> adding a lock in cmd_builddeb() fixes it. I'll send you a patch
[16:51] <james_w> thanks
[16:57] <jelmer> sent
[16:57] <jelmer> beuno: so it may be necessary to create a local copy of that branch first
[16:57] <jelmer> rather than using bzr builddeb on the remote url
[16:58] <beuno> jelmer, ah, ok. Just sent that off in another email too.
[17:26] <emgent> fog: hi
[17:30] <lamont> No handlers could be found for logger "bzr"
[17:30] <lamont> what's that mean?
[17:30] <fog> emgent: hey
[17:34] <quicksilver> if you did a bzr update (or bzr pull) which yielded some conflicts
[17:34] <quicksilver> and you decide you don't really want to resolve them now
[17:34] <quicksilver> can you undo it?
[17:40] <beuno> quicksilver, bzr revert
[17:40] <quicksilver> I don't think so.
[17:40] <quicksilver> I think bzr rever will throw away my local changes.
[17:40] <jelmer> quicksilver: You mean, commit with conflict markers?
[17:40] <quicksilver> precisely the opposite of what I wish to do.
[17:40] <quicksilver> jelmer: rollback the update/pull.
[17:41] <quicksilver> previously my local copy was on revision 10 (say).
[17:41] <quicksilver> I had local changes.
[17:41] <jelmer> quicksilver, maybe something like "bzr merge --force -r43..41"
[17:41] <quicksilver> pulling revision 11 lead to lots of conflicts I don't wish to resolve today.
[17:41] <quicksilver> instead I wish to return to my previous situation
[17:41] <jelmer> if the changes you merged in were revno 41 to 43
[17:41] <quicksilver> (revision 10 + local changes)
[17:42] <jelmer> hmm, I doubt that'd help with conflicts though
[17:42] <beuno> can you merge with uncommitted changes?
[17:43] <beuno> if so, you shouldn't  :)
[17:43] <beuno> and then use revert
[17:47] <jelmer> beuno, you can't merge
[17:47] <jelmer> but you can pull
[17:49] <quicksilver> you can both pull and update with uncommitted changes
[17:49] <quicksilver> as long as you're tracking fairly closely it's quite a sane thing to do
[17:49] <quicksilver> btu I believe it lacks the ability to undo if it goes wrong
[17:49] <quicksilver> which is why I asked the question here ;)
[17:50] <quicksilver> it's a bit unusual since most bzr operations are undoable.
[17:55] <jelmer> yeah, reversibility ftw
[17:56] <jelmer> quicksilver: I wonder what the sanest UI for this would be though
[18:21] <strk> lifeless: so I did 'commit' when bound to 'mybranch', then 'switch', 'merge ../mybranch', cleanup stuff, commit
[18:21] <strk> taking forever as usual :)
[19:57] <awilkins> Once again, win32 packages lag behind the bleeding edge....
[19:58]  * awilkins waves his neatly set up win32 build environment that takes about 10 seconds to build both Python-style packages
[20:02] <jelmer> hi awilkins
[20:08] <awilkins> jelmer: Hello jelmer, after dinner I can spend some time trying to get those extensions to build
[20:08] <awilkins> I think maybe I should install a 4-series GCC in my MinGW
[20:09] <awilkins> Anyhow, time to cook some chicken soup ; back later
[20:35] <cr3> how can I reverse a commit between release 530..529? too late for an uncommit
[20:35] <beuno> cr3, you want to go back to the state of 529?
[20:35] <cr3> maybe bzr diff -r530..529 | patch -p1 or somesuch
[20:36] <beuno> cr3, bzr revert -r 529
[20:36] <cr3> beuno: only reverse that commit, not all the commits since then
[20:36] <fullermd> No, you don't want that...   merge can do it.
[20:36] <fullermd> bzr merge -r530..529 .
[20:36] <cr3> fullermd: excellent, thanks!
[20:47] <melat0nin> hi all
[20:48] <melat0nin> got a simple question.. how do i download a branch from a revision other than the most recent?
[20:48] <beuno> melat0nin, bzr branch -r revno
[20:49] <melat0nin> beuno: then the branch url?
[20:49] <beuno> melat0nin, yeap, the order doesn't matter really
[20:49] <melat0nin> beuno: great, thanks :)
[20:49] <beuno> as long as -r is followed by the revno
[20:50] <melat0nin> cool
[20:50] <quicksilver> jelmer: bzr backtrack -r123 ?
[20:50] <quicksilver> jelmer: meaning backtrack repo to revision 123, keep uncommitted working changes
[20:56] <tethridge> where is the mailing list for bazaar?
[20:57] <tethridge> found it
[20:57] <tethridge> I was looking on launchpad
[20:57] <tethridge> it's not on there.  :-)
[21:11] <awilkins> jelmer: Ping?
[21:11] <jelmer> awilkins: pong
[21:11] <awilkins> Which compiler are you using on these extensions?
[21:11] <jelmer> quicksilver: Hmm, what if you do two pulls in a row and then want to back both of them out?
[21:12] <jelmer> awilkins: I'm using gcc
[21:12] <awilkins> Which version?
[21:13] <awilkins> The MinGW 4-series GCC is marked as "Warning: This is an alpha testing release.  That means the build may
[21:13] <awilkins> contain major missing functionality and serious bugs, including silent
[21:13] <awilkins> incorrect code compilation.
[21:14] <jelmer> awilkins: 4.3.1
[21:14] <jelmer> awilkins: I'm on Linux though
[21:14] <awilkins> I think some of the C idioms you are using are not liked by the 3 series compiler
[21:16] <jelmer> which ones? Can you pastebin the output?
[21:16] <awilkins> Sure
[21:26] <awilkins> jelmer: Going to be a little while, the last revision busted my windows setup script
[21:26] <jelmer> awilkins: k
[21:34] <awilkins> jelmer: Are the PAR ldflags very important?
[21:34] <awilkins> *APR
[21:34] <jelmer> awilkins: depends on what they are exactly :-)
[21:35] <jelmer> here on Linux, they're actually empty
[21:38] <awilkins> jelmer: On windows, it's hard to tell because apr-config is a bash script :-)
[21:39] <jelmer> awilkins, ah :-)
[21:39] <jelmer> awilkins, I think you should be able to get away with ignoring them
[21:41] <lifeless> Jc2k: interesting ide
[21:41] <lifeless> abentley: it was 23:20 or so;
[21:41] <lifeless> *now* its 0640 and wtf am I doing up is what I'm asking myself
[21:41] <abentley> hehe
[21:42] <Jc2k> thinking about implementing the wall of GNOME ;)
[21:42] <beuno> goooooooood morning lifeless
[21:43] <beuno> Jc2k, if everything goes as planned, I'll get to theming for Gnome in about an hour or so
[21:43] <beuno> then we have to see if that actually brings any useful results  :)
[21:43] <Verterok> mornin'
[21:44] <lifeless> beuno: cool!
[21:45] <mwhudson> mornings
[21:46] <beuno> señor mwhudson, good morning
[21:46] <Jc2k> beuno: awesome :)
[21:46] <beuno> I have a few things to bounce off you when you're past your morning coffee
[21:46] <beuno> remember=revid is bugging the hell out of me
[21:47] <mwhudson> ah haha
[21:48] <beuno> it doesn't seem to work, the UI for it sucks badly, and it breaks the beautiful new theme
[21:48] <mwhudson> hm, if it's broken it broke recently
[21:48] <beuno> so it's down to "fix it" or "remove it, make plans for something much better soon"
[21:48] <beuno> mwhudson, well, it's broken on LP
[21:48] <mwhudson> it's a terrible terrible ui though
[21:48] <mwhudson> beuno: oh
[21:48] <mwhudson> :)
[21:48] <mwhudson> maybe it works in trunk then
[21:49] <beuno> let me try, I think not
[21:49] <beuno> it does not!
[21:49] <beuno> oh
[21:49] <beuno> it does
[21:49] <beuno> ew
[21:50] <mwhudson> i think it may just be even harder to use than you expected :)
[21:50] <beuno> it works on LP too
[21:50] <beuno> yes
[21:50] <beuno> it's an extra step
[21:50] <beuno> worse UI then I thought then
[21:51] <beuno> ugh, ok, I'll change the bug si it's "make it better"
[21:52] <quicksilver> jelmer: I don't know. I don't know enough about how bzr stores stuff.
[21:52] <Verterok> abentley: hi
[21:52] <quicksilver> jelmer: I don't even know if the data exists to unmerge the local changes.
[21:52] <Verterok> abentley: done, the migration scripts now support postgresql ;-)
[21:52] <quicksilver> jelmer: or if you'd have to explicitly 'save' state when doing a 'bzr update'.
[21:52] <abentley> Verterok: Thanks.  I saw that this morning.  Haven't had a chance to try it.
[21:53] <quicksilver> jelmer: maybe that is the simplest solution; have 'bzr update' (or pull) explicitly save the local diff and the revision number in an undo history.
[21:53] <Verterok> abentley: np, glad to help, in case you find any problems with the scripts drop me an email or ping me
[21:53] <beuno> abentley, that would be a cool link to add to "merge request" in LP. A link to the diff between the missing revisions.
[21:55] <abentley> beuno: Yes, showing diffs is on our roadmap.
[21:55] <beuno> abentley, cool  :)  That would make it much more BB-like
[21:56] <abentley> beuno: In fact, today I've been working on adding the ability to show a diff of "x merged into y assuming z is already merged into y".
[21:57] <beuno> abentley, It's getting more advanced, yay!  :)
[22:02] <awilkins> jelmer: Ok, first problem, no svn_client_commit_item_2_t in 1.4.6 (although now 1.5 is live I suppose I ought to use it ...)
[22:02] <jelmer> awilkins: Strange, it works fine here
[22:02] <awilkins> Is it in the headers?
[22:03] <jelmer> ahh, it's a typo
[22:03] <jelmer> awilkins, please pull from the 0.4 branch
[22:04] <jelmer> It was part of an assert() that wasn't being compiled on my machine
[22:04]  * awilkins pulls
[22:04] <jelmer> because I was using -DNDEBUG
[22:04] <awilkins> Bugger, more conflicts :-(
[22:04] <mwhudson> beuno: your update of the description on 242469 made me chuckle
[22:06] <beuno> mwhudson, some frustration may of passed on to there  :)
[22:08] <awilkins> jelmer: Same error, line 85 of client.c
[22:09] <awilkins> jelmer: Ok, typo fixed
[22:10] <awilkins> jelmer: And now back to our friendly "initializer element not constant"
[22:10] <awilkins> client.c:750
[22:11] <awilkins> I think it's the sizeof()
[22:12] <jelmer> awilkins: You may want to change the &PyType_Type to just NULL
[22:14] <awilkins> jelmer: Same in editor.c:[63,135,139,35-,354,444]
[22:17] <awilkins> jelmer: Changing to NULL fixed some of those (where the &PyTYpe_Type was)
[22:17] <awilkins> But not all
[22:18] <awilkins> http://pastebin.ca/1054359
[22:19] <jelmer> awilkins: you may want to try setting tp_dealloc to NULL in some of these cases where I've set it to PyObject_Del
[22:21] <awilkins> jelmer: Wahey, next .c files worth of errors :-)
[22:22] <awilkins> Same things again , methinks
[22:22]  * awilkins hands out the NULL pointers
[22:24]  * awilkins updates paste
[22:26] <awilkins> OK, C errors fixed, now back to Python ones :-)
[22:28] <mwhudson> if the objects go through PyType_Ready you can leave ob_type and tp_dealloc to null (and maybe some other fields too)
[22:28] <awilkins> Distutils is choking now :-(
[22:41] <lazy1> is there a way to preview what "bzr push" will do?
[22:41] <mwhudson> missing, sorta
[22:42] <mwhudson> lazy1: what sort of answer do you want?
[22:42] <mwhudson> a diff?  a list of revisions?
[22:42] <lazy1> bzr push --preview
[22:42] <lazy1> :)
[22:43] <lazy1> is there a shortcut for "last pulled revision"? (so I can use "bzr log")
[22:43] <LarstiQ> lazy1: yes, but what would you like the output of that to be? (Ie, are you after `bzr missing push/location`?)
[22:43] <awilkins> jelmer: Would you happen to know whether you need to build things with the same compiler used to build the SVN and APR libs... because it's become VERY unhappy now
[22:43] <lazy1> I about to push my changes and would like to know which revision will get pushed
[22:44] <jelmer> awilkins: I'm not sure
[22:44] <LarstiQ> lazy1: I'd recommend `bzr missing` for that scenario
[22:44] <awilkins> jelmer: From the output, SVN and APR I have were built with MSVC
[22:44] <james_w> lazy1: hi, "bzr diff -r submit:" will show you a diff of your changes compared to the branch "bzr push" will push to
[22:44] <james_w> bzr diff -r ancestor:.../wherever will do it for other branches
[22:44] <james_w> "bzr send -o-" will show you something like the first.
[22:45] <lazy1> thanks
[22:46] <awilkins> jelmer: MSVC hates you because you used stdbool.h though :-)
[22:46] <lazy1> james_w: is there a way to set the submit branch? (not with bzr pull --remember)
[22:47] <jelmer> awilkins: heh, ok
[22:49]  * awilkins pastes in a simple stdbool.h
[22:50] <awilkins> Heh, MSVC also hates you for using those funky dot things (sorry, my C is virtually absent) on client.c:724
[22:51] <lazy1> works like a charm, thanks
[22:51] <beuno> mwhudson, downloading bundles from LH (trunk and LP) seems really broken. It outputs a binary file which is unmergeable: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/argentina%40gmail.com-20080622180415-9ognqtaiptt58z7p?start_revid=argentina%40gmail.com-20080623155739-je1svgi6ikjyudfq&remember=argentina%40gmail.com-20080623052141-lr31t9rjdbsuqfib&compare_revid=argentina%40gmail.com-20080623052141-lr31t9rjdbsuqfib
[22:52] <beuno> am I doing something wrong this time too?
[22:52] <mwhudson> i wouldn't be at all surprised
[22:52] <mwhudson> it's a bit of a crazy feature really
[22:52] <jelmer> awilkins, wow, that's quite an old C compiler
[22:53] <awilkins> I'm using the VS2003 compiler because of all the warnings in the distutils files about having to use the same compiler that Python was built with
[22:53]  * beuno files a bug
[22:54] <mwhudson> beuno: here is somewhere where i really think "delete the feature" is a viable choice
[22:54] <awilkins> jelmer: I had a terrible time finding a package for it, and poking all the magic values into the registry that the full Visual Studio install shoves in so msvccompiler.py can read them and set it up
[22:56] <jelmer> awilkins: It's not very easy to work around that :-/
[22:56] <beuno> mwhudson, fair enough. I'll clean it up after I finish going through the last bits for today for the new theme
[22:56] <jelmer> awilkins: Specifying these member values in the right order is a pain
[22:57] <awilkins> I suppose I can keep trying the mingw compiler
[23:00] <awilkins> jelmer: Have a shufty at the mingw output
[23:00] <awilkins> http://pastebin.ca/1054520
[23:01] <beuno> jelmer, bzr.debian.org seems to hate people, so I'm going to send a tarball to the DD
[23:01] <jelmer> beuno, ah, ok
[23:01] <jelmer> beuno, there's also a tarball and all that up on my site
[23:02] <beuno> doesn't work with nosmart either  :/
[23:02] <jelmer> http://samba.org/~jelmer/debian/unstable
[23:02] <beuno> (it does for me)
[23:02] <beuno> jelmer, I don't see it on there, but I sent it off anyway, so no worries
[23:04] <jelmer> awilkins, yikes
[23:04] <jelmer> awilkins, yeah, that doesn't look like it's going to work
[23:04] <jelmer> awilkins, you don't have a newer msvc?
[23:05] <awilkins> jelmer: Yes, but is that going to link properly with Python?
[23:05] <jelmer> awilkins: Not sure :-/
[23:05] <awilkins> I have the latest windows SDK, which is MSVC 9
[23:05] <awilkins> Python 2.5 was built on MSVC 7
[23:06]  * awilkins has very few clues as far as C goes
[23:06] <awilkins> I mostly stick to languages that link dynamically and don't whine about it.
[23:07] <jelmer> I think it's worth a try to check with MSVC9
[23:08] <awilkins> jelmer: I'm not convinced IU've got the libraries right ; they all have different names on Win32
[23:08] <awilkins> But I got the object files to build
[23:09] <jelmer> alternatively, you could avoid the dot notation, but that's quite a lot of work
[23:12] <tethridge> anybody know the size of the mysql repository?
[23:14] <awilkins> jelmer: MSVC 9 hates that syntax too
[23:14] <jelmer> hmm, it's standard C99
[23:14] <jelmer> awilkins, what's the error exactly?
[23:15] <mwhudson> msvc will probably never support c99
[23:15] <awilkins> I'll paste
[23:15] <mwhudson> for fun and games echoing down the years
[23:15] <awilkins> http://pastebin.ca/1054580
[23:16]  * awilkins switches back to mingw
[23:20] <awilkins> Hmm, are warnings like "defined locally after being referenced with dllimport linkage" relevant?
[23:28] <beuno> hrm...
[23:28] <beuno> anyone know what this could be:
[23:28] <beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead.no_bundles$ bzr push lp:loggerhead
[23:28] <beuno> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
[23:28] <beuno> bzr: ERROR: Pack '13c6ba3d1a8d731ec8f18bfb908585d6' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x89eb72c>
[23:28] <beuno> I've never seen that  :/
[23:29] <beuno> hm, while autopacking...
[23:30] <mwhudson> beuno: try again i think
[23:33] <beuno> abentley, I see you worked on a bug related to that, is this what it fixed (I'm running bzr.dev, but maybe it's on the LP side): http://paste.ubuntu.com/22456/
[23:33] <beuno> mwhudson, that worked, thanks
[23:37] <igc> morning
[23:38] <beuno> mornin' igc
[23:38] <igc> hi beuno
[23:40] <beuno> Jc2k, incidently, while working on the gnome theme for LH, I found you have an unclosed <li> in the header:    <li><a href="http://live.gnome.org/BzrForGnomeDevelopers"><span>Bazaar wiki page</span></a><li>
[23:45] <lifeless> beuno: oh!
[23:45] <lifeless> beuno: that bug is biting pqm for launchpad developers
[23:45] <awilkins> jelmer: Look like libraries ; I don't the the auto-library-finding is quite so luxurious on Win32 ; you can look at the horrible pathes I've had to do afterward
[23:46] <lifeless> mthaddon: ^^^^
[23:46] <lifeless> beuno: could you make sure there is a bug exactly matching that, and grab all log details possible etc
[23:46] <beuno> lifeless, sure. I see two of them, but it could be related to either
[23:47] <beuno> bug #165293 and #212908
[23:49] <mwhudson> neither of those bugs mention autopacking
[23:50] <lifeless> beuno: the thing is, push shouldn't trigger either under normal circumstances
[23:50] <beuno> alright, new bug, here I come
[23:50] <lifeless> beuno: either we're hitting md5 collisions in loggerhed (a possibility)
[23:51] <lifeless> or, something is funky
[23:51] <lifeless> mwhudson: can you grab a copy of the launchpad data for the branch beuno was pushing too
[23:51] <lifeless> beuno: can you take a copy of your branch & repository that you pushed from, so we can reproducce
[23:51] <mwhudson> lifeless: i think when beuno pushed again, it worked
[23:51] <beuno> it did
[23:51] <lifeless> mwhudson: we can rollback one push
[23:51] <mwhudson> lifeless: ok
[23:52] <lifeless> mwhudson: through the magic of robert
[23:52] <jam> abentley: I have a question about bzrlib.merge.transform_tree
[23:52] <lifeless> (but only if we have the obsolete packs etc). Its not guaranteed but should be doable
[23:52] <mwhudson> beuno: which branch was it?
[23:52] <jam> abently: If I do: merge.transform_tree(tree, tree.basis_tree(), [file_id]), shouldn't it revert that text to the value in the basis?
[23:53] <beuno> mwhudson, a branch I did lh.dev -> lh.feature -> commit -> push to trunk
[23:54] <mwhudson> beuno: can you not push over non-lefthand parents to trunk please?
[23:54] <mwhudson> if that's what you did
[23:54] <mwhudson> lifeless: https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk, er, interesting
[23:55] <lifeless> mwhudson: set allow_append_revisions_only=True (or whatever the setting is - 'bzr help configuration')
[23:55] <beuno> mwhudson, you mean, merge in trunk and push?  Ah, yes, I can see how that's annoying, sorry
[23:55] <lifeless> mwhudson: you'll want to uncommit the tip
[23:56] <beuno> mwhudson, that's now what I just did though
[23:56] <lifeless> mwhudson: or push --overwrite, to restore it
[23:56] <mwhudson> beuno: can you clean it up?
[23:56] <mwhudson> feel free to push --overwrite or whatever
[23:57] <lifeless> mwhudson: did you get a copy of the repo already ?
[23:57] <beuno> mwhudson, sure, I'll clean it up now and overwrite
[23:57] <mwhudson> lifeless: so i have two tarballs of the branch, one from the push area, one mirror
[23:57] <beuno> well, after you copy whatever you need to debug  :)
[23:57] <mwhudson> lifeless: ye
[23:57] <mwhudson> s
[23:57] <mwhudson> lifeless: what did you want me to do with them?
[23:57] <lifeless> mwhudson: thanks, drop them on devpad
[23:57] <lifeless> beuno: can you mail me the copy of your repository & branch too
[23:57] <beuno> mwhudson, sure, on it's way
[23:58] <mwhudson> beuno: thanks
[23:58] <beuno> er, lifeless
[23:58] <lifeless> beuno: thanks
[23:58] <beuno> just finishing filing the bug
[23:58] <lifeless> I'm so tempted to repeat by mini-python-dbs-suck rant
[23:58] <tolstoy> If I tag in a repo, push it to a server, then, from somewhere else, pull  from that server, how come I don't get the new tags?
[23:59]  * mwhudson gets confused by network reachability in the data centre
[23:59] <bob2> tolstoy: iirc push doesn't push tags unless it also has some other data to push