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