[00:05] <blr> wgrant: have project +setbranch working (sans tests currently), but would also like the branch to include the vcs default on the project info page - working on that now.
[00:20] <blr> wgrant: cjwatson: does "Preferred VCS" work better than "Default VCS", only for user facing UI.
[00:25] <wgrant> blr: "Version control system", I think.
[00:25] <wgrant> Possibly with text near it that says the other repos will still be usable, but only if they exist.
[00:25] <wgrant> lifeless: 99% is almost exactly 1s.
[00:25] <wgrant> Don't know requests per day offhand.
[00:31] <wgrant> blr: It is technically only the preferred VCS, but "technically" arguments don't usually make for good UI :)
[00:31] <lifeless> wgrant: thanks; 1s seems slow :(
[00:32] <lifeless> wgrant: I don't suppose you remember what it was a couple years back
[00:32] <wgrant> lifeless: Much better than it was, but indeed. It's dragged down by bugs at the moment due to the way subscriptions are implemented.
[00:32] <wgrant> lifeless: It was ~1.4 between 2012 and 2013.
[00:33] <wgrant> Only with the new DB servers did it drop substantially below that.
[00:34] <wgrant> s/dragged down/dragged up/
[00:38] <lifeless> I knew what you meant :P
[00:38] <lifeless> made worse
[00:47] <blr> wgrant: yes have a note that you can still have bzr/git repos as well using the formHelp class
[00:48] <blr> lifeless: we're running on SSDs now which presumably have made a difference
[00:55] <blr> not loving this markup, but it will have to do for now.
[02:42] <blr> wgrant: shall I merge the tabbed pull instructions into this branch?
[02:42] <blr> err push
[02:46] <wgrant> blr: That possibly makes sense less on a form that has to show both sets of options anyway.
[04:22] <blr> wgrant: hmm, I've pushed a bzr branch to lp.dev/foo, which appears to have succeeded, however IBranchCollection(self.context).is_empty() is true (where self.context is foo)
[04:23] <blr> do I need to run a branch scan job?
[04:26] <blr> ./cronscripts/process-job-source.py -v IBranchScanJobSource reports "No jobs to run"
[04:49] <blr> added ipdb to source-deps, hope that's okay.
[05:28] <wgrant> blr: Hmm, that's mysterious.
[05:28] <wgrant> Did you get to the bottom of it?
[05:56] <blr> wgrant: no, I think the push must have failed actually, not certain if I have codehosting running correctly, getting "Parent directory of lp://dev/turnip/ does not exist."
[05:57] <wgrant> blr: Oh
[05:57] <blr> when running `bzr push -d devel lp://dev/turnip/` - using make-lp-user with my real lp id
[05:57] <wgrant> blr: Did you follow https://dev.launchpad.net/Code/HowToUseCodehostingLocally?
[05:57] <wgrant> I suspect you're connecting to OpenSSH :)
[05:57] <wgrant> You need a snippet in ~/.ssh/config to force it to port 5022, and possibly to a different hostname depending on exactly how things are set up.
[05:59] <blr> ah 5502, connection refused
[06:04] <blr> wgrant: hmm nmap'ing lpdev 5502 is not open, running with make run_codehosting however
[06:04] <wgrant> blr: 5022
[06:05] <blr> sorry, meant 5022, which is also not open
[06:09] <wgrant> blr: Ah, what's the mtime on /var/tmp/launchpad_forking_service.sock?
[06:12] <blr> wgrant: about 10m ago
[06:12] <wgrant> blr: Odd. From inside the container does 127.0.0.88:5022 appear to be open?
[06:13] <wgrant> Ah yeah, it only listens to that by default, I think.
[06:13] <wgrant> configs/development/launchpad-lazr.conf:port: tcp:5022:interface=127.0.0.88
[06:13] <blr> no, open: 22, 80, 443, 2121
[06:14] <wgrant> Any processes mentioning 'sftp' in ps?
[06:14] <blr> codehosting port/interface are correct in the config
[06:15] <blr> no sftp
[06:18] <blr> ah it is there in fact
[06:20] <blr> clearly I've done something terrible :)
[06:22] <wgrant> Is it listening on anything?
[06:22] <wgrant> What does netstat -lnp -A inet say?
[06:23] <blr> tcp        0      0 127.0.0.88:5022         0.0.0.0:*               LISTEN      32189/python2.7
[06:24] <blr> I can connect from inside the container
[06:25] <wgrant> Right, it's not visible from the outside by default, I suppose.
[06:25] <wgrant> You can tweak the config I mentioned above to 0.0.0.0, or just push from inside.
[06:48] <blr> excellent thanks wgrant - I'll make a note on the wiki.
[06:48] <wgrant> Sounds good.
[13:04] <cjwatson> wgrant: I have most of the LP side of repository deletion done now, but one remaining bit is dealing with deleting referencing GitRef rows.  I notice that for Branch/BranchRevision we do this by having BranchRevision.branch REFERENCES branch(id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED.  Do you think that makes sense for GitRef.repository too?  I'm assuming the deferrable bits are mainly for performance
[13:05] <cjwatson> The alternative of course would be to clean them up manually in Python
[13:06] <wgrant> cjwatson: I generally prefer it to be explicit, since it's a one-liner.
[13:07] <wgrant> It's arguably sensible to have it cascade at the DB level in this case, though.
[13:07] <cjwatson> I'm happy to implement it either way, just noticed that I couldn't find anything to clean up BR and went looking in the schema.
[13:08] <cjwatson> Doing it in Python saves me another DB patch ;-)
[13:08] <wgrant> Heh
[13:34] <cjwatson> OK, repository deletion basically done, I just shoved in self.refs.remove().  It'll need an FDT first so I won't rush to push it.
[13:34] <cjwatson> Oh, browser code I guess