[02:01] <blr> huh, `ag` can find zope templates with --plone
[02:07] <blr> wgrant: thank you for the review (imagine that took some time!)
[02:07] <wgrant> blr: Yup, mostly tiny things.
[02:10] <blr> wgrant: do we want the target ref to default to heads/master?
[02:10] <blr> context +register-merge ref picker
[02:11] <wgrant> blr: It should default to the target repo's HEAD ref, which is GitRepository.default_branch as of yesterday.
[02:12] <blr> ah cool, handy
[02:13] <wgrant> I'm not completely sure how it should all work at this stage. I think we eventually want a two-stage picker that selects a repo and then a ref within it.
[02:13] <blr> yep, would make sense to be within the same control
[02:13] <wgrant> We can't have the target ref input prepopulated with the default_branch, because the user could change the selected repo and invalidate the branch.
[02:14] <wgrant> So I think we for now have to go with a picker that asks for a vocab on the selected repo, but for the normal case accept that an empty ref input means a server-side fallback to default_branch.
[02:14] <blr> would be easy enough to reset it if the content of the target repository input changes
[02:14] <wgrant> Right, but reset to what? :)
[02:14] <wgrant> It'd have to be empty.
[02:14] <blr> well, it would have to be empty yes
[02:15] <blr> unless we could make an api call
[02:15] <wgrant> I think blank == HEAD makes sense in general.
[02:15] <wgrant> Like, if you clone a repo, you get HEAD.
[02:15] <wgrant> HEAD is a sensible thing for a null branch name to mean.
[02:15] <blr> ok, perhaps we just need to add a note in that case that HEAD is assumed unless otherwise specified
[02:15] <wgrant> I don't think it's worth improving on that until we can have the unified picker.
[02:15] <wgrant> Yep
[02:32] <mwhudson> wgrant, blr: just curious, have you thought at all about getting go get launchpad.net/foo to work if the foo project uses git?
[02:35] <blr> mwhudson: I'm afraid I'm not that familiar with golang, but that certainly sounds like a useful feature given our increasing use of the language...
[02:36] <mwhudson> yeah, there is support in the go tool for urls like that, but it assumes bzr
[02:36] <mwhudson> would be nice to fix it somehow
[02:36] <mwhudson> i'm not sure about all the intricacies of how go get works
[02:39] <blr> welp, apparently there's a carshare service in melbourne called GoGet. Thanks google.
[02:40] <mwhudson> i think one approach would be to put <meta> tags on the launchpad.net/project page
[02:40] <blr> presumably the go source is on github somewhere
[02:40] <mwhudson> (and delete the special casing for launchpad in the go tool)
[02:41] <mwhudson> blr: docs here https://golang.org/cmd/go/#hdr-Remote_import_paths
[02:41] <mwhudson> source is here https://github.com/golang/go/blob/master/src/cmd/go/discovery.go
[02:42] <mwhudson> (and get.go, vcs.go)
[02:42] <blr> mwhudson: thanks, will have a look this evening
[02:42] <blr> have been meaning to spend some time with golang at any rate.
[02:42] <mwhudson> blr: would it be useful to file a bug about this?
[02:42] <blr> mwhudson: absolutely yes, please tag it 'git'
[02:42] <mwhudson> if you do the lp bits, i'll do the go bits :-)
[02:45] <wgrant> Yep, that definitely makes sense.
[02:45] <wgrant> Inasmuch as go get itself does :)
[02:45] <mwhudson> https://bugs.launchpad.net/launchpad/+bug/1465467
[02:45] <mup> Bug #1465467: put <meta name="go-import"> tags on project, series pages <git> <Launchpad itself:New> <https://launchpad.net/bugs/1465467>
[02:45] <mwhudson> well yeah
[02:46] <mwhudson> i guess testing this against launchpad.dev will actually be easier than testing it against launchpad.net, unless you hack your own build tool
[02:46] <mwhudson> er
[02:46] <mwhudson> *go tool
[02:49] <blr> thanks mwhudson, at a glance it seems easy enough
[02:49] <mwhudson> blr: yeah, seems like it should be fairly easy
[02:50] <mwhudson> blr: go 1.5 will be released in august, would be nice to be able to get the relevant change into that
[02:51] <mwhudson> not completely sure i want to set up a launchpad dev environment just for this, but i guess i could...
[02:51] <blr> mwhudson: could you mock it locally somehow and point me at your golang fork on gh perhaps?
[02:54] <mwhudson> blr: sorry, i don't really understand
[02:54] <blr> mwhudson: I'm not certain you're going to be able to avoid setting up LP heh, although it is reasonably painless these days
[02:55] <mwhudson> blr: depends on whether i can con one of you guys into doing it first
[03:00] <blr> mwhudson: I can have a poke at it at codecraft this evening
[03:00] <mwhudson> blr: awesome
[03:00] <mwhudson> i've put it on my todo list
[03:00] <mwhudson> but not at the top :-)
[06:54] <maozhou_> Can someone help me? how to init series?
[06:55] <cjwatson> maozhou_: Um, what are you trying to do exactly?
[06:56] <cjwatson> Project series don't require initialisation, and initialising a distribution series on launchpad.net is something we'd expect to have had prior notice of.
[07:02] <maozhou_> i set up launchpad server on local, then i add a series.but when i init it ,it dosen't work
[07:04] <cjwatson> maozhou_: This is not even slightly easy to get going, but https://wiki.ubuntu.com/NewReleaseCycleProcess may provide some clues.
[07:09] <maozhou> cjwatson: i do it by this way.(https://dev.launchpad.net/LEP/DerivativeDistributions),but when i init it ,it dosen't work.
[07:11] <cjwatson> You'll probably need to run 'cronscripts/process-job-source.py IInitializeDistroSeriesJobSource'
[07:11] <cjwatson> But on a local instance you're mostly on your own, or at least will have to dig through log files yourself and generally provide more useful problem reports than "it doesn't work" :-)
[07:12] <cjwatson> I suspect derived distributions will be pretty complex to get going on a local instance, as you'd have had to import some other distribution to derive from.
[07:13] <cjwatson> You could in principle import Ubuntu using scripts/gina.py or something, but there'd be a lot of details for you to work out for yourself.
[07:24] <maozhou_> cjwatson: my workmate said that he once init the "DerivativeDistributions"  succeed by run some script, but he can't remember which script he run. may be i need try to run 'cronscripts/process-job-source.py IInitializeDistroSeriesJobSource'
[07:27] <maozhou_> cjwatson: thanks for your help, Let me try by your way.
[07:27] <wgrant> maozhou_: Oh, are you working on the kylinos.com.cn Launchpad instance that was spamming people a few months back?
[07:30] <cjwatson> ... and have you deleted sampledata yet? :-)
[07:33] <maozhou_> wgrant: yes, may be. I am sorry about that. but how to stop it spamming people?
[07:36] <wgrant> maozhou_: As far as we could tell, you took a normal Launchpad development instance, including all the development sample data, enabled outbound email, and started using it. The sample data includes some real email addresses, and is generally a terrible basis for a production deployment.
[07:36] <wgrant> I don't know what your goal for your Launchpad instance is, but starting with sampledata is almost certainly the wrong way to go.
[07:38] <cjwatson> Also may well have security holes of various kinds since the sample data includes people with e-mail addresses you don't control in privileged teams.
[07:41] <cjwatson> The development sample data is meant to make it easier to experiment with changes to Launchpad itself locally, by giving you a bit of test data so that important pages will render something at least a little bit useful.  But it should never be included in production deployments.
[07:42] <cjwatson> I don't know if there's a sensible way to excise it from an already-running instance; it would probably involve non-trivial database surgery, and might well be easier to start again from scratch.
[07:54] <maozhou_> ok, i will tell my workmate to check it . may be we need to modification datebase.
[07:59] <maozhou> if i alter datebase about mailaddress,is it effectivity?
[08:04] <cjwatson> You really ought to delete the predefined non-team accounts, and there will be various other junk in e.g. your list of registered projects, your bug/branch/specification tables, etc. that you probably want to get rid of.
[08:07] <wgrant> A fresh bootstrapped database would be a much better idea.
[08:14] <maozhou_> there are many data already in datebase ,if do a fresh bootstrapped database, all the data will be losed , may be we can't do that.
[08:26] <maozhou_> we will check it to stop it spamming people.
[09:14] <maozhou_> cjwatson:when i run  'cronscripts/process-job-source.py IInitializeDistroSeriesJobSource' , it's error . the error log is “Running <InitializeDistroSeriesJob for distribution: kylin, distroseries: dota, parent[overlay?/pockets/components]: utopic[False/Release/main], architectures: (), archindep_archtag: None, packagesets: None, rebuild: True> (ID 2) in status Waiting”
[09:14] <maozhou_> Job resulted in OOPS: OOPS-ea5bde41e13487cb6437263a6b26b44d
[09:14] <maozhou_>  1 InitializeDistroSeriesJob jobs did not complete.
[09:15] <maozhou_> what is “OOPS: OOPS-ea5bde41e13487cb6437263a6b26b44d” ？
[09:15] <cjwatson> You'll need to find the actual text of that OOPS.
[09:15] <cjwatson> It should have been dumped out somewhere, but exactly where depends on your configuration.
[09:16] <cjwatson> The error_reports lazr config section should have an error_dir key, which might be a place to start.
[09:17] <maozhou_> ok，i know .thank you.
[14:33] <cjwatson> wgrant: Would you mind having another quick look over https://code.launchpad.net/~cjwatson/launchpad/git-repository-ui-edit-target/+merge/261232 ?  I know you already gave an Approve vote, but I made some fairly extensive changes to cope with the changes related to target_default.
[20:55] <blr> morning
[21:38] <blr> hmm would be nice to have the option to delete a comment within x minutes of creation for people that haven't had enough coffee.
[21:56] <mwhudson> i think there is a bug with a very small number about that :-)
[21:57] <blr> mwhudson: made a start on your request last night, have the import meta rendering on Product+index, will try to sort out the bzr meta and ProductSeries tag before eow
[21:57] <mwhudson> blr: i just noticed, cool :-)
[21:58] <mwhudson> i'll get set up to be able to test it
[21:58] <mwhudson> is launchpad still running on precise?
[21:59] <blr> mwhudson: yep
[22:00] <mwhudson> okidoke
[23:09] <blr> mwhudson: have another branch (which allows a project to have an associated 'default' vcs, amoungst other things) which needs to land before this branch. Not far away however
[23:09] <blr> will govern whether a bzr or git meta tag is rendered
[23:20] <mwhudson> blr: ah yes, that seems relevant :-)