/srv/irclogs.ubuntu.com/2015/05/15/#launchpad-dev.txt

blrwgrant: 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:05
blrwgrant: cjwatson: does "Preferred VCS" work better than "Default VCS", only for user facing UI.00:20
wgrantblr: "Version control system", I think.00:25
wgrantPossibly with text near it that says the other repos will still be usable, but only if they exist.00:25
wgrantlifeless: 99% is almost exactly 1s.00:25
wgrantDon't know requests per day offhand.00:25
wgrantblr: It is technically only the preferred VCS, but "technically" arguments don't usually make for good UI :)00:31
lifelesswgrant: thanks; 1s seems slow :(00:31
lifelesswgrant: I don't suppose you remember what it was a couple years back00:32
wgrantlifeless: 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
wgrantlifeless: It was ~1.4 between 2012 and 2013.00:32
wgrantOnly with the new DB servers did it drop substantially below that.00:33
wgrants/dragged down/dragged up/00:34
lifelessI knew what you meant :P00:38
lifelessmade worse00:38
blrwgrant: yes have a note that you can still have bzr/git repos as well using the formHelp class00:47
blrlifeless: we're running on SSDs now which presumably have made a difference00:48
blrnot loving this markup, but it will have to do for now.00:55
blrwgrant: shall I merge the tabbed pull instructions into this branch?02:42
blrerr push02:42
wgrantblr: That possibly makes sense less on a form that has to show both sets of options anyway.02:46
blrwgrant: 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:22
blrdo I need to run a branch scan job?04:23
blr./cronscripts/process-job-source.py -v IBranchScanJobSource reports "No jobs to run"04:26
blradded ipdb to source-deps, hope that's okay.04:49
wgrantblr: Hmm, that's mysterious.05:28
wgrantDid you get to the bottom of it?05:28
blrwgrant: 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:56
wgrantblr: Oh05:57
blrwhen running `bzr push -d devel lp://dev/turnip/` - using make-lp-user with my real lp id05:57
wgrantblr: Did you follow https://dev.launchpad.net/Code/HowToUseCodehostingLocally?05:57
wgrantI suspect you're connecting to OpenSSH :)05:57
wgrantYou 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:57
blrah 5502, connection refused05:59
blrwgrant: hmm nmap'ing lpdev 5502 is not open, running with make run_codehosting however06:04
wgrantblr: 502206:04
blrsorry, meant 5022, which is also not open06:05
wgrantblr: Ah, what's the mtime on /var/tmp/launchpad_forking_service.sock?06:09
blrwgrant: about 10m ago06:12
wgrantblr: Odd. From inside the container does 127.0.0.88:5022 appear to be open?06:12
wgrantAh yeah, it only listens to that by default, I think.06:13
wgrantconfigs/development/launchpad-lazr.conf:port: tcp:5022:interface=127.0.0.8806:13
blrno, open: 22, 80, 443, 212106:13
wgrantAny processes mentioning 'sftp' in ps?06:14
blrcodehosting port/interface are correct in the config06:14
blrno sftp06:15
blrah it is there in fact06:18
blrclearly I've done something terrible :)06:20
wgrantIs it listening on anything?06:22
wgrantWhat does netstat -lnp -A inet say?06:22
blrtcp        0      0 127.0.0.88:5022         0.0.0.0:*               LISTEN      32189/python2.706:23
blrI can connect from inside the container06:24
wgrantRight, it's not visible from the outside by default, I suppose.06:25
wgrantYou can tweak the config I mentioned above to 0.0.0.0, or just push from inside.06:25
blrexcellent thanks wgrant - I'll make a note on the wiki.06:48
wgrantSounds good.06:48
cjwatsonwgrant: 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 performance13:04
cjwatsonThe alternative of course would be to clean them up manually in Python13:05
wgrantcjwatson: I generally prefer it to be explicit, since it's a one-liner.13:06
wgrantIt's arguably sensible to have it cascade at the DB level in this case, though.13:07
cjwatsonI'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:07
cjwatsonDoing it in Python saves me another DB patch ;-)13:08
wgrantHeh13:08
cjwatsonOK, 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
cjwatsonOh, browser code I guess13:34
=== jamesh_ is now known as jamesh

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!