[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#554640: marked as done (aptitude: please allow resumption of incomplete downloads)



Your message dated Thu, 13 Aug 2015 18:51:57 +0200
with message-id <20150813165157.GA27849@crossbow>
and subject line Re: resumption / restarting of interrupted transfers
has caused the Debian Bug report #507426,
regarding aptitude: please allow resumption of incomplete downloads
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
507426: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507426
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: aptitude
Version: 0.6.0.1-1
Severity: wishlist


We recently had a thread on d-u about the possibility of allowing the resumption of incomplete downloads.  This is really necessary when trying to download large packages under poor network conditions.  Under the current system, aptitude will just loop forever, starting again each time the download stalls.  Even if there are reasons why this should not be the default, might it not be a good idea to allow the user to enable resumption?

-- Package-specific info:
aptitude 0.6.0.1 compiled at Oct 25 2009 19:26:02
Compiler: g++ 4.3.4
Compiled against:
  apt version 4.8.1
  NCurses version 5.7
  libsigc++ version: 2.0.18
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20090803
  cwidget version: 0.5.13
  Apt version: 4.8.1
	linux-gate.so.1 =>  (0xb77c5000)
	/usr/lib/libv4l/v4l1compat.so (0xb77c1000)
	libapt-pkg-libc6.9-6.so.4.8 => /usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0xb76ef000)
	libncursesw.so.5 => /lib/libncursesw.so.5 (0xb76aa000)
	liblog4cxx.so.10 => /usr/lib/liblog4cxx.so.10 (0xb7501000)
	libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xb74fb000)
	libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0xb7438000)
	libept.so.0 => /usr/lib/libept.so.0 (0xb73bd000)
	libxapian.so.15 => /usr/lib/libxapian.so.15 (0xb726c000)
	libz.so.1 => /usr/lib/libz.so.1 (0xb7257000)
	libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb71d4000)
	libboost_iostreams.so.1.40.0 => /usr/lib/libboost_iostreams.so.1.40.0 (0xb71c9000)
	libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb71b0000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb70be000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7097000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb707a000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6f32000)
	libv4l1.so.0 => /usr/lib/libv4l1.so.0 (0xb6f2d000)
	libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb6f29000)
	libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6f24000)
	libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0xb6f04000)
	libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0xb6ed7000)
	libuuid.so.1 => /lib/libuuid.so.1 (0xb6ed3000)
	librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb6eca000)
	libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb6e98000)
	libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb6e87000)
	/lib/ld-linux.so.2 (0xb77c6000)
	libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0xb6e7d000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6e58000)
	libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0xb6dee000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-rc5-lizzie-00402-gb6727b1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6. 0.7.24            Advanced front-end for dpkg
ii  libboost-iostreams1.40 1.40.0-2          Boost.Iostreams Library
ii  libc6                  2.10.1-5          GNU C Library: Shared libraries
ii  libcwidget3            0.5.13-1          high-level terminal interface libr
ii  libept0                0.5.29            High-level library for managing De
ii  libgcc1                1:4.4.2-2         GCC support library
ii  liblog4cxx10           0.10.0-1          A logging library for C++
ii  libncursesw5           5.7+20090803-2    shared libraries for terminal hand
ii  libsigc++-2.0-0c2a     2.0.18-2          type-safe Signal Framework for C++
ii  libsqlite3-0           3.6.19-3          SQLite 3 shared library
ii  libstdc++6             4.4.2-2           The GNU Standard C++ Library v3
ii  libxapian15            1.0.16-3          Search engine library
ii  zlib1g                 1:1.2.3.3.dfsg-15 compression library - runtime

Versions of packages aptitude recommends:
pn  apt-xapian-index              <none>     (no description available)
pn  aptitude-doc-en | aptitude-do <none>     (no description available)
pn  libparse-debianchangelog-perl <none>     (no description available)
ii  sensible-utils                0.0.1      Utilities for sensible alternative

Versions of packages aptitude suggests:
pn  debtags                       <none>     (no description available)
pn  tasksel                       <none>     (no description available)

-- debconf-show failed



--- End Message ---
--- Begin Message ---
Hi,

On Mon, Dec 01, 2008 at 09:15:53PM +1030, Arthur Marsh wrote:
> I just had a resumption work after earlier having a transfer restart from
> the beginning using the site snapshot.debian.net.
> 
> Is there anywhere in the aptitude documentation that discusses when
> resumption of transfers works or does not work?

apt continues the download if it can, if the server says the file was
updated in the meantime it can't reuse the partial file it already has
of course.

I am a bit at the loose here as we have tests ensureing that download
continueing works as expected – and the bugreport has in exchange not
a lot of information helping in nailing down why it shouldn't or why it
should be a special case here not covered by a test.

I am hence assuming that this problem is fixed in the meantime in the
seven years of silence in this bugreport… closing hence, but feel free
to reopen if this is still reprodicible of course!


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


--- End Message ---

Reply to: