[00:41] <blr> wgrant: can I render a value from services.config without setting the property on the view?
[00:42] <wgrant> blr: modules/lp.services.config/config in TALES will get you the current configuration.
[00:43] <blr> wgrant: ah excellent thanks
[02:36] <maozhou_> wgrant: do you kown how to delete a series on my test launchpad server?
[02:43] <maozhou_>  Is there anynone knows how to delete a series?
[02:49] <maozhou> oh,the network is bad
[02:53] <maozhou> is there anyone knows how to delete the series?
[03:10] <wgrant> maozhou: It's not possible to delete a distroseries without complex DB surgery.
[03:13] <maozhou> ok
[03:15] <maozhou> and how to delete a builder ? It's not possible to delete a builder  without modification of DB?
[03:19] <wgrant> no, builders can't be deleted, as they're referenced by builds that they have performed. when we decommission a builder, we unset "builder ok" and "publicly visible" to dispose of it.
[03:26] <maozhou> but sometimes the builder is not available, if we can't delete it, the list of builders will be more and more.
[03:40] <wgrant> maozhou: unchecking the "publicly visible" flag hides it from the list
[03:44] <maozhou> wgrant: that's a good idea
[03:54] <blr> wgrant: sorry, could you clarify what you mean by the view should have a _label_ of "configure code"
[03:55] <blr> did you mean a heading in the template? where your inline comment was placed it seemed like you were asking for an update to the docstring in the view class
[03:58] <blr> have added an h2 with context/name at any rate.
[04:01] <wgrant> blr: Ah, sorry, views have two special properties.
[04:01] <wgrant> page_title, and label.
[04:01] <blr> wgrant: added a .note class, does this look okay? http://i.imgur.com/J1N7L4g.png
[04:01] <blr> wgrant: ah I see, no need to have it in the template.
[04:02] <wgrant> blr: label appears as the h1 on the page, page_title in the breadrumbs in the head.
[04:02] <wgrant> Yep
[04:02] <wgrant> blr: That looks fine, yep.;
[04:30] <blr> wgrant: any thoughts on an appropriate name for the vcs inferring function if I push it into the model?
[04:31] <blr> inferred_vcs or default_vcs?
[04:35] <wgrant> blr: inferred_vcs makes sense to me.
[04:35] <blr> thanks
[04:35] <wgrant> blr: It won't be around for terribly long, I suspect, as we can fill in all existing rows once the UI to change it is in palce.
[04:36] <maozhou> I create a series which derives from "utopic", but I can't find arch of 386, why? like this : http://imgur.com/8wEriuZ
[04:38] <wgrant> maozhou: That architecture apparently doesn't exist in the previous series of that distribution.
[04:38] <wgrant> Only the first series in a distribution can copy from another distribution; subsequent series always copy from the previous series in the same distro.
[04:41] <maozhou> wgrant:It's the first series in a distribution, I have created a new distribution.
[04:43] <wgrant> maozhou: Are you sure that your version of utopic has i386?
[04:47] <maozhou> wgrant: Yes , I'm sure. like this: http://imgur.com/ytOFPQC
[04:50] <wgrant> maozhou: Is there an i386 checkbox on the new distribution's primary archive's admin page?
[04:53] <maozhou>  wgrant: what's the URL of the new distribution's primary archive's admin page??
[04:54] <wgrant> maozhou: Like https://launchpad.dev/ubuntu/+archive/primary/+admin, except not ubuntu
[05:00] <blr> wgrant: should productseries-setbranch.pt be in code/templates?
[05:00] <wgrant> blr: I'd say so. It's on a Registry object, but it's a totally Code-specific view.
[05:00] <wgrant> Registry is quite big enough :)
[05:01] <blr> wgrant: ok, I'll take this opportunity to move it - I just cargoculted product-setbranch from that, so figured that was where it should live!
[05:01] <wgrant> blr: By no means an unreasonable assumption.
[05:04] <maozhou> wgrant: I can't find the i386 checkbox .http://imgur.com/NVI7ePR
[05:05] <wgrant> maozhou: It would be immediately below the bottom of that image.
[05:05] <wgrant> A checkbox for each architecture, if you're running modern code.
[05:05] <wgrant> Or potentially none, if you're running old code.
[05:10] <maozhou> wgrant:http://i.imgur.com/OXU5S1s.png . I still can't it ,may be I'm running old code.
[05:10] <wgrant> maozhou: Right, in that case it's not relevant.
[05:10] <wgrant> maozhou: I think I may know what the problem is, though.
[05:11] <wgrant> If you're running a largely unmodified development config, your batch navigator settings will be configured to use very small batches.
[05:11] <wgrant> +initseries assumes that all of the architectures will be returned in a single batch.
[05:12] <wgrant> (because all production-like systems have a default batch size of 75, far higher than the number of architectures)
[05:13] <wgrant> Try increasing config.launchpad.default_batch_size to 75 or so, restarting the application, and refreshing the page.
[05:18] <maozhou> wgrant: what's the "batch size" mean?
[05:19] <wgrant> maozhou: When a request is made for a potentially large collections of objects, only a fixed number are returned at a time. eg. https://bugs.launchpad.net/ubuntu/ only shows the first 75 bugs.
[05:20] <wgrant> maozhou: In the development config, the number is 5, not 75.
[05:21] <maozhou> I understand
[05:26] <maozhou> wgrant: how to increasing config.launchpad.default_batch_size? need I modify DB or code?
[05:27] <wgrant> maozhou: launchpad-lazr.conmf
[05:27] <wgrant> -m
[05:28] <maozhou> ok
[05:34] <maozhou> wgrant: I have increased config.launchpad.default_batch_size to 75 ,after running "make run_all" , I still can't find arch of i386.
[05:37] <wgrant> maozhou: Perhaps that was not the problem after all. Does https://launchpad.dev/api/devel/ubuntu/utopic/architectures list i386?
[05:38] <maozhou> But，I can find arch of i386 if the series is  derives from other series， eg. 14.04 .....
[05:38] <wgrant> SELECT architecturetag, enabled FROM distroarchseries WHERE distroseries = (SELECT id FROM distroseries WHERE name = 'utopic' AND distribution = 1);
[05:43] <maozhou> wgrant: https://launchpad.dev/api/devel/ubuntu/utopic/architectures  doesn't list i386.
[05:43] <wgrant> I suspect, then, that someone has set the disabled flag on it.
[05:43] <wgrant> The SQL statement will confirm.
[05:43] <maozhou> ok
[05:49] <maozhou> wgrant: You are right , arch of i386 has been disabled by someone, I recovered it , then I find the arch of i386.  Thank you.
[05:49] <wgrant> Great.
[05:49] <wgrant> Disabling an architecture is meant to be permanent, so you may run into trouble. But it may be fine depending on when they did it.
[05:52] <maozhou> yes
[05:56] <maozhou> Only the first series in a distribution can copy from another distribution, Is it reasonable?
[06:01] <maozhou> If the first series is incomplete, we can't delete it, and the subsequent series can't copy from another distribution, that's in trouble
[06:06] <wgrant> Correct, you need to be careful and work out what you're going to do.
[06:06] <wgrant> Launchpad can only do so much automatically, due to file conflicts.
[06:07] <wgrant> Planning how a distro will operate before you start using it is absolutely essential.
[06:07] <wgrant> In some cases you may want to initialise it without any packages and copy the relevant packages in yourself.
[06:17] <maozhou> I understand.
[06:58] <maozhou> wgrant: If I have created new distribution and series. how to upload the chroot-xxx-.tar.bz2 to the series? I can only upload it to the series which belong to ubuntu.
[07:14] <wgrant> maozhou: manage-chroot defaults to Ubuntu, but you can tell it to use any distro.
[07:23] <maozhou> ok,thans
[07:23] <maozhou> thanks
[07:40] <maozhou> wgrant: I have created new distribution and series, and the series is initialized successful. But  I can't find the series which belong to the new distribution. And upload thd chroot-xxx.tar.bz2 is error. http://imgur.com/zc8ijjW   http://imgur.com/mAbPLux
[07:41] <wgrant> maozhou: You'll find the series if you click "All series". The distro page doesn't show series with status=Experimental by default; you probably want to set it to Development.
[07:41] <wgrant> The manage-chroot error is a permission problem.
[07:43] <wgrant> Specifically, you need to be either an admin or a member of the primary archive's owner team to manage its chroots.
[07:46] <maozhou> wgrant：but I can upload the chroot file to "ubuntu:utopic" successful  in the same way
[07:47] <wgrant> maozhou: The user you're logged in as is probably a member of the team that owns your Ubuntu's primary archive.
[07:50] <maozhou> wgrant: how to add current user to the team that owns my distribution‘s archive？
[07:52] <wgrant> maozhou: The primary archive will be owned by the distribution's original owner.
[07:52] <wgrant> That may, in this case, be the ~name16 user.
[07:55] <maozhou> wgrant： but the current user is ~name16 （admin@canonical.com）
[07:56] <wgrant> maozhou: What does https://launchpad.dev/api/devel/kylin2/+archive/primary say about the owner_link?
[08:11] <maozhou> wgrant : I'm sorry, there are something wrong with my notebook, it's panic just now , can you repeat it?
[08:12] <wgrant> 17:56:31   wgrant | maozhou: What does https://launchpad.dev/api/devel/kylin2/+archive/primary say about the owner_link?
[08:19] <maozhou> #wgrant:  http://imgur.com/p8y9tsa
[08:21] <wgrant> maozhou: Mysterious. Are you sure your API client is authenticated as ~name16?
[08:27] <maozhou> wgrant: the user who login launchpad.dev is ~name16, http://imgur.com/CPel393
[08:28] <wgrant> maozhou: But manage-chroot uses an OAuth token, not your browser cookie directly. It depends who you were logged in as when you first ran an API client against launchpad.dev.
[08:29] <wgrant> You can run seahorse and delete the launchpad.dev entry to force it to reauthenticate.
[08:29] <maozhou> but how to authenticate my API client as ~name16?
[08:30] <wgrant> If there's no token in gnome-keyring (which seahorse manages), running manage-chroot will prompt you to use your browser to authorise the client again.
[08:30] <wgrant> It will authenticate as ~name16 if you authorise it from a browser logged in as ~name16.
[08:33] <maozhou> what's seahorse?
[08:35] <wgrant> maozhou: seahorse is the graphical GNOME Keyring manager.
[08:37] <maozhou> i understand
[08:48] <maozhou> wgrant: which passwd should I delete? It is "Password for 'System-wide: Ubuntu (kylin)@https://api.launchpad.dev/' on 'launchpadlib'" ?
[08:51] <wgrant> maozhou: That's the one.
[08:53] <maozhou> ok
[08:54] <cjwatson> maozhou: You said name16's e-mail address was admin@canonical.com.  Please change that (or, better, create a new user to add to the same teams and deactivate name16); that's the address you spammed a couple of months ago, and you said yesterday you were going to change the sampledata addresses.
[08:55] <cjwatson> maozhou: If you change the existing user's address, please do it manually with SQL so that LP doesn't send an address change notification to the old address.
[08:59] <maozhou> cjwatson: I'm sorry about that, I will modify DB about the mail addresses now.
[09:00] <maozhou> cjwatson: Which email addresses  spammed you?
[09:14] <maozhou> cjwatson: I'm surprised about it , I haven't configured the email. The vaule of Mailer is stub in "devel/zcml/package-includes/mail-configure-normal.zcml"
[09:44] <cjwatson> maozhou: I don't know what was the source address, because I'm not behind admin@canonical.com; it was reported by one of our sysadmins.
[13:52] <cjwatson> blr: Fixed your code-in-swift nit; can I take your comment as an Approve vote?
[13:52] <cjwatson> (and thanks)
[16:07] <cjwatson> wgrant,blr: I've tested self-imports from LP git to LP bzr, and they work fine now, both https:// and (should anyone so desire) git://.
[16:07] <cjwatson> So definitely no firewall problems there.
[16:36]  * cjwatson creates https://code.launchpad.net/~cjwatson/launchpad/git-import-test to see what will happen
[16:41] <cjwatson> wgrant,blr: Oh dear, this plan may work for turnip but apparently not for Launchpad itself.  http://launchpadlibrarian.net/209437153/cjwatson-launchpad-git-import-test.log
[16:43] <cjwatson> Maybe code-import-worker could bump its recursion depth, but I have no idea what it would need to bump it to
[17:05] <cjwatson> blr: code-in-swift is just the first pass, BTW; I've been looking through some other deployments and the wsgi-app charm, and working out how I want this to look.  wsgi-app (although we can't use it directly because we have significant non-WSGI components) does something not a million miles away from what deployment-manager does, and I think we want the same kind of thing: [current_symlink, previous_symlink, build_label] config ...
[17:05] <cjwatson> ... entries, mojo spec looks at build_label and pushes a tarball for that rev into swift if it needs to, charm ensures that it has unpacked copies from swift of all the configured things and GCs old unused ones
[17:06] <cjwatson> To upgrade we juju set previous_symlink to current_symlink, build_label and current_symlink to the new rev, and mojo run --manifest manifest-upgrade
[17:07] <cjwatson> To rollback we mojo run --manifest manifest-rollback, which does juju set current_symlink=$previous_symlink
[17:07] <cjwatson> (and the rest)
[17:09] <cjwatson> And upgrades shouldn't have the scary thing of overwriting the running code in place any more
[17:10] <cjwatson> Anyway, I'm EOD and on leave tomorrow, so will pick this up on my back burner next week if I get time
[20:44] <blr> cjwatson: oh yes, of course :)
[20:45] <blr> cjwatson: that sounds like an excellent improvement
[20:52] <blr> hmm no comments on your issue yet wgrant, clearly you've put the fear in them.
[22:02] <blr> wgrant: hmm, does it make sense for ProductSeries to also have inferred_vcs? the context is of course now different in ProductSetBranchView
[22:03] <blr> I suspect I should just check for the existence of self.context.inferred_vcs in initial_values instead
[22:10] <blr> ah ForbiddenAttribute :|
[22:11] <blr> wgrant: how can I check for a property on a proxied object?
[22:26] <wgrant> cjwatson: The LP repo is packed with depth=200 IIRC. I'm tempted to fix dulwich to not recurse, though.
[22:27] <wgrant> blr: You need to add it to the interface (or configure.zcml manually, if that class names attributes directly rather than using its interfaces for security)
[22:30] <blr> wgrant: I think I want the latter, I'm not sure it makes sense for ProductSeries to have the property
[22:38] <wgrant> blr: Oh, I missed the first part of your question, sorry.
[22:39] <wgrant> blr: ProductSeries.vcs doesn't make sense, so you always want to find Product.inferred_vcs.
[22:39] <wgrant> blr: Consider always using self.context.pillar.inferred_vcs.
[22:39] <wgrant> .pillar is on a lot of Registry objects as a way to get to the Product or Distribution that contains the object.
[22:39] <wgrant> It even works on Product and Distribution themselves.
[22:40] <blr> ah wasn't aware of that, useful thanks
[23:12] <blr> wgrant: is it acceptable to call a private method from the view?
[23:13] <blr> (in this case Product._default_git_repository)
[23:15] <blr> well, a cachedprop.
[23:18] <wgrant> blr: Not usually. Why?
[23:18] <wgrant> If you want the default repo, I would define a property on the view that uses IGitRepositorySet
[23:19] <blr> wgrant: for the configure code link, which currently only checks for development_focus.branch
[23:21] <wgrant> blr: Ah, you misunderstood my recommendation.
[23:21] <blr> quite possibly!
[23:21] <wgrant> blr: The need for the check goes away if you fix it so the link isn't randomly different from the others.
[23:21] <wgrant> None of the others change based on whether a branch is set or not.
[23:21] <wgrant> s/a branch/the config/
[23:22] <wgrant> If we keep the check, it needs to be fixed to consider the Git case too.
[23:22] <wgrant> But I don't think we need to keep the check.
[23:22] <blr> wgrant: ah, so you're happy for it to just read 'configure code' in either case
[23:22] <blr> agreed, I don't think we're losing much by having a simple link
[23:23] <wgrant> We don't lose much, and we gain simplicity, performance and consistency.
[23:24] <blr> 'Configure code' and 'Configure code for this project' for text and summary work?
[23:27] <wgrant> Link summaries are silly, as they only appear as tooltips, but that works for consistency.
[23:31] <wgrant> cjwatson: I think your sampledata was out of date. Will testfix if you're not around.
[23:36] <wgrant> Have fixed the dulwich issue, trying an import locally now.
[23:38] <wgrant> Looks happy.