[pacman-dev] Download options
There was many thread and patches regarding this, so I am starting another! So far there are two (maybe three) things people want options for to do with the downloader. I see most of these options being set in pacman.conf and rarely specified on the command line. Argue with me if I am wrong here... Based on that assumption, here are my preferred option names (for both pacman.conf and the command line): 1) Disable low speed timeout DisableDownloadTimeout --disable-download-timeout I see no need to separate out speed and time timeouts. 2) Set maximum download speed MaxDownloadSpeed --max-download-speed I would also accept replacing speed with limit. 3) (in a glorious future) Set maximum concurrent downloads MaxConcurrentDownloads --max-concurrent-downloads Any argument about these option names will need to be very clearly justified. I don't own a bike so have no need for a bikeshed. Allan
Re: [pacman-dev] [PATCH 4/4] makepkg: reject packages with newlines in paths
On 06/11/16 08:08, Andrew Gregory wrote: > libalpm's local database format does not support paths with newlines. > > Signed-off-by: Andrew Gregory> --- > scripts/Makefile.am | 1 + > scripts/libmakepkg/lint_package/file_names.sh.in | 42 > > 2 files changed, 43 insertions(+) > create mode 100644 scripts/libmakepkg/lint_package/file_names.sh.in > OK. Needed an addition to scripts/po/POTFILES.in A
Re: [pacman-dev] [PATCH v2] Give a "success!" message on database check
On 08/10/16 05:45, Patrick Eigensatz wrote: > 'pacman -Dk' prints a "success!" message if there were no errors. > It is possible to suppress the output using the '-q / --quiet' flag. > > This implements the feature discussed at https://bugs.archlinux.org/task/50087 > > Signed-off-by: Patrick Eigensatz> --- OK - I changed the description of -q a bit to not just include database checks. I have committed a second patch to allow -q suppress success output of --asdeps and --asexplicit. A
Re: [pacman-dev] [PATCH v3] Parametrise the different ways in which the payload is reset
On 18/10/16 00:40, Martin Kühne wrote: > 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. Thanks, A
Re: [pacman-dev] [PATCH 1/1] libalpm/signing: support EDDSA from gpgme 1.7.0
On 12/11/16 06:18, Christian Hesse wrote: > From: Christian Hesse> > Signed-off-by: Christian Hesse > --- > lib/libalpm/signing.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/lib/libalpm/signing.c b/lib/libalpm/signing.c > index 527e763..1feacff 100644 > --- a/lib/libalpm/signing.c > +++ b/lib/libalpm/signing.c > @@ -356,6 +356,10 @@ static int key_search(alpm_handle_t *handle, const char > *fpr, > #if GPGME_VERSION_NUMBER >= 0x010500 > case GPGME_PK_ECC: > #endif > +/* value added in gpgme 1.7.0 */ > +#if GPGME_VERSION_NUMBER >= 0x010700 > + case GPGME_PK_EDDSA: > +#endif > pgpkey->pubkey_algo = 'E'; > break; > } > Thanks, A
Re: [pacman-dev] [PATCH 2/4] makepkg: reject package data with newlines
On 06/11/16 08:08, Andrew Gregory wrote: > The PKGINFO format cannot handle values that contain newlines. > > Signed-off-by: Andrew Gregory> --- > > Many package fields get processed in such a way that getting a newline into > a .PKGINFO file is actually not all that easy. One way to do it is with > PACKAGER (e.g. `PACKAGER=foo$'\n'bar makepkg`). Ideally there would be > a lint_package check for this, but we don't currently have an easy way to loop > through all package variables and this is the most reliable way to be sure > that > we check everything we write. > OK.