=== Ursinha is now known as Ursinha-afk [02:16] is there a 'bzr st --no-ignore' or equivalent? [02:26] glyph, maybe bzr ls --ignored? [02:26] glyph: there's the separate 'bzr ignored', but I guess you're after what bzr thinks of all files in a given directory? [02:28] (if so, 'bzr ls' with various flags is probably the way to go) [02:29] glyph: Also, '--no-ignore' is pretty much what bzr st already does: show no ignored files ;) [02:31] spiv: "no ignores" not "no ignored" :) [02:31] spiv: I want a complete enumeration of all files, with none of them ignored, to do something programmatic (in a shell script) to a bzr working tree. [02:32] glyph: bzr ls -iVuR, perhaps with added -v [02:32] And -0 [02:33] What's the something, out of interest? [02:33] huh. What's 'V' mean in that output? [02:33] spiv: revert for reals [02:34] spiv: an operation which, curiously, no version control system implements [02:37] glyph: 'bzr revert && bzr clean-tree --detritus'? [02:37] spiv: <3 [02:38] :) [02:38] nope, still doesn't quite work [02:38] it doesn't delete '.moved' directories, apparently. [02:38] oh wait, no, it works [02:38] I just wanted 'bzr clean-tree --unknown --detritus --force' [02:39] (FWIW, the 'V' in that output means 'versioned', I think) [02:39] (not that you care now :) [02:39] wait no... 'bzr clean-tree --ignored --unknown --detritus --force' [02:39] why isn't that the default [02:39] you could make the default behavior be invoked via 'bzr clean-tree --not-really' [02:40] By default it deletes unknowns. [02:40] While leaving potentially valuable ignored files. [02:41] Arch had a sometimes useful distinction between 'junk' (always safe to delete) and 'precious' (not versioned, but don't delete automatically) [02:42] I occasionally wish we'd kept that, although I think probably that level of complexity probably does users more harm than good. [02:44] And of course no categorisation is ever perfect: sure .pyc files are almost always junk or explicitly versioned, but maybe you don't want your vcs to randomly delete .o files that are expensive to rebuild. [02:44] Except when you do... [02:45] Anyway, I'm glad I've saved you from some shell scripting :) [02:45] * spiv -> lunch [02:45] hrm [02:45] you may have saved me even more than you thought [02:45] does this work for svn too? [02:46] Probably! [02:46] Haha it does [02:46] _rad_ [02:48] oh crud, except there _are_ like 2 dotfiles I want to not delete [02:55] glyph: easy! [02:56] Just copy those files to /tmp and back :P [03:04] glyph: actually, if you want to be slightly cunning, [03:04] glyph: 'bzr revert; bzr add .dotfile1 .dotfile2; bzr clean-tree --yadda-yadda; bzr rm --keep .dotfile1 .dotfile2' [03:05] spiv: Cute. [03:05] There's no point doing the add before the revert, of course :) [03:05] spiv: I already implemented the other thing, but I might switch to that. [03:06] (The --keep is redundant in this case too, but explicitness and paranoia doesn't hurt) [03:10] spiv: you forgot the last 'bzr revert', too ;) [03:28] hi all... quick question [03:28] if I do bzr checkout URL [03:29] or I do bzr branch URL wd; cd wd; bzr bind URL [03:29] it seems to have the same effect [03:29] am I understanding that right? [03:29] change the first version to bzr checkout URL wd [03:36] spundun: Yes. [03:36] spundun: 'bzr checkout' is an alias for creating a bound branch to make it easier on people who are familiar only with svn. [03:37] If you just s/bzr/svn in your commandlines, everything basically works if you don't think too hard about it :) [03:37] ah, ok [03:39] I find the concept weird that I create a branch using bzr branch URL, and then within that branch I can just do bzr push URL, then I'm not reall a branch anymore, I'm the trunk :/ [03:40] by I, I mean my branch [03:40] spundun: But it is a branch: if you commit to it, it won't get committed to trunk. You could push it somewhere else on the server, if you didn't want to push those revisions to trunk. [03:41] yes, I get that. But somehow in my mind, I shouldn't be able to push my branch back to the trunk, I should have to merge it or something... [03:41] spundun: consider: bzr get ...:.../trunk; cd trunk; hack hack hack; cd ../; mv trunk my-feature-branch; bzr get ...:.../trunk; cd trunk; bzr merge ../my-feature-branch [03:42] ok [03:42] I guess the more I think about it, the more I'll get used to the idea [03:42] or something like that [03:44] thanks glyph [03:45] spundun: another way to think of it is that initially, a branch is a perfect copy of the thing it's a branch of. you can push/pull between them to re-synchronize them, assuming they haven't diverged. A merge is only necessary to resolve the conflict that occurs when two branches go in two different directions. [03:45] trunk isn't "special", it's just a branch in a particular place that you've socially agreed is important to a project. [03:46] right, ok === jdobrien_ is now known as webm0nk3y [08:08] morning all [08:08] oops, morning jam et all ;) [08:09] I thought it was "et al" [08:09] jam: do you know how doc.bazaar.canonical.com scripts are handled ? [08:09] argh, yes, it *is* et al [08:09] thinko between english, french and latin ;) [08:09] Just blame it on a typo. We'll all believe you :p [08:10] hehe [08:10] are 'al' and 'all' pronounced the same in english ? [08:10] no, latter is more like awl [08:10] Not out of my mouth.. [08:11] But 'al' isn't English, so it's a trick question, really... [08:11] it's a (short) name ; [08:11] ) [08:11] bob2: I've always pronounced "et al" as in "pet" "all" [08:11] And I agree more like "awl" [08:11] doesn't mean I pronounce it correctly [08:11] hm, I say et al(lan) [08:12] possibly people are too polite to correct me ;p [08:12] http://www.thefreedictionary.com/et+al. [08:12] says it is supposed to be "et alii" [08:12] or et alia [08:12] let's add some confusion: 'etal', in french, is where butler cut the meat ;) [08:12] I have even less idea how to pronounce et alli! [08:13] bob2: probably like Italy ;) [08:13] haha === weigon_ is now known as weigon [09:05] mass_import.py up to 812M resident memory, "something" is leaking or python is *really* bad to manage its heap [09:05] 'manage'. lol. [09:05] vila: 812MB for the driving script seems pretty excessive [09:05] in other news nexuiz-data is still happily running at 100% CPU without producing any data in its log :-/ [09:05] jam: right, even 100M would seem excessive... [09:06] lifeless: was the joke targeted at python or at my poor english (I guess the former but just checking) ? [09:06] vila: python, as I understood it [09:06] /wave lifeless [09:06] python [09:07] hai :) [09:07] I can't remember if mass_import was already consuming that much memory when running for weeks before my driver changes... [09:08] jam: any idea about poking at a running python script with meliae ? [09:09] vila: if you can get a pdb console, you can get in with meliae [09:09] I think there are some gdb tricks you can pull ,but none that I really know [09:09] k, thanks [09:09] I think Andrew mentioned using gdb to interrupt, then set trap at the trace function [09:10] and then install pdb at that point [09:10] that way you know you aren't interrupting the middle of a python OP code, etc. [09:10] I think we should just kill this import then and try to reproduce the issue locally [09:10] spiv^^? [09:10] vila: you mean nexuis? [09:10] yup [09:10] if you had console access, bzr already installes SIGQUIT => pdb [09:10] but I don't think you have console access to the builder process [09:11] given it has been spawned from a cron script, I doubt I can get console access yes [09:12] the disturbing fact is that the log file hints that we are in the middle of a bzr operation [09:14] a commit [09:15] vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log. [09:15] 10 days to process a commit is probably considered excessive too :) [09:15] It wouldn't be hard to create if you think it would be helpful [09:15] vila: we may be inefficient, but 10 days is a little rediculuous [09:16] I would say 1 hr is max, even for nexuis-data [09:16] oh, sorry, I've been slightly exaggerating, it's 99% CPU not 100 [09:25] Oh, shucks, you made a new release... [09:26] vila: well in that case, it is clearly not blocked :) [09:29] jam: :) [09:29] fullermd: yeah, by the way, any hint about why bzr-duilder is packaged for FreeBSD ? [09:30] 'cuz C-S packaged it. [09:30] * fullermd glances at logs. [09:30] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/149891 [09:30] * vila has no idea who Control-Super is... [09:31] Better than Meta-Super, that guy is a jerk [09:31] I'm pretty sure it requires some debian dependencies... [09:32] if not Ubuntu dependencies for that matter [09:32] jam: He recently escaped [09:32] LeoNerd: ha ha [09:32] using an alternate exit ? [09:33] . o O (Slowly but inexorably emacs progresses on all fronts ;) [09:33] If you're all through bucking around... [09:34] Sawhorse Saw"horse`, n. [09:34] A kind of rack, shaped like a double St. Andrew's cross, on [09:34] which sticks of wood are laid for sawing by hand; -- called [09:34] also buck, and sawbuck. [09:34] [1913 Webster] [09:34] I'm so much informed now :( [09:34] no idea about what a *single* St Andrew's cross is... [09:35] It's half of a double St. Andrew's cross. [09:36] interesting google images results... http://www.google.com/search?client=ubuntu&channel=fs&q=St.+Andrew%27s+cross&ie=utf-8&oe=utf-8 [09:38] I meant the union jack flag origin of course.. [09:40] adding double to the search terms amazingly returns images with... two crosses... how smart... NOT ! [09:40] * fullermd declines to enquire into where vila's mind wanders... [09:41] 'double rainbow' [10:06] what with the old mails spam from lists.ubuntu.com ? [10:27] morning [10:35] _o/ [10:39] _o/ high five [10:40] you'll be relieved to know that i don't need any help today, everything is working nicely :) [10:40] yeah ! [10:40] hopefully i'm finished with being a pain for now [10:41] hehe, you're not a pain, this channel is here to provide help ;D [10:41] and very helpful it is :) [10:42] by the way, my implementation is for http://www.codebasehq.com/ [10:43] why doesn't it mention bzr then :-p [10:43] because it's not ready yet [10:43] good, better than the opposite :) [10:43] we're making a bunch of changes, some of which are announced [10:44] bzr support is not announced, just going to surprise people with it [10:44] plus i wanted to be sure it was going to work [11:07] jelmer_: I saw your email to ubuntu-devel about showing authors [11:08] jml: I've heard the same concern Dave come up a couple of times before. What do you think? [11:09] jelmer_: It reminded me of things I've wanted to do with bzr-stats [11:09] jelmer_: get # of landings rather than # of commits. [11:10] jelmer_: and it would make 'bzr log' way more useful for PQM-managed projects [11:10] jml: Yeah, indeed [11:11] hmm. [11:11] I wonder how interesting it would be to do it in a plugin [11:12] jelmer_: fwiw, I'd propose this output: http://paste.ubuntu.com/578777/ [11:13] jml: I think we should have all the magic in place to do it in a plugin [11:13] "bzr log --format=boo" [11:14] that would be an interesting experiment [11:16] maxb: Do you have any thoughts on how we should deal with the dh_python2 transition ? [11:16] maxb: I guess we could either create separate recipes for the older distro series, or patch all of them to avoid dh_python2. [11:17] maxb: I'd prefer doing the first, otherwise we'll end up doing the patching forever. [11:17] jml, jelmer: Are you talking about adding authors at commit time or extracting them at log time ? [11:17] vila: extracting at log time [11:18] as jelmer mentioned there are perfs issues (so far) and in the context of pqm, I think adding the authors at commit time would make far more sense no ? [11:19] vila: I think that would use up precious space in the revision text for some projects, and it wouldn't help with historical and foreign data [11:20] if it's too much of an issue I think a cache would be the best approach [11:21] hmm [11:23] jelmer_: I was talking about *always* adding authors, only for projects that want it (and I was thinking plugin there, not core) [11:24] s/was/*wasn't*/ [11:24] ! [11:24] vila: if you have -n0, then you have the information easily available [11:25] sure, I thought the issue was to *not* use -n0 nor the implied perf penalty [11:25] vila: without it, perf is going to suck quite a bit more, in semi-common cases [11:25] and ISTR that adding author in pqm context was mentioned in the past too [11:26] determining non-common ancestors is pretty hard [11:26] and doing it over-and-over again for each rev is pretty bad [11:26] yeah but one day we'll have to fix that once and for all [11:29] vila: could you do that tomorrow? [11:30] it's on my TODO list, but pretty much at the bottom unfortunately [11:31] I just find it annoying that we keep spending time on workarounds :( [11:33] jelmer_: I've not thought about it - I'm planning to study the situation and form an opinion over the weekend [11:33] maxb: ok, I'll hold off for a bit then [11:53] jam: Did you see my followup to https://code.launchpad.net/~jelmer/bzr-email/drop-pre-0.15/+merge/49628 ? [11:53] jelmer_: approved [11:54] jam: Thanks [11:54] I did see it, but just didn't have anything else to add. "approve of the rest" covered my feelings, though it wasn't explicit [11:56] Do people think that branching a working tree at a given revision should branch from that revision even if it's not the tip of the branch for that working tree? [11:56] jam: ah, ok [11:57] awilkins: That's a tricky one [11:57] e.g. bzr update -r N # where N is less than P which is tip revision ; bzr switch -b newbranch ; bzr revno # emits P not N [11:57] awilkins: It would be useful to warn the user in that situation. [11:58] awilinks: That said, I think it might require opening the dirstate file to figure out the revno of the working tree [11:58] jelmer_, A valid story would be - I bisected to find a bug, now I want to branch the revision that introduced it to fix it ala DaggyFixes [11:59] jelmer_, Probably, I know that qlog does something to work out the current revision because it marks it in the log [12:00] jelmer_, For switch -b it must be doing it anyway because it merges the new branch (at HEAD) to the one you have so you end up with a working tree of HEAD [12:01] awilkins: Yeah, but not for e.g. "bzr branch " [12:02] jelmer_, No, I don't think that is intuitive [12:02] awilkins: So, I think it makes sense to warn the user if they try to branch from a location where there are both a working tree and a branch with the tip out of sync [12:02] jelmer_, I think I'm really only thinking about local branches and lightweight checkouts [12:03] awilkins: I don't think we should be inconsistent in the way we treat local and remote branches [12:04] jelmer_, I agree that's a useful warning ; I found the idea that once I had updated my lw checkout to a particular revision that switch -b would branch that revision to be intuitive and the result (branching the HEAD of the branch bound to the checkout) to be understandable but disappointing [12:05] awilkins: Is there a particular reason why you're only switching your working tree rather than your working tree *and* your branch tip ? [12:05] The -b implies that I'm creating a branch tip and switching to it [12:07] Or are we driving at different things? My work setup is typically lightweight checkouts [12:07] yes, but why do you use "bzr up -r" ? It causes the working tree tip and the branch tip to be different [12:07] In this case, I am bisecting somewhat manually [12:08] I have located the revision with the bug in it and wish to start a new branch with this revision at it's tip so I can fix it [12:08] ah, hmm [12:09] so perhaps we should allow you to do something like "bzr switch -b newbranch -rtree:" [12:10] I was just going to suggest bzr switch -b newbranch -r `bzr revision-info` ; but apparently revision-info does not respect dirstate [12:10] awilkins: it has a --tree option [12:11] jelmer_, Aha, that's nice [12:12] A dirstate-based revspec would be lovely though [12:12] especially for access to pending merge tips [12:12] yeah [12:12] * jelmer_ files teh bug [12:14] Ah, and switch -b -r does not behave as you'd want [12:14] yeah, please file a bug about that [12:14] $ bzr switch -b -r 201 fix-update # Tree is up to date at revision 233. [12:15] well, you'd want an argument to -b [12:15] ah, you have - sorry [12:15] Ack [12:15] Ah, yes, not an arg to be, arg to command [12:17] It doesn't respect the revision argument for either case, branching or non-branching [12:22] vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log. <- there's still a good chance this would kill the ongoing operation, given how dodgy signals are [12:23] mgz: true and hi ! [12:23] and SIGTERM already dumps the current stack as it exits, right? [12:23] * mgz waves at vila [12:24] hmm, that would at least gives us a hint... [12:36] fullermd: I'd like to install sphinx for some tests, but it seems it's available only for py27 :-/ [12:36] fullermd: I don't want to play around with 2 different versions of python on my babune slave, so, is bzr packaged for 2.7 and if not when/why/what ? [12:44] ha, finally the true jelmer is back... [12:46] heh [12:46] I had a nouveau freeze :-/ [12:46] hmpf [12:49] Are the docs on the website in the main source tree? I've spotted a bug asking for some clarification in the Visual Sourcesafe docs I wrote but I can't remember where the doc sources are .... [12:50] doc/... :-) [12:50] awilkins: most of the docs live under doc/en in lp:bzr [12:50] awilkins: it depends, but doc.bazaar.c.c are mostly in... too slow for jelmer :) [12:50] vila: and for maxb :) [12:50] errk, didn't even saw this one ;D [12:51] on the other hand, the shortest answers came first :) [12:51] Yeah, can't find http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html there though. [12:52] I should know, I wrote it [12:52] Gah [12:53] heh [12:53] parent branch: http://bazaar.launchpad.net/~bzr/bzr-migration-docs/trunk/ [12:53] Aha [14:06] jelmer: thanks for the review ! [14:29] vila: np [14:32] * jelmer resubmits his lazy-bzrdir branch [14:35] maxb: Hmm, weren't all the issues with running the bzr-dbus testsuite on a buildd fixed now? [14:35] * jelmer is still getting failures building for sid [14:44] Well, the recipe build seems happy [14:44] Got a link to the sid buildlog? [14:45] there isn't one - I'm building locally [14:45] I'll pastebin [14:49] maxb: http://pastebin.ubuntu.com/578852/ [14:50] ah, I remember that test, that's the one which tries to connect to a dbus session bus running outside the context of the build [14:51] http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk/revision/47 was my attempt to skip it when appropriate [14:51] I guess my "when appropriate" check isn't working out quite right for you [14:52] actually, I see what's happening [15:01] spiv: I've been seeing if I could duplicate that strange locking problem. Doesn't work on a cooked up example. But it always happens with a particular branch. -Dlock doesn't show anything out of the ordinary (to me). Are there any other debug switches I could try? [15:02] briandealwis: I bet spiv's asleep [15:02] briandealwis: if this is a bzr+ssh:// issue you were trying to debug -Dhpss might help [15:02] ah, he's showing green [15:02] It's a local issue. [15:03] I have two branches, p1 and p2 that have a common ancestor. Trying to push from p1 to p2 results in a strange self-locking problem [15:03] maxb: fixed it by starting a temporary dbus session [15:04] I wasn't having this problem in 2.2.x; maybe I'll try some bisecting. [15:08] briandealwis: what's the bug number? [15:09] mgz: haven't filed a bug yet, sorry. [15:09] mgz: will do that next [16:17] mgz: finally filed as bug 733350 [16:17] Launchpad bug 733350 in Bazaar "LockContention error when pushing to a bound branch" [Undecided,New] https://launchpad.net/bugs/733350 [16:23] vila: Thanks for the review, I'll add some docstrings. [16:23] vila: it's not just bzr-svn that adds itself to the beginning of the server prober list, bzr-hg and bzr-git do as well [16:23] jelmer: thanks for your persistence there ;) [16:24] jelmer: one more reason to discuss a saner scheme, the issue has existed for far too long [16:25] jelmer: and even if your work allows more lazy loading, ISTM that bzr-svn users still pay a penalty when they work with bzr branches only right ? [16:25] vila: they do an extra OPTIONS request when talking over http, but that's all at this point [16:26] I added some hacks to do that OPTIONS request over the existing HTTP connection, rather than building up a new connection. [16:26] jelmer: and you manage to not load any modules that won't be needed if the probe fail ? [16:27] . o O (I'm tired, I'm sure this could expressed in a simpler way :-/) [16:28] vila: yes, that's the point of the probers. the prober implementations live inside the plugin __init__ and only load the actual stuff when they find something [16:29] ha ok, so the lazy loading addresses the remaining issues then [16:31] jelmer: about the OPTIONS stuff, wibni (once you land you hacks in core ;) the smart server was adding its own option too ? [16:32] vila: what's wibni ? [16:32] Wouldn't It Be Nice If ? or did I mangled that ? === beuno is now known as beuno-lunch [16:33] briandealwis: is that info at the bottom for the trunk branch? if so, the push branch value is odd, try editing .bzr/branch/branch.conf to remove it [16:33] vila: no, you didn't... just an acronym I didn't know yet :) [16:33] mgz: you're right, I made a mistake: it's from the workspace branch [16:33] vila: Yeah, it'd be nice to add an OPTIONS entry for the bzr smart server.. though we should probably still support the POST request in case the user is e.g. using a cgi script [16:34] mgz: I've been able to reproduce the issue from a synthetic branch — it hinges on tags [16:34] . o O (There you are, people are so used to your tyops that they see tyops even when you type correctly) [16:34] okay, in which case the odd thing is is *also* thinks it a checkout of backup? [16:34] that's not intended surely [16:34] jelmer: sure and for older clients too, but still [16:35] tags being what's broken seems likely, spiv added some new behaviour there. [16:35] mgz: I bind "trunk" to "backup", where "backup" exists on a different drive. So pushes to "trunk" are backed up [16:35] but the fix for you should probably just be editing a conf file. [16:35] briandealwis: but what is 'workspace'? A normal branch? a checkout? [16:36] mgz: a normal branch [16:36] the info posted is of a checkout. [16:37] mgz: now I'm confused :) [16:37] `bzr info` on workspace should say it's parent branch is trunk, and have no checkout bits [16:38] `bzr info` on trunk should have no parent branch, and say it's a checkout of backup. [16:38] `bzr info` on backup should just say it's a normal branch. [16:38] mgz: I was right originally: it was from "trunk"; that was info carried when branching from my original branches [16:38] mh [16:39] mgz: I removed the stray info, and it makes no difference [16:39] mgz: I'll add a synthetic example that demonstrates the bug in a sec [16:39] ah, you've got one now? [16:40] mgz: yeah — it's all about pushing with tags [16:40] mgz: I used bisect to identify the problematic commit. if you look at it, it adds some locking. [16:41] yup, I can repo too with that. [16:45] jelmer: I'm very tempted to give you the green light to land all the weave-in-a-plugin stuff [16:45] vila: \o/ Did you see the intermediate branch, bzrdir-weave ? [16:46] jelmer: since you raise an error if the old_register_format is used, the worst that can happen is that people running trunk will have to revert if they encounter issues [16:46] jelmer: did you see my reviews ;) [16:46] clearly I haven't :) [16:46] jelmer: and I'm sure you will be motivated to fix any bugs if that's the case [16:47] yeah, of course [16:47] mgz: I tacked on the example [16:48] yup, that's similar to what I got to fail. [16:48] jelmer: with 2.4b1 close to freeze, I tend to prefer landing now than wait for a second review which will requires more effort from the reviewer than your own efforts to fix the hypothetical fallouts [16:49] mgz: any progress on https://code.launchpad.net/~gz/bzr/create_delta_index_memoryerror_633336/+merge/52251 ? [16:49] vila: sounds good to me - most of it is just moving code around now anyway [16:50] mgz: I didn't review closely but I was wondering if your actual fix was already viable ? [16:50] yeah, I'm going to give in and rewrite those two functions to take **struct and return a code rather than *struct [16:51] it's a bigger change, but there's no point trying to keep a limited api when they need sensible error handling. [16:52] mgz: ha ! Yeah, when you're tired to override, using distinct objects help express better semantics ;) [17:03] darnit, what's the trick for getting the mainline rev a dotted rev was merged in? I always forget it and give up and use qlog instead. [17:05] mainline: ? [17:07] http://paste.ubuntu.com/578908/ <- and the number of times I do this as well, env-variables is particularly painful [17:07] mgz: bzr help topics [17:08] yeah, but `bzr help topics | grep env` is just as annoying to type every time [17:08] mgz: which is itself mentioned in 'bzr help' [17:08] oh [17:08] so, I try and remember and get it wrong a few times. [17:09] why, for instance, is 'environmental' abbreviated, but 'variables' is not? [17:10] yeah, this needs to be reworked, revisionspec is another bad example [17:11] It should probably be 'environment-variables' with an alias of 'envvars' [17:12] or may be bzr-guess could be extended to handle help topics and merge in core [17:12] merge*d [17:12] I thought Parth worked on a bit on that at some point... [17:13] ^thanks, mainline works, presumably new in 2.2 or 2.3 though. [17:13] yup, I'd say 2.3 [17:15] right, I need some food, then I'll write a little code. === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno [17:57] mgz: mah, my memroy was bad, help topic guessing has been *disabled* in revno... 2 :-( [18:30] vila: argh, test isolation failure :-( [18:31] jelmer: caught by pqm ? [18:31] vila: yep [18:32] which branch ? [18:32] vila: lazy-bzrdir [18:32] k [18:33] vila: bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server happens to fail because the returned control dir suddenly has its repository format set to 2a [18:33] the cause seems to be the fact that we now run the per_controldir tests against RemoteBzrDirFormat [18:33] ah [18:34] why do you suspect an isolation issue ? [18:34] vila: I can reproduce it locally. "./bzr selftest -s bt.test_remote" succeeds, "./bzr selftest -s bt.per_controldir -s bt.test_remote" fails [18:34] arg [18:35] * jelmer wonders what the best approach is to debug this sort of thing [18:35] they are all painful [18:35] :) [18:35] is there any particular function that gets called after each test? [18:36] probably, never tried that approach though [18:37] what I generally do is establish a list of tests including the failure and bisect it [18:37] jelmer: Concerning bzr-rewrite packaging - is it correct to drop the "Replaces: bzr-rebase" whilst retaining the Conflicts? [18:38] jelmer: as an aside, just trying to run bzr with my current trunk of bzr-hg crashes with NotImplementedError: > [18:38] --no-plugins time is back :-/ [18:43] seems to be in bzrlib.tests.per_controldir.test_push.TestPush === deryck[lunch] is now known as deryck [18:45] vila: Can you try again with trunk? [18:45] try what with which trunk ? [18:46] don't lose focus on the crash, different people will have different issues, we'll see later :) [18:46] bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty [18:47] ./bzr selftest --no-plugins -s bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty -s bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server [18:47]