Re: [Bug-wget] [PATCH 5/5] use pkg-config to check gnutls deps if available
I'm in favour of using pkg-config for detection of these libraries and would
like to see the manual checking code gone in a future release.
If we're to merge these patches, all of them should be squashed into one since
they all perform the same action. I've merged all the patches into a single one
and added ChangeLog entry to its right place. If others agree, I'll push this
patch.
--
Thanking You,
Darshit Shah
From 4ddfb0080bca10093774142e79fbe97eeb056782 Mon Sep 17 00:00:00 2001
From: Mike Frysinger
Date: Sat, 1 Nov 2014 14:09:33 +0530
Subject: [PATCH] use pkg-config to check for libraries
Newer versions of zlib, openssl, gnutls, libuuid and pcre packages ship
with pkg-config files, so if we can detect it via those, do so. If that
fails, fall back to the old methods.
---
ChangeLog| 4 ++
configure.ac | 203 ---
2 files changed, 129 insertions(+), 78 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 87366e4..7d8b2f2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2014-11-01 Mike Frysinger
+
+ * configure.ac: Use pkg-config to search for zlib, openssl, gnutls, libuuid and pcre
+
2014-11-01 Darshit Shah
* configure.ac: Fix check for libpsl
diff --git a/configure.ac b/configure.ac
index 5d063df..01d3eef 100644
--- a/configure.ac
+++ b/configure.ac
@@ -265,48 +265,64 @@ dnl
dnl Checks for libraries.
dnl
+PKG_PROG_PKG_CONFIG
+
AS_IF([test x"$with_zlib" != xno], [
with_zlib=yes
- AC_CHECK_LIB(z, compress)
+ PKG_CHECK_MODULES([ZLIB], zlib, [
+LIBS="$ZLIB_LIBS $LIBS"
+CFLAGS="$ZLIB_CFLAGS $CFLAGS"
+AC_DEFINE([HAVE_LIBZ], [1], [Define if using zlib.])
+ ], [
+AC_CHECK_LIB(z, compress)
+ ])
])
AS_IF([test x"$with_ssl" = xopenssl], [
- dnl As of this writing (OpenSSL 0.9.6), the libcrypto shared library
- dnl doesn't record its dependency on libdl, so we need to make sure
- dnl -ldl ends up in LIBS on systems that have it. Most OSes use
- dnl dlopen(), but HP-UX uses shl_load().
- AC_CHECK_LIB(dl, dlopen, [], [
-AC_CHECK_LIB(dl, shl_load)
- ])
-
- ssl_found=no
- case $host_os in
-*mingw32* )
- dnl prefer link to openssl dlls if possible. if not then fallback on static libs. if not then error
-
- AC_CHECK_LIB(eay32, EVP_MD_CTX_init)
- if test x"$ac_cv_lib_eay32_EVP_MD_CTX_init" != xno
- then
-AC_CHECK_LIB(ssl32, SSL_connect, [
- ssl_found=yes
- AC_MSG_NOTICE([Enabling support for SSL via OpenSSL (shared)])
- AC_LIBOBJ([openssl])
- LIBS="${LIBS} -lssl32"
- AC_DEFINE([HAVE_LIBSSL32], [1], [Define to 1 if you have the `ssl32' library (-lssl32).])
-],
-AC_MSG_ERROR([openssl not found: shared lib eay32 found but ssl32 not found]))
-
- else
-LIBS+=' -lgdi32'
-dnl fallback and test static libs
- fi
- dnl add zdll lib as dep for above tests?
-;;
- esac
+ PKG_CHECK_MODULES([OPENSSL], [openssl], [
+AC_MSG_NOTICE([compiling in support for SSL via OpenSSL])
+AC_LIBOBJ([openssl])
+LIBS="$OPENSSL_LIBS $LIBS"
+CFLAGS="$OPENSSL_CFLAGS -DHAVE_LIBSSL $CFLAGS"
+LIBSSL=" " # ntlm check below wants this
+AC_DEFINE([HAVE_LIBSSL], [1], [Define if using openssl.])
+ ], [
+dnl As of this writing (OpenSSL 0.9.6), the libcrypto shared library
+dnl doesn't record its dependency on libdl, so we need to make sure
+dnl -ldl ends up in LIBS on systems that have it. Most OSes use
+dnl dlopen(), but HP-UX uses shl_load().
+AC_CHECK_LIB(dl, dlopen, [], [
+ AC_CHECK_LIB(dl, shl_load)
+])
+
+ssl_found=no
+case $host_os in
+ *mingw32* )
+dnl prefer link to openssl dlls if possible. if not then fallback on static libs. if not then error
+
+AC_CHECK_LIB(eay32, EVP_MD_CTX_init)
+if test x"$ac_cv_lib_eay32_EVP_MD_CTX_init" != xno
+then
+ AC_CHECK_LIB(ssl32, SSL_connect, [
+ssl_found=yes
+AC_MSG_NOTICE([Enabling support for SSL via OpenSSL (shared)])
+AC_LIBOBJ([openssl])
+LIBS="${LIBS} -lssl32"
+AC_DEFINE([HAVE_LIBSSL32], [1], [Define to 1 if you have the `ssl32' library (-lssl32).])
+ ],
+ AC_MSG_ERROR([openssl not found: shared lib eay32 found but ssl32 not found]))
+
+else
+ LIBS+=' -lgdi32'
+ dnl fallback and test static libs
+fi
+dnl add zdll lib as dep for above tests?
+ ;;
+esac
- AS_IF([test x$ssl_found != xyes], [
-dnl Now actually check for -lssl if it wasn't already found
-AC_LIB_HAVE_LINKFLAGS([ssl], [crypto], [
+AS_IF([test x$ssl_found != xyes], [
+ dnl Now actually check for -lssl if it wasn't already found
+ AC_LIB_HAVE_LINKFLAGS([ssl], [crypto], [
#include
#include
#include
@@ -314,19 +330,19 @@ AS_IF([test x"$with_ssl" = xopenssl], [
#include
#include
#include
-], [SSL_library_init ()])
-if test x"
Re: [Bug-wget] [PATCH] Stylistic and idiomatic cleanups in Perl tests
Sorry, my bad. :-/ Amended in new patch attached. /Pär 2014-11-01 7:00 GMT+01:00 Darshit Shah : > On 11/01, Darshit Shah wrote: > >> On 10/31, Pär Karlsson wrote: >> >>> Thanks for the tips, I was going crazy trying to make git to send the >>> emails via git send-email, and it just ended up weird. >>> >>> Changed the tree into a branch and retained the WgetTests.pm name. >>> >>> Attaching via Gmail interface. If anything looks weird, I'll try to fix >>> it. >>> >>> Tested as previously with all versions of Perl. >>> >>> Ack >> >> Just noticed, the ChangeLog entry needs to go into tests/ChangeLog not > in the ChangeLog file in the root of the repository. > > >> --- end quoted text --- >> >> -- >> Thanking You, >> Darshit Shah >> > > > --- end quoted text --- > > -- > Thanking You, > Darshit Shah > 0001-Stylistic-and-idiomatic-cleanups-in-Perl-tests.patch Description: Binary data
Re: [Bug-wget] [Bug-Wget] Patch Test-proxied-https-auth.px
Darshit Shah writes:
> On 10/31, Giuseppe Scrivano wrote:
>>Darshit Shah writes:
>>
>>> Ever since the Perl tests have been ported to the parallel test
>>> harness, Test-proxied-https-auth.px has always failed for me. In a
>>> prior thread, we'd identified the problem as a race between the HTTPS
>>> server being set-up and Wget sending the request.
>>>
>>> The test was already using `sleep 1` to eliminate this race. I've
>>> bumped this up to 2 seconds. Now on my machine, the test no longer
>>> fails.
>>>
>>> If everyone is okay with this change, lets push it. If someone wants
>>> to change the number, please speak up.
>>
>>the problem seems to be that sometimes wget registers a connection as
>>persistent even though it should not that.
>>
>>Before I prepare a patch, I would like to check with you all as you
>>already spent some time on this issue.
>>
>>This code dates back to 2003, but I am not sure we should check for the
>>"Connection" response header only if there is a Content-Length specified
>>(that is contlen != -1).
>>
>>With this patch I could run the test in a loop without failures.
>>
>>(while true; do make check -C tests TESTS=Test-proxied-https-auth || exit;
>>done)
>>
>>diff --git a/src/http.c b/src/http.c
>>index 844f800..cded2de 100644
>>--- a/src/http.c
>>+++ b/src/http.c
>>@@ -2287,7 +2287,7 @@ read_header:
>> }
>>
>> /* Check for keep-alive related responses. */
>>- if (!inhibit_keep_alive && contlen != -1)
>>+ if (!inhibit_keep_alive)
>> {
>> if (resp_header_copy (resp, "Connection", hdrval, sizeof (hdrval)))
>> {
>>
>>
>
> This patch does fix the issue for me too. I agree that the problem was
> in how Wget creates persistent connections. Also, I don't think that
> we should check for the Connection header *only* if the Content-Length
> exists, there are lots of HTTP/1.1 servers that use a Keep-Alive
> connection without sending the Content-Length.
>
> I ack this patch
thanks. I will add a changelog entry and push it.
Regards,
Giuseppe
Re: [Bug-wget] [Bug-Wget] Policy on commit messages
Am Samstag, 1. November 2014, 05:43:11 schrieb Darshit Shah: > Hi, > > In the last few days we've seen a huge flurry of activity and a large number > of patches have been committed to the code base. As someone who was > traveling and hence unable to keep up with the mailing lists, I tried to > catch up by looking at the code base and the changes that have been made. > > It would turn out that the commit messages aren't very informative on the > last few commits. Unless I know the context of the change from the mailing > list, it would be very difficult to understand why that particular change > was important. Both the ChangeLog and commit messages usually only describe > the change in literal terms but not in their logical reasoning. > > I propose that henceforth, all commits be reviewed for detailed descriptions > of not only the syntactical changes, but also the logical reasons behind > the change. This will help us in the long term to follow through the > changes in the code base and also make it easier for new contributors to > understand why some things are the way they are. As I understood, for GNU projects we have very detailed ChangeLog entries and thus very short commit messages. I am not going to make detailed ChangeLog entries AND detailed commit messages. If we move to detailed commit messages (I would appreciate it), then we should autogenerate ChangeLog files from the commit messages. You will find many projects out there already doing so. If we can agree upon a frame or method, I would also appreciate a 'reason field' for the changes. If it is not redundant. E.g. a commit message like 'fixing double free()' stands for itself. Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] [PATCH 5/5] use pkg-config to check gnutls deps if available
Am Samstag, 1. November 2014, 14:11:53 schrieb Darshit Shah: > I'm in favour of using pkg-config for detection of these libraries and would > like to see the manual checking code gone in a future release. > > If we're to merge these patches, all of them should be squashed into one > since they all perform the same action. I've merged all the patches into a > single one and added ChangeLog entry to its right place. If others agree, > I'll push this patch. Cool, I also would like to see support for pkg-config. You could add pkg-config for libpsl as well into the patch and check if there are any other libraries missing. Also, please consider using AC_SEARCH_LIBS instead of AC_CHECK_LIBS. A good description why is here: https://autotools.io/autoconf/finding.html Here is an example for libz: AC_ARG_WITH(zlib, AS_HELP_STRING([--without-zlib], [disable gzip compression support]), with_zlib=$withval, with_zlib=yes) if test $with_zlib != "no"; then AC_SEARCH_LIBS(deflate, z, [with_zlib=yes; AC_DEFINE([WITH_ZLIB], [1], [Use zlib])], [with_zlib=no; AC_MSG_WARN(*** ZLIB was not found. You will not be able to use gzip (de)compression)]) fi Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] [Bug-Wget] Policy on commit messages
On Sat, 1 Nov 2014, Tim Rühsen wrote: If we move to detailed commit messages (I would appreciate it), then we should autogenerate ChangeLog files from the commit messages. You will find many projects out there already doing so. I would strongly support this as well. -- / daniel.haxx.se
Re: [Bug-wget] [PATCH 5/5] use pkg-config to check gnutls deps if available
On 11/01, Tim Rühsen wrote: Am Samstag, 1. November 2014, 14:11:53 schrieb Darshit Shah: I'm in favour of using pkg-config for detection of these libraries and would like to see the manual checking code gone in a future release. If we're to merge these patches, all of them should be squashed into one since they all perform the same action. I've merged all the patches into a single one and added ChangeLog entry to its right place. If others agree, I'll push this patch. Cool, I also would like to see support for pkg-config. You could add pkg-config for libpsl as well into the patch and check if there are any other libraries missing. Oh, I didn't know libpsl ships with pkg-config files. I'll add that in a separate patch. Also, please consider using AC_SEARCH_LIBS instead of AC_CHECK_LIBS. A good description why is here: https://autotools.io/autoconf/finding.html I've been using AC_SEARCH_LIBS, and am currently fixing the configure file, will replace AC_CHECK_LIBS with AC_SEARCH_LIBS. Here is an example for libz: AC_ARG_WITH(zlib, AS_HELP_STRING([--without-zlib], [disable gzip compression support]), with_zlib=$withval, with_zlib=yes) if test $with_zlib != "no"; then AC_SEARCH_LIBS(deflate, z, [with_zlib=yes; AC_DEFINE([WITH_ZLIB], [1], [Use zlib])], [with_zlib=no; AC_MSG_WARN(*** ZLIB was not found. You will not be able to use gzip (de)compression)]) fi Tim --- end quoted text --- -- Thanking You, Darshit Shah pgp4hv4FYck3m.pgp Description: PGP signature
Re: [Bug-wget] [Bug-Wget] Policy on commit messages
On 11/01, Tim Rühsen wrote: Am Samstag, 1. November 2014, 05:43:11 schrieb Darshit Shah: Hi, In the last few days we've seen a huge flurry of activity and a large number of patches have been committed to the code base. As someone who was traveling and hence unable to keep up with the mailing lists, I tried to catch up by looking at the code base and the changes that have been made. It would turn out that the commit messages aren't very informative on the last few commits. Unless I know the context of the change from the mailing list, it would be very difficult to understand why that particular change was important. Both the ChangeLog and commit messages usually only describe the change in literal terms but not in their logical reasoning. I propose that henceforth, all commits be reviewed for detailed descriptions of not only the syntactical changes, but also the logical reasons behind the change. This will help us in the long term to follow through the changes in the code base and also make it easier for new contributors to understand why some things are the way they are. As I understood, for GNU projects we have very detailed ChangeLog entries and thus very short commit messages. The problem with ChangeLogs is that they only specify the changes as a fact. Not the actual logic / reasons behind them which is what we'd like to track in good commit messages. I am not going to make detailed ChangeLog entries AND detailed commit messages. Sure, I personally find it too tedious to write both a ChangeLog and a commit message. If we move to detailed commit messages (I would appreciate it), then we should autogenerate ChangeLog files from the commit messages. You will find many projects out there already doing so. I am all for autogenerating the ChangeLogs. If we can agree upon a frame or method, I would also appreciate a 'reason field' for the changes. If it is not redundant. E.g. a commit message like 'fixing double free()' stands for itself. Precisely what I'm looking for! Tim --- end quoted text --- -- Thanking You, Darshit Shah pgpK1lYgbjl48.pgp Description: PGP signature
Re: [Bug-wget] [Bug-Wget] Policy on commit messages
On 01 Nov 2014 14:05, Tim Rühsen wrote: > Am Samstag, 1. November 2014, 05:43:11 schrieb Darshit Shah: > > In the last few days we've seen a huge flurry of activity and a large number > > of patches have been committed to the code base. As someone who was > > traveling and hence unable to keep up with the mailing lists, I tried to > > catch up by looking at the code base and the changes that have been made. > > > > It would turn out that the commit messages aren't very informative on the > > last few commits. Unless I know the context of the change from the mailing > > list, it would be very difficult to understand why that particular change > > was important. Both the ChangeLog and commit messages usually only describe > > the change in literal terms but not in their logical reasoning. > > > > I propose that henceforth, all commits be reviewed for detailed descriptions > > of not only the syntactical changes, but also the logical reasons behind > > the change. This will help us in the long term to follow through the > > changes in the code base and also make it easier for new contributors to > > understand why some things are the way they are. > > As I understood, for GNU projects we have very detailed ChangeLog entries and > thus very short commit messages. the GNU project ChangeLogs are not useful in git. their intention is to be mechanical and describe what's changed so that in a CVS world, you could easily revert. most GNU projects that have moved to git have also updated their commit message policy to not be useless (although they still hold onto ChangeLogs). some have automated the procedure though so that they put the info into the commit message and then the ChangeLog is generated from that. see coreutils git messages as an example. -mike signature.asc Description: Digital signature
Re: [Bug-wget] [PATCH 5/5] use pkg-config to check gnutls deps if available
On 01 Nov 2014 14:11, Darshit Shah wrote: > If we're to merge these patches, all of them should be squashed into one > since > they all perform the same action. I've merged all the patches into a single > one > and added ChangeLog entry to its right place. If others agree, I'll push this > patch. originally i had the patch merged, but it got to be a pain with the rebasing since no one was pushing it to the main repo. i don't care if it's pushed as one commit or many, but i'm going to keep it split locally & send it out that way since it's less work to maintain it. -mike signature.asc Description: Digital signature
Re: [Bug-wget] Features request
Darshit Shah wrote: On 11/01, taras.malivanc...@totaldefense.com wrote: a case, what would be the expected outcome? Should Wget delete the larger file? Or retain it? It should delete partial file.The full file must not be downloaded , the download will stop when downloaded stuff reaches limit.For example ,/maxsize 10 while downloading 100 Mb file without size in header - stops at 10 Mb and deletes the downloaded chunk. I'm not too sure if this is feature is required. But if you already have it implemented, do share it on this list and we may consider merging it into the codebase. I have it,but in old compilation of version 1.9, will try to compile the last one nderstand. I would suggest you give a concrete example with a real URL and the corresponding filename. It seems like you're on Windows and Wget creates some filename which Windows refuses to create. We may only have to rename the output filenames for Windows in that case. Do provide a precise example so that we can understand the problem better. I will send as I will find one also related to bad names. With -N -O the wget can look at timestamp of file named as written in "-O". Please explain why this is not OK. I don't understand what you're asking for. Could you please be more clear on your position as to why -N and -O have a use-case when used together? The usage is keeping a file up to date when the output provides bad. Either the file cannot be created or working with bad name is not convenient. The process runs automatically periodically.wget -O file.bin -N http://dsjdjfkfkfdfd... - either tells "the file is not newer" or downloads new version.If the download fails - it keeps old file. Then following batches process the data accordingly.
Re: [Bug-wget] [PATCH 1/5] use pkg-config to check zlib deps if available
Darshit Shah writes: > On 10/31, Mike Frysinger wrote: >>On 31 Oct 2014 16:50, Giuseppe Scrivano wrote: >>> Mike Frysinger writes: >>> > Newer versions of these packages ship with pkg-config files, so if we can >>> > detect it via those, do so. If that fails, fall back to the old methods. >>> >>> so far I always tried to stay as far away from pkg-config as possible, >>> but if that is used by distro maintainers then we should probably >>> reconsider it. > > I favour pkg-config too. It would make our lives a lot more simpler. >> >>distro maintainers extremely prefer it over each package doing its own >>(limited >>testing) in build files (i.e. configure) or using legacy xxx-config scripts. >>pkg-config is way more reliable than either of those. >>-mike ok thanks for your opinions. I've added the changelog entries and going to push the series. Regards, Giuseppe
Re: [Bug-wget] [PATCH 1/5] use pkg-config to check zlib deps if available
On 11/01, Giuseppe Scrivano wrote: Darshit Shah writes: On 10/31, Mike Frysinger wrote: On 31 Oct 2014 16:50, Giuseppe Scrivano wrote: Mike Frysinger writes: > Newer versions of these packages ship with pkg-config files, so if we can > detect it via those, do so. If that fails, fall back to the old methods. so far I always tried to stay as far away from pkg-config as possible, but if that is used by distro maintainers then we should probably reconsider it. I favour pkg-config too. It would make our lives a lot more simpler. distro maintainers extremely prefer it over each package doing its own (limited testing) in build files (i.e. configure) or using legacy xxx-config scripts. pkg-config is way more reliable than either of those. -mike ok thanks for your opinions. I've added the changelog entries and going to push the series. I sent out a patch that squashes all the patches into a single one. Since they're logically related, I think we should push them as a single patch. Regards, Giuseppe --- end quoted text --- -- Thanking You, Darshit Shah pgp7r0P7m2p1a.pgp Description: PGP signature
Re: [Bug-wget] [PATCH] Stylistic and idiomatic cleanups in Perl tests
On 11/01, Pär Karlsson wrote: Sorry, my bad. :-/ Amended in new patch attached. Pushed. Thanks for the contribution! -- Thanking You, Darshit Shah pgpvS1LXupKcE.pgp Description: PGP signature
Re: [Bug-wget] [Bug-Wget] Policy on commit messages
Mike Frysinger writes: > On 01 Nov 2014 14:05, Tim Rühsen wrote: >> Am Samstag, 1. November 2014, 05:43:11 schrieb Darshit Shah: >> > In the last few days we've seen a huge flurry of activity and a large >> > number >> > of patches have been committed to the code base. As someone who was >> > traveling and hence unable to keep up with the mailing lists, I tried to >> > catch up by looking at the code base and the changes that have been made. >> > >> > It would turn out that the commit messages aren't very informative on the >> > last few commits. Unless I know the context of the change from the mailing >> > list, it would be very difficult to understand why that particular change >> > was important. Both the ChangeLog and commit messages usually only describe >> > the change in literal terms but not in their logical reasoning. >> > >> > I propose that henceforth, all commits be reviewed for detailed >> > descriptions >> > of not only the syntactical changes, but also the logical reasons behind >> > the change. This will help us in the long term to follow through the >> > changes in the code base and also make it easier for new contributors to >> > understand why some things are the way they are. >> >> As I understood, for GNU projects we have very detailed ChangeLog entries >> and >> thus very short commit messages. > > the GNU project ChangeLogs are not useful in git. their intention is to be > mechanical and describe what's changed so that in a CVS world, you could > easily > revert. most GNU projects that have moved to git have also updated their > commit > message policy to not be useless (although they still hold onto ChangeLogs). > some have automated the procedure though so that they put the info into the > commit message and then the ChangeLog is generated from that. see coreutils > git > messages as an example. > -mike changelogs are crap, not useful to anyone, that is my opinion. We are required to have them because of the GNU Coding standards. I was already having a discussion privately with RMS in these last days trying to change this requirement from the 80', but I had no luck so far. In the meanwhile I had a look at gitlog-to-changelog that is included into gnulib and we should probably move to it, it will save headaches when we have to merge patches. So my proposal is that for now we move more high-level changelog-like messages in the commit message (i.e. no need to document all the minor changes that is easier to get from the code itself) and then generate the ChangeLog file from the current ChangeLog that we we will keep around as read-only + all the commit messages since we decide to move to this new model. The first step is probably to merge all the current ChangeLogs in a single one, in the root directory and then start from there. Regards, Giuseppe
Re: [Bug-wget] broken progressbar in 1.16
Darshit Shah writes: > From 1a29f21bb24c531f450dd59446a0c5a0f7e81110 Mon Sep 17 00:00:00 2001 > From: Darshit Shah > Date: Sat, 1 Nov 2014 05:34:04 +0530 > Subject: [PATCH] Remove extra padding from the progress bar > > --- > src/ChangeLog | 7 +++ > src/progress.c | 7 ++- > 2 files changed, 9 insertions(+), 5 deletions(-) > > diff --git a/src/ChangeLog b/src/ChangeLog > index 58bf905..214441f 100644 > --- a/src/ChangeLog > +++ b/src/ChangeLog > @@ -1,3 +1,10 @@ > +2014-11-01 Darshit Shah > + > + * progress.c (create_image): Extra padding for size_grouped_diff has > already > + been added. Do not add that again. > + (create_image): Assert that the progress bar being drawn is lesser than > the > + size of the screen. > + > 2014-10-29 Peter Meiser (tiny change) > > * openssl.c (ssl_init) [! OPENSSL_NO_SSL3]: Add guard for OpenSSL > diff --git a/src/progress.c b/src/progress.c > index 5ba542d..f211998 100644 > --- a/src/progress.c > +++ b/src/progress.c > @@ -907,10 +907,6 @@ create_image (struct bar_progress *bp, double > dl_total_time, bool done) >char *p = bp->buffer; >wgint size = bp->initial_length + bp->count; > > - const char *size_grouped = with_thousand_seps (size); > - int size_grouped_len = count_cols (size_grouped); > - /* Difference between num cols and num bytes: */ > - int size_grouped_diff = strlen (size_grouped) - size_grouped_len; >int size_grouped_pad; /* Used to pad the field width for size_grouped. */ > >struct bar_progress_hist *hist = &bp->hist; > @@ -1159,9 +1155,10 @@ create_image (struct bar_progress *bp, double > dl_total_time, bool done) >move_to_end (p); > } > > - while (p - bp->buffer - bytes_cols_diff - size_grouped_diff < bp->width) > + while (p - bp->buffer - bytes_cols_diff < bp->width) > *p++ = ' '; >*p = '\0'; > + assert (count_cols(bp->buffer) <= bp->width); > } > > /* Print the contents of the buffer as a one-line ASCII "image" so ACK with a whitespace after "count_cols". Regards, Giuseppe
Re: [Bug-wget] [PATCH 1/5] use pkg-config to check zlib deps if available
Hi Darshit, Darshit Shah writes: > On 11/01, Giuseppe Scrivano wrote: >>Darshit Shah writes: >> >>> On 10/31, Mike Frysinger wrote: On 31 Oct 2014 16:50, Giuseppe Scrivano wrote: > Mike Frysinger writes: > > Newer versions of these packages ship with pkg-config files, so if we > > can > > detect it via those, do so. If that fails, fall back to the old > > methods. > > so far I always tried to stay as far away from pkg-config as possible, > but if that is used by distro maintainers then we should probably > reconsider it. >>> >>> I favour pkg-config too. It would make our lives a lot more simpler. distro maintainers extremely prefer it over each package doing its own (limited testing) in build files (i.e. configure) or using legacy xxx-config scripts. pkg-config is way more reliable than either of those. -mike >> >>ok thanks for your opinions. I've added the changelog entries and >>going to push the series. >> > I sent out a patch that squashes all the patches into a single > one. Since they're logically related, I think we should push them as a > single patch. sorry for pushing it without explaining why. I think it still makes sense to keep them in different patches. Each change in this series is logically complete and the smaller patchs can be, the better it turns in case we need to git bisect the history. Regards, Giuseppe
Re: [Bug-wget] [PATCH 1/5] use pkg-config to check zlib deps if available
On 11/01, Giuseppe Scrivano wrote: Hi Darshit, Darshit Shah writes: On 11/01, Giuseppe Scrivano wrote: Darshit Shah writes: On 10/31, Mike Frysinger wrote: On 31 Oct 2014 16:50, Giuseppe Scrivano wrote: Mike Frysinger writes: > Newer versions of these packages ship with pkg-config files, so if we can > detect it via those, do so. If that fails, fall back to the old methods. so far I always tried to stay as far away from pkg-config as possible, but if that is used by distro maintainers then we should probably reconsider it. I favour pkg-config too. It would make our lives a lot more simpler. distro maintainers extremely prefer it over each package doing its own (limited testing) in build files (i.e. configure) or using legacy xxx-config scripts. pkg-config is way more reliable than either of those. -mike ok thanks for your opinions. I've added the changelog entries and going to push the series. I sent out a patch that squashes all the patches into a single one. Since they're logically related, I think we should push them as a single patch. sorry for pushing it without explaining why. I think it still makes sense to keep them in different patches. Each change in this series is logically complete and the smaller patchs can be, the better it turns in case we need to git bisect the history. That makes sense. Yes. -- Thanking You, Darshit Shah pgpf_SSwqVb_4.pgp Description: PGP signature
Re: [Bug-wget] broken progressbar in 1.16
On 11/01, Giuseppe Scrivano wrote: Darshit Shah writes: From 1a29f21bb24c531f450dd59446a0c5a0f7e81110 Mon Sep 17 00:00:00 2001 From: Darshit Shah Date: Sat, 1 Nov 2014 05:34:04 +0530 Subject: [PATCH] Remove extra padding from the progress bar --- src/ChangeLog | 7 +++ src/progress.c | 7 ++- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/src/ChangeLog b/src/ChangeLog index 58bf905..214441f 100644 --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,10 @@ +2014-11-01 Darshit Shah + + * progress.c (create_image): Extra padding for size_grouped_diff has already + been added. Do not add that again. + (create_image): Assert that the progress bar being drawn is lesser than the + size of the screen. + 2014-10-29 Peter Meiser (tiny change) * openssl.c (ssl_init) [! OPENSSL_NO_SSL3]: Add guard for OpenSSL diff --git a/src/progress.c b/src/progress.c index 5ba542d..f211998 100644 --- a/src/progress.c +++ b/src/progress.c @@ -907,10 +907,6 @@ create_image (struct bar_progress *bp, double dl_total_time, bool done) char *p = bp->buffer; wgint size = bp->initial_length + bp->count; - const char *size_grouped = with_thousand_seps (size); - int size_grouped_len = count_cols (size_grouped); - /* Difference between num cols and num bytes: */ - int size_grouped_diff = strlen (size_grouped) - size_grouped_len; int size_grouped_pad; /* Used to pad the field width for size_grouped. */ struct bar_progress_hist *hist = &bp->hist; @@ -1159,9 +1155,10 @@ create_image (struct bar_progress *bp, double dl_total_time, bool done) move_to_end (p); } - while (p - bp->buffer - bytes_cols_diff - size_grouped_diff < bp->width) + while (p - bp->buffer - bytes_cols_diff < bp->width) *p++ = ' '; *p = '\0'; + assert (count_cols(bp->buffer) <= bp->width); } /* Print the contents of the buffer as a one-line ASCII "image" so ACK with a whitespace after "count_cols". Pushed! -- Thanking You, Darshit Shah pgpBdjbBrqELf.pgp Description: PGP signature
Re: [Bug-wget] broken progressbar in 1.16
On Sat, Nov 01, 2014 at 11:39:55PM +0530, Darshit Shah wrote: > Pushed! Pulled; not there yet: e-flightgear-201411 0%[ ] 1,05M 286KB/s eta 1h 41m wget: progress.c:1161: create_image: Проверочное утверждение «count_cols (bp->buffer) <= bp->width» не выполнено. zsh: abort wget -c (it's [Assertion "count_cols (bp->buffer) <= bp->width" failed] I think) I've filtered the patch to exclude changelog hunk and applied it on top of 1.16 release; the downloaded size is 1168780 of 1599602688 bytes, the image is (my homegrown testing one) http://fly.osdn.org.ua/~mike/iso/tmp/live-flightgear-20141101-x86_64.iso Second run resulted in 1002020 bytes downloaded with the same failure. -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info
[Bug-wget] Fix "end" range check in map_html_tags()
-- *Witchakorn Kamolpornwijit* MIT Class of 2016 Blog: http://chalet16.com Portfolio: http://www6.portfolio.chalet16.com Facebook/Twitter/IRC: chalet16 Skype: chalet1601 0001-Fix-range-check-in-map_html_tags.patch Description: Binary data
