Skip to content
GitLab
  1. 04 Jan, 2017 2 commits
  3. 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
  5. 22 Oct, 2016 1 commit
  7. 31 Aug, 2016 1 commit
  9. 30 Aug, 2016 1 commit
  11. 04 Jan, 2016 1 commit
  13. 11 Nov, 2015 1 commit
  15. 01 Feb, 2015 1 commit
  17. 24 Dec, 2014 1 commit
  19. 19 Oct, 2014 1 commit
  21. 16 Oct, 2014 2 commits
  23. 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
  25. 04 Aug, 2014 1 commit
  27. 22 May, 2014 1 commit
  29. 28 Jan, 2014 1 commit
  31. 06 Jan, 2014 1 commit
  33. 19 Dec, 2013 1 commit
  35. 15 Nov, 2013 1 commit
  37. 07 Nov, 2013 1 commit
  39. 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
  41. 21 Aug, 2013 1 commit
  43. 22 Jul, 2013 1 commit
  45. 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
  47. 24 Feb, 2013 1 commit
  49. 29 Jan, 2013 2 commits
  51. 17 Jan, 2013 1 commit
  53. 03 Jan, 2013 1 commit
  55. 14 Dec, 2012 1 commit
  57. 20 May, 2012 1 commit
  59. 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
  61. 15 Mar, 2012 1 commit
  63. 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
  65. 14 Feb, 2012 1 commit
  67. 23 Jan, 2012 2 commits
  69. 19 Jan, 2012 1 commit