| saiarcot895 | Something in the builders doesn't like the 1.1-GB source file (https://launchpad.net/~saiarcot895/+archive/flightgear-edge/+build/5436966) | 00:24 |
|---|---|---|
| saiarcot895 | Neither this version nor the previous version (which I've retried 3 or 4 times) succeeded, and all failed within minutes | 00:24 |
| wgrant | Hmm | 00:28 |
| wgrant | The build farm is really not designed to commonly build packages that large, but it should work. | 00:28 |
| cjwatson | ensurePresent seems to be synchronous | 00:28 |
| wgrant | I suspect things are just a bit too heavily loaded atm to fetch all the relevant files within a minute. | 00:28 |
| wgrant | cjwatson: It is, deliberately. | 00:29 |
| wgrant | And it has a 60 second timeout atm. | 00:29 |
| cjwatson | Why deliberately? | 00:29 |
| wgrant | cjwatson: So we know when it's done. | 00:29 |
| cjwatson | Well, right, I didn't mean it should be fire-and-forget | 00:29 |
| cjwatson | Bug 241646, I guess | 00:30 |
| ubot5 | bug 241646 in launchpad-buildd "Downloading files from librarian should be asynchronous" [Low,Triaged] https://launchpad.net/bugs/241646 | 00:30 |
| wgrant | Mm, it doesn't really matter too much. | 00:31 |
| wgrant | That was mostly from back in the days when it blocked the master. | 00:31 |
| wgrant | We'd otherwise have to introduce a new call to check if a file existed in the cache, and poll it. | 00:31 |
| wgrant | Which doesn't seem like an improvement at all. | 00:31 |
| wgrant | The problem here is just that we set a 60 second timeout, and that's not enough. | 00:31 |
| wgrant | Even if it were async, we'd still have a timeout, and it would probably still be 60s. | 00:31 |
| wgrant | I'll increase the timeout to 5 minutes like we have in most other places. | 00:33 |
| cjwatson | I was thinking of some kind of "still going" callback from the slave, but OK | 00:37 |
| cjwatson | 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:37 |
| saiarcot895 | Perhaps a check to see if the downloaded size has changed? | 00:38 |
| cjwatson | That's unnecessarily roundabout given that the slave knows what it's downloading. | 00:38 |
| wgrant | cjwatson: I'm not sure I see the benefit of polling. | 00:43 |
| cjwatson | I wasn't advocating polling | 00:45 |
| cjwatson | I don't know quite how to phrase what I want in the buildd slave architecture | 00:46 |
| wgrant | Unless we radically change the communication architecture, requests have to be initiated by buildd-manager. | 00:47 |
| cjwatson | 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:47 |
| wgrant | 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:48 |
| wgrant | But it would indeed make sense to have a smaller timeout on the slave<->librarian call | 00:49 |
| wgrant | And in the normal case terminate it from there. | 00:49 |
| cjwatson | I get that it's hard with the master using xmlrpclib though, since AFAIK we can't stream a response | 00:49 |
| wgrant | Right. | 00:49 |
| cjwatson | 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 |
| wgrant | Heh | 00:55 |
| cjwatson | it'd require bodging both sides, since neither twisted.web.xmlrpc nor xmlrpclib supports that extension (though it's not unheard of elsewhere) | 00:55 |
| cjwatson | xmlrpc can't be the best protocol for this | 00:57 |
| lifeless | s/ for this/./ | 01:00 |
| === stokachu_ is now known as stokachu | ||
| === DalekSec_ is now known as DalekSec | ||
| FourDollars | 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:24 |
| TheLordOfTime | 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 |
| TheLordOfTime | (just a thought) | 03:26 |
| FourDollars | TheLordOfTime: Yes, but it should be a open source project. And should not be a private project. | 03:27 |
| FourDollars | TheLordOfTime: Is there any way to know who owns this project? | 03:27 |
| wgrant | FourDollars: I've freed up the name for you. | 03:27 |
| TheLordOfTime | FourDollars: ask wgrant, who already fixed the problem :) | 03:28 |
| FourDollars | wgrant++ | 03:28 |
| FourDollars | wgrant: Thanks a lot. :D | 03:28 |
| wgrant | np | 03:29 |
| === davmor2_ is now known as davmor2 | ||
| apachelogger | wgrant: can I get a size bump to 10gib on https://launchpad.net/~neon/+archive/kf5-snapshot-weekly please :) | 12:23 |
| wgrant | apachelogger: Done | 12:24 |
| apachelogger | wgrant: thank you | 12:24 |
| === BradCrittenden is now known as bac | ||
| === zequence_ is now known as zequence | ||
| === dobey_ is now known as dobey | ||
| === Guest26569 is now known as Kyle | ||
| KI7MT | 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 |
| KI7MT | *can't | 19:00 |
| dobey | 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:08 |
| dobey | the upstream is probably bugzilla.gnome.org | 19:09 |
| KI7MT | dobey, Ok, thank you. | 19:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!