=== timfreun1 is now known as timfreund [09:12] hi all [09:12] does ubuntu allow apps that run on an emulator? [13:13] james_w: https://code.launchpad.net/~jml/pkgme-binary/backend-tests/+merge/88365 up for review [13:13] james_w: speeds up the test suite [13:42] ajmitch: around? [14:16] jml, reviewed [14:17] jml, I'm adding a card to add a pdf test to the acceptance tests [14:22] jml, I also added one yesterday to set up CI [14:40] james_w: thanks. [15:05] james_w: was thinking of writing a little command-line twisted app that takes a pkgme-service url, a tarball and a metadata file, submits the tarball & metadata file to the pkgme-service, and terminates when it gets a response [15:05] jml, I think that would be very useful indeed [15:06] james_w: would be useful for testing our current production deployment works, and probably also for future issues. [15:06] james_w: ok, I'll do that then. [15:08] jml, I'm assuming we'll be able to hit the pkgme-service API url from the developer access machine to test production [15:16] james_w: or that a losa will [15:17] yeah [15:17] I wonder if it could form the basis of a much improved nagios check as well? [15:33] james_w: there's a thought. [17:39] james_w: I'm trying to submit a package to my local pkgme service and it's not finding the database [17:39] james_w: "no connection info available" [17:49] jml, dependency database? [18:04] james_w: yeah, that one [18:05] jml, do you have ~/.config/pkgme-binary? [18:05] james_w: I guess what I mean is, how do I say "use dev.cfg" (or is it actually looking for it?) [18:05] james_w: no. [18:05] james_w: how about I do that :) [18:05] jml, dev.cfg is used if production_credentials.cfg isn't there [18:05] so it should be using it already [18:06] james_w: hmm. so it should be looking for test.db, right? [18:06] ~/.config/pkgme-binary/conf needs to point to a database containing valid dep db information [18:06] two different databases [18:07] test.db holds all the pkgme-service tables, but doesn't have the pkgme-binary dependency tables [18:07] ahh, of course. [18:17] james_w: there's something going on that I don't understand. [18:18] james_w: the script runs fine and prints out the request body from the server [18:19] james_w: but the celery daemon logs a 'Connection refused' during submitter.request(metadata.callback_url, headers=headers, body=body) in submit_pkgme_info(metadata) [18:20] james_w: which I guess means it's trying to make a second connection. [18:20] james_w: the harness shuts down after the first successful one [18:21] jml, so it all works but it gets a refused connection calling the callback? [18:21] james_w: yes. [18:21] jml, that sounds plausible [18:21] celery doesn't log that it's running the job twice? [18:22] james_w: well, celery doesn't log much [18:22] it prints out every traceback twice though [18:23] but errors is all I get. [18:23] * jml looks for a verbose option [18:23] jml, also, have you encountered $PIP_DOWNLOAD_CACHE yet? [18:24] it makes "fab bootstrap" a little bit less annoying [18:24] james_w: I have. [18:24] good [18:24] james_w: but it's still pretty annoying :) [18:24] yes :-) [18:24] running it now to try out your new script [18:38] james_w: got debug logging working. no sign of two jobs. [18:41] jml, you made a tarball from acceptance test data? [18:41] (trying to run it myself) [18:41] james_w: yeah, I just used the gtk one [18:42] jml, is it easy to change the twisted server to shut down after two requests? [18:42] james_w: hmm. I guess so. I tried changing it to not shut down at all, but the second request never came. [18:43] hmm [18:44] that seems equivalent then [18:44] jml, have you confirmed it's getting one request? [18:44] james_w: how do you mean? [18:44] jml, the theory is that it's shutting down after the first request, but have you confirmed that it's getting a request and shutting down [18:45] rather than the port being wrong and so no requests are making it to the callback server? [18:45] james_w: it's definitely getting the callback request. [18:45] ok [18:45] james_w: it prints the output from that to stdout [18:47] ah yes [18:47] (I'm just seeing "timeout while waiting for response" so far) [18:48] james_w: check celeryd@test.log [18:48] (because I haven't set up ~/.config/pkgme-binary yet) [18:48] ah. [18:54] ok, I'm seeing the same thing now [18:58] cool. [18:59] exarkun suggested "You may also be shutting down the reactor such that the response is never sent, and some kind of retry logic in the client is kicking in." [18:59] and when I put a delay between sending request & shutdown, everything works fine [18:59] annoyingly, there's no event to hook on for "response sent" [19:00] ah [19:00] that would do it [19:00] reactor.callLater(0, ...) to the rescue :( [19:00] 0 meaning no timeout, which will run as the next thing after what it is doing, which happens to be sending the response? [19:01] yes [19:01] in the next event loop cycle, roughly [19:02] ok [19:02] do you know why it was working in the integration test? [19:03] I guess the reactor isn't shut down until the end of the test? [19:04] james_w: errors in the celery log don't necessarily fail the integration test. [19:04] ah, true [19:04] I'd like to fix that. [19:04] But I don't really know how. :) [19:04] yeah [19:05] also, the url in the response printed by the harness isn't a url, do we need to add another config option for that? [19:05] one for the dir to put the tarballs in, one for the url to get things in that dir? [19:06] yeah, probably [19:06] also, I seem to have broken the test somewhere along the line [19:10] nope. [19:10] it's just that it behaves poorly with already-running celery [19:10] james_w: I'm late for things. [19:10] ok [19:10] james_w: will catch up tomorrow. please merge this branch if you think it's ok. [19:11] jml, looks fine to me, if you are happy with it I will [19:11] I am. [19:11] g'night all === JanC_ is now known as JanC [21:54] jml: I'm around now, guessing that you're not? :)