[00:09] lp's bug database hates me [00:10] BasicOSX, or, it's down for a bit [00:10] and will be back in ~30 minutes or so [00:13] beuno: should be back much sooner than that [00:13] its only an os reboot [00:13] though over a few machines [00:17] * beuno likes pleasantly surprising people [00:19] lifeless: dude, these are not laptops. some of these machines take 5 minutes just to *POST* [00:19] * thumper wonders what a POST is here [00:20] I'm not Scotty, I don't over-estimate the downtime just for the hell of it [00:20] thumper: BIOS POST [00:20] the BIOS thing that happens before first stage bootloader [00:20] Geez... no wonder people are complaining about Ubuntu boot times :P [00:24] elmo: sorry [00:25] elmo: on the other hand, how is your scottish brogue? [00:43] * Kinnison ruffles elmo [00:44] * Kinnison 's new machine takes 45 seconds to get from poweron to grub, and then 15 seconds from there to login [00:44] POST sucks [00:46] Salutations. I'm running Eclipse Ganymede and I'm trying to install the bzr plug-in. The plug-in itself installed fine, but step 1 in the installation instructions has me stumped: "install the bzr-xmloutput plugin" - I cannot find an Intrepid package for it. Am I missing something? [00:49] owh: it's likely just a .tgz [00:49] which you drop into ~/.bzr/plugins [00:49] (unpacked) [00:51] So, that will do it for one user. What about the other users? I'm more than a little surprised that we seem to be back to dropping files into a directory - that feels like stepping back a decade. [00:52] owh: its packaged in jaunty [00:52] https://edge.launchpad.net/ubuntu/+source/bzr-xmloutput [00:53] * owh wonders if that will just install under Intrepid. [00:53] probably it will [00:54] yay for the jaunty package [00:57] Nope, it depends on python-central >= 0.6.11 [00:57] Crap [01:04] Well, while less than orthodox, installing the latest Janty python-central + bzr-xmloutput seemed to install. How do I test to make sure it actually works? [01:04] owh: bzr help plugins [01:04] owh: should list xmloutput [01:05] Magic [01:05] Much Tah. [01:05] Now to make it all work with Eclipse :) [01:07] * jelmer wished somebody packaged bzr-eclipse [01:08] igc: want to put two things on the eclipse list? [01:08] igc: package for ubuntu and windows :) [01:10] thumper,igc: fwiw there is some initial work on a debian package in the pkg-bazaar bzr repository [01:10] but I couldn't figure out how to build bzr-eclipse non-interactively [01:10] jelmer: did you ask veterok [01:12] Hmm, seem to be running into a problem. In the Team Synchronisation View, I click on the Synchronise Button, which brings up a dialog with synchronisation types. I chose Bazaar, and initially it told me that there was an invalid path. I pointed it at /usr/bin/bzr and it stopped complaining, but when I click Finish, nothing happens. Next is greyed out. [01:17] odd [01:17] uhm [01:17] I have no idea :) [01:21] lifeless: no [01:21] lifeless: I tried out the pre-built version of bzr-eclipse but found it had to many rough edges [01:22] lifeless: so froze my effort to package it [01:22] that was a while ago though, it may have gotten better since [01:23] omg annoying voice guy won't stfu [01:23] ? [01:23] oops wrong window. [01:24] sorry :) [01:24] NfNitLoop: heh [01:24] NfNitLoop: had me laughing [01:24] this cellphone connection is laggy... thought i was typing elsewhere [01:25] How do I go about figuring out why I cannot create a bzr team synchronisation in eclipse? [01:25] owh: I'd love to help you but I don't know enough about eclipse [01:25] owh: make sure have the eclipse version the bzr-eclipse page talks about [01:26] I do, 3.4.1 which is >= 3.3 [01:27] isn't that incompatible? I seem to recall a different build of the eclipse plugin being needed [01:37] Seems to be working. That's a 'feature' not a bug :) [01:38] Not that I like the word "seems" in a development environment, but backups are there for a reason :) [03:07] trace generates _very_ odd results sometimes [03:07] hi [03:15] hmm, could be decorators messing it up [03:34] hi all [03:36] hi igc [03:37] hi lifeless [04:02] hi edcrypt [04:02] thumper hi [04:03] edcrypt: I haven't looked at the source yet, but I have a couple of comments on the readme :) [04:03] edcrypt: although first a question [04:03] edcrypt: for the init-workspace, you have the sandbox outside the repo [04:03] edcrypt: why? [04:03] edcrypt: I would have thought it easier to have MyProject be the shared repo [04:03] edcrypt: with trunk [04:03] edcrypt: and the sandbox checkout [04:04] edcrypt: then you don't have two different repo styles for --feature-branches or other [04:04] I'm really concerned that all these 'make it easy by layering' approachs are just making the problem worse [04:04] lifeless: all problems are solvable with another layer of indirection L) [04:05] * thumper snickers [04:05] thumper: not big motive, it's just the layout I'm used to [04:05] to fix it we need to remove the sand grains causing the issue [04:05] edcrypt: personally I have my lightweight checkouts outside my repo [04:06] edcrypt: but I think that the plugin should be simple enough to understand without having two different layouts [04:07] thumper: I think I agree. [04:08] I'm pretty sure that switch is smart enough now that `bzr switch feature-x` will DTRT [04:08] rather than `bzr switch ../feature-x` [04:10] thumper: it will search in branch-root/../ [04:10] so yes, qualified [04:11] man, it is going to take a long time to index all of bzrlibs tests [04:11] why is trace.Trace so slow [04:13] edcrypt: also the `update-sandbox` command will do weird things if the checkout is no longer trunk [04:17] 10 tests in 20 minutes [04:17] 2 minutes each, 18K tests, 36K minutes :( [04:17] 600 hours :( [04:17] 24 days. faaaark [04:19] lifeless: why are you doing this? [04:19] lifeless: I guess that's what happens when you run python functions for every bytecode... [04:19] thumper: right. it should check that. [04:20] thumper: thanks for the feedback, [04:20] spiv: wheeee [04:20] thumper: I have written a plugin [04:20] thumper: it indexes tests by the code they exercise [04:20] edcrypt: my pleasure [04:20] then when you run 'bzr selftest --changes' it calculates the changed code and looks up the relevant tests [04:21] * thumper nods [04:21] it works, with some various caveats. I finished it up last night, but without a full index its useless; so I haven't put it out there yet [04:33] spiv: possibly I should just use lsprof [04:33] spiv: and extract stuff from that, but I do need the module paths [04:33] * lifeless will play after work [04:35] jelmer: ping [05:02] * igc lunch [05:09] Am getting a bzr return code of '3' from a bzr checkout - no output unf :-( Any idea what a return 3 from a bzr checkout is? My googlefu can't find a simple table of codes. [05:09] "failed" [05:09] hth :) [05:10] poolie: not really :-D [05:10] is there something in ~/.bzr.log? [05:11] spm: no output at all?! [05:11] spm: pastebin please [05:11] poolie: yes actually! ta. but is the generic connection failed, pls to using -Dhpss message. hmmm. [05:11] lifeless: from the buildbot log. looks like it throws away stderr/out [05:12] so .bzr.log has: https://pastebin.canonical.com/16383/ [05:13] builbot slave log has: https://pastebin.canonical.com/16384/ cf line 21 [05:14] spm: haven't looked yet but I bet 'fix your dns' [05:14] heh [05:14] we'll need stderr thats where the openssh output will have gone [05:15] hm i thought we removed that "please use -Dhpss" message [05:15] maybe he has an old bzr [05:16] poolie: Yikes! 1.8 [05:16] spm: please be using something from this year [05:17] spm: but I bet you a liquid refreshment that its dns [05:17] I could really learn to hate ec2... dns seems so fragile there. [05:23] igc: I don't really understand your LocalRemoteBranchTypes thing [05:27] lifeless: give it another 30 minutes - what's there was just a 'save-before-lunch' snapshot [05:28] igc: ok; if its useful I can say what confused me [05:29] lifeless: sure, go ahead [05:30] Given commonly recommended practices like feature branching, the intention when branching locally (start me a new line of development) is different to the intention when branching from a remote location (grab me my copy of that project). [05:30] that was the bit that confuses me [05:32] I don't know how often you grab a copy of a project without the intent of making changes; but it sure seems to me that mirroring (grab a copy) is less common than editing (get me something I will make changes to) [05:32] s/you grab/one grabs/ [05:33] Anyhow, hope that helps; and please do think about the root cause of the issues; I don't think its accidental that we are having a lot of growing pains here - our design is broken and we need to fix it. [05:37] lifeless: poolie: fyi. pebkac, effectively. ssh-agent fail. fixed now. ta, and sorry for the false alarm as it were. [05:37] damn, I owe you water [05:38] high quality tap water at that! No less! [05:38] I shall piss in the cup myself [05:39] ENSFW [05:44] I've seen NSFW, and VNSFW, what's ENSFW? [05:44] "error nsfw" [05:44] extremely? ahh, ok [07:02] hi all [07:49] window level all [08:01] If I make a branch append-only, will the smartserver enforce that? In this case I cannot assume that the people using the branch are not malicious. [08:06] lifeless: pong === jrydberg_ is now known as jrydberg [08:17] jelmer: see mail [08:56] lifeless: push_branch also pushes to existing branches [08:57] BzrDir.push_branch() will open the underlying branch if there is one [08:59] jelmer: I know, thats part of the issue ;P [09:06] lifeless: but you want to get at a Branch without getting at a BzrDir first? [09:08] lifeless: anyway, the suggestions for the helper seem reasonable [09:09] lifeless: seems a bit similar to BzrDir.open_containing_tree_branch_or_repository [09:09] lifeless: ie BzrDir.open_branch_or_bzrdir() [09:11] jelmer: it may create :) [09:11] jelmer: look at the network trace [09:12] lifeless: so basically, the only thing I can't do is a create without a push [09:12] lifeless: which trace? [09:13] the one in my mail [09:15] * igc dinner [09:19] how do you deloomify a branch? [09:20] jml: bzr export-loom [09:20] meh [09:20] ok, what I really meant was, how can I make this error go away? TypeError: open() got an unexpected keyword argument 'ignore_fallbacks' [09:21] upgrade your loom plugin with aaron's patch [09:21] thanks. === sabdfl1 is now known as sabdf1 === fta_ is now known as fta === serg_ is now known as serg [10:50] re === nevans1 is now known as nevans [13:27] wgrant: it certainly should if they are using the smartserver to access it [13:31] is there a jaunty user around that could test https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa/+files/bzr-svn_0.5.4-1~bazaar1~jaunty1_all.deb from the beta ppa? [13:32] LarstiQ, sure [13:34] ah [13:34] doesn't work with nightlies [13:58] abentley: ping [14:03] vila: pong [14:05] abentley: at the end of bzrlib/merge_directive.py MergeDirective2 is registered with a string mentioning 0.19 while its _format_string attribute mentions 0.90, is it deliberate ? [14:05] vila: doesn't sound like it. lemme see... [14:06] LarstiQ, works perfect [14:06] beuno: thanks! [14:07] vila: Yes, it looks deliberate. You see that it's registered twice, right? [14:07] yes [14:08] so why ? [14:08] 0.19 never existed. It got renamed to 0.90. [14:08] But by that point, there were already merge directives in the wild that used 0.19 [14:08] abentley: oeuf corse [14:09] So this was to retain compatibility with those merge directives. [14:10] abentley: added as comment [14:12] abentley: and thanks :) [14:12] vila: np === ja1 is now known as jam [15:30] hey vila, how's it going? [15:31] jam: fine, getting closer to submission :) [15:31] I at least saw your commit show up :) [15:31] jam: Ha ! Good, still not here, but at least I fixed the setup (again :-/) [15:31] vila: btw, my recent LRUCache patch *might* be part of the answer for why branch conversions leak a bit of memory [15:32] We were "leaking" LRUNodes by leaving in the linked-list, but not in the dict [15:32] jam: Next on my list to check :) [15:32] The nodes themselves aren't large enough to explain it, but maybe them coupled with referencing a key that then gets repeated would be enough [15:33] jam: and multiplied by the number of LRUCache, multiplied by the number of autorepack during the conversion... [15:34] jam: damn, just realized I haven't approved your patch :-/ [15:35] vila: well, when we get rid of the containing btree reference, it should gc the lru nodes [15:35] so... maybe [15:35] certainly I think the fix will help [15:35] and in the meantime I'll finish perf testing the link indirection [15:35] it seems to cost about 10% overhead [15:35] ECONTEXT link ? [15:37] vila: LRUNodes are in a double linked list (.next, .prev) [15:37] which means that if you just del LRUCache [15:37] they stay around until gc.collect() runs [15:37] ha, that link :) [15:38] You can use 'prev_key' and then look up the prev object in LRUCache._cache [15:38] the problem is it adds a dict overhead [15:39] vila: current timing: http://paste.ubuntu.com/152135/ [15:39] That is with 2.8M tuples [15:39] 8.2k unique [15:44] jam: this measures only the cache overhead right ? [15:44] right [15:44] this is with a test where a miss has 0 cost [15:44] I just do except: cache[val] = val [15:45] so, you're trying to be quicker without leaking memory, I'd say we don't want to leak memory, whatever the price is :) [15:46] vila: this isn't about *leaking* specifically [15:46] it is just whether the data gets cleaned up during "del foo" [15:46] or during "gc.collect()" [15:46] jam: sure, I shouldn't have say leaked, sry [15:46] vila: the patch you approved was about a more genuine "leak" [15:46] where not even gc.collect() would grab it [15:47] because they were still 'live' in the linked list [15:47] vila: And gc.collect() runs automatically every 700 unmatched allocations or so [15:48] so the data will get cleaned up eventually [15:49] I *think* I want to do it anyway [15:49] I just need a real-world benefit [15:49] and maybe big conversions are it [15:49] since during autopack we'll be generate a new btree index, and "throwing away" the old one [15:50] by the way, the xml cache trick seems to reduce memory pressure too here, I'm (approx) at 20 out 27 hours (instead of 41) and the memory is at 3GB ( instead of 4GB) [15:51] jam: right, and we autopack several times :) [15:51] one just triggers here :) [15:52] vila: yeah, the xml trick means that for the 100 or so revision trees we have in memory [15:52] we only have 1 copy of 99% of the inventory objects [15:53] I would be surprised for it to be 1GB [15:55] jam: those 3 and 4GB are very rough, and the conversion is still not done, yet, from memory (mine) this was growing linearly with time [15:55] then again, it could be *huge* for improving fragmentation [15:56] jam: that's the problem :) We really need to find a better way to measure that fragmentation [15:56] vila: bzr branch lp:~jameinel/+junk/py_memory_dump :) [16:05] jam: Hmpf man malloc(3) BUGS section 8-/ [16:12] <__alexandre__> hi everybody [16:13] <__alexandre__> I have a problem using bazaar and I need some help. Am I in the right place ? [16:13] hi, jelmer is around? [16:14] __alexandre__: simply ask the question [16:14] <__alexandre__> I'm trying to use bazaar with an HTTP server (lighttpd) [16:14] <__alexandre__> but with basic authentification [16:15] <__alexandre__> and bazaar does not ask me for my password when it gets 401 error [16:15] __alexandre__: use a username in the url [16:15] http://username@host/... [16:15] <__alexandre__> I tried [16:15] <__alexandre__> but I get a big traceback [16:16] <__alexandre__> if I set the password with it [16:16] <__alexandre__> something like [16:16] <__alexandre__> http://username:password@localhost/the_path [16:17] <__alexandre__> even just http://username@localhost does not work [16:22] __alexandre__: can you pastebin the traceback somewhere ? What bzr version are you using ? [16:23] <__alexandre__> Bazaar (bzr) 1.6.1 with python2.5.2 [16:24] __alexandre__: hmm, I'm affraid you need to upgrade, 1.6.1 is pretty old and some bugs have been fixed in that area [16:24] <__alexandre__> bzr: ERROR: pycurl.error: (65, "necessary data rewind wasn't possible") [16:24] <__alexandre__> Traceback (most recent call last): [16:24] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 857, in run_bzr_catch_errors [16:24] <__alexandre__> return run_bzr(argv) [16:24] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr [16:24] <__alexandre__> ret = run(*run_argv) [16:24] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases [16:24] <__alexandre__> return self.run(**all_cmd_args) [16:24] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 840, in run [16:24] <__alexandre__> from_location) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 878, in open_tree_or_branch [16:25] <__alexandre__> bzrdir = klass.open(location) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 756, in open [16:25] __alexandre__: eeerk, pastebin ! not here ! [16:25] <__alexandre__> return BzrDir.open_from_transport(t, _unsupported=_unsupported) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 793, in open_from_transport [16:25] <__alexandre__> redirected) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/lazy_import.py", line 125, in __call__ [16:25] <__alexandre__> return obj(*args, **kwargs) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/transport/__init__.py", line 1616, in do_catching_redirections [16:25] <__alexandre__> return action(transport) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 770, in find_format [16:25] <__alexandre__> transport, _server_formats=_server_formats) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1593, in find_format [16:25] <__alexandre__> return format.probe_transport(transport) [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 2580, in probe_transport [16:25] <__alexandre__> server_version = medium.protocol_version() [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/smart/medium.py", line 531, in protocol_version [16:25] <__alexandre__> client_protocol.query_version() [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/smart/protocol.py", line 770, in query_version [16:25] <__alexandre__> self.call('hello') [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/smart/protocol.py", line 618, in call [16:25] <__alexandre__> self._request.finished_writing() [16:25] <__alexandre__> File "/usr/lib/python2.5/site-packages/bzrlib/smart/medium.py", line [16:25] <__alexandre__> oh ok [16:25] <__alexandre__> I'm using the one which is in Ubuntu repository [16:25] <__alexandre__> oups sorry [16:25] <__alexandre__> (which are not always uptodate) [16:26] <__alexandre__> ok I'll try with the last stable version [16:26] <__alexandre__> thank you ! [16:27] __alexandre__: anyway, the relevant error here is: ERROR: pycurl.error: (65, "necessary data rewind wasn't possible") [16:27] and I'm pretty sure many fixes applies to solve that :-) [16:29] __alexandre__: if you look at https://launchpad.net/bzr/ you'll find instructions on how to add a bzr sources.list entry for any Ubuntu version, and you can choose to use stable, beta or nightly build of bzr [16:32] <__alexandre__> ok it seems to work with a newer version. thank you [16:58] vila: just checked 'man malloc', I'm not particularly worried about the bug [16:59] jam: no, no worries, just... ugh [16:59] It just means that if you have "for(i = 0; i < infinity; ++i) {malloc(100000)} [16:59] it will over succeed [16:59] pages aren't actually acquired until you touch them [16:59] ...and then randomly kill some processes [16:59] I remember benchmarking it in the past [20:10] hello, I need help with nested trees: when I "join --reference" a subtree "bzr st" on the outer tree lists ".bzr" directory of subtree as "unknown". is this correct behavior? (I am using bzr 1.13.1) [20:12] btw, "bzr st" also lists all the other files/directories within the subtree as "unknown", too... [20:18] no one who can help me? I'd love you use nested trees, because they seem to be exactly what I need. [20:19] jonnydee: nested trees (especially reference) have seen recent development, I don't think 1.13 has all of that. [20:19] * LarstiQ is bad with time [20:19] jonnydee: http://bazaar-vcs.org/NestedTreeProgress [20:20] particularly, the feature that bzr will remember the revision of the inner tree within the outer tree is very cool!!! [20:21] LarstiQ: I've read this site, but I wonder why bzr 1.13.1 already has "join --reference" released... [20:21] (thanx for your reaction :) ) [20:21] is there a plugin with a pre_commit hook for test before commit? [20:22] *not* PQM ;-) [20:22] jonnydee: it's not in bzr.dev, let me check 1.13 [20:23] jonnydee: --reference is indeed on join in 1.13, but join itself is a hidden command. [20:24] jonnydee: anyway, it boils down to: I'm afraid nested trees as released will not do what you want, just yet. [20:25] jonnydee: depending on what you want, you could 1) wait 2) try Aaron's recent code 3) use scmproj or config-manager 4) without reference, manual, etc [20:25] ahh ok :) but do you know what can be done with the current release? I mean can I use join in any useful way? [20:26] jonnydee: there are cases where it can be usefully used, yes [20:26] jonnydee: but what's your usecase? Maybe we can help you find something for that. [20:28] I would like to have a 'lib' branch as a subtree of another project branch. [20:29] the lib branch is versioned itself [20:31] currently, I maintain a branch with all my software projects in it. but this turns out to be not quite practicable, because when I develop a feature for project x I branch the complete tree with all projects [20:31] pretty much the canonical case for by reference nested trees, indeed [20:31] so I would like to have a separate branch for each project [20:32] and get common things for each project by subtrees [20:32] yes, I think it's exactly the use case described in http://bazaar-vcs.org/NestedTreesDesign [20:33] jonnydee: I haven't looked at scmproj (https://launchpad.net/bzr-scmproj) since it's redesign, but I've used it in the past to accomplish this [20:33] jonnydee: so you might want to look at that for something that works right now [20:34] oh, thanks for this hint :) I'll have a look to it. and thank you very much for your attention and help :) [20:36] jonnydee: np [20:50] vila: around by any chance? [20:50] I have some testsuite questions :-) [20:50] james_w: lucky you ! :) [20:50] yay! [20:51] I want a way to run the testsuite for a plugin that doesn't depend on the plugin being the one that bzr will load [20:51] what testsuite ? [20:51] so that e.g. "python tests/__init__.py" in the plugin will run its tests regardless of where it is [20:51] * LarstiQ tries to parse that again [20:51] ah, right [20:52] ok, run the test suite without selftest [20:52] yeah [20:52] jusdepending on unittest or using bzrlib.tests features [20:52] ? [20:52] I've needed it a couple of times, so I'm finally going to try and come up with a working solution, so I thought that I would come to the master [20:52] bzrlib.tests would be nice [20:53] and why not use selftest -s bp.myplugin ? [20:53] because that involves making sure that "myplugin" is on the bzr plugin path [20:53] need to test various versions without swapping ? [20:53] I just wrote a quick pre_change_branch_tip hook for running tests [20:54] it gets the branch and a revid, so it exports to a tempdir, and runs the tests there [20:54] james_w: BZR_PLUGIN_PATH=. ? [20:54] james_w: I was thinking about LarstiQ proposal while searching the relevant bug on lp :) [20:54] bit of a hammer [20:55] LarstiQ: yeah, it's a bit annoying as it tries to load like setup.py as a plugin for example [20:55] james_w: ooh [20:55] right [20:55] james_w: if __name__ == "__main__": [20:55] unittest.TestProgram(module=__name__) [20:56] if the incantation I use when doing TDD outside bzr [20:56] so that would be fine for anything not using the bzr extensions? [20:56] vila: how does that differ from unittest.main()? [20:56] it should be fine to use bzr extensions *except* for load_test() and test_suite() [20:57] ah, because of inheritance! [20:58] LarstiQ: main = TestProgram [20:58] in unittest.py ? :-P [20:58] james_w: why not write a 'main()' function which just imports bzrlib.tests and runs itself [20:58] line ~808 :) [20:58] heck, if you want to get crafty, you could have it set BZR_PLUGIN_PATH [20:58] and then run 'bzr selftest -s bp.myplugin' [20:59] ELOOP :) [21:00] vila: not really, it is just a "if __name__ == '__main__':" check [21:00] I suppose it is recursive, but directly terminating [21:00] jam: not the code, the discussion :) [21:00] ok, putting vila's suggestion in tests/__init__.py runs 0 tests [21:00] I proposed -s bp.myplugin earlier :) [21:00] vila: right, and he said the problem was he didn't want to have to put it into path [21:00] so *I* suggested having the plugin put itself into path [21:01] and have the *plugin* call out to "bzr selftest $ME" [21:01] putting it in __init__.py fails as you can't run "__init__.py" as it tries to import parts of the plugin, and plugins haven't been loaded yet so they aren't under b.p. [21:01] so his "python tests/__init__.py" would Just Work [21:01] jam: right, I rule that out too fast maybe (I thought there may be several versins conflicting) [21:02] james_w: if you use b.p. imports then you *must* use bzr to load correctly [21:02] yeah [21:02] so I want to run bzr, but I want slightly more control over the plugins it imports [21:04] bug #316192 [21:04] Launchpad bug 316192 in bzr "bzrlib.plugin.load_plugins() loads system plugins even for non-system bzrlib" [Medium,Confirmed] https://launchpad.net/bugs/316192 [21:04] james_w: well you could put the "if __name__" check very early [21:04] and have it finish with "sys.exit()" [21:04] (as in, put it before the other 'import' statements, etc) [21:04] bug #82693 [21:04] Launchpad bug 82693 in bzr "Ability to run tests in a particular plugin" [Wishlist,Confirmed] https://launchpad.net/bugs/82693 [21:12] jam, james_w : we could add a test-plugin command that will implement jam suggestion above (load the plugin and run selftest -s bp.plugin) with options to load *only* the plugin or *also* the plugin and accept the plugin path as a parameter [21:13] that would be great [21:13] I'm getting there [21:13] however, the plugin is currently loaded as "bzrlib.plugins.trunk" [21:14] james_w: :-) I know that one, I ended up making my ~/.bazaar/plugins directory a link farm pointing to various ~/src subdirectories [21:14] that's what I have [21:15] I also love a bzr enable/disable plugin that mv in and out the DISABLED directory :-) [21:18] \o/ [21:18] it won't work on Windows though [21:19] if __name__ == '__main__': [21:19] import os [21:19] import subprocess [21:19] import sys [21:19] mv DISABLED? [21:19] dir = os.path.join(os.path.dirname(os.path.abspath(__file__)), "plugins") [21:19] retcode = subprocess.call("bzr selftest -s bzrlib.plugins.builder", [21:19] shell=True, env={"BZR_PLUGIN_PATH": dir}) [21:19] sys.exit(retcode) [21:19] with /plugins/builder -> / [21:19] (symlink) [21:20] thanks team, I'll use this for a while and see how it goes [21:36] zr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt) [21:37] i get that while trying to do a pull [21:37] how do i turn off ca validation [21:37] i use self-signed certs [21:38] Kobaz: Add your cert to the site ca cert list? [21:38] Then you can use self-signed certs /and/ retain some security. [21:38] woot. [21:40] or use http+urllib:// [21:42] LarstiQ: That's the same as turning off ca validation, right? [21:42] exarkun: isn't that exactly what Kobaz is asking? [21:42] Yes [21:42] ah, that way. [21:43] exarkun: yes, I believe it is. [21:43] exarkun: although our use of urllib may have grown certificate validation. [21:44] I wish it did, it's the only thing keeping pycurl alive. [21:45] mmm [21:45] so the only way is to add the ca to the ca store? [21:46] oh wait [21:46] what's http+urllib:// [21:46] i'm using bzr+https:// [21:46] Kobaz: could you try bzr+https+urllib:// ? [21:47] not sure if multiple decorators work, but worth a try [21:48] k [21:48] it's weird though, i'm putting bzr on a new box [21:48] i use bzr+https:// on all my other boxes with no issue [21:48] all on bzr 1.13 [21:49] Kobaz: in bzr 1.13 the server will do more operations; you may be seeing the server itself generatin that error [21:49] bzr: ERROR: Unsupported protocol for url "bzr+https+urllib:// [21:50] it's definitly not the server [21:50] Kobaz: my guess is that all the others do not have pycurl installed [21:50] oh yeah, that's how i fixed it, was removing pycurl [21:51] good night [21:51] so soon? [21:52]