[00:41] wgrant: can I render a value from services.config without setting the property on the view? [00:42] blr: modules/lp.services.config/config in TALES will get you the current configuration. [00:43] wgrant: ah excellent thanks [02:36] wgrant: do you kown how to delete a series on my test launchpad server? [02:43] Is there anynone knows how to delete a series? [02:49] oh,the network is bad [02:53] is there anyone knows how to delete the series? [03:10] maozhou: It's not possible to delete a distroseries without complex DB surgery. [03:13] ok [03:15] and how to delete a builder ? It's not possible to delete a builder without modification of DB? [03:19] 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] but sometimes the builder is not available, if we can't delete it, the list of builders will be more and more. [03:40] maozhou: unchecking the "publicly visible" flag hides it from the list [03:44] wgrant: that's a good idea [03:54] wgrant: sorry, could you clarify what you mean by the view should have a _label_ of "configure code" [03:55] 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] have added an h2 with context/name at any rate. [04:01] blr: Ah, sorry, views have two special properties. [04:01] page_title, and label. [04:01] wgrant: added a .note class, does this look okay? http://i.imgur.com/J1N7L4g.png [04:01] wgrant: ah I see, no need to have it in the template. [04:02] blr: label appears as the h1 on the page, page_title in the breadrumbs in the head. [04:02] Yep [04:02] blr: That looks fine, yep.; [04:30] wgrant: any thoughts on an appropriate name for the vcs inferring function if I push it into the model? [04:31] inferred_vcs or default_vcs? [04:35] blr: inferred_vcs makes sense to me. [04:35] thanks [04:35] 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] 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] maozhou: That architecture apparently doesn't exist in the previous series of that distribution. [04:38] 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] wgrant:It's the first series in a distribution, I have created a new distribution. [04:43] maozhou: Are you sure that your version of utopic has i386? [04:47] wgrant: Yes , I'm sure. like this: http://imgur.com/ytOFPQC [04:50] maozhou: Is there an i386 checkbox on the new distribution's primary archive's admin page? [04:53] wgrant: what's the URL of the new distribution's primary archive's admin page?? [04:54] maozhou: Like https://launchpad.dev/ubuntu/+archive/primary/+admin, except not ubuntu [05:00] wgrant: should productseries-setbranch.pt be in code/templates? [05:00] blr: I'd say so. It's on a Registry object, but it's a totally Code-specific view. [05:00] Registry is quite big enough :) [05:01] 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] blr: By no means an unreasonable assumption. [05:04] wgrant: I can't find the i386 checkbox .http://imgur.com/NVI7ePR [05:05] maozhou: It would be immediately below the bottom of that image. [05:05] A checkbox for each architecture, if you're running modern code. [05:05] Or potentially none, if you're running old code. [05:10] wgrant:http://i.imgur.com/OXU5S1s.png . I still can't it ,may be I'm running old code. [05:10] maozhou: Right, in that case it's not relevant. [05:10] maozhou: I think I may know what the problem is, though. [05:11] If you're running a largely unmodified development config, your batch navigator settings will be configured to use very small batches. [05:11] +initseries assumes that all of the architectures will be returned in a single batch. [05:12] (because all production-like systems have a default batch size of 75, far higher than the number of architectures) [05:13] Try increasing config.launchpad.default_batch_size to 75 or so, restarting the application, and refreshing the page. [05:18] wgrant: what's the "batch size" mean? [05:19] 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] maozhou: In the development config, the number is 5, not 75. [05:21] I understand [05:26] wgrant: how to increasing config.launchpad.default_batch_size? need I modify DB or code? [05:27] maozhou: launchpad-lazr.conmf [05:27] -m [05:28] ok [05:34] 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] maozhou: Perhaps that was not the problem after all. Does https://launchpad.dev/api/devel/ubuntu/utopic/architectures list i386? [05:38] But，I can find arch of i386 if the series is derives from other series， eg. 14.04 ..... [05:38] SELECT architecturetag, enabled FROM distroarchseries WHERE distroseries = (SELECT id FROM distroseries WHERE name = 'utopic' AND distribution = 1); [05:43] wgrant: https://launchpad.dev/api/devel/ubuntu/utopic/architectures doesn't list i386. [05:43] I suspect, then, that someone has set the disabled flag on it. [05:43] The SQL statement will confirm. [05:43] ok [05:49] 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] Great. [05:49] 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] yes [05:56] Only the first series in a distribution can copy from another distribution, Is it reasonable? [06:01] 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] Correct, you need to be careful and work out what you're going to do. [06:06] Launchpad can only do so much automatically, due to file conflicts. [06:07] Planning how a distro will operate before you start using it is absolutely essential. [06:07] In some cases you may want to initialise it without any packages and copy the relevant packages in yourself. [06:17] I understand. [06:58] 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. === frankban_ is now known as frankban [07:14] maozhou: manage-chroot defaults to Ubuntu, but you can tell it to use any distro. [07:23] ok,thans [07:23] thanks [07:40] 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] 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] The manage-chroot error is a permission problem. [07:43] Specifically, you need to be either an admin or a member of the primary archive's owner team to manage its chroots. [07:46] wgrant：but I can upload the chroot file to "ubuntu:utopic" successful in the same way [07:47] maozhou: The user you're logged in as is probably a member of the team that owns your Ubuntu's primary archive. [07:50] wgrant: how to add current user to the team that owns my distribution‘s archive？ [07:52] maozhou: The primary archive will be owned by the distribution's original owner. [07:52] That may, in this case, be the ~name16 user. [07:55] wgrant： but the current user is ~name16 （admin@canonical.com） [07:56] maozhou: What does https://launchpad.dev/api/devel/kylin2/+archive/primary say about the owner_link? [08:11] wgrant : I'm sorry, there are something wrong with my notebook, it's panic just now , can you repeat it? [08:12] 17:56:31 wgrant | maozhou: What does https://launchpad.dev/api/devel/kylin2/+archive/primary say about the owner_link? [08:19] #wgrant: http://imgur.com/p8y9tsa [08:21] maozhou: Mysterious. Are you sure your API client is authenticated as ~name16? [08:27] wgrant: the user who login launchpad.dev is ~name16, http://imgur.com/CPel393 [08:28] 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] You can run seahorse and delete the launchpad.dev entry to force it to reauthenticate. [08:29] but how to authenticate my API client as ~name16? [08:30] 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] It will authenticate as ~name16 if you authorise it from a browser logged in as ~name16. [08:33] what's seahorse? [08:35] maozhou: seahorse is the graphical GNOME Keyring manager. [08:37] i understand [08:48] wgrant: which passwd should I delete? It is "Password for 'System-wide: Ubuntu (kylin)@https://api.launchpad.dev/' on 'launchpadlib'" ? [08:51] maozhou: That's the one. [08:53] ok [08:54] 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] 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] cjwatson: I'm sorry about that, I will modify DB about the mail addresses now. [09:00] cjwatson: Which email addresses spammed you? [09:14] 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] 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. === anthonyf is now known as Guest73520 [13:52] blr: Fixed your code-in-swift nit; can I take your comment as an Approve vote? [13:52] (and thanks) === mgz_ is now known as mgz === Spads is now known as M-SpaceHobo === M-SpaceHobo is now known as Spads [16:07] 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] 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] 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] Maybe code-import-worker could bump its recursion depth, but I have no idea what it would need to bump it to [17:05] 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] ... 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] 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] To rollback we mojo run --manifest manifest-rollback, which does juju set current_symlink=$previous_symlink [17:07] (and the rest) [17:09] And upgrades shouldn't have the scary thing of overwriting the running code in place any more [17:10] 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] cjwatson: oh yes, of course :) [20:45] cjwatson: that sounds like an excellent improvement [20:52] hmm no comments on your issue yet wgrant, clearly you've put the fear in them. [22:02] wgrant: hmm, does it make sense for ProductSeries to also have inferred_vcs? the context is of course now different in ProductSetBranchView [22:03] I suspect I should just check for the existence of self.context.inferred_vcs in initial_values instead [22:10] ah ForbiddenAttribute :| [22:11] wgrant: how can I check for a property on a proxied object? [22:26] cjwatson: The LP repo is packed with depth=200 IIRC. I'm tempted to fix dulwich to not recurse, though. [22:27] 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] wgrant: I think I want the latter, I'm not sure it makes sense for ProductSeries to have the property [22:38] blr: Oh, I missed the first part of your question, sorry. [22:39] blr: ProductSeries.vcs doesn't make sense, so you always want to find Product.inferred_vcs. [22:39] blr: Consider always using self.context.pillar.inferred_vcs. [22:39] .pillar is on a lot of Registry objects as a way to get to the Product or Distribution that contains the object. [22:39] It even works on Product and Distribution themselves. [22:40] ah wasn't aware of that, useful thanks [23:12] wgrant: is it acceptable to call a private method from the view? [23:13] (in this case Product._default_git_repository) [23:15] well, a cachedprop. [23:18] blr: Not usually. Why? [23:18] If you want the default repo, I would define a property on the view that uses IGitRepositorySet [23:19] wgrant: for the configure code link, which currently only checks for development_focus.branch [23:21] blr: Ah, you misunderstood my recommendation. [23:21] quite possibly! [23:21] blr: The need for the check goes away if you fix it so the link isn't randomly different from the others. [23:21] None of the others change based on whether a branch is set or not. [23:21] s/a branch/the config/ [23:22] If we keep the check, it needs to be fixed to consider the Git case too. [23:22] But I don't think we need to keep the check. [23:22] wgrant: ah, so you're happy for it to just read 'configure code' in either case [23:22] agreed, I don't think we're losing much by having a simple link [23:23] We don't lose much, and we gain simplicity, performance and consistency. [23:24] 'Configure code' and 'Configure code for this project' for text and summary work? [23:27] Link summaries are silly, as they only appear as tooltips, but that works for consistency. [23:31] cjwatson: I think your sampledata was out of date. Will testfix if you're not around. [23:36] Have fixed the dulwich issue, trying an import locally now. [23:38] Looks happy.