1. 04 Jan, 2017 2 commits
  2. 05 Dec, 2016 2 commits
    • Martin Kühne's avatar
      Parametrise the different ways in which the payload is reset · e83e868a
      Martin Kühne authored and Allan McRae's avatar Allan McRae committed
      
      
      In FS#43434, Downloads which fail and are restarted on a different server
      will resume and may display a negative download speed. The payload's progress
      in libalpm was not properly reset which ultimately caused terminal noise
      because the line width calculation assumes positive download speeds.
      
      This patch fixes the incomplete reset of the payload by mimicing what
      be_sync.c:alpm_db_update() does over in sync.c:download_single_file().
      The new dload.c:_alpm_dload_payload_reset_for_retry() extends beyond the
      current behavior by updating initial_size and prevprogress for this case.
      This makes pacman reset the progress properly in the next invocation of the
      callback and display positive download speeds.
      
      Fixes FS#43434.
      
      Signed-off-by: default avatarMartin Kühne <mysatyre@gmail.com>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      e83e868a
    • Dave Reisner's avatar
      dload: use curl's keepalive mechanism · 7114ca62
      Dave Reisner authored and Allan McRae's avatar Allan McRae committed
      
      
      This does exactly the same thing as it code it replaces, but punt to
      curl to do it for brevity. Requires curl 7.25.0, which we already cover.
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      7114ca62
  3. 22 Oct, 2016 1 commit
  4. 31 Aug, 2016 1 commit
  5. 30 Aug, 2016 1 commit
  6. 04 Jan, 2016 1 commit
  7. 11 Nov, 2015 1 commit
  8. 01 Feb, 2015 1 commit
  9. 24 Dec, 2014 1 commit
  10. 19 Oct, 2014 1 commit
  11. 16 Oct, 2014 2 commits
  12. 02 Oct, 2014 1 commit
    • Olivier Brunel's avatar
      alpm: Fix wrong xferred/total sizes when resuming downloads · 1e3c088c
      Olivier Brunel authored and Allan McRae's avatar Allan McRae committed
      When a package is already partially downloaded in the cache, its download
      size will only be of what's left to be downloaded. Since pkg->download_size
      is what's used when calculating the total download size for the totaldl
      callback, same thing apply.
      
      However, the download progress callback was including this initial size,
      which would thus lead to invalid values (and percentage) used in frontends.
      That is, the progress bar could e.g. go further than 100%
      
      In the case of pacman, there is a sanity check for different historical
      reason (44a57c89
      
      ), so before the possible "overflow" was noticed, the total
      download size/progress reported was wrong. Once caught, the TotalDownload
      option was ignored and it would use individual file download values as
      fallback instead.
      
      Signed-off-by: default avatarOlivier Brunel <jjk@jjacky.com>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      1e3c088c
  13. 04 Aug, 2014 1 commit
  14. 22 May, 2014 1 commit
  15. 28 Jan, 2014 1 commit
  16. 06 Jan, 2014 1 commit
  17. 19 Dec, 2013 1 commit
  18. 15 Nov, 2013 1 commit
  19. 07 Nov, 2013 1 commit
  20. 18 Sep, 2013 1 commit
    • Christian Hesse's avatar
      dload: avoid renaming files downloaded via sync operations · 3b3152fc
      Christian Hesse authored and Allan McRae's avatar Allan McRae committed
      
      
      If the server redirects from ${repo}.db to ${repo}.db.tar.gz pacman gets
      this wrong: It saves to new filename and fails when accessing
      ${repo}.db.
      
      We need the remote filename only when downloading remote files with
      pacman's -U operation. This introduces a new field 'trust_remote_name'
      to payload. If set pacman downloads to the filename given by the server.
      
      The field trust_remote_name is set in alpm_fetch_pkgurl().
      
      Fixes FS#36791 ([pacman] downloads to wrong filename with redirect).
      
      [dave: remove redundant assignment leading to memory leak]
      
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      3b3152fc
  21. 21 Aug, 2013 1 commit
  22. 22 Jul, 2013 1 commit
  23. 05 Jul, 2013 1 commit
    • Dave Reisner's avatar
      do not check error from close(2) · eb19d41d
      Dave Reisner authored and Allan McRae's avatar Allan McRae committed
      
      
      On operating systems we support, the behavior is always such that the
      kernel will do the right thing as far as invalidating the file
      descriptor, regardless of the eventual return value. Therefore,
      potentially looping and calling close multiple times is wrong.
      
      At best, we call close again on an invalid FD and throw a spurious EBADF
      error. At worst, we might close an FD which doesn't belong to us when a
      multi-threaded application opens its own file descriptor between
      iterations of the loop.
      
      Signed-off-by: default avatarDave Reisner <dreisner@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      eb19d41d
  24. 24 Feb, 2013 1 commit
  25. 29 Jan, 2013 2 commits
  26. 17 Jan, 2013 1 commit
  27. 03 Jan, 2013 1 commit
  28. 14 Dec, 2012 1 commit
  29. 20 May, 2012 1 commit
  30. 09 Apr, 2012 1 commit
    • Dan McGee's avatar
      Fix issues with unintialized variable value usage · ded66fbb
      Dan McGee authored
      
      
      Detected by clang scan-build static code analyzer.
      
      * Don't attempt to free an uninitialized gpgme key variable
      * Initialize answer variable before asking frontend a question
      * Pass by reference instead of value if uninitialized fields are
        possible in download signal handler code
      * Ensure we never call strlen() on NULL payload->remote_name value
      
      Signed-off-by: default avatarDan McGee <dan@archlinux.org>
      ded66fbb
  31. 15 Mar, 2012 1 commit
  32. 20 Feb, 2012 1 commit
    • Nagy Gabor's avatar
      Print error message when to-be-downloaded file cannot be created · 31d95b86
      Nagy Gabor authored
      
      
      It can happen that the to-be-downloaded file cannot be created in cachedir.
      For example, I am an -Sup user, and it is comfortable to set --cachedir to
      /mnt/pendrive, which is a FAT filesystem, so files like
      capseo-1:0.3-2-i686.pkg.tar.xz cannot be downloaded to there.
      
      Before this patch, pacman didn't give clear output about what happens when
      the download code could not create the necessary file. This can be confusing
      with -Su. An example output:
      ***
      $ sudo pacman -S capseo bochs --cachedir /c/TEMP
      
      resolving dependencies...
      looking for inter-conflicts...
      
      Targets (2): bochs-2.4.6-1  capseo-1:0.3-2
      
      Total Download Size:    0.61 MiB
      Total Installed Size:   2.61 MiB
      
      Proceed with installation? [Y/n]
      :: Retrieving packages from extra...
      warning: failed to retrieve some files from extra
       bochs-2.4.6-1-i686       611.5 KiB   118K/s 00:05 [------------------]  97%
      error: failed to commit transaction (unexpected error)
      Errors occurred, no packages were upgraded.
      ***
      
      After the patch, pacman will give more informative error message (and
      pm_errno is set properly):
      ***
      error: could not open file '/c/TEMP/capseo-1:0.3-2-i686.pkg.tar.xz.part': Invalid argument
      error: failed to commit transaction (failed to retrieve some files)
      ***
      
      Unfortunately, the "could not open file" error message is printed for
      every mirror (that can be dozens of lines), which is ugly, but at least
      informative... Without modifying the download logic (for example, by
      introducing -2 return value for _alpm_download() to indicate giving up),
      this ugliness cannot be eliminated.
      
      Signed-off-by: default avatarNagy Gabor <ngaba@bibl.u-szeged.hu>
      Signed-off-by: default avatarDan McGee <dan@archlinux.org>
      31d95b86
  33. 14 Feb, 2012 1 commit
  34. 23 Jan, 2012 2 commits
  35. 19 Jan, 2012 1 commit