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