karmic has seen the end of its life and is no longer receiving any
updates. Marking the karmic task for this ticket as "Won't Fix".
** Changed in: apt (Ubuntu Karmic)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/354972
Title:
apt-transport-https: large packages timeout after 120s, even while
progress is being made
Status in apt package in Ubuntu:
Fix Released
Status in apt source package in Lucid:
Fix Released
Status in apt source package in Karmic:
Won't Fix
Status in apt package in Debian:
Fix Released
Bug description:
Binary package hint: apt
As part of testing, I am occasionally installing large packages from
private-ppas on launchpad, which makes use of https and apt-transport-
https. While doing so, I get timeouts like the following:
Get:1 https://private-ppa.launchpad.net hardy/main PACKAGE 9.1.0-6 [63.4MB]
Err https://private-ppa.launchpad.net hardy/main PACKAGE 9.1.0-6
Operation timed out after 120000 milliseconds with 13942784 out of
63370760 bytes received
Failed to fetch
https://ID:passw...@private-ppa.launchpad.net/PROJECT/ubuntu/pool/main/P/PACKAGE/PACKAGE_9.1.0-6_i386.deb
Operation timed out after 120000 milliseconds with 13942784 out of 63370760
bytes received
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?
Manually wget'ing the package and installing succeeds, and I also do
not see similar timeouts when downloading (asbsurdly) large packages
over http.
Looking at the source code, in methods/https.cc we have the following
code:
// set timeout
int timeout = _config->FindI("Acquire::http::Timeout",120);
curl_easy_setopt(curl, CURLOPT_TIMEOUT, timeout);
curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, timeout);
Quoting the curl_easy_setopt(3) manpage:
CURLOPT_TIMEOUT
Pass a long as parameter containing the maximum time in seconds
that you allow the libcurl transfer operation to take.
Note that it's not a timeout of inactivity, it's just a maximum time
the transfer can take. This does not match the behavior of
method/http.cc where HttpMethod::Go sets the same timeout value on a
select() call on any of the open filedescriptors; this only gets
triggered if none of the connections make any progress by the timeout
time.
It seems to me that the http and https behaviors ought to be made
consistent, or else the https method ought to honor a separate
Acquire::https::Timeout setting.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: apt-transport-https 0.7.20.2ubuntu5
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: apt
Uname: Linux 2.6.28-11-generic i686
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/354972/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
