| SamB | it might be a good idea to also list whoever called the first of those guys to get called | 00:01 |
|---|---|---|
| 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:06 |
| jelmer | SamB: it's an interrupted clone? | 00:07 |
| SamB | yeah | 00:07 |
| 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:08 |
| 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:09 |
| SamB | I'm on b5 | 00:10 |
| jelmer | SamB: lp:bzr/2.5 | 00:10 |
| 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:11 |
| SamB | no problem | 00:12 |
| * SamB runs "sudo apt-get install bzr/unstable" | 00:16 | |
| SamB | hmm | 00:16 |
| SamB | apt-get complains | 00:16 |
| * SamB uses aptitude instead | 00:29 | |
| jelmer | SamB: unstable doesn't have the right version yet I think | 00:29 |
| SamB | oh. what should I be installing, then ? | 00:30 |
| 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:31 |
| SamB | so I guess "bzr 2.5.0~bzr6458-2" was good enough | 00:32 |
| jelmer | ah, ok :) | 00:33 |
| SamB | (apt-get is apparantly not smart enough to think of pulling python-bzrlib{,.tests} from unstable too | 00:35 |
| 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:36 |
| SamB | or better than deleting bzr, python-bzrlib, and everything that depend on them | 00:37 |
| 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:38 |
| jelmer | :) | 00:39 |
| * jelmer -> sleep | 00:41 | |
| Stavros | hello | 02:48 |
| 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:49 |
| 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 | 02:50 |
| spiv | If Stavros comes back, someone should suggest "bzr missing" to them to diagnose their situation. | 03:12 |
| vila | hi all ! | 07:30 |
| rcsheets | hello vila | 07:32 |
| wgz | morning vila. | 07:33 |
| vila | rcsheets: please to meet you (not sure I recognize the nick though ;) | 07:33 |
| vila | heya wgz | 07:33 |
| vila | wgz: did you land evrything you wanted on 2.5 ? | 07:34 |
| rcsheets | vila: i mostly lurk :) | 07:34 |
| vila | good, we also welcome lurkers | 07:35 |
| 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 | 07:42 |
| mgz | morning all! | 08:24 |
| 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:41 |
| mgz | it should all be pretty safe, private functions, some extra args, and otherwise compatible | 08:45 |
| rcsheets | good morning | 08:57 |
| mgz | I am wondering from your nick rcsheets, why you need to revision control your bedding. | 08:57 |
| rcsheets | it's... a complex and embarrassing story | 08:58 |
| mgz | :) | 08:58 |
| vila | mgz: change APIs around unicode issues ? | 09:18 |
| mgz | vila: I need to alter two things particularly | 09:19 |
| mgz | how trace exception reporting functions pass error information around | 09:19 |
| mgz | and some details of exception instances | 09:20 |
| 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:21 |
| mgz | ...specifically? | 09:23 |
| 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:24 |
| vila | hehe, that's bad :) You should at least add a failing test first ;) | 09:25 |
| vila | you're fixing at least a bug right ? | 09:26 |
| 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:27 |
| 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:28 |
| vila | can't find it back :-/ or may be it's not catching my eye as it did | 09:34 |
| mgz | do we know what's up from the test failures from the bzr-builddeb ppa due to debian_releases() returning None? | 10:12 |
| mgz | I'm guessing it's related to the package upgrades we've been trying to get through on the builders? | 10:14 |
| === zyga_ is now known as zyga-xchat | ||
| === yofel_ is now known as yofel | ||
| jelmer | mgz: that's already fixed | 10:58 |
| mgz | ace. | 10:59 |
| mgz | ah, that's the 'Fix tests' r714 commit. | 11:02 |
| jelmer | mgz: yeah, that was kindof sloppy of me, only testing without distro_info installed | 11:58 |
| mgz | gah, I'm going nuts, I just need to start commiting bits | 12:06 |
| * mgz shelves the world | 12:06 | |
| === Quintasan_ is now known as Quintasan | ||
| 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:16 |
| jelmer | oh | 13:18 |
| * jelmer should put up his overwrite-tags MP while he still can | 13:18 | |
| vila | ha :) | 13:18 |
| * vila back | 14:07 | |
| vila | jelmer, mgz: so what ? | 14:07 |
| 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:11 |
| jelmer | vila: mp on the way | 14:12 |
| vila | ha cool | 14:12 |
| jelmer | vila: proposed | 14:30 |
| vila | jelmer: so the idea is that you can use '--overwrite' or '--overwrite-tags' or both right ? | 14:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| rly | How do I express 'do not care anything about local changes, just update it'? | 14:39 |
| vila | rly: 'bzr revert ; bzr update' | 14:39 |
| rly | vila: thanks | 14:40 |
| vila | jelmer: meh, wtf with changes in bzrdir.py on crontroldir.py ? | 14:42 |
| vila | urgh, my bad | 14:42 |
| jelmer | vila: hmm? | 14:43 |
| vila | nothing, did I mention anything ? | 14:43 |
| jelmer | :) | 14:44 |
| * vila should really fix his bzr-review hack to take the targeted branch into account | 14:44 | |
| jelmer | mgz: thoughts on alternatives? Would you rather see another argument be passed around and renaming overwrite to overwrite_history ? | 14:50 |
| vila | jelmer: Aren't we breaking plugins that redefine push/pull here ? | 14:54 |
| jelmer | vila: yes | 14:55 |
| mgz | not having a day of api epiphanies unfortunately | 14:55 |
| mgz | maybe vila has clever ideas? | 14:55 |
| vila | mgz: it happens but I'm not sure I understand API epiphanies ;) | 14:56 |
| vila | jelmer: so having overwrite_tags will break them less no ? | 14:57 |
| 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:00 |
| jelmer | if we add a separate parameter then it will definitely break them | 15:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| rly | 'it takes until the heat death of the universe before this completes...' | 15:08 |
| rly | So, that said, where does bzr stand? | 15:08 |
| rly | https://bugs.launchpad.net/bzr suggests it is unmaintained. | 15:10 |
| jelmer | rly: why? | 15:10 |
| 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:11 |
| 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:27 |
| 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:34 |
| vila | plugin breaks, fallouts discovered while using it... | 15:35 |
| 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:36 |
| 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:38 |
| 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:39 |
| 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:40 |
| jelmer | vila: because you might want to discard your local tags in favor of the ones on the remote host | 15:41 |
| 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:43 |
| 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:44 |
| Mez | yeah, just spotted that | 15:45 |
| jelmer | also, hi :) | 15:45 |
| Mez | hey :D | 15:45 |
| 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:46 |
| 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:48 |
| vila | jelmer: that we said roughly the same thing one month ago ? ;) | 15:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| jelmer | Mez: slowly :) | 15:56 |
| jelmer | Mez: but there is some progress, at least | 15:56 |
| mgz | heh, another dupe of the bug I'm working on now just filed | 16:13 |
| uniquenick | is bundlebuggy still actively maintained? | 16:59 |
| alucardni | \wc | 17:00 |
| jelmer | uniquenick: it's not | 17:03 |
| uniquenick | do the bzr devs still use it anyways, or something else? | 17:04 |
| jelmer | uniquenick: we're using Launchpad review system for bzr itself | 17:05 |
| uniquenick | does launchpad take over for pqm also, or is it still used? | 17:11 |
| jelmer | uniquenick: we're still using PQM | 17:11 |
| abentley | jelmer: In fact, I've just submitted a branch for bzr-pqm. Are you up for a review? | 17:21 |
| jelmer | abentley: sure | 17:31 |
| abentley | jelmer: thanks. https://code.launchpad.net/~abentley/bzr-pqm/fix-lp-land/+merge/91318 | 17:31 |
| mgz | okay, nearly there, cut this down enough to be workable | 17:41 |
| SamB | hmm | 18:29 |
| SamB | it would be nice if bzr would save what it's downloaded so far to non-temporary packfiles every so often ... | 18:30 |
| * SamB expects there's a bug about that | 18:32 | |
| 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:37 |
| 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:38 |
| 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:39 |
| SamB | could be | 18:41 |
| SamB | so, what I should be doing is making lp:launchpad smaller, you say? | 18:41 |
| wgz | resumable branching would be ace | 18:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| * 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| jelmer | (originally pack files were never thin IIUC) | 18:55 |
| SamB | so ... when bzr reconnects, how does it resume downloading the same pack, anyway? | 19:01 |
| jelmer | I'm not sure, I think it just re-does the request | 19:02 |
| SamB | so why couldn't the request be saved along with the partial packfile again ? | 19:04 |
| 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:05 |
| 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:06 |
| SamB | jelmer: so ... how does the reconnecting thing help people with unreliable net connections? | 19:07 |
| 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:08 |
| 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:09 |
| 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:11 |
| 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:12 |
| jelmer | s/wouldn't/would/ | 19:13 |
| SamB | but I'm not sure why I haven't ... | 19:13 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| Stavros | i branched and moved the .bzr dir to this repo and now it's a standalone repo | 19:22 |
| 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:23 |
| 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 | 19:25 | |
| SamB | hmm, is there a way to use a different file instead of .bzr.log ? | 20:11 |
| fullermd | env BZR_LOG | 20:21 |
| SamB | is there any good reason for multi-pull to be recursing into .bzr directories? | 20:22 |
| fullermd | That sounds like the 'find_branches blows' bug. | 20:33 |
| 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:40 |
| ls3 | Essentially extracting a single survey's directory within the repo. | 20:41 |
| fullermd | export does that. | 20:42 |
| ls3 | oh ok. I must have failed previously | 20:44 |
| fullermd | Note that it looks like you have the args in reverse order. bzr export DEST SRC. | 20:45 |
| ls3 | yikes | 20:46 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| jelmer | barry: perhaps it's creating it in the wrong directory | 21:12 |
| 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:13 | |
| 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:14 |
| barry | jelmer: yeah, there's no orig.tar.gz anywhere to be found | 21:15 |
| 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:16 | |
| 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:17 |
| jelmer | barry: you want --destdir=. | 21:20 |
| jelmer | barry: as argument to uscan | 21:20 |
| SamB | hmm, it looks like multi-pull is using something that drives find_bzrdirs, instead | 21:21 |
| 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:22 |
| barry | jelmer: in .. | 21:23 |
| * SamB wonders where get-packaged-orig-source may be documented | 21:23 | |
| 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:24 |
| jelmer | barry: right, bzr bd expects the tarball in . | 21:25 |
| SamB | hmm, it looks like bzrtools might be avoiding find_branches because it wants an iterator? | 21:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| * 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:33 |
| 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:34 |
| jelmer | we could fix that at least, though | 21:35 |
| barry | jelmer: yep, i can file on that | 21:36 |
| barry | jelmer: here's what bothers me... | 21:36 |
| 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:37 |
| 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:38 |
| barry | jelmer: into both .. and ../build-area ? | 21:39 |
| 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:40 |
| jelmer | barry: the other difference is that files in $(orig-dir) can either be .tar.gz, .tar.bz2 or .tar.xz | 21:41 |
| 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:42 |
| 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:43 | |
| 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:44 |
| 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:45 |
| jelmer | barry: np, thanks for getting to the bottom of this and providing useful feedback, as always :) | 21:46 |
| barry | my pleasure! :) | 21:46 |
| SamB | jelmer: does bzr-svn need to be so noisy about not being able to open such-and-such location with subversion? | 21:59 |
| 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:00 |
| SamB | hmm | 22:01 |
| 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:02 |
| jelmer | SamB: in find_branches/find_bzrdirs | 22:03 |
| SamB | ah | 22:03 |
| SamB | yes, now that you mention it I did see some mention of probing elsewhere ... | 22:04 |
| 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:06 |
| jelmer | and svn registers two probers, one that recognizes svn repositories and one that recognizes svn checkouts | 22:07 |
| jelmer | etc | 22:07 |
| === r0bby is now known as r0bby_ | ||
| === r0bby_ is now known as robbyoconnor | ||
| SamB | jelmer: so, how *should* find_bzrdirs be probing? | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!