[00:35] Project windmill build #122: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/122/ === groo_ is now known as groo__ [00:43] wgrant: you've been nominated to coordinate killing poppy, if thats ok with you and sinzui [01:02] lifeless: Killing poppy? You mean moving to poppy-sftp before the rollout? [01:02] Or do you mean renaming poppy-sftp to something sensible, which I would also gladly do? [01:15] wgrant: moving to the new service before the db deploy [01:16] partial scheduled downtime; I've mailed mrevell for a slot on monday [01:18] lifeless: Yeah, saw that. I'll chat with mrevell tonight. [01:18] Thanks. [01:21] wgrant: cool, and *thank you* === poolie__ is now known as poolie [01:34] wgrant: I don't understand why https://bugs.launchpad.net/launchpad/+bug/745799 shows librarian access [01:34] <_mup_> Bug #745799: DistroSeries:+queue Timeout accepting packages < https://launchpad.net/bugs/745799 > [01:35] lifeless: It grabs the changes file to send emails. [01:35] It's on a POST, right? [01:35] yes [01:36] * wgrant looks at the OOPS. [01:37] we should probably store that stuff in -db [massively more resourced] and clear it on completion [01:37] Possibly, although DDs will change where this is required. [01:37] Hmm. [01:37] * wgrant stabs SPFP. [01:38] StevenK: Revision 12696 [01:38] I'm not even sure why it's using SPFP... except maybe for conflict checks. [01:38] We really need to merge the copier and uploader and queue conflict check mechanisms. [01:38] Erm. [01:39] Why are the PackageDiff queries so slow? [01:39] Could you EA them? [01:39] sure [01:39] just qaing stuff first [01:39] Thanks. [01:39] so we cna fix person:+branches [01:39] Great! [01:40] wgrant: thoughts on https://bugs.launchpad.net/launchpad/+bug/740640 ? [01:40] qa wise [01:41] lifeless: Deploy it. The non-AJAX stuff looks safe, the AJAX stuff is bad but needs user interaction behind a flag. [01:42] (and it's already broken on prod) [01:42] wgrant: you've looked at subscriptions - -12704 [01:42] bah [01:42] 12703 [01:43] I'm even in the relevant team on qas now. [01:43] CHecking. [01:45] huwshimi: Ah! The privacy overlay! [01:45] anyone know the time dimension in staging restore logs ? [01:45] 725,778 [01:45] e.g. is that milliseconds, seconds, minutes? [01:46] I presume ms... aren't there timestamps around it? [01:46] wgrant: Indeed [01:47] huwshimi: Not quite pretty yet, but looks like a good start. [01:47] looks like redoing trusted.sql was /way/ more time than the heat migration [01:47] Hm, that's really unlikely. [01:48] wgrant: and yet... [01:49] So I think you're reading it wrong :) [01:50] lifeless: We are QAd. [01:50] Hm. [01:50] Except that we are bad. [01:51] r12697 still has the sprites breakage, right? [01:51] huwshimi: ^^ [01:52] anyhow [01:52] 2011-03-31 00:44:24 INFO 2208-59-0 applied just now in 495.6 seconds [01:52] so, fine. [01:52] Yeah. [01:53] Not good, but fine. [01:53] wgrant: That's right [01:53] huwshimi: I'll tag it. [01:53] Let's deploy 12696. [01:53] Unless the fix is coming RSN. [01:54] Hmm, will be on qas in three hours. [01:55] TYhere's only one interesting performance fix between 12696 and the fix, so I think we might as well deploy now. [02:01] +1 [02:01] Requesting. [02:01] want to queue it? I'll get onto those explains [02:02] thanks! [02:02] Thanks. I don't see why they should be so slow. [02:02] * lifeless hopes he got the tone right in his last email [02:03] does that include ajax times? [02:04] wgrant: you're talking about the 5x574ms queries ? [02:04] No. [02:04] lifeless: Yes, those queries. [02:04] AJAX log is 12699 [02:07] wgrant: its one slow one [02:07] query 569 [02:09] the data isn't on qas yet, will see about prod [02:09] Thanks. [02:12] oopses are looking good - product:+code-index is only a soft timeout now [02:12] Excellent. [02:12] and > 300 are +branches/+registeredbranhces [02:12] Your fix unbreaks Person:+registeredbranches too, right? [02:12] it should [02:12] Heh [02:15] I didn't explicitly test [02:15] but to have a different cause would be excitingly coincidental [02:15] * wgrant growls at qa-tagger. [02:16] Don't add more items for me to the db-stable report 30s after I look at it. [02:17] wgrant: Sorry I had a bit of a brain failure when I tagged that as qa-ok, I was forgetting about the sprites thing. [02:18] huwshimi: It happens. I always check the bugs manually before deploying. [02:18] wgrant: Yeah thanks. [02:23] wgrant: you're doing 721591 ? [02:24] lifeless: Yes, just waiting for mawson to catch up. [02:24] Publishing is slow. [02:24] no worries [02:24] just seeing if the bugmessage.visibilty move regressed bugtask performance [02:25] OOPS-1916QS19 suggests it may have [02:25] wgrant: Ah ha, that explains why mawson's code was up-to-date when I updated it. Let me know when you're done and I'll play with it. [02:25] lifeless: It could have, but it should be fixable. [02:26] ah, hitting reload enough worked [02:26] so if it has regressed its tolerable [02:27] wow [02:27] 8 ajax requests for bugtask:+index [02:28] huwshimi: another tweak - show the count in the collapsed log [02:28] Ajax Requests (8 in 12s) [02:29] (just enumerate & sum) [02:35] StevenK: All yours. [02:36] lifeless: Sure. [02:36] gnar, new bugtask heat indices don't want to be used [02:41] wgrant: Thanks, I'll be evil after lunch. [02:42] hi all [02:42] StevenK: What DSD malice are you up to? [02:42] wgrant: The job runner. [02:43] Aha. [02:44] lifeless, i like your downtime page [02:44] poolie: thanks! [02:45] re bug 746486, couldn't you just remember a mapping from transaction-id to url? [02:45] huwshimi, ^ [02:47] poolie: But how do we create that mapping? [02:48] I found a YUI bug report asking for this sort of thing. [02:48] There's no way to do it at the moment :/ [02:48] Unless we patch Y.io, I guess. [02:50] wow [02:52] Yes :/ [02:52] It's a bit crap. [02:52] it's not possible to dig the transaction out of the yui internals? [02:53] i believe you, i'm just surprised [02:56] lifeless, what did you mean by "blueprints linked bugs" has "inline editing of lists of bugs" [02:56] when i look at a blueprint page with linked bugs it does not seem to have any inline edit controls [03:18] thumper: You've hacked lazr.restful a bit, haven't you? [03:18] kinda [03:19] I need to change the JSON encoder that it uses. Do you have hints for using a non-released version in a dev LP instance, or should I just create a test egg? [03:20] well... I don't personally have a preference [03:20] to test you can easily just create a test egg [03:20] and not add it to the branch [03:21] Sure. [03:40] if I have a resultset designed to bring branch Branch objects [03:40] how can I change the resultset to just give me the Branch.id column? [03:42] thumper: Look at .values [03:42] resultset.values(Branch.id) [03:42] wgrant: cool, ta [03:43] wallyworld: You can't do the escaping inside update_field? [03:43] wgrant: I mentioned that in one of my review replies [03:44] It was my initial suggestion, and I still think it's the right place to do it. [03:44] The latest version is less bad, but it's still the wrong layer. [03:44] wgrant: sorry, i misunderstood. i'll rework it [03:45] wallyworld: Thanks. While your previous versions will work, I want it to be hard to misuse, or people are going to misuse it. [03:45] wgrant: are we sure update_field is used universally and will capture all cases? [03:45] wallyworld: No. [03:45] But it should be. [03:45] I know it isn't used universally yet [03:46] it is still a recent (ish) change [03:46] thumper added the event recently, though... [03:46] So update_field may be the only consumer of that event. [03:46] I think it is [03:46] we may however need to tweak it [03:46] I want these abstractions to be neat, so people don't have to care about escaping. [03:47] They can just do the simple thing, and it will do the right thing for them. [03:47] wgrant: agreed :-) [03:47] as I think there are places where it expects a plain string [03:47] and other places where it expects real HTML [03:47] we may want two methods [03:47] thumper: that's my worry too [03:47] thumper: Hm? Are there are more than two cases? [03:47] two methods is fine [03:47] wgrant: yes [03:47] 1) Given HTML. Needs not to be escaped. [03:47] titles [03:48] 2) Given non-HTML. Always safely escapable, sometimes needs to be escaped. [03:48] assignees which is a link to a person [03:48] wgrant: the question becomes how to determine the HTMLness of the param [03:48] I suppose we could have the new_value_html be a Node [03:48] and check that [03:49] thumper: Exactly. [03:49] then there is still one method [03:49] wallyworld: make it so [03:49] My suggestion is to parse all HTML values into Nodes before giving them [03:49] to the callbacks. This lets update_field distinguish between safe and [03:49] unsafe values. [03:49] that makes a certain amount of sense [03:49] This is similar to what I am doing to our templates at the moment. [03:50] * wallyworld switches branches again [03:56] Unity, you were doing so well. You had not crashed for three days. [04:06] Hah [04:15] A simple review for someone: https://code.launchpad.net/~huwshimi/launchpad/browse-links-746104/+merge/55667 [04:15] thumper? wgrant? ^ [04:16] * wgrant looks. [04:16] Difficult. [04:17] StevenK: Want a very difficult mentor review? [04:18] wgrant: No? :-) [04:18] done [04:19] Thanks thumper. [04:19] 2011-03-31 03:19:20 INFO Ran 48 DistroSeriesDifferenceJob jobs. [04:19] 2011-03-31 03:19:20 DEBUG Removing lock file: /var/lock/launchpad-rundistroseriesdifferencejob.lock [04:19] \o/ [04:20] But did they work? [04:20] do we have a bug for the loggerhead test fail ? [04:20] There is a loggerhead bug. Not sure about a launchpad one. [04:20] ah 745738 [04:30] wgrant: That's the next question. [04:30] But first, tea. [04:38] * StevenK tries to work out how to disable the annoying update-motd stuff [04:40] Project windmill build #123: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/123/ === Ursinha-bbl is now known as Ursinha [04:49] ok, buildbot should succeed *next run* [04:50] * StevenK finds another DSD bug [04:51] This is just a wart, nothing bad [05:14] wgrant: I'm having trouble finding the code that lists the differences for DSDs, can I have a quick hand? [05:14] wgrant: I'd like to hide the child difference line if dsd.base_version == dsd.source_version [05:15] StevenK: You want to hide the child diff, you mean? [05:15] * 3.6.2.0-3 to Maverick version: 3.6.2.0-3 [05:15] * 3.6.2.0-3 to Sid version: 3.6.3.0-2 [05:15] I'd like to not display the first line, since they're the same and the diff will be empty [05:22] StevenK: Grep around in lib/lp/registry/templates, I guess. [05:22] I think Unity just survived me pressing Ctrl+Alt! [05:22] Yes, I can press Ctrl+Alt reliably now. [05:22] This is a good start. [05:23] Ah no, broken again. [05:27] wgrant: I can't see anything obvious in lib/lp/registry/templates/distroseries-localdifferences.pt [05:29] StevenK: distroseriesdifference-listing-extra.pt [05:31] wgrant: Ah ha! Thanks. [05:34] thumper: Still around? [05:37] thumper: Do you recall why we wanted hybrid JSON/XHTML representations in the client cache? We can restore them now, if we want. [05:39] huwshimi, while you're doing css-easy bugs, it would be nice if the textareas for entering bug and mp comments used the same monospace font as the comments are finally shown in [05:39] i think there's a bug for this [05:39] poolie: I think I've seen that bug [05:39] just if you're running low :) [05:40] In https://code.launchpad.net/~wgrant/lazr.restful/bug-684430 I've changed lazr.restful to give XML-escape-safe JSON in most cases. But this will somewhat bloat XHTML representations that are delivered inside application/json... do we care? [05:40] (<, >, & get translated to \uXXXX) [05:41] poolie: Are you thinking of this bug: 713366? [05:41] If we care, then I can shuffle things so it only affects the TALES function, but that seems overcomplicated. [05:41] wgrant i doubt that would ever impact performance [05:41] compared to all the round trips [05:41] poolie: Right. [05:41] is there any chance any client libraries will fail to understand it? [05:41] No. [05:42] Even cjson understands this, and cjson is pretty bad at complying with the spec :) [05:42] i can't think of any other consequences then; can you? [05:42] The only negative consequences are ugliness and slight bloat. [05:42] It's still perfectly correct. [05:42] mm [05:43] it's not really optimized for human reading now [05:43] Indeed. [05:44] so a weak approval from me [05:44] (ugliness also in terms of escaping where we don't need to. but it's not like HTML escaping, because the strings are exactly equivalent once the JSON is parsed) [05:44] or rather enthusiastic but non-authoritative [05:44] Heh [05:44] Thanks. [05:56] https://code.launchpad.net/~wgrant/lazr.restful/bug-684430/+merge/55678 [05:57] Project db-devel build #507: FAILURE in 5 hr 21 min: https://lpci.wedontsleep.org/job/db-devel/507/ [05:57] wgrant: i think my xss fix may be ok now? [05:59] wallyworld: Let's see. [06:00] wallyworld: You use get('innerHTML'), but can't you just set the Node as the content directly? I don't really know YUI, but from my experimentation that seems like it should be possible. [06:00] Indeed, you already do that in multicheckbox.js [06:01] wgrant: which line nr? [06:01] lp.ui.js, 81 in the diff. [06:02] In picker.js you've lost a containing . That doesn't matter at all? [06:02] wgrant: yes, i missed that one. as you say i changed in elsewhere. i'll fix [06:02] Thanks. This looks really good. [06:03] wgrant: also, your lazr restful mp - you need to update news.txt and other stuff. i've already got a mp almost ready to land. i can merge in your stuff once approved and it can be done in one go if you like [06:04] wallyworld: I've already added a NEWS.txt entry. But yes, we should probably release both as 0.18.1. [06:04] What's your change? [06:04] wgrant: https://code.edge.launchpad.net/~wallyworld/lazr.restful/propogate-notifications/+merge/54690 [06:04] Ah, right. [06:05] that one scares me :) [06:05] why? :-) [06:05] Very handy, but scary. [06:05] it replicates what we already do [06:05] for page loads [06:05] but also now via xhr calls [06:05] Yeah, but it's really racy. [06:06] I am very wary of adding 10x the opportunities for races. [06:06] i can see what you mean, but given how we use ajax atm, it should be ok [06:06] I would prefer it if the lazr.restful operations would use a separate notification system that didn't use the session, just returning them within the request. [06:06] s/system/provider/ [06:07] eg. if you comment on a bug then quickly load another one, the notification comes up on the wrong page. [06:07] This is going to make that a whole lot worse. [06:08] However, I guess that fix is on the LP side, not in lazr.restful. [06:08] So this change is probably OK to land. Do you have the LP changes yet? [06:09] wgrant: yes - currently being reviewed. i have a pipe. 1st one for the core infrastructure changes, next one for the actual end functionality [06:10] wgrant: https://code.edge.launchpad.net/~wallyworld/launchpad/show-ajax-notifications/+merge/54342 [06:11] stub: so I'm thinking a -1 and -2 patch *in case* qa is stalled and my updating indices patch doesn't get through in time for the deploy [06:11] wgrant: re your earlier comment. the notifications are returned with the response to a given request [06:12] stub: that way we /can/ do it live if we need to [06:12] lifeless: sure. [06:12] wallyworld: I'm not sure how well that's going to interact with my markupsafe changes, but I guess I'll see when I get to that. [06:12] (-1 to drop the index that is superceded, -2 to add the two new ones). We may need to change the other indices, but I'd like to wait for performance data before doing that. [06:12] stub: ok, I'll prep [06:12] wallyworld: But the normal LP notification infrastructure uses the session, so they can leak cross-request if timing is bad. [06:13] wallyworld: We may later need to fix this for API requests, but it seems well layered so that should be easy. [06:14] wgrant: atm, i'm not changing the backend implementation wrt content/escaping or mechanics of generating notifications. i'm just providing the transport so that xhr calls can get notifications pushed through [06:15] wallyworld: In the bit around line 32 of the blueprint-title-fix diff, any reason you're escaping and setContent instead of using default_value.set('text', default_value)? [06:16] Um, obviously without using the same variable name twice. [06:16] wgrant: cause i didn't know about set('text', ...). my js/yui foo is improving but i'm not an expert clearly :-) [06:16] wgrant: so does set('text'...) escape correctly etc? [06:16] wallyworld: Yeah, me neither... I know a bit of jQuery, but my only real YUI experience is this week. [06:17] wallyworld: It doesn't need to escape, since it is using the DOM. [06:17] But effectively, yes. [06:17] wgrant: ok, so under the covers it will render correctly i guess i what i'm asking. i'll change it and retest [06:17] lifeless: Thanks. [06:18] wallyworld: I'm going to try to break it locally, since I don't quite understand what a couple of the bits do. [06:18] I need to learn more about our JS :/ [06:18] wgrant: break away :-) [06:21] wallyworld: Does the new object from the event get stored somewhere that I can get to in the console? [06:22] wgrant: ask me again tomorrow when I'll have time to give you a full answer [06:22] wgrant: you mean the new_value key of the dict? [06:22] wallyworld: I ideally want to see the whole object, I guess. [06:22] Hmm, something's still wrong. [06:23] wgrant: you may need to set a breakpoint as it's just passed around and not stored anywhere [06:23] wallyworld: If you load a blueprint, change the title to have '' in it, refresh the page, then change another field (eg. Approver), the breadcrumb flashes green on the first change. [06:23] So we're still doing something slightly wrong. [06:23] ugh [06:24] why does launchpad forget I merge into db-devel every day now ? [06:24] lifeless: Oh, so it's not just me. [06:24] wgrant: you mean the first change after refreshing the page? [06:24] wallyworld: The first change after refreshing the page makes the breadcrumb flash, yes. [06:24] wallyworld: So the cache value is wrong, somehow. [06:24] stub: can has tick? https://code.launchpad.net/~lifeless/launchpad/bug-618406/+merge/55680 [06:24] Or the new value is just different, despite being the same. [06:25] wgrant: could be the stupid

wrappers [06:25] i'll have a look [06:25] wallyworld: Yeah, I'm guessing so. [06:25] Thanks. [06:25] wallyworld: It's possibly related to the fact that there is no HTML cache to compare against. [06:25] This can be fixed now, though, since we are escaping JSON properly. [06:25] wgrant: well, the html is just presentation. it's the underlying values which are compared [06:26] wallyworld: Ah, OK. [06:26] so the

comment i made is likely wrong [06:27] wgrant: for example, an assignee attribute may be fred but the html property will be href=...~fred... etc [06:27] lifeless: tick [06:27] wallyworld: Right, but I wasn't sure if it compared the HTML values too. [06:28] wgrant: no, it doesn't [06:29] stub: Ah, thanks, forgot to reply to that email, but you said what I wanted to :) [06:31] I hereby apologise for INotificationRequest. My only excuse is I didn't know better, many years ago when I wrote it :) [06:31] stub: hahaha [06:31] stub: do you mean about the session aspect, or some other aspect ? [06:32] re: session, it was written correctly first off with state being passed in the URL. But that was deemed too ugly so I had to break it. [06:32] thats right [06:32] I'm talking about notifications being HTML strings [06:32] ah! [06:32] Think Curtis fixed that [06:33] righto, that makes more sense (I distinctly remembered discussing the session aspect with you at the time) [06:33] I have an idea for fixing the urls. [06:33] stub: I'm hopefully getting to fixing that stuff tomorrow. [06:33] if we : [06:33] - put notifications in their own place (perhaps in the session db still) [06:33] IIRC, the fundamental problem is it is impossible to differentiate one browser window from another reliably. [06:33] - with an association to a user (as only logged in folk can trigger notifications) [06:34] stub: Yes :/ [06:34] The easiest way to fix this is probably to just continue AJAXifying everything. [06:34] then we could use a very short short (primary key in the table) reference to select the notification to show [06:37] lifeless, hi [06:37] can you give me a url showing inline bug list editing? [06:37] poolie: hi, sorry, edistracted [06:38] np [06:38] there are some in 727023 [06:38] i just had no idea that was actually implemented so i was curious to see it [06:38] the blueprint thing I'm going off an escalated bug [06:38] which I think was fixed [06:38] that you couldn't change the status of linked bugtasks on a blueprint [06:39] I may be misremembering [06:39] lifeless: I suspect the existing mechanism is good enough rather than polluting the URLs with a query parameter. Cure seems worse than the problem (which is rare to trigger (?), and harmless). [06:39] anyhow, I'm basically massively skeptical of any per-bug rules until we have /any/ bug stuff working really well [06:39] separately, i just got a timeout again OOPS-1916L440 on my code homepage [06:39] stub: its certainly low priority [06:39] is that a regression of bug 745310 [06:40] <_mup_> Bug #745310: Person:+branches timeout < https://launchpad.net/bugs/745310 > [06:40] (if known, np) [06:40] stub: I can reproduce it really easily; I have ascreen shot around somewhere with 8 or so notifications on one page [06:40] poolie: I'll look at the OOPS. my WAG is that the page was poor before the regression, and thus is just timing out naturally because ithasn't been optimised (just restored to its prior behaviour) [06:41] yer, but you have to try hard. People are less likely to be submitting 8 tabs simultaneously now that Launchpad performance sucks so much less. [06:41] i wonder [06:41] stub: And we do lots of stuff by AJAX now, which can do notifications without the session evil. [06:43] wgrant: If you pull in the notifications asynchronously, you still have to somehow identify *this* window's set of notifications vs. *that* window's set of notifications. [06:43] wgrant: the issue was that when a page first loads, the cache contains the escaped value, but then the update_cahced_object() function stuffs the unescaped new value into the cache. this is how it always has been so i'll fix it === almaisan-away is now known as al-maisan [06:44] Oh. [06:44] wallyworld: My lazr.restful branch fixes that. [06:44] wallyworld: The cache now contains the unescaped value. [06:44] How did I not think of that :/ [06:44] Let's see if it works now. [06:44] wgrant: ok, then i won't change it on my side [06:46] wallyworld: Yeah, new lazr.restful fixes it. [06:46] Great. [06:46] \o/ [06:46] So, I'm not quite done yet, but I think this infrastructure may just about be correct. [06:46] Then we can deploy it eeeeeverywhere. [06:47] well it's certainly a big improvement on what it was. [06:47] did you head spin around when you said "eeeeeeverywhere"? [06:49] wgrant: can you let me know when your lazr-resful mp is approved so i can roll it into a single 18.1 release? thanks. [06:49] I need to work out how to land it. [06:49] lp-land [06:50] i was just going to merge it into mine directly [06:51] Might as well land separately, or it's going to be confusing to people looking through the history. [06:51] lifeless: You haven't by any chance added a long-poll change notification service to LP while I wasn't watching, have you? [06:51] ok [06:51] wgrant: sorry no [06:51] wgrant: I know where one is we can pick up and use [06:52] wgrant: or I have some ideas on a variant [06:52] Damn. [06:53] wgrant: I think this is fine [06:53] the race is lower on faster requests [06:53] Sure. [06:53] wgrant: I agree we should improve it, but perfect enemy of the good [06:54] Oh, lazr.restful isn't PQM. [06:54] Handy. [06:59] wallyworld: Mine's landed. [06:59] Now, let me finish up reviewing your client fixes. [06:59] wgrant: thanks. will grab it. hopefully my mp will get approved tonight. [06:59] wallyworld: One thing: testtools is only a test dep, so it shouldn't be in requires. [07:01] wgrant: ah ok. i was just going by what i though the review comments said i had to do. i actually agree with you that it needent be listed as a dep. i'll have another look. [07:02] lifeless, sorry, i'm tired and i'm probably just being thick, but i can't see why a lock bit would have any performance impact [07:02] wallyworld: I didn't read the comments at all. [07:08] wallyworld: Do we need getHTMLOrDefault? I can't think when we'd need a fake HTML representation for something that doesn't have an HTML representation. [07:09] wgrant: i put it there as a "failsafe" so that something sensible would still be displayed if there were no explicit html included [07:09] wallyworld: I think we probably want to crash in that case, no? [07:10] wgrant: not sure. i can see both sides. [07:11] Because that function does some slightly questionable stuff, so it would be nice to demolish it if it's not really useful. [07:13] Hi lifeless. A question about qa-ing changes. If you look at 737165 ... you can see I've qa-ed this (on dogfood, with the help of bigjools because qa-ing this required admin rights to set a feature flag) but it got flagged qa-needstesting again. Not sure what to do at this point. [07:13] https://bugs.launchpad.net/launchpad/+bug/737165 [07:13] <_mup_> Bug #737165: Add search option for higher versions of local packages < https://launchpad.net/bugs/737165 > [07:15] I suppose I should just tag it again qa-ok ... but I prefer to check with you first ... [07:15] rvba: Yes, just tag it again. [07:15] wgrant: i'll look at removing it. leave it with me [07:16] qa-tagger ignores old tags, since bugs can be reused. [07:16] all right [07:16] wallyworld: Thanks. Apologies for being so nitpicky, but this stuff will hopefully be used everywhere eventually, so I want to get it *really* right now. [07:17] wgrant: np at all. i agree with the need to get it as right as possible. === al-maisan is now known as almaisan-away [07:28] rvba: things get tagged every time that they show up on the landing branch [07:29] rvba: tagging them ok orotherwise before the taggers get to them just means you'll need to do it again [07:29] rvba: ah, as wgrant explained ;) [07:30] lifeless: I get it now ;-). I'll make sure to check that every time I receive a mail from the buildbot. [07:36] wgrant: tis done [07:36] Woo. [07:37] This change has made the code 15 lines shorter, which can only be a good thing. [07:38] wallyworld: As I said on the MP, _defaultFormatter is a bit odd and I don't understand its purpose. [07:38] It's still using innerHTML, so it smells bad. [07:38] It might be right, but I don't know. [07:39] 161 + // If there is no html representation, the raw cache value should be [07:39] 162 + // properly wrapped inside a node. [07:39] That test comment's wrong now, right? [07:39] The test itself seems to be correct. [07:39] wgrant: bugger sorry. comment is borked [07:43] wgrant: _defaultFormatter is required to return text, and now getHTML wraps stuff inside a node, so get get('innerHTML') is necessary [07:43] poolie: all software sucks. [07:43] poolie: some software sucks more [07:43] wallyworld: Hm, so it will return HTML or unescaped text, right? [07:43] wgrant: although the null case needs to be checked now [07:43] Anything that calls it is probably broken, then. [07:43] poolie: for performance in launchpad the question isn't 'can it have a performance impact', it is 'is the performace impact low enough' [07:44] poolie: we have, you might say, a target rich environment [07:44] poolie: there are practical limits beyond which theoretical models just fail - like in python profiling, actual measurement is the key things [07:45] poolie: I suggest that if you want a better metric than my hunch as expressed, that it needs coding up and scale testing [07:45] wgrant: yes, I think it returns html (when asked to do so) but that html is expected to be safe [07:46] wallyworld: Hm, so the caller sets use_html? [07:47] As I said, this might well be fine, it just seems odd to have a function return both trusted and untrusted strings. [07:47] Depending on the situation. [07:47] wgrant: yes, see text-area-editor.pt [07:48] principle of least suprise [07:48] that's the only place that sets it to true [07:48] Ah, I see. [07:49] I might file a bug for that. [07:49] Since it's mildly insane. [07:49] Anyway, approved. [07:49] lifeless: Still around to mentor? [07:50] wgrant: thanks [07:50] in a few minutes [08:04] Project windmill build #124: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/124/ [08:14] lifeless: Thanks. [08:21] grah [08:21] another compiler layering bug [08:42] good morning === almaisan-away is now known as al-maisan [09:14] More conflicts :( [09:20] can has review https://code.launchpad.net/~lifeless/launchpad/bug-618406/+merge/55703 ? [09:51] stub: one more if you have time https://code.launchpad.net/~lifeless/launchpad/bug-618406/+merge/55703 [09:51] Project devel build #595: FAILURE in 5 hr 5 min: https://lpci.wedontsleep.org/job/devel/595/ [09:52] allenap: https://code.launchpad.net/~stevenk/launchpad/dsd-hide-child-diff/+merge/55685 [09:52] lifeless: I'll take it. === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews [09:55] lifeless: done [10:05] stub: thanks [10:09] allenap: Thanks, but stub got there ;) [10:09] lifeless: No worries, I'm happy :) [10:11] db-devel qa is all green (sorry about those patches! I need some better reminder system for qa todo) [10:14] Hmm... so my ec2 instance is terminated, but no results :-( [10:15] oh... there they are [10:17] Do we have any scripts that still need LibrarianLogger? Its a pain and I think the noise problems it solved no longer exist. [10:18] dunno; fine to nuke IMO [10:18] stub: I check both deployment reports as part of 'starting work' and 'wrapping up [10:18] ' [10:18] daily === al-maisan is now known as almaisan-away [11:35] night all [12:12] Morning, all. [12:16] allenap: did you say you were fixing the db-devel conflict ? === almaisan-away is now known as al-maisan [12:48] * jml has spent the morning defacing sheets of creativity-sized paper. [12:49] * henninge lunches === matsubara-afk is now known as matsubara [13:02] jml: is that a euphemism? [13:03] bigjools: heh. no. [13:03] jml: guess where I do most of my thinking :) [13:03] bigjools: :D [13:06] allenap, hi, care to give me a quick review of: https://code.launchpad.net/~danilo/launchpad/revert-xss-workaround/+merge/55738 (all removal of something we landed earlier :) [13:07] danilos: Yay, thanks. [13:07] wgrant, heh, you are welcome :) [13:08] danilos: If you run into any more escaping issues like that, *please* whine at me until I fix them before working around them like that :) [13:08] wgrant, heh, if all it takes is whining at someone, I'd be happy to :) [13:09] wgrant, fwiw, I do agree with your position, and I brought it up multiple times (in pre-imp, MP, ... :), but we are also working against a deadline [13:09] wgrant, now that I know the proper address to whine at, all the better :) [13:11] oh yeah [13:11] colo [13:11] danilos: Maintenance squads are handy for this sort of thing. [13:12] ... [13:14] Oh dammit. [13:14] The new superlong buildd connection timeout sucks. [13:20] whycome [13:22] One could previously kill a build from a hung builder by disabling the builder. [13:22] The connection would time out after a reasonable interval. [13:22] And the next scan would see that the builder was disabled. [13:22] But now the connection timeout is something like a day. [13:22] So that doesn't work so well. [13:23] s/builder/virtual builder/ :-) [13:23] Yeah. [13:24] But I like to pretend that armel doesn't exist, and the others don't hang, so... [13:26] hi allenap, have time for a review? [13:30] ffs. [13:30] I should release testtools already. [13:32] Yippie, build fixed! [13:32] Project db-devel build #508: FIXED in 5 hr 27 min: https://lpci.wedontsleep.org/job/db-devel/508/ [13:32] jml: you should. [13:33] bac: Certainly :) [13:33] danilos: But I'll do yours first. [13:33] allenap: great: https://code.edge.launchpad.net/~bac/launchpad/bug-745660/+merge/55636 -- most of the 700+ lines are a file deletion [13:34] bigjools: I think I fixed the db-devel conflict... I have my fingers crossed. [13:34] bigjools: No I didn't. [13:34] allenap: yeah :( [13:35] nagbot is still nagging [13:35] PQM swallowed my branch and defecated it into /dev/null. [13:35] bigjools: I didn't think of this consequence when I sped up PQM :/ [13:35] I'll have another go. [13:35] (buildbot-poller only tries to merge again if there's not already a merge in the queue, so the OMG-so-slow PQM slowed down the spam too) [13:50] allenap: a small MP to review if you have the time https://code.launchpad.net/~rvb/launchpad/dds-fix-localpackagediffs-745776/+merge/55704 [13:51] rvba: Should do. [13:51] allenap: great [14:00] henninge: ping for standup [14:16] allenap: could you please have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/js-translation-2/+merge/55575 ? [14:18] adeuring: I'll probably get to it, sure. [14:18] allenap: thanks! [14:30] allenap, btw, thanks for the review :) === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | https://code.launchpad.net/launchpad-project/+activereviews [14:34] danilos: No worries. It was an easy one! === matsubara is now known as matsubara-brb [14:53] hey allenap, jcsackett, would love a review of https://code.launchpad.net/~gary/launchpad/bug741684/+merge/55656 and follow-on branch https://code.launchpad.net/~gary/launchpad/bug741684-2/+merge/55657 when you have a moment. [14:53] gary_poster: looking at the first of those now. [14:53] awesome thank you jcsackett [14:55] Yippie, build fixed! [14:55] Project devel build #596: FIXED in 5 hr 4 min: https://lpci.wedontsleep.org/job/devel/596/ [15:00] gary_poster: i don't think you have any reason to worry about problems with caching initial_message; to my knowledge, one of the reasons we access initial_message is b/c it *doesn't* change, so we can use it as a reference. [15:01] cool, thanks [15:01] so it's a pretty excellent candidate for cache. [15:01] awesome [15:02] gary_poster: what's the reason for LeftJoining on BugActivity from BugNotification? can you have a situation where a notification has no corresponding activity? [15:02] yes, jcsackett. [15:02] huh. [15:03] * jcsackett makes note that he misunderstands what bugactivity must be. [15:03] I want to run a process from a Python script. I want to collect the stdout and the stderr. I want to be able to get the "pure" stdout, unmixed with stderr, but I would also like to be able to have a combined stdout/stderr that looks a lot like hat you would get if stdout & stderr went to the same pipe [15:04] s/hat/what/ [15:06] jml, ec2 test does something like that IIRC. It's not easy nor perfect [15:06] jml, you're not going to like it, but there is code at http://bazaar.launchpad.net/~james-w/ubuild/trunk/view/head:/ubuild/background_runner.py that works [15:06] gary_poster: actually, it doesn't. I'm fixing ec2 test to do that :) [15:07] james_w: your powers of prediction are amazing :) [15:08] james_w: I think I could justifiably switch to using Twisted rather than do that. [15:09] hmm. [15:10] maybe I can do something where I set up a couple of forking streams and replace p.stdout & p.stderr with them [15:11] something roughly equivalent to p.stdout = MultiStream(pure_stdout, mixed_output); p.stderr = mixed_output [15:15] ugh, no, wrong direction === matsubara-brb is now known as matsubara [15:23] henninge: did you want to chat about js at all? Or you're good? === al-maisan is now known as almaisan-away [15:24] deryck: at the moment I am good. [15:25] thanks for asking [15:25] henninge: ok. I'm stepping out of the office for a lunch outside the house. In about an hour. [15:25] adeuring: ^^ just fyi [15:25] ok [15:25] ok [15:32] jcsackett, on calls, so sorry for "succinct" message [15:32] bug activity is not always generated [15:32] IIRC, comments don't always have one, for instance [15:32] I don't remember the details, but I do remember that it is not always there [15:33] gary_poster: dig. no worries for the succinctness. :-) [15:33] :-) [15:33] thanks [15:35] i am surprised that creating a comment could not count as activity; seems to break my mental model of what should be happening. :-) [15:36] but then, that happens all the time. [15:37] :-) [15:38] Project windmill build #125: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill/125/ [15:51] allenap: thanks for the review and the suggestions! [15:52] bac: You're welcome. [15:52] i wasn't aware about cmp. good to know. [15:53] gary_poster: r=me on part 1. looking at the second bit in just a few. [15:54] great, thanks again jcsackett [15:55] Ursinha: I'm looking at https://bugs.launchpad.net/launchpad/+bug/715832 [15:55] <_mup_> Bug #715832: ec2 land adds duplicate tags to the merge proposal's commit message < https://launchpad.net/bugs/715832 > [15:56] Ursinha: I think you originally changed autoland to edit the commit message [15:56] Ursinha: what was the motivation behind that? [15:59] jcsackett, while it is still in your head, I'd love to get your ideas on reducing the churn in that for loop. mumble would be fine--I could take notes for a third branch, or comments, or future work, or something. It would be a shame to lose your idea though. [15:59] gary_poster: what does the ProxyFactory decorator do? is that the one that throws a security proxy on returned data? [15:59] jcsackett, exactly [16:00] gary_poster: my notions on it are still churning--i'm not certain i *have* a solution, just i see that the DB call is happening at roughly a similar O() as before, so could still be an issue. [16:05] jcsackett, gotcha. If there are no teams without preferred emails, and only one notification at a time, you are right, the changes in the loop are small. [16:05] I know we have multiple notifications at a time, though; and I actually ought to see how many teams we have with and without a preferred email--I bet that's a relatively simple SQL select I can make on staging. [16:05] Sadly, I don't see a way to simplify this further and maintain the desired functionality. That isn't to say that there isn't onem of course. If there are more problems, it will be interesting to see what we can do. [16:06] gary_poster: yeah, i think if we reach a point where further changes are needed, we're going to have an interesting time of it. [16:06] that said, and as i said in the review, the actual DB stuff itself is cheaper than it was thanks to your changes, which is a huge help. and the situation in which your other changes doesn't help should be an edge case. [16:07] yeah, hope so. Thanks. [16:10] gary_poster: on part 2, you the goal of _get_recipients_for_team is to get emails for every Person (who is not a Team) that has membership in the team, whether directly or via another team, right? [16:11] jcsackett, not precisely. The logic is similar to that described in get_recipients: [16:12] a team with a preferred email is its own recipient, with no transitive walk down. [16:12] aaah, missed that bit. [16:12] if a team does not have a recipient, then you need to do a transitive walk down to find what does [16:12] (which can be a person or a team) [16:12] right, now it all clicks together. [16:12] cool [16:13] i was about to suggest a single query via teamparticipation, but the filtering to then get rid of people you don't need would be just as expensive as the current iterations. [16:13] yeah. I also considered a recursive with statement, but it didn't seem to be a match: I need to walk down the things I don't return. [16:14] (where with helps you walk down the things you return) [16:14] I could have done it with "with" but it would have made more loops in the DB, even though there might be fewer in Python. [16:14] At least the way I conceived of it [16:15] i think you're right, as i'm thinking through this. and we would much rather have the loops be in python, given db speed was the problem. :-P [16:15] allenap, jcsackett: Could one of you review the code portion of https://code.launchpad.net/~gmb/launchpad/team-subscription-opt-out/+merge/55764 please? [16:16] :-) yeah. Well, the speed is honestly the first problem. The DB usage is a scalability issue, and a secondary problem. But yeah, ideally we'd fix both. :-/ [16:16] gmb: Sure, I'll do it next. [16:16] Cool, thanks. [16:18] gary_poster: r=me on part 2. i have no problems with it being a function, rather than a method. :-) [16:18] jcsackett, cool :-) . Thanks! [16:18] you're welcome. === deryck is now known as deryck[lunch] [16:49] gmb, apparently you have largely reimplemented Launchpad: Diff against target: 345455 lines (+151809/-75208) 3004 files modified [16:49] WAT [16:49] I'm not going to be able to review that today. [16:49] gary_poster: So, that bzr problem you mentioned... [16:49] ^^ [16:49] Oo-kay. [16:49] allenap: Let me take a look at that, then. [16:50] Oh. [16:50] Hahaha. [16:50] Interesting. [16:50] allenap: Ready for review for merging into lp:~gmb/launchpad/db-devel === matsubara is now known as matsubara-lunch [16:51] E_RONG_TARGET [16:51] Hehe :) [16:52] allenap: https://code.launchpad.net/~gmb/launchpad/team-subscription-opt-out/+merge/55779 instead. [16:52] allenap: jcsackett I've 2 small bugfix MP for you to review: [16:52] https://code.launchpad.net/~rvb/launchpad/dds-req-packagediff-fix-flashing/+merge/55775 [16:52] https://code.launchpad.net/~rvb/launchpad/dds-fix-localpackagediffs-745776/+merge/55704 [16:52] gmb: Okeydoke. [16:53] Ta [16:53] rvba: I'll see if I can squeeze one of those in after Graham's. [16:53] great [16:53] rvba: i'm looking at the first of the two now. [16:53] jcsackett: thx === salgado is now known as salgado-lunch [16:57] rvba: why the name change from "retry_handler" to "recompute"? was it just to be clearer, or was there anything else? [16:57] jcsackett: yes, just to be more clear [16:57] cool. === _mup__ is now known as _mup_ [16:59] rvba: to summarize, the big change here is that you're now attaching events to that new span, which is replaced by a placeholder without events on error. is that correct? [17:01] jcsackett: right [17:02] rvba: last question. :-) ui wise, i see that you are removing the red flash animation. this isn't something we want on error anymore? or is it provided by somethine else now? [17:03] jcsackett: I removed the flash anim because, although I like js animation as much as the next guy, you'll be instant feedback right where you've just clicked [17:03] hence no need to flash [17:04] rvba: okay. r=me. [17:04] s/you'll be/you'll get/ [17:04] rvba: it might be worth it to run that flash change by a ui guy, but i see no problems with it. [17:05] jcsackett: we plan to get feedback for the ui (and the rest) asap. All of this is related to the new derived distro series ... thing. [17:06] rvba: sounds good to me. :-) [17:06] rvba: as i said, r=me. :-) [17:06] jcsackett: great, thx. [17:06] if allenap hasn't hit your other branch in a few, i'll take a look at it as well. [17:09] https://code.launchpad.net/~jml/launchpad/various-ec2-fixes/+merge/55763 genuinely needs a review now [17:09] sorry for the noise [17:10] allenap: I'm doing quite a bit of work in a dependant branch, so I'll add the tests you suggested there. [17:10] gmb: Cool :) [17:25] rvba: i am looking at your second branch now. [17:25] jml: if allenap hasn't gotten to your branch in a bit, you're up next for me. [17:27] It's a race! [17:30] jcsackett: Actually, it's all yours; I have to go and collect the kids now. [17:30] allenap: righto. :-) [17:32] jcsackett: looks like allenap took my second branch first :-) [17:32] jcsackett: thanks. [17:32] man. [17:32] web browsers suck. [17:32] can we stop using them please? [17:33] * jcsackett laughs. [17:33] turns out the svgs on http://lpqateam.canonical.com/doc/vision.html look fine in firefox but tiny in chrome [17:35] rvba: r=me, with a small change listed in the MP comment. [17:36] jml: i'll be looking at yours in just a few. [17:36] jcsackett: thanks. [17:36] jcsackett: thanks. [17:36] allenap: thanks also for your review [17:39] did we both hit that branch? [17:39] * jcsackett laughs. [17:39] jcsackett, allenap: I've got a MP for a project which doesn't appear to be listed on the launchpad-project page === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews [17:40] allenap: ah :) [17:40] jelmer: which project? [17:40] jcsackett: lpreview-body [17:41] huh. there is definitely a strong argument for that being an lp project. :-P [17:41] MP link? i'll look when i'm done with jml's MP. [17:44] jcsackett: yeah, indeed :) [17:45] The MP is @ https://code.launchpad.net/~jelmer/lpreview-body/lazy-hooks/+merge/50471 [17:45] thanks :) [17:46] mrevell: could you have a look at https://code.launchpad.net/~jml/launchpad/vision-doc-split/+merge/55789 ? [17:46] * mrevell looks [17:47] jml No problem [17:54] jml, Is there a package with sphinx-build or do I need to go hunt it down from somewhere? [17:54] mrevell: python-sphinx [17:55] ah, thanks [18:01] jml, I'll complete my review of that branch in the morning. [18:01] jml: looks like a good grab bag of fixes. r=me. [18:01] jcsackett: thanks. [18:02] jml: are there bugs filed about the coverage of tests on ec2? your MP mentioned it is not well tested, in general. [18:02] jcsackett: not really. [18:03] jcsackett: there's such a great deal of stuff that's not tested I'm not sure that it's possible to file a closable bug. [18:03] jml: yeah, i could see that being an issue. [18:03] it's sort of funny that our testing infrastructure is sufficiently complicated it's hard to test itself. [18:05] jelmer: r=me. i love short branches. :-) [18:06] jcsackett: Thanks :) === salgado-lunch is now known as salgado [18:07] jcsackett: yeah. it's ec2 and Launchpad's own deployment/installation complexity that really does it. [18:08] jcsackett: ec2 test was originally a fairly organic script that (AIUI) was written as we were learning about how best to do this. Because it wasn't written with testing in mind, there are a lot of sticky bits that need to be unstuck. === deryck[lunch] is now known as deryck [18:09] jml: makes sense. refactoring for testability can be a major pain, too. [18:10] jcsackett: yes. how long has it been since I last advocated TDD in this forum? [18:10] your talk was last week, wasn't it? [18:10] does that count? :-) [18:12] ++TDD! [18:12] :) [18:15] As the original source of the ec2 script and its lack of tests, and someone who has written *lots* of tests, I personally think that exploratory programming has its place. And personally still feel a tad defensive, obviously ;-) . [18:15] When the exploration takes much more time than expected, and what you have works, and you are supposed to go off and do something else now thank you very much, you're left with something like what ec2 was before jml started his magic on it. [18:16] gary_poster: I think that doing TDD with ec2test would have been prohibitively difficult [18:16] I certainly had no freaking idea what I was doing when I was starting :-) [18:16] :) [18:17] and once something is working, it's much easier for someone else to come along & refactor, because "use it and see if it works" becomes a valid & effective test [18:17] gary_poster: I agree. Sometimes you just need to type really fast and see what comes out the other end. There's nothing wrong with that. [18:18] jkakar, cool. congrats on new position! Looks really interesting [18:18] gary_poster: And you shouldn't feel defensive--you solved an important problem. [18:18] :-) thanks [18:18] gary_poster: Thanks! It's turning out to be a lot of fun. :) [18:18] gary_poster: and I honestly don't mean to attack. I couldn't fault your approach with ec2test, and ... what Jamu said :) [18:18] I bet [18:18] That's actually an interesting thing... [18:19] heh, thanks guys. when I said I felt defensive, I was trying to admit that I was not entirely rational in feeling that way :-) [18:19] :) === matsubara-lunch is now known as matsubara [18:34] g'night all. [18:37] night. [18:38] night [18:44] allenap: thanks for the review! Was away and nice to see it done when I returned. :-) [18:44] Wasn't expecting it. :-) [18:55] Project windmill build #126: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/windmill/126/ [19:38] is raising Unauthorized the best way to send back a 401? [19:38] i mean, i assume so, but i don't want to get tripped up by something i'm not aware of, and status codes in launchpad have tripped me up before. [19:46] sinzui: did you still want to mumble about bug 676988? [19:46] <_mup_> Bug #676988: Relax-NG validity error : Element hardware failed to validate < https://launchpad.net/bugs/676988 > [19:47] yes [19:47] when would you like? now? [20:26] sinzui: https://lp-oops.canonical.com/oops.py/?oopsid=1782C2286 [20:31] jcsackett: wow, special oops [20:48] is there a bug about editing blueprints changing the title in an odd way? [20:49] specifically [20:57] <lifeless> yes [20:57] <lifeless> erm possibly yes [20:57] <lifeless> I hink its pending deploy [20:57] <lifeless> does qastaging look better to you? [21:11] <wgrant> james_w: Yes, and the fix has landed. [21:11] <james_w> great, thanks [21:17] <wgrant> We can probably deploy it in a few minutes, too. [21:20] <wgrant> :( [21:20] <wgrant> IE breaks all my plans. [21:23] * thumper gets coffee [21:23] <thumper> I'm natty now [21:23] <jcsackett> IE breaks everyone's plans. [21:23] <thumper> and unity is being a PITA [21:24] <wgrant> thumper: Oh? [21:24] <wgrant> It's pretty stable for me once I've been running for an hour or two. [21:24] <wgrant> But for the first hour just pressing Ctrl+Alt is enough to make it crash. [21:25] <thumper> Ctrl+Alt is fine here :) [21:38] <lifeless> wow, its conflict city atm [21:38] <lifeless> -> hospital, bbiab [21:38] <wgrant> *Another* one? [21:38] <lifeless> garbo [21:38] * wgrant fixes. [21:44] <wgrant> Fairly non-trivial :/ [21:44] <deryck> Later on, everyone. [21:53] * thumper stabs unity in the face [21:53] * thumper goes to a different shell [21:54] <wgrant> thumper: Is it being buggy, or you just don't like it? [21:54] <thumper> crashing on me all the time [21:54] <thumper> can't work like that [21:54] <thumper> it is different if it is my work [21:54] <thumper> but it isn'tyet [21:54] <wgrant> Heh [21:55] <wgrant> Which driver? [21:55] <thumper> intel [21:55] <wgrant> :( [22:02] <jcsackett> sinzui: got another few moments to mumble? [22:17] <thumper> hi guys [22:17] <thumper> I have to take caitlin to the dentist shorty [22:17] <thumper> so I'll miss the standup === matsubara is now known as matsubara-afk [22:57] <wgrant> james_w: Fixed now. [22:58] <james_w> thanks [23:02] <wallyworld> sinzui: are you guys having a standup now? [23:03] <huwshimi> wallyworld: Technically [23:03] <wgrant> I've seen no sinzui this morning, though. [23:03] <wallyworld> huwshimi: i hope my mumble works today. it's been flakey of late :-( [23:03] <huwshimi> wallyworld: It has been for a lot of people === salgado is now known as salgado-afk [23:29] <poolie> hi all [23:30] <wgrant> Morning poolie. [23:37] <LPCIBot> Project windmill build #127: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/127/ [23:38] <wgrant> wallyworld: Do you have a PyPI account? Might as well poke someone to give you or I upload access to lazr.restful. [23:39] <wallyworld> wgrant: no, i don't have one. i'm lp-landing now. i want to package it all up and get it into download-cache so i can get a downstream branch going [23:40] <wgrant> wallyworld: Great. You've fixed the date in NEWS.txt? [23:40] <wgrant> I think that's all that's left to do. [23:40] <wallyworld> wgrant: well, no :-) i guess i should [23:41] <wgrant> wallyworld: Also, lazr.restful isn't PQM-managed, so you just merge directly. [23:41] <wallyworld> ok [23:45] <wgrant> huwshimi: You have no outstanding Loggerhead CSS updates? [23:45] <huwshimi> wgrant: Nope. Should I? [23:46] <wgrant> huwshimi: Just checking that I wasn't going to conflict with you if I attacked it to remove the double line spacing. [23:46] <huwshimi> wgrant: Nah all good. Go for it [23:46] <wgrant> Thanks.