[00:01] poolie: Ahhh... that's it. I merged to trunk, found a significant bug, shelved the barnch for a while. I must not have reverted that merge in trunk. [00:01] Oh, what a headache. [00:03] awmcclain: so um [00:03] try doing something like this: [00:03] run log on the feature branch, to find the revisions with changes you want to keep [00:03] then do a cherrypick merge of them into trunk [00:03] this should bring the files back into existance [00:04] then merge back into feature branch? [00:04] Or, what if I create a new feature branch, and just cherrypick merge from my old branch into that? [00:05] spiv: alive? [00:05] spiv: did you already fix a dupe of bug 356699 perhaps? [00:05] Launchpad bug 356699 in bzr "not stacking when source branch doesn't support stacking, even though it states it will do" [Undecided,New] https://launchpad.net/bugs/356699 [00:06] awmcclain: oh sorry you're trying to merge trunk in, i see [00:06] how about [00:06] merge trunk, then do [00:06] 'bzr merge -r 10..20 .' [00:06] ie replay those changes from this branch [00:06] oh, smart. [00:07] where 10 is the feature revision where trunk and feature diverge, and 20 is the feature revision just before i merge trunk back in [00:10] hello, a dev here just committed a change to a branch, somehow it included a remove and add of the same file, even though his 'bzr st' and 'bzr diff' before commit didn't show this change, and he claims he didn't touch that file. [00:11] now a checkout of that branch fails with "bzr: ERROR: Revision {.......} not present in "....." [00:11] kenichi_: using plain bzr or bzr-svn? [00:12] i didn't set up this branch, but i believe the trunk it came from was initially set up with bzr-svn [00:19] poolie: I'm alive, I don't remember fixing that bug, although anything is possible... [00:19] * spiv quickly checks the recent changes [00:21] it just sounded like something you changed [00:22] lifeless has touched that code recently as part of cutting out more roundtrips from push. [00:22] poolie: does bzr-svn cause this? is there somewhere you could point me to read up on issues like this? [00:23] He may have accidentally fixed that at the same time, I'm not sure. [00:23] kenichi_: i've seen some bug reports similar to this, i don't know specifically what's happening sorry [00:23] jelmer might, or you can ask on the bazaar list [00:23] ok, thanks [00:27] kenichi_: what's the bug # exactly? [00:28] jelmer: i haven't filed a bug report, just the abridged paste above. [00:29] kenichi_: It's hard to say anything specifically related to the error class, can you perhaps pastebin the traceback? [00:32] jelmer: i'm not actually getting a traceback, just the error, and a non-working checkout. is there a arg i can pass to get more info? (tried -v) [00:38] jelmer: here's as much info as i have to give http://pastebin.com/d176d4a49 [00:48] poolie: we have bugs remaining in autostacking [00:49] poolie: its possible I fixed the most recently opened one, but I haven't explicitly checked [01:13] spiv: how goes the ghost inventory tests? [01:21] morning all [01:24] morning [01:26] hi igc [01:27] hi lifeless [01:28] hi guys - is there any way I can remove a "pending merge", as it's not showing up in my repository viewer for some reason :S [01:28] vxnick: bzr revert [01:28] vxnick: a pending merge is one that has been done to your working tree but not committed to the repository [01:28] lifeless: I see, thanks [01:29] lifeless: any way I can "undo" that revert? I didn't realise it'd remove everything I've just done :) [01:30] vxnick: uhm heh. It will have backed up to files with ~ in their name anything you had edited [01:30] poolie: fyi, my top tasks today are admin-related: hr, expenses, etc. I'll then try to get an email out re branch specific rules status & options going forward [01:30] igc, thanks [01:30] thanks for the user documentation [01:30] vxnick: things changed by the merge that you had not edited are recoverable by repeating the merge [01:30] mine are too, specifically expenses, report and reviews [01:31] lifeless: sorry to bother you - how can I merge these back? [01:32] vxnick: can you rephrase, I don't quite follow the question [01:32] lifeless: well, I've reverted as you suggested - I see the ~ files; how do I put my changes back into the main files? Not sure how else to explain it I'm afraid [01:33] vxnick: first, repeat the merge [01:33] lifeless: bzr merge? [01:33] yeah, however you did it before [01:34] lifeless: well I didn't do it specifically last time; it just kinda happened :P [01:34] I'll give it a go [01:35] argh [01:35] ok, so once you've got the merge done, you can copy the ~ files back over [01:35] no idea [01:35] ok [01:35] what commands had you run leading up to this [01:36] right - initially I made a single-file commit; I then went on to work on some other files, and committed those as a newer revision. This stated that it would merge r127 (the single commit) into r128 [01:36] the problem then being that r127 doesn't show up in my repo viewer [01:36] so I have since uncommited back to r126 [01:36] then reverted as you suggested [01:37] interesting [01:37] in a bad way? :P [01:38] I'm trying to imagine why you would get told a merge is happening when you haven't apparently being doing merges [01:38] is this a checkout of a branch other people commit to as well? [01:38] I'm using bzr as a centralised system in this case [01:38] just myself [01:38] it made me bzr update before I could commit r127 (the single file) [01:38] ok! [01:38] bzr update is a form of merge [01:38] I see [01:39] ok [01:39] now, 127 is probably 126.1.1 now, because of the merge [01:39] but because you uncommitted its all rather invisible [01:39] right [01:39] have you got bzrtools installed? there is a command in there 'bzr heads' that may be useful [01:40] I believe so - I'll run it... [01:40] bzr heads --dead [01:40] just going to install it [01:40] I appreciate your help btw :) [01:40] anytime [01:43] bah bzrtools isn't working for me [01:45] probably because it's not compatible bzr 1.5 by the looks of it [01:45] you'd need bzrtools 1.5 [01:45] ah yes, just trying it [01:47] lifeless: unknown command "head" [01:47] heads [01:47] its a plural ;) [01:47] returns nothing [01:47] bzr heads --dead ? [01:47] yeah a load of stuff [01:47] anything in particular I'm looking for? [01:48] well, it will let us undo the uncommit, if you want to [01:48] I'm not quite sure what the best way out of this is [01:48] hmm [01:48] anything you have committed is recoverable [01:49] so a revert only affects my working copy, not the repo? [01:49] and the backup files will contain any edits you'd made and not committed [01:49] right [01:49] poolie: if you get a chance, I'd like you feedback on the user doc as well, though that can wait til early next week [01:49] so if I wanted to, I could delete my working copy and do a fresh checkout? [01:49] a revert puts your local tree back to the state of the branch [01:49] it gets rid of edits and of pending merges [01:49] I see [01:50] not quite sure where to go from here to be honest [01:51] so, whats your current state? if I understand correctly you have [01:51] - some stuff you uncommitted [01:51] - some stuff we reverted [01:51] what would you like to have? [01:52] ultimately, I'd like to separate this merged r127 so I can commit it seperate to r128; but short-term I'd like to get back to where I was, which was without reverting :P [01:52] before reverting, even [01:52] so before reverting you had the content of the thing you'd uncommitted [01:52] let me just have a quick scroll up [01:54] I'm just gonig to reboot; I'll be back in a few minutes [01:54] I keep on getting the following with bzr.dev (even after trying make clean; make and I don't see old bzrlibs lying around in my pythonpath) [01:54] bzr: ERROR: The API for "" is not compatible with "(1, 14, 0)". It supports versions "(1, 15, 0)" to "(1, 15, 0)". [01:54] lifeless: thanks for letting me know [02:01] (andrew) Bump api_minimum_version to 0.15.0 because of the removal of [02:01] InstallFailed. [02:01] ^^^ that seems to be the culprit (pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m) [02:03] back [02:03] hi [02:03] right, I've checked my history [02:04] I uncommitted 128 and 127, so I'm currently at 126 [02:04] ok [02:04] you should be able to just 'bzrpull -r revid: .' [02:04] and all my changed files are at r126 [02:04] I'll give that a try [02:05] (and bzr heads can give you the revid for what you had at 128) [02:05] it doesn't unfrotunately [02:05] heads --dead doesn't anyway [02:05] thats odd [02:05] well it will be in your ~/.bzr.log [02:06] can I grep for 128 in that log? [02:06] it's pretty packed [02:06] yah [02:06] or at least less, then /128 [02:07] you're looking for a revid, which looks like email-date-random [02:07] righto [02:08] I've grep'ed for 20090508 and have one result, which I'm presuming is 128 [02:08] anyways, I'm surprised that nobody else is getting that problem, must be on my setup then. have to sleep now. goodnight. [02:08] AmanicA: are you running nightlies? [02:08] :) [02:09] 3am [02:09] AmanicA: if you're running bzr.dev or a nightly package, you will get skew like this from time to time [02:09] not sure what nighties are [02:09] ah [02:09] no bzr.dev [02:09] it means a plugin (e.g. bzrtools, or bzr-svn) hasn't updated. [02:10] ok thx. I thought so but it seemed to be in __init__.pyc so I thought it a core issue [02:10] lifeless: is the revid the full me@domain-datetime-random string? [02:10] or just part of it [02:10] the full thing [02:10] thanks [02:10] to give it to the ui, prefix it with revid: [02:11] trying now [02:11] AmanicA: __init__ has 1,15,0, whatever is asking is asking for 1,14,0 [02:11] but that may just be wher bzr complains [02:11] lifeless: do I need the < > around it? [02:11] ok thx [02:11] vxnick: no [02:12] for instances, revid:pqm@pqm.ubuntu.com-20090504033314-7mfh3y311028dk2m [02:12] bah, gotta install bzrpull too by the looks of it :) [02:12] vxnick: 'bzr pull ...' [02:12] vxnick: you missing a space: ) [02:12] woops [02:12] I was copying you literally [02:13] *I* missed a space ;) [02:14] lifeless: thanks a lot for responging, I thought I was losing it for a while. Would have been nice if it said what wanted the new version, will look into it another night. anyways goodnight. [02:14] lifeless: I think you may possibly be a genius :) [02:14] lifeless: it says I'm on r128 now so I just need to resolve some conflicts [02:14] vxnick: ok, cool [02:14] are the .moved files the newer ones (r128) or the r126 ones? [02:16] older I would expect [02:16] many thanks for your help - I'll try to do it from here :) [02:16] really appreciate it [02:21] igc: responding to your doc is on my todo as well [02:21] however today is already quite full :) [02:21] spiv: reping, see above [02:23] I'm afraid I need some help merging these .moved files :( [02:23] not really sure how to do it [02:24] well [02:24] the easiest way is just to mv them over the non .moved files; if the non .moved files are unchanged (don't show up in bzr st or bzr diff) [02:24] then you can do 'bzr diff' and see the difference [02:25] I also have these ~1~ files left [02:25] similar/same process for them [02:26] these .moved files look identical - you're saying delete them basically? [02:26] or delete the originals [02:28] if they are identical delete them [02:28] question - are they conflicting because they're identical? bzr auto-resolves conflicts usually doesn't it? [02:29] they're conflicting because they were existing files where bzr wanted to put files [02:29] gotcha [02:29] bzr resolve can be used to tell bzr that you have resolved a conflict [02:29] thanks [02:33] ok, I've removed the duplicates however bzr resolve is still showing the conflicts [02:33] my mistake [02:33] I didn't do --all [02:35] lifeless: any chance we could attempt separating the merged r127 from r128? [02:35] or isn't that possible [02:38] vxnick: I'm reasonably sure they are separate in bzr's internals [02:38] vxnick: what does 'bzr log' show? [02:38] lifeless: it'd just be nice to view the changes in my repo viewer [02:39] lifeless: bzr log shows all revs up to 128 [02:39] including 127 [02:39] ah - it has 126.1.1 [02:39] what happened is that you had two things happen at once [02:40] and you needed to merge to combine them - the 126.1.1 shows the thing that happened outside the 'trunk' [02:41] so is there anyway I can go back and do that? [02:41] the reason I'm so keen to view r127 is that it was a massive commit [02:42] bbiab [02:43] vxnick: well your repository view should be able to show it [02:43] just look at 126.1.1 [02:43] 126.1.1 is the commit prior to the big one though [02:43] 126.1.1 was a single file commit [02:44] hey lifeless, I'm around for a bi [02:44] bit [02:44] jam: hi; just keen to get bbc->production readiness planned [02:44] I'm worried about iter_changes and stacking [02:44] jam: also we need to write our talks [02:44] for next week [02:44] s/for/during/ [02:45] dang, its friday already ... [02:45] yup [02:47] lifeless: slight problem - I've checked-out the repo in a different place and bzr revno is showing as r126 :S [02:47] rather than 128 [02:47] I tried bzr co -r revno:128 (not sure of the syntax) but it said no such revision [02:51] vxnick: that sounds like they are in your checkout only. [02:51] vxnick: if you are happy with how it looks now, do 'bzr push repo' [02:52] where repo is the url you checkout from [02:52] lifeless: any chance we can sort the 126.1.1 or is it stuck like that? [02:52] i.e. get it into its own rev no [02:52] vxnick: its basically stuck like that [02:53] lifeless: ok no probs - i'll push [02:53] it can be rewritten but its getting kinda complex [02:54] lifeless: "pushed up to revision 128" :-) [02:54] anything else or should I be good now? [02:54] should be good [02:54] go to your other checkout and do 'bzr update' to see [02:54] yeah am currently runnig [02:54] works fine [02:54] thanks loads [02:55] I'm glad there's a decent community around here [02:56] no problem [02:58] lifeless: did you just get a new gpg key? [02:58] I guess it is now "(My Canonical long address)" :) [02:58] jam: I added a new signing subkey for a machine [02:58] jam: so 'log DIR' is slow in dev6rr because ... [02:58] so igc, 'log DIR'... I think we are fundamentally approaching it from the wrong direction, simply because that was the easiest for XML formats [02:59] jam: my laptop has it, but that new machine has only it. [02:59] Inventory.filter() is slow [02:59] igc: 'log DIR' is slow because the algorithm is structured to hit every item in the directory each time [02:59] rather than starting with changes [02:59] and it's slow because children is slow [02:59] 'log -v' on 1k revs of mysql is 3s [02:59] log DIR is 1m30s [02:59] O(tree) algorithms are *bad* [03:00] jam: so post-processing the delta will probably work *much* quicker [03:00] igc: From what I can tell, part of the issue is handling 'recursion' [03:00] jam: precisely [03:00] in that if someone gives "DIR" we need to figure out if "some-random-delta-file-id" is part of that DIR [03:00] there are a few ways we can do it [03:01] 1) Change Inventory.filter() for CHKInventory [03:01] jam: I couldn't see how to that faster down at the inventory layer (i.e. iter_entries(dir=X)) [03:01] the size of specific_fileids() is always going to be much smaller and define a smaller subset of the set [03:01] iter_entries_by_dir(dir=X for X in specific_fileids) [03:01] jam: s/always/usually/. Pathological users abound. [03:01] but that still scales poorly [03:02] lifeless: this is a case where optimizing for the common case is probably going to give the best wins, as long as we aren't terribly pathological [03:02] 2) Do 'changes' first, and then filter that after the fact [03:02] technically the path filter can be computed from the parent_id_basename =>file_id map [03:02] jam: oh agreed; I'm just making sure we don't forget that silly things happen [03:02] and can be 'cached' between trees that have the same root hash [03:02] however, that still scales as O(entries_in_dir) [03:03] when O(num_changes) is often ~5-10 [03:03] (on average) [03:03] also! [03:03] remember we're about to change iter_changes [03:03] So I was thinking that if we do a smart inversion of [03:03] this will impact chk delta stuff [03:03] and it may do so helpfully [03:03] for ..., file_id, ... in iter_changes(): [03:03] parents = get_id_path(file_id) [03:04] if file_id or parents in specifice_fileids: [03:04] add [03:04] lifeless: right, because we are looking to include parents of changes, right? [03:04] igc: so I would inline the get_id_path part [03:04] because [03:04] a) You can keep a set of "known_uninteresting" directories [03:04] jam: yes, in an as-yet-un-pinned-down-way [03:05] as well as a set of "known_interesting" ones [03:05] so that you only have to recurse to the root sometimes [03:05] and as changes are likely to be grouped by dirs [03:05] you'll likely get fast culling [03:06] jam: sounds promising [03:08] igc: I *think* you could push some of that down into iter_changes, except you lose any chance to cache info between trees [03:08] as the *tree_shape* information could be cached between trees [03:08] as long as parent_id_basename_root_id (sha1) didn't change [03:08] jam: we could pass a cache in [03:08] lunchtime [03:08] however, by my numbers that only gives... 5:1 hits [03:09] so *something* but unless we added 'delta' support to the cache maintenance, I'm not convinced it saves a whole lot [03:09] (you could have the delta look at the parent_id_basename map changes, and determine what could be kept/discarded, but that takes more thinking.) [03:10] igc: do you feel like that is enough info for you to work on it? [03:10] jam: yes thank-you [03:10] I have a couple of thoughts too [03:10] lifeless: If I'm still here when you get back, I'd be interested in chatting a bit about stacking requirements and GC+CHK [03:10] GC makes stacking 'easy' because it doesn't have deltas [03:10] have you guys considered using the per-file graph to jump back in log DIR? [03:10] but CHK is doubly difficult [03:11] jam: stacking is currently serialiser-locked, I don't see how CHK impacts it [03:11] lifeless: as in finding the recursive set of possible file ids, and then grabbing all of their graphs [03:11] etc [03:11] jam: [recursive set] - no [03:11] lifeless: CHK 'externals' are not easily deduced from just the index [03:11] and they are potentially "deep" [03:11] in that the direct referenced one will reference more [03:11] I mean, in rev Y, under DIR, 5-10 files are changed [03:12] consider only their per-file graphs, and you get 5-10 possible revs to jump to [03:12] lifeless: I don't think you know that in Y-1 another 3 files disjoint were modified [03:12] jam: oh bother [03:12] jam: I really wish we'd had time to do the recursive-change field in inventories; it would solve this trivially [03:13] lifeless: right [03:13] though at the expense of a bit more data churn [03:13] lifeless: and another minor issue: the per-file graphs don't contain delete info yet & log needs to report that [03:14] lifeless: so if your smart fetch requires the complete inventory for a given revision in order to determine the file-ids to fetch [03:14] we only know the chk pages by *walking* them [03:14] igc: indeed [03:14] we can get some of that by the first pass as we transmit data [03:14] but that only gives us a single depth of referenced pages [03:14] igc: we can fix that by including a node at deletes [03:14] so we may need to walk *those* as well, in case of > depth-2 trees [03:15] jam: smart fetch requires a delta, not a inventory [03:15] jam: [once we have the delta patch finished]. CUrrently your 'make xml' hack is in place [03:15] lifeless: ouchie [03:16] lifeless: so GCVF already supports fallback versioned files [03:16] and passes the VF test suite for that [03:16] So the *only* whole I can think of for stacking support [03:16] is how we handle CHK pages [03:16] jam: I'd approach this by a) turning it on and reenabling it, see how it goes [03:17] b) look closely at whether we're going to have showstopper design issues, or things we can tweak to improve [03:17] hole? [03:18] today, I'd say we want the entire CHK tree for edge-revisions in the stacking branch, as this philosophically matches our current 'can get full inventory' rule for them. [03:18] lifeless: well, 99% of all current trees we work in are only going to be depth 2 [03:19] (one root, then leaves, or at most 1 root + 1 internal + 1 leaf) [03:19] but the design is that they can be much deeper [03:19] I'm somewhat concerned that we won't have problems because depth 2 won't trigger bugs [03:19] ideally we can drop that back to 'all CHK page needed to generate a delta of any revision present against its parents' [03:20] jam: I'm really not quite understanding the concern; are you saying fetch won't copy the right data? [03:20] ATM, fetch has 2 passes, right? [03:20] or can't be made to copy it? or will be slow if it does? [03:20] The first pass could inspect the data it wants to transmit [03:20] to determine the data it needs to transmit [03:20] jam: StreamSource can do as many passes as it wants [03:21] except for CHK pages, that might need yet-another pass to get to the actual end [03:21] it generates 1 stream [03:21] StreamSink can, after insertion, say 'I need more data' [03:21] and that will result in a second stream [03:21] It only gets to say that 1 time, right? [03:21] but I guess you're right about stream sending a multi-pass stream [03:21] since we already do that now [03:22] the CHK pages introduced in the revs being pushed should all be included in the first stream, always. [03:22] if the revs are at the edge of the stacking repository, it will ask for the inventories of the adjacent-absent revisions [03:22] StreamSource in that case should provide all the CHK pages of those inventories [03:23] lifeless: so the 'pages introduced' should always be included, I'm wondering if the 'pages referenced' should always be included [03:23] as well as the inventories for adjacent [03:23] though I suppose that should overlap [03:23] I'm not sure it is 100% overlap [03:23] (might be) [03:23] pages referenced-and-not-introduced should be included in adjacent-inventories-full-page-set [03:24] a future improvement would be to have the second stream be 'pages-required-to-delta-against-this-but-not-the-full-closure' - and thats where it gets tricky and is why you are concerned. [03:25] that should be done after basic support is up [03:25] lifeless: right, especially because it depends on the delta algorithm [03:25] I think for fetch we should be only deltaing adjacently [03:25] or within the set being sent [03:29] really lunching now [03:35] lifeless: btw, I think dev6rr fetch just picks 'an' adjacent revision, not *all* adjacent revisions. Though it could certainly do so. [03:35] jam: if we can consolidate the two similar code paths it would do all [03:35] :) [03:39] hmm, regression in ignore:( [03:39] bzr ignore foo, where foo is a versioned directory, and contents of foo showing as unknown === poolie1 is now known as poolie [04:00] a revision object has no reference to its repository [04:00] is this deliberate? [04:01] is it something we care deeply about? I don't think so [04:01] deliberate is harder to answer [04:01] i can't say i've ever found that surprising [04:02] revisions have always seemed pretty atomic in some sense to me, not that much more structured than strings in some sense [04:03] huh, nice repetition hudson [04:03] in some sense [04:09] what's the difference between supports_delta and supports_diff in a log formatter? [04:11] jml: delta is like bzr st, diff is like bzr diff [04:11] (i think) [04:11] ok. that makes sense. [04:11] mwhudson: so, what you were saying earlier about revisions not being more than structured strings [04:12] mwhudson: I get that, but it can go either way wrt having a reference to a repository [04:13] jml: yes [04:13] well, [04:13] no [04:13] jml: i guess what i mean is that you don't go directly from a string to something else [04:13] sure [04:13] the string is often a key into a real object [04:13] you might look up something under a string to find something else [04:13] but you don't go string.object_with_key [04:14] revisions are like that [04:14] *nod* [04:14] but maybe they could also be such that revision.get_parents() worked. [04:14] yeah [04:15] I'm just noticing that I can't use a log formatter to show the author of the second-to-left parent revision of mainline as the author of the mainline revision. [04:20] ah [04:20] the log formatter doesn't get the branch or repo or anything? [04:20] well, i guess there may not be a branch [04:21] mwhudson: no. [04:21] ugh [04:21] mwhudson: I mean, you subclass the log formatter, so you can pass it one yourself [04:22] yeah, but that's pretty icky [04:22] will work for what i guess you're doing :) [04:22] and in the canonical use case, there is a branch [04:25] lifeless: late pong [04:26] spiv: its all there in history ;P [04:26] how is it going basically [04:27] lifeless: I've been taken a little by surprise by fileids_altered_by_revision_ids, when a (stacked, no fallbacks set) repo has say rev-2 but not rev-1, and rev-2 doesn't change any files from rev-1, fileids_altered_by_revision_ids(['rev-2']) still reports rev-1. [04:28] right [04:28] thats the root of the bug in fact [04:28] heres why it occurs: [04:28] without rev-1's inventory, we can't calculate the delta [04:28] so we get everything that is referenced [04:28] not new references [04:29] its why we want rev-1's inventory in the stacking repo [04:30] Yeah, it makes sense (the fulltext inventory clearly says "this file is at version rev-1"), but for some reason I was expecting fileids_al... to incorrectly deduce rev-2 there. [04:30] ah [04:30] :) [04:30] it used to return nothing [04:30] this lead to bugs in fetch where incorrect inventories caused stuff to be dropped [04:30] so we fixed that [04:30] It doesn't really matter which version it reports, so long as it reports something and I can check that it's present. [04:31] i.e. this doesn't break my fix, but it's caused me grief when designing tests. [04:31] if rev1's inventory is there it will report nothing [04:31] if its not there it will report rev1's version, because rev2 doesn't have a version [04:32] ok [04:32] (Also, there are no explicit unit tests for this corner of fileids_al...'s behaviour) [04:32] what do you want to test [04:32] spiv: uhm, there are actually, its just that those tests are pretty much inpenetrable [04:32] That the fix works ;) [04:32] ok [04:32] More specifically, [04:32] less broads [04:34] [re: fileids_al...'s tests, grep didn't find any other than test_fileid_involved.py, and it has no tests that show a revision in the result that wasn't passed as an arg to fileids_al...) [04:34] hmmm, you may be right [04:35] I know I wrote tests when I changed it [04:35] it may be layered [04:37] so - what behaviours do you want to ensure [04:38] 'it works' [04:38] that can be expanded [04:38] are there things that shouldn't happen [04:38] Anyway, I'm testing: simple linear history where [parent inv missing + all texts present -> ok], [parent invs present + new texts present -> ok], [parent inv missing + text missing -> not ok] [04:38] and things that should [04:38] ok [04:38] Also, ghost rev that does not cause missing texts -> ok [04:39] that shouldn't interact badly with fileids_altered [04:39] branchbuilder supports ghosts now [04:39] Ah, handy, I didn't know that. [04:39] I added it for a test [04:40] look at record_snapshot's docstring [04:41] Also, I found I needed to use add_inventory directly on the target repo rather than get/insert_record_stream, because ensuring that I get a single fulltext inventory record was too fiddly with the stream API. [04:43] thats surprising [04:44] I would have expected roughly insert_record_stream(FullTextRecord(get_record_stream(foo, 'topological', True).next())) to Just Work [04:45] Right, I could probably manually assemble a FullTextContentFactory, but that's considerably more complicated than just calling add_inventory. [04:45] true [04:45] add_inventory is fine too [04:46] Yeah. I was a bit reluctant too at first, because it takes the test slightly further away from the way streaming fetch works, but I made peace with the idea fairly quickly :) [04:46] s/too/to/ [04:47] Anyway, I feel that I do understand all the dark corners now, so it's going rapidly now. But right now it's lunch time! [04:48] * spiv -> food [04:48] excellent [04:48] I'm doing pdr stuff [04:48] so just ping if you are able to save me from it at any point [05:01] oh yeah [05:01] jml: https://code.edge.launchpad.net/~lifeless/subunit/autoconf/+merge/6328 is textually large, but code wise tiny [05:01] jml: I'd love a review :) [05:02] lifeless: I might not get around to it for a week or so [05:02] lifeless: but I'll put it on my todo list -- who knows what will happen! [05:03] jml: I'lll nag other people then [05:03] jml: as it will block me [05:03] lifeless: ok. [05:03] jml: or you can opt and and I'll land it as is [05:03] lifeless: I'm basically talks talks talks until next weekend :) [05:04] beamer where art thou? [05:04] jml: basically it moves subunit to use autoconf; this gives the library a good soname and makes it packagable [05:05] ok. [05:05] jml: no python code changes at all; minor changes to the shell tests to support VPATH builds [05:10] spiv: I've checked, build_snapshot in bzr.dev has support for ghosts [05:10] hello there, i'm gettign "Cannot build extension "bzrlib._btree_serializer_c"." [05:11] anyone knows a little bit of insight as to what is wrong? [05:11] there should be more output than that [05:11] it's quite long [05:11] if you can pastebin it somewhere I will look at it [05:17] http://pastebin.com/d2a36e92d [05:18] # [05:18] bzrlib/_btree_serializer_c.c:4:20: error: Python.h: No such file or directory [05:18] # [05:18] that suggests you don't have the python library header files on your system [05:19] you might prefer to use a prebuilt bzr, but if you do want to build bzr yourself you need 'python-dev' or whatever the package is called on your operating system [05:19] or you can run bzr without building the extensions (it can run as pure python) [05:19] i do have that package [05:20] can you do [05:20] ls /usr/include/python2.5/Python.h [05:21] hmm [05:21] not there [05:21] are you running jaunty ? [05:22] debian lenny [05:23] hmm, I think that has 2.5 as defalt [05:23] *default* [05:23] anyhow, you need /usr/include/python2.5/Python.h [05:23] I think its normally in python2.5-dev, which is pulled in by python-dev usually [05:26] sudoed it and it worked [05:26] weird, maybe some permissions are messed up [05:27] thanks! [05:29] no probs [05:31] spiv, lifeless: btw, if you add a FulltextContentFactory, I believe it goes down to '.add_lines()' which can create a delta [05:31] you have to insert a KnitFulltext record if you want to force it to be a full text [05:31] though I believe add_inventory() can also generate a delta [05:32] jam: it won't create a delta if the target repo is missing the parent [05:32] jam: which is the scenario [05:32] jam: the point is to avoid dragging the parent content around by mistake [05:44] -> pdr stuff done [05:45] deep hacking time on check; if anyone wants me SMS or ring [06:12] abentley: if you're around; we used to have code for determining left-hand-distance-to-null; do you happen to recall what we did with it? [06:13] (I'm refactoring Branch.check to take a precalulated graph rather than every branch doing the same thing) [06:20] does bzrlib have a standard way of taking an optional location and turning it into a branch? [06:20] should it? [06:20] EPARSE [06:20] [what talk are you writing btw, and if you're all talk at the moment, consider mailing jam and I] [06:21] lifeless: I think the cost of explaining what I mean is greater than or equal to the cost of figuring it out myself :) [06:21] jml: if you mean 'open_or_init' or something like that, uhm no, And I don't think so [06:22] if you mean something else, maybe, who knows. [06:22] lifeless: I mean more like a command-level thing for saying "just default to the branch that's in the current directory." [06:23] lifeless: but I think that's just if location is None: location = '.' [06:25] talks I'm doing are: Introduction to Twisted; Tour of Launchpad Code; Teach Me Packaging; "Your Code Sucks and I Hate You" [06:26] lifeless: and whatever help I can spare for your & jam's talk [06:31] jml: we're doing two :P [06:31] so please pluralise :) [06:31] jml: anyhoo, thats Branch.open_containing [06:31] lifeless: the one I submitted the proposal for :) [06:31] and yes, if location is None: location='.' [06:32] jml: la-la-la-la [08:03] * igc celebrates completing his just-in-time hr paperwork by starting his many-weeks-late expenses paperwork [08:09] igc: :) [08:09] igc: I know the feeling! [08:10] spiv: does that mean you've remembered my "review me" invitiation? :-) [08:13] igc: yes :) [08:13] igc: (doing those now, in fact) [08:22] luks: ping [08:22] pong [08:23] luks: I'd like to make Gary admin of qbzr google group. He's most active these weeks [08:23] sure, no objections to that [08:23] ok [09:28] * igc packs it in for the day [09:28] have a good weekend all === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [12:46] lifeless: It's on Graph. [12:47] lifeless: Graph.find_distance_to_null [12:49] abentley: thanks === dahoste|away is now known as dahoste === abentley1 is now known as abentley === nevans1 is now known as nevans === pindonga is now known as ricardokirkner === BjornT_ is now known as BjornT [14:53] how do I create a working tree for something that doesnt have one ? [14:53] Mez, bzr co . [15:03] hi. is there any way to have a bzr repo be pushed to svn, and keep each commit author? (I mean, every team member commits to a central bzr repo, and from there one person pushes to a svn repo... each individual commit.. retains authorship, or are all commits re-owned by the person who effectively pushes to svn?) [15:07] jelmer: I've packaged subunit [15:07] jelmer: if you want to change the maintainer field and do the upload to close your bug in debian, that would be fine [15:08] ricardokirkner: bzr will add metadata saying the original author, but I'm not sure whether svn looks ast that or not; I suspect it doesn't. [15:09] lifeless, it uses svn properties for that right? [15:10] I had some issues with that... its not very nice from the svn point of view to have a lot of properties set/reset on each commit [15:26] ricardokirkner: it uses revision properties if you have a new enough version of svn (svn >= 1.5) [15:26] lifeless: ah, nice [15:27] lifeless: care to be co-maintainer ? [15:27] jelmer: sure [15:27] jelmer, and if you have a lesser version? what does it use? [15:28] ricardokirkner: file properties [15:28] jelmer, sorry I am missing something here.. [15:29] svn:ignore is a svn property... this is a revision property? [15:29] if so, what is a file property? === dereine is now known as dereine[OFF] [15:32] ricardokirkner: svn:ignore is a file property [15:32] ricardokirkner: revision properties are generally not visible for the user [15:32] jelmer: https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases revno 70 [15:33] does bzr require repackaging like git if it gets big? [15:34] savvas: bzr automatically packs as needed [15:34] you can manually trigger a pack if you have reason to, but its not something we recommend [15:34] lifeless: whu [15:34] lifeless: what sort of fancy branch is that? [15:34] jelmer: package branch [15:35] it's ok, I like "automagic" :) [15:35] halt() [15:35] gnight [15:36] How can I list the files changes in a commit? [15:37] *changed [15:37] Odd_Bloke, -v [15:38] Odd_Bloke: bzr st -c revno [15:38] Odd_Bloke: log -v -c revno [15:38] bzr diff -c revno | diffstat [15:38] (really gone now) [15:38] lifeless: ah, interesting [15:38] lifeless: 'night [15:39] jelmer: oh [15:39] one more thing [15:39] there is a tarball [15:39] lifeless: and appropriately set debian/watch ? :-) [15:39] no [15:39] watch can't do bzr well [15:39] https://edge.launchpad.net/~subunit/+archive/ppa [15:39] lifeless: it can deal with tarballs though :-) [15:40] grab the -65 tarball from there [15:40] lifeless: btw, how do I register new package branches? [15:40] jelmer: yes, but I'm not making official release tarballs at this point [15:40] jelmer: usual way, push to em [15:40] lifeless: ah, k [15:40] lifeless: but mirrorred branches? There's no register link [15:40] the tarball of -65 is a snapshot, you could make your own but nicer to reuse [15:41] jelmer: I don't know that you can, or that it has even been considered [15:41] jelmer: not currently possible to have a mirrored package branch [15:41] jelmer: anyhow, lp is fast now [15:42] lifeless: Yeah, but I'd like to register the branches on bzr.debian.org [15:42] good use case [15:42] jelmer: ^ [15:42] as packaging branches seem to be supported for debian in lp too [15:42] james_w: ^ [15:42] ciao [15:43] they are [15:43] I think the immediate problem is that the form for registering just has a space for "Project:" [15:43] so it can't be used [15:43] I don't know if there are more fundamental issues [15:46] Is any special work required for a bzr 'head' branch? [15:46] (in a configuration sense) [15:47] james_w: should I file a bug? [15:47] Kamping_Kaiser: you might like to set "append_revisions_only", but other than that there isn't much [15:48] that's not required, it just enforces something that most people expect for a "head" branch [15:48] jelmer: bug 347755 I think [15:48] Launchpad bug 347755 in launchpad-code "No UI for registering package branches" [Medium,Triaged] https://launchpad.net/bugs/347755 [15:48] james_w, thanks. [15:49] whatever is a head branch? [15:49] james_w: thanks [15:49] LarstiQ, something I link to on a public site as a 'known working' rcs snapshot [16:11] Kamping_Kaiser: ah ok, so not trunk if that isn't guaranteed to be known working [16:12] LarstiQ, true, the wording on my part was bad. [16:40] I have a noob question: I just did a merge and have some conflicts. I understand the .OTHER files are the one from the branch I am merging into the branch I am working on. Could someone clarify what is the .BASE and .THIS? [16:42] Can anyone tell me how to get the Nautilus integration going in bzr-gtk? [16:42] * awilkins installs the GNOME-python binding [16:43] * awilkins discovers they are already there [16:44] gcerquant: THIS is from the tree you merged in to [16:44] gcerquant: BASE is the common ancestor === dereine[OFF] is now known as dereine [16:45] But I branched a copy, worked on it, and then merged it back [16:45] shouldn't THIS and BASE be the same ? [16:46] They won't be because if THIS and BASE were the same, there would be no conflict [16:46] Which OS are you using? [16:47] Mac [16:47] ok, I get it [16:47] * awilkins doesn't know much about 3-way merge editors for Mac [16:47] gcerquant: changesapp.com is good [16:47] I forgot I did a revert on the main branch [16:47] I was going to suggest it might be easier if you open it in meld / TortoiseMerge / stuff [16:47] Changes.app is awesome, yes [16:48] thanks for your help [16:48] gcerquant: you can also integrate it with bzr if you haven't already :) [16:48] I did :) [16:49] with this alias: diff = diff --using=chdiff [16:49] anything more efficient? [16:50] gcerquant: add it your .bashrc file [16:50] sorry [16:50] ignore that [16:51] np [16:51] gcerquant: ALIASES] [16:51] chdiff = diff --using chdiff --diff-options --wait [16:51] gcerquant: in ~/.bazaar/bazaar.conf [16:51] [ALIASES] on the line above it [16:51] yep, that's what I have [16:52] except for the --wait options [16:52] what does it change? [16:52] --diff-options isn't passed to chdiff in that case is it? [16:52] gcerquant: http://pastie.org/472261 [16:52] gcerquant: it means you can use "bzr chdiff" [16:53] gcerquant: --wait means bzr halts until changes.app is quit [16:53] but unless I miss something, I prefer it without the wait [16:53] fair enough :) [16:54] so I can open a diff, look at it in Changes, maybe do an other commands in my term (bzr conflicts, or just ls...) [16:54] yeah [16:54] I see your point [16:54] I think I just copied/pasted the whole thing from the changes website [16:54] it wasn't a conscious decision [16:54] :) [16:55] I had done a script for Changes in svn to edit the files in place, with the right name. So I could edit and save within Changes, and be done [16:55] might adapt it for bzr [16:56] vxnick, what do you develop for Mac? [16:56] gcerquant: I just do web stuff - LAMP type stuff [16:57] Here's a thought - could we use an "ignored" status change kind ; e.g. - you've got a file that you want to stop tracking, the only way being to `bzr rm --keep foo` and then `bzr ignore foo` ; unfortunately when others pull your revision this will delete their local copy of the file instead of just ignoring it. [16:59] In other words, would tracking the use of `rm` vs `rm --keep` as separate types of change be useful (for me, yes). [16:59] awilkins: I think that sounds sensible [17:00] prevention is better than the cure ;) [17:00] Specific example, using Maven with the eclipse plugin ; it generates .project files ; someone has added these to version control in error. [17:00] I want to remove and ignore them without spoiling his day. [17:00] Ok, he can just regenerate them :-) [17:04] http://paste.lisp.org/display/79905 [17:04] It looks like my merge produce a conflict because I removed a new line. [17:04] Is this possible? [17:04] Is there an option for that? [17:48] I. Just. Love. Bazaar. [17:49] .oO( "Get a roooom!" ) ;) [17:49] :-p [17:50] I love it too - can't bring myself to use anything else :P === dahoste is now known as dahoste|away [17:50] I have check other system, but bzr has the right approach for so many things it's a no-brainer decision [17:51] yeah [17:51] I *love* bzr uncommit ;) [17:51] can you unrevert as well? [17:52] I was once burned by this with svn (used an newly alias the wrong way. alias was deleted just after I finished crying) [17:53] revert saves a backup copy of the modified files in the local checkout. I don't know if it has an automatic "unrevert" command, but you can just mv foo.c.~1~ foo.c [17:53] Though usually I use vimdiff between them [17:54] there is no unrevert [17:54] one day... [17:57] jelmer: are you around? [17:57] hi bialix [17:57] hi james_w [18:00] there is question about conversion from svn: http://stackoverflow.com/questions/839683/how-to-migrate-from-a-complicated-subversion-repository-to-a-distributed-version [18:02] jelmer: ^^ [18:06] bialix: answered [18:08] thx === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [19:47] Haha, subunit switched from scons to autoconf *one day* after i installed scons specifically for it. :P [19:47] make it switch back! [19:50] Since I'm just using it for Python, I don't even need to compile it though. [20:29] ronny: try again. I note http://paste.pocoo.org/show/116024/ doesn't include releases like 1.14.1 [20:30] LarstiQ: yes, its a bit incomplete, its just a pretty generic guess [20:30] * LarstiQ nods [20:30] ronny: you could try parsing http://pypi.python.org/simple/bzr or something like that === kiko is now known as kiko-afk [20:31] LarstiQ: i will probably put dealing with that in an actual py.test extension using the xmlrpc api or some code i worte for the pida plugin updates [20:32] * LarstiQ might want some code like that too [20:32] ronny: anyway, for the releases in that script, they should now work :) [20:33] LarstiQ: i just wrote a scanner for the simple http pypi [20:33] its pretty nasty and just has some regex [20:33] it works semilar to things like easy_install and pip [20:33] #its just less smart [20:34] right [20:34] * LarstiQ has read the easy_install code [20:34] that's actually how I got to know about /simple/ [20:35] i hope you didnt cry in tears of blood [20:35] only a little bit [20:35] reading code by pje is a #1 health danger [20:35] well, luckyly hes now a self-refactoring guru and wont fuck up python any more [20:37] he has had some good ideas tough [20:38] mainly thinking of wsgi here === beuno_ is now known as beuno [20:45] quick ? - I want to look at a file from December in my bzr repo, and then go back to today's version [20:45] possible? [20:47] yam: bzr cat -r XXX file [20:47] or bzr revert -r XXX file; bzr revert file [20:51] * LarstiQ thought yam was talking to himself [20:51] jam: how are you doing? [20:51] LarstiQ: I'm doing pretty good. how about you? [20:51] Sorry, not talking to myself, trying it out - works! [20:52] yam: I meant you and jam's nicks being very similar [20:52] thank you kindly - I knew that IRC would be the answer I needed [20:52] jam: feeling a bit ground by work and studying, but otherwise not unhappy [20:53] LarstiQ: yam jam sounds pretty good, actually [21:03] how do i remove a pending merge tips? [21:03] andriijas: bzr revert --forget-merges [21:04] thx [21:26] HI everyone. I am seeing this bug https://bugs.launchpad.net/bzr-svn/+bug/373726. Has anyone else seen this, is there a nifty workaround? [21:26] Ubuntu bug 373726 in bzr-svn "Error importing svn repository" [Undecided,New] [21:34] rellis_: I haven't seen that before, but it violates an invariant of bzr, I wonder how you got to that point. [21:35] hmm, I can think of one way to do that. [21:36] Hi, I guess I am missing something very stupid in the docs. But how do you init a branch with an existing branch info? [21:36] rellis_: hi [21:36] *init a new [21:37] rellis_: I think this might be a bug that's fixed in 0.5.4, is there any chance you can try with that? [21:37] rellis_: Is this repo publicly accessible? [21:41] psykidellic: do you want a copy of the other branch? `bzr branch old new` [21:41] psykidellic: if not, it is unclear to me what effect you're after [21:55] LarstiQ: We have a branch at: /bzr/project/branch..... . I created a new repo using: init-repo. I want to import project/brnach with all its history to the new repo. [21:55] *branch [21:56] psykidellic: if it's one branch, just `bzr branch` it. [21:56] LarstiQ: Alright. And it will be added to repository when I push it first time. [21:56] psykidellic: if I understand you correctly as having added a repository after deciding a standalone branch wasn't the way to go, `bzr reconfigure` might be handy. [21:57] LarstiQ: Exactly :) [21:57] psykidellic: that's fine too [21:57] LarstiQ: You read my mind! [21:57] psykidellic: specifically, `bzr reconfigure --use-shared` would have been of help to you [21:58] I have not yet branched to new one. I will look into reconfigure now. [21:58] Thanks. [21:58] * psykidellic goes back to docs. === dereine is now known as dereine[OFF] [22:30] jelmer: bah, packaging fail. I'm fixing === beuno_ is now known as beuno [23:00] jelmer: all fixed now [23:00] missing pkg-config build-dep [23:00] Peng_: its packaged now [23:00] launchpad.net/~subunit/+archive/ppa [23:18] Can anyone explain why I can't push any repo? I constantly get "Target directory xx already exists [...]" or "Generic path error" [23:19] Or permission denied errors are common too. [23:22] xlax: are you pushing to launchpad? [23:23] lifeless: no, I'm trying my own (s)ftp solution. [23:24] Because I need the project to be private, and I didn't see any option for that in launchpad. [23:24] hi all. is there a pure CLI way to achieve per-file commit messages? I'm using bzr on a headless box [23:24] launchpad cann host private projects, but its for a fee. [23:25] anyhow - Target directory xx already exists - means you've made a directory rather than having bzr push to a new directory. === dereine[OFF] is now known as dereine [23:25] either pass --use-existing-dir to push, or don't make the branch directories by hand [23:25] the GPE I'd need to see a backtrace of - there will be one in ~/.bzr.log [23:25] lifeless: using --use-existing-dir will get me the GPE ^^ [23:25] FurnaceBoy: I don't think so [23:26] lifeless, hm ok, thanks. just on a project whose policy encourages them. [23:26] lifeless: Oh, nice. I've already set up running it from source, so I'm not sure I'll bother with the PPA though. Plus I don't run Jaunty. [23:26] FurnaceBoy: you could use the python interface, or write aplugin to support it. [23:26] FurnaceBoy: mainly a UI problem, its a lot easier to write that sort of thing in a gui [23:26] lifeless, interesting! [23:26] lifeless, I'll think about that. thankyou [23:26] FurnaceBoy: feel free to file a bug saying you'd like it in the CLI [23:27] Peng_: lenny? [23:27] lifeless, is the main Bzr on lp? [23:27] lifeless: Hardy. Plus Gutsy. :X [23:27] (I'll upgrade soon i swear!) [23:27] FurnaceBoy: http://launchpad.net/bzr [23:27] Peng_: :) [23:28] lifeless, ok, so if i wanted to write such a plugin, would i branch to do it? (sorry i'm new to bzr/lp) [23:28] Peng_: hopefully jkakar will do the autoppa magic and I can upload gutsy and hardy too [23:28] FurnaceBoy: well a plugin is a new separate project; so you'd start a new project, which would be a bzr plugin [23:28] lifeless: Is creating gutsy packages even allowed anymore? It's not supported... [23:28] FurnaceBoy: or you could just patch bzr itself; it might be easier in this particular case:- for that you would branch bzr, yes. [23:29] Peng_: not sure. [23:29] hardy is [23:29] Hmm. It seems my host has an odd way of calling its directories... [23:29] lifeless: AutoPPA magic for Bazaar? [23:29] jkakar: subunit [23:29] jkakar: (hi) [23:29] lifeless: Ah, okay, yeah, I should finish that since it's already half done. Hi! :) [23:30] jkakar: I've done C/python/tools/C-dev packages [23:30] lifeless: I noticed that. I'll see if I can review/integrate your changes sometime this weekend. [23:30] jkakar: they're built https://edge.launchpad.net/~subunit/+archive/ppa and code is https://code.edge.launchpad.net/~subunit/ubuntu/jaunty/subunit/releases [23:31] lifeless: btw, the last entry in changelog is by robertc@lifelessdesktop [23:31] debian/changelog? [23:31] meh, I haven't set DEBFULLNAME and DEBEMAIL yet on that machine [23:32] lifeless: ah [23:32] my desktop went bang [23:32] I have a new i7 920 :) [23:32] lifeless: also, any chance you can use 0.0.1~bzr65 for the upstream version? That way bzr-builddeb can Do The Right thing at some point === zirpu is now known as zirpu-away [23:33] lifeless: what's an i7 ? [23:33] 4-core, 8 hyperthreadedvcpu's goodness [23:33] lifeless: nice [23:33] intels current gamer/workstation cpu [23:34] jelmer: I used - deliberately === zirpu-away is now known as zirpu [23:34] lifeless: why the - ? [23:34] jelmer: its an upstream release [23:34] not on the path to 0.0.1, after 0.0.1 [23:35] we could use 0.0.2~bzr65 if we wanted [23:35] lifeless: so it's actually 0.0.1 ? or just a snapshot after 0.0.1 ? [23:35] the latter [23:35] lifeless: what about 0.0.1+bzr65 ? [23:35] I guess we could also get bzr-builddeb to support something like 0.0.1-bzr65 though [23:35] bzr-builddeb should support it [23:36] in terms of parsing etc, its legit [23:36] lifeless: it might be confusing for native packages though [23:36] no, if foo-x-y, -y is debian revision, -x is part of upstream version [23:37] jkakar: overview is 'used autoconf to get a soname, and after that its stock debhelper magic mostly' [23:37] jkakar: the thing that you could do that would be nice is get it working with autoppa for future release builds [23:37] lifeless: what I mean is that it makes parsing the version string harder for bzr-builddeb [23:38] jelmer: it should be getting parsed by python-dpkg anyhow ;) [23:38] jelmer: which DTRT [23:38] if it does make it harder, well I'm not married to this [23:38] python-apt, but yeah [23:39] hi :) [23:39] james_w: I went with -f on autoreconf [23:39] it should work with two -, but is currently broken, fixed in the 2.1 branch [23:39] datestamps and patches, eww. [23:39] lifeless: cool [23:39] plus, it doesn't care if you create a native package with - in it [23:39] lifeless: Cool, that shouldn't be hard. [23:40] hi jkakar [23:40] Heya james_w! :) [23:40] jkakar: did you know that launchpad will soon support uploads with a target of "hardy intrepid jaunty"? [23:40] jkakar: I'd like to keep two packaging branches. One 'official' this-is-packaged-for-$distro [debian with flow-down to ubuntu for now], and one 'upstream' this-is-ppa-magic. [23:41] jkakar: the ppa one should descend from the official one [23:41] lifeless: Cool, that makes sense. [23:41] james_w: awesome [23:41] james_w: I didn't, no. That sounds pretty awesome. [23:41] yeah, it removes the simple case that autoppa solves [23:42] then you should just write your package so the same source works on multiple distributions :-) [23:42] james_w: that's awesome [23:42] james_w: Well, sort of. That's only half of the case AutoPPA solves--the other half is providing some simple templating so that slightly different control files and such can be used for each build. [23:42] also, you two may be interested in https://launchpad.net/bzr-builder that I wrote [23:43] jkakar: yeah, but that's rarely required, though can often be nice to have [23:43] james_w: Really? I probably just don't know enough about packaging, but that seems to be required for every single project I've packaged (which is like 4 things). [23:44] james_w: you've reinvented config-manager ;) [23:44] james_w: For example, on dapper my Python libraries need to Build-Depends on python-support, whereas on newer releases they need to Build-Depends on python-central. [23:44] james_w: The same kind of problem crops up when you need to depend on version 1.1 of libfoo on dapper and 1.2 on hardy. [23:44] lifeless: yeah [23:45] james_w: Anyway, I really hope it is rarely needed... it'd be great for AutoPPA to be killable. [23:45] jkakar: yeah, Build-Depends is the main case. Depends you can do from within the package [23:45] python-central isn't something you can do with an "|" though, unless you are really sneaky [23:46] Would it make sense for the SMP test stuff to use the multiprocessing module? Nose does, Or So I Heard. [23:46] Build-Depends: package-that-only-exists-in-dapper | python-central [23:46] Peng_: no [23:47] Peng_: we want full isolation ;) [23:47] so http://bazaar.launchpad.net/~dailydebs-team/bzr-builder/cookbook/annotate/head%3A/bzr/jaunty.recipe is what controls what is uploaded to the jaunty nightly PPA now [23:47] lifeless: the plan is apparently to integrate this with launchpad [23:48] back in a bit [23:48] james_w: what's advantage of bzr-builder and nested trees (when they land..) [23:48] james_w: ? [23:48] lifeless: I don't know what that means, but okay. :D [23:48] * Peng_ doesn't know a thing about multiprocessing. [23:49] jelmer: I don't know how it will work with nested trees, it will probably do a join there I guess [23:49] jelmer: I just throw away the created tree at the moment, so I don't really care [23:49] it does mean that it can't use bzr-builddeb currently, which nested trees would allow us to do === dereine is now known as dereine[OFF] [23:50] lifeless: oh, I also tested a larger package earlier. A chunk of nautilus was 2 minutes to branch, 30 seconds to apt-get [23:59] james_w: not a great ratio [23:59] james_w: but better than the past