1. 05 Dec, 2016 1 commit
    • 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
  2. 22 Oct, 2016 2 commits
  3. 23 Feb, 2016 1 commit
  4. 04 Jan, 2016 1 commit
  5. 20 Sep, 2015 1 commit
  6. 20 Jul, 2015 1 commit
  7. 03 Mar, 2015 1 commit
  8. 01 Feb, 2015 1 commit
  9. 27 Dec, 2014 1 commit
  10. 24 Dec, 2014 1 commit
  11. 13 Oct, 2014 1 commit
  12. 30 Sep, 2014 3 commits
  13. 03 Aug, 2014 1 commit
  14. 24 Jun, 2014 1 commit
  15. 08 Mar, 2014 1 commit
  16. 04 Mar, 2014 1 commit
  17. 03 Mar, 2014 4 commits
  18. 07 Feb, 2014 1 commit
  19. 04 Feb, 2014 1 commit
  20. 30 Jan, 2014 1 commit
  21. 28 Jan, 2014 1 commit
  22. 15 Jan, 2014 1 commit
  23. 10 Jan, 2014 1 commit
  24. 06 Jan, 2014 2 commits
  25. 19 Dec, 2013 1 commit
  26. 15 Dec, 2013 2 commits
  27. 31 Oct, 2013 3 commits
  28. 15 Oct, 2013 2 commits
  29. 03 Sep, 2013 1 commit
    • Dave Reisner's avatar
      libalpm: introduce a usage level for repos · 106d0fc5
      Dave Reisner authored and Allan McRae's avatar Allan McRae committed
      
      
      This defines a level of interest a user has in a repository. These are
      described by the bitmask flags in the alpm_db_usage_t enum:
      
        ALPM_DB_USAGE_SEARCH: repo is valid for searching
        ALPM_DB_USAGE_INSTALL: repo is valid for installs (e.g. -S pkg)
        ALPM_DB_USAGE_UPGRADE: repo is valid for sysupgrades
        ALPM_DB_USAGE_ALL: all of the above are valid
      
      Explicitly listing the contents of a repo will always be valid, and the
      repo will always be refreshed appropriately on sync operations.
      
      Signed-off-by: default avatarDave Reisner <dreisner@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
      106d0fc5