[Bug-wget] pedantic;) spelling patch

[Noël Köthe]

Hello,

attached a small patch against wget.git which fixes:

invokation -> invocation
seperated -> separated

thx.

Regards

Noeldiff --git a/ChangeLog-2014-12-10 b/ChangeLog-2014-12-10
index a48a868..65f6e92 100644
--- a/ChangeLog-2014-12-10
+++ b/ChangeLog-2014-12-10
@@ -729,7 +729,7 @@
 	* testenv/Makefile.am: Run the tests in Python's Optimizedmode
 	* testenv/conf/__init__.py (gen_hook): Use try..except instead of if..else
 	* testenv/misc/color_terminal.py: System and check will not change while a test is
-	run. Do not test for them on every invokation of printer()
+	run. Do not test for them on every invocation of printer()
 	* testenv/server/http/http_server.py: The ssl and re modules are required by
 	specific functions. Load them lazily
 	(HTTPSServer.__init__): Lazy load ssl module here
diff --git a/doc/wget.texi b/doc/wget.texi
index 1e55e63..f6f0fbc 100644
--- a/doc/wget.texi
+++ b/doc/wget.texi
@@ -802,7 +802,7 @@ With @samp{--progress=bar}, there are currently two possible parameters,
 @var{force} and @var{noscroll}.
 
 When the output is not a TTY, the progress bar always falls back to ``dot'',
-even if @samp{--progress=bar} was passed to Wget during invokation. This
+even if @samp{--progress=bar} was passed to Wget during invocation. This
 behaviour can be overridden and the ``bar'' output forced by using the ``force''
 parameter as @samp{--progress=bar:force}.
 
diff --git a/src/main.c b/src/main.c
index e7d5c66..a5617da 100644
--- a/src/main.c
+++ b/src/main.c
@@ -809,7 +809,7 @@ HTTPS (SSL/TLS) options:\n"),
 N_("\
--pinnedpubkey=FILE/HASHES  Public key (PEM/DER) file, or any number\n\
of base64 encoded sha256 hashes preceded by\n\
-   \'sha256//\' and seperated by \';\', to verify\n\
+   \'sha256//\' and separated by \';\', to verify\n\
peer against\n"),
 #if defined(HAVE_LIBSSL) || defined(HAVE_LIBSSL32)
 N_("\
diff --git a/src/options.h b/src/options.h
index a8c494b..85d2de1 100644
--- a/src/options.h
+++ b/src/options.h
@@ -243,7 +243,7 @@ struct options
 
   char *pinnedpubkey;   /* Public key (PEM/DER) file, or any number
of base64 encoded sha256 hashes preceded by
-   \'sha256//\' and seperated by \';\', to verify
+   \'sha256//\' and separated by \';\', to verify
peer against */
 
   char *random_file;/* file with random data to seed the PRNG */
diff --git a/testenv/README b/testenv/README
index 3fee6ad..86c0d74 100644
--- a/testenv/README
+++ b/testenv/README
@@ -130,12 +130,12 @@ The rules object is a dictionary element, with the key as the Rule Name and
 value as the Rule Data. In most cases, the Rule Data is another dictionary.
 
 Various variables used consistently across all tests are:
-* WGET_OPTIONS: The command line string passed to Wget upon invokation. This
+* WGET_OPTIONS: The command line string passed to Wget upon invocation. This
 string may contain URLs, like in the case where in-URL authentication is
 used. Variable names passed like {{var_name}} will be replaced by the
 contents of the variable self.var_name before being passed to Wget
 * WGET_URLS: This is a list of filenames which will be appended as the URLs
-to Wget during invokation. This is a list of lists, where WGET_URLS[0]
+to Wget during invocation. This is a list of lists, where WGET_URLS[0]
 represents the list of Filenames called from Server[0], WGET_URLS[1] is a
 list of files downloaded from Server[2], etc.
 * Files: This variable defines the files that exist in the Server's
@@ -215,7 +215,7 @@ executed. The currently supported options are:
 download. The complete URL will be created and passed to Wget
 automatically. (alias URLs)
 * WgetCommands  : A string consisting of the various commandline switches
-sent to Wget upon invokation. Any data placed between {{ }} in this string
+sent to Wget upon invocation. Any data placed between {{ }} in this string
 will be replaced with the contents of self. before being passed to
 Wget. This is particularly useful for getting the hostname and port for a
 file. While all Download URL's are passed to Urls, a notable exception is
diff --git a/testenv/conf/wget_commands.py b/testenv/conf/wget_commands.py
index 2b7522e..fb379be 100644
--- a/testenv/conf/wget_commands.py
+++ b/testenv/conf/wget_commands.py
@@ -2,7 +2,7 @@ from conf import hook
 
 """ Pre-Test Hook: WgetCommands
 This hook is used to specify the test specific switches that must be passed to
-wget on invokation. Default switches are hard coded in the test suite itself.
+wget on invocation. Default switches are hard coded in the test suite itself.
 """
 
 


signature.asc
Description: This is a digitally signed 

[Bug-wget] segfault in strlen() [was: Re: wget 1.17 segfaults under openSUSE 13.1 (x86_64; glibc 2.18)]

[Noël Köthe]

Hello,

Am Samstag, den 21.11.2015, 00:10 +0100 schrieb Darshit Shah:
> Another thing that I just remembered, this issue seems to pop up when
> the file 
> being downloaded already exists on disk. Maybe, that is why you're
> seeing the 
> different behaviour? 
> 
> Try downloading the file when it already exists and see if the
> problem can be 
> reproduced on the newer system.

I got the following wget 1.17 segfault bug report describing your
point: "wget segfault in strlen()

Starting program: /usr/bin/wget -N http://josm.openstreetmap.de/josm-latest.jar
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x76a2fc9a in strlen () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x77fce780 (LWP 18282)):
#0  0x76a2fc9a in strlen () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x5557d7b7 in set_file_timestamp (hs=0x7fffdbf0) at http.c:2167
filename_len = 140737488347680
filename_plus_orig_suffix = 0x557f6a60 "josm-latest.jar"
local_dot_orig_file_exists = false
local_filename = 0x555997e4  
"\367\320\301\350\037H\213M\370dH3\f%("
st = {st_dev = 2054, st_ino = 9975482, st_nlink = 1, st_mode = 33188, 
  st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, 
  st_size = 10362423, st_blksize = 4096, st_blocks = 20240, st_atim = {
tv_sec = 1447884469, tv_nsec = 0}, st_mtim = {tv_sec = 1447814041, 
tv_nsec = 0}, st_ctim = {tv_sec = 1447884469, 
tv_nsec = 165141734}, __glibc_reserved = {0, 0, 0}}
#2  0x555810bc in http_loop (u=0x55812f30, 
original_url=0x55812f30, newloc=0x7fffdeb8, 
local_file=0x7fffdec0, referer=0x0, dt=0x7fffdfc8, proxy=0x0, 
iri=0x558130f0) at http.c:3888
timestamp_err = 4137853056
count = 0
got_head = false
time_came_from_head = false
got_name = false
tms = 0xd5c 
tmrate = 0x11d 
err = 32767
ret = TRYLIMEXC
tmr = -1
hstat = {len = 0, contlen = 0, restval = 0, res = 0, rderrmsg = 0x0, 
  newloc = 0x0, remote_time = 0x0, error = 0x0, statcode = 0, 
  message = 0x0, rd_size = 0, dltime = 0, referer = 0x0, 
  local_file = 0x0, existence_checked = false, 
  timestamp_checked = false, orig_file_name = 0x0, orig_file_size = 0, 
  orig_file_tstamp = 0}
st = {st_dev = 140733193388032, st_ino = 2358, 
  st_nlink = 140737352679280, st_mode = 4141159968, st_uid = 32767, 
  st_gid = 22, __pad0 = 0, st_rdev = 93824992278048, 
  st_size = 140737488347680, st_blksize = 0, st_blocks = 0, st_atim = {
tv_sec = 140737331241088, tv_nsec = 24}, st_mtim = {
tv_sec = 140737488346992, tv_nsec = 140737488346384}, st_ctim = {
tv_sec = 93824994994784, tv_nsec = 93824995110704}, 
  __glibc_reserved = {-6998084334733230058, 93824994995013, 
93824994994784}}
send_head_first = false
file_name = 0x557f6a60 "josm-latest.jar"
force_full_retrieve = false
#3  0x555916d2 in retrieve_url (orig_parsed=0x55812f30, 
origurl=0x55812fa0 "http://josm.openstreetmap.de/josm-latest.jar", 
file=0x7fffdff8, newloc=0x7fffe000, refurl=0x0, dt=0x7fffdfc8, 
recursive=false, iri=0x558130f0, register_status=true) at retr.c:817
result = NOCONERROR
url = 0x558131f0 "http://josm.openstreetmap.de/josm-latest.jar;
location_changed = false
iri_fallbacked = false
dummy = 0
mynewloc = 0x0
proxy = 0x0
u = 0x55812f30
proxy_url = 0x0
up_error_code = 0
local_file = 0x0
redirection_count = 0
method_suspended = false
saved_body_data = 0x0
saved_method = 0x0
saved_body_file_name = 0x0
#4  0x5558a055 in main (argc=3, argv=0x7fffe228) at main.c:1860
dt = 128
url_err = 32767
filename = 0x0
redirected_URL = 0x0
iri = 0x558130f0
url_parsed = 0x55812f30
url = 0x7fffdf70
t = 0x7fffdf70
p = 0x55812f24 ""
i = 1
ret = -1
longindex = -1
nurl = 1
retconf = -1
argstring_length = 55
use_userconfig = false
noconfig = false
append_to_log = false
timer = 0x55812080
start_time = 4,6101e-07
"

https://bugs.debian.org/805673

Regards

Noël

signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] Bug with czech locales

[Noël Köthe]

Hello Petr,,

Am Dienstag, den 07.04.2015, 11:42 +0200 schrieb Petr Krcmar:
 Hi, I found bug in wget in combination with czech locales cs_CZ.UTF-8 in
 Debian Jessie, but it looks like mainline problem.
 
 When I am downloading files and downloaded file size exceeds one
 megabyte, wget starts breaking lines. It looks like this:
...

This is a known ugly problem in 1.16 https://bugs.debian.org/768110
which got fixed in 1.16.1 and later (latest is 1.16.3).
Debian jessie is frozen since some time (no new upstream releasesare
allowed) and that is the reason why the fixing version didn't moved into
Jessie.
Maybe I can get this fixed after the Jessie release in a point release.


-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] broken progressbar in 1.16

[Noël Köthe]

Hello,

Am Montag, den 03.11.2014, 10:12 +0530 schrieb Darshit Shah:

 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)

 This bug keeps getting more interesting and surprising. While the progress 
 bar 
 draws correctly for the original file you mentioned, the assertion fails with 
 the new ISO (live-flightgear). The funny thing is, this bug is now firing 
 based 
 on the filename of the file being downloaded, which is not something I expect 
 since the filename section of the progress bar is isolated from the rest and 
 should not create such an effect.
 
 I'm going to spend some more time debugging this issue.

I applied the progress bar patch on 1.16 and run into the same problem.

Connecting to fly.osdn.org.ua (fly.osdn.org.ua)|212.40.45.6|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 1599602688 (1.5G), 1590685248 (1.5G) remaining 
[application/octet-stream]
Saving to: 'live-flightgear-20141101-x86_64.iso'

ar-20141101-x86_64.   0%[  ]  12.47M  1.41MB/s 
wget: progress.c:1161: create_image: Assertion `count_cols (bp-buffer) = 
bp-width' failed.

Looks like shipping wget with the broken progress bar because the patch
could stop downloading.
Maybe the default could be the old but stable progress bar and when the
new feature works it could be changed to the new default?

Regards

Noël


signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] certificate revocation lists (CRLs) #43501

[Noël Köthe]

Hello Debian,;)

wget developers are working on CRL support and raised the following
questions which somebody of you guys have a better answer:

Am Mittwoch, den 05.11.2014, 12:48 +0100 schrieb Tim Ruehsen:

 BTW, does Debian meanwhile has a CRL infrastructure (something like 
 /etc/ssl/certs/) or is planning something like it ?

I'm aware of fetch-crl
https://packages.debian.org/unstable/main/fetch-crl but maybe there is
more anything planed like CRL support for the ca-certificates package?


Thx.

Regards

Noël

-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] certificate revocation lists (CRLs) #43501

[Noël Köthe]

Hello Tim,

Am Mittwoch, den 05.11.2014, 12:48 +0100 schrieb Tim Ruehsen:

  https://savannah.gnu.org/bugs/?43501
  
  The first step could to document (IMHO prefered in the manpage) this
  behavior (see attached first ugly patch because I don't know where to
  place this better).
  
  The next and better step might be to implement this by loading CRLs
  files (reporter points to curl where this is possible) then this patch
  should be removed again.

 On 24th Oct I pushed a change to Mget that allows to specify a CRL file via
 --crl-file. If nobody complains, I would fit that patch to Wget's GnuTLS code.

:) That you be perfect for this request.

 BTW, does Debian meanwhile has a CRL infrastructure (something like 
 /etc/ssl/certs/) or is planning something like it ?

I'm not aware of an infrastructure but asked the people who might know
this (CC: to this list).

 Also, OCSP certificate status checking might be interesting for Wget.

:) ACK.

Thank you.

Regards

Noël

-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] wget alpha release 1.14.96-38327

[Noël Köthe]

Hello,

Am Dienstag, den 24.12.2013, 18:06 +0100 schrieb Giuseppe Scrivano:

  I could drop 3 documentation patches.
  The Debian bugtracker does not have additional patches.
  I don't track which wget upstream patch fixed which Debian bug if this
  is your request.
 
 would you mind to send the patches to the ML, either by git send-email
 or attaching the output git format-patch?  It helps to get more eyes on
 them.
 Get these patches upstream will make things easier for you as well, you
 will have less stuff to rebase when a new version is out.

Sure, but the 3 additional patches are included in 1.14.96-38327.
wget release 1.14 in Debian is carrying the following patches:
http://patch-tracker.debian.org/package/wget/1.14-5
and the 1.14.96-38327 reduces them by 3:
http://patch-tracker.debian.org/package/wget/1.14.96.38327-2
They are only documentation patches. I hope I didn't misunderstand your
request again.

  Maybe only a small documentation fix but its minor.
  https://savannah.gnu.org/bugs/index.php?33826
 
  As a friend of release early and release often:
  Go for it;) and the wget user will get a lot of fixes from the 16 month
  of development.
 
 we definitely need a better model than let's release when we think it
 is ok :-)
 
 Should we move to a release every 3/6 months?

12 month would be fine too but I don't have a strong option on this.

 I don't think that doing it more often would make any sense, given the
 activity that usually wget has.

ACK.

-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part

[Bug-wget] Debian wget bug #701032 and #709637 [was: Re: wget alpha release 1.14.96-38327]

[Noël Köthe]

Hello,

Am Mittwoch, den 25.12.2013, 01:13 +0530 schrieb Darshit Shah:

  I tried going through the Debian bugtracker just now. Didn't see any
 patches available
 which haven't already been applied. However there are a couple of bug
 reports on it
 that we must look into. I'll try and reproduce them if possible.
 Specifically, I'm
 looking at bug reports #701032 and #709637.

:) Good.

 @nok: It would be very nice of you if you could report these as bugs in the
 upstream
 bug tracker. I know they're both marked as non-reproducible in your system.
 While
 I'll attempt to reproduce #701032, there seems to be a definite bug in wget
 based on
 the extensive logs provided in #709637.

Sure.
http://bugs.debian.org/709637 wget: Credentials in URL not supported
(server depended) is now here:
https://savannah.gnu.org/bugs/index.php?41002
and
http://bugs.debian.org/701032 wget tries to reuse connection despite
http/1.0 and no connection: keep-alive you find here:
https://savannah.gnu.org/bugs/index.php?41003

Have a nice day

Noël


signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] wget alpha release 1.14.96-38327

[Noël Köthe]

Hello,

Am Sonntag, den 22.12.2013, 13:21 +0100 schrieb Giuseppe Scrivano:

  @Noel: Could you please elaborate on the patches that fixes bugs in
  your bugtracker?

Building this pre 1.15 wget with gnutls 3.2 fixes alot of https
problems. In detail you can see the the fixed Debian bug list here:

http://ftp-master.metadata.debian.org/changelogs/main/w/wget/experimental_changelog

I could drop 3 documentation patches.
The Debian bugtracker does not have additional patches.
I don't track which wget upstream patch fixed which Debian bug if this
is your request.

  If anything needs fixing, I'd like to help and ensure a new release
  ASAP.

Maybe going through https://savannah.gnu.org/bugs/?group=wget in some
spare time and comment, tag, close some bugs.:) e.g. bug #36580 just
need a person with the right savannah account/permissions (nok does not
have;)).

 I've delayed it since there were some new bug reports and I had no time
 to go trough all of them.  From a first check, it seems there is nothing
 blocking a release, so I will probably do that in the next few days.
 
 Is there something we should absolutely consider for inclusion before we
 make a new release?

Maybe only a small documentation fix but its minor.
https://savannah.gnu.org/bugs/index.php?33826

As a friend of release early and release often:
Go for it;) and the wget user will get a lot of fixes from the 16 month
of development.

Thanks for your work!

Regards

Noel

-- 
Noël Köthe n...@debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] wget alpha release 1.14.96-38327

[Noël Köthe]

Hello,

Am Samstag, den 02.11.2013, 13:32 +0100 schrieb Giuseppe Scrivano:

 I have just uploaded an alpha release for wget.  If no blocking errors
 are found, then I will make an official release in the coming weeks
 (that is, wget 1.15).

I uploaded this alpha to our experimental tree and it builds and works
so far fine.

https://buildd.debian.org/status/package.php?p=wgetsuite=experimental
(to see details click in the Status row)

I could removed 4 patches and it fixes 8 bugs in the Debian bugtracker.

Maybe a low hanging fruit might be:)

https://savannah.gnu.org/bugs/index.php?33826


-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part

Re: [Bug-wget] Latex source code for Wget's instruction manual

[Noël Köthe]

Hello,

Am Montag, den 01.04.2013, 20:53 -0700 schrieb RJ:
 Is it possible to get a copy of the Latex source code for the Wget
 instruction manual?
 I would like to print a few copies for instructional purposes, but
 need to first compile in a smaller font.

It is the source code in the doc/ directory wget.texi or in git
http://git.savannah.gnu.org/cgit/wget.git/tree/doc

Or do you mean an other manual?

-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org


signature.asc
Description: This is a digitally signed message part

[Bug-wget] patches for TLS SNI support and --match-query-string option

[Noël Köthe]

Hello,

there are two patches in the wget bug tracker which are requested by
some users.
Are there any problems with them or can they be included in trunk?

TLS SNI support
https://savannah.gnu.org/bugs/?26786

--match-query-string option
https://savannah.gnu.org/bugs/?31147

Thank you.

-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org

[Bug-wget] next wget release?

[Noël Köthe]

Hello,

I don't want to pester with this question but when is the next wget
release planed? 1.12 was released 2009-09-22 and since then there were
some bugfixes and patches integrated in the VCS but they do not reach
the user.

Thank you.


-- 
Noël Köthe noel debian.org
Debian GNU/Linux, www.debian.org



signature.asc
Description: This is a digitally signed message part