[00:01] Noldorin: how is it failing exactly? [00:01] jelmer: was my earlier summary accurate [00:02] jelmer, it doesn't import the module from site-packages [00:02] glyph: yes, although I should note that only newer twisted revisions were imported with newer versions of bzr-svn on launchpad [00:03] Noldorin: what module is it failing to import? [00:03] Noldorin: and how is it doing that, do you have a traceback? [00:03] jelmer: hrm [00:03] glyph: so perhaps it's better to be safe than sorry and redo the launchpad imports [00:03] jelmer: is there a way to explicitly refresh that? [00:03] and is launchpad on bzr-svn 1.1.1 yet? [00:04] jelmer, nothing. just says "cannot importy module" [00:04] no traceback sorry [00:04] Noldorin: .bzr.log should have a traceback [00:05] glyph: yes, it's post-1.1.1 [00:06] jelmer, okay just a sec [00:10] jelmer: I guess the way to fix it is just to do the re-import somewhere else, then 'bzr push --overwrite lp:twisted'? [00:11] jelmer: +1 to getting launchpad to redo that import [00:11] glyph: we'll have to do it via Launchpad, as import branches are only writable by the importds [00:11] glyph: I can look into getting that done [00:11] jelmer: so there's no button for me to press, then [00:33] Noldorin: any luck? [00:33] in my Python script, I'd like to check the status of a given folder, such as if there are uncommitted changes, unknown files, etc. What is the best way to do that? [00:34] I've been told there are bzr tools for Python, and that sounds nice. If anyone has a link to docs, I'd appreciate it. [00:34] jo-erlend: you probably want to use the working tree [00:34] jelmer, I don't understand what you mean by that. [00:35] jo-erlend: from bzrlib.workingtree import WorkingTree; w = WorkingTree.open("."); print bool(wt.changes_from(wt.basis_tree())) [00:35] sounds nice. Any docs for it? [00:36] jo-erlend: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.workingtree.WorkingTree.html [00:43] I guess I'll just run bzr st and check the status myself. I don't even understand how to begin using that stuff, and the only thing I need is to see if a folder has any changes. I don't need to do anything about it. [00:44] jo-erlend: the fragment I pasted earlier should give you a boolean that indicates whether anything has changed [00:52] oh. That was easier than it looked. :) [00:52] thanks. :) [01:00] jelmer, yeah just testing [01:00] jelmer, that feature isn't documented, though? [01:03] I can do w.unknowns to get unversioned files, but I don't understand how I can see if files are modified. I also can't figure out how to find out what WorkingTree.changes_from does. [01:04] jelmer, what's an easy way to check if bzr-git has loaded correctly? [01:06] jo-erlend: the fragment I posted should tell you if there are any modifications since the last commit [01:06] "bzr: ERROR: No module named apt_pkg" - https://launchpadlibrarian.net/85223456/buildlog.txt.gz [01:07] From https://code.launchpad.net/~spamassassin/+recipe/spamassassin-daily [01:07] Bulding is failing again.... [01:07] jelmer, yes, I understand that. I'm having difficulty finding out how to see if I already know that a file is unversioned or not, for instance. [01:07] Darxus: there is work going on to fix that [01:07] jelmer: Thanks. [01:07] jo-erlend: it will only return versioned files, so only files that are not in .unknowns() [01:08] jelmer, ? [01:08] oh, I see. Thanks. [01:08] jo-erlend: See Tree.changes_from() for the documentation ("pydoc bzrlib.tree.Tree.changes_from") [01:08] Noldorin: "bzr plugins" [01:09] jelmer, that displays fine even if dependent modules didn't load though [01:11] Noldorin: it means the basic bits of bzr-git have loaded though [01:11] Noldorin: if you want to make sure *all* of bzr-git works, run the bzr-git testsuite [01:11] jelmer, yes but it won't tell me if dulwich loaded [01:11] jelmer, which is what i want to find out [01:11] very simply [01:12] Noldorin: any sort of operation involving a git repository should load dulwich [01:13] got it [01:13] jelmer, here's the error: [01:13] bzr: ERROR: Unsupported protocol for url "git://": Unable to import library "dulwich": bzr-git: Plea [01:13] se install dulwich, https://launchpad.net/dulwich [01:14] jelmer, when dulwich is a symlinkd rather than real dir in site-packages/ [01:14] that happens [01:14] Noldorin: right, but what about the traceback (in ~/.bzr.log) ? [01:14] Noldorin: we just use "import" from python to load dulwich, so that's all inside of Python itself [01:14] oooh [01:14] i see [01:15] got it [01:15] jelmer, http://pastebin.com/cXdaVkpL [01:16] hmm, that's masking the actual error [01:16] jelmer,yeah... [01:17] Noldorin: can you try adding "import dulwich" to bzr-git's __init__.py ? [01:18] jelmer, same [01:18] Noldorin: the traceback in ~/.bzr.log should be different [01:18] oh yes [01:18] jelmer, http://pastie.org/2870011 [01:19] Noldorin: right, python's import doesn't find dulwich [01:20] yeah [01:20] so python's import doesn't like symlink dirs basically? [01:20] because it finds it fine when it's a normal dir [01:22] Noldorin: it seems happy with symlinks on Unix, perhaps it's different on Windows? [01:23] jelmer, perhaps [01:23] i've updated the python bug i submitted about it [01:23] originally i was confused about what i tested [01:23] http://bugs.python.org/issue13412?@ok_message=msg%20147744%20created%3Cbr%3Eissue%2013412%20message_count%2C%20messages%20edited%20ok&@template=item [01:23] jelmer, ^ [01:23] jelmer, i'm off now, but feel free to investigate it more and ping me later :-) [01:24] ciao [01:25] Noldorin: sorry, I'll leave that up to the Python folks [01:26] jelmer, that's fine. i only said that in case you thought it might be something specific about bzr :-P [01:26] jelmer, if you think it's a generic issue, my bug should take care of it [01:26] ta ta [06:31] hi vila? [07:51] poolie: hey ! [08:12] morning all [08:15] hi jam [08:22] hi poolie [08:22] you've been quite active on email after being gone :) [08:26] oh, really? [08:26] i was only gone for a day [08:26] i do feel like i've been having a good few weeks though [08:31] jam anyhow i battled with buildds and ec2 today [08:31] and i haven't actually touched memory usage :/ [08:31] so i don't have much to say [08:31] other than that i'm glad i was heading in the direction you described [09:02] 'morning [09:21] morning all [09:25] hi mgz, jelmer [10:23] when I branch from some place, work on my new branch and commit to it before merging with the branch I branched from ... Will the details of the commits to my branch be visible in the other one, or will it be treated as a single commit? [10:24] yes and no, though bzr log will by default only show the merge [10:24] you get the best of both worlds :) [10:24] what exactly does that mean? [10:25] yes the data of every commit ever is visible [10:25] the information is kept, but the default view only shows the 'mainline' [10:25] no by default 'bzr log' will not show the branch merged in, just the merge commit [10:39] oh, ok. I'll need to consider my personal comments, then :) [10:40] that's good general advice :) [11:10] weird failures ;_; [11:14] the problem with the windows bot being red for so long is I have no idea which of these are due to path escaping changes [11:44] mgz :-/ [11:58] vila: just posted summary in bug 842223 mp [11:59] Launchpad bug 842223 in Bazaar "Change to tilde escaping causes test failures" [High,In progress] https://launchpad.net/bugs/842223 [11:59] maybe just something went wrong with the building of extensions on babune? [12:00] I don't think I caused them at any rate, so this branch can probably still land [12:01] and the last main windows babune build got through without bailing trying to remove a shell script, which is great [12:01] * vila reads [12:03] so, summary, this should land and I should check the extensions build on babune right ? [12:03] I think so. [12:04] this was using /debug/ not /Windows/ [12:04] and we've not touched debug in a while. [12:06] right, but the /debug/ job rebuilt some extensions, nothing suspicious there [12:06] or is it ? [12:16] mgz: ^ ? [12:18] the rebuild in itself isn't suspicious, I started at an older revision, so there were pyrex source updates in between [12:19] * mgz downloads the log to have a look too [12:19] which are indirectly reflected by the compilations [12:23] there's an error from make saying format incorrect de paramétre [12:23] probably not relevent [12:24] yeah, bogus mount, spurious AFAICT [12:24] * mgz notes for future reference, altgr+; e [12:25] hehe, no, that's an agrave accent not an acute one ;) [12:25] dammit, I had that first [12:25] altgr+#, e -> è then [12:25] yup [12:26] and the mystery of the vanishing bug 842233 failures is resolved [12:26] Launchpad bug 842233 in Bazaar "InvalidURL from tests for local_path_from_url on windows" [Medium,Confirmed] https://launchpad.net/bugs/842233 [12:26] the end of the log is "lost connection" [12:26] I've lost altgr on my keyboard long ago anyway so feel free to not type accents ;) [12:27] so they weren't run [12:27] ha [12:27] good ? :D [12:27] would be nice if babune clearly distinguished between "all tests run, some failed" [12:28] and "stuff went seriously wrong" [12:28] shouldn't subunit handle that ? 'lost connection' comes from there no ? [12:29] I never remember to look at the test count, and it's not immediately obvious [12:29] well, subunit doesn't help, certainly. [12:34] ææßßððAaaseaphews [12:34] I see why you removed altgr now [12:34] I just got stuck in an alternate land where my input made only funky characters [12:35] hehe, I *lost* it and since I use it very rarely I didn't notice ;) [12:35] it seems to be bound to alt now [12:41] :) [12:41] i like the cømpose key [12:42] right, that the one I should use :) [13:13] are commit messages used for anything other than telling other humans about a project? I've noticed that some people seem to use a very formal commit "format", whereas I just write the stuff I've done. [13:16] jo-erlend: some humans use conventions to communicate ;) But really they are just conventions. Unless a project use higher level tools to process these commit messages, they are just strings as far as bzr is concerned [13:16] jo-erlend: it's a social issue, generally you want to fit in with what the project you're contributing to does, or if its your own project make up the rules [13:16] for instance, in bzr itself, [13:16] people do commit messages in feature branches however they want, [13:17] but then when our automated lander merges the feature to the main branch it adds the committer and proposer to the commit message which by convention is a one sentence overview [13:18] using the structured stuff for commit like --fixes and --author is better than munging those into the message [13:19] if you're writing "patch from X fixing bug N" then you're doing something wrong in my view :) [13:20] is fixes just a label, or is it linked to a bug tracker? [13:22] it's stored as aURL [13:32] oh, ok. [13:33] but I guess it has better understanding for bugs stored in launchpad? [13:36] mgz: hi [13:36] mgz: just looking at your recent comment [13:36] mgz: the new behaviour seems right to me [13:38] jelmer: yeah, but does show that I didn't succeed in getting the exact tilde handling as before [13:38] only having to change one test isn't too bad, I just fear other fallout [13:38] jo-erlend: launchpad itself has some special integration, and I think some other bug tracker software has some too [13:40] eheh, jam's comment on pylzma is funny [13:41] mgz: I've seen cases where tests were *enforcing* a bug [13:45] mgz: well, you've submitted 3+ times now I think, and nobody gets a failure message :) [14:17] I seem to have accidentally broken the access restrictions on my home bzr+http server [14:17] not a bad thing right now, as I wanted to test against a remote http repo === aj00200_ is now known as aj00200 [14:46] mgz: I've updated switch-colocated to include tests for unicode colocated and other branches [14:47] that also involved using "real" branch names rather than url encoding for the "sibling" branch support in switch [14:49] vila: any plans for Branch._get_store() ? :) [14:49] huh ? Shouldn't be needed, what's the use case ? [14:51] vila: ah, hmm. I guess Branch._get_config_stack() then? [14:51] or Branch.get_config_stack() [14:51] we already landed that no ? :) [14:51] right :) [14:51] I guess we'll just need a custom RemoteBranch.get_config_stack() implementation which uses RemoteBranchStore or something similar [14:53] right, there is already a RemoteBranchStack [14:53] jelmer: do you encounter a issues with it ? [14:54] I'm seeing VFS access over HPSS from BranchStore [14:54] vila: RemoteBranch.get_config_stack() returns _mod_config.BranchStack(self) [14:55] right, RemoteBranchStack is a bit hackish, let me find the relevant comment [14:55] vila: also, RemoteBranchStack still uses BranchStore so presumably will involve VFS calls too [14:56] if you use the old config scheme you also trigger VFS calls [14:57] this should be better once http://pad.lv/832042 is fixed [14:57] Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] [14:58] +# Needed for 'stacked_on_location' *only* which use a hack that could be [14:58] +# removed when each config file is read only once. This stack is not yet used [14:58] +# in branch.py -- vila 2011-09-06 [15:01] ah, thanks [15:01] vila: btw, that bug is in progress but not assigned? [15:01] hehe, I was angry :) [15:03] jelmer: fixed (or rather assigned ;) [15:04] vila: :) [15:05] not sure yet if I should finish migration options before or after fixing it [15:05] s/migration/migrating/ [15:07] vila: after, IMO. we shouldn't really be adding more VFS calls [15:08] I don't think we added some so far ? [15:08] vila: Branch.get_config() doesn't use VFS calls AFAIK, but Branch.get_config_stack() does [15:08] but the remote config stuff is one of the most confusing so I may have miss a case [15:08] vila: also, it's nice to have the design (including lokcing, etc) of the config stacks finished before we start using it in anger [15:09] locking should be ok [15:10] ha, looking at remote.py, right, not a VFS but still a request so in the end, it will be a single VFS instead of at least one request per option [15:10] vila: I mean locking in combination with not reading/writing config files for every option touched [15:11] vila: plus the overhead of enabling VFS mode [15:11] oh, that, right [15:13] if I'm not mistaken, the actual behavior for remote objects is to query the config for each option (without caching it) so doing a single VFS call will be a win [15:13] as for locking, we are already under a branch lock so we reuse it [15:14] i.e. at worst, even today, we do one VFS call instead of a query and in the end, we'll get rid of the queries [15:15] vila: but we should be moving away from VFS calls, not introducing new ones [15:15] one step at a time :) [15:15] once we know which VFS calls are still needed, we can turn them into queries [15:16] vila: sure; I'm just saying I don't think we should be switching to config stacks while they're introducing more VFS calls [15:16] or reuse the existing ones (but that sounded too hairy last time I looked) [15:16] jelmer: what do you propose then ? [15:16] vila: adding a HPSS call for branch stores [15:18] premature design, the needed calls will be fully defined when all the options are migrated [15:19] and *requiring* HPSS calls will break backward compatibility with older servers [15:19] vila: that means introducing more VFS calls until all options are migrated, I really think that's a bad idea. [15:19] vila: I didn't say anything about requiring HPSS calls. Just about not relying on VFS calls. [15:20] *one* VFS call by store instead of one query by option [15:20] vila: who says we can't have a VFS call for retrieving the stack contents? [15:20] s/VFS/HPSS/ [15:20] the point is to reduce the queries, VFS or not [15:20] backward compatibility for older servers [15:21] you can't switch to stacks using HPSS calls *only* [15:21] sure, either way we'll still support falling back to VFS if the serve doesn't support newer calls like we do with all HPSS calls [15:21] *server [15:22] HPSS calls are worth only if they replace *several* VFS calls, it doesn't matter here [15:22] vila: eventually we want to get to a VFS-free HPSS server [15:22] sure [15:23] but I'd rather to an HPSS call that also returns the branch store when opening the branch then... [15:23] s/rather/rather add/ [15:23] in that case that would mean one less roundtrip [15:23] but just adding an HPSS call to replace a single VFS call ? What's the gain ? [15:24] vila: it's not tied to the underlying file format [15:25] vila: wouldn't the config be read each time the branch is read locked? [15:26] jelmer: it depends on whether the config file is always read when a branch is read locked :) [15:27] but it may be a win anyway if it avoids a roundtrip in most cases [15:28] vila: anyway, my point really was about fixing when we read and write config files first [15:28] so that we have a stable config stack/store API to rely on [15:30] vila: I think the HPSS thing matters too, but that should be a lot easier to fix (and not have any impact on callers) [15:30] you totally lost me [15:31] vila: I think we should fix bug 832042 before using config stacks/stores in anger, because it probably will impact API users [15:31] Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 [15:32] jelmer: if you find a way to fix it without a new config scheme, please go ahead, I bang head for a long time before reaching the conclusion that the new design was the best way to achieve that :) [15:33] vila: I think we should fix it *in config stacks/stores* before we start switching options over [15:34] jelmer: wrong idea, that would multiply the potential issues [15:35] vila: if we don't then I think we probably will have to fix callers of the stack/store API when bug 832042 gets fixed. [15:35] Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 [15:37] chicken-and-egg [15:38] I did propose a stack registry to make sure stack/store acquisition could be controlled [15:38] this was pushed because there was no clear need [15:39] I'm now working to make the needs clearer [15:39] Sorry, but I don't see how a stack registry is relevant here. [15:39] I know :) [15:40] as a caller, I want to know when my changes get written to disk if I do: Branch.get_config_stack().set("foo", "bar") [15:41] today: during the call, tomorrow: when you release the branch write lock [15:42] vila: it would be nice ot state that in bug 832042 at least [15:42] Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 [15:42] at the moment it's very vague about that [15:43] devnotes/configuration.txt has a more precise definition and refers to bug #832042 [15:44] but still a bit hand-wavy [15:44] vila: I don't see any references to 832042 in configuration.txt [15:45] is this your private notes? [15:45] grr doc.bazaar.canonical.com is down ?? [15:48] ha right, the bug reference is a local edit, I was referring to the last section 'Why and when locking config files matter' [15:50] vila: doc/developers/configuration.txt in lp:bzr ? [15:52] no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt [15:53] no, http://bazaar.launchpad.net/~bzr-core/bzr/devnotes/view/head:/configuration.txt#L760 even [15:55] ah, ok [15:55] vila: thanks [15:55] I'll paste the relevant bits into the bug [15:59] (it's really confusing to have two documents about this btw, I don't really see the point of lp:bzr/devnotes) [15:59] not implemented yet stuff [16:00] right, but that's true for doc/developers in lp:bzr too [16:00] err, no, the later is targeted at developers and refers to internals as they work today (at least that's my understanding) [16:05] vila: I've landed several specs there before they were implemented, plans.txt was created specifically for that purpose [16:06] really ? [16:07] there is no plans.txt right now though [16:07] vila: there is, doc/developers/plans.txt in lp:bzr [16:08] * vila blinks [16:10] my understanding of devnotes was that it was just a place to stow random notes from sprints, I don't think I've looked at it since Barcelona [16:10] anyway, the configuration.txt in there is a good read [16:10] the devnotes one you mean ? [16:11] I think you sent me a copy of it earlier, I didn't realize it was in there [16:11] vila: yeah [16:11] Ha, you read it at least once, I was scared for a second :) [16:14] jelmer: if you want more read on config, enjoy https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 ;) [16:16] vila: sure, I'll have a look [16:26] vila: https://code.launchpad.net/~vila/bzr/config-command/+merge/82421 now includes aliases too, is that intentional? [16:27] vila: http://pastebin.ubuntu.com/740351/ [16:27] wow, nice catch, no it's not [16:27] or is it... [16:28] errr [16:28] no not intentional [16:28] but is it such a bad idea ? Yes, probably === zyga is now known as zyga-afk [17:19] jelmer: fix pushed and comment added to the mp explaining the root issue [17:21] * jelmer looks [17:23] vila: wouldn't this break "bzr config" for people who currently don't have a [DEFAULT] header set? [17:25] I don't think we really support having a no-name section in bazaar.conf, some tests were relying on this assumption but IIRC bazaar.conf is created with the DEFAULT section (and documented as such) [17:25] ok [17:26] the old code is pretty blurry around this specific issue === beuno is now known as beuno-lunch [17:35] yeah [17:45] jelmer: reviewed some of your updated branches, just a few little things [17:46] mgz: thanks [17:46] vila: it looks a bit odd that list option values are in quotes [17:46] vila: I know why, but still [17:46] anyway, MP looks good otherwise [17:49] jelmer: yup, the issue is that we don't rely on the store to automaGically interpolate lists, we *can* do either (depending on option registration), we default to not. [17:49] jelmer: regarding the HPSS call, I agree it can and should be done, [17:50] jelmer: but it doesn't have to be done before or after $this, it can be done in parallel [17:50] jelmer: and indeed, some _get_store is needed ;) [17:51] jelmer: I had to re-think our discussion backwards, but I've connected the dots :-) [17:54] vila: ah, ok [17:54] vila: I'm still working on Andrew's HPSS branch, I might have a stab at the config store one too [18:06] hpss still scares me... [18:15] mgz: it scared me too, but I found it quite reasonable once I dug into it. The main thing that makes it hard to work with is that the code is so scattered across different bits of bzrlib. [18:15] yeah, finding which bits are actually still live can be a bit of a challenge, and understanding the naming === beuno-lunch is now known as beuno [18:30] vila: FWIW, "bzr config -d lp:..." is 11 HPSS calls before your change, 25 after (13 VFS) [19:11] jelmer: (not here) can you paste that with a full (reproducing) url as a comment in the mp ? [19:16] If I want to run a command after a particular branch gets a new HEAD revision, where do I put that hook? [19:18] vila: done [19:18] glyph: a bzr plugin which installs a post_tip_change hook. I believe we have examples somewhere, hang on.. [19:20] jelmer: actually maybe I'm saying this wrong [19:20] I want to install this on the server side of things [19:20] the branch that gets pushed to [19:22] glyph: in both cases, the pre_change_branch_tip / post_change_branch_tip hooks should work [19:22] glyph: see lp:bzr-testrunner for an example of a plugin which uses the pre_change_branch_tip hook [20:15] jelmer, i'm trying to make a blackbox test to reproduce bug 889872. since the simple tests in test_pack don't fail, i assume there needs to be a certain amount of data available. any idea how much that might be, based on the failures you saw? [20:15] Launchpad bug 889872 in Bazaar "not a valid key error" [Critical,Confirmed] https://launchpad.net/bugs/889872 [20:17] GRiD: hi [20:18] GRiD: no idea, sorry - it happened on my bzr and samba repositories, both of which are pretty big [20:19] right ok. is there a way to generate a test repo during a blackbox test with that kind of data, or no? [20:20] even if there was, i assume it would be slow. [20:21] GRiD: perhaps there are other parameters you can tweak to make it happen earlier? [20:21] GRiD: I'm not really familiar with the index code unfortunately [20:24] jelmer, ok thanks. i'll play with it. [20:27] well i've duplicated it on a repack of bzr at least. === abentley_ is now known as abentley [21:23] hi all [21:23] hi grid, jelmer, [21:26] hi poolie [21:34] hi poolie [21:34] hi hi [22:13] mornin everyone :)