Re: [pacman-dev] [PATCH 2/2] wip: pacman: rework the UI of -F
On 2/6/19 9:22 PM, Morgan Adamiec wrote: > On Thu, 7 Feb 2019 at 01:31, Allan McRae wrote: >> >> On 3/2/19 4:42 am, morganamilo wrote: >>> Reworks the UI of -F according to FS#47949 >>> >>> In short -F replaces both -Fs and -Fo. >>> --regex/-x has been replaced with --search/-s. >>> >>> Signed-off-by: morganamilo >>> --- >>> >>> This patch is WIP. Functional changes made, >>> documentation still needs to be changed. >>> >>> Additionally I think https://bugs.archlinux.org/task/47949#comment143477 >>> Is a good idea and I will probably be included in v2 >>> >> >> I'm OK with the changes (without having done a review of your code...). >> However, I think we need to work on the output. >> >> >> Old: >> $ pacman -Fo opt/ >> opt/ is owned by core/filesystem 2018.12-2 >> opt/ is owned by extra/bullet 2.88-1 >> opt/ is owned by extra/postgresql-old-upgrade 10.6-1 >> opt/ is owned by community/9base 6-6 >> opt/ is owned by community/aspnet-runtime 2.2.1+102-1 >> ... >> >> New: >> $ ./src/pacman/pacman -F opt/ >> core/filesystem 2018.12-2 (base) [installed] >> opt/ >> extra/bullet 2.88-1 >> opt/ >> extra/postgresql-old-upgrade 10.6-1 >> opt/ >> ... >> >> >> So the new output follows the old -Fs, which was good when the filepath >> was different for each match. But it not great for some situations >> now... That output remains good for the new -Fs (rainbow issues being >> ignored!), but a rethink is needed for the new -F operations. >> >> Allan > > What if we keep-Fo but have it just change the output format? -F and > -Fo would both work on files and paths. What would it mean, though? Perhaps -o, --oneline -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH 2/2] wip: pacman: rework the UI of -F
On Thu, 7 Feb 2019 at 01:31, Allan McRae wrote: > > On 3/2/19 4:42 am, morganamilo wrote: > > Reworks the UI of -F according to FS#47949 > > > > In short -F replaces both -Fs and -Fo. > > --regex/-x has been replaced with --search/-s. > > > > Signed-off-by: morganamilo > > --- > > > > This patch is WIP. Functional changes made, > > documentation still needs to be changed. > > > > Additionally I think https://bugs.archlinux.org/task/47949#comment143477 > > Is a good idea and I will probably be included in v2 > > > > I'm OK with the changes (without having done a review of your code...). > However, I think we need to work on the output. > > > Old: > $ pacman -Fo opt/ > opt/ is owned by core/filesystem 2018.12-2 > opt/ is owned by extra/bullet 2.88-1 > opt/ is owned by extra/postgresql-old-upgrade 10.6-1 > opt/ is owned by community/9base 6-6 > opt/ is owned by community/aspnet-runtime 2.2.1+102-1 > ... > > New: > $ ./src/pacman/pacman -F opt/ > core/filesystem 2018.12-2 (base) [installed] > opt/ > extra/bullet 2.88-1 > opt/ > extra/postgresql-old-upgrade 10.6-1 > opt/ > ... > > > So the new output follows the old -Fs, which was good when the filepath > was different for each match. But it not great for some situations > now... That output remains good for the new -Fs (rainbow issues being > ignored!), but a rethink is needed for the new -F operations. > > Allan What if we keep-Fo but have it just change the output format? -F and -Fo would both work on files and paths.
Re: [pacman-dev] [PATCH 2/2] wip: pacman: rework the UI of -F
On 3/2/19 4:42 am, morganamilo wrote: > Reworks the UI of -F according to FS#47949 > > In short -F replaces both -Fs and -Fo. > --regex/-x has been replaced with --search/-s. > > Signed-off-by: morganamilo > --- > > This patch is WIP. Functional changes made, > documentation still needs to be changed. > > Additionally I think https://bugs.archlinux.org/task/47949#comment143477 > Is a good idea and I will probably be included in v2 > I'm OK with the changes (without having done a review of your code...). However, I think we need to work on the output. Old: $ pacman -Fo opt/ opt/ is owned by core/filesystem 2018.12-2 opt/ is owned by extra/bullet 2.88-1 opt/ is owned by extra/postgresql-old-upgrade 10.6-1 opt/ is owned by community/9base 6-6 opt/ is owned by community/aspnet-runtime 2.2.1+102-1 ... New: $ ./src/pacman/pacman -F opt/ core/filesystem 2018.12-2 (base) [installed] opt/ extra/bullet 2.88-1 opt/ extra/postgresql-old-upgrade 10.6-1 opt/ ... So the new output follows the old -Fs, which was good when the filepath was different for each match. But it not great for some situations now... That output remains good for the new -Fs (rainbow issues being ignored!), but a rethink is needed for the new -F operations. Allan
Re: [pacman-dev] [PATCHv2] libalpm: prevent 301 redirect loop from hanging the process
On 7/2/19 12:36 am, Mark Ulrich wrote: > If a mirror responds with a 301 redirect to itself, it will create an > infinite redirect loop. This will cause pacman to hang, unresponsive to > even a SIGINT. The result is pacman being unable to sync or > download any package from a particular repo if its current mirror > is stuck in a redirect loop. Setting libcurl's MAXREDIRS option > effectively prevents a redirect loop from hanging the process. > > Signed-off-by: Mark Ulrich > --- > lib/libalpm/dload.c | 1 + > 1 file changed, 1 insertion(+) Great! Applied. Allan > > diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c > index 36ae4ee1..7b114230 100644 > --- a/lib/libalpm/dload.c > +++ b/lib/libalpm/dload.c > @@ -259,6 +259,7 @@ static void curl_set_handle_opts(struct dload_payload > *payload, > curl_easy_setopt(curl, CURLOPT_URL, payload->fileurl); > curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, error_buffer); > curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 10L); > + curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 10L); > curl_easy_setopt(curl, CURLOPT_FILETIME, 1L); > curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 0L); > curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L); >
[pacman-dev] [PATCHv2] libalpm: prevent 301 redirect loop from hanging the process
If a mirror responds with a 301 redirect to itself, it will create an infinite redirect loop. This will cause pacman to hang, unresponsive to even a SIGINT. The result is pacman being unable to sync or download any package from a particular repo if its current mirror is stuck in a redirect loop. Setting libcurl's MAXREDIRS option effectively prevents a redirect loop from hanging the process. Signed-off-by: Mark Ulrich --- lib/libalpm/dload.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 36ae4ee1..7b114230 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -259,6 +259,7 @@ static void curl_set_handle_opts(struct dload_payload *payload, curl_easy_setopt(curl, CURLOPT_URL, payload->fileurl); curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, error_buffer); curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 10L); + curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 10L); curl_easy_setopt(curl, CURLOPT_FILETIME, 1L); curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 0L); curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L); -- 2.20.1
Re: [pacman-dev] [PATCH] libalpm: prevent 301 redirect loop from hanging the process
> But what if you have a mirror which legitimately has 2 hops? I could see > someone trying to run something like: > > pacman -U https://www.archlinux.org/packages/core/x86_64/pacman/download/ > > This is guaranteed 1 redirect already, what if the mirror that it > redirects to has a legitimate second hop in order to account for some > reorganizing? > > I'm fine with the spirit of the patch, but limiting this to a single hop > isn't enough. A larger number like 10 still accomplishes the same goal > while allowing some mirror flexibility/brokenness. That makes sense. I will change it to 10 redirects and resubmit. -- Mark Ulrich
Re: [pacman-dev] [PATCH] libalpm: prevent 301 redirect loop from hanging the process
On Wed, Feb 06, 2019 at 05:22:46AM -0600, Mark Ulrich wrote: > If a mirror responds with a 301 redirect to itself, it will create an > infinite redirect loop. This will cause pacman to hang, unresponsive to > even a SIGINT. The result is pacman being unable to sync or > download any package from a particular repo if its current mirror > is stuck in a redirect loop. Setting libcurl's MAXREDIRS option > effectively prevents a redirect loop from hanging the process. > > Signed-off-by: Mark Ulrich > --- > lib/libalpm/dload.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c > index 36ae4ee1..d04a5e46 100644 > --- a/lib/libalpm/dload.c > +++ b/lib/libalpm/dload.c > @@ -259,6 +259,7 @@ static void curl_set_handle_opts(struct dload_payload > *payload, > curl_easy_setopt(curl, CURLOPT_URL, payload->fileurl); > curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, error_buffer); > curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 10L); > + curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 1L); But what if you have a mirror which legitimately has 2 hops? I could see someone trying to run something like: pacman -U https://www.archlinux.org/packages/core/x86_64/pacman/download/ This is guaranteed 1 redirect already, what if the mirror that it redirects to has a legitimate second hop in order to account for some reorganizing? I'm fine with the spirit of the patch, but limiting this to a single hop isn't enough. A larger number like 10 still accomplishes the same goal while allowing some mirror flexibility/brokenness. > curl_easy_setopt(curl, CURLOPT_FILETIME, 1L); > curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 0L); > curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L); > -- > 2.20.1
[pacman-dev] [PATCH] libalpm: prevent 301 redirect loop from hanging the process
If a mirror responds with a 301 redirect to itself, it will create an infinite redirect loop. This will cause pacman to hang, unresponsive to even a SIGINT. The result is pacman being unable to sync or download any package from a particular repo if its current mirror is stuck in a redirect loop. Setting libcurl's MAXREDIRS option effectively prevents a redirect loop from hanging the process. Signed-off-by: Mark Ulrich --- lib/libalpm/dload.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 36ae4ee1..d04a5e46 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -259,6 +259,7 @@ static void curl_set_handle_opts(struct dload_payload *payload, curl_easy_setopt(curl, CURLOPT_URL, payload->fileurl); curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, error_buffer); curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT, 10L); + curl_easy_setopt(curl, CURLOPT_MAXREDIRS, 1L); curl_easy_setopt(curl, CURLOPT_FILETIME, 1L); curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 0L); curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L); -- 2.20.1
