[00:24] Something in the builders doesn't like the 1.1-GB source file (https://launchpad.net/~saiarcot895/+archive/flightgear-edge/+build/5436966) [00:24] Neither this version nor the previous version (which I've retried 3 or 4 times) succeeded, and all failed within minutes [00:28] Hmm [00:28] The build farm is really not designed to commonly build packages that large, but it should work. [00:28] ensurePresent seems to be synchronous [00:28] I suspect things are just a bit too heavily loaded atm to fetch all the relevant files within a minute. [00:29] cjwatson: It is, deliberately. [00:29] And it has a 60 second timeout atm. [00:29] Why deliberately? [00:29] cjwatson: So we know when it's done. [00:29] Well, right, I didn't mean it should be fire-and-forget [00:30] Bug 241646, I guess [00:30] bug 241646 in launchpad-buildd "Downloading files from librarian should be asynchronous" [Low,Triaged] https://launchpad.net/bugs/241646 [00:31] Mm, it doesn't really matter too much. [00:31] That was mostly from back in the days when it blocked the master. [00:31] We'd otherwise have to introduce a new call to check if a file existed in the cache, and poll it. [00:31] Which doesn't seem like an improvement at all. [00:31] The problem here is just that we set a 60 second timeout, and that's not enough. [00:31] Even if it were async, we'd still have a timeout, and it would probably still be 60s. [00:33] I'll increase the timeout to 5 minutes like we have in most other places. [00:37] I was thinking of some kind of "still going" callback from the slave, but OK [00:37] there does have to be a timeout somewhere, but I would've thought it would be better phrased as "slave download from librarian stalled" [00:38] Perhaps a check to see if the downloaded size has changed? [00:38] That's unnecessarily roundabout given that the slave knows what it's downloading. [00:43] cjwatson: I'm not sure I see the benefit of polling. [00:45] I wasn't advocating polling [00:46] I don't know quite how to phrase what I want in the buildd slave architecture [00:47] Unless we radically change the communication architecture, requests have to be initiated by buildd-manager. [00:47] But there are two things that might time out: one is master<->slave (e.g. slave falls over), the other is slave<->librarian. I'm saying those should be independent timeouts; if slave<->librarian times out then it should fail the ensurePresent call (or analogue), but otherwise I'd like it to be able to refresh the master<->slave timeout as long as it's still in progress [00:48] We probably don't want an unlimited timeout on master<->slave, as slaves more than occasionally break in terrible ways and need to be killed. [00:49] But it would indeed make sense to have a smaller timeout on the slave<->librarian call [00:49] And in the normal case terminate it from there. [00:49] I get that it's hard with the master using xmlrpclib though, since AFAIK we can't stream a response [00:49] Right. [00:55] We could break the xmlrpc spec and send a response without content-length, and push a byte every so often ... not sure that's the best option :) [00:55] Heh [00:55] it'd require bodging both sides, since neither twisted.web.xmlrpc nor xmlrpclib supports that extension (though it's not unheard of elsewhere) [00:57] xmlrpc can't be the best protocol for this [01:00] s/ for this/./ === stokachu_ is now known as stokachu === DalekSec_ is now known as DalekSec [03:24] Hi, I want to register a new project for ibus-chewing, but Launchpad told me that ibus-chewing is already used by another project. And then I open https://launchpad.net/ibus-chewing, there is no such project. Do you know how to fix this? [03:26] FourDollars: If it says it exists but you can't see it it *could* be a private project. If you read the error page: "This page does not exist, or you may not have permission to see it." [03:26] (just a thought) [03:27] TheLordOfTime: Yes, but it should be a open source project. And should not be a private project. [03:27] TheLordOfTime: Is there any way to know who owns this project? [03:27] FourDollars: I've freed up the name for you. [03:28] FourDollars: ask wgrant, who already fixed the problem :) [03:28] wgrant++ [03:28] wgrant: Thanks a lot. :D [03:29] np === davmor2_ is now known as davmor2 [12:23] wgrant: can I get a size bump to 10gib on https://launchpad.net/~neon/+archive/kf5-snapshot-weekly please :) [12:24] apachelogger: Done [12:24] wgrant: thank you === BradCrittenden is now known as bac === zequence_ is now known as zequence === dobey_ is now known as dobey === Guest26569 is now known as Kyle [19:00] Hello, noob question, but I'm trying to locate bugs for a package called yelp-tools particularly, upstream bugs, but I can seem to fins any bug rpts at all .. am I not looking in the correct location: https://launchpad.net/ubuntu/+source/yelp-tools [19:00] *can't [19:08] https://bugs.launchpad.net/ubuntu/+source/yelp-tools would be where any bugs opened against the package in ubuntu would be, it's not the upstream [19:09] the upstream is probably bugzilla.gnome.org [19:20] dobey, Ok, thank you.