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 ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: aptitude: please allow resumption of incomplete downloads
- From: Celejar <celejar@gmail.com>
- Date: Thu, 05 Nov 2009 16:11:42 -0500
- Message-id: <20091105211142.29283.92585.reportbug@localhost.localdomain>
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 ---
- To: 507426-done@bugs.debian.org
- Subject: Re: resumption / restarting of interrupted transfers
- From: David Kalnischkies <david@kalnischkies.de>
- Date: Thu, 13 Aug 2015 18:51:57 +0200
- Message-id: <20150813165157.GA27849@crossbow>
- In-reply-to: <4933C061.8010007@internode.on.net>
- References: <4933C061.8010007@internode.on.net>
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 KalnischkiesAttachment: signature.asc
Description: Digital signature
--- End Message ---