[00:00] no I'll just have to find out how to push it to lp [00:01] s/no/now [00:05] blizzkid: see http://help.launchpad.net/ [00:11] lifeless: thanks for fixing the selftest tests, they annoy me every time i see them [00:12] for some reason tests that just check a parameter is passed through a layer annoy me though [00:12] hmmz.... why do my branches have /+junk in it? [00:12] i guess partly they often require a big hammer (monkeypatching) to write but they don't test very strongly [00:12] blizzkid: if they're not associated with a project they're called junk [00:12] maybe you want to register a project? [00:13] poolie: not exactly... let me explain: I made a change to a gwibber branch [00:13] but I can't upload to that branch [00:16] is it your branch? [00:17] no [00:17] so you want to fix a bug or something and give that back to them? [00:18] right [00:18] i see you're already in the gwibber team? [00:18] what's the branch about? what name do you want to push it to? === kfogel is now known as johnlodder [00:20] poolie: in short I'd like ~blizzkid/gwibber/cwibber instead of ~blizzkid/+junk/gwibber/cwibber [00:20] ok and what happens if you try to push to the first of them? [00:21] igc, what are we going to do about bug 415508? [00:21] Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,Triaged] https://launchpad.net/bugs/415508 [00:22] poolie: testing atm [00:22] poolie: I think we're going to deprecate the code path using path_content_summary() [00:22] poolie: iiuic, it's not broken in 2a, "just" 1.14 [00:23] poolie: so, testing that a layer does whats meant to is never pointless IMO [00:23] poolie: so maybe it's high and not critical? [00:23] path_content_summary is broken in 2a as welel [00:23] *well* [00:23] if you e.g. do 'bzr commit --excludes' (or at the moment 'bzr commit foo') [00:24] poolie: it worked [00:24] yay [00:25] lifeless: if you do that then what? [00:28] (impatient) [00:28] blizzkid: all good now? [00:30] poolie: yeah, now let's hope they accept the merge proposal :) [00:30] poolie: then the corruption occurs because the non iter_changes commit code path is executed [00:31] ok so if we set up content filtering, in 2a, then used commit --excludes there would be corruption [00:31] of what type? [00:31] btw our bug-handling doc says we don't use status Triaged, only Confirmed [00:32] poolie: of the sort in that bug [00:32] poolie: john's done all the digging [00:32] poolie: (why are you impatient, its a fine monday morning) [00:32] it's a lovely day [00:32] i just want to get a 2.0 out [00:32] it's constructive impatience :) [00:33] so i'm just asking because it looks like it's not actually corruption, just that we redundantly store a new text [00:33] which would be bad, admittedly [00:33] if we store all the texts on every commit it would be awful [00:34] it also means that log does very much the wrong thing [00:34] and the merge graph, when merges are involved, goes haywire without converging [00:34] ok [00:35] if we can get a small fix I'm incliined to say say we should backport it to the karmic version and get it out there. [00:35] its _bad_ [00:38] its not eat your history and spit it out [00:38] but if you recall the bug we discovered it via, its a tremendous performance hit [00:38] i do [00:39] just trying to understand it [00:39] i might start on this today [00:40] and would you agree with ian's thing to "deprecate the code path using path_content_summary()" [00:41] that requires adding exclude support to iter_changes (via internals or decoration) and checking it creates consistent deltas. [00:41] which sounds a bit large [00:41] I think changing the record_entry code path to stop using path_content_summary, and delete the path_content_summary method is fine. [00:42] i thought that's what ian was suggesting [00:42] alternatively, have path_content_summary work when there are filters [00:42] did you just set that bug to triaged, or is this launchpad being weird? [00:43] poolie: well, the code path that /uses it/ can't be deprecated without the exclude changes I mention above. But you can /change the code path to not use path_content_summary'. [00:43] right, and deprecate path_content_summary [00:43] at least weakly [00:43] ok, i'll pull on that string [00:43] I'm against deprecating the method. If its irredeemably broken, delete it. [00:43] i love the ajax bug stuff but it does seem to trip over itself a lot :/ [00:43] if its not so broken, fix it. [00:44] +1 from me wrt deleting the method instead of deprecating it [00:44] deprecation is good for non-ideal things, or things we've improved. its a poor way to indicate 'bad things are happening' [00:45] mm [00:45] as i see it, it's a way to give plugin or similar authors a clue that 'no you're not going crazy, we changed this' and to possibly give users something that still works until the plugin is updated [00:46] it's good at the first, only mediocre at the second because those users don't actually want to see the technical mesasges [00:46] sure; but this doesn't meet the contract it claims too [00:46] s/to/ [00:46] so wrt the first one, we could say it's better to raise an error if you still try to call it [00:47] sure. Or put it in NEWS. [00:47] yeah, there is that [00:47] igc, iirc you were going to check if any plugins care about it [00:47] poolie: I wasn't touching that bug [00:48] ok [00:48] poolie: re confirmed/triaged; LP changed its meaning around when it added triaged. I think we should ignore confirmed and just use triaged everywhere that we've set an importance. [00:49] something strange happened between the various status controls i think [00:49] because thats what lp's workflow and reports want. [00:49] like what? [00:49] like 'what bugs has a core dev not seen' [00:49] what i mean is, where does lp make a distinction between them? [00:50] I don't recall offhand [00:50] I've encountered glitchy things [00:52] mm, they may have [00:52] this thing i just saw might have been such a glitch [00:52] poolie: quick grep over my plugins.popular directory (used to build the plugins guide) shows ... [00:53] poolie: svn/commit.py, git/commit.py, cvsps_import/importer.py [00:53] poolie: anyhow, unless you have a reason /not/ to use triaged, we should be using it. [00:53] i think 'triaged' is kind of a stupid name that means the same as 'has an importance' [00:53] but that's not a very strong reason :) [00:53] poolie: I agree. Thats a different discussion though. [00:53] i just don't want more labels than there are logical states [00:53] [as in, its a discussion with #lauchpad-dev] [00:53] yeah [00:53] make that cvsps_import/cvsps/importer.py [00:53] i don't think we distinguish between two confirmed-type states, but the bugs are spread across them [00:54] igc, well there are 77 uses just in the tree so that's enough to get on with [00:54] so what would be a good overall test for this? [00:54] Triaged just means "I'll look at this and assigned an importance" to me [00:54] at the blackbox level i could set up a tree with filtering, commit, and then see if the per-file graph changed [00:54] igc: *looked* ? [00:54] or not quite blackbox [00:55] poolie: what particular thing do you want to test [00:55] lifeless: yes, sorry - Monday morning typo [00:55] that this bug is fixed :-) [00:55] i'm trying to work out what that means [00:55] poolie: I wouldn't write such a test; the bug is a lack of test coverage in filtering trees. [00:56] filtering trees in per_workingtree should be testing all the stock tests with filters, that would have caught this. [00:57] caught it how? [00:58] the path_content_summary bug would have been exposed [00:58] by exercising content_summary returns the summary of the canonical form? [00:58] s/exercising/checking [00:59] so we know its not a repository bug, exercising repository code to show the bug is fixed is waste [00:59] hm [00:59] yes, though if we added canonical_content_summary and convenient_content_summary [00:59] we ought to have something that tests that commit uses the right one [01:00] well [01:01] adding the test_content_filters test would be an easy place to start [01:01] Good morning. [01:02] poolie: we have lots of tests of commit builder [01:02] hi spiv [01:02] poolie: but roughly yes. [01:03] ok so i might start by changing *content_something to an interface with a more explicit name [01:03] FWIW, I think john had a patch. [01:04] If I were working on this, I'd look at how to make sure that that stops using path_content_summary; then work towards that. [01:10] poolie: re triaged/confirmed, can we at least not twiddle them - its just noise. I have no objection to a change when something else is being altered on the bug, but arbitrarily altering that field doesn't seem beneficial. [01:13] yes, i agree on both [01:13] i thought you were twiddling them, that's why i asked [01:13] but apparently it was lp [01:13] or something [01:14] no, I'll set to triaged if its < than that when I am altering the bug; but I won't just change that field alone ;0 [01:14] less than that? [01:15] triaged. If its new or incomplete or confirmed, and I'm changing other status fields [01:15] look, the doc says "don't use triaged" [01:15] so please don't [01:16] if you want to change the policy, because lp has changed or for other reasons, please do that first [01:16] having them set randomly depending on who last touched it is not helpful [01:25] igc, lifeless: if either of you feel like doing a review, there's https://code.edge.launchpad.net/~spiv/bzr/ids-only-necessary-texts/+merge/10444 :) [01:39] http://pastebin.ca/1541055 [01:40] I just got this error from Bazaar. [01:40] Could this be due to not having enough memory? [01:41] GungaDin: yes. (Or alternatively, due to Bazaar not being clever enough when dealing with large files) [01:41] maybe we should give a special message for memoryerror? [01:41] hmmmm... [01:41] ok [01:42] The problem shouldn't be large files... it's just a big repo [01:42] none of the files inside is that big. [01:42] poolie: not a bad idea. At least for some of the known trouble spots like that ''.join... [01:43] GungaDin: Hmm. IIRC, that error usually occurs when handling a large file version. Perhaps there used to be a very large file earlier in the history? [01:44] could be... [01:44] dunno really [01:47] So, given that you dump traces in bzr.log, couldn't you just swallow any even remotely predictable exceptions and give a human readable single line error message instead? [01:48] AfC: well, we mostly do that already :) [01:48] [me is Java programmer, knows value of thread dumps at programming & debugging time, but I also know how much they freak out innocent users who were under the mistaken impression that they have a warranty with their software :)] [01:49] yeah, we do exactly that [01:49] spiv: ... it also just came up on the mailing list [01:49] afc, the question is more precisely, [01:49] should we add MemoryError to the class of errors that are treated as environmental not a bug [01:49] poolie: ah [01:49] * AfC understands [01:50] So, does Python's VM expand to use all available memory until the kernel OOM killer gets it? [01:51] Probably "bzr: ERROR: out of memory" is virtually always a better thing to do than a traceback, even if the MemoryError is (hypothetically) a bug in a dependency rather than bzrlib. [01:51] For reasons that defy comprehension Java's VM has to be told manually to use [lots of] available memory. Quite the pain in the ass. [01:51] afc, no, it's like java, it normally raises an exception [01:51] especially with people innocently using recursive descent parsers, etc. [01:52] poolie: right, but in Java's case if you don't manually tell it to use more than hard coded maximum 256 MB (or whatever stupid number it is) of heap, that's all it'll ask for before raising OutOfMemoryError [01:52] Well, in the case of recursion, CPython has a limit on the amount of recursion it can handle because Python function calls use C stack frames too. [01:53] But yes, CPython will happily ask the OS for as much memory as the program demands. [01:53] spiv: (yeah, I realize I was conflating stack and heap there, but the two tend to go hand in hand when tree-building) [02:06] general frustration [02:06] packaged bzr and bzrtools don't work together :( [02:06] thumper: what are you using from bzrtools? [02:06] poolie: I tried both trunk and the one from the ppa [02:06] i mean, why do you have bzrtools installed? [02:06] just for background [02:06] cbranch [02:07] ok [02:07] :/ [02:07] so I was chatting with john yesterday [02:07] aaron insists on having them locked in sync [02:07] he's going to package more [02:07] :( [02:07] even though in this case there were 0 changes to update to 1.18 [02:07] to help with this [02:07] icanhazcbranchtrunk? [02:07] https://bugs.edge.launchpad.net/bzr/+bug/417922 [02:07] Launchpad bug 417922 in bzr "treat MemoryError as a special/environmental error" [Medium,Confirmed] [02:08] thumper: not for 2.0; something equivalent but hopefully integrated not bolted on, in 3.0 [02:08] yeah [02:08] * thumper nods [02:08] and by integrated I don't mean 'in core', I mean 'in UI / workflow' [02:08] using bzr.dev for bzr now [02:12] regarding john's patch http://bazaar.launchpad.net/~jameinel/bzr/1.17-content-filtering-commit/revision/4530 [02:12] it looks like it's still trusting the content_summary sha1 [02:12] i don't know if that's safe [02:13] but if we were going to take this patch, it does seem like we'd need a test of commit with content filtering [02:20] it depends what dirstate is doing [02:20] I suspect dirstte stores the canonical sha1 [02:21] in which case the sha1 in a content summary is valid if its coming from a dirstate cache hit [02:37] wt = Branch.open('/Users/rbriggs/bzr/test.bound') [02:37] wt.update [02:38] this is not actually updating the branch (it's a bound branch) [02:38] what is the method that I actually want to use [02:40] wt.update() [02:41] but [02:41] Branch.open returns a branch, not a tree [02:41] you want [02:41] wt = WorkingTree.open(...) [02:41] wt.update() [02:43] alright - I tried that too and it doesn't work either [02:44] what are you expecting to happen that is not happening? [02:44] I am expecting it to have the same result as if I ran bzr up from the command line [02:45] the branch that wt is bound to is at version 3 - but wt keeps staying at version 2 [02:48] thats the api that cmd_update uses [02:48] cmd_update does more; you should look at it inside bzrlib.builtins [02:50] cool - thanks [02:50] btw - love this chatroom - it has always been helpful [03:11] Ok, that's weird. That rbrigg fellow managed to have his nick show up in italics in my IRC client. Hm. injection vectors. Yeay. === davidstrauss_ is now known as davidstrauss [04:36] * igc lunch === abentley1 is now known as abentley === abentley1 is now known as abentley [07:09] hi all [07:16] hi vila! [07:16] hi vila [07:22] lifeless: rev4638 on trunk is weird, the message and the "code" actually committed doesn't seem to match >-/ [07:23] The message says : "Improve test performance of selftest tests." but the commit is about the "Triaged" definition... [07:23] lifeless: not a big deal, more a heads-up in case you missed something [07:24] oh frell [07:24] landed totally the wrog branch there [07:25] my worst nightmare.... :D [07:25] https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10590 [07:25] is the follow on to what I had meant to land [07:52] igc, so as far as i can make out the content_summary is meant to be about the internal form [07:52] i think we should see about a clearer distinction between those that are and those that aren't [07:53] poolie: right. It's only used in bzrlib (to my knowledge) for getting what to commit [07:53] it predates filters [07:53] sure [07:53] the question really is, what are interfaces that predate filtering meant to do [07:54] I agree with what you're saying. [07:54] interfaces predating are all about the canonical form, IMO [07:54] cool :) [07:54] then we all agree :) [07:54] lifeless: ir predates filters landing; content filtering development started before it existed by then I got sick [07:54] s/ir/it/ [07:54] s/by/but/ [07:55] i mean even aside from this particular method there are going to be other things that are not filtering-aware [07:55] right, because there was no convenient form [07:55] i was wondering before if perhaps we should have a separate tree object that represents the filtered form [07:55] it may be complicated to make that work properly with eg treetransforms [07:55] but it might be cleaner [07:56] hm it might be hard to make it work well with dirstate too [07:56] Files can be different from the filtered form (and different from canonical), and still evaluate to the same canonical form... [07:56] So at best it would probably only save you work some of the time. [07:56] fullermd: right [07:57] (of course, that may be the vast majority, so still be a win. But you'd always have to treat a miss as just a hint at any rate) [07:57] i meant easier in terms of less bugs, not faster [08:01] I'd think the result would just be to hide them more often. [08:01] (I guess that's "less", but probably not in a way we really want :) [08:01] why? [08:02] actually, are we even talking about the same thing? ie having a FilteredTree(filters, tree) class [08:03] Possibly not. I never really know what I'm talking about. [08:03] :} [08:15] vila: ping [08:15] pong [08:15] vila: good morning :) [08:15] NEBAP|work: You too :) [08:16] vila: get the error reproduced? [08:16] So, I looked at our bug and couldn't find a way to reproduce the "obj/file2' is not conflicted, only "obj.moved/file2" is not conflicted [08:17] hmmm [08:17] weird [08:17] So I left it up to you to find the right sequence :) [08:17] ^^ [08:17] From there, but from there only can I try to fix the problem [08:17] will play a bit with generated folder ;) [08:17] and then give you the results [08:17] NEBAP|work: ok, thanks ! [08:18] NEBAP|work: My best guess is that the sequence is so alien to me that I can't force myself to reproduce it, [08:18] doesn´t bazaar have a "log" where you can see the last xx commands? [08:18] .bzr.log in $HOME (bzr version will tell you where) [08:19] Good idea [08:19] I hope that it wasn´t my fault that caused the error.. [08:19] I suspect some more non-bzr commands are involved though [08:19] so, will that help if I take the log from chris computer? [08:20] NEBAP|work: Don't think about it as whose fault it was, in the end we want bzr to help you avoid such problems anyway [08:20] kk [08:20] NEBAP|work: it will certainly help, if only by restricting what bzr commands we should include in the scenario [08:21] there can also be a '.bzr.log.old' there too [08:21] k, I will look for those files on chris computer and then send them too, ok? [08:21] if you can find the commands that have been executed in the right time frame (hopefully you can identify that :) [08:21] that will help [08:22] NEBAP|work: try to filter them a bit first [08:22] ok, if the commands are in the log file, I´ll find them ;) [08:22] ok [08:30] poolie: I landed the policy change by mistake. I'll back it out tomorrow. [08:30] k [08:31] lifeless: grr, I already asked you (can't remember where): where the h is boto ? [08:31] vila: apt-get install python-boto [08:31] I'm sure I tried that :-( [08:31] may be only in karmic [08:31] in which case [08:32] add karmic to your sources [08:32] then apt-build install python-boto [08:32] python2.5-boot [08:32] boto [08:32] available in jaunty, may be it wasn't last time I checked... [08:32] in jaunty [08:32] in universe [08:33] lifeless: but did you try my patch ? The only helper class I modify is *inside* fork_for_tests... [08:34] vila: is it? [no I hadn't; I was doing a trawl through for unreviewed things...] [08:34] vila: email is on the way, keep that one private please .. (should contain the hole session from friday) [08:34] NEBAP|work: sure [08:35] lifeless: I don't want to force your vote (non sense anyway) but I'd like to keep that submission simple, I *want* to limit the number of spawn process, but it requires a more extensive change (I know, I tried) [08:37] vila: It would make me happy if you test it with ec2test. [08:37] lifeless: devil :) [08:37] I'd like to know that all the hacking you do in this space fits with ec2test, because I think its a good model for a bunch of things like - having pqm validate on windows during commit. [08:38] lifeless: you know we agree on the aim, even if we disagree on the steps to get there :) [08:38] I'm not sure we disagree on anything ;) [08:39] Is that the same as: "I'm sure we agree on nothing" ? :-D [08:39] heheh [09:09] NEBAP|work: I received the file, but it looks like a lot of lines are badly truncated (as if you copied some file content in a mail...) can you resend the file itself as attachment ? [09:13] * igc dinner [09:13] vila: sure, give me a second [09:14] Hello. I have a problem, the server admins have changed the SSH port so now my bzr branch is wrong when I try to commit files. How can I change this without losing the data I've modified? [09:14] NEBAP|work: the scope sounds good though as far as I can see, the last commit/push is the one that succeeded right ? [09:15] vila: yes should be :) [09:15] Coke: mention the port explicitly in the url [09:16] Coke: uze 'bzr info' to check what bzr thinks your branches are, use --remember in the right command to update that [09:16] vila: ah, remember [09:17] Coke: now you remember ? :-D [09:17] no, I'm trying to remember [09:17] sorry, to USE --remember [09:17] unknown command "--remember" [09:17] Coke: --remember is a parameter accepted by commands like 'push', 'pull' [09:18] Coke: more like: bzr push --remember [09:18] ok. and after remember I have the new URL? [09:18] and the URL as additional parameter of course [09:18] ok. [09:18] bzr: ERROR: no such option: --remember [09:18] which bzr version do you use? [09:18] I'm trying to do a ci [09:18] Coke: you use the command as usual (but mentioning a new URL) and you add --remember [09:18] 1.17 [09:19] Coke: what does 'bzr info' says ? [09:19] bzr ci does not have --remember as it does not require a URL [09:19] vila: on the way [09:19] vila: about? [09:19] Raim: so how do I solve this? [09:20] Coke: can you paste it somewhere ? Do you use a standalone branch or a heavyweight checkout ? [09:20] it says "checkout of branch" in info [09:20] hmm [09:20] all I want to do is change the URL used when doing ci and up [09:20] it's stored somewhere in some magic file [09:21] (which the README says explicitly not to touch manually) [09:21] Coke: cat .bzr/branch/branch.conf [09:21] vila: have you ever seen this: [09:21] mbp@grace% ./bzr --no-plugins selftest nested [09:21] testing: /home/mbp/bzr/bzr.1.18/bzr [09:21] /home/mbp/bzr/bzr.1.18/bzrlib (1.18 python2.6.2) [09:21] Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in ignored [09:21] Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in ignored [09:21] vila: should I change that manually? [09:21] [09:21] poolie: yup, every day :) [09:21] really? i don't think i ever havebefore [09:21] poolie: I traced it back to a test saying it was expected or something [09:22] I see it sometimes. [09:22] I was about to summon you spiv :) [09:22] vila: OH! that worked nicely even though I shouldn't meddle with .bzr [09:22] It's something that only happens when .pyc files are generated, or something weird like that. [09:22] Coke: huh ? Just looking at the file ? Or do you mean you edited the file ? [09:23] vila: I edited it. [09:23] Coke: ok, certainly the simplest there :) [09:24] There may be a way to do it from the command line, but not using heavy checkouts myself, I don't know it [09:24] How come bzr up doesn't restore deleted files? [09:25] I deleted a file in the local branch and then did bzr up to see if it would restore it, but no go [09:25] Coke: a versioned file ? [09:25] Coke: ho, you want 'bzr revert' [09:26] bzr update will respect your local changes as much as it can [09:26] vila: ah [09:26] thanks [09:26] still getting used to the CVS -> bzr switch [09:27] Coke: You're welcome [09:30] wow. bzr uploads could not possibly be any slower. :) [09:30] :/ [09:30] it's doing < 1k/s [09:31] over what protocol, and with what version? [09:31] sftp [09:31] 1.17 [09:31] to launchpad, or elsewhere? [09:32] elsewhere [09:32] for launchpad I use lp protocol [09:32] Man, does launchpad have support for showing number of checkouts and/or downloads yet? [09:33] no [09:33]