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