=== gary_poster is now known as gary_poster|away [00:38] wgrant: https://code.launchpad.net/~stevenk/launchpad/format-imports-ad-infinitum/+merge/122981 [00:59] wgrant: there's another existing css in choiceedit.js (similar to the one fixed in pickers) which i'll deal with as well [01:05] * StevenK stabs Unity [01:10] StevenK: The diff in lib/lp/codehosting/__init__.py is slightly suspicious, but possibly harmless [01:11] wgrant: Right, I wasn't really sure about that one. Probably best to revert and land, I guess? [01:12] You can keep it if you throw it through ec2 [01:36] wallyworld_: Bug #1045135, bug #1044546, bug #1044370 are all fixed now, right? [01:36] <_mup_> Bug #1045135: Changing a sharing policy can leave unused access policies lying around

< https://launchpad.net/bugs/1045135 > [01:36] <_mup_> Bug #1044546: +sharing shows '{policy_name}' for information types granted but not permitted by current combination of branch and bug sharing policies < https://launchpad.net/bugs/1044546 > [01:36] <_mup_> Bug #1044370: update sharing policies via ajax needs to refresh +sharing details < https://launchpad.net/bugs/1044370 > [01:37] wgrant: yes [01:37] Also bug #1008538 [01:37] <_mup_> Bug #1008538: Bug Supervisors are not notified when the project is not shared < https://launchpad.net/bugs/1008538 > [01:38] yes, that's the one just applied via the sql [01:38] Right, just wanted to check. All closed now [01:48] wgrant: https://code.launchpad.net/~wallyworld/launchpad/css-fix-empty-sharing-table/+merge/122983 [01:48] * StevenK tries to work out the cause of bug 1036775 [01:48] <_mup_> Bug #1036775: Launchpad shows bugs in projects that do not use Launchpad bugs

< https://launchpad.net/bugs/1036775 > [01:50] wallyworld_: I wonder if it would be cleaner to create a Pillar Name's private information blah blah in one Y.Node.create, then set tr/td/span's text [01:54] wgrant: i tend to find that Y.Node.create doesn't like everything in one statement, nt sure why [01:54] i can try it again, but every other time it returns something not quite right [01:55] wallyworld_: Hm, it should work, and it tends to be a bit cleaner I find [01:55] This particular case isn't that bad, but once you get another layer of nesting it ends up hideous [01:59] wgrant: it worked for this case. in the past, it has not gone well if i then try and set text on the node later, when it is created with nested elements in the string [01:59] i've pushed the changes [02:00] Thanks [02:03] wallyworld_: Hm, didn't you just revert that basically? [02:03] Now the only diff from devel is moving the Y.Node.create into the function [02:04] ffs, yes [02:07] wgrant: so here's the problem - Y.Node.create('') doesn't work, so that's why i did it as a create of the tr node, then an append child for the td [02:08] Ah ha, I think I get it [02:08] i guess i need to do a .one(td) to set the text [02:08] Huh, that's really strange [02:09] I wonder if it's something about s not wanting to exist without a surround [02:12] wgrant: the set text kills any nested nodes, so i needed to do a .one() to get the innermost node. that worked. changes on their way up [02:13] wallyworld_: I was thinking a .one('tr td span').set('text', pillar_name) would work [02:13] i don't need the span [02:13] and if i doa .one(td) on the row node, that works [02:13] Well, if you don't use the span then you need to also set the rest of the text [02:14] Which is really part of the template [02:14] But it doesn't really matter [02:14] i can just set the text of the table cell can't i [02:15] Right, but then you have to include the "'s private information blah blah blah blah" in the set() call [02:15] Rather than just the pillar_name [02:17] oh, i see what you are saying. but it works as is [02:19] wallyworld_: Are your latest changes pushed? [02:19] 'cause they're still bad [02:19] Oh, no they're not [02:19] Your order is just slightly confusing :) [02:27] wgrant: ok, i used a span, looks better i think [02:34] wallyworld_: Indeed, thanks [02:34] r=me [02:35] thanks [02:58] wgrant, wallyworld_: https://code.launchpad.net/~stevenk/launchpad/hide-search-for-unofficial/+merge/122993 [02:58] Somewhat misnamed, but oh well [03:44] wallyworld_, wgrant: No review for me? :-( [04:02] Clearly not. [04:27] StevenK: sorry, was at lunch with bigjools [04:28] looking now [04:31] wallyworld_: Ah, then maybe you can help me with bug 984871, which has JS written all over it. [04:31] ok [04:32] wallyworld_: In Chromium, you load the page and you see the number of results, and then some AJAX events happen and it disappears. [04:33] but it works in ff [04:33] Yes, but we have to support both. [04:33] Unless they do stupid things like encode ~'s [04:34] sure, just remarking [04:34] i'll have a look at the js [04:37] StevenK: in your mp, i can't see where in the diff the !ServiceUsage.UNKNOWN block mentioned in the covering letter used to be [04:38] wallyworld_: It's not in the diff. [04:39] Line 74 of buglisting-default.pt [04:39] the covering letter implies it was changed [04:41] oh i see [04:41] the outer conditional stays but we are adding a new conditional deeper inside [04:41] Right, exactly. [04:42] wallyworld_: There is other stuff handled in the block that I've left alone. [04:42] StevenK: why not use should_show_bug_information as on line 89? [04:43] that seems to fit with using an external tracker or not [04:43] especially the explanatory text [04:44] wallyworld_: Mainly because that TAL is a mess. [04:45] one issue for me is that we would be using two different ways of determining the use of an external tracker - view/should_show_bug_information and the enum check [04:46] can't the form stuff just be added to hat same construct? [04:46] with the not: removed? [04:46] Ah, I see. [04:48] wallyworld_: The construct further down is for portlets [04:51] StevenK: you mean because class="top-portlet" ? [04:51] the search form is inside this block [04:52] so i think the correct thing to do is use view/should_show_bug_information [04:52] just like the block above [04:54] wallyworld_: http://pastebin.ubuntu.com/1188320/ [04:54] i don't quite fully understand line 55 of the diff - "action search_url|string:" is ultimately replaced with just search_url without the "|string:". I guess this is a consequence of removing the f-flag and stopping the use of tal attributes? [04:55] StevenK: yes, i think that new diff makes sense to my untrained eye. [05:02] wallyworld_: I have no idea about that bit -- I'm just trying to rip out the class python: bit [05:05] StevenK: i think you need action search_url|string: since it will handle an empty search_url [05:05] and just render action="" instead maybe of action=None or something like that [05:10] steven@undermined:~/launchpad/lp-branches/hide-search-for-unofficial% bzr grep 'search_url\|string:' [05:10] lib/lp/bugs/templates/bugtarget-macros-search.pt: the |string bit will only be in the tal. the search_url will be set elsewhere [05:15] so given that attribute is not part of the feature flag removal, why not just leave it there as it was? [05:18] wallyworld_: http://pastebin.ubuntu.com/1188340/ [05:19] StevenK: it needs to be a tal attribute [05:19] for the expression to be evaluated i think [05:26] wallyworld_: Ah, http://pastebin.ubuntu.com/1188345/ [05:28] StevenK: yes, that looks right i think [05:29] tests will test us for sure :-) [05:29] Yeah, indeed [05:29] Let me commit and push [05:29] ok, i'll wait for the final diff to update [05:38] StevenK: r=me. that chrome issue doesn't happen for me locally sadly, just with lp.net [05:40] wallyworld_: Do you have buglisting turned on? [05:40] There's a feature flag involved. [05:40] ah, maybe not. i always forget that. i wish it had been added to sample data [05:42] right, fails now. good. [05:54] StevenK: it's a hack that was added in for an issue with Chromium's history handling [05:55] i don't understand what the issue was or what the fix does, but removing the hack stops the failure [05:55] because it no longer updates history with an 'incorrect' copy of the model missing 'total' [05:55] but i don't know what else will break removing this [06:07] Strange [06:07] wallyworld_: Where's the hack? [06:08] StevenK: listing_navigator.js, around line 166 [06:09] So I wonder if we could fix it by injecting total into e.prevVal [06:10] But no idea how to do that [06:11] i'd like to fully understand it all before we make changes [06:11] why was the change made, what was the issue etc === almaisan-away is now known as al-maisan [07:34] good morning [07:34] good morning adeuring [08:22] lifeless: hi [08:22] lifeless: re the LP SOA docs [08:23] lifeless: where should test implementations of services live? [08:24] for use when testing things that act as clients? [08:24] They should be provided by the concrete service, or at least interface tested by it to prevent skew, [08:24] . [08:25] lifeless: yeah, for that use [08:25] lifeless: so clients will probably have testing dependencies on the server code tree? [08:26] or a pypi package or deb package [08:26] right [08:27] they shouldn't need to import it however. better if they can't in general - use processes to use it [08:27] hmm [08:28] lifeless: you have told me before but I can't recall (sorry). Why is it better if they can't? [08:31] it makes it harder to tightly couple these loosely coupled things [08:32] e.g. language neutrality - if you want to redo a client into go, you don't need to touch the server. [08:32] test or otherwise [08:33] you can argue that this is silly, you can always do that work later... and if it was the only advantage, I'd say sure [08:34] but you also get enforced layer safety; you don't need to worry about conflicting library versions and so forth. [08:37] right. discipline in that regard rarely works [08:37] at least, not for me :) [08:38] indeed, you can't be a little bit (binary state) [08:38] probably not today or tomorrow, but maybe next week, I'd like to set this up for libdep-service. [08:39] can I do anything to help ? [08:40] hmm. [08:41] You mean, other than you already have? [08:41] :) [08:41] boom-tish [08:41] Answering questions is the only thing I can think of. [08:41] ok, well I stand ready. [08:41] is libdep-service django ? [10:37] wgrant: http://paste.ubuntu.com/1188697/ has some changes to dbpolicy.py and test_error.py. Had some fallout, and think I've ended up tracking a problem that was bugging gary and benji for ages [10:38] still haven't done a full test run though [10:38] stub: What'd you have to change? [10:38] And what sort of fallout? It looked relatively sensible. [10:39] getUtility(IZStorm).get('foo') could emit an OperationalError rather than a DisconnectionError if the db was down and the Store needed to be constructed [10:39] Opened a bug on that one [10:39] Huh [10:39] That's surprising. [10:40] Also, the test_error was triggering our 'store left in a disconnected state' checks. [10:40] They are the stuff of nightmares [10:40] Yeah, and I think I've fixed it now [10:41] The stores look like they were being created in that state, and I'm now ensuring they always get registered with the transaction manager so transaction abort puts them into a state we expect them to be in. === al-maisan is now known as almaisan-away === gary_poster|away is now known as gary_poster [12:16] mgz: hi, were you going to review that MP i posted yesterday? if not, i'll get someone else. [12:21] jelmer: could you please have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/specification-grants/+merge/123062 ? [12:21] adeuring: looking [12:21] jelmer: thanks! [12:48] bac: I shall post something to it, did look over the code [12:49] mgz, thanks. gary is also doing it but i'd like your comments since you've already looked === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: ∞ [14:05] mgz: gary has posted his comments on my MP. i'd like to land this shortly so if you have helpful comments could you add them soonish? thanks. [14:14] bac: posted a few comments [14:14] thanks mgz! [14:17] I see gary asked about the participants thing as well. [14:17] so it's not just me not knowing launchpad :) [14:38] mgz: yep. well commented now. [14:44] jcsackett: thanks for your review! [14:50] adeuring: you're welcome! [15:36] deryck: ping, got a sec? [15:36] rick_h_, on call with abentley right now [15:36] deryck: rgr [15:45] rick_h_, free now. What's up? [15:46] deryck: looking at the sql count test failure stuff and I think part of it is the storm clearing or something. http://paste.mitechie.com/show/774/ is the test failure, which shows the product insert, but the test as a "Store.of(product).invalidate()" which I would expect to reset the queries? [15:46] * deryck looks.... [15:47] deryck: Should we be posting design decisions like "blueprints support only PUBLIC and the proprietary types" somewhere? [15:47] abentley, hmmm, good question. [15:47] abentley, yeah, let's follow up to the dev list with that. [15:48] abentley, actually, wait, no I don't think we need to for that. [15:48] abentley, we're really just matching what we had before, plus privacy, or what people think of when they say privacy. [15:49] rick_h_, so the selects are the new queries? And you think these are left over from a different test? [15:50] deryck: so I'm investigating part of it. I think it might be my code's fault and I'm investigating, but the INSERT being listed made me wonder if the invalidate() wasn't working/what I was thinking [15:51] rick_h_, invalidate just tells storm to through away its own cache of the objects, to force it to get new objects. === matsubara is now known as matsubara-lunch [15:52] deryck: ok, so this is in fact saying the insert/update are part of the recorded queries then [15:56] rick_h_, right. I'd run this in devel and see what you get and compare the two. [15:56] deryck: ok, digging. Thanks for the quick sanity check. [15:56] np === deryck is now known as deryck[lunch] === matsubara-lunch is now known as matsubara [17:04] deryck[lunch]: I noticed that the set of allowed information_types for blueprints will exactly match that for projects. === deryck[lunch] is now known as deryck [17:08] abentley, nice [18:10] deryck: ping again, halp! [18:10] rick_h_, give me just a few minutes and I can help. [18:10] deryck: ok thanks [18:10] np [18:22] rick_h_, ok, what's up? [18:26] deryck: hangout? [18:27] rick_h_, sure. [18:51] sinzui: halp please! have a few min for a hangout? [18:51] I do [18:51] sinzui: invite coming [18:52] sinzui, and if you can spare 5 minutes after rick_h_, I'd like a quick chat about something, too. [19:14] jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/limit-blueprint-info-types/+merge/123150 ? [19:15] abentley: certainly. [19:17] abentley: r=me. [19:17] jcsackett: thanks. [20:09] sinzui, are you still chatting with rick_h_? [20:09] no [20:09] did rick_h_fall off the face of the earth? [20:10] he wants you sinzui, not me. [20:10] * rick_h_ runs away NOT IT! [20:10] I'm losing cable modem now anyway. ignore me. [20:10] cable guy is wiring up voip phone and needs to disable lines to test. [20:10] deryck: yea, you've been very jittery today [20:11] I'll return when he's done. :) [20:17] sinzui, let's try to chat, he has cut me yet. should be brief. [20:17] hasn't cut me [20:17] okay [20:23] * sinzui thinks he is talking to himself [20:24] rick_h_I am here? [20:24] Am I alive? [20:24] sinzui: yes [20:24] thank you for the validation of my existence [20:24] next up, find a purpose [20:25] sinzui: I find it best to tie them together. I exist to serve a purpose, my purpose is to exist. Next question. === gary_poster is now known as gary_poster|away [21:51] hmmm [21:51] new oauthkeys now notify with a from of bounces@c.c [21:51] :/ === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ∞ [22:52] wallyworld_, https://bugs.launchpad.net/launchpad/+bugs?field.tag=escalated [22:55] jcsackett: btw, you didn't land https://code.launchpad.net/~coreygoldberg/lp-dev-utils/ppr-access-parser/+merge/119409 for some reason ? [22:57] lifeless: Looks like I just forgot. If you can land, feel free--storm just took out Internet, and cell phone can't land. :-) [22:58] jcsackett: cool, I will do so [22:59] lifeless: Cool, thanks, and sorry for the forgetfulness. [22:59] no matter [23:00] sinzui: A storm has taken out Internet, and it appears my phone can't handle mumble on 3G alone. [23:00] okay