| __monty__ | Mmm, socket.error is a child class of IOError, so should the test for socket.error happen before the test for IOError? | 00:06 |
|---|---|---|
| poolie | i wonder why it isn't being handled by the existing code that tries to treat IOError as a user error? | 00:10 |
| mgz | in python 2.6 and later. | 00:10 |
| poolie | hi mgz | 00:11 |
| poolie | ah, perfect | 00:11 |
| __monty__ | Ah, yes the user was using 2.5 | 00:11 |
| poolie | in that case you could just list it in the same exception clause, and perhaps add a comment why it's being caught separately | 00:11 |
| __monty__ | What do you mean by listing it in the same exception clause? | 00:12 |
| mgz | having it before with a special note about connectivity would also be reasonable | 00:14 |
| poolie | i meant having (OSError, IOError, socket.error) | 00:17 |
| poolie | you should also add a test | 00:17 |
| poolie | i think this is pretty well covered in test_trace so you can go from those examples | 00:17 |
| __monty__ | What would be the best solution, testing it first with a specific message about connectivity or making the message for IOError more general and including OSError and socket.error? | 00:19 |
| poolie | can you explain the second alternative more? | 00:22 |
| __monty__ | The second alternative is what I understood you were proposing. | 00:22 |
| poolie | add a test that raises socket.errer | 00:23 |
| poolie | *error | 00:23 |
| poolie | check it does not print a traceback | 00:23 |
| poolie | the easiest way to make this test pass is probably to just also catch that exception in the same way as for IOError | 00:24 |
| poolie | hm | 00:24 |
| poolie | actually, on trunk, since we need py2.6 now, this bug may be obsolete | 00:24 |
| poolie | you could just interactively test that it works | 00:24 |
| __monty__ | How exactly do I test it? How do I try to get a socket.error? | 00:25 |
| poolie | look at eg test_format_io_error | 00:25 |
| poolie | probably a good way to get a realistic one is to try to connect to some unlikely port on localhost | 00:26 |
| poolie | like tcp port 2 | 00:26 |
| mgz | it's safe to just construct your own socket.error | 00:29 |
| poolie | it is | 00:29 |
| __monty__ | Yes, but how? | 00:30 |
| poolie | i feel if you do it yourself, you may miss quirks in how python constructs them | 00:30 |
| poolie | for instance there have been some bugs along the lines of actual python not setting named attributes on errors the way we expected, iirc | 00:30 |
| poolie | so if it's easy i'd lean towards generating a real owne | 00:30 |
| poolie | *one | 00:30 |
| __monty__ | I should write a new method in test_trace.py to test if this is no longer a problem in python 2.6, right? | 00:32 |
| poolie | yes | 00:32 |
| mgz | so, for instance, in bzrlib.tests.test_trace use test_format_pywintypes_error as a template but raise a likely looking socket.error instead | 00:33 |
| mgz | ...and I note there I did do what poolie said rather than what I suggested | 00:33 |
| mgz | in that I called a function that will raise a real error rather than constructing my own | 00:33 |
| poolie | this will probably cover bug 598158 | 00:35 |
| ubot5 | Launchpad bug 598158 in Bazaar "Socket is closed errors are not caught/wrapped." [Medium,Confirmed] https://launchpad.net/bugs/598158 | 00:35 |
| poolie | well, it's probably a dupe | 00:35 |
| poolie | in fact both are probably dupes of bug 393173 | 00:36 |
| ubot5 | Launchpad bug 393173 in amarok (Ubuntu) "Amarok does not transfer album art to iPod (dup-of: 260091)" [Undecided,New] https://launchpad.net/bugs/393173 | 00:36 |
| ubot5 | Launchpad bug 260091 in amarok (Ubuntu) "Amarok does not correctly re-format cover art when transferring to Ipod" [Undecided,Won't fix] https://launchpad.net/bugs/260091 | 00:36 |
| poolie | sorry bug 393713 | 00:38 |
| ubot5 | Launchpad bug 393713 in Bazaar "[master] socket.error causes a traceback" [Medium,Confirmed] https://launchpad.net/bugs/393713 | 00:38 |
| mgz | some socket errors are deeply unhelpful so some extra text in the advice param is probably a good idea | 00:39 |
| __monty__ | As extra text just point to bzr.log or something more helpful? | 00:41 |
| mgz | socket.socket(0) gives me a nice fast error, but that's probably a bad idea | 00:41 |
| mgz | depends if the constants are standardised at all I guess | 00:41 |
| poolie | i think there probably the thing is to catch them close to the point they're raised and rethrow something more meaningful | 00:42 |
| poolie | like try: socketblah: except socket.error: | 00:42 |
| poolie | raise something("failed to connect to smtp server %s:%d: %s" % (host, port, e)) | 00:42 |
| mgz | ehehe, funny mail from jam about the 2.4b3 release | 00:44 |
| poolie | :) | 00:44 |
| poolie | that was such a fun sprint | 00:44 |
| __monty__ | So, the error should be caught before we have to handle it in trace.py? Or did you mean something else poolie? | 00:46 |
| mgz | poolie, I've got half a thing written trying to convey that sense of fun, if I mail it to you will you proof read? | 00:46 |
| poolie | sure | 00:46 |
| poolie | i'd kind of like to consciously understand what we (or i) did right | 00:46 |
| poolie | to reproduce it | 00:46 |
| poolie | it seemed like there was just enough focus on having a hit list, but it wasn't overstructured | 00:47 |
| __monty__ | How does the test method work, I make sure an error is raised in the try block, then 'pass' the except block, then 'msg = _format_exception()', then self.assertContainsRe(msg, r"The string for the error here")? | 00:54 |
| poolie | that sounds right | 00:57 |
| __monty__ | Still how do I raise a socket.error that's realistic? | 00:58 |
| poolie | like mgz said just a socket.socket(0) could be a good start | 00:59 |
| spiv | __monty__: hmm, perhaps try to call sock.accept without first calling sock.listen? | 00:59 |
| poolie | o/ spiv | 00:59 |
| mgz | or socket.socket() then socket.send("something") yells at you for not being connected | 00:59 |
| mgz | really realistic ones like timeouts are probably not something we want in the test suite :) | 01:00 |
| spiv | mgz's idea sounds good too. | 01:00 |
| spiv | Hi poolie | 01:00 |
| __monty__ | Which one of these is least likely not to fail? | 01:01 |
| mgz | they should all fail! :) | 01:02 |
| poolie | either of those last two should be reliable | 01:02 |
| poolie | if it turns out they're not we can fix it | 01:02 |
| __monty__ | What would the error string look like for the socket.socket() socket.send("string") scenario? | 01:05 |
| poolie | just try it :) | 01:06 |
| spiv | python -c "import socket; s = socket.socket(); s.send('string')" :) | 01:06 |
| __monty__ | Is this correct for the string? Are the backslashes necessary since it's a raw string? | 01:10 |
| __monty__ | r"^bzr: ERROR: \[Errno .*\] Socket is not connected" | 01:12 |
| poolie | the backslashes are needed if you're trying to match it as a regexp | 01:15 |
| __monty__ | so it's not really necessary in this case since the error will always be: socket.error: [Errno 57] Socket is not connected | 01:16 |
| poolie | i don't think it's guaranteed to be error 57 on all platforms | 01:17 |
| poolie | spiv could i mumble at you about bug 220464? | 01:17 |
| ubot5 | Launchpad bug 220464 in Bazaar "Bazaar doesn't detect its own stale locks" [High,In progress] https://launchpad.net/bugs/220464 | 01:17 |
| __monty__ | Then this is good? r"^bzr: ERROR: \[Errno .*\] Socket is not connected" | 01:19 |
| poolie | yup | 01:19 |
| poolie | does it pass? | 01:19 |
| poolie | try running ./bzr selftest -s bt.test_trace | 01:19 |
| __monty__ | I get this: bzr: ERROR: No module named testtools | 01:20 |
| __monty__ | You may need to install this Python library separately. | 01:20 |
| __monty__ | bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703> | 01:20 |
| poolie | yes, you'll need testtools to run the tests | 01:20 |
| poolie | on ubuntu or debian, apt-get install python-testtools | 01:21 |
| __monty__ | This is the output: | 01:26 |
| __monty__ | bzr selftest: /Users/toon/src/bzr/connection-timed-out-364462/bzr | 01:26 |
| __monty__ | /Users/toon/src/bzr/connection-timed-out-364462/bzrlib | 01:26 |
| __monty__ | bzr-2.4.0dev4 python-2.6.5 Darwin-9.8.0-i386-32bit | 01:26 |
| spiv | poolie: sure; via which medium? | 01:26 |
| __monty__ | ---------------------------------------------------------------------- | 01:26 |
| __monty__ | Ran 25 tests in 0.577s | 01:26 |
| __monty__ | OK | 01:26 |
| __monty__ | Missing feature 'meliae' skipped 1 tests. | 01:26 |
| __monty__ | Missing feature 'pywintypes' skipped 1 tests. | 01:26 |
| __monty__ | bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703> | 01:26 |
| __monty__ | Sorry for the excessive pasting. | 01:27 |
| poolie | rockin | 01:28 |
| poolie | spiv, here, or mumble, or the phone | 01:28 |
| poolie | mostly it's been a while since i touched it so i can't recall if i meant to do anything else before proposing it | 01:28 |
| poolie | actually if you could just review it now that would be nice | 01:29 |
| __monty__ | Should I submit the change now? | 01:29 |
| poolie | yes please | 01:29 |
| spiv | poolie: sure, already started reading | 01:29 |
| spiv | poolie: So far it looks very nice! | 01:30 |
| poolie | there's another thing connected but just out of scope | 01:31 |
| poolie | which is to do with trying to release locks as we terminate | 01:31 |
| poolie | and there was some discussion at the sprint | 01:31 |
| poolie | which leaned me a bit closer towards a crash-only design | 01:32 |
| poolie | iow better to just pretty much terminate when something unexpected happens and then pick up next time | 01:32 |
| poolie | __monty__: all ok? | 01:38 |
| __monty__ | Yes, I'm composing the cover letter(?) I should mention all three of the bugs right? | 01:39 |
| poolie | since they're all dupes only the master is enough | 01:39 |
| poolie | thanks for fixing thins! | 01:39 |
| poolie | *this | 01:39 |
| mgz | poolie: I've emailed you a thingy. | 01:40 |
| poolie | ta | 01:40 |
| poolie | that's really nice, thanks! | 01:41 |
| poolie | i didn't know about bialix's shirt | 01:41 |
| poolie | i don't have any particular corrections or suggestions | 01:41 |
| poolie | i'd like to put it on the blog too | 01:41 |
| poolie | which will make it easy to add links | 01:42 |
| poolie | do you have access? | 01:42 |
| mgz | not currently. | 01:43 |
| poolie | ok sent | 01:44 |
| __monty__ | Merge proposed. Thank you for all the help poolie, mgz. :) | 01:47 |
| mgz | thanks poolie, and thanks monty :) | 01:48 |
| poolie | np, thanks for your contribution | 01:48 |
| __monty__ | See you later! | 01:49 |
| mgz | okay, gzlist on wordpress is now me. | 01:51 |
| mgz | darn minimum four character username restrictions :) | 01:51 |
| spiv | mgz: your nick is too compressed :) | 01:56 |
| spiv | poolie: branch reviewed, very nice | 01:57 |
| poolie | thanks spiv | 02:06 |
| mgz | okay, I think the post should be in the review queue on the blog | 02:07 |
| mgz | feel free to edit or change if anyone spots something that could do with improving | 02:07 |
| james_w | mgz, it looks like it is published | 02:14 |
| james_w | "Someone even" in the second sentence a mistake? | 02:14 |
| mgz | *how | 02:15 |
| mgz | dammit, I thought I'd changed that :) | 02:15 |
| poolie | i published it | 02:15 |
| poolie | well spotted | 02:15 |
| poolie | you should still be able to edit it? | 02:15 |
| poolie | spiv interesting question about reraising incidental errors | 02:15 |
| poolie | hm | 02:16 |
| mgz | hm I don't see the edit button | 02:16 |
| poolie | i'll fix it | 02:20 |
| mgz | I've got some fixes for your lock breaking branch in return :) | 02:21 |
| poolie | :) | 02:22 |
| poolie | mgz are you going to comment on the mp - should i wait for you? | 02:39 |
| mgz | yes please. | 02:39 |
| mgz | will try and be fast. | 02:39 |
| poolie | np | 02:40 |
| poolie | just didn't want to stand around looking silly | 02:40 |
| mgz | okay, nearly there | 02:48 |
| mgz | I don't really need to implement this twice... | 02:49 |
| mgz | requiring 2.6 means has_ctypes should always be true | 02:49 |
| mgz | okay, tests pass | 03:14 |
| poolie | i wonder if i should change this to cast to unicode to get the human form, rather than to str | 03:15 |
| poolie | to make it safer for py3 and indeed also for unicode values | 03:15 |
| mgz | it's generally the right thing to do | 03:22 |
| mgz | but it's a little annoying in Python 2 because it can be dangerous to pass somethings unicode rather than str | 03:23 |
| mgz | it can break exceptions and such like | 03:23 |
| mgz | okay, posted branch poolie | 03:29 |
| poolie | thanks mgz | 03:29 |
| mgz | I'm a bit past a coherant review, hopefully the changes make sense, otherwise it'll have to wait till tomorrow :) | 03:30 |
| poolie | sure | 03:31 |
| poolie | i have some other things to fix in it anyhow | 03:31 |
| poolie | have a good night | 03:31 |
| mgz | I got a few of them in the branch I think. Night poolie! | 03:31 |
| vila | woohoo, nice blog post mgz ! | 07:02 |
| poolie | it is isn't it | 07:52 |
| poolie | hi vila | 07:52 |
| poolie | i might call it a day though | 07:53 |
| vila | poolie: heya | 07:53 |
| poolie | thanks for the release | 07:53 |
| poolie | vila i don't know if you saw the mail from https://bugs.launchpad.net/bzr-cvsps-import/+bug/788914 | 07:53 |
| ubot5 | Ubuntu bug 788914 in CVS to Bazaar importer "unexpected keyword argument 'pb'" [Critical,Confirmed] | 07:53 |
| poolie | but it would be nice to review and merge his patch | 07:53 |
| poolie | *yawn* | 07:53 |
| vila | hmm, never touch this code so far :-/ | 07:54 |
| poolie | they should be shallow fixes | 07:54 |
| poolie | or maybe we can get lifeless to review them | 07:54 |
| poolie | anyhow i should really go | 07:55 |
| poolie | have a good day | 07:55 |
| poolie | will try to be online later next week | 07:55 |
| vila | have a nice weekend | 07:55 |
| poolie | you too | 07:55 |
| spiv | vila: you might enjoy https://code.launchpad.net/~spiv/bzr/subprocess-log-in-test-details/+merge/62612 | 08:02 |
| spiv | It might help demystify some babune failures. | 08:03 |
| vila | spiv: amazingly, I just found a trick to avoid the hangs... | 08:04 |
| spiv | Heh. | 08:04 |
| spiv | What's the trick? | 08:04 |
| vila | redirecting *selftest* stderr at the invocation seems to be enough (how that's inherited is yet unclear, but probably works for all cases where we don't explicitly handle stderr) | 08:04 |
| vila | so, what did I collect there ? | 08:05 |
| vila | I'm glad you asked: http://paste.ubuntu.com/613637/ | 08:05 |
| vila | *2* deprecation warnings... sound very small to block a pipe no ? | 08:06 |
| spiv | Well, depends on what the pipe's buffer size is | 08:06 |
| vila | hmm, 277 chars... | 08:06 |
| vila | awfully close to 256 :) | 08:06 |
| spiv | And how close we were to hitting the buffer limit without the extra noise :) | 08:06 |
| spiv | Yeah. | 08:07 |
| spiv | That worryingly suggests that jenkins or whatever is driving selftest in the slave isn't draining both stdout and stderr concurrently. | 08:08 |
| vila | my head spins a bit trying to understand the ramifications... | 08:09 |
| vila | dosen't clearly explain why your patch for osx/windows didn't work, I should retry that now | 08:09 |
| spiv | It also appears to disprove my optimism in saying “It's hopefully safe to assume that the terminal or whatever is draining both our stdout and stderr reliably!” :( | 08:10 |
| vila | yup, that remark triggered my trick test | 08:11 |
| vila | on the other hand, selftest is not supposed to output anything on stderr other than potential issues that needs to be addressed | 08:11 |
| vila | does that sound correct ? | 08:11 |
| spiv | vila: well, deprecation warnings sound like fair game for stderr to me | 08:12 |
| vila | yes, as things that should be addressed | 08:12 |
| spiv | And it's always possible to have lots of them | 08:12 |
| vila | hmm | 08:12 |
| vila | let me clarify | 08:12 |
| vila | we seem to encounter various issues with anything that appears on stderr | 08:13 |
| spiv | And there's some value in testing that we work in environments that do emit deprecation warnings. | 08:13 |
| spiv | i.e. with older libraries | 08:13 |
| vila | jenkins and subunit being brittle there | 08:13 |
| vila | so diverting stderr at the top level and investigating issues found there separately may help us reach a more robust babune | 08:14 |
| spiv | And in extreme situations (i.e. sufficiently bad bugs) we might even get subprocesses exploding with tracebacks on stderr | 08:15 |
| vila | I agree there is valuable information there, I don't mean to redirect to dev/null ! | 08:15 |
| spiv | Sure I didn't take it to mean that. | 08:15 |
| vila | right, my guess is that this should trigger test failures nevertheless | 08:15 |
| spiv | I'm just saying we can't rely on driving stderr output in babune down to zero either | 08:15 |
| spiv | We have to be able to cope with it (even if we do manage to get it down to zero normally, bugs happen) | 08:16 |
| vila | oh, right, may be not in the short term, but that's still a good target ;) | 08:16 |
| vila | I don't feel especially at ease with this deprecation warnings | 08:16 |
| spiv | It's probably a good target, but we can't depend on it. :) | 08:16 |
| vila | indeed | 08:16 |
| vila | so 2>selftest.stderr and cat selftest.stderr may be a useful trick | 08:17 |
| spiv | In the extreme case imagine someone introduces a syntax error in lazy loaded code that is only hit by a test subprocess | 08:17 |
| spiv | vila: +1 | 08:17 |
| spiv | buildbot gets this right :/ | 08:17 |
| vila | ? | 08:17 |
| vila | oh, you mean by handling it by default ? | 08:18 |
| spiv | It reads stdout and stderr from the subprocess just fine (and even shows stderr in red in the default console output display) | 08:18 |
| spiv | Right | 08:18 |
| vila | I can't believe (yet) the solution to so many babune problems could be that simple... | 08:19 |
| vila | time for more coffee :) | 08:19 |
| vila | hmm, by the way... | 08:19 |
| vila | OMG ! | 08:20 |
| vila | fullermd is not there ! | 08:20 |
| vila | Hell must be frozen ! | 08:20 |
| vila | ok, so plan: 1) more coffee, 2) look at spiv's stderr handling patch..... 4) profit ! | 08:21 |
| spiv | vila: given the state of http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29 you have quite a challenge as patch pilot today :) | 08:28 |
| spiv | Hangover from the sprint I guess! | 08:29 |
| vila | well, I backuped jelmer so I have a bit of lag, but I'm also waiting for reviews for my own proposals... | 08:29 |
| vila | may be I should just land them pretexting a user error while landing and approved one without realizing some pre-requisites weren't approved ;-D | 08:30 |
| vila | spiv: still hanging on OSX :-/ | 08:47 |
| spiv | vila: :/ | 08:49 |
| spiv | vila: does subprocess-log-in-details help at all? | 08:49 |
| vila | not tried that one yet | 08:49 |
| spiv | (Obviously it won't help the hang, but maybe it'll give better info if you interrupt the hang) | 08:49 |
| spiv | vila: I just did a couple of very quick reviews for you | 08:50 |
| spiv | And now I'm off! | 08:50 |
| vila | great ! | 08:50 |
| vila | have a nice week-end ! | 08:50 |
| spiv | Happy hacking, piloting, and babune-wrangling. | 08:50 |
| spiv | And have a nice weekend when you finally get there :) | 08:51 |
| vila | Riddell: hello there ! | 09:21 |
| vila | Riddell: I realized my comment on your https://code.launchpad.net/~jr/bzr/330063-merge-non-existing/+merge/61728 may need explanations about bb:tweak | 09:22 |
| vila | Riddell: or do you understand the meaning already ? | 09:22 |
| Riddell | it means tweaking the blackbox tests? | 09:22 |
| vila | hehe no | 09:22 |
| vila | BB == bundle buggy, that's what we used before reviews were available on lp | 09:23 |
| vila | different votes were available there and we still miss the 'tweak' one on lp | 09:23 |
| Riddell | ah | 09:23 |
| vila | we use it to convey: your patch looks good, you can land it without an additional review as long as you agree with the modifications asked by the reviewer and implement them | 09:24 |
| vila | but shorter ;) | 09:24 |
| vila | since this doesn't exist on lp, we use an idiom which is: review: needsfixing, status: approved | 09:25 |
| vila | Riddell: do you need further help with this proposal ? | 09:26 |
| Riddell | hopefully not, I'll get to it shortly once I've looked at my e-mail (I was taking a swap day yesterday) | 09:26 |
| Riddell | but I'll let you know if i do :) | 09:27 |
| vila | Riddell: ok, cool, welcome back :) | 09:27 |
| spiv | vila: heh, TestImportTariffs.start_bzr_subprocess_with_import_check explicitly uses the real $HOME! | 10:43 |
| spiv | vila: so you could argue that including ~/.bzr.log in the details is therefore appropriate ;) | 10:44 |
| vila | oh my, I routinely have Megs there ! | 10:44 |
| vila | I just didn't look at the result of my first run even if it was limited to ~10 tests, imagine what it will contain for a whole test suite ! | 10:45 |
| spiv | vila: it's just TestImportTariffs | 10:46 |
| vila | Megs * ~20.000, we will end up with GOs ! | 10:46 |
| vila | ha right, still we will end up with gOs :) | 10:46 |
| spiv | It shouldn't be much: | 10:47 |
| spiv | * details are discarded for passing tests | 10:47 |
| spiv | * only TestImportTariffs uses start_bzr_subprocess with a real $HOME | 10:47 |
| spiv | Worth checking my assumptions are right, of course. | 10:47 |
| vila | why not make them use a temp home then ? | 10:48 |
| spiv | But they should be ;) | 10:48 |
| spiv | “ # Normally we want test isolation from the real $HOME but here we | 10:48 |
| spiv | # explicitly do want to test against things installed there, therefore | 10:48 |
| spiv | # we pass it through. | 10:48 |
| spiv | ” | 10:48 |
| vila | argh | 10:48 |
| spiv | i.e. test_import_tariffs wants to make use ~/.bazaar/plugins | 10:48 |
| spiv | There's probably a better way to do that | 10:48 |
| vila | we rotate at 4M I think | 10:49 |
| spiv | Maybe set BZR_PLUGIN_PATH for the subprocess to explicitly be exactly what the parent uses | 10:49 |
| vila | that's 2M of noise on average ;-/ | 10:49 |
| Riddell | vila: should I be on the patch pilot schedule? | 10:52 |
| spiv | vila: I don't follow | 10:52 |
| spiv | vila: it only keeps the log contents if the test fails | 10:52 |
| spiv | vila: so normal cost: 0 | 10:53 |
| spiv | vila: no matter how large ~/.bzr.log is for that one test | 10:53 |
| vila | Riddell: up to you, feeel free to insert yourself, probably at the end of the cycle so you get some time to accomodate | 10:53 |
| vila | spiv: meh, maybe I misread your patch but I thought your were installing some automatic trigger for all subprocess calls ? | 10:54 |
| spiv | vila: for all start_bzr_subprocess calls | 10:55 |
| spiv | vila: but for all tests *except* TestImportTariff $HOME is some temporary directory | 10:55 |
| spiv | vila: and all in-process logging goes to an in-memory log during selftest | 10:55 |
| spiv | vila: so the only contents it will find are from test subprocesses, with the exception of TestImportTariff | 10:56 |
| spiv | (Ok, the doctests use real bzr $HOME too, but I don't think they use start_bzr_subprocess) | 10:56 |
| vila | spiv: right, worth adding as comments then, I'll look into it again later (I thought I said that in the review no ?) | 10:59 |
| vila | anyway, thanks for the explanations, will avoid useless roundtrips | 10:59 |
| spiv | vila: sure, just some drive by info as I was peeking at my mail :) | 11:00 |
| * Riddell blogs http://www.kdedevelopers.org/node/4435 | 12:57 | |
| Morbus | here's an odd question: is there anyways, from bzr command line, to "know" if someone has proposed a merge request? | 13:37 |
| maxb | Riddell: 1) Nice. 2) I'm confused by your user icon. 3) s/zx/xz/ | 13:37 |
| Morbus | i have a private lp account, and I need to integrate it with some CI tools, and it requires me knowing merge requests. | 13:37 |
| maxb | Not via the bzr command line, no | 13:37 |
| Morbus | damn. ok. | 13:38 |
| Morbus | so i instead need to figure out some way of automating a browser request to the LP MR page. | 13:38 |
| Morbus | which would normally be easy if it were public, but it's private. | 13:38 |
| Riddell | maxb: the user icon comes from Umbrello which was my university project back in the day | 13:38 |
| Riddell | Morbus: can't you use launchpad APIs? | 13:39 |
| Morbus | Riddell: didn't even know LP had APIs :) | 13:39 |
| Riddell | take a look at https://help.launchpad.net/API/launchpadlib | 13:39 |
| Riddell | I'm not sure if merges have APIs, but they ought to if there's any justice in the world | 13:39 |
| Morbus | heh, heh. | 13:40 |
| Riddell | ask in #launchpad to find out | 13:40 |
| maxb | Morbus: You probably want to look at the Launchpad Web Services API, and in particular, if you use python and launchpadlib, lp.branches.getByUrl(url="lp:.......").getMergeProposals(...) | 13:40 |
| Morbus | of course, i don't know any python, but i could figure it outl, I suspect. | 13:40 |
| Morbus | maxb: thanks! | 13:40 |
| Morbus | Riddell: you too :D | 13:40 |
| Morbus | hrm. if it's just a webservice that seems to export JSON, I shouldn't have to use python lib... | 13:41 |
| maxb | Python is not the only integration possibility, but it is the one with the most advanced client libraries | 13:42 |
| Morbus | sure. | 13:42 |
| Morbus | i don't necessarily need a whole shebang - i /just/ need the list of branches that have a merge request in. | 13:42 |
| Morbus | everything else i can handle from the command line locally. | 13:42 |
| maxb | Morbus: Try hitting this URL, then: https://api.launchpad.net/1.0/~bzr-pqm/bzr/bzr.dev?ws.op=getMergeProposals&status=Approved | 13:43 |
| Morbus | maxb: right. i presume that's protected by the same cookie auth as a private project is? | 13:44 |
| Morbus | cookie/session auth? | 13:44 |
| maxb | If it works, that's accidental. | 13:45 |
| Morbus | how do you mean? | 13:45 |
| Morbus | private thingies aren't supposed to be in the API? | 13:45 |
| maxb | The api.launchpad.net vhost is supposed to be accessed via OAuth tokens for authorization | 13:45 |
| Morbus | ah. | 13:46 |
| Morbus | does the pythonlib handle that too? | 13:46 |
| maxb | yes | 13:47 |
| maxb | Launchpad.login_with is the main entry point for authenticated access | 13:47 |
| Morbus | hrm. i think i tweaked this wrong: https://api.launchpad.net/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved | 13:48 |
| * maxb disappears for lunch, back ~15mins | 13:49 | |
| * Morbus heads off to try the pythonlib. | 13:49 | |
| maxb | or 5mins as the case may be | 13:56 |
| maxb | Morbus: Try hitting https://launchpad.net/api/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved with your cookie | 13:56 |
| Morbus | same error. | 13:56 |
| Morbus | Object: <lp.registry.model.personproduct.PersonProduct object at 0x12fd1fd0>, name: u'trunk' | 13:56 |
| maxb | Hm | 13:57 |
| maxb | No idea then, sorry | 13:57 |
| Morbus | i woudln't worry too much about it now. got launchpadlib installed and i'm gonna fiddle with that for a bit. | 13:57 |
| maxb | Probably time to hop over to #launchpad for any further questions | 13:57 |
| __monty__ | If I want to rename a branch can I just rename the directory? | 13:58 |
| __monty__ | Or can I use bzr mv oldbranch/* newbranch/ ? | 13:59 |
| maxb | just rename the directory | 14:00 |
| __monty__ | ty | 14:00 |
| === Ursinha is now known as Ursinha-afk | ||
| Morbus | hrm. where does this launchpadlib store the OAuth details I'm abotu to put in? | 14:07 |
| Morbus | the script will be running as a different (non-Unix) user than my current Unix user, so I don't want it to overwrite my own data. | 14:08 |
| === Ursinha-afk is now known as Ursinha | ||
| Morbus | wrong chan. | 14:09 |
| Riddell | ug, I keep using the broken "s" for submit option on feed-pqm | 14:14 |
| Riddell | lifeless: is it true you have a good reason for keeping that around? | 14:14 |
| vila | Riddell: hehe, was just reading such emails :) | 14:17 |
| Riddell | poolie: if you add me to ~hydrazine-core I'll set up daily builds so the packaging is no longer a year out of date | 14:21 |
| Riddell | I might also get rid of the broken "s" option on feed-pqm while nobody is looking :) | 14:21 |
| vila | Riddell: Propose a branch for merge, I run from sources ;) | 14:27 |
| lifeless | Riddell: nope | 15:27 |
| * lifeless disappears | 15:27 | |
| Riddell | oh good | 15:28 |
| vila | spiv: wake up ! wake up ! I have good news ! | 15:57 |
| vila | spiv: what ? Not even 1AM and you're not there... Sheesh | 16:03 |
| vila | For the rest of the crowd: one source of selftest hanging on babune shut got a head-shot, thanks to spiv ;) | 16:04 |
| vila | For the rest of the crowd: one source of selftest hanging on babune just got a head-shot, thanks to spiv ;) | 16:04 |
| vila | just not shut... tyops are back | 16:04 |
| vila | I blame fullermd | 16:05 |
| mgz | it's generally his fault. | 16:05 |
| mgz | vila: can you run a branch of mine on one of your forking babune slaves? | 16:07 |
| mgz | I think I fixed the remaining pain, just want to double check before proposing | 16:07 |
| vila | mgz: sure | 16:07 |
| vila | which branch and which subset ? | 16:08 |
| mgz | lp:~gz/bzr/cleanup_testcases_by_collection_613247 as always hang fix before r | 16:08 |
| mgz | ...interesting edit | 16:08 |
| mgz | that branch, but merge in whatever you need to make a full run work too. | 16:08 |
| vila | say that again ? | 16:08 |
| mgz | so, the import tariff hang fix if that was an issue on the slae | 16:09 |
| mgz | *slave | 16:09 |
| vila | I'd prefer a significant subset, not *all* hangs are fixed, I have a couple of pretty good silver bullets now tough | 16:09 |
| * mgz blames vila's infectious typos | 16:09 | |
| vila | hehe | 16:09 |
| vila | justasec, a couple of zombies to kill first | 16:10 |
| mgz | `-s bb. -s bt.test_` isn't bad, but I want a full run to compare resource usage really | 16:10 |
| mgz | I got it through a complete selftest on the laptop (after stopping X, had som OOMs trying to fork otherwise), so it should run inside 240MB or so | 16:11 |
| vila | hmm, a full run will be more complex *right now*, let's try with the subset and ping me again if I forget the full one | 16:11 |
| mgz | okay | 16:11 |
| vila | but how will you check resources usage on babune ? | 16:12 |
| mgz | but parallel=fork please, and optionally -Euncollected_cases | 16:12 |
| mgz | ^...it doesn't give metrics? er... speed I guess then. | 16:12 |
| vila | hmm, you know what ? File a bug on lp against babune so I can better track that | 16:12 |
| vila | yeah, speed could be a good indirect indicator | 16:13 |
| vila | hmm, bt.test_ will include tariff, no good, can *you* merge lp:~vila/bzr/import-tariff-test-subprocess-deadlock instead ? | 16:14 |
| vila | can we start with -s bb instead ? | 16:15 |
| mgz | okay, -s bb. then | 16:15 |
| vila | or is it not good enough ? | 16:15 |
| mgz | that should be clean though. | 16:15 |
| vila | mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/109/aggregatedTestReport/ | 16:16 |
| vila | crap typo in the branch name ;) | 16:19 |
| mgz | ehhee | 16:21 |
| mgz | add -s bt.test_selftest to the subset if you've not restarted yet | 16:21 |
| mgz | that should give some output | 16:21 |
| vila | I did, but it' soon enough to cancel | 16:22 |
| vila | hmm, 3 slaves running concurrently, if bad things happen, don't take the blame... | 16:24 |
| vila | ...or not too fast ;) | 16:24 |
| vila | http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/111/aggregatedTestReport/ | 16:25 |
| vila | mgz: gentoo failures already available, shallow ? | 16:26 |
| mgz | hm, that's the hard test case. | 16:26 |
| vila | mgz: same number on freebsd, karmic, osx (macadam is osx) | 16:27 |
| vila | Oh, I didn't specify -Exxx | 16:27 |
| vila | if that helps... | 16:27 |
| mgz | should work anyway, but those failures are from trying to exercise the parallel=fork code | 16:27 |
| mgz | which is... tricky | 16:28 |
| vila | unexplored territory.. unfortunately | 16:28 |
| vila | mgz: which makes me believe you're not splitting your proposal enough :-D | 16:29 |
| mgz | the code needs to work... | 16:29 |
| mgz | I can continue landing things that don't actually fix the issue for ever | 16:30 |
| mgz | but maybe I'll split fixing parallel=fork from the rest. | 16:30 |
| vila | mgz: well, -Euncollected_cases as a first step would be good to start with no ? | 16:31 |
| vila | mgz: if it requires *not* using --parallel, I'll still buy it | 16:31 |
| mgz | not if it prints every single test case when you run selftest with --parallel=fork :) | 16:31 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| vila | mgz: I can live with such a limitation as long as it doesn't break --parallel=fork when I *don't* use it ! | 16:32 |
| vila | mgz: if we reach the point where the test suite can fully run without OOMing that would make me extremely happy | 16:33 |
| mgz | what's the subunit version on those slaves? | 16:34 |
| vila | hmm, close to trunk I think, except for the osx one maybe | 16:34 |
| vila | oh no, even the osx one mounts my source dir | 16:35 |
| mgz | and testtools? | 16:36 |
| vila | so, trunk for subunit | 16:36 |
| vila | hey, let me type :) | 16:36 |
| vila | trunk too | 16:36 |
| mgz | hum hum. | 16:37 |
| vila | but that's not true for the chroots (but you don't care at that point (OMG this is becoming complex again :-/))) | 16:37 |
| mgz | I'll have to boot the laptop again, darn 2.6 requirement | 16:37 |
| vila | ha | 16:38 |
| vila | I updated this week after months of using very old versions... | 16:38 |
| mgz | hm, passes here. wonder if it's something about being a real multicore machine. | 16:41 |
| vila | not passing here | 16:44 |
| vila | just a note: | 16:44 |
| vila | have a look at my last --exclude ORed proposal for a trick to use short names for tests, you will then be able to use assertEquals instead of assertContains | 16:45 |
| vila | no big deal but I feel better not using regexps when I can avoid them | 16:45 |
| mgz | yeah, saw that. | 16:46 |
| mgz | still need contains, because it looks at the whole output | 16:46 |
| mgz | which is good here, because it tells me no tests are being run under fork | 16:46 |
| mgz | ...not sure why though | 16:46 |
| mgz | anyway, problem with the test not the case cleanup code | 16:47 |
| vila | http://paste.ubuntu.com/613816/ | 16:47 |
| vila | after running ./bzr selftest -s bt.test_selftest | 16:47 |
| vila | I'll ignore the two errors blaming some weird merge | 16:48 |
| mgz | ...and there it's the reverse problem | 16:48 |
| mgz | all the cases are leaking | 16:49 |
| mgz | but the test works. | 16:49 |
| vila | ha crap, forgot =-site | 16:49 |
| vila | ok single error, s/<above>/&/ :) | 16:50 |
| mgz | ...does that help? if not, I'd check bzrlib.tests.fork_for_tests and make sure the two list emptying statements survived the merge | 16:50 |
| vila | what ? You pushed ? | 16:50 |
| mgz | nope. | 16:51 |
| mgz | I'm just trying to understand your results | 16:51 |
| mgz | ...I'm not sure I have ssh to any machines with python 2.6 | 16:52 |
| vila | oooh, I love "notify = "uncollected_cases" in selftest_debug_flags" :D | 16:52 |
| vila | mgz: lol, reading your patch, tu quoque mi fili ! using test_suite_factory :) | 16:56 |
| vila | mgz: but you don't support the arguments, a bit more risky but good enough here | 16:57 |
| vila | mgz: come to think of it, the conditional code in sefltest for test_suite_factory may be better *outside* of tests.selftest | 16:58 |
| mgz | there are quite a lot of oddities with how code is arranged for selftest | 16:58 |
| vila | or rather, always called in the same way | 16:58 |
| vila | yeah, history | 16:58 |
| mgz | even having taken an axe to decorators, they're still a pain in the bum | 16:58 |
| mgz | I can't get a simple param from run_suite down to the code that does the forking | 16:59 |
| mgz | so have to monkey patch subunit | 16:59 |
| mgz | I'm still none the wiser about why the slaves didn't manage to run the forking test correctly | 17:01 |
| vila | only 3 failures on windows | 17:01 |
| vila | can't you just override the forking code ? | 17:02 |
| mgz | no fork! ... and they look very familiar failures I thought we'd fixed in the past. | 17:02 |
| mgz | basically about trying to read a locked pack file. | 17:03 |
| vila | huh ? Those are new to me... may be I didn't notice them earlier ? Worth investigating | 17:04 |
| vila | but right, not now, indeed, different failures | 17:04 |
| mgz | ^I want to test the actual code that selftest uses to do the test splitting and forking, because it has issues now | 17:04 |
| mgz | I don't like fixing problems if I'm not testing that they won't regress | 17:04 |
| vila | I was suggesting wrapping them to address your params passing issue | 17:05 |
| mgz | the problem is there are already too many wrappers :) | 17:06 |
| vila | nah... the functions you're after are not *yet* wrapped ;D | 17:07 |
| mgz | can you re-run the subset with the flag on? | 17:09 |
| mgz | ...I don't think it'll help me understand why the fork tests aren't happy on babune, but I'm out of ideas | 17:09 |
| vila | fired | 17:11 |
| vila | mgz: I wonder if your overrides survives the fork... | 17:13 |
| mgz | ooh, interesting | 17:14 |
| vila | ...or something | 17:14 |
| vila | may be silly but since you ran out of ideas, I'm trying to help :D | 17:14 |
| mgz | of course I've not been running the whole suite under --parallel=fork here | 17:14 |
| mgz | I'll see if I can get the failure by forcing that | 17:15 |
| mgz | yeay! | 17:15 |
| mgz | I can repo. | 17:15 |
| mgz | okay, will fix. | 17:15 |
| mgz | ...also, annoying, you don't get a full test count with --parallel=fork just a running total of completed tests | 17:16 |
| mgz | thanks vila! | 17:16 |
| vila | me ? Thank my daemon, he send me stupid ideas all day ! | 17:18 |
| vila | mgz: seriously, I have no idea why you're thanking me... any hint ? | 17:24 |
| mgz | your suggestion was enough to tell me how to reproduce the failures babune got locally | 17:25 |
| mgz | if I can reproduce, I can fix. | 17:26 |
| vila | haa, great ! | 17:26 |
| mgz | so, the why might be wrong, but the wondering was useful | 17:26 |
| smoser | vila, or maxb, could someone handle bug 788736 for me ? if its not a terribly painful thing. | 17:52 |
| ubot5 | Launchpad bug 788736 in Ubuntu Distributed Development "python-boto parallel import repair" [Undecided,New] https://launchpad.net/bugs/788736 | 17:52 |
| __monty__ | u | 17:53 |
| vila | smoser: justasec, just found it the mail in my backlog (and this has been a busy day...) | 17:55 |
| __monty__ | vila are you online | 17:55 |
| vila | __monty__: yes, but expect lag, I should have stopped working already ;) | 17:56 |
| __monty__ | vila: About the error for which I'm trying to add a test, do you have any idea why the result differs for you and me? | 17:58 |
| vila | __monty__: I don't know *what* result you get, but search for socket.error in the code base, there are plenty of cases where the same pattern occurs (EPIPE among others) | 17:59 |
| vila | smoser: on it | 17:59 |
| vila | smoser: branches overwritten, deleting tags | 18:00 |
| vila | smoser: expectedly getting No such tag errors :) | 18:00 |
| vila | maxb rocks... | 18:01 |
| Daviey | vila: Whilst looking at that one, fancy actioning maxb's suggestion for sysvinit :) ? | 18:04 |
| __monty__ | vila: Could you glance at the results I get for selftest? https://code.launchpad.net/~toonn/bzr/socket.error-traceback-393713/+merge/62585 | 18:04 |
| vila | smoser: requeued | 18:04 |
| vila | smoser: running | 18:05 |
| vila | Daviey: meh, which one ? I think I requeue that recently | 18:05 |
| Daviey | vila: https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2011-May/000807.html :) | 18:06 |
| vila | Daviey: :-/ I don't know enough there to act without maxb | 18:09 |
| * maxb waves | 18:09 | |
| vila | rejoice ! | 18:09 |
| vila | maxb: sudo what ? :D | 18:10 |
| maxb | I guess the first thing we need to do is decide which of my proposed options w.r.t. sysvinit we are going to go with | 18:10 |
| maxb | Daviey: How anxious are you to get this sorted? | 18:10 |
| Daviey | maxb: today doesn't matter | 18:11 |
| maxb | I would quite like to get james_w's opinion on my email | 18:12 |
| vila | smoser: comment on the bug when you get some results. Thanks in advance | 18:12 |
| Daviey | maxb: Throwing away the trivial merge doesn't seem to matter, but it's not a really a good generic fix IMO. As it's not ideal for other situations | 18:12 |
| vila | __monty__: just a sec | 18:13 |
| Daviey | vila: thanks for looking into it | 18:13 |
| maxb | Daviey: Agreed. Though, the situation that sysvinit is in on Launchpad, with some Ubuntu branches existing but no Debian branches existing, should never occur naturally anyway | 18:13 |
| vila | Daviey: np, thank maxb ;) | 18:13 |
| Daviey | maxb: I blame smoser. | 18:14 |
| maxb | So I'm guessing that someone has been doing some manual fiddling there anyway | 18:14 |
| maxb | eh? | 18:14 |
| maxb | Have we crossed sysvinit and python-boto? | 18:14 |
| Daviey | no, i just enjoy blaming smoser for generic things. | 18:14 |
| smoser | i probably did it. i am constantly fighting with bzr. it sees things differently than i do. | 18:14 |
| vila | __monty__: ok, so what OS are you on ? | 18:14 |
| vila | Oh, oSX | 18:14 |
| __monty__ | vila: os X.6 | 18:14 |
| smoser | and since i don't have a 'smoser' to blame like Daviey does, i usually just blame bzr. | 18:15 |
| __monty__ | vila: no os X.5.8 (sry) | 18:15 |
| vila | __monty__: ha ha, an OSX 10.5 user using python2.6... | 18:16 |
| vila | __monty__: you know what ? We may have more interesting bugs for you :) But let's focus on that one first | 18:16 |
| __monty__ | vila: Sure. | 18:17 |
| vila | sockets can raise different kind of execptions depending on the platform so you need to be ready for that | 18:18 |
| __monty__ | vila: Anywhere I can find what exception they raise on what platform? Or how do I handle this? | 18:19 |
| vila | __monty__: we care more about catching all the relevant ones that tracking which platform track which kind, so try grepping the sources for socket.error | 18:20 |
| vila | __monty__: more concretely, what you should check is not the *message* but rather the class of the exception and then the associated args | 18:23 |
| vila | you should find plenty of examples in the code | 18:23 |
| __monty__ | Indeed, they are plentiful. | 18:23 |
| vila | __monty__: so, if you start working again, it's better to put your mp into the 'Work In Progress' state | 18:32 |
| vila | __monty__: because it will pop up in the list again once you put it back to 'NeedsReview' | 18:33 |
| __monty__ | Ah yes, hadn't thought of that. | 18:33 |
| maxb | Argh, what?! The python-boto reimport has somehow retained the revisions that were not supposed to be there?! | 18:34 |
| __monty__ | vila: Care to give me another clue? I don't really understand what to learn from the examples in the code. | 19:03 |
| === medberry is now known as med_out | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| vila | __monty__: sorry, was afk | 19:40 |
| vila | so, what are you trying to test exactly ? | 19:40 |
| __monty__ | vila: I'm working on the test for the socket.error which apparently behaves different on linux(?) and on os X. | 19:54 |
| vila | right, I got that, but why are you doing that ? What is your final goal ? | 19:55 |
| __monty__ | Proving that the socket.error is allready caught? Because it's a subclass of IOError. | 19:57 |
| smoser | maxb, so any ideas? | 19:57 |
| smoser | it looks like the score is still : smoser's stupidity: 1, bzr: 0 | 19:58 |
| poolie | hi all | 19:59 |
| vila | __monty__: then you want a test that succeeds at catching IOError but fails at catching socket.error ? | 19:59 |
| vila | poolie: wow, hey ! | 20:00 |
| vila | poolie: is it late for me, early for you or both ? | 20:00 |
| poolie | :) early for me | 20:00 |
| vila | rats, I thought I could stop and enjoy my week-end ;-D | 20:01 |
| poolie | :) well, you can | 20:04 |
| poolie | isn't it something like 9pm there anyhow? | 20:04 |
| poolie | i just thought i'd poke at some discretionary lp patches since i'm up so early | 20:04 |
| vila | one last bug ! | 20:04 |
| vila | :) | 20:04 |
| __monty__ | vila: No I don't think so. Because IOError is allready handled by test_trace.py and socket.error is a subclass thereof (since python 2.6) the cause of bug 393713 no longer produces a traceback. I am now trying to add a test that proves this. So the bug can be closed. | 20:04 |
| ubot5 | Launchpad bug 393713 in Bazaar "[master] socket.error causes a traceback" [Medium,Confirmed] https://launchpad.net/bugs/393713 | 20:04 |
| vila | __monty__: if you raise a socket.error and have two exception handlers, one for IOError and one socket.error, if socket.error is a subclass, the IOError handler will trigger, if not, the socket.error handler will trigger, which one triggers tells you if your proof is correct | 20:06 |
| __monty__ | Ah, like so. So I try catching IOError first? | 20:07 |
| vila | __monty__: just try ! That's what tests are for ! Experimenting with your understanding of the code ! | 20:08 |
| __monty__ | Still, I don't really understand how the tests work. Is there someplace I can read up on them? My main difficulty with them is that the except blocks are just 'pass'ed and then the error string is checked. | 20:09 |
| vila | __monty__: try adding a self.debug() at the first line of your test and execute it step-by-step under pdb, that should help you understand how it works | 20:11 |
| __monty__ | vila: How do I run it in pdb? import pdb; import bzrlib.tests.test_trace; pdb.run('test_format_sockets_error()') ? | 20:20 |
| vila | __monty__: try adding a self.debug() at the first line of your test | 20:20 |
| vila | __monty__: and just re-run ./bzr selfest | 20:20 |
| __monty__ | vila: Can I go on step by step? Because now it just stops, then I type continue and the results for selftest are shown. | 20:23 |
| poolie | vila, tests using threading seem highly likely to be flakey | 20:24 |
| poolie | except KeyboardInterrupt, e: | 20:24 |
| poolie | out, err = e.args | 20:24 |
| poolie | wow that's quite creative | 20:24 |
| vila | __monty__: you don't know how to use pdb ? | 20:25 |
| poolie | well, good luck to you | 20:25 |
| poolie | __monty__: to step, use 's' or 'n' | 20:25 |
| poolie | the latter steps over function calls | 20:25 |
| __monty__ | vila: No, but 'step' seems to do the trick. | 20:25 |
| vila | doh, I'm tired, that was a silly question :( | 20:26 |
| vila | __monty__: http://docs.python.org/library/pdb.html?highlight=pdb#module-pdb | 20:26 |
| vila | poolie: I disagree | 20:27 |
| __monty__ | vila: I allready have that open, it's just I don't really see what's the point in using pdb. I can go over the code just reading it no? It doesn't seem to give me extra information. | 20:27 |
| vila | poolie: they are flaky only when they are buggy, at least that's my experience based on debugging the thread leaks | 20:28 |
| vila | poolie: most of the bugs where bad synchronization | 20:28 |
| vila | __monty__: you said you didn't understand how the tests worked, the best way to understand them is to see them run, just reading them reading doesn't have the same taste ;) | 20:29 |
| vila | poolie: s/where/were/ | 20:29 |
| vila | poolie: and unsurprisingly here, that's still a race, involving processes instead of threads but still a race | 20:30 |
| __monty__ | vila: What I meant was, why is(are) there except blocks if they don't do anything? | 20:30 |
| vila | __monty__: try removing them and you'll soon realize they *do* something | 20:31 |
| poolie | monty, where? | 20:31 |
| vila | __monty__: probably swallowing an execption | 20:31 |
| __monty__ | Ah, didn't realise that a trp | 20:32 |
| __monty__ | *Ah, didn't realise that a try block still raises the error if it's not handled. | 20:32 |
| poolie | it's not so much it still raises it, it just doesn't stop it propagating | 20:37 |
| __monty__ | vila: I'm still not sure about what you said earlier, 'the handler that's triggered will proof socket.error is a subclass'. Why should I proof that, it is true(since python 2.6). I think what I need to proof is that the socket.error is allready handled in test_trace.py, no? | 20:39 |
| __monty__ | poolie: Thank you for correcting. | 20:39 |
| vila | __monty__: I don't know, does test_trace catch IOError ? | 20:40 |
| __monty__ | Yes. | 20:40 |
| vila | that's not what your test is showing | 20:41 |
| __monty__ | vila: That's true but how do I show that? | 20:41 |
| vila | we're running into cycles, where did you start ? What was failing ? | 20:42 |
| vila | __monty__: the bug report says: "I think that on python2.6 (which is required for bzr2.4) this bug will be implicitly fixed because socket.error has become a subclass of IOError, which does not generate a traceback. We should test that though." | 20:44 |
| __monty__ | nvm what I was typing. In short that's the reason for the test ^. | 20:44 |
| vila | __monty__: that's what I described above: proof that IOError is a subclass of socket.error, this can be as simple as assertIsInstance(socket.error(), IOError) or assertTrue(issubclass(socket.error, IOError)) or a bit more detailed as I explained above | 20:47 |
| vila | if you want to go further then you need to find a case which indeed raise a socket.error, explore the call stack, remove the now useless socket.error handlers and check (with tests) that the behavior is still the same | 20:49 |
| __monty__ | vila: What socket.error handlers are you talking about? | 20:49 |
| pl0sh | hey guys, how can I publish my branches on my own server? | 20:50 |
| vila | any try block with a except socket.error clause | 20:50 |
| vila | pl0sh: by allowing people to connect to your server with any protocol supported by bzr: ftp/http/ssh/bzr | 20:51 |
| vila | pl0sh: the setup ranges from none to quite sophisticated depending on the protocol | 20:52 |
| === med_out is now known as medberry | ||
| pl0sh | let's say http, because my dev's uses winsucks, but my server is a freebsd box | 20:55 |
| poolie | pl0sh: do they need read write or readonly access? | 20:56 |
| poolie | if they're developers i guess rw? | 20:56 |
| poolie | the easiest thing then is to let them ssh in and run bzr over ssh | 20:56 |
| poolie | the bzr windows client includes ssh support | 20:56 |
| __monty__ | vila: I think I don't really understand the problem then. I thought what I was trying to solve was the fact that people got a traceback when a socket.error occured. Bug 364462 is what I started on but poolie(I think) pointed out it's a dupe of 393713. | 20:57 |
| ubot5 | Launchpad bug 364462 in bzr email commit hook "smtp "connection timed out" causes full stack trace to be dumped (dup-of: 393713)" [Medium,Confirmed] https://launchpad.net/bugs/364462 | 20:57 |
| ubot5 | Launchpad bug 393713 in Bazaar "[master] socket.error causes a traceback" [Medium,Confirmed] https://launchpad.net/bugs/393713 | 20:57 |
| pl0sh | poolie well, they have to be able to commit and merge the changes | 20:57 |
| poolie | monty, where are you with it now? | 20:57 |
| poolie | ok, so bzr+ssh is the way to go | 20:57 |
| pl0sh | Ok, where can I find some info? | 20:58 |
| __monty__ | poolie: Still nowhere pretty much. | 20:58 |
| pl0sh | I have installed bzr on my freebsd and on my windows boxes | 20:58 |
| poolie | pl0sh: there's an admin guide | 20:59 |
| poolie | but, basically, start an ssh server on the bsd box | 20:59 |
| poolie | then just from a windows box run eg | 20:59 |
| poolie | 'bzr init bzr+ssh://bsd/~/test' | 20:59 |
| pl0sh | great | 21:00 |
| pl0sh | and bzr push bzr+ssh://bsd/~/test right? | 21:01 |
| pl0sh | to push changes to the repo | 21:01 |
| flacoste | is there an easy API in bzrlib available to get the LP API branch URL from a working tree? | 21:01 |
| flacoste | i have a working tree of a branch on lp and want to make API call on its LP representation | 21:01 |
| poolie | hi flacoste | 21:08 |
| flacoste | hi poolie | 21:08 |
| flacoste | i was about to try | 21:08 |
| poolie | pl0sh: correct | 21:08 |
| poolie | i think there is one in plugins/launchpad | 21:08 |
| flacoste | from bzrlib.plugins.launchpad import lp_api | 21:08 |
| flacoste | lp_api.from_bzr(lp, branch) | 21:08 |
| __monty__ | poolie: I'm trying to write a test for 393713 but I'm not sure what to write in it. (Doing this because you say in comment #4: 'We should test that though.') | 21:21 |
| poolie | flacoste: so is that ok | 21:22 |
| flacoste | poolie: still writing the script :-) | 21:22 |
| flacoste | from the look of it, it seems like it's exactly what i need | 21:23 |
| poolie | flacoste: separately i was wondering if you could nudge lp reviewers to land more approved 3rd party patches | 21:23 |
| poolie | not me, other peolpe | 21:23 |
| poolie | if you want to add a tip to the api guide docs or wiki page that would be welcome | 21:23 |
| poolie | what are you writing, just for curiouisyt? | 21:23 |
| vila | g'night all, have fun ! | 21:24 |
| __monty__ | vila: gn, thanks for helping. | 21:24 |
| flacoste | poolie: a script to make a principia package branch official | 21:24 |
| poolie | monty, have you pushed your current code? | 21:25 |
| flacoste | poolie: inspired by set_official.py in udd but less coupled to the package-importer implementation | 21:25 |
| poolie | i'll have a look at the review | 21:25 |
| poolie | cool | 21:25 |
| * __monty__ nudges poolie to stop ignoring his question? :) | 21:25 | |
| flacoste | poolie: people approving a third party branch are supposed to take care of landing it, isn't that happening? | 21:26 |
| poolie | apparently not | 21:26 |
| flacoste | poolie: remember that it's not visiale if they have submitted it to ec2test and it will take some time to update | 21:26 |
| poolie | just sliping through the cracks i think | 21:26 |
| flacoste | well, i'm seeing 3rd party branches merged | 21:26 |
| flacoste | nigelb and chris' one | 21:26 |
| flacoste | which one haven't landed? | 21:27 |
| poolie | like https://code.launchpad.net/~james-w/launchpad/more-matchers/+merge/32057 | 21:27 |
| flacoste | it's lifeless here that needs nudging | 21:27 |
| poolie | 3 from chrisjohnson | 21:27 |
| flacoste | he might not be aware of it | 21:27 |
| poolie | oh to rereview it? | 21:27 |
| flacoste | he approved it | 21:27 |
| poolie | i've just put one of chris's up for ec2 | 21:27 |
| pl0sh | poolie thanks | 21:27 |
| poolie | i'm not saying it never happens, just it apparently doesn't always happen | 21:28 |
| poolie | i am very happy chris & others got prompt reviews | 21:28 |
| flacoste | i can send a reminder | 21:29 |
| poolie | vila, you just need a couple of tweaks to the utextwrap thing | 21:29 |
| poolie | __monty__: sorry, not trying to ignore you | 21:29 |
| poolie | show me the test you have currently? | 21:30 |
| poolie | if any | 21:30 |
| __monty__ | poolie: It's worthless currently. | 21:30 |
| poolie | i thought yesterday we got up to having a test based on the other error-reporting tests | 21:30 |
| poolie | that raised a socket error and then checked it was printed in a reasonable way | 21:31 |
| poolie | did that break? | 21:31 |
| __monty__ | Well, turns out the error message is different on different platforms. | 21:31 |
| poolie | oh, that's too be expected, yeah | 21:32 |
| ironcamel | has anyone got bzr bisect to work http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html ? | 21:32 |
| poolie | the main thing we want to assert in the test is just that it does not give a stack trace | 21:32 |
| poolie | ironcamel: what specifically is going wrong? | 21:32 |
| ironcamel | poolie: i installed it, but bzr bisect doen't do anything | 21:33 |
| ironcamel | bzr: ERROR: unknown command "bisect" | 21:33 |
| __monty__ | poolie: Agreed, so just test the string for not containing 'traceback' ? | 21:33 |
| poolie | how about 'bzr plugins -v' | 21:33 |
| poolie | __monty__: i think it's "Traceback" but yes | 21:33 |
| ironcamel | poolie: it's not listed | 21:34 |
| poolie | how did you install it? | 21:34 |
| ironcamel | poolie: python setup.py install | 21:34 |
| ironcamel | got the source from https://launchpad.net/bzr-bisect | 21:34 |
| poolie | hm, i wonder where that installed it to? | 21:36 |
| poolie | perhaps something that's not on your bzr plugin path | 21:36 |
| ironcamel | not sure | 21:36 |
| poolie | typically you'd install from source with just eg | 21:36 |
| poolie | bzr branch lp:bzr-bisect ~/.bazaar/plugins/bisect | 21:36 |
| ironcamel | oh really | 21:37 |
| ironcamel | it comes with a setup.py, so that's why i did that | 21:37 |
| ironcamel | poolie: i think that did it :) | 21:38 |
| ironcamel | a little documentation would have made this easier | 21:39 |
| poolie | please file a bug against it about the setup.py not doing the right thing | 21:39 |
| ironcamel | sure | 21:40 |
| ironcamel | done | 21:42 |
| __monty__ | poolie: This is what the test should look like right? https://code.launchpad.net/~toonn/bzr/socket.error-traceback-393713/+merge/62585 | 21:51 |
| poolie | looks pretty good | 22:00 |
| __monty__ | Ok, then I'm off, thanks for the help. Hope I can work on a different bug tomorrow. :) | 22:02 |
| smoser | hm... lp:ubuntu/nagios-plugins seems to be screwed up the same way python-boto is. | 22:12 |
| smoser | opened bug 789342 to address that. | 22:14 |
| ubot5 | Launchpad bug 789342 in Ubuntu Distributed Development " lp:ubuntu/nagios-plugins gives strange diffs" [Undecided,New] https://launchpad.net/bugs/789342 | 22:14 |
| === Ursinha is now known as Ursinha-afk | ||
| poolie | thanks smoser | 22:15 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === JayFo is now known as JFo | ||
| mgz | poolie, did you get a chance to look at my additions to your stale locks branch? | 23:26 |
| mgz | I... was slightly losing track last night but I think the code makes sense | 23:26 |
| poolie | mgz i did merge it in | 23:28 |
| poolie | thanks for that | 23:28 |
| poolie | i have some more items from spiv still to fix | 23:28 |
| poolie | at the moment i'm just finishing off some pending lp work | 23:28 |
| mgz | in unrelated bookkeeping, do I need to bug someone for an expenses form for last week? | 23:32 |
| poolie | yes, marianna | 23:33 |
| mgz | will email. | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!