[00:01] <SamB> it might be a good idea to also list whoever called the first of those guys to get called
[00:06] <SamB> oh, interesting
[00:06] <SamB> "bzr info -v" crashes on this branch
[00:06] <SamB> Branch history:
[00:06] <SamB>      14741 revisions
[00:06] <SamB> bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///home/naesten/hacking/launchpad/.bzr/repository/') has no revision launchpad@pqm.canonical.com-20120201152332-0i5ysxdk0ouw6jc2
[00:07] <jelmer> SamB: it's an interrupted clone?
[00:07] <SamB> yeah
[00:08] <jelmer> SamB: that's a bug fixed in 2.5, we shouldn't be setting the branch data unless the revision data is actually present
[00:08] <jelmer> so, it seems the odd thing wrt your traceback is that it's using vf_search.NotInOtherForRevs
[00:09] <SamB> bzr branch lp:launchpad; (hit ^C); bzr branch lp:launchpad; (this time it completes right away setting the branch data); cd launchpad; bzr pull
[00:09] <jelmer> and that doesn't have a get_recipe thing it can send over the wire
[00:09] <jelmer> SamB: yes, that's fixed in 2.5
[00:09] <SamB> where is this "2.5" ?
[00:10] <SamB> I'm on b5
[00:10] <jelmer> SamB: lp:bzr/2.5
[00:11] <SamB> so, you mean it was fixed since 2.5b5?
[00:11] <jelmer> yes
[00:11] <jelmer> I THINK
[00:11] <SamB> oh
[00:11] <jelmer> sorry about the caps
[00:12] <SamB> no problem
[00:16]  * SamB runs "sudo apt-get install bzr/unstable"
[00:16] <SamB> hmm
[00:16] <SamB> apt-get complains
[00:29]  * SamB uses aptitude instead
[00:29] <jelmer> SamB: unstable doesn't have the right version yet I think
[00:30] <SamB> oh. what should I be installing, then ?
[00:31] <jelmer> SamDB: either way, the bug is just that it allows creating a branch without fetching the relevant data in an empty repository
[00:31] <SamB> oh, actually, it's not doing that anymore afaict
[00:31] <jelmer> SamB: a workaround is just to "bzr init foo && bzr pull lp:launchpad"
[00:32] <SamB> so I guess "bzr 2.5.0~bzr6458-2" was good enough
[00:33] <jelmer> ah, ok :)
[00:35] <SamB> (apt-get is apparantly not smart enough to think of pulling python-bzrlib{,.tests} from unstable too
[00:36] <SamB> though, in all fairness, aptitude isn't smart enough to figure out that that would be a better plan than just not doing what I wanted, either
[00:37] <SamB> or better than deleting bzr, python-bzrlib, and everything that depend on them
[00:38] <SamB> why it thinks "delete the only thing asked for" or "leave the only thing asked for alone" are good plans, nobody seems to know
[00:39] <jelmer> :)
[00:41]  * jelmer -> sleep
[02:48] <Stavros> hello
[02:49] <Stavros> i have two branches in different directories, A and B. whenever i commit something to B and try to pull it to A, bzr tells me they have diverged and need a merge. i merge, and the next time i need to pull from B, it needs a merge again. why can't it see it's fast-forwardable?
[02:50] <Stavros> here, i just merged B to A, and trying to pull from B to A needs another merge
[02:50] <Stavros> i don't think this should be happening
[03:12] <spiv> If Stavros comes back, someone should suggest "bzr missing" to them to diagnose their situation.
[07:30] <vila> hi all !
[07:32] <rcsheets> hello vila
[07:33] <wgz> morning vila.
[07:33] <vila> rcsheets: please to meet you (not sure I recognize the nick though ;)
[07:33] <vila> heya wgz
[07:34] <vila> wgz: did you land evrything you wanted on 2.5 ?
[07:34] <rcsheets> vila: i mostly lurk :)
[07:35] <vila> good, we also welcome lurkers
[07:42] <wgz> bus time
[07:42] <wgz> vila: not yet
[07:42] <vila> wgz: k, ping me when you're done
[07:42] <vila> wgz: or better, let's chat quickly when you come out of the bus
[08:24] <mgz> morning all!
[08:41] <mgz> vila: so, my issue is I still need to change some apis, but am having trouble deciding on how exactly to do it
[08:41] <mgz> and that's the kind of thing that should really be in the last beta
[08:45] <mgz> it should all be pretty safe, private functions, some extra args, and otherwise compatible
[08:57] <rcsheets> good morning
[08:57] <mgz> I am wondering from your nick rcsheets, why you need to revision control your bedding.
[08:58] <rcsheets> it's... a complex and embarrassing story
[08:58] <mgz> :)
[09:18] <vila> mgz: change APIs around unicode issues ?
[09:19] <mgz> vila: I need to alter two things particularly
[09:19] <mgz> how trace exception reporting functions pass error information around
[09:20] <mgz> and some details of exception instances
[09:21] <mgz> I have a generic fix for BzrError I've been sitting on that involves wrapping it for _format, but it'll actually be a safer change to modify each class
[09:21] <vila> you know about bt.test_trace right ?
[09:23] <mgz> ...specifically?
[09:24] <vila> I think that's where most of output tests are, checking various functions and combinations of encoding, let me check
[09:24] <mgz> also bt.test_errors
[09:24] <mgz> I can certainly do this without breaking existing testcases
[09:25] <vila> hehe, that's bad :) You should at least add a failing test first ;)
[09:26] <vila> you're fixing at least a bug right ?
[09:27] <vila> hmm, not sure that's the one I was thinking about
[09:27] <mgz> there's also bb.test_non_ascii and things, but that's less useful
[09:27] <mgz> the combinatronics aren't particularly valid in the same process without having an actually different locale
[09:28] <vila> there is a test file where all sort of output are kinf of magically tested (I remember reading a test in a review that made no sense until I read the setup in this test file)
[09:34] <vila> can't find it back :-/ or may be it's not catching my eye as it did
[10:12] <mgz> do we know what's up from the test failures from the bzr-builddeb ppa due to debian_releases() returning None?
[10:14] <mgz> I'm guessing it's related to the package upgrades we've been trying to get through on the builders?
[10:58] <jelmer> mgz: that's already fixed
[10:59] <mgz> ace.
[11:02] <mgz> ah, that's the 'Fix tests' r714 commit.
[11:58] <jelmer> mgz: yeah, that was kindof sloppy of me, only testing without distro_info installed
[12:06] <mgz> gah, I'm going nuts, I just need to start commiting bits
[12:06]  * mgz shelves the world
[13:16] <vila> mgz: yeah and land some :) I'm late for lunch and would like to start freezing 2.5b6 not too long after I come back ;)
[13:18] <jelmer> oh
[13:18]  * jelmer should put up his overwrite-tags MP while he still can
[13:18] <vila> ha :)
[14:07]  * vila back
[14:07] <vila> jelmer, mgz: so what ?
[14:11] <mgz> vila: so, I still need to do some things, but only have the one mp to land atm
[14:11] <mgz> I think I can do some of this with... minimal-ish risk though, so it's not the end of the world if you freeze first
[14:11] <vila> ok, jelmer ?
[14:12] <jelmer> vila: mp on the way
[14:12] <vila> ha cool
[14:30] <jelmer> vila: proposed
[14:35] <vila> jelmer: so the idea is that you can use '--overwrite' or '--overwrite-tags' or both right ?
[14:36] <mgz> hm. `bzr rm .bzr` does something.
[14:36] <mgedmin> ooh! does it do something bad?
[14:36] <jelmer> vila: yeah, though there isn't much point in that
[14:36] <vila> mgz: yeah, I receive an email saying you're naughty
[14:37] <vila> jelmer: in what ?
[14:37] <jelmer> vila: (speciufying both is the same as just specifying --overwrite)
[14:37] <vila> oh
[14:37]  * mgedmin now knows vila is santa!
[14:37] <vila> jelmer: and '--overwrite --no-overwrite-tags' works ?
[14:38] <mgz> jelmer: seems generally okay, but I'm not convinced by the passing around of 'history' and 'tags' strings
[14:38] <jelmer> vila: We could also add --overwrite-history if you wanted to be able to just overwrite history
[14:38] <mgz> do we really want to support lots more kinds of unversioned data?
[14:38] <vila> jelmer: nope, the change looks fine for now, I'm just kicking the tires
[14:39] <rly> How do I express 'do not care anything about local changes, just update it'?
[14:39] <vila> rly: 'bzr revert ; bzr update'
[14:40] <rly> vila: thanks
[14:42] <vila> jelmer: meh, wtf with changes in bzrdir.py  on crontroldir.py ?
[14:42] <vila> urgh, my bad
[14:43] <jelmer> vila: hmm?
[14:43] <vila> nothing, did I mention anything ?
[14:44] <jelmer> :)
[14:44]  * vila should really fix his bzr-review hack to take the targeted branch into account
[14:50] <jelmer> mgz: thoughts on alternatives? Would you rather see another argument be passed around and renaming overwrite to overwrite_history ?
[14:54] <vila> jelmer: Aren't we breaking plugins that redefine push/pull here ?
[14:55] <jelmer> vila: yes
[14:55] <mgz> not having a day of api epiphanies unfortunately
[14:55] <mgz> maybe vila has clever ideas?
[14:56] <vila> mgz: it happens but I'm not sure I understand API epiphanies ;)
[14:57] <vila> jelmer: so having overwrite_tags will break them less no ?
[15:00] <jelmer> vila: no, it will break them more
[15:00] <jelmer> vila: if we pass a tuple, then most of them will just work - they'll just do full overwrites in some cases even if the user requested tag overwriting only
[15:01] <jelmer> if we add a separate parameter then it will definitely break them
[15:02] <vila> hmm
[15:02] <mgz> ideally that bool would flip, and tags would count as not overwriting at all
[15:02] <mgz> but I don't think that's a big deal
[15:04] <rly> Why would anyone want to use bzr over any of the other DVCSs?
[15:04] <mgz> why would anyone want to use any of the other dvcss over bzr?
[15:05] <rly> mgz: for git: performance.
[15:05] <rly> mgz: for Mercurial: better user-interface and I think it is more popular.
[15:05] <jelmer> rly: unless you have a really big tree, I don't think there's a significant difference in performance left
[15:05] <rly> I almost never see a bzr repository.
[15:06] <rly> I think it is at around 2% or so for the repos I care about.
[15:06] <jelmer> rly: I think the Bazaar UI is much better than Mercurial's. Not sure about popularity
[15:06] <rly> E.g. if bzr has zero open bugs, then that would be an advantage.
[15:06] <rly> I think darcs has tons of bugs open, still.
[15:07] <rly> An open bug is something which affects correct operation.
[15:07] <rly> Not some silly feature request.
[15:07] <rly> Speed could affect correctness because of termination problems.
[15:08] <rly> 'it takes until the heat death of the universe before this completes...'
[15:08] <rly> So, that said, where does bzr stand?
[15:10] <rly> https://bugs.launchpad.net/bzr suggests it is unmaintained.
[15:10] <jelmer> rly: why?
[15:11] <jelmer> rly: Mercurial and Bazaar both have open bugs
[15:11] <vila> rly: try https://launchpad.net/bzr/+milestones
[15:11] <jelmer> rly: I think popularity is mostly perspective; I don't come across many mercurial projects anymore these days, most (and quite a few who used Bazaar in the past) have migrated to Git.
[15:27] <vila> jelmer: I don't really know what to do with your --overwrite-tags proposal, this looks like something that needs to mature a bit. As such I'd more inclined to land it in trunk :-/
[15:34] <jelmer> vila: mature in what regard? I think if we're happy with the API change we should just land it - there's another couple of weeks before 2.5.0
[15:35] <vila> plugin breaks, fallouts discovered while using it...
[15:36] <jelmer> vila: plugin breaks should be fine now before we have 2.5.0
[15:36] <jelmer> there were requests from both the emacs people and go users (Gustavo) for this; I'd really like to land this rather than having them wait for another 6 or 7 months
[15:38] <vila> gustavo use case is already covered by --overwrite IIUC, overwriting only tags may be cleaner but if we deprecate the option in the future he won't be happy either
[15:38] <jelmer> vila: he was specifically asking for this
[15:38] <vila> and if we had proper versioning for tags we shouldn't need the option at all
[15:38] <vila> yes, but why ?
[15:39] <jelmer> vila: https://bugs.launchpad.net/bzr/+bug/681792/comments/4
[15:39] <ubot5`> Launchpad bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [High,In progress]
[15:39] <vila> to be able to *not* use --overwrite unconditionnally
[15:39] <vila> I know I re-read it
[15:40] <jelmer> vila: if we had proper versioning for tags we might still wants this option
[15:40] <alucardni> hello, is there a way to make bzr work behind a proxy? Exporting http_proxy, https_proxy doesn't work with bzr 2.5b5
[15:40] <vila> jelmer: why ?
[15:41] <jelmer> vila: because you might want to discard your local tags in favor of the ones on the remote host
[15:43] <jelmer> vila: I don't see why that matters though, if you're happy for this change to land on trunk
[15:43] <vila> I don't think pull and push are the right way to align tags between branches, it *is* today because the interactions are limited
[15:43] <vila> because we can more easily revert/fix it on trunk
[15:44] <vila> rushing features never worked in the past :-(
[15:44] <Mez> Is there a way I can take a subdirectory of a branch, and split it out into it's own branch? (we want to create a new project from a sub-project)
[15:44] <jelmer> vila: I don't think this is really rushing, and it's a really small feature
[15:44] <jelmer> Mez: see "bzr split"
[15:45] <Mez> yeah, just spotted that
[15:45] <jelmer> also, hi :)
[15:45] <Mez> hey :D
[15:46] <vila> jelmer: well, I do :) But if you manage to get approval from mgz instead, I will freeze a bit later (I need to leave for ~1/2 h)
[15:48] <Mez> jelmer: how're nested trees coming along ?
[15:48] <jelmer> vila: we have another full month for the final release, and this change is really simple. What is the worry?
[15:49] <vila> jelmer: that we said roughly the same thing one month ago ? ;)
[15:50] <vila> jelmer: I really need to go (and just get informed that I have *another* appointment* at 6pm so freeze won't be for today :-/),
[15:51] <vila> jelmer: the way you transform 'overwrite' is not public, how will the plugins deal with that ? Overall, there are issues I feel needs to be addressed (gut feeling), size doesn't matter
[15:51] <jelmer> vila: what do you mean with not public?
[15:53] <jelmer> vila: the plugins will need to be updated, but that seems fine as long as we haven't frozen the API (e.g. before the last beta)
[15:56] <jelmer> Mez: slowly :)
[15:56] <jelmer> Mez: but there is some progress, at least
[16:13] <mgz> heh, another dupe of the bug I'm working on now just filed
[16:59] <uniquenick> is bundlebuggy still actively maintained?
[17:00] <alucardni> \wc
[17:03] <jelmer> uniquenick: it's not
[17:04] <uniquenick> do the bzr devs still use it anyways, or something else?
[17:05] <jelmer> uniquenick: we're using Launchpad review system for bzr itself
[17:11] <uniquenick> does launchpad take over for pqm also, or is it still used?
[17:11] <jelmer> uniquenick: we're still using PQM
[17:21] <abentley> jelmer: In fact, I've just submitted a branch for bzr-pqm.  Are you up for a review?
[17:31] <jelmer> abentley: sure
[17:31] <abentley> jelmer: thanks.  https://code.launchpad.net/~abentley/bzr-pqm/fix-lp-land/+merge/91318
[17:41] <mgz> okay, nearly there, cut this down enough to be workable
[18:29] <SamB> hmm
[18:30] <SamB> it would be nice if bzr would save what it's downloaded so far to non-temporary packfiles every so often ...
[18:32]  * SamB expects there's a bug about that
[18:37] <jelmer> SamB: That's not necessarily useful - that would require it to send data in a specific order
[18:37] <SamB> jelmer: hmm?
[18:37] <SamB> oh ...
[18:37] <jelmer> SamB: if it's sending texts first, then having those texts in the repository wouldn't be really useful if you didn't have the rest of the revisions
[18:38] <jelmer> SamB: so you would need to change things so that revisions are sent in toplogical order, and grouped data per revision
[18:38] <SamB> maybe for large clones, multiple packs should be negotiated, then?
[18:39] <jelmer> SamB: why would you need multiple packs?
[18:39] <jelmer> SamB: it seems you're trying to solve a symptome of a problem rather than the problem itself
[18:41] <SamB> could be
[18:41] <SamB> so, what I should be doing is making lp:launchpad smaller, you say?
[18:42] <wgz> resumable branching would be ace
[18:43] <wgz> but nothing has been designed with that in mind unfortunately
[18:43] <SamB> well, I don't see anything to out-and-out prevent the client doing it anyway
[18:43] <jelmer> SamB: why do you need resumable clones? Why is your clone being interrupted in the first place?
[18:44] <SamB> well, okay, so bzr is eating a lot of RAM
[18:44] <jelmer> SamB: the only thing you could do is to have the client request smaller chunks of data rather than a lot of revisions at once. I don't see what that really solves though.
[18:44] <jelmer> SamB: so that seems like solving a symptom (interrupted clones) rather than the actual problem (high memory usage)
[18:45] <SamB> but, there are many ways it *can* happen
[18:45] <SamB> say, power loss
[18:45] <wgz> ...the symptom there sounds easier :)
[18:45] <SamB> and there's that, too
[18:45] <jelmer> wgz: I don't see why we would need all that much memory during clone?
[18:46] <jelmer> SamB: is power loss really common enough to warrant decreasing performance and adding extra roundtrips?
[18:46] <SamB> jelmer: not seeing it is a *lot* easier than making the computer see not it
[18:46] <wgz> people with unreliable and slow connections are common enough
[18:47] <SamB> jelmer: well, it could be an option
[18:47] <wgz> I've never touched the launchpad source because it was basically unbranchable for me when I tried some years back
[18:47] <jelmer> wgz: we already retry in newer versions, so unreliable connections shouldn't be much of an issue anymore
[18:47] <SamB> for those who tend to run out of batteries, lose connectivity, run out of RAM, you name it
[18:47] <SamB> jelmer: doesn't that depend on how long the connection goes out for?
[18:47] <jelmer> SamB: I'd rather see that engineering time be spent on reducing the memory overhead
[18:48] <SamB> jelmer: would be a lot more time, I think
[18:48] <wgz> there's also the fact 2a requires a lot of actual processing client side
[18:48] <jelmer> SamB: I think they're both far from trivial.
[18:49] <wgz> anyway, there are various annoyances, that lp:launchpad has more problems with than most projects
[18:49] <jelmer> wgz: fair enough, but does that have to mean lots of memory use?
[18:49] <jelmer> wgz: yeah - the other thing I think is that lp:launchpad has lots of ghosts, and the we seem to be querying those repeatedly
[18:49] <wgz> jelmer: anything big that compresses well can cause memory issues on unpacking
[18:50]  * SamB wonders if git actually manages to avoid this, or if he has simply not cloned a sufficiently large repository using the smart protocol for him to notice
[18:50] <SamB> (on this system)
[18:51] <jelmer> wgz: launchpad doesn't have really big tests so I'd be surprised if that was really an issue
[18:51] <jelmer> SamB: git doesn't have an abstraction for the formats - there is one and only one format, and that's used directly by the server and client
[18:51] <wgz> yeah, without actually looking at the memory consumption it would be wrong to blame any particular thing
[18:52] <jelmer> SamB: so after the negotation, the server just streams a byte-for-byte pack file that the client can write to disk directly
[18:52] <SamB> jelmer: that's no excuse for us to suck at cloning 2a to 2a over smart server ...
[18:53] <SamB> jelmer: I thought the server used a thin packfile
[18:53] <jelmer> SamB: right, that's what I've been saying all along :)
[18:53] <SamB> which is not a file
[18:53] <jelmer> SamB: a thin packfile is a valid pack file too, it just can contain deltas that have a base that is in a different pack file (that the client already has)
[18:54] <SamB> jelmer: well, yes, I know it's the same format
[18:54] <jelmer> as a client you can negotiate whether you're happy with a thin or a fat pack file
[18:54] <SamB> oh, I missed that
[18:55] <jelmer> (originally pack files were never thin IIUC)
[19:01] <SamB> so ... when bzr reconnects, how does it resume downloading the same pack, anyway?
[19:02] <jelmer> I'm not sure, I think it just re-does the request
[19:04] <SamB> so why couldn't the request be saved along with the partial packfile again ?
[19:05] <LeoNerd> If I rm -rf a branch directory I don't care about any more, it'll still leave the actual revisions in the parent's .bzr directory, yes? (because it's a shared repo)
[19:05] <jelmer> SamB: because you would have incomplete data in the packfile, the order in which pack entries are sent isn't topological or grouped by revision.
[19:05] <LeoNerd> Is there some garbage collection I can do to clean those up? Just want the disk space back really
[19:05] <lifeless> jelmer: original pack files were thin, because they were just vf deltas split temporally rather than fileidly
[19:06] <jelmer> LeoNerd: yes
[19:06] <jelmer> LeoNerd: I think bzr-colo has something, but there's nothing in core that can clean those revision up.
[19:06] <LeoNerd> Ah OK.. Then I won't worry overly for now.. it's not -that- big..
[19:07] <SamB> jelmer: so ... how does the reconnecting thing help people with unreliable net connections?
[19:08] <jelmer> SamB: they don't have to run the command again
[19:08] <SamB> jelmer: that does a lot of good if the transfer keeps getting inturrupted, I suppose?
[19:08] <jelmer> SamB: it will retry a particular HPSS request only once
[19:09] <jelmer> SamB: so if it keeps getting interrupted you still have a problem
[19:09] <jelmer> SamB: but I'm not sure if that's really an issue we should be trying to solve in bzr
[19:11] <SamB> well, it would beat having to sit there and type "bzr pull -r <something>" over and over
[19:11] <jelmer> SamB: so, let's fix the reason why you're keep hitting those memory limits
[19:12] <jelmer> allowing resumes wouldn't be complex *and* would hurt performance even further
[19:12] <jelmer> SamB: Git doesn't have any kind of resuming either - do you miss it there?
[19:12] <SamB> well, somehow no
[19:13] <jelmer> s/wouldn't/would/
[19:13] <SamB> but I'm not sure why I haven't ...
[19:16] <Stavros> hello
[19:16] <jelmer> hi Stavros
[19:16] <Stavros> i copied an entire working tree directory with cp -R master otherbranch and the repos are somehow shared, what trickery is this?
[19:17] <Stavros> i want completely different repos i can push and pull from
[19:17] <jelmer> Stavros: how are they shared?
[19:17] <Stavros> when i commit in one, the commit shows up in the others
[19:17] <jelmer> are they checkouts of the same branch, perhaps?
[19:17] <Stavros> and bzr info on the other repos shows: shared repository: master/.bzr/branches
[19:18] <jelmer> Stavros: you're using bzr-colo ?
[19:18] <Stavros> i have it installed, yes
[19:18] <SamB> lightweight checkouts ?
[19:18] <jelmer> Stavros: it seems this is some sort of bzr-colo thing, I'm familiar with that - sorry
[19:19] <Stavros> hmm
[19:19] <Stavros> can i unshare it?
[19:19] <SamB> jelmer: +not, right?
[19:19] <jelmer> Stavros: euhm, yep, thanks
[19:19] <SamB> Stavros: bzr reconfigure is your friend
[19:19] <SamB> well, I think it is
[19:19] <Stavros> bzr reconfigure --checkout .?
[19:20] <Stavros> ah, standalone
[19:20] <jelmer> stavros: "bzr reconfigure --standalone" I think
[19:20] <jelmer> Stavros: are you using bzr explorer? I wouldn't know how you end up with bzr-colo workspaces otherwise
[19:20] <Stavros> i'm not, but i colo-ified my repo once
[19:20] <Stavros> but it's weird that it knows to share, since i'm doing cp -R
[19:21] <Stavros> apparently this is a lightweight checkout
[19:21] <Stavros> i didn't know you could do that with cp -R
[19:21] <Stavros> bah, now bzr-reconfigure fails with "repo is already standalone" and bzr info says it's a lightweight checkout
[19:22] <Stavros> i branched and moved the .bzr dir to this repo and now it's a standalone repo
[19:23] <Stavros> but i don't understand what's going on otherwise
[19:23] <Stavros> aha, now one of the branches complains there's no repo
[19:25] <Stavros> i'll have a read on lightweight checkouts and figure it out, thank you all for your help!
[19:25]  * SamB seems to recall having ended up editing .conf files in the past
[20:11] <SamB> hmm, is there a way to use a different file instead of .bzr.log ?
[20:21] <fullermd> env BZR_LOG
[20:22] <SamB> is there any good reason for multi-pull to be recursing into .bzr directories?
[20:33] <fullermd> That sounds like the 'find_branches blows' bug.
[20:40] <fullermd> (well, related anyway.  It's going to "have to" recurse into .bzr for colo'd branches...)
[20:40] <ls3> is there a way to extract a directory from a (remote) branch? Ie, I have a repo of surveys but I want to do something like 'bzr export bzrrepo/surveys/foobar1 /save/to/dir' in a release script
[20:41] <ls3> Essentially extracting a single survey's directory within the repo.
[20:42] <fullermd> export does that.
[20:44] <ls3> oh ok. I must have failed previously
[20:45] <fullermd> Note that it looks like you have the args in reverse order.  bzr export DEST SRC.
[20:46] <ls3> yikes
[21:05] <barry> i have a question about what bzr-builddeb -S is supposed to do when upstream releases a .zip file.  anyone around to chat about that?  jelmer?
[21:06] <jelmer> hey barry
[21:06] <barry> hi jelmer
[21:06] <barry> jelmer: i'm helping someone add packaging for this: http://pypi.python.org/pypi/autobahn/0.4.10
[21:06] <jelmer> barry: .zip isn't a valid extension for debian source files, so you would have to repack it
[21:07] <jelmer> barry: bzr merge-upstream will accept .zip files, but it will re-export .orig.tar.gz files for this reason
[21:07] <barry> jelmer: yep, so i added a get-packaged-orig-source target which calls `uscan --force-download --repack`
[21:07] <barry> jelmer: but it still fails
[21:08] <jelmer> barry: how does it fail - doesn't uscan create a .orig.tar.gz file?
[21:08] <barry> jelmer: straight up uscan or even make -f debian/rules get-packaged-orig-source works properly, but bzr bd -S doesn't
[21:08] <barry> http://pastebin.ubuntu.com/826923/
[21:08] <barry> so this might just be a bug, but i wanted to understand what's intended before filing one
[21:09] <barry> after that failure, i see ../autobahn-0.4.10.zip but no orig.tar.gz
[21:09] <barry> and nothing in ../build-area
[21:09] <jelmer> does 'make -f ...' actually create a .tar.gz file ?
[21:10] <barry> yes, uscan --force-download --repack works.  it's bzr bd -S that doesn't
[21:10] <barry> jelmer: iow, i can do the uscan, then debuild -S and i get the expected source package.
[21:10] <barry> but bzr bd -S gives me the error
[21:12] <jelmer> barry: perhaps it's creating it in the wrong directory
[21:13] <barry> jelmer: could be, but if it's not in .. or ../build-area where would it be? ;)
[21:13]  * barry plays with --orig-dir
[21:14] <jelmer> barry: it should be in the cwd when make -f is executed, which is currently the source directory
[21:14] <barry> yeah --orig-dir doesn't help
[21:15] <barry> jelmer: yeah, there's no orig.tar.gz anywhere to be found
[21:16] <barry> jelmer: in case you want to take a look: lp:~barry/+junk/autobahn
[21:16]  * barry suspects it's just a bug
[21:16]  * jelmer looks
[21:17] <SamB> fullermd: what is this "find_branches" of which you speak?
[21:17] <fullermd> The API that roots around for branches under a dir.  multi-pull would use it to find the branches to pull.
[21:20] <jelmer> barry: you want --destdir=.
[21:20] <jelmer> barry: as argument to uscan
[21:21] <SamB> hmm, it looks like multi-pull is using something that drives find_bzrdirs, instead
[21:22] <barry> jelmer: thanks, that does seem to work, but i'm disturbed by the fact that `bzr bd -S` and `make -f debian/rules get-packaged-orig-source` leave things in different states
[21:22] <fullermd> Maybe that's what it's called.
[21:22] <jelmer> barry: where does 'make -f debian/rules get-packaged-orig-source' create the tarball?
[21:22] <SamB> no, the next method down is called "find_branches"
[21:23] <barry> jelmer: in ..
[21:23]  * SamB wonders where get-packaged-orig-source may be documented
[21:24] <barry> SamB: if you add get-orig-source and run debuild, you'll see a warning to use get-packaged-orig-source instead ;).  istr it described in some dpkg-* or debuild manpage somewhere, but don't remember the details
[21:25] <jelmer> barry: right, bzr bd expects the tarball in .
[21:26] <SamB> hmm, it looks like bzrtools might be avoiding find_branches because it wants an iterator?
[21:27] <jelmer> SamB: I think it's got it's own wrapper for find_branches which adds support for apache index.html files
[21:27] <barry> jelmer: hmm.  okay.  it does bother me that it seems difficult/impossible to make this work for either bd -S or debuild -S
[21:27] <barry> debuild -S afaict, expect it in ..
[21:28] <SamB> jelmer: oh, that's also true
[21:28] <SamB> I mean, there is certainly code here for scraping those
[21:28] <barry> jelmer: but now that i know how this works, i think i will just file a bug on bzr-builddeb and we can discuss further there
[21:28] <jelmer> barry: debuild -S doesn't run get-packaged-orig-source I think ?
[21:29] <SamB> multi-pull might not touch that, though
[21:29] <jelmer> barry: get-orig-source is defined as putting the tarball in the current directory, not ..
[21:29] <SamB> it seems to iterate over *local* branches
[21:29] <jelmer> barry: (per debian policy)
[21:29] <jelmer> barry: I would be very wary of diverging from that.
[21:30] <SamB> jelmer: presumably that's why this other target has a different name ?
[21:30] <jelmer> SamB: hmm, which target?
[21:30] <barry> jelmer: but, here's the problem.  if i do the following:
[21:30] <SamB> the "get-packaged-orig-source"
[21:30] <barry> make -f debian/rules get-packaged-orig-source
[21:30] <barry> followed by
[21:30] <barry> debuild -S
[21:30] <barry> the latter will fail to find the orig.tar.gz even though it is in .
[21:31] <jelmer> SamB: get-packaged-orig-source was added for bzr-builddeb specifically, because get-orig-source is defined retrieving the *current* upstream source tarball, not the upstream source for the current package version.
[21:31] <SamB> oh
[21:32] <jelmer> barry: right, but that's an issue for 'debian/rules get-orig-source' as well; we can't require get-orig-source to write to anything but "." because that would violate policy
[21:33]  * SamB wonders why launchpad doesn't give him a preview of his merge proposal
[21:33] <jelmer> we could change just get-packaged-orig-source, but that would make the target for get-orig-source and get-packaged-orig-source inconsistent which I think would be a bad idea.
[21:34] <barry> jelmer: something still isn't sitting right with me. ;)  let me look at one other thing for a moment
[21:34] <jelmer> barry: another alternative would be for bzr-builddeb to just do the repacking for you, doesn't it already do that?
[21:34] <barry> jelmer: it doesn't
[21:35] <jelmer> we could fix that at least, though
[21:36] <barry> jelmer: yep, i can file on that
[21:36] <barry> jelmer: here's what bothers me...
[21:37] <barry> if i branch say ubuntu:python-wadllib and then bzr bd -S i get the orig.tar.gz in ..
[21:37] <barry> it's also in ../build-area
[21:37] <barry> and no .orig.tar.gz in .
[21:38] <jelmer> barry: it's only copied there by bzr-builddeb itself before it builds
[21:38] <barry> jelmer: copied from where to where?
[21:38] <jelmer> barry: extracted from the relevant revision in the branch
[21:39] <barry> jelmer: into both .. and ../build-area ?
[21:40] <jelmer> barry: $(orig-dir) is the location where a cache of the orig tarballs is kept, $(build-area) is where the builds actually happen
[21:40] <barry> jelmer: okay that does make some sense then.  in one case we're using a source branch, so the info is in the branch revisions.  in the other, we have to download it from the 'net so it must conform to policy
[21:41] <jelmer> barry: the other difference is that files in $(orig-dir) can either be .tar.gz, .tar.bz2 or .tar.xz
[21:42] <jelmer> barry: for the build-area they're converted as necessary (e.g. if you're building a 1.0 version package they're converted to .tar.gz)
[21:42] <barry> make snse
[21:42] <barry> sense even
[21:42] <barry> jelmer: my (hopefully last ;) question is: what happens when the package gets uploaded and a source branch is created?  is get-packaged-orig-source ignored?
[21:43] <jelmer> barry: yes, get-packaged-orig-source is just one way to get the source
[21:43] <jelmer> IIRC we first look in ../tarballs, then check the branch for a relevant tag, then check get-packaged-orig-source, then try uscan
[21:43]  * SamB didn't know 1.0 packages were required to use .tar.gz
[21:44] <barry> jelmer: okay cool.  that all makes sense then and sounds good.  so i think the one bug to file then is that bd should do the repacking automatically, right?
[21:45] <jelmer> barry: yep
[21:45] <barry> jelmer: awesome.  thanks for all the help!
[21:45] <jelmer> barry: perhaps another about bzr-builddeb making it clearer where it expects the generated tarball?
[21:45] <barry> jelmer: yep
[21:46] <jelmer> barry: np, thanks for getting to the bottom of this and providing useful feedback, as always :)
[21:46] <barry> my pleasure! :)
[21:59] <SamB> jelmer: does bzr-svn need to be so noisy about not being able to open such-and-such location with subversion?
[22:00] <jelmer> SamB: it shouldn't be - what version of bzr-svn?
[22:00] <SamB> jelmer: I mean, it's just log messages, but for multi-pull it's a lot of 'em
[22:01] <SamB> hmm
[22:02] <jelmer> oh, you mean about the files in ~/.bzr.log? I guess it could be a bit quieter about that
[22:02] <jelmer> though I would also argue that the way in which the probing happens there is wrong
[22:02] <SamB> jelmer: happens where?
[22:03] <jelmer> SamB: in find_branches/find_bzrdirs
[22:03] <SamB> ah
[22:04] <SamB> yes, now that you mention it I did see some mention of probing elsewhere ...
[22:06] <jelmer> SamB: that's very well possible :)
[22:06] <jelmer> Probers are things that can detect a control directory somewhere
[22:06] <jelmer> so we have a BzrProber that looks at .bzr/branch-format and returns the right bzr format based on that
[22:06] <SamB> yeah, it seemed fairly likely given the name
[22:07] <jelmer> and svn registers two probers, one that recognizes svn repositories and one that recognizes svn checkouts
[22:07] <jelmer> etc
[23:32] <SamB> jelmer: so, how *should* find_bzrdirs be probing?