[00:23] <tethridge> I'm trying to push my first branch to launchpad.  I've registerd a branch and now I'm trying to push it, but I'm getting an error that reads "bzr: ERROR: Transport operation not possible: http does not support mkdir()"
[00:23] <tethridge> anybody know what I'm doing wrong?
[00:24] <fullermd> You need to use bzr+ssh to push to launchpad, not http.
[00:24] <beuno> tethridge, yes, you need to specify your Launchpad id with:   bzr launchpad-login <username>
[00:25] <beuno> that will start using bzr+ssh instead of http (which is the default read-only)
[00:25] <tethridge> that did the trick
[00:25] <tethridge> thanks
[00:25] <beuno> np
[00:25]  * beuno is off for a run
[00:38] <kees> in RCS and CVS, there are in-file ident tags ($Id, $Source, etc).  How can I get bzr to update these?
[00:38] <kees> (i.e. the strings that "ident" looks file)
[00:39] <fullermd> The phrase you're looking for is "Keyword Expansion".  There's no in-core support for it.
[00:40] <fullermd> There's a proof-of-concept plugin floating around somewhere.  That keyword should bring it up.
[00:40] <kees> fullermd: thanks, yeah.  the search terms were not obvious (id, tag, rcs) heh.
[00:41] <fullermd> http://bazaar-vcs.org/KeywordExpansion specifically.
[00:42] <kees> thanks.  I had just found it too :)
[00:59] <markh> is support for platform-specific line endings (ie, windows line endings) still moving, or has it stalled?
[01:03] <fullermd> I haven't heard anything about it recently...
[01:05] <Peng_> Was it ever not stalled?
[01:05] <markh> its a bummer as it prevents me from effectively using a launchpad mirror of a CVS branch on Windows - the "real" CVS trunk and the bzr branch aren't identical at all on my platform - every single file differs :(
[01:05] <fullermd> Well, it was backfiring for a while.
[01:06] <markh> in the short term, I wonder if I can convince launchpad to allow a branch to nominate the line-ending for such an import...
[01:06] <fullermd> I dunno.  I thought at the end of the last spurt, the POC plugin for it was roughly completeish.  Not sure.
[01:09] <markh> POC?
[01:09] <bob2> proof of concept
[01:09] <bob2> I thought the only issue was dumb editors destroying the existing line endings
[01:09] <markh> right - the wiki at http://bazaar-vcs.org/LineEndings doesn't refer to an impl...
[01:09] <bob2> so it seems a bit weird that the bzr import of a cvs branch is broken
[01:10] <markh> right - how to change the copy in the working tree?
[01:10] <markh> well - not "broken"
[01:10] <fullermd> Well, either that, or Pinocchio On Crack   ;)
[01:10] <markh> the cvs checkout on windows has \r\n, the bzr branch has \n
[01:10] <bob2> weird
[01:10] <fullermd> Anyway.  It might have been an actual bundle for bzr.dev instead of a plugin.  That would make it tougher to play with.
[01:10] <markh> why is it wierd?
[01:10] <markh> if I checkout on linux, the cvs branch has \n
[01:10] <bob2> cvs is stupid like that
[01:10] <markh> ie, cvs does have basic line-end translation
[01:10] <markh> heh
[01:10] <markh> or smart ;)
[01:10] <bob2> bzr just faithfully copies it
[01:10] <markh> I get the correct line endings
[01:11] <bob2> so the bzr import should just have whatever was in the cvs repo
[01:11] <bob2> and the only issue would be editors messing it up
[01:11] <markh> the cvs repo stored \n IIUC
[01:11] <markh> but I expect if the cvs import process was run on Windows, the bzr repo would get \r\n
[01:12] <markh> assuming that import process just does a normal "cvs co" on the platform
[01:12] <snova> i'm getting an error when i try to set my launchpad username
[01:12] <markh> (ie, I expect that the cvs import process doesn't use the repo at all - it just uses whatever cvs checkout/export does on the platform - subtle but important difference)
[01:13] <snova> can anybody help?
[01:13] <bob2> snova: pastebin the error
[01:13] <markh> snova: if you give us a clue *what* error, we might :)
[01:13] <snova> where?
[01:13] <bob2> paste.pocoo.org
[01:14] <snova> it's a paltry two lines, going there now...
[01:15] <snova> here: http://paste.pocoo.org/show/87187/
[01:16] <snova> oddly enough, i can still push/checkout branches under my username (like ~snova/+junk/test)
[01:17] <markh> it looks a little like curl-ca-bundle.crt can be found by pycurl
[01:17] <markh> can't
[01:18] <snova> i thought it had something to do with certificates
[01:18] <markh> IIUC, that .crt file is full of certificates
[01:19] <snova> might it be possible to download launchpad's certificate manually?
[01:20] <markh> I think that file contains some top-level trusted issuers, which allows a whole lot of sites automatically
[01:20] <markh> try executing with '-v', then looking in .bzr.log.  IIUC, there should be some messages about that .crt missing if that is the problem.
[01:20] <markh> (probably even without -v - I'm not sure)
[01:21] <snova> it doesn't look very useful. just the same error and a traceback
[01:22] <fullermd> You could work around it by shutting off pycurl momentarily.
[01:22] <snova> how?
[01:22] <snova> i found a file on my system that might be useful: /usr/share/apps/kssl/ca-bundle.crt, which appears to contain a bunch of certificates
[01:22] <fullermd> I'd do it just by chmod'ing away the pycurl module while doing it...
[01:23] <fullermd> Hacky, to be sure.
[01:23] <snova> i've done worse
[01:24] <snova> what will bazaar do without pycurl? fall back to something else?
[01:24] <fullermd> Yeah, it'll use urllib, which doesn't do cert validation (and thus won't fail from not knowing the CA)
[01:24] <snova> i guess i'll find out -- oh, it worked now.
[01:25] <snova> i'll try putting it back and seeing what happens -- how might i test it?
[01:25] <fullermd> Normal operations you can force one or the other with URL decoration, but since you don't directly type the URL for lp-login...
[01:26] <snova> i tried lp-login again (without arguments) and i got the same error. the configuration file is correct now, though.
[01:26] <snova> i could just remove python-pycurl, nothing depends on it except a package i can get rid of anyway
[01:27] <snova> i don't even know why i have it (the extra package, that is)
[01:29] <snova> thanks everybody, removing the python-pycurl package worked
[01:29] <snova> goodbye
[02:17] <chandlerc> jelmer: any news on my segfault bug? its really blocking me currently
[02:17] <kiko__> chandlerc: what are you getting a segv on?
[02:17] <chandlerc> bzr-svn
[02:18] <kiko__> chandlerc: crashing inside an extension?
[02:18] <chandlerc> kiko: bug #276219
[02:18] <chandlerc> its extra weird, the python wrapper is pulling a null pointer out instead of a valid C-string
[03:12] <jelmer> chandlerc: just repleid
[03:12] <jelmer> *replied
[03:21] <markh> I guess it would be interesting to know if path starts out as the "impossible" value of NULL, or something in the frames called by that manage to set it.
[03:24] <jelmer> Verterok|out: ping
[06:49] <nbjayme> hello i have a question on the use of sftp.
[06:50] <nbjayme> i have multiple priv keys and i want to use an identify file named launchpad.net.  how do I specify that in bzr push sftp ?
[06:50] <nbjayme> like, i.e. -i <identity file> when using ssh.
[06:51] <bob2> are you using openssh?
[06:53] <nbjayme> i am under ubuntu ... yes i believe it's openssh.
[06:53] <nbjayme> xubuntu (to be more correct).
[06:54] <bob2> http://paste.pocoo.org/show/87195/ -> ~/.ssh/config
[06:55] <nbjayme> thanks!  i'll try that. :)
[07:08] <vila> hi all
[07:09] <nbjayme> hello too. :)
[07:10] <nbjayme> bob2 your config worked. thanks.
[07:10] <bob2> great
[07:10] <nbjayme> i tried uploading my branch but launchpad returned an error that mkdir is not allowed.
[07:11] <nbjayme> i also done the bzr push bzr+ssh  but i am not allowed to create a directory.
[07:12] <nbjayme> so, i cannot create a directory under trunk, noh?
[07:14] <bob2> trunk is a branch?
[07:14] <nbjayme> okay, thanks again bob2.
[07:16] <jml> nbjayme: what's the exact error message that Launchpad gives you?
[07:17] <nbjayme> here is bzr+ssh error:  ERROR: Generic bzr smart protocol error: bad response ("Not allowed to execute '/home/bzrrepo/bin/bzr serve --inet --directory=/ --allow-writes'.\r",)
[07:17] <nbjayme> here is bzr push sftp error:  Permission denied: "/boi-php/trunk/boiChat": [Errno 13] mkdir failed
[07:19] <nbjayme> this project can have multiple modules... boiChat is one.  I was thinking the trunk can accept multiple branch (like a shared repo).... may need to setup my local repo then to meet what's expected by trunk.
[07:30] <jml> nbjayme: branches on Launchpad need to live in ~<username>/<project>/<branch-name>
[07:31] <jml> nbjayme: if you aren't pushing to something that looks like lp:~foo/bar/baz (or bzr+ssh://bazaar.launchpad.net/~foo/bar/baz), then it's not going to work.
[07:31] <nbjayme> jml, thanks.... i was able to commit using ~<username>.  will people that want to download the branch need to place ~<username>?
[07:32] <jml> nbjayme: they'll need to use whatever username you used.
[07:32] <nbjayme> okay. thanks much. :)
[07:32] <jml> nbjayme: if you are the maintainer of that project, you can register that branch as the development focus
[07:32] <jml> nbjayme: or as the branch for a release series
[07:32] <jml> so then people can do: bzr branch lp:<project-name>
[07:34] <nbjayme> jml... it's still all new to me though, sorry for newbie questions.  you mean I need to specify that by clicking "link the branch to this series"?  then they can do lp:<project-name>?
[07:34] <jml> nbjayme: yes, if that series is the 'development focus' (i.e. trunk)
[07:35] <nbjayme> thanks!  :-)  i've done it.
[07:35] <jml> nbjayme: since most people will probably want to fetch trunk, this is Launchpad's way of making it more convenient.
[07:35] <jml> nbjayme: it's one of my favourite features :)
[07:41] <nbjayme> thanks so much.... will upload additional projects in the coming weeks. :-)
[10:12] <vila> jml: sorry to bother you, but can you ping mthaddon about pqm being blocked
[10:12] <vila> jml: by the way, did I thank enough for showing me iswitch ?
[10:16] <james_w> hey vila
[10:16] <james_w> iswitch?
[10:18] <vila> james_w: iswitch is an emacs dwimmy package to change buffers, really handy
[10:18] <james_w> ah
[11:09] <vila> jfroy: ping
[12:09] <Odd_Bloke> I have someone who wants to use bzr-svn on a Subversion working directory and be able to communicate commits to the server once he has access to it again.  Can this work?  If so, how?
[12:50] <intellectronica> hya. i'm giving LP-hosted stacked branches a try. everything works fine, but i'm having problems when trying to submit to PQM
[12:53] <Odd_Bloke> intellectronica: That _probably_ means that the bzr that PQM is using doesn't have a bzr that understands stacked branches.
[12:54] <intellectronica> Odd_Bloke: i don't think that this is a problem with the PQM. i get the same problem when trying to branch back from the branch i pushed. i get 'Permission denied (publickey)'
[12:55] <james_w> intellectronica: when you created the stacked branch did you use lp:whatever as the "stacked-on" url? Or did you use http://bazaar.lp.net/... ?
[12:55] <intellectronica> james_w: i used lp:
[12:56] <Odd_Bloke> intellectronica: "lp:" will probably have resolved to your bzr+ssh:// URL, which won't work for PQM.
[12:56] <james_w> intellectronica: what I think has happened is that is translated to a bzr+ssh://intellectronica@ URI, which no-one else can access
[12:58] <intellectronica> james_w: still, the push went fine, and LP shows me that it's there
[12:58] <james_w> push from you may be ok, as you have access to both branches
[12:59] <Odd_Bloke> intellectronica: Have you tried a pull from the http location of the branch?
[12:59] <james_w> creating the stacked branch with http://... as the stacked-on URI may be worth a try
[13:02] <intellectronica> so, problem solved. turns out i needed to specify my lp username in the URLs used in locations.conf (since it is different from my local username, which ssh would have used by default)
[13:03] <intellectronica> bzr+ssh works fine after that, b.t.w
[13:03] <Odd_Bloke> intellectronica: It might not for other people, FWIW.
[13:03] <kiko> intellectronica, I find it interesting that launchpad-login doesn't fix that under the covers.
[13:04] <kiko> intellectronica, I think it's worth reporting a bzr bug with lots of details and the workaround. I'll talk to martin about it
[13:04] <intellectronica> kiko: indeed. it obviously does the right thing when i try to push, just not when i try to read
[13:04] <kiko> exactly
[13:31] <kiko> intellectronica, did you file the bug?
[13:32] <intellectronica> kiko: not yet. will do shortly, though
[13:32] <kiko> cool, I want to use it in a reply to salgado
[13:37] <intellectronica> kiko: https://bugs.launchpad.net/launchpad-bazaar/+bug/279037
[15:01] <jelmer> Odd_Bloke, hi
[15:06] <Odd_Bloke> jelmer: Ho.
[15:06] <jelmer> Odd_Bloke, What would be blocking me from using PQM with a git repo?
[15:07] <Odd_Bloke> jelmer: I don't know, TBH.
[15:07] <jelmer> Odd_Bloke, but on the PQM side of things?
[15:09] <Odd_Bloke> jelmer: Not sure, I'll look into it in a while.
[15:12] <Odd_Bloke> jelmer: If you look at Bazaar2Handler in pqm/__init__.py in the PQM source, that's all that is needed.
[15:16] <jelmer> Odd_Bloke, ah, ok, that doesn't look too bad
[15:16] <jelmer> Odd_Bloke, it looks like some of your branches are not yet merged - is that correct?
[15:17] <Odd_Bloke> jelmer: http://bzr.daniel-watkins.co.uk/pqm/dependencies.png are the branches waiting to be merged. :p
[15:17] <jelmer> Odd_Bloke, wow..
[15:17] <jelmer> Odd_Bloke, is there an integration branch that contains all of them?
[15:19] <Odd_Bloke> jelmer: Not yet, that's on my TODO list.
[16:39] <Odd_Bloke> I'm getting "bzr: ERROR: exceptions.ImportError: cannot import name bisect_right" with a traceback whenever I try to run bzr.dev.  Any thoughts on what might be causing this?
[16:40] <Odd_Bloke> Happens even with '--no-plugins'.
[16:40] <nevans> I just used the rebase plugin (because rebase-push is the only bzr-svn workflow that puts all changesets into the svn-repo)... but it didn't rebase the first changeset.
[16:40] <nevans> got a bunch of conflicts, but I resolved them rather than notice what had happened.
[16:41] <nevans> so I can't run rebase-abort anymore
[16:41] <nevans> is there an easy way to find the previous branch head (prior to rebasing), and get back to it?
[16:41] <jelmer> nevans: "bzr heads" should give you a ist of heads
[16:42] <nevans> jelmer, thanks.  running that now.
[16:42] <nevans> jelmer: any idea why rebase might have missed a changeset?
[16:43] <jelmer> nevans, what do you mean by first changeset exactly?
[16:43] <nevans> running rebase 0.4.1 and bzr 1.7.1
[16:43] <Odd_Bloke> Oh, epic fail.  I have a directory called 'bisect' in the directory I was running from, which happens to be a Python module. >.<
[16:43] <nevans> I had three changesets in my branch that weren't in the parent... after the rebase, only two of them were rebased on top of the parent
[16:43] <jelmer> Nephyrin, was one of them a merge revision perhaps?
[16:44] <nevans> all of new/modified files in that first commit were lost
[16:44] <nevans> jelmer, yeah, it was.
[16:44] <jelmer> nevans, rebase skips merges by default
[16:44] <nevans> ahhh
[16:44] <jelmer> nevans, you can force it to rebase merges by using --always-rebase-merges
[16:45] <nevans> yeah... I think I'll need to use that.  :)
[16:45] <jelmer> rebasing a merge will potentially cause a lot of conflicts though
[16:45] <nevans> I was merging from a third branch into a branch based off of svn-trunk
[16:45] <nevans> then rebasing that branch against svn-trunk
[16:45] <jelmer> Btw, rebase is not the only workflow anymore these days that makes all revisions end up in svn
[16:45] <nevans> oh?
[16:46] <nevans> cool... because using rebase just feels a bit weird.  :)
[16:46] <jelmer> you can set push_merged_revisions = True; that'll push revisions that were merged in branches/FOO
[16:46] <nevans> interesting.
[16:46] <nevans> I'll play around with that.
[16:46] <nevans> thanks!
[16:52] <nevans> jelmer: any news on #248289?
[16:52] <nevans> that ticket is why I originally switched to the rebase-push workflow...
[16:53] <nevans> https://bugs.launchpad.net/bzr-svn/+bug/248289 (concurrent access problems)
[16:54] <jelmer> nevans, no, that requires changes in bzrlib
[16:57] <mdmkolbe> Help! bzr complains that it can't aquite lock "(remote lock)".  I think it broke when the network died durring a commit.  How do I fix it?
[16:58] <jelmer> mdmkolbe: bzr break-lock <url>
[16:59] <mdmkolbe> jelmer: thanks, that fixed it.  Yea!
[18:28] <clemente> Hi, I'm just trying to continue the patch I did on another computer. And I try on a branch of lp:bzr :  bzr pull  "http://bundlebuggy.aaronbentley.com/download_patch/%3C87abdj9e18.fsf@yahoo.com%3E"
[18:28] <clemente> And I get: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[18:29] <clemente> How could they diverge?
[18:29] <clemente> And I don't want to merge, only to pull
[18:31] <james_w> clemente: if lp:bzr has moved on in the meantime they will be diverged
[18:31] <james_w> clemente: if you don't have any local commits on top of lp:bzr then "bzr pull --overwrite" will do what you want
[18:32] <jelmer> hmm, somebody needs to give pqm a kick
[18:32] <clemente> james_w: ok, with --overwrite it is applied (because the still applied cleanly). That's what I needed; thanks
[18:35] <clemente> If a patch can apply cleanly (with no conflicts), shouldn't pull really pull it even if the branches diverged? (I think there was some discussion about that)
[18:36] <fullermd> Pull doesn't apply patches.
[18:36] <fullermd> Pull syncs _branches_.  You can't sync to something that's not a superset of you without losing data.
[18:36] <fullermd> Hence, requiring forcing.
[18:40] <clemente> fullermd: I understand that a bit, but I think an unexperienced new user can see this as a limitation
[18:40] <clemente> because... sometimes you can sync without losing data
[18:40] <clemente> It is like applying a patch and then commiting afterwards
[18:41] <fullermd> But then your branch isn't synced.
[18:41] <clemente> If the remote changes are different to the local changes, a clean merge is possible
[18:41] <fullermd> pull makes it so that the branches are the _same_, not the files.  If 'log' doesn't show EXACTLY the same thing on both sides, the branches are different.
[18:41] <fullermd> If you want to merge, then you use merge.
[18:43] <fullermd> In git, they're not so distinguished; you have merge which fast-forwards (pulls) if it can, or falls back to merging if it can't.
[18:43] <fullermd> But they're distinct actions, which is why bzr makes them different commands.
[18:44] <clemente> fullermd: yes, git confused things for me still more
[18:44] <fullermd> pull means "update my _mirror_ of that other branch".  merge means "bring in the _changes_ from that other branch".
[18:45] <clemente> But --speaking as a user who looks at the interface-- merge joined my branch with the trunk; what I was looking for is to _bring the changes_ but without joining the two branches
[18:45] <clemente> Now I know that it's bzr pull --overwrite
[18:46] <luks> not really, pull --overwrite will get rid of your local revisions
[18:47] <clemente> And how can bzr otherwise bring the changes without joining the branches?
[18:48] <clemente> Well, for the patches it would be „bzr patch“.... but for the new _revisions_?
[18:48] <luks> if you care only about changes, not the original revisions there is bzr-rebase
[18:48] <luks> if you care about the revisions, there is no way
[18:50] <luks> pull --overwrite is something you want to use _only_ if you want a mirror of the pulled branch
[18:50] <clemente> I wanted to do this only so that Bundle Buggy could detect that I superseded my own patch (written in another computer). I assume this objective will be difficult...
[18:51] <luks> if you have two diverged merge requests (branches), and want BB to recognize one of them as superseeded, you need to merge
[18:51] <luks> or pull the other branch before committing to the new branch
[18:53] <clemente> luks: you mean pull --overwrite from the patch, right?
[18:53] <clemente> The two branches (on each computer) are disconnected
[18:55] <luks> clemente: the patch represents the branch
[19:03] <clemente> Thanks, that was very useful
[19:03] <clemente> I have a hard time trying to correlate bzr commands/plugins (for instance, rebase) with the actions they do in fact to the revision graph shown by „bzr vis“
[19:04] <clemente> I would like a „bzr vis“ where you could edit/drag/cut/copy/... nodes :-)
[19:06] <mathiaz> james_w: Hi - I'd like to get your input on using bzr branches for packaging. Here is the situation - the dovecot packaging branch in debian is in svn.
[19:06] <mathiaz> james_w: here: svn://svn.debian.org/svn/collab-maint/deb-maint/dovecot/branches/1.1-work/debian
[19:07] <mathiaz> james_w: I'd like to create an ubuntu branch that has the structure ubuntu/debian/
[19:07] <fullermd> clemente: There are few manipulations of nodes that you can do, without replacing the nodes.
[19:07] <mathiaz> james_w: the problem is that the debian svn repository has just the files in debian/ - it doesn't have a sub-directory debian/ with the files in it.
[19:08] <clemente> fullermd: if you start from the top, this doesn't affect the older nodes (below)
[19:09] <fullermd> clemente: rebase is for doing those sort of changes
[19:09] <mathiaz> james_w: so how can I structure an ubuntu/ directory that would have a debian/ branch in it ?
[19:09] <clemente> fullermd: For instance, what I wanted was just to „cut“ the wire which connected my branch with the trunk branch...
[19:09] <clemente> fullermd: ok, I should learn it
[19:10] <fullermd> Well, there aren't any "wires" per se connecting branches.  The important thing is the revision graph.
[19:10] <fullermd> Essentially, you can add nodes into the top of it; pretty much any other action is destructive to one degree or another.
[19:11] <clemente> ok, I wanted to cut the „edge“ which connected the latest revision nodes of each branch (mine, and trunk)
[19:12] <clemente> There are many operations on the top nodes which could be represented graphically and through drag & drop
[19:13] <fullermd> Well, you can represent a lot graphically.  You're more limited in what you can do within the constraints of the bzr revision graph   :p
[19:13] <fullermd> You can't create a new node "underneath" an existing one, for instance.
[19:15] <clemente> That would replace all the upper nodes
[19:15] <fullermd> Right.  You'd have to create a whole new set of all the nodes after that point.
[19:16] <fullermd> Which means that everybody else's copy of the branch would now be incorrect, and need to be force-sync'd.  Any work they'd done on top of those old revisions would have to be recreated or it couldn't be merged or kept up to date.  etc.
[19:16] <fullermd> (which isn't to say it's necessarily or always a Bad Idea; just that it has reprecussions, so it needs to be done deliberately)
[19:18] <james_w> hey mathiaz, "bzr join" can do that I think
[19:18] <james_w> mathiaz: I've never used it though
[19:22] <clemente> fullermd: I suppose this graphical revision editor would be too ambitious to be placed in the bug tracker as a RFE... :-)
[19:23] <fullermd> Well, in thse sense that rather open-ended wishlist items don't fit the bugtracker well...
[19:24] <fullermd> It could be a handy thing to have around.  Probably more "useful" to define a full rewriting engine and language, then write a GUI frontend for it.
[19:24] <fullermd> I've mentally fiddled with a language from time to time for it.
[19:24] <fullermd> It's definitely something that's needed.
[19:24] <mathiaz> james_w: hm - it kind of works. I think I was looking for something similar to svn externals definition.
[19:25] <clemente> That's very interesting. The revision specification has already many ways to locate revisions, but --I think-- not to manipulate them
[19:25] <mathiaz> james_w: the problem is that I cannot add the files in debian/ to the ubuntu branch.
[19:26] <mathiaz> james_w: I've joined to the debian/ branch with the --reference option.
[19:27] <fullermd> Yeah, that's what revspecs are for; ways of specifying revisions   :)
[19:27] <james_w> mathiaz: yeah, --reference is more like svn:externals, but it's experimental, so I would recommend it if this is more than an experiment.
[19:27] <james_w> mathiaz: I hope it becomes supported soon.
[19:27] <fullermd> A good general mechanism for rewriting history is certainly necessary.  But it's also necessarily an extraordinary action.
[19:28] <mathiaz> james_w: right - I'm working on the dovecot package for now.
[19:29] <mathiaz> james_w: whenever I touch a package that is maintained in svn in debian I look into ways to create an ubuntu branch in bzr.
[19:29] <mathiaz> james_w: while still making it easy to forward patches to debian/.
[19:30] <mathiaz> james_w: in this case it's a bit tricky as it's a package in experimental that doesn't use a pkg-name/debian/ structure.
[19:31] <mathiaz> james_w: I'd like to end up with an ubuntu branch I could use bzr bd with.
[19:31] <james_w> mathiaz: I'm glad you are trying these things. It's a shame I often don't have a good answer for you.
[19:31] <mathiaz> james_w: but I don't see how I can connect the debian branch with ubuntu/debian/
[19:32] <mathiaz> james_w: ok - thanks for the help. I'll play with this a little bit more.
[19:32] <james_w> there's the merge-into plugin, which is similar to "bzr join" without --reference, but I don't know if it will have a benefit over "bzr join" for your case.
[19:32] <james_w> mathiaz: I'm interested by "the problem is that I cannot add the files in debian/ to the ubuntu branch." Could you expand?
[19:36] <mathiaz> james_w: http://paste.ubuntu.com/54737/
[19:37] <mathiaz> james_w: and that's when I try to join the subtree: http://paste.ubuntu.com/54738/
[19:39] <james_w> mathiaz: can you try "bzr join" without --reference please?
[19:39] <james_w> mathiaz: I believe it still allows you to "bzr pull" later
[19:42] <mathiaz> james_w: http://paste.ubuntu.com/54740/
[19:42] <mathiaz> james_w: well - what I'd like to be able to do is also bzr diff in debian/
[19:42] <mathiaz> james_w: and get the diff with the debian svn branch
[19:43] <james_w> mathiaz: hmm, yeah, I guess that "bzr diff -r branch:svn://..." might work, but I don't really know
[19:44] <james_w> mathiaz: that looks sensible
[19:44] <mathiaz> james_w: hm - bzr diff --old seems to almost work
[19:44] <james_w> mathiaz: confusing but sensible
[19:48] <mathiaz> james_w: hm - bzr  merge doesn't work once I've joined the debian branch.
[19:48] <james_w> mathiaz: are you in ./debian?
[19:49] <mathiaz> james_w: yes - it fails with an error about Key 'new-2' not found
[19:49] <mathiaz> james_w: http://paste.ubuntu.com/54741/
[19:49] <james_w> mathiaz: I would guess it's a bug then
[19:49] <james_w> mathiaz: rather than not being supposed to work
[19:50] <james_w> mathiaz: sorry about that, it looks like you can't really do what you want currently
[19:50] <mathiaz> james_w: oh well - this not the end of the world. I'll survive :D
[19:51] <james_w> you always do :-)
[19:57] <clemente> What format does tree.set_parent_ids([....]) expect?
[19:57] <clemente> Is that the „revision graph“?
[19:58] <james_w> clemente: a list of revision ids
[19:58] <james_w> which are strings
[19:59] <clemente> and what relation is there between the elements of that list?
[19:59] <clemente> Is that function declaring that each left-most is parent of the right-most ?
[20:01] <james_w> the left-most is the first item in the list
[20:01] <james_w> the right-most is the last item
[20:02] <clemente> And each revision is the parent of the revision right to it
[20:03] <clemente> So ["a","b","c"] is a tree with 3 revisions, right? The first one (in time) was "a", then came "b", then came "c"
[20:06] <james_w> no, it's just about the parents of the working tree
[20:06] <james_w> [] is the tree before any commits
[20:06] <james_w> ["x"] is a normal tree
[20:06] <james_w> ["x", "y", ...] is a tree with pending merges
[20:08] <clemente> ouch! I thought that all parents were listed there. So that's why it's more normal to list just one revision there. Thanks
[20:09] <clemente> Only parents of the working tree. Not the parents of those parents, etc.
[20:10] <james_w> yup
[20:11] <clemente> A tree has a revision as its parent. And which parent has that revision?
[20:11] <clemente> Does it matter for tree.set_parent_ids()?
[20:12] <james_w> it doesn't matter
[20:12] <james_w> the parent(s) are stored as part of the revision
[20:12] <james_w> or rather the revision tree, which is referenced by the revision, I think
[20:14] <clemente> I always think that I must describe the whole revision graph, from [] to any revision
[20:15] <james_w> that only really happens in tests I think
[20:42] <clemente> I'm seeing this on a test I'm writing: bzrlib.tests.branch_implementations.test_sprout.TestSprout.test_sprout_with_utf8_symlink(RemoteBranchFormat-default) is leaking threads among 2 leaking tests
[20:42] <clemente> The tests are failing and I throw KnownFailure
[20:42] <clemente> Is something wrong?
[20:43] <clemente> Ran 7 tests in 0.661s.  OK (known_failures=5).  The other 2 „leak threads“...?
[20:48] <james_w> that's not necessarily your test
[20:48] <james_w> if you comment out your test do they go away?
[20:48] <james_w> I'm not even sure whether it's deterministic
[20:50] <clemente> It's my test. „I'm leaking threads“ if I do just „tree = self.make_branch_and_tree('tree1')“ but not if I do „print "a"“
[20:51] <clemente> Mmm... not only my test. Others do it too:  ./bzr selftest test_sprout_from_any_repo_revision
[20:52] <clemente> bzrlib.tests.branch_implementations.test_sprout.TestSprout.test_sprout_from_any_repo_revision(RemoteBranchFormat-default) is leaking threads among 2 leaking tests
[20:53] <stefanlsd> Does anyone know why this doesnt work - bzr branch lp:~ubuntu-dev/mplayer/ubuntu     -  It just hangs and doesnt download anything... - would it be a bzr thing with big repo's?
[20:55] <clemente> stefanlsd: works here. Try pressing ENTER several times (>4). Maybe you are also experiencing bug 246052
[20:57] <james_w> clemente: hmm, self.make_branch_and_tree shouldn't leak threads, if it is, it's not your fault
[20:58] <clemente> stefanlsd: in any case, to see what the bzr process is doing, you can attach to it with: strace -p pid_of_the_bazaar_process
[21:00] <stefanlsd> clemente: thanks. thats useful - repeating this over and over http://pastebin.ubuntu.com/54761/
[21:02] <clemente> stefanlsd: the send() and recv() show that it's downloading things from the net
[21:02] <clemente> send("GET /") is requesting
[21:02] <clemente> So it is just slow...
[21:03] <stefanlsd> ok... heh. slow
[21:03] <clemente> So that you can enjoy Bazaar longer :-)
[21:03] <clemente> Bazaar could show more information during that time (or something else to read); maybe you can find or file a bug report about that
[21:04] <stefanlsd> joys of being in south africa :)
[21:15] <clemente> Ok, I wrote my second patch much faster than the first one; thank you for helping beginners to learn Bazaar :-)
[21:16] <james_w> mathiaz: I just came across bug 203376, which I think is what you are hitting. It's fixed in 1.7, which unfortunately isn't in Intrepid
[21:16] <clemente> stefanlsd: by the way, the „branch“ command I started when you said that, has finished right now successfully on my machine. 108 Mb
[21:17] <mathiaz> james_w: ok. It turns out that I missunderstood the branch structure. The branch actually follows the pkg-name/debian/ structure :D
[21:17] <james_w> heh
[21:18] <mathiaz> james_w: so I've setup a merge mode for bzr builddeb.
[21:18] <mathiaz> james_w: it's just that the svn branch has two other directories in addition to the debian directory.
[21:18] <stefanlsd> clemente: aah. ouch.  mm.  is it possible for me to branch ignoring all previous changes history etc?   just want the latest so i can merge a 5 line patch into...
[21:18] <mathiaz> james_w: that confused me.
[21:18] <stefanlsd> clemente: i'm on 8mb so far :)
[21:19] <james_w> ah, at least it works
[21:19] <mathiaz> james_w: so now I've co the debian svn tree, and branched it to an ubuntu/ branch.
[21:20] <mathiaz> james_w: I've setup merge mode for builddeb and added the configuration to the bzr branch.
[21:20] <clemente> stefanlsd: mmm... from memory, I think there are „lightweight checkouts“ to check out just the latest things, and „stacked branches“ to have a part here and another remote (I think, please correct if needed)
[21:20] <mathiaz> james_w: now I have to import the ubuntu changes.
[21:20] <mathiaz> james_w: any suggestions ?
[21:21] <james_w> does ubuntu touch anything outside of ./debian/ ?
[21:21] <mathiaz> james_w: let me check that
[21:22] <clemente> clemente: probably with „stacked branches“ you could do that. Although I never used them
[21:22] <clemente> clemente: stop talking to yourself!
[21:22] <james_w> mathiaz: it's not easy though
[21:23] <james_w> mathiaz: I don't think I can offer you more that diff+patch or equivalent currently
[21:23] <clemente> stefanlsd: see ./bzr help branch   on bzr >=1.6 for --stacked
[21:23] <mathiaz> james_w: right - I may try to use loom again
[21:23] <stefanlsd> clemente: yeah. reading about stacked right now. sounds interesting...
[21:29] <jelmer> chandlerc: ping
[21:29] <clemente> After „bzr selftest“:  Ran 14132 tests in 956.732s.  FAILED (failures=37, errors=43, known_failure_count=27)
[21:29] <clemente> Is this the normal state? I mean failures!=0
[21:30] <james_w> no, shouldn't be
[21:30] <james_w> if the "./bzr" you said a moment ago means you are on linux at least
[21:30] <james_w> windows may have that, I'm not sure
[21:30] <clemente> yes I am
[21:31] <james_w> yeah, should be 0 failures
[21:31] <james_w> PQM tries to ensure that
[21:31] <clemente> Most of them are like:
[21:31] <james_w> platform differences etc. can mean that it's not always 0 on your machine
[21:31] <clemente>     self.run_bzr('patch --silent mypatch')
[21:31] <clemente> AssertionError: Unexpected return code
[21:31] <clemente> not equal:
[21:31] <clemente> a = 0
[21:31] <clemente> b = 3
[21:31] <james_w> ah, you might like to run the tests with --no-plugins
[21:32] <james_w> assuming that you aren't testing a plugin
[21:32] <clemente> Aren't plugins required to pass tests?
[21:32] <james_w> shouldn't be
[21:33] <james_w> it won't load the tests of the plugins either
[21:33] <james_w> and nothing in bzr core should rely on a plugin being present
[21:33] <clemente> I only had 2: bzr_push_and_update  bzr_rebase
[21:39] <jelmer> clemente, patch is in bzrtools
[21:40] <clemente> jelmer: mmm... do I have bzrtools installed? :-)
[21:40] <clemente> I think not
[21:40] <clemente> Does it mean that if I add it to my Bazaar, the bug will disappear?
[21:41] <jelmer> clemente, It appears like you have bzrtools installed
[21:41] <jelmer> clemente, does "bzr plugins" list  bzrtools?
[21:41] <clemente> jelmer: yes... But I don't know where did it find it
[21:42] <clemente> Not in ~/.bazaar/plugins
[21:42] <jelmer> clemente, in the system folkder perhaps?
[21:43] <clemente> probably. I thought that if I ran bzr like ./bzr, the system folder wouldn't be read
[21:43]  * clemente has bzrtools in /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools
[21:46] <stefanlsd> is there a suggested ppa for 1.7?
[21:49] <clemente> Ran 13889 tests in 954.235s. OK (known_failures=27). 862 tests skipped   <== with --no-plugins. Runs as expected
[21:49] <clemente> what's a PPA? :-)
[21:50] <james_w> stefanlsd: the ~bzr one I expect
[21:50] <clemente> Ok, Personal Package Archive
[21:50] <clemente> Only for Debian?
[21:50] <stefanlsd> mmm. looks like..  https://edge.launchpad.net/~bzr/+archive
[21:51] <clemente> and Ubuntu, etc?
[21:54] <james_w> clemente: just for Ubuntu currently
[22:51] <jelmer> lifeless, 'morning
[22:51] <lifeless> hi jelmer, how are you?
[22:51] <jelmer> lifeless, Good, thanks
[22:52] <jelmer> just got "bzr svn-serve" working
[22:52] <lifeless> schweet
[23:09] <james_w> hey lifeless, have you had a chance to review my config-manager patch?