| BasicOSX | lp's bug database hates me | 00:09 |
|---|---|---|
| beuno | BasicOSX, or, it's down for a bit | 00:10 |
| beuno | and will be back in ~30 minutes or so | 00:10 |
| lifeless | beuno: should be back much sooner than that | 00:13 |
| lifeless | its only an os reboot | 00:13 |
| lifeless | though over a few machines | 00:13 |
| * beuno likes pleasantly surprising people | 00:17 | |
| elmo | 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:19 | |
| elmo | I'm not Scotty, I don't over-estimate the downtime just for the hell of it | 00:20 |
| elmo | thumper: BIOS POST | 00:20 |
| ddaa | the BIOS thing that happens before first stage bootloader | 00:20 |
| cody-somerville | Geez... no wonder people are complaining about Ubuntu boot times :P | 00:20 |
| lifeless | elmo: sorry | 00:24 |
| lifeless | elmo: on the other hand, how is your scottish brogue? | 00:25 |
| * Kinnison ruffles elmo | 00:43 | |
| * Kinnison 's new machine takes 45 seconds to get from poweron to grub, and then 15 seconds from there to login | 00:44 | |
| Kinnison | POST sucks | 00:44 |
| owh | 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:46 |
| NfNitLoop | owh: it's likely just a .tgz | 00:49 |
| NfNitLoop | which you drop into ~/.bzr/plugins | 00:49 |
| NfNitLoop | (unpacked) | 00:49 |
| owh | 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:51 |
| lifeless | owh: its packaged in jaunty | 00:52 |
| lifeless | https://edge.launchpad.net/ubuntu/+source/bzr-xmloutput | 00:52 |
| * owh wonders if that will just install under Intrepid. | 00:53 | |
| lifeless | probably it will | 00:53 |
| thumper | yay for the jaunty package | 00:54 |
| owh | Nope, it depends on python-central >= 0.6.11 | 00:57 |
| owh | Crap | 00:57 |
| owh | 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 |
| lifeless | owh: bzr help plugins | 01:04 |
| lifeless | owh: should list xmloutput | 01:04 |
| owh | Magic | 01:05 |
| owh | Much Tah. | 01:05 |
| owh | Now to make it all work with Eclipse :) | 01:05 |
| * jelmer wished somebody packaged bzr-eclipse | 01:07 | |
| thumper | igc: want to put two things on the eclipse list? | 01:08 |
| thumper | igc: package for ubuntu and windows :) | 01:08 |
| jelmer | thumper,igc: fwiw there is some initial work on a debian package in the pkg-bazaar bzr repository | 01:10 |
| jelmer | but I couldn't figure out how to build bzr-eclipse non-interactively | 01:10 |
| lifeless | jelmer: did you ask veterok | 01:10 |
| owh | 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:12 |
| lifeless | odd | 01:17 |
| lifeless | uhm | 01:17 |
| lifeless | I have no idea :) | 01:17 |
| jelmer | lifeless: no | 01:21 |
| jelmer | lifeless: I tried out the pre-built version of bzr-eclipse but found it had to many rough edges | 01:21 |
| jelmer | lifeless: so froze my effort to package it | 01:22 |
| jelmer | that was a while ago though, it may have gotten better since | 01:22 |
| NfNitLoop | omg annoying voice guy won't stfu | 01:23 |
| lifeless | ? | 01:23 |
| NfNitLoop | oops wrong window. | 01:23 |
| NfNitLoop | sorry :) | 01:24 |
| thumper | NfNitLoop: heh | 01:24 |
| thumper | NfNitLoop: had me laughing | 01:24 |
| NfNitLoop | this cellphone connection is laggy... thought i was typing elsewhere | 01:24 |
| owh | How do I go about figuring out why I cannot create a bzr team synchronisation in eclipse? | 01:25 |
| lifeless | owh: I'd love to help you but I don't know enough about eclipse | 01:25 |
| lifeless | owh: make sure have the eclipse version the bzr-eclipse page talks about | 01:25 |
| owh | I do, 3.4.1 which is >= 3.3 | 01:26 |
| lifeless | isn't that incompatible? I seem to recall a different build of the eclipse plugin being needed | 01:27 |
| owh | Seems to be working. That's a 'feature' not a bug :) | 01:37 |
| owh | Not that I like the word "seems" in a development environment, but backups are there for a reason :) | 01:38 |
| lifeless | trace generates _very_ odd results sometimes | 03:07 |
| meoblast001 | hi | 03:07 |
| lifeless | hmm, could be decorators messing it up | 03:15 |
| igc | hi all | 03:34 |
| lifeless | hi igc | 03:36 |
| igc | hi lifeless | 03:37 |
| thumper | hi edcrypt | 04:02 |
| edcrypt | thumper hi | 04:02 |
| thumper | edcrypt: I haven't looked at the source yet, but I have a couple of comments on the readme :) | 04:03 |
| thumper | edcrypt: although first a question | 04:03 |
| thumper | edcrypt: for the init-workspace, you have the sandbox outside the repo | 04:03 |
| thumper | edcrypt: why? | 04:03 |
| thumper | edcrypt: I would have thought it easier to have MyProject be the shared repo | 04:03 |
| thumper | edcrypt: with trunk | 04:03 |
| thumper | edcrypt: and the sandbox checkout | 04:03 |
| thumper | edcrypt: then you don't have two different repo styles for --feature-branches or other | 04:04 |
| lifeless | I'm really concerned that all these 'make it easy by layering' approachs are just making the problem worse | 04:04 |
| thumper | lifeless: all problems are solvable with another layer of indirection L) | 04:04 |
| * thumper snickers | 04:05 | |
| edcrypt | thumper: not big motive, it's just the layout I'm used to | 04:05 |
| lifeless | to fix it we need to remove the sand grains causing the issue | 04:05 |
| thumper | edcrypt: personally I have my lightweight checkouts outside my repo | 04:05 |
| thumper | edcrypt: but I think that the plugin should be simple enough to understand without having two different layouts | 04:06 |
| edcrypt | thumper: I think I agree. | 04:07 |
| thumper | I'm pretty sure that switch is smart enough now that `bzr switch feature-x` will DTRT | 04:08 |
| thumper | rather than `bzr switch ../feature-x` | 04:08 |
| lifeless | thumper: it will search in branch-root/../ | 04:10 |
| lifeless | so yes, qualified | 04:10 |
| lifeless | man, it is going to take a long time to index all of bzrlibs tests | 04:11 |
| lifeless | why is trace.Trace so slow | 04:11 |
| thumper | edcrypt: also the `update-sandbox` command will do weird things if the checkout is no longer trunk | 04:13 |
| lifeless | 10 tests in 20 minutes | 04:17 |
| lifeless | 2 minutes each, 18K tests, 36K minutes :( | 04:17 |
| lifeless | 600 hours :( | 04:17 |
| lifeless | 24 days. faaaark | 04:17 |
| thumper | lifeless: why are you doing this? | 04:19 |
| spiv | lifeless: I guess that's what happens when you run python functions for every bytecode... | 04:19 |
| edcrypt | thumper: right. it should check that. | 04:19 |
| edcrypt | thumper: thanks for the feedback, | 04:20 |
| lifeless | spiv: wheeee | 04:20 |
| lifeless | thumper: I have written a plugin | 04:20 |
| lifeless | thumper: it indexes tests by the code they exercise | 04:20 |
| thumper | edcrypt: my pleasure | 04:20 |
| lifeless | then when you run 'bzr selftest --changes' it calculates the changed code and looks up the relevant tests | 04:20 |
| * thumper nods | 04:21 | |
| lifeless | 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:21 |
| lifeless | spiv: possibly I should just use lsprof | 04:33 |
| lifeless | spiv: and extract stuff from that, but I do need the module paths | 04:33 |
| * lifeless will play after work | 04:33 | |
| lifeless | jelmer: ping | 04:35 |
| * igc lunch | 05:02 | |
| spm | 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 |
| poolie | "failed" | 05:09 |
| poolie | hth :) | 05:09 |
| spm | poolie: not really :-D | 05:10 |
| poolie | is there something in ~/.bzr.log? | 05:10 |
| lifeless | spm: no output at all?! | 05:11 |
| lifeless | spm: pastebin please | 05:11 |
| spm | poolie: yes actually! ta. but is the generic connection failed, pls to using -Dhpss message. hmmm. | 05:11 |
| spm | lifeless: from the buildbot log. looks like it throws away stderr/out | 05:11 |
| spm | so .bzr.log has: https://pastebin.canonical.com/16383/ | 05:12 |
| spm | builbot slave log has: https://pastebin.canonical.com/16384/ cf line 21 | 05:13 |
| lifeless | spm: haven't looked yet but I bet 'fix your dns' | 05:14 |
| spm | heh | 05:14 |
| lifeless | we'll need stderr thats where the openssh output will have gone | 05:14 |
| poolie | hm i thought we removed that "please use -Dhpss" message | 05:15 |
| poolie | maybe he has an old bzr | 05:15 |
| spm | poolie: Yikes! 1.8 | 05:16 |
| lifeless | spm: please be using something from this year | 05:16 |
| lifeless | spm: but I bet you a liquid refreshment that its dns | 05:17 |
| spm | I could really learn to hate ec2... dns seems so fragile there. | 05:17 |
| lifeless | igc: I don't really understand your LocalRemoteBranchTypes thing | 05:23 |
| igc | lifeless: give it another 30 minutes - what's there was just a 'save-before-lunch' snapshot | 05:27 |
| lifeless | igc: ok; if its useful I can say what confused me | 05:28 |
| igc | lifeless: sure, go ahead | 05:29 |
| lifeless | 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 |
| lifeless | that was the bit that confuses me | 05:30 |
| lifeless | 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 |
| lifeless | s/you grab/one grabs/ | 05:32 |
| lifeless | 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:33 |
| spm | lifeless: poolie: fyi. pebkac, effectively. ssh-agent fail. fixed now. ta, and sorry for the false alarm as it were. | 05:37 |
| lifeless | damn, I owe you water | 05:37 |
| spm | high quality tap water at that! No less! | 05:38 |
| lifeless | I shall piss in the cup myself | 05:38 |
| poolie | ENSFW | 05:39 |
| BasicOSX | I've seen NSFW, and VNSFW, what's ENSFW? | 05:44 |
| poolie | "error nsfw" | 05:44 |
| BasicOSX | extremely? ahh, ok | 05:44 |
| vila | hi all | 07:02 |
| maxb | window level all | 07:49 |
| wgrant | 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:01 |
| jelmer | lifeless: pong | 08:06 |
| === jrydberg_ is now known as jrydberg | ||
| lifeless | jelmer: see mail | 08:17 |
| jelmer | lifeless: push_branch also pushes to existing branches | 08:56 |
| jelmer | BzrDir.push_branch() will open the underlying branch if there is one | 08:57 |
| lifeless | jelmer: I know, thats part of the issue ;P | 08:59 |
| jelmer | lifeless: but you want to get at a Branch without getting at a BzrDir first? | 09:06 |
| jelmer | lifeless: anyway, the suggestions for the helper seem reasonable | 09:08 |
| jelmer | lifeless: seems a bit similar to BzrDir.open_containing_tree_branch_or_repository | 09:09 |
| jelmer | lifeless: ie BzrDir.open_branch_or_bzrdir() | 09:09 |
| lifeless | jelmer: it may create :) | 09:11 |
| lifeless | jelmer: look at the network trace | 09:11 |
| jelmer | lifeless: so basically, the only thing I can't do is a create without a push | 09:12 |
| jelmer | lifeless: which trace? | 09:12 |
| lifeless | the one in my mail | 09:13 |
| * igc dinner | 09:15 | |
| jml | how do you deloomify a branch? | 09:19 |
| lifeless | jml: bzr export-loom | 09:20 |
| jml | meh | 09:20 |
| jml | ok, what I really meant was, how can I make this error go away? TypeError: open() got an unexpected keyword argument 'ignore_fallbacks' | 09:20 |
| lifeless | upgrade your loom plugin with aaron's patch | 09:21 |
| jml | thanks. | 09:21 |
| === sabdfl1 is now known as sabdf1 | ||
| === fta_ is now known as fta | ||
| === serg_ is now known as serg | ||
| jelmer | re | 10:50 |
| === nevans1 is now known as nevans | ||
| LarstiQ | wgrant: it certainly should if they are using the smartserver to access it | 13:27 |
| LarstiQ | 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:31 |
| beuno | LarstiQ, sure | 13:32 |
| beuno | ah | 13:34 |
| beuno | doesn't work with nightlies | 13:34 |
| vila | abentley: ping | 13:58 |
| abentley | vila: pong | 14:03 |
| vila | 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 |
| abentley | vila: doesn't sound like it. lemme see... | 14:05 |
| beuno | LarstiQ, works perfect | 14:06 |
| LarstiQ | beuno: thanks! | 14:06 |
| abentley | vila: Yes, it looks deliberate. You see that it's registered twice, right? | 14:07 |
| vila | yes | 14:07 |
| vila | so why ? | 14:08 |
| abentley | 0.19 never existed. It got renamed to 0.90. | 14:08 |
| abentley | But by that point, there were already merge directives in the wild that used 0.19 | 14:08 |
| vila | abentley: oeuf corse | 14:08 |
| abentley | So this was to retain compatibility with those merge directives. | 14:09 |
| vila | abentley: added as comment | 14:10 |
| vila | abentley: and thanks :) | 14:12 |
| abentley | vila: np | 14:12 |
| === ja1 is now known as jam | ||
| jam | hey vila, how's it going? | 15:30 |
| vila | jam: fine, getting closer to submission :) | 15:31 |
| jam | I at least saw your commit show up :) | 15:31 |
| vila | jam: Ha ! Good, still not here, but at least I fixed the setup (again :-/) | 15:31 |
| jam | vila: btw, my recent LRUCache patch *might* be part of the answer for why branch conversions leak a bit of memory | 15:31 |
| jam | We were "leaking" LRUNodes by leaving in the linked-list, but not in the dict | 15:32 |
| vila | jam: Next on my list to check :) | 15:32 |
| jam | 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:32 |
| vila | jam: and multiplied by the number of LRUCache, multiplied by the number of autorepack during the conversion... | 15:33 |
| vila | jam: damn, just realized I haven't approved your patch :-/ | 15:34 |
| jam | vila: well, when we get rid of the containing btree reference, it should gc the lru nodes | 15:35 |
| jam | so... maybe | 15:35 |
| jam | certainly I think the fix will help | 15:35 |
| jam | and in the meantime I'll finish perf testing the link indirection | 15:35 |
| jam | it seems to cost about 10% overhead | 15:35 |
| vila | ECONTEXT link ? | 15:35 |
| jam | vila: LRUNodes are in a double linked list (.next, .prev) | 15:37 |
| jam | which means that if you just del LRUCache | 15:37 |
| jam | they stay around until gc.collect() runs | 15:37 |
| vila | ha, that link :) | 15:37 |
| jam | You can use 'prev_key' and then look up the prev object in LRUCache._cache | 15:38 |
| jam | the problem is it adds a dict overhead | 15:38 |
| jam | vila: current timing: http://paste.ubuntu.com/152135/ | 15:39 |
| jam | That is with 2.8M tuples | 15:39 |
| jam | 8.2k unique | 15:39 |
| vila | jam: this measures only the cache overhead right ? | 15:44 |
| jam | right | 15:44 |
| jam | this is with a test where a miss has 0 cost | 15:44 |
| jam | I just do except: cache[val] = val | 15:44 |
| vila | 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:45 |
| jam | vila: this isn't about *leaking* specifically | 15:46 |
| jam | it is just whether the data gets cleaned up during "del foo" | 15:46 |
| jam | or during "gc.collect()" | 15:46 |
| vila | jam: sure, I shouldn't have say leaked, sry | 15:46 |
| jam | vila: the patch you approved was about a more genuine "leak" | 15:46 |
| jam | where not even gc.collect() would grab it | 15:46 |
| jam | because they were still 'live' in the linked list | 15:47 |
| jam | vila: And gc.collect() runs automatically every 700 unmatched allocations or so | 15:47 |
| jam | so the data will get cleaned up eventually | 15:48 |
| jam | I *think* I want to do it anyway | 15:49 |
| jam | I just need a real-world benefit | 15:49 |
| jam | and maybe big conversions are it | 15:49 |
| jam | since during autopack we'll be generate a new btree index, and "throwing away" the old one | 15:49 |
| vila | 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:50 |
| vila | jam: right, and we autopack several times :) | 15:51 |
| vila | one just triggers here :) | 15:51 |
| jam | vila: yeah, the xml trick means that for the 100 or so revision trees we have in memory | 15:52 |
| jam | we only have 1 copy of 99% of the inventory objects | 15:52 |
| jam | I would be surprised for it to be 1GB | 15:53 |
| vila | 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 |
| jam | then again, it could be *huge* for improving fragmentation | 15:55 |
| vila | jam: that's the problem :) We really need to find a better way to measure that fragmentation | 15:56 |
| jam | vila: bzr branch lp:~jameinel/+junk/py_memory_dump :) | 15:56 |
| vila | jam: Hmpf man malloc(3) BUGS section 8-/ | 16:05 |
| __alexandre__ | hi everybody | 16:12 |
| __alexandre__ | I have a problem using bazaar and I need some help. Am I in the right place ? | 16:13 |
| bialix | hi, jelmer is around? | 16:13 |
| bialix | __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:14 |
| __alexandre__ | and bazaar does not ask me for my password when it gets 401 error | 16:15 |
| jam | __alexandre__: use a username in the url | 16:15 |
| jam | http://username@host/... | 16:15 |
| __alexandre__ | I tried | 16:15 |
| __alexandre__ | but I get a big traceback | 16:15 |
| __alexandre__ | if I set the password with it | 16:16 |
| __alexandre__ | something like | 16:16 |
| __alexandre__ | http://username:password@localhost/the_path | 16:16 |
| __alexandre__ | even just http://username@localhost does not work | 16:17 |
| vila | __alexandre__: can you pastebin the traceback somewhere ? What bzr version are you using ? | 16:22 |
| __alexandre__ | Bazaar (bzr) 1.6.1 with python2.5.2 | 16:23 |
| vila | __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:24 |
| __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 |
| vila | __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:25 |
| __alexandre__ | ok I'll try with the last stable version | 16:26 |
| __alexandre__ | thank you ! | 16:26 |
| vila | __alexandre__: anyway, the relevant error here is: ERROR: pycurl.error: (65, "necessary data rewind wasn't possible") | 16:27 |
| vila | and I'm pretty sure many fixes applies to solve that :-) | 16:27 |
| vila | __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:29 |
| __alexandre__ | ok it seems to work with a newer version. thank you | 16:32 |
| jam | vila: just checked 'man malloc', I'm not particularly worried about the bug | 16:58 |
| vila | jam: no, no worries, just... ugh | 16:59 |
| jam | It just means that if you have "for(i = 0; i < infinity; ++i) {malloc(100000)} | 16:59 |
| jam | it will over succeed | 16:59 |
| jam | pages aren't actually acquired until you touch them | 16:59 |
| vila | ...and then randomly kill some processes | 16:59 |
| jam | I remember benchmarking it in the past | 16:59 |
| jonnydee | 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:10 |
| jonnydee | btw, "bzr st" also lists all the other files/directories within the subtree as "unknown", too... | 20:12 |
| jonnydee | no one who can help me? I'd love you use nested trees, because they seem to be exactly what I need. | 20:18 |
| LarstiQ | 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 | |
| LarstiQ | jonnydee: http://bazaar-vcs.org/NestedTreeProgress | 20:19 |
| jonnydee | particularly, the feature that bzr will remember the revision of the inner tree within the outer tree is very cool!!! | 20:20 |
| jonnydee | LarstiQ: I've read this site, but I wonder why bzr 1.13.1 already has "join --reference" released... | 20:21 |
| jonnydee | (thanx for your reaction :) ) | 20:21 |
| james_w | is there a plugin with a pre_commit hook for test before commit? | 20:21 |
| james_w | *not* PQM ;-) | 20:22 |
| LarstiQ | jonnydee: it's not in bzr.dev, let me check 1.13 | 20:22 |
| LarstiQ | jonnydee: --reference is indeed on join in 1.13, but join itself is a hidden command. | 20:23 |
| LarstiQ | jonnydee: anyway, it boils down to: I'm afraid nested trees as released will not do what you want, just yet. | 20:24 |
| LarstiQ | 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 |
| jonnydee | 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:25 |
| LarstiQ | jonnydee: there are cases where it can be usefully used, yes | 20:26 |
| LarstiQ | jonnydee: but what's your usecase? Maybe we can help you find something for that. | 20:26 |
| jonnydee | I would like to have a 'lib' branch as a subtree of another project branch. | 20:28 |
| jonnydee | the lib branch is versioned itself | 20:29 |
| jonnydee | 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 |
| LarstiQ | pretty much the canonical case for by reference nested trees, indeed | 20:31 |
| jonnydee | so I would like to have a separate branch for each project | 20:31 |
| jonnydee | and get common things for each project by subtrees | 20:32 |
| jonnydee | yes, I think it's exactly the use case described in http://bazaar-vcs.org/NestedTreesDesign | 20:32 |
| LarstiQ | 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 |
| LarstiQ | jonnydee: so you might want to look at that for something that works right now | 20:33 |
| jonnydee | oh, thanks for this hint :) I'll have a look to it. and thank you very much for your attention and help :) | 20:34 |
| LarstiQ | jonnydee: np | 20:36 |
| james_w | vila: around by any chance? | 20:50 |
| james_w | I have some testsuite questions :-) | 20:50 |
| vila | james_w: lucky you ! :) | 20:50 |
| james_w | yay! | 20:50 |
| james_w | 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 |
| vila | what testsuite ? | 20:51 |
| james_w | 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 | |
| LarstiQ | ah, right | 20:51 |
| vila | ok, run the test suite without selftest | 20:52 |
| james_w | yeah | 20:52 |
| vila | jusdepending on unittest or using bzrlib.tests features | 20:52 |
| vila | ? | 20:52 |
| james_w | 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 |
| james_w | bzrlib.tests would be nice | 20:52 |
| vila | and why not use selftest -s bp.myplugin ? | 20:53 |
| james_w | because that involves making sure that "myplugin" is on the bzr plugin path | 20:53 |
| vila | need to test various versions without swapping ? | 20:53 |
| james_w | I just wrote a quick pre_change_branch_tip hook for running tests | 20:53 |
| james_w | it gets the branch and a revid, so it exports to a tempdir, and runs the tests there | 20:54 |
| LarstiQ | james_w: BZR_PLUGIN_PATH=. ? | 20:54 |
| vila | james_w: I was thinking about LarstiQ proposal while searching the relevant bug on lp :) | 20:54 |
| LarstiQ | bit of a hammer | 20:54 |
| james_w | LarstiQ: yeah, it's a bit annoying as it tries to load like setup.py as a plugin for example | 20:55 |
| LarstiQ | james_w: ooh | 20:55 |
| LarstiQ | right | 20:55 |
| vila | james_w: if __name__ == "__main__": | 20:55 |
| vila | unittest.TestProgram(module=__name__) | 20:55 |
| vila | if the incantation I use when doing TDD outside bzr | 20:56 |
| james_w | so that would be fine for anything not using the bzr extensions? | 20:56 |
| LarstiQ | vila: how does that differ from unittest.main()? | 20:56 |
| vila | it should be fine to use bzr extensions *except* for load_test() and test_suite() | 20:56 |
| james_w | ah, because of inheritance! | 20:57 |
| vila | LarstiQ: main = TestProgram | 20:58 |
| vila | in unittest.py ? :-P | 20:58 |
| jam | james_w: why not write a 'main()' function which just imports bzrlib.tests and runs itself | 20:58 |
| vila | line ~808 :) | 20:58 |
| jam | heck, if you want to get crafty, you could have it set BZR_PLUGIN_PATH | 20:58 |
| jam | and then run 'bzr selftest -s bp.myplugin' | 20:58 |
| vila | ELOOP :) | 20:59 |
| jam | vila: not really, it is just a "if __name__ == '__main__':" check | 21:00 |
| jam | I suppose it is recursive, but directly terminating | 21:00 |
| vila | jam: not the code, the discussion :) | 21:00 |
| james_w | ok, putting vila's suggestion in tests/__init__.py runs 0 tests | 21:00 |
| vila | I proposed -s bp.myplugin earlier :) | 21:00 |
| jam | vila: right, and he said the problem was he didn't want to have to put it into path | 21:00 |
| jam | so *I* suggested having the plugin put itself into path | 21:00 |
| jam | and have the *plugin* call out to "bzr selftest $ME" | 21:01 |
| james_w | 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 |
| jam | so his "python tests/__init__.py" would Just Work | 21:01 |
| vila | jam: right, I rule that out too fast maybe (I thought there may be several versins conflicting) | 21:01 |
| vila | james_w: if you use b.p. imports then you *must* use bzr to load correctly | 21:02 |
| james_w | yeah | 21:02 |
| james_w | so I want to run bzr, but I want slightly more control over the plugins it imports | 21:02 |
| vila | bug #316192 | 21:04 |
| ubottu | 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 |
| jam | james_w: well you could put the "if __name__" check very early | 21:04 |
| jam | and have it finish with "sys.exit()" | 21:04 |
| jam | (as in, put it before the other 'import' statements, etc) | 21:04 |
| vila | bug #82693 | 21:04 |
| ubottu | Launchpad bug 82693 in bzr "Ability to run tests in a particular plugin" [Wishlist,Confirmed] https://launchpad.net/bugs/82693 | 21:04 |
| vila | 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:12 |
| james_w | that would be great | 21:13 |
| james_w | I'm getting there | 21:13 |
| james_w | however, the plugin is currently loaded as "bzrlib.plugins.trunk" | 21:13 |
| vila | james_w: :-) I know that one, I ended up making my ~/.bazaar/plugins directory a link farm pointing to various ~/src subdirectories | 21:14 |
| james_w | that's what I have | 21:14 |
| vila | I also love a bzr enable/disable plugin that mv in and out the DISABLED directory :-) | 21:15 |
| james_w | \o/ | 21:18 |
| james_w | it won't work on Windows though | 21:18 |
| james_w | if __name__ == '__main__': | 21:19 |
| james_w | import os | 21:19 |
| james_w | import subprocess | 21:19 |
| james_w | import sys | 21:19 |
| LarstiQ | mv DISABLED? | 21:19 |
| james_w | dir = os.path.join(os.path.dirname(os.path.abspath(__file__)), "plugins") | 21:19 |
| james_w | retcode = subprocess.call("bzr selftest -s bzrlib.plugins.builder", | 21:19 |
| james_w | shell=True, env={"BZR_PLUGIN_PATH": dir}) | 21:19 |
| james_w | sys.exit(retcode) | 21:19 |
| james_w | with /plugins/builder -> / | 21:19 |
| james_w | (symlink) | 21:19 |
| james_w | thanks team, I'll use this for a while and see how it goes | 21:20 |
| Kobaz | zr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt) | 21:36 |
| Kobaz | i get that while trying to do a pull | 21:37 |
| Kobaz | how do i turn off ca validation | 21:37 |
| Kobaz | i use self-signed certs | 21:37 |
| exarkun | Kobaz: Add your cert to the site ca cert list? | 21:38 |
| exarkun | Then you can use self-signed certs /and/ retain some security. | 21:38 |
| exarkun | woot. | 21:38 |
| LarstiQ | or use http+urllib:// | 21:40 |
| exarkun | LarstiQ: That's the same as turning off ca validation, right? | 21:42 |
| LarstiQ | exarkun: isn't that exactly what Kobaz is asking? | 21:42 |
| exarkun | Yes | 21:42 |
| LarstiQ | ah, that way. | 21:42 |
| LarstiQ | exarkun: yes, I believe it is. | 21:43 |
| LarstiQ | exarkun: although our use of urllib may have grown certificate validation. | 21:43 |
| LarstiQ | I wish it did, it's the only thing keeping pycurl alive. | 21:44 |
| Kobaz | mmm | 21:45 |
| Kobaz | so the only way is to add the ca to the ca store? | 21:45 |
| Kobaz | oh wait | 21:46 |
| Kobaz | what's http+urllib:// | 21:46 |
| Kobaz | i'm using bzr+https:// | 21:46 |
| LarstiQ | Kobaz: could you try bzr+https+urllib:// ? | 21:46 |
| LarstiQ | not sure if multiple decorators work, but worth a try | 21:47 |
| Kobaz | k | 21:48 |
| Kobaz | it's weird though, i'm putting bzr on a new box | 21:48 |
| Kobaz | i use bzr+https:// on all my other boxes with no issue | 21:48 |
| Kobaz | all on bzr 1.13 | 21:48 |
| lifeless | Kobaz: in bzr 1.13 the server will do more operations; you may be seeing the server itself generatin that error | 21:49 |
| Kobaz | bzr: ERROR: Unsupported protocol for url "bzr+https+urllib:// | 21:49 |
| Kobaz | it's definitly not the server | 21:50 |
| LarstiQ | Kobaz: my guess is that all the others do not have pycurl installed | 21:50 |
| Kobaz | oh yeah, that's how i fixed it, was removing pycurl | 21:50 |
| LarstiQ | good night | 21:51 |
| Kobaz | so soon? | 21:51 |
| Kobaz | here's something i've been wondering a while | 21:52 |
| Kobaz | how do i display relative paths when doing bzr st, or other commands | 21:52 |
| Kobaz | bogger {~/projects/system_init} kobaz$ bzr st * | 21:52 |
| Kobaz | unknown: system_init/create_postgres_users | 21:52 |
| LarstiQ | Kobaz: 23.00, my usual sleeping time | 21:52 |
| Kobaz | what i used to do all the time with subversion, is copy and paste the filename and do somethign with it | 21:53 |
| Kobaz | so if i copy and paste | 21:53 |
| Kobaz | i get bzr diff system_init/create_postgres_users | 21:53 |
| Kobaz | which doesn't exist... since i'm already in system_init/ | 21:53 |
| Kobaz | if i do bzr st *... i should see just: system_init | 21:53 |
| Kobaz | er i mean... i should just see the files with relative paths... which would be just one filw: create_postgres_users | 21:54 |
| lifeless | Kobaz: we are changing st to be like svn in that regard | 21:59 |
| lifeless | Kobaz: for now you could do `bzr root`/<filename> | 21:59 |
| Kobaz | i like if you do svn st... and it will show you everything in the tree | 22:00 |
| Kobaz | but it would be cool if there was an option to do relative paths | 22:00 |
| Kobaz | i think both methods should exist | 22:00 |
| lifeless | Kobaz: yes, it will show everything and give relative paths | 22:10 |
| lifeless | htats the current plan as I understand it | 22:10 |
| Kobaz | nifty | 22:12 |
| kfogel | lifeless: the new eol-conversion stuff is entirely client side, right? that is, if someone wants the feature, and they upgrade their local bzr to 1.14rc1, then they'll get the feature, even if the other servers they talk to are 1.13 or older. Is that correct? | 22:18 |
| lifeless | kfogel: at this point I believe so | 22:19 |
| kfogel | lifeless: thanks. Wanted to make absolutely sure, before I said it to a VIU. | 22:20 |
| kfogel | lifeless: I saw your "I believe"; I will CC Martin on my response to make sure. | 22:20 |
| lifeless | kfogel: igc has been writing this feature | 22:21 |
| fullermd | 'client' is probably the wrong division. It's all WT-side. | 22:21 |
| kfogel | fullermd: well, in a sense that's a subset of "client" (I think this user wants to be told the answer in the simplest way possible). | 22:22 |
| lifeless | kfogel: I'm not aware of any changes in the repository api to signal how things should be stored | 22:25 |
| lifeless | kfogel: which says its all client side to me | 22:25 |
| kfogel | lifeless: *nod* | 22:26 |
| Peng_ | beuno: Ping? | 22:34 |
| beuno | Peng_, pong | 22:34 |
| Peng_ | beuno: Oh hi! | 22:34 |
| Peng_ | Um. | 22:34 |
| beuno | hai | 22:34 |
| Peng_ | beuno: Any opinion on bug 358322? | 22:35 |
| ubottu | Launchpad bug 358322 in loggerhead "Every call to LoggerheadConfig() creates a new temp dir" [Critical,Confirmed] https://launchpad.net/bugs/358322 | 22:35 |
| beuno | Peng_, yeah, we should use the same dir, and make it configurable | 22:35 |
| beuno | not add the timestamp, or whatever random string to add | 22:36 |
| beuno | is that what you where aiming at? | 22:36 |
| Peng_ | beuno: I wasn't aiming at anything in particular. | 22:36 |
| beuno | well, that's what I thought of in the shower a day or two ago :) | 22:37 |
| AmanicA | kfogel: wouldn't you need to update to the 1.14 formats to get that feature? so the old version on the server would not like it | 22:38 |
| AmanicA | New formats 1.14 and 1.14-rich-root supporting End-Of-Line (EOL) conversions, | 22:39 |
| Peng_ | AmanicA: But if the only new format is the working tree, and the server-side doesn't have working trees, it's not a problem. | 22:39 |
| Peng_ | beuno: Is my patch okay as an interim solution? | 22:39 |
| AmanicA | ah | 22:39 |
| kfogel | AmanicA, Peng_: or at least, whatever working trees are on the server side are of no concern on our side. | 22:40 |
| beuno | Peng_, I did not know there was a patch | 22:40 |
| * beuno looks | 22:40 | |
| beuno | Peng_, you should file merge proposals ;) | 22:42 |
| beuno | now | 22:42 |
| beuno | what would the prefix fix? | 22:42 |
| Peng_ | beuno: Sorry. I didn't because it was only an RFC. | 22:42 |
| beuno | identifying it? | 22:42 |
| blfgomes | could anybody help me setup bzr to work with a proxy that requires authentication? | 22:45 |
| beuno | Peng_, ^ ? | 22:46 |
| Peng_ | Err, hold on. I just got distracted. | 22:46 |
| beuno | sure, didn't know if you had read | 22:47 |
| lifeless | blfgomes: export http_proxy=http://hostname:port/ | 22:47 |
| blfgomes | anybody? I have HTTP_PROXY configured, I can do pretty much everything (wget, apt-get), except for bzr | 22:47 |
| lifeless | blfgomes: ok, is it lp: url's that are giving you grief ? | 22:48 |
| blfgomes | lifeless: I tried the whole url as well, but it doesn't seem to be authentication in either case | 22:48 |
| blfgomes | I just get a 407 straight away | 22:49 |
| lifeless | hmm | 22:49 |
| lifeless | vila: ^ | 22:49 |
| lifeless | what proxy is it? | 22:49 |
| blfgomes | good question | 22:49 |
| blfgomes | I've seen some unorthodox proxy configuration here at work before, where some things wouldn't work... But why should bzr fail when wget runs smoothly? | 22:51 |
| lifeless | if its doing NTLM/kerberos we might not support tat | 22:51 |
| lifeless | I'm reasonably sure we support digest | 22:51 |
| lifeless | vila maintains our http stack | 22:52 |
| blfgomes | I'm giving my credentials in plain text in the HTTP_PROXY variable | 22:52 |
| lifeless | oh | 22:52 |
| lifeless | I'd strace and see what bzr is putting on the wire | 22:52 |
| lifeless | note that lp: url's won't work through a proxy at all at this point :( | 22:53 |
| lifeless | due to a xmlrpc lib limitation we haven't worked around yet | 22:53 |
| Peng_ | beuno: On a different subject, I forgot, for "fix is in lp:loggerhead", do you use Fix Committed or Fix Released? | 22:53 |
| lifeless | http://bazaar.launchpad.net/ ones will work | 22:53 |
| beuno | Peng_, committed | 22:54 |
| blfgomes | you're right... lp: urls timeout here, whereas full urls give me the 407 error | 22:54 |
| Peng_ | beuno: Thanks. | 22:54 |
| Peng_ | beuno: Anyway. What do you mean about prefixes? | 22:58 |
| beuno | Peng_, the cache dirs are created in /tmp | 22:58 |
| beuno | with different names each time, no? | 22:58 |
| Peng_ | beuno: Oh. The prefix argument is just so the directory is named "/tmp/loggerhead-cache-XXXXXX" instead of something like "/tmp/tmpXXXXXX". That's not a new change. | 22:59 |
| beuno | Peng_, ok, so, I'm fine with that change | 22:59 |
| beuno | bb:approve | 22:59 |
| beuno | lp: | 22:59 |
| beuno | whatever | 22:59 |
| beuno | but the deeper problem is that you shouldn't have to re-generate the cache everytime you restart | 22:59 |
| beuno | no? | 23:00 |
| beuno | or did I worry for nothing? | 23:00 |
| beuno | I do that sometimes | 23:00 |
| Peng_ | beuno: Honestly, I don't mind that. My cache got corrupted once, so that meant a restart fixed it. | 23:00 |
| beuno | I guess you don't have 200mb of caches and a dying server | 23:01 |
| beuno | :) | 23:01 |
| Peng_ | Heh, right. | 23:01 |
| beuno | someday, I'll work on Loggerhead again | 23:01 |
| beuno | I'm sure | 23:02 |
| Peng_ | beuno: It doesn't *need* to be recreated every time. Using a static location doesn't cause any problems. | 23:02 |
| Peng_ | Well, currently I think the file gets deleted on shutdown anyway, and I don't know hwy. | 23:02 |
| lifeless | blfgomes: please file a bug | 23:02 |
| Peng_ | s/hwy/why/ | 23:02 |
| lifeless | blfgomes: I'll assign it to vila and ask him to look; he's in europe | 23:02 |
| lifeless | BasicOSX: ping; is your addons repo work now ? | 23:03 |
| beuno | Peng_, yeah. I think making it static is better. And even more if it's configurable | 23:03 |
| BasicOSX | lifeless: I haven't check since the initial debug and troubleshooting | 23:03 |
| BasicOSX | I'm still at my real job, will check it again tonight when I'm home | 23:04 |
| blfgomes | lifeless: I'll make sure it's a bug, first | 23:04 |
| lifeless | blfgomes: thanks | 23:05 |
| lifeless | BasicOSX: ok, grab me and we'll sort it out; I have a meeting in ~ 3 hours for <2 hours | 23:05 |
| lifeless | BasicOSX: other than that a clear slate to help | 23:05 |
| BasicOSX | lifeless: I also have a backup of the repo (go Timemachine) from 2am that morning, I'm going to restore some place different and see if my repo got corrupt | 23:08 |
| Peng_ | beuno: If I make it configurable, what do you think the default should be? Going through mkdtemp is really hte safest option. | 23:13 |
| Peng_ | s/hte/the/ Darnit! | 23:13 |
| beuno | Peng_, agreed. Make mkdtemp the default, but let the user pass a config option | 23:14 |
| Peng_ | beuno: Alright. | 23:16 |
| beuno | Peng_, you rock | 23:16 |
| * beuno -> home | 23:26 | |
| beuno | bbiab | 23:26 |
| lifeless | james_w: btw let me know if my plugin works ;) | 23:47 |
| lifeless | james_w: I didn't test it | 23:47 |
| === Daviey_ is now known as Daviey | ||
| Peng_ | beuno: Back yet? | 23:56 |
| beuno | Peng_, yes | 23:56 |
| Peng_ | beuno: What do you want the option to be named? --cache-dir? --sql-dir? Something else? | 23:56 |
| Peng_ | (FWIW, I picked --cache-dir, since it may be changed to something not-SQL in the future.) | 23:56 |
| beuno | Peng_, --cache-dir sounds good | 23:57 |
| Peng_ | beuno: Alright. Thanks. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!