[pacman-dev] Download options

2016-12-01 Thread Allan McRae
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

2016-12-01 Thread Allan McRae
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

2016-12-01 Thread Allan McRae
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

2016-12-01 Thread Allan McRae
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

2016-12-01 Thread Allan McRae
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

2016-12-01 Thread Allan McRae
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.