| # 01:04:31 | Bilge | It seems using gold instead of ld was the problem with my build |
| # 01:13:53 | loide | quits : Ping timeout: 240 seconds |
| # 01:33:54 | perr | joins #crosstool-ng |
| # 01:38:15 | Bilge | But I don't understand why I see no errors at any stage, ever |
| # 02:34:08 | djerome | joins #crosstool-ng |
| # 03:28:12 | djerome | quits : Ping timeout: 245 seconds |
| # 03:44:21 | djerome | joins #crosstool-ng |
| # 03:52:17 | djerome | quits : Ping timeout: 260 seconds |
| # 04:57:55 | ctngbot | joins #crosstool-ng |
| # 05:04:19 | djerome | joins #crosstool-ng |
| # 05:12:32 | djerome | quits : Ping timeout: 258 seconds |
| # 05:23:07 | perr | quits : Ping timeout: 245 seconds |
| # 05:31:21 | b_rare | quits : Remote host closed the connection |
| # 16:31:18 | ctngbot | joins #crosstool-ng |
| # 17:26:07 | diorcety | joins #crosstool-ng |
| # 18:30:59 | smartin_ | joins #crosstool-ng |
| # 20:55:45 | diorcety | quits : Read error: Connection reset by peer |
| # 20:59:38 | Bilge | y_morin: the reason the downloads take so long is that it's trying (3 times) a lot of dead mirrors |
| # 21:04:20 | y_morin | Bilge: Yes, that's because ct-ng supports many different versions, and some may come from the mirrors. |
| # 21:04:39 | y_morin | Bilge: But there is room for improvment, yes. |
| # 21:05:13 | smartin_ | quits : Quit: leaving |
| # 21:05:34 | Bilge | If I'm reading this correctly, ftp://ftp.gnu.org is transferring at 5-6k/sec with ETA of 1 hour |
| # 21:05:37 | Bilge | (on Travis) |
| # 21:06:22 | Bilge | But if it somehow actually manages to get to the building phase from this then we should know why it fails now since I have full logging on |
| # 21:06:32 | Bilge | https://travis-ci.org/Docker-nano/crosstool-NG/builds/36711587 |
| # 21:28:57 | loide | quits : Quit: Saindo |
| # 21:45:09 | Bilge | Isn't there some way to configure wget options? It's having to time out 3 times on a slow connection and the first two are slow so it takes about half an hour to actually get a fast mirror |
| # 21:46:19 | Bilge | Being able to set retry limit to 1 would help |
| # 21:47:14 | y_morin | Bilge: Paths and misc options ---> (10) Connection timeout |
| # 21:47:45 | y_morin | Bilge: You can lower that. The default is to account for very crapy environment, which tend to happen more often that we'd like. |
| # 21:47:53 | y_morin | .. than we'd like, or expect. |
| # 21:48:02 | Bilge | Not the timeout, the retry limit |
| # 21:48:21 | Bilge | It dowloads at 10k/sec for about 10 minutes then dies and times out |
| # 21:48:24 | Bilge | It does that 3 times for each slow link |
| # 21:48:27 | Bilge | The first two are slow |
| # 21:48:31 | y_morin | Bilge: No, that is not configurable (for now? ;-)) |
| # 21:48:36 | Bilge | > I'm sorry but your test run exceeded 50.0 minutes. |
| # 21:48:48 | Bilge | Travis didn't even manage to download the dependencies :( |
| # 21:48:57 | y_morin | What mirror is so slow? |
| # 21:49:13 | Bilge | ftp.gnu.org |
| # 21:49:17 | Bilge | Both http and ftp protocols |
| # 21:49:36 | Bilge | I don't know why Tavis is having such problems with it because the mirror seems fine to me |
| # 21:50:40 | y_morin | Ah yes, they are horibly slow tonight. I usually get ~13Mbps from them, and that's the speed of my own connection. |
| # 21:51:49 | y_morin | But where do you expect to get gcc, if not from the gnu site? |
| # 21:52:03 | y_morin | Ah, it's giving me 1.25Mbps, now... |
| # 21:52:07 | Bilge | I believe the gcc.gnu.org mirror is really fast |
| # 21:52:14 | Bilge | That's the one that eventually succeeded |
| # 21:54:33 | y_morin | Well, travis has network issues... Not much we can do about it. But, can't you cache the downloads between the builds? |
| # 21:54:49 | Bilge | N0pe |
| # 21:54:57 | Bilge | Can't I change the mirror order? |
| # 22:18:34 | y_morin | quits : Quit: Nighty Night! |
| # 22:22:44 | Bilge | I added `sudo sh -c 'echo 127.0.0.1 ftp.gnu.org >> /etc/hosts'` to Travis config and it got binutils quickly but failed to get gcc from any other mirrors |
| # 22:23:17 | Bilge | Looks like gcc.gnu.org is defined for binutils but not for actual GCC for some reason |
| # 22:26:30 | Bilge | I got the build to run but the log is truncated at 4MB so I still don't know why it fails :^) |
| # 22:26:42 | Bilge | The log length has exceeded the limit of 4 Megabytes (this usually means that test suite is raising the same exception over and over). |
| # 22:26:59 | Bilge | I think now is the time to give up on Travis |