[00:02]  * cjwatson embarks on a bit of refactoring there
[00:06] <cjwatson> wgrant: I think it was actually broken by r17579 and we just didn't notice.  inferred_vcs shows up in the output.
[00:07] <wgrant> cjwatson: Quite possibly. Must be test ordering.
[00:07] <wgrant> Since that test has passed since then.
[00:07] <cjwatson> Yeah, as I say that test doesn't seem as careful as it should be.
[00:08] <cjwatson> I'm up for a while yet, so I'll clean it up
[00:08] <wgrant> I'd forgotten about the JSON cache when I approved that branch. I'm tempted to revert the inferred_vcs export.
[00:09] <wgrant> blr: What do you think?
[00:09] <wgrant> inferred_vcs should be temporarily, anyway, as we can backfill vcs at some point.
[00:10] <wgrant> And it is causing every Product view to incur Branch and GitRepository queries to render the JSON representation.
[00:17] <cjwatson> I wouldn't be sad about that
[00:27] <blr> wgrant: how valuable is it to expose in the api?
[00:28] <wgrant> blr: I don't think it's very interesting at the moment.
[00:28] <blr> agreed
[00:28] <blr> we really only need it internally for now
[00:30] <blr> wgrant: are you happy to revert the export or shall I?
[00:34] <wgrant> blr: Could you? Most/all of the query count test fixes can probably go.
[00:35] <blr> wgrant: sure
[00:52] <cjwatson> Ha, after starting on this refactoring I notice that I have a branch from March with exactly the same thing in progress
[01:25] <wgrant> cjwatson: I hate it when that happens.
[01:26] <wgrant> Like with the product-aps thing
[01:26] <wgrant> I was looking on DF and wondering why the query didn't use the Product.access_policies that clearly already existed.
[01:27] <wgrant> So I tweak the query locally and the tests fail because the column doesn't exist.
[01:27] <wgrant> I'd worked through most of the solution on DF in February and completely forgotten all about it.
[04:33] <wgrant> blr: All the other test changes are still necessary with that reverteD?
[04:37] <blr> wgrant: hmm perhaps I missed some tests, green with regex 'query_count' and 'test_product', plus the doctest
[04:39] <wgrant> blr: I'd just look through your two testfix merges to see if you've missed anything.
[04:51] <blr> wgrant: yes, the other querycount bumps are necessary (specification, bugtask, gitlisting)
[04:52] <wgrant> blr: Weird, OK.\
[04:52] <wgrant> r=me
[04:52] <wgrant> Thanksw
[05:18] <wgrant> Oh
[05:18] <wgrant> I even filed a bug about the thing I forgot about, with details: https://bugs.launchpad.net/launchpad/+bug/1425430
[05:19] <mup> Bug #1425430: Bulk project access checks are slow <privacy> <private-projects> <timeout> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1425430>
[08:25] <cjwatson> blr: I think your latest change will result in duplicated result lines if there is a comment in the dirty header and a comment somewhere else in the same file
[08:28] <cjwatson> blr: You probably want http://paste.ubuntu.com/11797735/ ?
[08:32] <cjwatson> wgrant: Any word on the Soyuz redesign docs you had sketches of?
[08:35] <wgrant> cjwatson: No.
[08:35] <wgrant> Hmm.
[08:35] <wgrant> buildbot is very unhappy with me.
[08:35] <wgrant> I have a vague recollection of Storm leaking references with List attributes.
[08:35] <wgrant> Many years ago.
[08:35] <cjwatson> It really is ...
[08:36] <wgrant> PackageUpload.searchable_versions is a List, though.
[08:36] <wgrant> And it doesn't seem to blow up quite so effectively.
[08:50] <blr> cjwatson: err quite, thanks.
[08:55] <wgrant> I can reproduce it locally, at least, on one test.
[09:02] <blr> wgrant: shall I land this in the morning, given you and buildbot are not on good terms atm?
[09:25] <wgrant> blr: Yeah, landing it now won't exactly work.
[09:29] <wgrant> Ahhh, computers, how I love you.
[09:29] <wgrant> Can reliably reproduce in product-aps-set
[09:30] <wgrant> Cannot reproduce in current devel.
[09:30] <wgrant> But buildbot can.
[09:32] <cjwatson> I'm going to see if I can implement my apt-get build-dep / dose-builddebcheck suggestion today, unless anyone has serious objections.
[09:32] <cjwatson> Starting with trying to backport the thing to precise ...
[09:33] <wgrant> The whole pulling ocaml into everywhere thing is sort of unpleasant.
[09:33] <wgrant> But worth a try, I suppose.
[09:33] <cjwatson> Only into our build-dep chain.
[09:33] <cjwatson> ocaml binaries are standalone once you get them built.
[09:34] <wgrant> Yeah
[09:34] <wgrant> But is ocaml in the interesting bootstrap set today?
[09:34] <blr> ocaml? O.o
[09:34] <wgrant> Oh, it's in main, so it must be.
[09:34] <wgrant> blr: Yes, people are weird, sadly.
[09:35] <cjwatson> This kind of problem often fits functional languages quite well.
[09:35] <wgrant> Indeed.
[09:36] <cjwatson> We could reduce bootstrap problems by allowing lp-buildd to degrade to failing versioned build-dep failures if it doesn't have dose.
[09:37] <cjwatson> ocaml is in main because of llvm-toolchain-* b-ding on dh-ocaml.  Not sure why that is.
[09:40] <blr> wgrant: yes, and then write libraries like this http://sumtypes.readthedocs.org/en/latest/
[09:42] <lifeless> wgrant: people are weird w.r.t. ocaml ?
[09:44] <wgrant> lifeless: There are only three projects I've ever cared about written in it, and at least one of them (sks) has no reason to be.
[09:44] <blr> lifeless: I've never met a quant, but I can imagine they would be very weird.
[12:18] <wgrant> I think the leak may be through Storm's MutableValueVariable._event_system, but I'm just avoiding that part of the code entirely for now.
[12:21] <cjwatson> wgrant: Want me to organise a deployment this afternoon if possible, assuming that you defeat it before EOD?
[12:31] <wgrant> cjwatson: Yeah, just waiting for tests to complete.
[12:32] <wgrant> Then I get get -use landed and deployed tomorrow afternoon.
[12:32] <wgrant> Thanks.
[12:58] <wgrant> So perhaps the mere act of reading it is sufficient for doom. Bah.
[13:04] <mpt> Wow bug 1853 is in progress \o/
[13:04] <mup> Bug #1853: Project group "display name" is redundant with "title" <feature> <lp-registry> <projectgroups> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1853>
[13:07] <mpt> The 20th-oldest still-open Launchpad bug report
[20:16] <rpadovani> I know you guys are super busy, but do you have 5 minutes to take a look to https://bugs.launchpad.net/loggerhead/+bug/1436483 ? The diff side by side in completely unusable, and I'm sure it's a 5 minutes fix
[20:16] <mup> Bug #1436483: The diff page side by side has broken layout <loggerhead:New> <https://launchpad.net/bugs/1436483>
[20:43] <blr> rpadovani: certainly not looking very side by side there.
[20:47] <rpadovani> blr, :D I think it's due the  radius borders someone added back in march
[20:51] <blr> hmm, that's a different issue, I'm not sure that style should be applied there.
[20:52] <blr> rpadovani: I think the issue is the padding
[20:52] <blr> on .code, .linenumber
[20:54] <blr> rpadovani: thanks for the report, will get that fixed now. I just need to see if that style is being used elsewhere (probably how this bug was introduced)
[20:54] <rpadovani> blr, thanks for the fast response, I should ping you guys more often :D
[20:55] <blr> yeah, please do :)
[21:07] <blr> rpadovani: wow, how long has this been broken, any idea?
[21:08] <blr> bzr blame is suggesting that padding was added in 2011...
[21:08] <rpadovani> blr, so it isn't, because I used to use it until I opened the bug
[21:09] <blr> rpadovani: ok, something else going on in that case (although that did fix it...)
[21:12] <rpadovani> blr, the width of .lineNumber
[21:12] <rpadovani> https://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/revision/484
[21:13] <rpadovani> that fixes https://bugs.launchpad.net/loggerhead/+bug/310255
[21:13] <mup> Bug #310255: 6 digit line numbers get cutoff <loggerhead:Fix Released by cruzjbishop> <https://launchpad.net/bugs/310255>
[21:15] <blr> rpadovani: looking for a diff that satisfies both
[21:37] <blr> hmm I don't actually know who reviews loggerhead.. I guess we do?
[21:44] <blr> rpadovani: thanks, cjwaston will probably want to look at that, but should be landed soon.
[21:45] <rpadovani> blr, thanks to you :-)
[21:45] <blr> maybe we need css regression testing!
[21:46] <rpadovani> or a theme ex-novo, maybe responsing (just joking)
[21:47] <blr> a responsive theme for LP would be great, but a fair bit of work I'd imagine.
[21:49] <rpadovani> tbh after the git support the thing I really would like are webhooks (and I see you are working on them)
[21:49] <blr> yep, webhooks are coming :)
[21:49] <rpadovani> \o/