=== Ionic is now known as Guest25863
=== ePierre__ is now known as ePierre
[07:31] <acheronuk> unable to report a bug today "Timeout error. Sorry, something just went wrong in Launchpad."
[07:31] <acheronuk> hopefully temporary
[07:32] <wgrant> It is temporary.
[07:32] <wgrant> Give it a few minutes.
[07:34] <acheronuk> thanks :)
[08:44] <mapreri> trying to manually trigger a build is giving me a timeout, and so did yesterday evening.  last oops: OOPS-9a2342cb36a60c8641d1dbbda5c70352
[08:44] <ubot5> https://oops.canonical.com/?oopsid=OOPS-9a2342cb36a60c8641d1dbbda5c70352
[08:44] <mapreri> (a ppa build in a daily recipe)
[08:45] <cjwatson> wtf is with that gigantic non-sql time
[08:45] <wgrant> Normally that would be dpkg-architecture but that shouldn't be the case for an SPRB, should it...
[08:46] <wgrant> Oh
[08:46] <wgrant> SPRB time estimation is entertaining
[08:46] <wgrant> Look at query 36
[08:46] <mapreri> that url I can't see sounds very entertaining :3
[08:47] <cjwatson> maybe a recipe with a gazillion builds?
[08:47] <wgrant> Precisely
[08:47] <mapreri> it's https://code.launchpad.net/~scribus/+recipe/scribus-daily
[08:47] <wgrant> We do that calculation in the DB for BPBs
[08:47] <cjwatson> right, so SPR.getMedianBuildDuration needs to be 500% less stupid
[08:47] <wgrant> There are ~6k builds
[08:47] <wgrant> Still shouldn't be quite that slow, but who knows
[08:47] <wgrant> Could be security proxy time and such
[08:48] <cjwatson> mapreri: basically it's pulling every single build back from the DB and iterating over each one in Python to calculate the median build duration
[08:48] <mapreri> can't sql do that?
[08:48] <cjwatson> yes
[08:48] <cjwatson> if only the code were less stupid :)
[08:48] <mapreri> heh ^^
[08:48] <cjwatson> please file a bug, totally fixable
[08:49] <cjwatson> (and quote the OOPS ID)
[08:49] <mapreri> OOI, how come whatever schedules the daily build doesn't error out as well?
[08:49] <mapreri> (different timeouts for different sources?)
[08:50] <wgrant> mapreri: It's a cronjob, so doesn't have such a strict timeout.
[08:50] <wgrant> And yeah, the binary package build estimation code already does exactly what we need here
[08:51] <cjwatson> Alternatively (or additionally) we could take the SnapBuild/LiveFSBuild approach of only taking the median of the recent N builds
[08:52] <cjwatson> Since those are more likely to be relevant on current hardware
[08:52] <mapreri> which is probably a saner idea, as the same software a decades ago has a different build time than now
[08:52] <cjwatson> It's not a big deal for recipe builds since those tend to be short, but ...
[08:53] <cjwatson> BPB just takes the most recent build
[08:54] <mapreri> I'll let you turn the bug text into something more readable for you, not sure of what exactly to write that is good for you two :)
[08:55] <mapreri> in the meantime, am I stuck waiting till tomorrow morning for the next build or can I circumnavigate this through the API or something?
[08:56] <cjwatson> I mean you can try the API in case you get lucky (it might do a bit less work or something), but my guess is you're stuck
[08:56] <cjwatson> I'll try to get a patch done today, unless wgrant wants to do it
[08:56] <mapreri> guess that's fine ^^
[08:57] <mapreri> I spend my days trying to get people to be patient while waiting for the debian processes to do their course, I can apply the same teachings to myself
[08:57] <wgrant> cjwatson: Median of recent approach sounds ideal. I'm unlikely to get to it tonight.
[08:58] <wgrant> I am coincidentally fixing another bug that is also pulling several thousand too many rows back into Python...
[09:03] <cjwatson> wgrant: What were the specifics of your "well actually" on twisted-17.9.0?  It's not my comment originally, but I might as well update it
[09:05] <mapreri> mhhh, there is no retry button for recipe builds? (like https://code.launchpad.net/~scribus/+archive/ubuntu/ppa/+recipebuild/1575865)
[09:05] <mapreri> (not that I wanted to retry that specific now)
[09:05] <cjwatson> No real point (aside from this bug) since they can just as easily be reissued.
[09:05] <mapreri> ack
[09:06] <wgrant> cjwatson: behind squid
[09:06] <cjwatson> We have retry on builds that can't be reissued due to burning version numbers.
[09:06] <wgrant> which it isn't any more
[09:06] <wgrant> but no change there
[09:07] <cjwatson> Ah, right.  I could add byte-range support but don't really feel like navigating that bit of Twisted today :)
[09:07] <cjwatson> But I'll update the comment for future travellers
[09:08] <cjwatson> wgrant: https://wiki.canonical.com/Launchpad/Instances still says "apache2 -> squid -> twistd" FWIW although it's not clear in context whether it's referring to staging or prod
[09:08] <cjwatson> or something hypothetical
[09:08] <wgrant> i thought that was all about staging but i haven't read it in a while
[09:08] <cjwatson> ah, that's in the non-production section
[09:09] <cjwatson> ... I think, maybe not.  confusingly written.
[09:09]  * cjwatson squints at heading sizes
[09:09] <cjwatson> ... right, relies on me being able to spot the difference between h3 and h4.
[16:07] <teward> is there a connection between the ubuntu members' @ubuntu.com address and the default contact email set on Launchpad, or do I have to contact Canonical SA for this info?  If anyone knows.
[16:10] <Nafallo> teward: yes. unless you work at Canonical your primary e-mail on LP should be where the alias point at. not sure how often that gets updated or if it's kicked manually though.
=== maclin1 is now known as maclin
[16:31] <teward> yeah the SPF problem and DKIM/DMARC problem are plaguing my other domains, so I just finished my mail server for another domain that I'm going to dedicate, hence the inquiry.  If it's not redirected in a couple days I'll open a ticket about it but wanted to check first :P
[19:23] <ahasenack> hi guys, the diff shown in https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/345312 doesn't match what you get with git locally
[19:23] <ahasenack> locally: https://pastebin.ubuntu.com/p/jfvkf4vydR/
[19:23] <ahasenack> the diff shown in the mp's page has more stuff, like doc/* changes
[19:24] <nacc> cjwatson: --^ fwiw, i think we talked about this a while back as possibly pygit2 getting confused. But not 100%
[20:20] <cjwatson> somebody should file a bug (against turnip)
[20:20] <cjwatson> quoting the repository/ies in question and the relevant commit IDs
[22:13] <nacc> cjwatson: yep, that was the request back then when I (in poor form) didn't finish following up
[22:15] <cjwatson> unless this is https://bugs.launchpad.net/turnip/+bug/1747699
[22:15] <ubot5> Ubuntu bug 1747699 in turnip "incorrect diff in MPs: modified file shown as entirely new" [Undecided,New]
[22:16] <cjwatson> which is also from ahasenack
[22:17] <cjwatson> really it would be helpful if somebody could dig into turnip and figure it out though.  you'd have to do a certain amount of running stuff by hand unless you wanted to set up a full local instance, but it's not too hard to extract turnip/api/store.py:get_merge_diff and friends and run them on a repository by hand
[22:18] <cjwatson> or (perhaps better) come up with a reduced case to add to the test suite that illustrates the problem
[22:27] <nacc> cjwatson: yeah, i think that's roughly where i got to before I dropped it before (tracing through turnip and then reducing it to possibly a pygit2 thing)
[22:27] <nacc> cjwatson: i'll see if i can find where i was before
[22:32] <cjwatson> cool
[22:36] <cjwatson> mapreri: OK, you can try your recipe thing again now