| Summary: | enhance RESUMECOMMAND documentation in make.conf man page was: Portage/wget ratelimit fails on re-get. | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Tres 'RiverRat' Melton <RiverRat> |
| Component: | Documentation | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | Keywords: | InVCS |
| Priority: | High | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 181949, 187293 | ||
did you set RESUMECOMMAND? No. I didn't know about that one. Now I'd like to change this to a documentation bug. Please add to "man make.conf" at the end of the FETCHCOMMAND subsection: Also see: RESUMECOMMAND below. And to the end of the RESUMECOMMAND subsection: If using wget then the "--continue" option is advised. This has been released in 2.1.3_rc6. |
sys-apps/portage-2.1.1_pre3-r4 net-misc/wget-1.10.2 FETCHCOMMAND="/usr/bin/wget --limit-rate=1k -t 5 --passive-ftp -P \${DISTDIR} \${URI}" Above FETCHCOMMAND was set to confirm the following: Start fetching a package and interrupt it. When restarted the ratelimits are not applied until the start of the first full download. If the next file is partially complete it will fail to apply the rate limits too. I haven't checked if the rate limits are applied to a partial file after a full file with them are applied. It is these symptoms that is leading me to believe that portage is failing to rate limit when it recieves the following response: HTTP request sent, awaiting response... 206 Partial Content or after noticing that it has part of the file. If this turns out to be a wget bug then forgive me for mis-assigning it to portage.