=== chihchun_afk is now known as chihchun === JanC is now known as Guest13710 === JanC_ is now known as JanC === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [13:20] I want to find the last activity on a bug by API. I found the bug_activity collection but don't see a defined ordering. Is there anything that will give me a most-recent-first (such as the bugs collection is defined to do)? Or should I just iterate and sort myself - or do I iterate and not need to sort? [13:25] bug_activity is ordered by ID, which should generally amount to most-recent-last [13:27] Thanks. So since I can't slice from the end of a collection, I guess I need to iterate anyway? [13:28] I'd just iterate; the size is usually not prohibitive. [13:29] OK, thank you. [13:29] In the common case it will fit in a single batch. [13:29] I really like this API BTW. Very nice and straightforward. [13:30] It's rare but nice to get praise for the Launchpad API ;-) [13:34] cjwatson: do you have time to review merge proposal? https://code.launchpad.net/~mitya57/git-build-recipe/+git/git-build-recipe/+merge/311874 [13:41] muktupavels: looks good to me, will land [13:41] thanks! [13:49] uploaded to Debian unstable, will see about getting it onto our builders a bit later [13:58] cjwatson, thanks! === pbek_ is now known as pbek === hrybacki is now known as hrybacki|mtg === hrybacki|mtg is now known as hrybacki [16:54] cjwatson: Ping, I messed up. Kubuntu recently staged a good amount of packages, and we have a script that uses the API to retry the dep waits. So thay ended up triggering 200 some builds before some common deps were ready. Not only did I accidentally flood the queue, but that may be why half of the amd64/i386 builders are disabled, right? [16:55] s/flood the queue/flood the queue with builds that are known to fail/ [16:56] Is the builder thing my fault? If so, I admit to it. [16:59] tsimonq2: not your fault [17:00] cjwatson: Ok, so what's the deal then? :) [17:00] tsimonq2: lcy01's openstack infrastructure has been having some difficulty and is down for the time being; the rest is certainly worse than usual, but I don't have time to look today, I can just re-enable and hope [17:01] cjwatson: Ok fair enough [21:40] the job queue for the amd64/i386 builders is huge. what's going on? Also all of lcy01-* is "Cleaning" [21:41] mapreri: i asked this in #ubuntu-relesae as well -- i think lcy01's openstack is having issues (based upon cjwatson's comment ealier) and there was a glibc and perl5 upload (so a lot of stuff is getting rebuilt?) [21:41] oh, I should have really read backlog [21:41] nacc: there are no rebuilds for those uploads... (though there they do cause a lot of autopkgtests to be triggered :S) [21:42] mapreri: err, right, sorry! [21:42] mapreri: i meant queue entries [21:43] nacc: what do you mean by "queue entries"? [21:43] mapreri: as you said, autopkgtests that need to run [21:43] ah yeah [21:51] those don't affect LP builders [21:51] they run on the same cloud but there are quotas [21:52] I think the most recent problem was an internal DNS outage that probably took out a bunch of stuff [21:52] so we'll see how it goes as that all clears [21:52] looks better already than when I last looked [21:53] cjwatson: ah ok, thanks for that info (filing it away) [21:54] cjwatson: well, looking at https://launchpad.net/builders seems lcy01 is still not doing anything :) [21:55] * mapreri got used to no build queue at all on launchpad :> guess it's bad idea to get used to such performance [21:57] yeah, lcy01 is probably still dead but lgw01 is OK on its own once it's caught up [21:57] which it should if the resolver quits exploding [21:58] then where would be the fun [22:03] has been trying to catch up all day, and got not very far with it. hopefully overnight it can