touch-packages team mailing list archive

[Rolf Leggewie <354972@xxxxxxxxxxxxxxxxxx>]

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:PASSWORD@xxxxxxxxxxxxxxxxxxxxxxxxx/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