[00:44] <poolie1> mkanat: the warning is harmless
[00:44] <poolie1> mkanat: is that an imported branch on launchpad, or elsewhere?
[00:44] <mkanat> poolie1: Yeah, I figured.
[00:44] <poolie1> nekohayo: he's away this week probably
[00:45] <mkanat> poolie1: I imported it locally. The problem seemed to be that I was importing into a rich-root-pack repo.
[00:45] <mkanat> poolie: When I used the default repo type instead, it worked.
[00:45] <mkanat> poolie: It also could have been some old bug, since it was bzr 1.5.
[00:45] <poolie> ok
[00:46] <nekohayo> poolie: .... this "week"?! he leaves IRC on for weeks on end? :)
[00:46] <nekohayo> oh well too bad I guess
[01:14] <jelmer> asac, hi
[01:14] <jelmer> asac, authentication should work out of the box with bzr-svn
[01:14] <jelmer> asac, http or https authentication doesn't work with bzr itself, so you may have to specify "svn+http://" or "svn+https://" to get it to bypass the standard bzr http transport.
[01:19] <asac> jelmer: oh. cool. thank you!
[05:26] <grettke> Hi. You guys had any luck running a bzr smart-server on Vista?
[05:27] <spiv> AFAIK the TCP server works fine.  I think I recall hearing about someone using it over HTTP with NTLM auth at some point, I'm not sure which version of Windows though.
[05:30] <grettke> Thanks. Strangest thing, Vista seems to be blocking the smart server. It allows Perl echo servers to run, and I can access bzr locally, but it doesn't show up over the netwoek. It is Vista that is doing something weird.
[05:37] <spiv> grettke: try explicitly using the external IP address in the --port argument?  e.g. --port 1.2.3.4:4155
[05:38] <grettke> spiv: Will do.
[05:44] <grettke> spiv: That does it. Why is this necessary? There is something with which I am not familiar because it didn't occur to me to bind it in that manner.
[05:50] <AfC> (is that the IPv6 bug again?)
[05:51] <AfC> grettke: (we had to do that, but in our case it was a problem of `bzr serve` not starting (blowing up) and this forced it to think of the address as IPv4 only which made it work right)
[05:51] <spiv> grettke: good question, it might be to do with IPv6
[05:51] <spiv> Or it might be that passing None as the host to Python's socket.listen method is choosing the wrong interface for some reason.
[05:51] <spiv> grettke: it might be related to https://bugs.edge.launchpad.net/bzr/+bug/293697
[05:51] <AfC> grettke: (this was on a Linux server, so even more tangential to what you're asking about)
[05:52] <spiv> Hmm, actually, I don't think that's the bug I was thinking of.
[05:52] <spiv> Ah, https://bugs.edge.launchpad.net/bugs/286871 is what I was thinking of.  That's also what AfC is referring to.
[05:53] <grettke> spiv, AfC, ubottu: I had pretty much ruled out the router, the switch, the other computer, and even bzr since I can access from the server box itself, just not other computer; the last thing about which I wondered was whether or not I should disable IPv6 completely on the card.
[05:54]  * AfC {chortle}s at the addressee list in the above line
[05:57] <AfC>  grettke: I imagine you can just specify a 4 byte IPv4 address as Andrew suggested and move on. I haven't the faintest whether Microsoft uses IPv6 internally in its operating system (if it did, then turning it off might make things go splat) or for the E.T. phone home "feature".
[05:59] <grettke> Thanks everyone, now I can sleep well again; this has been a thorn in my side I tell you!
[05:59] <spiv> grettke: you could try --port 0.0.0.0:4155 to further narrow down what's going wrong.  If that works, it suggests that it's trying an IPv6 address.
[06:00] <spiv> grettke: if it doesn't, it suggests for some reason passing None as the host is causing it to bind to the wrong interface (or perhaps simply that it's not binding to all interfaces).
[06:00] <spiv> grettke: either way, a bug report with the details would be good I think.
[06:00] <grettke> spiv: That does work: bzr serve --port 0.0.0.0:4155
[06:01] <grettke> spiv: Will do.
[06:04] <grettke> bye guys
[06:16] <mtaylor> help? "bzr: ERROR: [Errno 14] Bad address"
[06:21] <mwhudson> mtaylor: that's a new one
[06:21] <mtaylor> mwhudson: well that's not what I want to hear . :(
[06:21] <mwhudson> mtaylor: what were you doing?
[06:21] <spiv> mtaylor: which version?
[06:21] <spiv> mtaylor: and which OS?
[06:22] <mtaylor> mwhudson: I get it doing just about anything - bzr diff , bzr commit
[06:22] <mtaylor> spiv: opensolaris
[06:22] <spiv> mtaylor: I think this may be a bug that was recently fixed in bzr.dev
[06:22] <mtaylor> and version is...
[06:22] <spiv> mtaylor: ah, yep, then it probably is that bug.
[06:22] <mtaylor> spiv: 1.9
[06:22] <mtaylor> ok
[06:22] <mtaylor> phew. I'll just update then
[06:22] <mwhudson> oh, the chdir('') one?
[06:22] <mwhudson> that makes sense
[06:23] <spiv> mwhudson: right
[06:23] <spiv> mtaylor: https://bugs.edge.launchpad.net/bzr/+bug/297831 if you're curious
[06:23] <spiv> mtaylor: a workaround would be to delete the _readdir_pyx.so, although that will impact performance a bit
[06:24]  * spiv heads off
[06:24] <mtaylor> nah. I'm running a pre-release version of opensolaris anyway - I might as well upgrade bzr to bzr.dev :)
[06:24] <mtaylor> spiv: thanks!
[06:24] <spiv> mtaylor: :)
[06:24]  * mtaylor stabs solaris in the face
[07:11] <vila> hi all
[07:12] <GPHemsley> (fullermd:) What's the deal with the new repo format, 1.9?
[07:17] <Peng_> What about it? It has a faster and more space-efficient index format.
[07:19] <GPHemsley> How would I use it?
[07:20] <GPHemsley> Is there documentation on it somewhere?
[07:23] <Peng_> If you don't need your repo to be compatible with bzr 1.8 or earlier, you'd run "bzr upgrade --1.9".
[07:26] <GPHemsley> Peng_: And how is 1.9 better?
[07:41] <Peng_> GPHemsley: Like I said, it uses a smaller and faster index format.
[07:41] <Peng_> GPHemsley: If your project is pretty small, it probably won't make a huge difference.
[07:56] <loxs> hello, is there any installer that has "everything included" to install bzr with everything needed to be able to access ssh+bzr repositories from windows?
[08:06] <Peng_> Can't the Windows installer do that?
[08:06] <Peng_> Though you might want to install putty anyway.
[08:07]  * Peng_ leaves. Sorry, but I don't know much about Windows anyway.
[08:09] <loxs> well, I installed bzr and it tells me that ssh+bzr is illegal protocol
[08:12] <luks> sounds like a serious bug in the installer
[08:14] <loxs> is it possible the reason to be that I previously had python installed?
[08:19] <loxs> well, I uninstalled python and installed a "fresh" copy... and it still can't connect to ssh+bzr repositories
[08:41] <loxs> I installed the latest version from 1.7 series. Now it doesn't tell that it's illegal protocol, but the connection times out
[08:43] <loxs> and there is no networking problem, because I can connect via putty without any problems
[08:52] <loxs> same with 1.8 series :(
[09:01] <loxs> OK, it's possible I'm doing it wrong
[09:01] <loxs> is bzr co bzr+ssh://user@some.address.com/some/directory/ valid syntax?
[09:31] <loxs[]> luks, any idea?
[09:31] <luks> loxs[]: yes, it's a valid syntax
[09:31] <luks> no idea about the problem though
[09:32] <luks> it would be probably useful to file a bug report
[09:32] <loxs[]> yes, now I'm searching for a similar thing
[09:32] <loxs[]> the problem is that I can't provide any useful information :)
[09:35] <loxs[]> and I am not sure that something is not wrong with my settings
[09:35] <loxs[]> my windows I mean (i have no windows knowledge)
[11:51] <Odd_Bloke> poolie1: lifeless: My ~bzr membership is about to expire, the emails keep telling me to poke one of you about it. :)
[12:33] <matkor> What it means:  Contents conflict in <file> ?
[12:33] <matkor> How can I resolve it ?
[12:34] <matkor> ah bzr mv ...
[12:35] <skam> hi everyone
[12:35] <spiv> matkor: "bzr help conflicts" might be helpful
[12:35] <skam> i have to "split" a bazaar repository into three parts: a big repository should be split into three smaller ones (due to some changes in our company). is this possible?
[13:20] <vila> skam: If your big repositories contains 3 independents projects, yes. You can create one repository by project, and pull all project branches in their specific repo
[13:20] <vila> s/big repositories/big repository/
[13:38] <ras0ir> im using ftp (vsftpd) to push, however .bzr dir umask is shown as "drwx------", and i cannot clone because of "bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden)" message.
[15:38] <fta2> hiredman, any plan to update bzrtools in jaunty ? bzr is stuck to 1.6.1 instead of 1.9 because of this.
[15:38] <fta2> hiredman, nm
[15:38] <fta2> i meant "hi," (damn xchat)
[15:39] <jelmer> fta2: iirc James had requested a sync for bzrtools as well
[15:40] <james_w> nope, I forgot
[15:40] <james_w> looks like we need bzrtools and bzr-gtk, anything else?
[15:41] <fta2> bzr-builddeb is stuck too
[15:41] <vila> jam: ping
[15:41] <james_w> fta: stuck?
[15:42] <fta2> well, i mean, upgrading bzr removes bzr-builddeb and bzrtools
[15:42] <james_w> ah, ok
[15:42] <james_w> that will take an upload, need to check that it works first though
[15:44] <fta2> thanks
[16:03] <quicksilver> is there a more recommended protocol than sftp these days?
[16:04] <fta2> bzr+ssh
[16:06] <quicksilver> does that work better over slightly higher latency links?
[16:06] <quicksilver> fresh branch checkouts are a bit painful over adsl.
[16:06] <LarstiQ> bzr+ssh has 1/3rd the roundtrips of sftp
[16:07] <LarstiQ> quicksilver: so you'll notice with high latency links
[16:08] <quicksilver> excellent.
[16:19] <quicksilver> Hmm, well bzr+ssh is making much more substantial use of my network connection, but it's not saying much while it does it.
[16:19] <quicksilver> no funky progress bar
[16:19] <jelmer> yeah, progress reporting sucks a bit atm :-/
[16:20] <quicksilver> sftp was 14 minutes to check out 604 revision, 70 megabyte repo
[16:21] <quicksilver> bzr+ssh was 2 minutes 40 seconds.
[16:21] <quicksilver> woot :)
[16:23] <vila> LarstiQ: hi ! Where did you get that 1/3rd ?
[16:23] <LarstiQ> vila: here from what lifeless has said, I suppose
[16:25] <vila> ok, it's for bzr branch without shared repos I presume then
[16:25] <LarstiQ> I think so, yes.
[16:26] <vila> For a split second I thought you had implemented some effort tests to compare sftp vs bzr+ssh without telling us :-)
[16:27] <LarstiQ> no no, sorry :)
[16:27]  * LarstiQ goes to his mom for dinner, ciao
[16:34] <Dvyjones> How do I set up bzr for launchpad?
[16:36] <Tak> set up?
[16:41] <Kobaz> mmm
[16:42] <Kobaz> so what's the preferred repo layout
[16:42] <Kobaz> i was trying to do like, repo/project/trunk repo/project/branches, etc
[16:43] <Kobaz> what would the /project/ be... making it a branch doesn't seem to work
[16:43] <Kobaz> ie: branch within a branch
[16:44] <james_w> Kobaz: if you want then it can just be a plain directory
[16:44] <Kobaz> k
[16:44] <james_w> I would advise you make repo/ a plain directory
[16:44] <Dvyjones> How do I set up SSH keys with Bazaar? It seems like it isn't detecting my key...
[16:44] <james_w> each /project/ a shared repository
[16:45] <Kobaz> yeah
[16:45] <james_w> then branches underneath that
[16:50] <Peng_> Dvyjones: What OS?
[16:50] <Dvyjones> Linux
[16:50] <Peng_> Dvyjones: There is absolutely no magic involved. It just calls out to OpenSSH. If "ssh foo@bar" works, it will work with bzr.
[16:51] <Dvyjones> So it's probably me specifying the wrong SSH key in launchpad, or it hasn't updated yet...
[16:53] <Peng_> Probably, yeah. Or your SSH key suffers from the OpenSSL vulnerability.
[16:53] <Peng_> Or you made some sort of mistake when pasting it into the box on LP.
[16:53] <Dvyjones> It was generated just a couple of days ago on Ubuntu 8.120, so I guess not :P
[16:55] <Peng_> heh, ok
[16:55] <Peng_> I don't know what's wrong, then. Sorry.
[16:56]  * Dvyjones copied it again, and it worked
[17:06] <Kobaz> er
[17:06] <Kobaz> whoops
[17:06] <Kobaz> how do i do an unpush
[17:56] <ras0ir> can someone explain me why chmod values are different in bzr push sftp:// and bzr push ftp:// ?
[18:20] <cody-somerville> How do I configure who it says made the commit?
[18:20] <cody-somerville> Right now it is using my hostname
[18:20] <beuno> cody-somerville, bzr whoami
[18:21] <cody-somerville> thanks
[18:25] <danser> I accidentally did some commits without having my whoami configured. is there a way to change the committer's names afterwards?
[18:26] <jelmer> danser, only by redoing the commits
[18:26] <danser> jelmer: ok, thanks
[18:29] <Peng_> Unless your default username is really embarrassing, it's probably best to just live with the mistake.
[18:30] <danser> it's only about two recent commits, and I'm still the only author, so I don't mind redoing these :-)
[19:00] <Tak> is it possible to encode a password in a location? or noninteractively at the commandline at all?
[19:00] <jelmer> Tak, yes, "bzr://username:password@hostname/path"
[19:02] <Tak> hmm - I get: ERROR: Invalid url supplied to transport: "invalid port number (part of password) in url
[19:02] <Peng_> Maybe supply a port too?
[19:02] <Tak> I am, actually
[19:05] <Tak> the entire url looks like: sftp://user:pass@host:port/path/
[19:49] <Tak> do I need to urlescape the password? (the url is already in single-quotes for the shell)
[20:43] <seb_kuzminsky> i'm thankful for the vcs-imports team
[20:44] <seb_kuzminsky> but i have a question
[20:44] <seb_kuzminsky> i'm trying to branch this: https://code.launchpad.net/~vcs-imports/emc/trunk
[20:45] <seb_kuzminsky> if i branch it into its own, new repo (ie, i run bzr branch in a directory which is not initialized) it works nice & fast
[20:45] <zephyr> is there anything special i have to do to push files from olive to a website through ftp?
[20:45] <seb_kuzminsky> but if i try to branch into an existing shared repo, with some other locally-created branches, it's awfully slow
[20:46] <seb_kuzminsky> it says "Transferring 0/4", then stops & bzr pegs the CPU, and it just sits there
[20:46] <luks> seb_kuzminsky: your repository is probably in a different format and it has to convert it
[20:46] <seb_kuzminsky> ah
[20:46] <luks> try bzr info on both
[20:46] <seb_kuzminsky> new branch of lp: pack-0.92
[20:47] <seb_kuzminsky> branch into existing repo: rich-root-pack
[20:47] <seb_kuzminsky> thanks luks!
[20:48] <seb_kuzminsky> i'm a bit confused by the different repo formats
[20:48] <luks> you are not the only one :)
[20:48] <seb_kuzminsky> i guess i should stay on the default pack-0.92, but it kept bugging me to "upgrade my repo"
[20:49] <seb_kuzminsky> :-/
[20:49] <zephyr> hi. i just started using bzr through olive - i am trying to push some test files to my server through ftp, i dont get an error, but nothing happens
[21:00] <hiredman> I grabbed bzr-git from launch bad, I see "TypeError: 'Tree' object is not iterable" when I try to branch from a git repo
[21:02]  * mwhudson points at jelmer 
[21:02] <mwhudson> hiredman: what version of bazaar?
[21:03] <hiredman> 1.9
[21:04] <mwhudson> hmm
[21:04] <hiredman> python 2.5
[21:04] <mwhudson> hiredman: are there bug reports for bzr-git?
[21:10] <hiredman> http://gist.github.com/29575 is the output
[21:10] <jml> hi
[21:10] <jml> I just got bit by a UI bug in loom.
[21:10] <jml> but it's a pretty subtle one.
[21:11] <mwhudson> hiredman: hm, fairly mysterious
[21:12] <jml> I was submitting threads to a PQM via exported branches, I ended up having one of the threads rejected because of a text conflict caused by one of my lower threads.
[21:12] <hiredman> :(
[21:13] <jml> I feel that loom should have warned me about this.
[21:13]  * james_w waves to jml 
[21:13] <jml> james_w: hello.
[21:13] <james_w> mwhudson: thanks again for loggerhead, just set it up on a site and it was painless and works beautifully
[21:13] <mwhudson> james_w: glad it worked for you!
[21:14] <james_w> jml: presumably they didn't conflict before you started exporting?
[21:14] <jml> james_w: they did!
[21:14] <jml> james_w: the interesting thing here is that the lower thread had commits that were not yet merged into the upper threads.
[21:14] <james_w> ah, that'll do it
[21:15] <james_w> so you're able to export threads from above your current position in the stack?
[21:15] <jml> thing is, the only way to find that out with loom is to go to the bottom thread and merge all the way up.
[21:15] <jml> james_w: I think export-loom just does the whole stack -- not sure though.
[21:16] <jml> james_w: I might have switched to a higher thread also, again not sure.
[21:16] <james_w> ah, I haven't used export-loom, I see that would be a problem
[21:16] <james_w> what warning would you have liked?
[21:16] <james_w> "You are exporting a loom that hasn't been fully merged. The resulting branches may conflict"?
[21:17] <jml> james_w: I guess what I would like is something akin to "bzr status" that shows me if any threads have revisions that haven't been merged into the higher threads
[21:17] <jml> and also what's changed since the last record (hah!)
[21:18] <james_w> it sounds like they are things that bzr-loom should provide
[21:18] <james_w> representing it obviously won't be easy, as you indicate
[21:18] <jml> yeah.
[21:38] <jfroy|work> Hello people
[21:38]  * jml shakes his fist at combine-thread
[21:38] <jfroy|work> I was wondering if there was an semantical equivalent of "svn mv" something out of a branch into a new one.
[21:39] <jfroy|work> That is, I have a project that has grown way too large, and I'd like to refactor a sub-component of it as a sub-project, with its own set of branches.
[21:39] <jfroy|work> Is there a way to grab a sub-tree of a branch and turn that into a branch, or branch a sub-tree of a branch. Or is the infamous "move the file manually into a new branch" the way to go.
[21:40] <jml> anyone know how I can get info from the last record?
[21:57] <jelmer> beuno, hi
[21:58] <jelmer> mwhudson, hi
[21:58] <mwhudson> jelmer: some bzr-git queries from hiredman
[21:59] <jelmer> hiredman, pong
[21:59] <jelmer> mwhudson, we (and by that I mean Lo-Lan-Do) are working on also getting loggerhead up and running on alioth
[21:59] <mwhudson> jelmer: nice
[22:03] <james_w> jelmer: cool
[22:06] <james_w> jelmer: does the version of loggerhead you are using include the serve-branches script? Is that what you are using?
[22:07] <jelmer> james_w, no, we're the standard loggerhead package - which uses start-loggerhead
[22:07] <james_w> using serve-branches can display the hierarchy nicely
[22:08] <james_w> going by one of the bug reports it sounds like that is what would be preferred
[22:09] <jelmer> ah, wasn't aware they're actually doing different things these days
[22:10] <mwhudson> serve-branches -- new, perhaps a little dwimmish, liked\
[22:10] <mwhudson> start-loggerhead -- old, crappy, i personally hate it
[22:11] <james_w> I'm not sure where the extra port is coming from, do you have the public URL setting in loggerhead.conf?
[22:22] <jelmer> mwhudson, but serve-branches doesn't use loggerhead.conf, does it?
[22:22] <mwhudson> jelmer: no, you have to use --style options
[22:23] <jelmer> it would be nice if there was a way to just get the stylistic improvements by setting some variable in lgogerhead.conf
[22:24] <mwhudson> you mean the serving from directories stuff?
[22:24] <mwhudson> because there isn't any real difference in appearance, i thought
[22:25] <jelmer> I'd like to get the hierarchy that serve-branches has
[22:25] <mwhudson> what else can't you get with serve-branches?
[22:26] <jelmer> That's the only bit I'm aware of that's differnet (but I may not be very well informed)
[22:26] <mwhudson> then why not use serve-branches?
[22:27] <mwhudson> i realize you can't use loggerhead.conf so neatly, but a little shell script with --port this and --host that doesn't seem so hard
[22:28] <jelmer> mwhudson, this is for the debian package, which already uses start-loggerhead
[22:29] <mwhudson> jelmer: now you've lost me
[22:29] <mwhudson> which part of the debian package?
[22:29] <jelmer> the init script
[22:30] <mwhudson> oh right\
[22:30] <mwhudson> did you see that trunk loggerhead has one of them too now?
[22:30] <jelmer> the alternative is for me to allow the user to configure a choice between start-loggerhead and serve-branches
[22:31] <jelmer> and to confuse users since their configuration for address/port to listen on is in different places
[22:31] <mwhudson> ah
[22:31] <james_w> the loggerhead.conf suits a package really well, and so having an option to turn on the hierarchical browsing would be great IMO
[22:32] <mwhudson> i'm fine with the idea of configuring serve-branches from a config file
[22:32] <mwhudson> i'm not really fine with it being the same as loggerhead.conf currently is though
[22:34] <lifeless> or
[22:34] <lifeless> nuke loggerhead.conf completely
[22:35] <lifeless> and let a /etc/defaults/loggerhead set variables
[22:35] <lifeless> (in the packaging)
[22:38] <jelmer> mwhudson, serve-branches doesn't necessarily have to support a config file - it can just be a tool to quickly get a loggerhead up
[22:38] <jelmer> the important thing (for me at least) is that the same functionality is in start-loggerhead
[22:41] <fullermd> Looks like Dragonfly finished their git conversion.
[22:54] <mwhudson> jelmer: i don't see why you so want start-loggerhead
[22:57] <jelmer> mwhudson, it means I don't have to worry about the configuration (since except for enabling it, it is all outside of /etc/default), because it can fork for me as well as log etc, and because it's already there (otherwise I'd have to make sure there's a smooth transition from start-loggerhead to serve-branches)
[22:58] <mwhudson> jelmer: well if you'd _asked_ me when you were packaging loggerhead, i'd have told you to stay away from it ;-p
[22:58] <mwhudson> jelmer: when serve-branches is feature compatible, we can do a compatibility shim somehow
[22:59] <lifeless> mwhudson: or, as some of the features are insane
[22:59] <jelmer> mwhudson: at that time, serve-branches wasn't even installed by setup.py IIRC..
[22:59] <lifeless> mwhudson: you could just deprecate it
[22:59] <mwhudson> there's always going to be a spot of friction though, because the way the branches are specified
[22:59] <mwhudson> +of
[23:43] <hiredman> jelmer: ping
[23:43] <jelmer> hiredman, pong
[23:43] <hiredman> Yo
[23:47] <jelmer> hiredman, you were hitting issues in bzr-git
[23:48] <hiredman> Yes.
[23:49] <hiredman> I was not able to branch from a git tree, or whatever you call it
[23:50] <hiredman> I am not even sure how complete bzr-git is suposed to be
[23:50] <hiredman> http://gist.github.com/29575 was the output