SamBit might be a good idea to also list whoever called the first of those guys to get called00:01
SamBoh, interesting00:06
SamB"bzr info -v" crashes on this branch00:06
SamBBranch history:00:06
SamB     14741 revisions00:06
SamBbzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///home/naesten/hacking/launchpad/.bzr/repository/') has no revision launchpad@pqm.canonical.com-20120201152332-0i5ysxdk0ouw6jc200:06
jelmerSamB: it's an interrupted clone?00:07
jelmerSamB: that's a bug fixed in 2.5, we shouldn't be setting the branch data unless the revision data is actually present00:08
jelmerso, it seems the odd thing wrt your traceback is that it's using vf_search.NotInOtherForRevs00:08
SamBbzr branch lp:launchpad; (hit ^C); bzr branch lp:launchpad; (this time it completes right away setting the branch data); cd launchpad; bzr pull00:09
jelmerand that doesn't have a get_recipe thing it can send over the wire00:09
jelmerSamB: yes, that's fixed in 2.500:09
SamBwhere is this "2.5" ?00:09
SamBI'm on b500:10
jelmerSamB: lp:bzr/2.500:10
SamBso, you mean it was fixed since 2.5b5?00:11
jelmerI THINK00:11
jelmersorry about the caps00:11
SamBno problem00:12
* SamB runs "sudo apt-get install bzr/unstable"00:16
SamBapt-get complains00:16
* SamB uses aptitude instead00:29
jelmerSamB: unstable doesn't have the right version yet I think00:29
SamBoh. what should I be installing, then ?00:30
jelmerSamDB: either way, the bug is just that it allows creating a branch without fetching the relevant data in an empty repository00:31
SamBoh, actually, it's not doing that anymore afaict00:31
jelmerSamB: a workaround is just to "bzr init foo && bzr pull lp:launchpad"00:31
SamBso I guess "bzr 2.5.0~bzr6458-2" was good enough00:32
jelmerah, ok :)00:33
SamB(apt-get is apparantly not smart enough to think of pulling python-bzrlib{,.tests} from unstable too00:35
SamBthough, 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, either00:36
SamBor better than deleting bzr, python-bzrlib, and everything that depend on them00:37
SamBwhy it thinks "delete the only thing asked for" or "leave the only thing asked for alone" are good plans, nobody seems to know00:38
* jelmer -> sleep00:41
Stavrosi 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
Stavroshere, i just merged B to A, and trying to pull from B to A needs another merge02:50
Stavrosi don't think this should be happening02:50
spivIf Stavros comes back, someone should suggest "bzr missing" to them to diagnose their situation.03:12
vilahi all !07:30
rcsheetshello vila07:32
wgzmorning vila.07:33
vilarcsheets: please to meet you (not sure I recognize the nick though ;)07:33
vilaheya wgz07:33
vilawgz: did you land evrything you wanted on 2.5 ?07:34
rcsheetsvila: i mostly lurk :)07:34
vilagood, we also welcome lurkers07:35
wgzbus time07:42
wgzvila: not yet07:42
vilawgz: k, ping me when you're done07:42
vilawgz: or better, let's chat quickly when you come out of the bus07:42
mgzmorning all!08:24
mgzvila: so, my issue is I still need to change some apis, but am having trouble deciding on how exactly to do it08:41
mgzand that's the kind of thing that should really be in the last beta08:41
mgzit should all be pretty safe, private functions, some extra args, and otherwise compatible08:45
rcsheetsgood morning08:57
mgzI am wondering from your nick rcsheets, why you need to revision control your bedding.08:57
rcsheetsit's... a complex and embarrassing story08:58
vilamgz: change APIs around unicode issues ?09:18
mgzvila: I need to alter two things particularly09:19
mgzhow trace exception reporting functions pass error information around09:19
mgzand some details of exception instances09:20
mgzI 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 class09:21
vilayou know about bt.test_trace right ?09:21
vilaI think that's where most of output tests are, checking various functions and combinations of encoding, let me check09:24
mgzalso bt.test_errors09:24
mgzI can certainly do this without breaking existing testcases09:24
vilahehe, that's bad :) You should at least add a failing test first ;)09:25
vilayou're fixing at least a bug right ?09:26
vilahmm, not sure that's the one I was thinking about09:27
mgzthere's also bb.test_non_ascii and things, but that's less useful09:27
mgzthe combinatronics aren't particularly valid in the same process without having an actually different locale09:27
vilathere 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
vilacan't find it back :-/ or may be it's not catching my eye as it did09:34
mgzdo we know what's up from the test failures from the bzr-builddeb ppa due to debian_releases() returning None?10:12
mgzI'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
jelmermgz: that's already fixed10:58
mgzah, that's the 'Fix tests' r714 commit.11:02
jelmermgz: yeah, that was kindof sloppy of me, only testing without distro_info installed11:58
mgzgah, I'm going nuts, I just need to start commiting bits12:06
* mgz shelves the world12:06
=== Quintasan_ is now known as Quintasan
vilamgz: 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 should put up his overwrite-tags MP while he still can13:18
vilaha :)13:18
* vila back14:07
vilajelmer, mgz: so what ?14:07
mgzvila: so, I still need to do some things, but only have the one mp to land atm14:11
mgzI think I can do some of this with... minimal-ish risk though, so it's not the end of the world if you freeze first14:11
vilaok, jelmer ?14:11
jelmervila: mp on the way14:12
vilaha cool14:12
jelmervila: proposed14:30
vilajelmer: so the idea is that you can use '--overwrite' or '--overwrite-tags' or both right ?14:35
mgzhm. `bzr rm .bzr` does something.14:36
mgedminooh! does it do something bad?14:36
jelmervila: yeah, though there isn't much point in that14:36
vilamgz: yeah, I receive an email saying you're naughty14:36
vilajelmer: in what ?14:37
jelmervila: (speciufying both is the same as just specifying --overwrite)14:37
* mgedmin now knows vila is santa!14:37
vilajelmer: and '--overwrite --no-overwrite-tags' works ?14:37
mgzjelmer: seems generally okay, but I'm not convinced by the passing around of 'history' and 'tags' strings14:38
jelmervila: We could also add --overwrite-history if you wanted to be able to just overwrite history14:38
mgzdo we really want to support lots more kinds of unversioned data?14:38
vilajelmer: nope, the change looks fine for now, I'm just kicking the tires14:38
rlyHow do I express 'do not care anything about local changes, just update it'?14:39
vilarly: 'bzr revert ; bzr update'14:39
rlyvila: thanks14:40
vilajelmer: meh, wtf with changes in bzrdir.py  on crontroldir.py ?14:42
vilaurgh, my bad14:42
jelmervila: hmm?14:43
vilanothing, did I mention anything ?14:43
* vila should really fix his bzr-review hack to take the targeted branch into account14:44
jelmermgz: thoughts on alternatives? Would you rather see another argument be passed around and renaming overwrite to overwrite_history ?14:50
vilajelmer: Aren't we breaking plugins that redefine push/pull here ?14:54
jelmervila: yes14:55
mgznot having a day of api epiphanies unfortunately14:55
mgzmaybe vila has clever ideas?14:55
vilamgz: it happens but I'm not sure I understand API epiphanies ;)14:56
vilajelmer: so having overwrite_tags will break them less no ?14:57
jelmervila: no, it will break them more15:00
jelmervila: 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 only15:00
jelmerif we add a separate parameter then it will definitely break them15:01
mgzideally that bool would flip, and tags would count as not overwriting at all15:02
mgzbut I don't think that's a big deal15:02
rlyWhy would anyone want to use bzr over any of the other DVCSs?15:04
mgzwhy would anyone want to use any of the other dvcss over bzr?15:04
rlymgz: for git: performance.15:05
rlymgz: for Mercurial: better user-interface and I think it is more popular.15:05
jelmerrly: unless you have a really big tree, I don't think there's a significant difference in performance left15:05
rlyI almost never see a bzr repository.15:05
rlyI think it is at around 2% or so for the repos I care about.15:06
jelmerrly: I think the Bazaar UI is much better than Mercurial's. Not sure about popularity15:06
rlyE.g. if bzr has zero open bugs, then that would be an advantage.15:06
rlyI think darcs has tons of bugs open, still.15:06
rlyAn open bug is something which affects correct operation.15:07
rlyNot some silly feature request.15:07
rlySpeed could affect correctness because of termination problems.15:07
rly'it takes until the heat death of the universe before this completes...'15:08
rlySo, that said, where does bzr stand?15:08
rlyhttps://bugs.launchpad.net/bzr suggests it is unmaintained.15:10
jelmerrly: why?15:10
jelmerrly: Mercurial and Bazaar both have open bugs15:11
vilarly: try https://launchpad.net/bzr/+milestones15:11
jelmerrly: 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
vilajelmer: 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
jelmervila: 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.015:34
vilaplugin breaks, fallouts discovered while using it...15:35
jelmervila: plugin breaks should be fine now before we have 2.5.015:36
jelmerthere 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 months15:36
vilagustavo 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 either15:38
jelmervila: he was specifically asking for this15:38
vilaand if we had proper versioning for tags we shouldn't need the option at all15:38
vilayes, but why ?15:38
jelmervila: https://bugs.launchpad.net/bzr/+bug/681792/comments/415:39
ubot5`Launchpad bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [High,In progress]15:39
vilato be able to *not* use --overwrite unconditionnally15:39
vilaI know I re-read it15:39
jelmervila: if we had proper versioning for tags we might still wants this option15:40
alucardnihello, is there a way to make bzr work behind a proxy? Exporting http_proxy, https_proxy doesn't work with bzr 2.5b515:40
vilajelmer: why ?15:40
jelmervila: because you might want to discard your local tags in favor of the ones on the remote host15:41
jelmervila: I don't see why that matters though, if you're happy for this change to land on trunk15:43
vilaI don't think pull and push are the right way to align tags between branches, it *is* today because the interactions are limited15:43
vilabecause we can more easily revert/fix it on trunk15:43
vilarushing features never worked in the past :-(15:44
MezIs 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
jelmervila: I don't think this is really rushing, and it's a really small feature15:44
jelmerMez: see "bzr split"15:44
Mezyeah, just spotted that15:45
jelmeralso, hi :)15:45
Mezhey :D15:45
vilajelmer: 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
Mezjelmer: how're nested trees coming along ?15:48
jelmervila: we have another full month for the final release, and this change is really simple. What is the worry?15:48
vilajelmer: that we said roughly the same thing one month ago ? ;)15:49
vilajelmer: 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
vilajelmer: 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 matter15:51
jelmervila: what do you mean with not public?15:51
jelmervila: 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
jelmerMez: slowly :)15:56
jelmerMez: but there is some progress, at least15:56
mgzheh, another dupe of the bug I'm working on now just filed16:13
uniquenickis bundlebuggy still actively maintained?16:59
jelmeruniquenick: it's not17:03
uniquenickdo the bzr devs still use it anyways, or something else?17:04
jelmeruniquenick: we're using Launchpad review system for bzr itself17:05
uniquenickdoes launchpad take over for pqm also, or is it still used?17:11
jelmeruniquenick: we're still using PQM17:11
abentleyjelmer: In fact, I've just submitted a branch for bzr-pqm.  Are you up for a review?17:21
jelmerabentley: sure17:31
abentleyjelmer: thanks.  https://code.launchpad.net/~abentley/bzr-pqm/fix-lp-land/+merge/9131817:31
mgzokay, nearly there, cut this down enough to be workable17:41
SamBit 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 that18:32
jelmerSamB: That's not necessarily useful - that would require it to send data in a specific order18:37
SamBjelmer: hmm?18:37
SamBoh ...18:37
jelmerSamB: 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 revisions18:37
jelmerSamB: so you would need to change things so that revisions are sent in toplogical order, and grouped data per revision18:38
SamBmaybe for large clones, multiple packs should be negotiated, then?18:38
jelmerSamB: why would you need multiple packs?18:39
jelmerSamB: it seems you're trying to solve a symptome of a problem rather than the problem itself18:39
SamBcould be18:41
SamBso, what I should be doing is making lp:launchpad smaller, you say?18:41
wgzresumable branching would be ace18:42
wgzbut nothing has been designed with that in mind unfortunately18:43
SamBwell, I don't see anything to out-and-out prevent the client doing it anyway18:43
jelmerSamB: why do you need resumable clones? Why is your clone being interrupted in the first place?18:43
SamBwell, okay, so bzr is eating a lot of RAM18:44
jelmerSamB: 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
jelmerSamB: so that seems like solving a symptom (interrupted clones) rather than the actual problem (high memory usage)18:44
SamBbut, there are many ways it *can* happen18:45
SamBsay, power loss18:45
wgz...the symptom there sounds easier :)18:45
SamBand there's that, too18:45
jelmerwgz: I don't see why we would need all that much memory during clone?18:45
jelmerSamB: is power loss really common enough to warrant decreasing performance and adding extra roundtrips?18:46
SamBjelmer: not seeing it is a *lot* easier than making the computer see not it18:46
wgzpeople with unreliable and slow connections are common enough18:46
SamBjelmer: well, it could be an option18:47
wgzI've never touched the launchpad source because it was basically unbranchable for me when I tried some years back18:47
jelmerwgz: we already retry in newer versions, so unreliable connections shouldn't be much of an issue anymore18:47
SamBfor those who tend to run out of batteries, lose connectivity, run out of RAM, you name it18:47
SamBjelmer: doesn't that depend on how long the connection goes out for?18:47
jelmerSamB: I'd rather see that engineering time be spent on reducing the memory overhead18:47
SamBjelmer: would be a lot more time, I think18:48
wgzthere's also the fact 2a requires a lot of actual processing client side18:48
jelmerSamB: I think they're both far from trivial.18:48
wgzanyway, there are various annoyances, that lp:launchpad has more problems with than most projects18:49
jelmerwgz: fair enough, but does that have to mean lots of memory use?18:49
jelmerwgz: yeah - the other thing I think is that lp:launchpad has lots of ghosts, and the we seem to be querying those repeatedly18:49
wgzjelmer: anything big that compresses well can cause memory issues on unpacking18: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 notice18:50
SamB(on this system)18:50
jelmerwgz: launchpad doesn't have really big tests so I'd be surprised if that was really an issue18:51
jelmerSamB: 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 client18:51
wgzyeah, without actually looking at the memory consumption it would be wrong to blame any particular thing18:51
jelmerSamB: so after the negotation, the server just streams a byte-for-byte pack file that the client can write to disk directly18:52
SamBjelmer: that's no excuse for us to suck at cloning 2a to 2a over smart server ...18:52
SamBjelmer: I thought the server used a thin packfile18:53
jelmerSamB: right, that's what I've been saying all along :)18:53
SamBwhich is not a file18:53
jelmerSamB: 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
SamBjelmer: well, yes, I know it's the same format18:54
jelmeras a client you can negotiate whether you're happy with a thin or a fat pack file18:54
SamBoh, I missed that18:54
jelmer(originally pack files were never thin IIUC)18:55
SamBso ... when bzr reconnects, how does it resume downloading the same pack, anyway?19:01
jelmerI'm not sure, I think it just re-does the request19:02
SamBso why couldn't the request be saved along with the partial packfile again ?19:04
LeoNerdIf 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
jelmerSamB: 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
LeoNerdIs there some garbage collection I can do to clean those up? Just want the disk space back really19:05
lifelessjelmer: original pack files were thin, because they were just vf deltas split temporally rather than fileidly19:05
jelmerLeoNerd: yes19:06
jelmerLeoNerd: I think bzr-colo has something, but there's nothing in core that can clean those revision up.19:06
LeoNerdAh OK.. Then I won't worry overly for now.. it's not -that- big..19:06
SamBjelmer: so ... how does the reconnecting thing help people with unreliable net connections?19:07
jelmerSamB: they don't have to run the command again19:08
SamBjelmer: that does a lot of good if the transfer keeps getting inturrupted, I suppose?19:08
jelmerSamB: it will retry a particular HPSS request only once19:08
jelmerSamB: so if it keeps getting interrupted you still have a problem19:09
jelmerSamB: but I'm not sure if that's really an issue we should be trying to solve in bzr19:09
SamBwell, it would beat having to sit there and type "bzr pull -r <something>" over and over19:11
jelmerSamB: so, let's fix the reason why you're keep hitting those memory limits19:11
jelmerallowing resumes wouldn't be complex *and* would hurt performance even further19:12
jelmerSamB: Git doesn't have any kind of resuming either - do you miss it there?19:12
SamBwell, somehow no19:12
SamBbut I'm not sure why I haven't ...19:13
jelmerhi Stavros19:16
Stavrosi copied an entire working tree directory with cp -R master otherbranch and the repos are somehow shared, what trickery is this?19:16
Stavrosi want completely different repos i can push and pull from19:17
jelmerStavros: how are they shared?19:17
Stavroswhen i commit in one, the commit shows up in the others19:17
jelmerare they checkouts of the same branch, perhaps?19:17
Stavrosand bzr info on the other repos shows: shared repository: master/.bzr/branches19:17
jelmerStavros: you're using bzr-colo ?19:18
Stavrosi have it installed, yes19:18
SamBlightweight checkouts ?19:18
jelmerStavros: it seems this is some sort of bzr-colo thing, I'm familiar with that - sorry19:18
Stavroscan i unshare it?19:19
SamBjelmer: +not, right?19:19
jelmerStavros: euhm, yep, thanks19:19
SamBStavros: bzr reconfigure is your friend19:19
SamBwell, I think it is19:19
Stavrosbzr reconfigure --checkout .?19:19
Stavrosah, standalone19:20
jelmerstavros: "bzr reconfigure --standalone" I think19:20
jelmerStavros: are you using bzr explorer? I wouldn't know how you end up with bzr-colo workspaces otherwise19:20
Stavrosi'm not, but i colo-ified my repo once19:20
Stavrosbut it's weird that it knows to share, since i'm doing cp -R19:20
Stavrosapparently this is a lightweight checkout19:21
Stavrosi didn't know you could do that with cp -R19:21
Stavrosbah, now bzr-reconfigure fails with "repo is already standalone" and bzr info says it's a lightweight checkout19:21
Stavrosi branched and moved the .bzr dir to this repo and now it's a standalone repo19:22
Stavrosbut i don't understand what's going on otherwise19:23
Stavrosaha, now one of the branches complains there's no repo19:23
Stavrosi'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 past19:25
SamBhmm, is there a way to use a different file instead of .bzr.log ?20:11
fullermdenv BZR_LOG20:21
SamBis there any good reason for multi-pull to be recursing into .bzr directories?20:22
fullermdThat 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
ls3is 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 script20:40
ls3Essentially extracting a single survey's directory within the repo.20:41
fullermdexport does that.20:42
ls3oh ok. I must have failed previously20:44
fullermdNote that it looks like you have the args in reverse order.  bzr export DEST SRC.20:45
barryi 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
jelmerhey barry21:06
barryhi jelmer21:06
barryjelmer: i'm helping someone add packaging for this: http://pypi.python.org/pypi/autobahn/0.4.1021:06
jelmerbarry: .zip isn't a valid extension for debian source files, so you would have to repack it21:06
jelmerbarry: bzr merge-upstream will accept .zip files, but it will re-export .orig.tar.gz files for this reason21:07
barryjelmer: yep, so i added a get-packaged-orig-source target which calls `uscan --force-download --repack`21:07
barryjelmer: but it still fails21:07
jelmerbarry: how does it fail - doesn't uscan create a .orig.tar.gz file?21:08
barryjelmer: straight up uscan or even make -f debian/rules get-packaged-orig-source works properly, but bzr bd -S doesn't21:08
barryso this might just be a bug, but i wanted to understand what's intended before filing one21:08
barryafter that failure, i see ../autobahn-0.4.10.zip but no orig.tar.gz21:09
barryand nothing in ../build-area21:09
jelmerdoes 'make -f ...' actually create a .tar.gz file ?21:09
barryyes, uscan --force-download --repack works.  it's bzr bd -S that doesn't21:10
barryjelmer: iow, i can do the uscan, then debuild -S and i get the expected source package.21:10
barrybut bzr bd -S gives me the error21:10
jelmerbarry: perhaps it's creating it in the wrong directory21:12
barryjelmer: could be, but if it's not in .. or ../build-area where would it be? ;)21:13
* barry plays with --orig-dir21:13
jelmerbarry: it should be in the cwd when make -f is executed, which is currently the source directory21:14
barryyeah --orig-dir doesn't help21:14
barryjelmer: yeah, there's no orig.tar.gz anywhere to be found21:15
barryjelmer: in case you want to take a look: lp:~barry/+junk/autobahn21:16
* barry suspects it's just a bug21:16
* jelmer looks21:16
SamBfullermd: what is this "find_branches" of which you speak?21:17
fullermdThe API that roots around for branches under a dir.  multi-pull would use it to find the branches to pull.21:17
jelmerbarry: you want --destdir=.21:20
jelmerbarry: as argument to uscan21:20
SamBhmm, it looks like multi-pull is using something that drives find_bzrdirs, instead21:21
barryjelmer: 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 states21:22
fullermdMaybe that's what it's called.21:22
jelmerbarry: where does 'make -f debian/rules get-packaged-orig-source' create the tarball?21:22
SamBno, the next method down is called "find_branches"21:22
barryjelmer: in ..21:23
* SamB wonders where get-packaged-orig-source may be documented21:23
barrySamB: 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 details21:24
jelmerbarry: right, bzr bd expects the tarball in .21:25
SamBhmm, it looks like bzrtools might be avoiding find_branches because it wants an iterator?21:26
jelmerSamB: I think it's got it's own wrapper for find_branches which adds support for apache index.html files21:27
barryjelmer: hmm.  okay.  it does bother me that it seems difficult/impossible to make this work for either bd -S or debuild -S21:27
barrydebuild -S afaict, expect it in ..21:27
SamBjelmer: oh, that's also true21:28
SamBI mean, there is certainly code here for scraping those21:28
barryjelmer: but now that i know how this works, i think i will just file a bug on bzr-builddeb and we can discuss further there21:28
jelmerbarry: debuild -S doesn't run get-packaged-orig-source I think ?21:28
SamBmulti-pull might not touch that, though21:29
jelmerbarry: get-orig-source is defined as putting the tarball in the current directory, not ..21:29
SamBit seems to iterate over *local* branches21:29
jelmerbarry: (per debian policy)21:29
jelmerbarry: I would be very wary of diverging from that.21:29
SamBjelmer: presumably that's why this other target has a different name ?21:30
jelmerSamB: hmm, which target?21:30
barryjelmer: but, here's the problem.  if i do the following:21:30
SamBthe "get-packaged-orig-source"21:30
barrymake -f debian/rules get-packaged-orig-source21:30
barryfollowed by21:30
barrydebuild -S21:30
barrythe latter will fail to find the orig.tar.gz even though it is in .21:30
jelmerSamB: 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
jelmerbarry: 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 policy21:32
* SamB wonders why launchpad doesn't give him a preview of his merge proposal21:33
jelmerwe 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
barryjelmer: something still isn't sitting right with me. ;)  let me look at one other thing for a moment21:34
jelmerbarry: another alternative would be for bzr-builddeb to just do the repacking for you, doesn't it already do that?21:34
barryjelmer: it doesn't21:34
jelmerwe could fix that at least, though21:35
barryjelmer: yep, i can file on that21:36
barryjelmer: here's what bothers me...21:36
barryif i branch say ubuntu:python-wadllib and then bzr bd -S i get the orig.tar.gz in ..21:37
barryit's also in ../build-area21:37
barryand no .orig.tar.gz in .21:37
jelmerbarry: it's only copied there by bzr-builddeb itself before it builds21:38
barryjelmer: copied from where to where?21:38
jelmerbarry: extracted from the relevant revision in the branch21:38
barryjelmer: into both .. and ../build-area ?21:39
jelmerbarry: $(orig-dir) is the location where a cache of the orig tarballs is kept, $(build-area) is where the builds actually happen21:40
barryjelmer: 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 policy21:40
jelmerbarry: the other difference is that files in $(orig-dir) can either be .tar.gz, .tar.bz2 or .tar.xz21:41
jelmerbarry: 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
barrymake snse21:42
barrysense even21:42
barryjelmer: 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
jelmerbarry: yes, get-packaged-orig-source is just one way to get the source21:43
jelmerIIRC we first look in ../tarballs, then check the branch for a relevant tag, then check get-packaged-orig-source, then try uscan21:43
* SamB didn't know 1.0 packages were required to use .tar.gz21:43
barryjelmer: 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
jelmerbarry: yep21:45
barryjelmer: awesome.  thanks for all the help!21:45
jelmerbarry: perhaps another about bzr-builddeb making it clearer where it expects the generated tarball?21:45
barryjelmer: yep21:45
jelmerbarry: np, thanks for getting to the bottom of this and providing useful feedback, as always :)21:46
barrymy pleasure! :)21:46
SamBjelmer: does bzr-svn need to be so noisy about not being able to open such-and-such location with subversion?21:59
jelmerSamB: it shouldn't be - what version of bzr-svn?22:00
SamBjelmer: I mean, it's just log messages, but for multi-pull it's a lot of 'em22:00
jelmeroh, you mean about the files in ~/.bzr.log? I guess it could be a bit quieter about that22:02
jelmerthough I would also argue that the way in which the probing happens there is wrong22:02
SamBjelmer: happens where?22:02
jelmerSamB: in find_branches/find_bzrdirs22:03
SamByes, now that you mention it I did see some mention of probing elsewhere ...22:04
jelmerSamB: that's very well possible :)22:06
jelmerProbers are things that can detect a control directory somewhere22:06
jelmerso we have a BzrProber that looks at .bzr/branch-format and returns the right bzr format based on that22:06
SamByeah, it seemed fairly likely given the name22:06
jelmerand svn registers two probers, one that recognizes svn repositories and one that recognizes svn checkouts22:07
=== r0bby is now known as r0bby_
=== r0bby_ is now known as robbyoconnor
SamBjelmer: so, how *should* find_bzrdirs be probing?23:32

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!