[00:00] I just uploaded and downloaded an attachment named 'huh?' [00:00] wgrant, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/983116/+attachment/3077581/+files/HUD-to-do-what%3F-de.png [00:00] <_mup_> Bug #983116: [Component: Keyboard] HUD is not < https://launchpad.net/bugs/983116 > [00:00] Yeah, prod strips them [00:00] Compare the exception on https://launchpad.net/huh%3F and https://launchpad.dev/huh%3F [00:01] https://dogfood.launchpad.net/huh%3F shows the correct behaviour [00:01] qastaging is bad [00:01] So something on the prod/qas frontend configs is molesting our URLs; there's no LP bug here. [00:01] yes, jcsackett confirmed that qa and prodct beahve the same [00:02] So I would suggest replacing that MP with an RT [00:02] Who knows what else the frontends are doing :/ [00:02] and watch it for 5 years? [00:03] Nah, I'll coerce APAC webops to give me the configs next week and then give them a diff :) [00:03] Diffs are a good way to accelerate RTs [00:03] I am glad it is reproducible on qastaging; that makes things much easier. [00:04] Since there's no squid or haproxy, AIUI [00:05] steven@undermined:~% wget -Sq https://qastaging.launchpad.net 2>&1 | grep X-Cache [00:05] X-Cache: HIT from arsenic.canonical.com [00:05] Oh [00:05] So *that's* what arsenic does... [00:05] s/Oh/Oh god why/ [00:06] * wgrant files the RT [00:06] arsenic for staging too [00:07] We may need to do the same tweak we did to get the restricted librarian working [00:08] # nocanon per RT#42560, woe with LP's handling of eg %2B [00:08] ProxyPass / balancer://launchpad-librarian-cluster/ nocanon [00:08] <_mup_> Bug #42560: /var is mounted over /var/run and /var/lock < https://launchpad.net/bugs/42560 > [00:08] That shouldn't be it, since decoding the %3F is not a legal part of canonicalization, but it's possible. [00:09] Whatever it is, either apache or squid is in the wrong here, not LP [00:12] It looks like it's probably our squid config, but I don't think I have a copy. [01:05] * StevenK glares at DF [01:06] With no builder how am I supposed to QA? :-( === matsubara is now known as matsubara-afk [01:25] StevenK: DB hacking or qa-meh [01:25] Yeah, qa-meh might be the way [01:50] wgrant: I wonder if bug 834293 is fixed, we did a bunch of work on branch privacy [01:50] <_mup_> Bug #834293: Product:+code-index times out < https://launchpad.net/bugs/834293 > === jtv1 is now known as jtv [02:07] StevenK: No [02:07] We made it better, but not much better [02:07] * wgrant finds data [02:08] https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-monthly-pageids.html [02:08] 99% under 7.26s [02:11] * StevenK made the mistake of searching OOPS on neem with 'AssertionError' [02:12] 1648 OOPSes later ... [02:13] Almost all of them appear to be AssertionError: Bug #504291: Store left in a disconnected state. [02:13] StevenK: Why? [02:13] <_mup_> Bug #504291: DisconnectionErrors (already disconnected) happening again < https://launchpad.net/bugs/504291 > [02:13] We know the precise circumstances around +edit-dependencies [02:13] So we don't need to grep for it [02:13] I wasn't [02:13] That grep was for bug 808950 [02:13] <_mup_> Bug #808950: AssertionError: You exported name as an IChoice based on an SQLObjectVocabularyBase, you should use lazr.restful.fields.ReferenceChoice instead < https://launchpad.net/bugs/808950 > [02:14] Ah [02:15] But doesn't seem to show up [02:23] StevenK: Have you tried to reproduce it? [02:25] I was looking for an OOPS as the first step. [02:26] "AssertionError: You exported milestone_assignment as an IChoice based on an SQLObjectVocabularyBase, you should use lazr.restful.fields.ReferenceChoice instead." on Product:EntryResource:searchTasks [02:26] is pretty clear [02:26] And the fix is obvious [02:28] (hint: grep the entire tree for the field name) [02:31] # The vocabulary should be HWBus; this is fixed in [02:31] # _schema_circular_imports to avoid circular imports. [02:31] Didn't you kill that? [02:31] _schema_circular_imports continues to live [02:31] Its death will come only from lazr.restful's demise, or being split up into app-specific _schema_circular_importses. [02:32] wgrant: Hmm, I don't get it. Since bugtasksearch has assignee as a Choice [02:32] StevenK: Look at the other places that use it, and it should become clear [02:33] Hah. Assignee is a Reference [02:33] In bugtarget [02:33] That's fine. [02:33] But milestone_assignment isn't [02:33] We only care about milestone_assignment, don't we? [02:33] We shouldn't use copy_field, but use Reference? [02:34] I'd look at how the other code that goes near that field uses it. [02:35] wgrant: What other code? milestone_assignment turns up in two places. [02:35] You're on the right track. [02:36] That wasn't the answer I was expecting. :-) [02:37] wgrant: Oh, it isn't used at all./ [02:38] search params never assigns it in __init__ [02:38] Bingo [02:39] Should I drop it entirely then? [02:39] It's obviously exported, but use of it will return 500s [02:39] Right, it's probably in 1.0, but it's also likely that any attempt to use it crashes [02:39] Check that, and if it always crashes then obliterate it [02:39] If it doesn't always crash, think about it a big and then obliterate it anyway. [02:40] bit [02:41] Hah [02:41] So it wants a milestone name ? [02:41] I think it wants a milestone reference. [02:41] Given that it's using the Milestone vocab [02:42] But it's exported as a Choice, which means it wants an enum value [02:42] Which is why it crashes [02:42] Try giving it references and names and see if there's anything that doesn't OOPS [02:44] OOPS-a8ab241f5057264be5073a00263b04fb and OOPS-2c4ba13f50161b4d3ae38ccb94059308 [02:49] Ah... ha... [02:49] The archeology of this is interesting [02:49] It actually dates back to batch edit functionality added in mid-2005. [02:50] In r1860 [02:50] If milestone_assignment was set in search parameters, it looks like it set the milestone of the found bug tasks. [02:51] HAHAHA [02:51] It's only referenced in a doctest that has been disabled since 2005 [02:51] Ah, no, there was a separate batch assignment form on the search page, but it all used that same "search" schema [02:51] # XXX Bjorn Tillenius 2005-08-01: [02:51] # This test is disabled in wait for SQLObject being fixed to accept [02:51] # both distinct=True and an orderBy argument. [02:52] xx-bugattachments.txt is disabled? [02:52] No, just the last test of it [02:52] Ah [02:52] XXX print http(r""" [02:52] ... GET /bugs/fir... [02:53] wgrant: What about name in that bug? Or is that long dead? [02:54] StevenK: It may still exist, but the pageid is bad [02:54] Perhaps search the apidoc for parameters named name [02:54] 'cause the method mentioned in the bug doesn't have onje [02:54] And I don't think it ever did [02:55] Huh [02:55] That code persisted until June 2006 [02:55] But I'm pretty sure the bulk edit form was long gone by then, or I'd remember. [02:57] * StevenK ignores name [04:02] wallyworld__: Read https://code.launchpad.net/~stevenk/launchpad/obliterate-milestone_assignment/+merge/128158 and weep [04:06] * wallyworld__ reads [04:08] there were some cobwebs there [04:08] I think the cobwebs are covered in dust [04:09] Maybe this branch will land now [04:13] wallyworld__: Did you want to approve that MP, or are you afraid of the spiders that own said cobwebs? === gary_poster is now known as gary_poster|away [04:15] StevenK: i'll aprove it, i just thought you wanted me to read it [04:16] wallyworld__: The reading was first, yeah [04:16] wallyworld__: I was curious about your reaction before you reviewed it [04:16] StevenK: so, you saying that if the api is used now, as it, it oopses? [04:16] as is [04:17] wallyworld__: searchTasks() works fine. If you pass in milestone_assignment as one of your arguments, you will get an OOPS. [04:17] ok, so no harm in removing it then [04:17] Right, and I doubt any one is using it [04:17] If they are, they move from a 500 to what, 404 or a lazr.restful error? [04:18] you may have won the prize for removing the oldest code [04:18] 40x for sure, not sure what [04:18] 400 [04:19] Well, actually, once the WADL updates launchpadlib will probably tell them they're wrong before even sending the request [04:19] But still, if they were relying on getting a 500 from that then they're pretty strange :) [04:20] Let's find out in about an hour [04:20] Hm? [04:20] Why an hour? [04:20] buildbot and qas updating [04:21] Ah [04:21] Current run has 15 minutes to go [04:21] Unless wallyworld__ breaks it again [04:21] it was only once :-( [04:21] Twice [04:22] once [04:22] the other was suprious [04:22] Once this morning and the feature flag related changes a few days ago [04:22] same old thing we'vebeen seeing lately [04:22] i thought you meant today [04:37] Why did we add rf-setup-certs to LP? [04:37] curtis said to [04:37] I thought it was supposed to go into lp-dev-utils ? [04:37] oops, maybe, let me check [04:37] StevenK: the email said utilities [04:38] Hmmm [04:38] i can move it [04:38] wgrant: What do you think? [04:39] I think it should move [04:40] wgrant: StevenK: +expirable-bugs oops on a dsp. i can't see a link so it must have been via url hacking. i guess it should return a 404 instead of a 500? or did we want to implement expirable bugs on a dsp? [04:40] wallyworld__: So the ZCML has +expirable-bugs on IBugTarget [04:41] A DSP is a bug target, but it doesn't support it [04:41] ah. but there's no link on the dsp bugs page [04:41] Curtis and William are of the opinion that it should support it [04:41] ok, will look at that, thanks [04:41] and then we can add the link to the page [04:43] wallyworld__: I'm not really of the opinion that it should support it [04:43] wgrant: Do you think Colin's work is far enough long to close bug 556839? [04:43] I'm of the opinion that it might be easier to fix it to support it than it is to remove the page [04:43] Given it's registered for IBugTarget [04:43] StevenK: No [04:43] We don't use async by default? [04:43] wallyworld__: I'd put the cert gen script in lp-dev-utils, I think [04:43] As StevenK suggests [04:44] wgrant: why wouldn't we want to find expirable bugs on a dsp? [04:44] wallyworld__: 'cause even Distribution:+expirable-bugs had only 136 hits last month [04:45] Hah [04:45] And how many of those were Google? [04:45] hmmm. [04:45] Most were probably search engines, yeah [04:45] maybe we want to redo the zcml then to stop lying? [04:45] +expirable-bugs was mostly introduced to show what would happen when expiration was turned on [04:46] wallyworld__: Right, it's possibly best to just register it on IProduct and IDistribution [04:46] Not sure if IProductSeries or IDistroSeries or IProject have it linked [04:46] ok, i'll check that out. i think that's the better solution [04:47] rather than doing something no one will use [04:47] IProductSeries and IDistroSeries have about as many hits as I'd expect from Google [04:47] But it's difficult to say [04:47] wallyworld__: Right [04:47] * wallyworld__ first gets out the hedge trimmer [04:47] In some situations like this it's a one-liner to fix it, so it's easier to just make it work [04:48] But this is not one of them [04:48] yeah, dicking eith _getTargetJoinAndClause() for dsp would be messy [04:49] wgrant: So, for bug 1050191, I agree with Curtis. If it was in +junk first, we don't care. [04:49] <_mup_> Bug #1050191: allocate-revision-karma.py is too slow to complete < https://launchpad.net/bugs/1050191 > [04:49] StevenK: It's on my chopping block for the next few days [04:49] As it's directly implicated in the BranchRevision drama [04:49] Right [04:49] I'll leave it alone then [04:49] Fixing it is probably a prereq, but in which way I'm not sure [04:49] Right :) [04:50] Is mawson back to crying about your queries? [04:50] No [04:50] I have the data I need for now [04:50] You can molest mawson if you so desire [04:51] I have no need to, I was curious. [04:51] Oh right, you qa-meh'd the PCJ thing [04:51] I did, yes. [04:51] Bug 1031751 is interesting. I've seen a test fail in that way too [04:51] <_mup_> Bug #1031751: KeyError: 'primary_vars' raised setting branch for a project < https://launchpad.net/bugs/1031751 > [04:52] Right, some of Orange's work triggered that a week or so ago [04:52] An unrelated cause, but similar exception [04:52] Yeah. I'm not sure about the cause for the bug [04:54] Almost at 45 revisions needing deployment [04:54] StevenK: I suspect a branch was being created with a private team as the registrant [04:55] StevenK: Perhaps registering a codeimport [04:55] But the OOPS is gone and the traceback severely truncated [04:55] Care you try what I suggested on qastaging? [04:55] +new-import with a private team? [04:56] That shouldn't set the registrant to the primary team, but it might [04:56] So it's worth a try [04:57] PrivatePersonLinkageError: Cannot link person (name=rhinos, visibility=PRIVATE) to (name=None)
[04:59] Indeed [04:59] I can't see an obvious way to set the registrant to a private team [04:59] And you can't log in as a team any more, so that won't work... [05:00] Oh, hmmm [05:02] That OOPS would make it obvious :( [05:23] .oOo. [06:01] StevenK: Ah, it would have helped if I'd read the summary [06:02] OOPS-07a7ee485f0ae949f3e103cc1db1c082 [06:04] Nice. [06:04] What was the cause, then? [06:10] Hmmmm, I think I get it. Creating an import for a series owned by a private team [06:11] is sso glitching [06:11] I'm having trouble logging into oops.c.c [06:12] lifeless: It's working for me [06:13] I'm getting The connection was reset [06:13] on [06:13] https://oops.canonical.com/openid/+return?janrain_nonce= ... [06:13] StevenK: code_import = getUtility(ICodeImportSet).new( [06:13] registrant=branch_owner, [06:13] From ProductSeriesSetBranchView.update_action [06:15] wgrant: So we should croak in validate if branch_owner is private? [06:16] StevenK: No [06:16] You should specify the registrant [06:16] Oh, registrant=self.user ? [06:17] Yeah [06:17] wgrant: But I thought the form was asking who should own the branch? [06:17] So isn't that ignoring them ... [06:17] own != register [06:17] So owner != registrant [06:18] I think you'll find that all the other branch creation callsites use the user as the registrant, with the provided owner as the owner. [06:18] That's certainly the intent. [06:19] I suspect that Registry got confused when producing this view [06:19] Right [06:19] Ugh, all of the tests for it are in doctests [06:31] I chose SHA-512 because everyone knows it's 512 times more secure than SHA-1. [06:31] — Rusty Russell [06:31] :) [06:35] obj_info["primary_vars"]) [06:35] KeyError: 'primary_vars' [06:35] Fantastic [06:36] In a test? [06:36] I wouldn't have a test for this issue directly. [06:36] Rather amend an existing test to check that the registrant is the user, not the owner [06:37] Making the branch approximately -1/+2 [06:39] But I just wrote one :-( === lifeless_ is now known as lifeless [06:48] StevenK: It may be useful for checking that the issue is really gone, but it's not something that's worth the test suite time and LoC to keep forever [06:56] Raaaargh [06:56] This entire test uses the product.owner as the registrant as well as the logged in the user [06:57] Change one of them to be the other, I guess [06:57] Changing the whole test to make a driver and set them as the owner of the series has lots of ('Invalid value', InvalidValue("token u'person-name-100001' not found in vocabulary")) [06:57] StevenK: Ensure that the user is a member of the team [06:57] What team [06:57] ? [06:58] You can only create a branch owned by yourself or a team in which you participate [06:58] So the owner has to be a superteam of the user [07:04] Right, large diff [07:20] wgrant: Did you want to review? [07:20] Sure [07:21] wgrant: https://code.launchpad.net/~stevenk/launchpad/no-private-registrant-setbranch/+merge/128173 [07:26] StevenK: Do you use ROT26 from time to time? [07:27] ROT26 is the alphabet? [07:43] good morning === spm` is now known as spm_ === spm_ is now known as spm === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: ~300 [10:50] morning [10:54] rick_h_: hey there [10:54] you're on early [10:55] czajkowski: trying to get back on time [10:56] rick_h_: can you pop into #lp please if you're free? [11:00] adeuring: ping, can you help czajkowski debug a blueprint issue? https://oops.canonical.com/?oopsid=OOPS-51c8161b2e479d7ed62ba67c1000bd19 [11:00] * adeuring is looking [11:01] adeuring: looks like a user hit a forbidden setting it to embargoed or something. [11:01] 383264 [11:04] adeuring: ? typo'd bug number or something? [11:06] rick_h_: PEBCAK: I tend to forget to click into a wondow before typing something. I this I wanted to add a 2-fact auth number into a browser window, while irc IRC window still had the focus... [11:06] adeuring: ah gotcha cool [11:07] thanks for looking at the oops [11:41] rick_h_: https://bugs.launchpad.net/launchpad/+bug/1062207/comments/1 [11:41] <_mup_> Bug #1062207: Unable to raise blueprint < https://launchpad.net/bugs/1062207 > === gary_poster|away is now known as gary_poster [13:22] abentley: I missed you yesterday about setting the field value = PUBLIC [13:22] abentley: that was my doing when I setup the UI because I needed to set a value to the form field so that choicepicker stuff would pick it up [13:22] now that the field exists, model sets, etc it can probably just go away [13:22] adeuring, thanks for the review. Agree on both counts. We can hold the individual adapters until after alpha though, I think. [13:23] deryck: right [13:23] rick_h_: I've removed it, and there seem to be no ill effects. [13:23] abentley: right [13:23] and the IProductSet checks were because there were tests that hit that View that weren't of that interface and weren't getting information_type added onto it [13:24] abentley: I had talked to deryck about that one when I thit it [13:24] rick_h_: Strange. We don't seem to have any tests like that now. [13:25] abentley: it was something I hit. I had a chat with deryck about it asking if there was a better way than the interface checks [13:26] abentley: ProjectGroup perhaps gets hit in there? [13:26] rick_h_: I don't understand. [13:28] abentley: I'll bring it up on the call in a sec === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugs: ~300 === matsubara-afk is now known as matsubara [14:06] After 3 years, I think I'm starting to understand buildbot's waterfall display. [14:13] abentley: lol [14:14] jelmer: It's funny 'cause it's true. === benji___ is now known as benji [14:39] * deryck switches work locations, back online shortly [15:10] adeuring, bac, abentley: do either of you have time to review https://code.launchpad.net/~sinzui/launchpad/contact-new-maintainer/+merge/128273 [15:10] sinzui: i'll look [15:24] sinzui: if the maintainer is a single person, not a team, user_address in LicenseNotification.send(), while it is a list of strings if the maintainer is a team. shouldn't a one-element list be used for "person is maintainer" case too? [15:26] sinzui: never mind, i see now taht a single address worked before [15:27] adeuring, indeed that is confusing. I had to read the code of our send mail helper to see that it would work [15:29] sinzui: right, I an often a bit worried when a function(method argument can have different types. ANyway, r=me [15:29] thank you adeuring [15:36] adeuring: branch for you if you get a sec, I noted a 'known issue' for the backend stuff that needs updating will be coming in a second branch. https://code.launchpad.net/~rharding/launchpad/edit_product_info_type/+merge/128081 [15:36] rick_h_: I'll look [15:36] adeuring: Do we have an equivalent for get_specification_privacy_filter that works for product listings? [15:37] abentley: not yet... [16:01] rick_h_: r=me [16:07] adeuring: ty much [16:56] rick_h_, abentley -- I'm going to have to leave here shortly, a little earlier than expected. [16:56] rick_h_, abentley -- but I'll obviously be around tonight and tomorrow as I finish tests and get my last branch landed. [17:20] deryck: rgr [19:34] rick_h_: I'm having trouble with a DB query-- getting duplicate results back. Can you have a look at it with me? [19:34] abentley: sure thing [19:35] rick_h_: let's hangout [19:35] abentley: rgr [19:59] abentley or bac if you're still around. Would appreciate a review of https://code.launchpad.net/~rharding/launchpad/store_edit_product_info_type/+merge/128288 [19:59] rick_h_: looking. [19:59] abentley: ty much [20:04] rick_h_: Where is _setLicense being invoked? [20:05] abentley: it's set by the ProductEditView when all the fields are updated. [20:05] abentley: there's an assumption there because changing the information_type changes the license I guess... [20:06] rick_h_: I think this change leaves a hole in the validation, because it allows information_type to change without setLicense being invoked. [20:06] abentley: yea, right [20:07] rick_h_: Can we do setLicense first? Or add the subscription in _set_information_type? [20:09] abentley: thinking, really hate to call setLicense from set_information_type [20:10] rick_h_: Not set_license, but adding the subscription. [20:10] so maybe the best thing is to try to pull out the block that does the commerical sub generation and share it between teh two [20:12] what about a check in set_information_type that if the information_type is EMBARGOED/PROPRIETARY it sets the license manually there, overrides so that it makes sure it's getting the OTHER_PROPRIETARY value [20:12] rick_h_: That would make sense. Either the license or the information_type could be seen as proprietary intent. [20:12] yea, it's just more a functino of license so trying to think of a good way to keep it there [20:12] rick_h_: r16102 provides make_product_form which should simplify your code. [20:12] the root issue is you can set the information type, and the license might not kick in. [20:13] abentley: cool, thanks for the heads up on that. [20:14] abentley: but can the license field ever not be supplied? It's a required field of data [20:15] rick_h_: The view code should never be responsible for the sanity of the data. Especially given we have a web service API. [20:16] abentley: yea, sorry I thought it was required in the model via the validate method, but that's just worried about resetting the license review [20:21] rick_h_: So, I think the subscription is the key thing. The license doesn't matter for information types. A product could have an open source license, but not be announced yet. Which is fine, as long as they're paying for the right to secrecy. [20:22] abentley: yea, so I'll pull that out into a new create_complimentary_subscription method and call from both places. I need to make sure it'll be safe to run twice [20:22] since it could get called via both the license setter and the information type setter [20:23] rick_h_: Sounds good. We seem to be calling such methods "ensure_FOO", rather than create_ or make_. [20:25] abentley: not sure ensure fits here like it does fixing policies [20:25] it's just creating an initial compl. commercial sub [20:28] rick_h_: It's like it in the sense that it doesn't try to create things that already exist. [20:32] ok, fits my head strange but I can buy in :) Pushed an update to the MP when it processes [20:33] bah, I need to update the test though to verify the subscription exists as well [20:37] rick_h_: You don't need line 116 because it duplicates line 148. [20:38] abentley: ah true thanks. [20:41] rick_h_: I would do http://pastebin.ubuntu.com/1262684/ but I believe your code's equivalent. [20:43] abentley: thanks for the suggestino [20:45] rick_h_: r=me either way, but I'm surprised you don't have to change the view in order to solve the bug. [20:46] abentley: the view was in the first branch to get the field to show up [20:46] abentley: it's listed as a pre-req to this MP [20:46] rick_h_: Gotcha. [20:47] thanks for the late day review abentley [20:47] rick_h_: np [20:47] rick_h_: still before my EOD. [20:48] still, late Friday bonus reviews yay ...not :) [20:54] rick_h_: So thanks for the advice on debugging the privacy filter. It turned out that the And() needed to be in a sub-select, because that Product._information_type == InformationType.PUBLIC evaluates true for most rows. [21:00] abentley: cool, glad it worked out. Is that grantee thing still an issue or was that nothing? [21:03] rick_h_: The grantee thing was not really part of it. It was just generating rows where AccessPolicyGrantFlat.grantee_id != TeamParticipation.teamID but Product._information_type == PUBLIC, so such rows were being yielded in the result. === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~300