Re: [Bug-wget] wget chrasches.

Hi Nils, did you try wget from https://eternallybored.org/misc/wget/ ? If you create an account for me and send me the credentials via PM, I could test it from GNU/Linux and from wine emulation. Otherwise, you possibly can try the command line from Linux, just to see if it's a WIN32 or a

[Bug-wget] wget chrasches.

Hi, We have problem with wget. It chrasches just when you think that the file is downloadad. Version see below: Problem, see attachment. We have also tried orher versions , both 32 and 64 bit and v 1.90, but the problem exists in all versions. The version: D:\Test Deletas\Navteq\Utils>wget -V

Re: [Bug-wget] Wget 1.20.3 timestamp behavior doesn't match the one described on the manual

On 15/08/19 14:32, Tim Rühsen wrote: > On 8/15/19 2:23 PM, Dalme wrote: >>> Are you saying that wget sends a wrong date with the If-Modified-Since >>> header ? If so it's a bug on our side. Maybe you can come up with more >>> details (--debug output). >> No, sorry. What I'm trying to say is

Re: [Bug-wget] Wget 1.20.3 timestamp behavior doesn't match the one described on the manual

On 8/15/19 2:23 PM, Dalme wrote: > >> Are you saying that wget sends a wrong date with the If-Modified-Since >> header ? If so it's a bug on our side. Maybe you can come up with more >> details (--debug output). > No, sorry. What I'm trying to say is that when you take a look on the > wget manual

Re: [Bug-wget] Wget 1.20.3 timestamp behavior doesn't match the one described on the manual

> Are you saying that wget sends a wrong date with the If-Modified-Since > header ? If so it's a bug on our side. Maybe you can come up with more > details (--debug output). No, sorry. What I'm trying to say is that when you take a look on the wget manual at gnu.org of '-N' mode you find "Turn

Re: [Bug-wget] Wget 1.20.3 timestamp behavior doesn't match the one described on the manual

On 8/14/19 9:07 PM, Dalme wrote: > From the wget manual (at > https://www.gnu.org/software/wget/manual/wget.html#Time_002dStamping): > "If the local file does not exist, or the sizes of the files do not > match, Wget will download the remote file no matter what the time-stamps > say." However,

[Bug-wget] Wget 1.20.3 timestamp behavior doesn't match the one described on the manual

>From the wget manual (at https://www.gnu.org/software/wget/manual/wget.html#Time_002dStamping): "If the local file does not exist, or the sizes of the files do not match, Wget will download the remote file no matter what the time-stamps say." However, using Wget 1.20.3 it only downloads the

Re: [Bug-wget] Wget 1.20.3 on Solaris

On 5/7/19 6:34 PM, Jeffrey Walton wrote: > On Mon, May 6, 2019 at 2:01 PM Tim Rühsen wrote: >> ... >> >> Please try this patch and report back: >> diff --git a/testenv/Makefile.am b/testenv/Makefile.am >> index b5a39ad2..5150d4ac 100644 >> --- a/testenv/Makefile.am >> +++ b/testenv/Makefile.am

[Bug-wget] Wget at the GNU Hacker's Meet (GHM), 2019

Hi Everyone, Do you GNU? Attend the GNU Hackers' Meeting in Madrid this summer! Twelve years after it's first edition in Orense, the GHM is back to Spain! This time, we will be gathering in the nice city of Madrid for hacking, learning and meeting each other. The GNU Hackers' Meeting is a

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Mon, May 6, 2019 at 2:01 PM Tim Rühsen wrote: > ... > > Please try this patch and report back: > diff --git a/testenv/Makefile.am b/testenv/Makefile.am > index b5a39ad2..5150d4ac 100644 > --- a/testenv/Makefile.am > +++ b/testenv/Makefile.am > @@ -123,5 +123,5 @@ endif > EXTRA_DIST = certs

Re: [Bug-wget] Wget 1.20.3 on Solaris

On 05.05.19 05:26, Jeffrey Walton wrote: > On Fri, May 3, 2019 at 4:11 AM Tim Rühsen wrote: >> >> On 5/2/19 6:12 PM, Jeffrey Walton wrote: >>> On Thu, May 2, 2019 at 8:12 AM Darshit Shah wrote: ... However, this _is_ a bug. Since if you see testenv/Makefile.am, we have a

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Fri, May 3, 2019 at 4:11 AM Tim Rühsen wrote: > > On 5/2/19 6:12 PM, Jeffrey Walton wrote: > > On Thu, May 2, 2019 at 8:12 AM Darshit Shah wrote: > >> ... > >> However, this _is_ a bug. Since if you see testenv/Makefile.am, we have a > >> `HAVE_PYTHON3` conditional block. And configure also

Re: [Bug-wget] Wget 1.20.3 on Solaris

On 5/2/19 6:12 PM, Jeffrey Walton wrote: > On Thu, May 2, 2019 at 8:12 AM Darshit Shah wrote: >> ... >> However, this _is_ a bug. Since if you see testenv/Makefile.am, we have a >> `HAVE_PYTHON3` conditional block. And configure also checks for it. You are right, there is /usr/bin/python3.4

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Thu, May 2, 2019 at 8:12 AM Darshit Shah wrote: > ... > However, this _is_ a bug. Since if you see testenv/Makefile.am, we have a > `HAVE_PYTHON3` conditional block. And configure also checks for it. > > This is why I am interested in seeing the contents of your config.log file. I > would like

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Thu, May 2, 2019 at 11:34 AM Jeffrey Walton wrote: > > On Thu, May 2, 2019 at 9:13 AM Tim Rühsen wrote: > > > > On 5/2/19 2:15 PM, Darshit Shah wrote: > > > That is a terrible suggestion. Please don't do that or suggest it. > > > I'm sure Jeffrey here is capable of knowing what this is and

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Thu, May 2, 2019 at 9:13 AM Tim Rühsen wrote: > > On 5/2/19 2:15 PM, Darshit Shah wrote: > > That is a terrible suggestion. Please don't do that or suggest it. > > I'm sure Jeffrey here is capable of knowing what this is and what the > > implications of such a binary are. > > I wouldn't call

Re: [Bug-wget] Wget 1.20.3 on Solaris

On 5/2/19 2:15 PM, Darshit Shah wrote: > That is a terrible suggestion. Please don't do that or suggest it. > I'm sure Jeffrey here is capable of knowing what this is and what the > implications of such a binary are. I wouldn't call it 'terrible', but it's definitely not a good idea for

Re: [Bug-wget] Wget 1.20.3 on Solaris

On 5/2/19 2:12 PM, Darshit Shah wrote: > * Tim Rühsen [190502 10:21]: >> On 5/2/19 10:02 AM, Jeffrey Walton wrote: >>> On Thu, May 2, 2019 at 4:00 AM Tim Rühsen wrote: Hi Jeff, On 5/1/19 11:38 PM, Jeffrey Walton wrote: > On Wed, May 1, 2019 at 3:51 PM Tim Rühsen wrote:

Re: [Bug-wget] Wget 1.20.3 on Solaris

That is a terrible suggestion. Please don't do that or suggest it. I'm sure Jeffrey here is capable of knowing what this is and what the implications of such a binary are. However, this is a publicly archived mailing list. People will find this when they search the web in the future (not

Re: [Bug-wget] Wget 1.20.3 on Solaris

* Tim Rühsen [190502 10:21]: > On 5/2/19 10:02 AM, Jeffrey Walton wrote: > > On Thu, May 2, 2019 at 4:00 AM Tim Rühsen wrote: > >> > >> Hi Jeff, > >> > >> On 5/1/19 11:38 PM, Jeffrey Walton wrote: > >>> On Wed, May 1, 2019 at 3:51 PM Tim Rühsen wrote: > > could you post e.g. the

Re: [Bug-wget] Wget 1.20.3 on Solaris

On 5/2/19 10:09 AM, Tim Rühsen wrote: > On 5/2/19 10:02 AM, Jeffrey Walton wrote: >> On Thu, May 2, 2019 at 4:00 AM Tim Rühsen wrote: >>> >>> Hi Jeff, >>> >>> On 5/1/19 11:38 PM, Jeffrey Walton wrote: On Wed, May 1, 2019 at 3:51 PM Tim Rühsen wrote: > > could you post e.g. the

Re: [Bug-wget] Wget 1.20.3 on Solaris

On 5/2/19 10:02 AM, Jeffrey Walton wrote: > On Thu, May 2, 2019 at 4:00 AM Tim Rühsen wrote: >> >> Hi Jeff, >> >> On 5/1/19 11:38 PM, Jeffrey Walton wrote: >>> On Wed, May 1, 2019 at 3:51 PM Tim Rühsen wrote: could you post e.g. the content of tests/Test-504.log ? >>> >>> Yes,

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Thu, May 2, 2019 at 4:00 AM Tim Rühsen wrote: > > Hi Jeff, > > On 5/1/19 11:38 PM, Jeffrey Walton wrote: > > On Wed, May 1, 2019 at 3:51 PM Tim Rühsen wrote: > >> > >> could you post e.g. the content of tests/Test-504.log ? > > > > Yes, attached. > > > > Do you want an account on the box. I

Re: [Bug-wget] Wget 1.20.3 on Solaris

Hi Jeff, On 5/1/19 11:38 PM, Jeffrey Walton wrote: > On Wed, May 1, 2019 at 3:51 PM Tim Rühsen wrote: >> >> could you post e.g. the content of tests/Test-504.log ? > > Yes, attached. > > Do you want an account on the box. I keep it around for testing, and I > can make you admin. You can

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Wed, May 1, 2019 at 6:56 PM Darshit Shah wrote: > > The error seems to arise from a missing python3 binary on the test machine. > > I do remember that we added a check for this to our build script to deal with > this issue. I wonder why it is broken on your machine. Could you also please >

Re: [Bug-wget] Wget 1.20.3 on Solaris

The error seems to arise from a missing python3 binary on the test machine. I do remember that we added a check for this to our build script to deal with this issue. I wonder why it is broken on your machine. Could you also please share the config.log file that is generated? Anyways, a quick fix

Re: [Bug-wget] Wget 1.20.3 on Solaris

On Wed, May 1, 2019 at 3:51 PM Tim Rühsen wrote: > > could you post e.g. the content of tests/Test-504.log ? Yes, attached. Do you want an account on the box. I keep it around for testing, and I can make you admin. You can connect to it with 'ssh trushen@151.196.22.177'. If so, send over your

Re: [Bug-wget] Wget 1.20.3 on Solaris

Hi Jeff, could you post e.g. the content of tests/Test-504.log ? I guess it is more of a path issue or a missing perl module. Regards, Tim On 01.05.19 21:35, Jeffrey Walton wrote: > Hi Everyone, > > Below is the result of running 'make check' on Solaris 11.3. The > previous self tests were

[Bug-wget] Wget 1.20.3 on Solaris

Hi Everyone, Below is the result of running 'make check' on Solaris 11.3. The previous self tests were OK. The only problem are the ones below. I'm hazarding a guess it is an ancient version of Perl: $ perl --version This is perl 5, version 12, subversion 5 (v5.12.5) built for

[Bug-wget] wget-1.20-win32

Hi, I'm using wget-1.20-win32 (not wget-1.20.3-win32 because there is a problem). During download, there is a problem with the "scrolling" name, the last character character of the name is repeated some time : Kind regards Walter

[Bug-wget] wget-1.20.3 released [stable]

Please find below the new release of GNU Wget. It fixes a buffer overflow vulnerability which was reported to us by JPCERT. Here are the compressed sources and a GPG detached signature[*]: https://ftp.gnu.org/gnu/wget/wget-1.20.3.tar.gz https://ftp.gnu.org/gnu/wget/wget-1.20.3.tar.gz.sig Use

Re: [Bug-wget] [Wget-dev] wget option "bind-address" is not working for virtual interface (eth1.0)

Hi Tim, Thanks for your quick response and following is command used to create virtual interface. ip link add name eth1.0 link eth1 type macvlan thank you! Best Regards Babu On Mon, 1 Apr 2019 at 19:34, Tim Rühsen wrote: > Hi Babu, > > please respond to the mailing list, so

[Bug-wget] wget-1.20.2 released [stable]

Wget 1.20.2 has been released. There are no major user facing changes. This release was made possible thanks to the work of: André Wolski Darshit Shah Jeffrey Walton Leon Klingele Nam Nguyen Simon Dales Tim Rühsen Here are the compressed sources and a GPG detached signature[*]:

Re: [Bug-wget] [Wget-dev] wget option "bind-address" is not working for virtual interface (eth1.0)

Hi Babu, please respond to the mailing list, so everybody can read and learn. For me to reproduce: How do you set up the virtual interface (e.g. command line) How exactly looks your ping command line like ? Regards, Tim On 4/1/19 3:55 PM, Babu Prasad wrote: > Hi Tim, thanks for your response,

Re: [Bug-wget] [Wget-Bug][PATCH] Disable automatic wget headers

ourse the previous patch will be modified. > > > Envoyé à partir de Outlook<http://aka.ms/weboutlook> > > > > De : Darshit Shah > Envoyé : vendredi 15 mars 2019 11:18 > À : adham elkarn > Cc : elkarni...@hotmail.fr; bu

[Bug-wget] [Wget-Bug][PATCH] Disable automatic wget headers

From: a-elk Disable automatic wget headers. *options.h: added no-headers member *http.c: removed default headers *main.c: added new option noheaders, added help description *init.c: adde new option noheaders >From bug #54769 (https://savannah.gnu.org/bugs/?54769). Some servers doesn't handle

Re: [Bug-wget] wget -crNl inf --- filenames mangled

On 2/18/19 12:02 AM, Andres Valloud wrote: > Hi, so I ran wget like this: > > wget --no-check-certificate -dcrNl inf $baseUrl/root/pub/mods/2012/ -P > $baseLocal -o wget-mods-2012.log > > Looking at the log, '1f43' appears (I think) as a consequence of -l inf, > because .../mods/2012/ has a

Re: [Bug-wget] wget -crNl inf --- filenames mangled

Hi, so I ran wget like this: wget --no-check-certificate -dcrNl inf $baseUrl/root/pub/mods/2012/ -P $baseLocal -o wget-mods-2012.log Looking at the log, '1f43' appears (I think) as a consequence of -l inf, because .../mods/2012/ has a reference to .../mods/, which leads wget to read the

Re: [Bug-wget] wget -crNl inf --- filenames mangled

On 16.02.19 23:02, Andres Valloud wrote: > Tim, > > I limited the data from 99gb to 3.3gb, and just to the directory where > I've seen the problem occurs.  The strange string '1f43' appears in this > limited setup.  The '1f43' substring seems to appear deterministically > depending on the file

Re: [Bug-wget] wget -crNl inf --- filenames mangled

On 2/14/19 12:25 PM, Andres Valloud wrote: > Tim, > > On 2/14/19 02:03, Tim Rühsen wrote: >>> I looked at the downloaded html files with grep.  They do contain the >>> substring "1f43", seemingly after a ^M character (I did not check every >>> single occurrence).  Sometimes, the ^M character is

Re: [Bug-wget] wget -crNl inf --- filenames mangled

Tim, On 2/14/19 02:03, Tim Rühsen wrote: I looked at the downloaded html files with grep.  They do contain the substring "1f43", seemingly after a ^M character (I did not check every single occurrence).  Sometimes, the ^M character is within a file name such as this:

[Bug-wget] Wget results VERY different from browser save

On closer inspection, I've found that the results from Wget and Firefox are very different. Neither is perfect, but the Wget results are definitely wrong. Here are the results from both: = wget --append-output=Wget_Google.log --show-progress

[Bug-wget] wget-1.20.1 released [stable]

Hi, due to some privacy issues in default settings of Wget, we introduce this bugfix release. The --xattr option (saving original URL and Referer into extended file attributes) was introduced and enabled by default since Wget 1.19. It possibly saved - possibly unrecognized by the user -

[Bug-wget] wget-1.20 released [stable]

We are pleased to announce the release of GNU Wget 1.20. GNU Wget is a free utility for non-interactive download of files from the Web. It supports HTTP(S), and FTP(S) protocols, as well as retrieval through HTTP proxies. This is a small release with some bugfixes and a few quality of life

Re: [Bug-wget] Wget running out of memory

Hi Giovanni, On 9/24/18 7:38 AM, Giovanni Porta wrote: > Hello all, > > For the past week or so, I've been attempting to mirror a website with Wget. > However, after a couple days of downloading (and approx 38 GB downloaded), > Wget eventually exhausts all system memory and swap leading to the

[Bug-wget] Wget running out of memory

Hello all, For the past week or so, I've been attempting to mirror a website with Wget. However, after a couple days of downloading (and approx 38 GB downloaded), Wget eventually exhausts all system memory and swap leading to the process getting killed. The server I'm using has 2GB of RAM and

Re: [Bug-wget] Wget localtime bug in 1.19.5

Hi Sam, thanks for the report. The problem might be fixed in upstream gnulib already. May I send you a tarball with everything up-to-date for testing ? BTW, s...@bingner.com doesn't seem to be a valid account (invalid DNS MX or A/ resource record). Please let me know where to send the

[Bug-wget] Wget localtime bug in 1.19.5

I had wget crashing when I compiled for iOS and tracked down the problem to be the rpl_localtime using the macro for localtime so it resolved to: struct tm * rpl_localtime (time_t const *timep) { struct tm *tm = rpl_localtime (timep); This is because it has "-I ../src" in the CFLAGS so that

Re: [Bug-wget] wget in a 'dynamic' pipe

Paul Wagner writes: > That's what the OP thinks, too. I attributed the slow startup to DNS > resolution. Depending on your circumstances, one way to fix that is set up a local caching-only DNS server. Direct ordinary processes to use that. Then the first lookup is expensive, but the caching

Re: [Bug-wget] wget in a 'dynamic' pipe

Dear all, On 12.09.2018 03:51, wor...@alum.mit.edu wrote: Tim Rühsen writes: Thanks for the pointer to coproc, never heard of it ;-) (That means I never had a problem that needed coproc). Anyways, copy the script results in a file '[1]' with bash 4.4.23. Yeah, I'm not surprised there are

Re: [Bug-wget] wget in a 'dynamic' pipe

Tim Rühsen writes: > Thanks for the pointer to coproc, never heard of it ;-) (That means I > never had a problem that needed coproc). > > Anyways, copy the script results in a file '[1]' with bash 4.4.23. Yeah, I'm not surprised there are bugs in it. > Also, wget -i - waits with downloading

Re: [Bug-wget] wget in a 'dynamic' pipe

On 9/11/18 5:34 AM, Dale R. Worley wrote: > Paul Wagner writes: >> Now I tried >> >>{ i=1; while [[ $i != 100 ]]; do echo >> "http://domain.com/path/segment_$((i++)).mp4"; done } | wget -O foo.mp4 >> -i - >> >> which works like a charm *as long as the 'generator process' is finite*, >>

Re: [Bug-wget] wget in a 'dynamic' pipe

Paul Wagner writes: > Now I tried > >{ i=1; while [[ $i != 100 ]]; do echo > "http://domain.com/path/segment_$((i++)).mp4"; done } | wget -O foo.mp4 > -i - > > which works like a charm *as long as the 'generator process' is finite*, > i.e. the loop is actually programmed as in the example.

Re: [Bug-wget] wget wait_ares void value not ignored

Thanks, it has been remove on 8th of March 2018 (commit 7eff94e881b94d119ba22fc0c29edd65f4e6798b) Regards, Tim On 08/24/2018 09:39 AM, Endre Hagelund wrote: > Hi > > I've encountered a bug when compiling wget 1.19.5 from source with the > following command: > > ./configure --with-cares &&

[Bug-wget] wget wait_ares void value not ignored

Hi I've encountered a bug when compiling wget 1.19.5 from source with the following command: ./configure --with-cares && make Compile fails with the following error message: host.c: In function 'wait_ares' host.c:735:11: error: void value not ignored as it ought to be timer = ptimer_destroy

Re: [Bug-wget] wget in a 'dynamic' pipe

On 19.07.2018 17:24, Paul Wagner wrote: > Dear wgetters, > > apologies if this has been asked before. > > I'm using wget to download DASH media files, i.e. a number of URLs in > the form domain.com/path/segment_1.mp4, domain.com/path/segment_2.mp4, > ..., which represent chunks of audio or

[Bug-wget] wget in a 'dynamic' pipe

Dear wgetters, apologies if this has been asked before. I'm using wget to download DASH media files, i.e. a number of URLs in the form domain.com/path/segment_1.mp4, domain.com/path/segment_2.mp4, ..., which represent chunks of audio or video, and which are to be combined to form the whole

[Bug-wget] Wget keeps crashing on me

it seems that Wget keeps crashing in Windows sometimes when the filename is large enough to scroll it. On 15 May 2017 01:25:25 +0200 , Jernej Simončič wrote: >I thought about the progress bar, since it does behave a bit weird on >Windows - specifically, if the filename is scrolling, once

Re: [Bug-wget] Wget on Windows handling of wildcards

> From: Sam Habiel > Date: Wed, 6 Jun 2018 08:27:44 -0400 > Cc: bug-wget@gnu.org > > Is there a valid argument to be made that some arguments for wget > should not be expanded, like accept and reject? Probably. The problem is that wildcard expansion of the command line doesn't understand the

Re: [Bug-wget] Wget on Windows handling of wildcards

Gisle, I downloaded it from here: https://eternallybored.org/misc/wget/. It doesn't seem to be MinGW compiled; but I can't tell. Eli, Holy shit it works! I spent several hours trying different combinations--but never came up with this incantation! Thank you so much! Is there a valid argument

Re: [Bug-wget] Wget on Windows handling of wildcards

> From: Sam Habiel > Date: Tue, 5 Jun 2018 14:16:27 -0400 > > I have a wget command that has a -A flag that contains a wildcard. > It's '*.DAT'. That works fine on Linux. I am trying to get the same > thing to run on Windows, but *.DAT keeps getting expanded by wget (cmd > does no expansion

[Bug-wget] Wget on Windows handling of wildcards

First time poster. I have a wget command that has a -A flag that contains a wildcard. It's '*.DAT'. That works fine on Linux. I am trying to get the same thing to run on Windows, but *.DAT keeps getting expanded by wget (cmd does no expansion itself). There is no way that I found of suppressing

Re: [Bug-wget] Wget follows "button" links

Hi, > "Both --no-clobber and --convert-links were specified, only --convert-links will be used." Right, I missed that. The combination of both flags was buggy by design (also in 1.12) and suffered from several flaws (not to say bugs). Regex more like '.*/xpage=watch.*'. The exact syntax depends

Re: [Bug-wget] Wget follows "button" links

Hey Tim, Please see http://savannah.gnu.org/bugs/?31781 where it implemented. Since version 1.12.1. On my personal mac I have 1.19.5, and when I run the command with both arguments i get: "Both --no-clobber and --convert-links were specified, only --convert-links will be used." As a

Re: [Bug-wget] Wget follows "button" links

Hi, in this case you could try it with -X / --exclude-directories. E.g. wget -X /delete,/remove That wouldn't help with "xpage=watch..." though. And I can't tell you if and how good -X works with wget 1.12. Why (or since when) doesn't --no-clobber plus --convert-links work any more ? Please

Re: [Bug-wget] Wget follows "button" links

Hey Tim, Thanks for the info. The wiki software we use (xwiki) appends something to wiki pages URLs to express a certain behavior. For example, to "watch" a page, the button once pressed redirects you to "www.wiki.com/WIKI-PAGE-NAME?xpage=watch=adddocument" Where the only thing that changes

Re: [Bug-wget] Wget follows "button" links

On 06/05/2018 11:53 AM, CryHard wrote: > Hey there, > > I've used the following: > > wget --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36" > --user=myuser --ask-password --no-check-certificate --recursive

Re: [Bug-wget] Wget for WIndows download

On 15.05.2018 13:48, Graeme wrote: > I am trying to find the up to date version of Wget for Windows. > > On https://www.gnu.org/software/wget/faq.html#download there are 4 links. > > Sourceforge and Bart Puype links seem to be dead links. > > Christopher Lewis' link times out. > > Jernej

[Bug-wget] Wget for WIndows download

I am trying to find the up to date version of Wget for Windows. On https://www.gnu.org/software/wget/faq.html#download there are 4 links. Sourceforge and Bart Puype links seem to be dead links. Christopher Lewis' link times out. Jernej Simoncic's link works but the files don't seem to have

Re: [Bug-wget] Wget not ignoring the return value of a void function in 1.19.5

On 05/08/2018 09:16 AM, Josef Moellers wrote: > Hi, > > While trying to upgrade to 1.19.5, we found a bug in wget (src/host.c) > where the (non-existing) return value of a void function is assigned to > a variable. > > A patch is appended. Thanks, setting timer to NULL is not needed here.

[Bug-wget] Wget not ignoring the return value of a void function in 1.19.5

Hi, While trying to upgrade to 1.19.5, we found a bug in wget (src/host.c) where the (non-existing) return value of a void function is assigned to a variable. A patch is appended. Josef Index: wget-1.19.5/src/host.c === ---

Re: [Bug-wget] wget 1.18-5+deb9u1 with --hsts -E -k fails

Hi Karl, Thanks! That's a pretty detailed bug report. Definitely helpful :) 1. Yes, I'm aware of the issue. Even 1.20 is not listed on it. I'll get right on fixing that ASAP. 2. and 3. These are a little more involved than I have the time to look into for now. It does seem like it is

[Bug-wget] wget 1.18-5+deb9u1 with --hsts -E -k fails

Hello, This is a bad bug report. Sorry. I'm thinking that you'd rather hear _something_ than nothing. I'm using wget 1.18-5+deb9u1, which is 1.18 on Debian Squeeze (9.4). I can't say I'm certain that there is even a bug, although there is a functionality problem at some level. 3 different

Re: [Bug-wget] wget 1.19.4 - possible double free in url.c

On 03/01/2018 03:01 PM, Volkmar Klatt wrote: > Dear wget maintainer, > > 1) in wget 1.19.4 (and probably earlier) > please check carefully > > static char * convert_fname (char *fname) > in > src/url.c > > I run a OpenBSD machine, x86, ABI=32 > and I guess there's a double free when using

[Bug-wget] wget 1.19.4 - possible double free in url.c

Dear wget maintainer, 1) in wget 1.19.4 (and probably earlier) please check carefully static char * convert_fname (char *fname) in src/url.c I run a OpenBSD machine, x86, ABI=32 and I guess there's a double free when using iconv, see patch attached. With this change, all my non-skipped tests

Re: [Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download

Am Freitag, den 02.02.2018, 16:28 +0100 schrieb rosario.contar...@esa.int: > Hi Tim, > > with --with-ssl=openssl compiled and ran. That's good to hear :-) > Unfortunately it still not working: > > /home/coadmin/temp/wget-project/wget-1.14/src/wget -v --debug https: >

Re: [Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download

: bug-wget@gnu.org, i...@ssa.esa.int Date: 02/02/2018 16:13 Subject: Re: [Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download Hi Rosario, Am Freitag, den 02.02.2018, 14:53 +0100 schrieb rosario.contar...@esa.int: > HI Tim, > > Thank you for your pointer. >

Re: [Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download

Hi Rosario, Am Freitag, den 02.02.2018, 14:53 +0100 schrieb rosario.contar...@esa.int: > HI Tim, > > Thank you for your pointer. > > Unfortunately wget 1.14 is only available for SLES 12 (not 11). > > So I tried to compile wget 1.14 on 11. > > It fails on > > configure: error:

Re: [Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download

ueh...@gmx.de> To: rosario.contar...@esa.int, bug-wget@gnu.org Cc: i...@ssa.esa.int Date: 01/02/2018 21:01 Subject: Re: [Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download Am Donnerstag, den 01.02.2018, 17:29 +0100 schrieb rosario.contar...@esa.int: > Dear all, >

Re: [Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download

Am Donnerstag, den 01.02.2018, 17:29 +0100 schrieb rosario.contar...@esa.int: > Dear all, > > I believe, to fix the following issue, I should upgrade wget at least > to > 1.14 > > * * * > wget -v --debug https://ssd.jpl.nasa.gov/dat/radar_data_ast.txt > DEBUG output created by Wget 1.11.4 on

[Bug-wget] wget 1.11.4 on SLES 11 SP3 fail an https download

Dear all, I believe, to fix the following issue, I should upgrade wget at least to 1.14 * * * wget -v --debug https://ssd.jpl.nasa.gov/dat/radar_data_ast.txt DEBUG output created by Wget 1.11.4 on linux-gnu. --2018-02-01 17:28:00-- https://ssd.jpl.nasa.gov/dat/radar_data_ast.txt Resolving

Re: [Bug-wget] Wget bug - srcset

Am Donnerstag, den 01.02.2018, 14:00 +0100 schrieb Bence Bojti: > Dear Developers! > > I have a problem with the Wget 1.18 (installed from standard repo of > Debian > 9). > > I need wget to mirroring a website with --page-requisites. > > Unfortunately on my website, which I want to mirror (

[Bug-wget] Wget bug - srcset

Dear Developers! I have a problem with the Wget 1.18 (installed from standard repo of Debian 9). I need wget to mirroring a website with --page-requisites. Unfortunately on my website, which I want to mirror ( https://mno.hu ), there are lot of tag with a few . This is valid html5 code. For

Re: [Bug-wget] wget 1.19.2 fails on Test-metalink-http.py and Test-metalink-http-quoted.py

Thanks, slightly amended and pushed. With Best Regards, Tim On 01/30/2018 09:42 AM, Arkadiusz Miśkiewicz wrote: > On Monday 30 of October 2017, Tim Rühsen wrote: >> On 10/30/2017 12:49 PM, Arkadiusz Miśkiewicz wrote: >>> On Monday 30 of October 2017, Tim Rühsen wrote: On 10/29/2017

Re: [Bug-wget] wget 1.19.2 fails on Test-metalink-http.py and Test-metalink-http-quoted.py

On Monday 30 of October 2017, Tim Rühsen wrote: > On 10/30/2017 12:49 PM, Arkadiusz Miśkiewicz wrote: > > On Monday 30 of October 2017, Tim Rühsen wrote: > >> On 10/29/2017 09:39 PM, Arkadiusz Miśkiewicz wrote: > >>> On Sunday 29 of October 2017, Tim Rühsen wrote: > On Sonntag, 29. Oktober

[Bug-wget] wget-1.19.4 released [stable]

We would like to announce GNU Wget 1.19.4. This is a bug fix version that fixes a major bug with v1.19.3. With v1.19.3 Wget would request the origin server for a gzip compressed document. However, due to a logic bug, it would never decompress it for the user. This caused almost all downloads to

[Bug-wget] [wget-1.19.3] side effect of excluding from decompression ?

Hello, With wget-1.19.3, % wget http://www.oracle.com/technetwork/indexes/downloads/index.html downloads index.html as gzip compressed data, such as % ls -l index.html; file index.html x   13380 Jan 20 14:52 index.html index.html: gzip compressed data - deflate method With

[Bug-wget] wget-1.19.3 released [stable]

We are pleased to announce the release of GNU Wget 1.19.3. GNU Wget is a free utility for non-interactive download of files from the Web. It supports HTTP(S), and FTP(S) protocols, as well as retrieval through HTTP proxies. This is a minor bugfix release, primarily to fix the behaviour of GNU

Re: [Bug-wget] Wget not building with libpsl?

Cancel this... /usr/local/bin/pod2man was missing, so the script bailed early. The program was not being updated with 'make install' like I expected. On Fri, Jan 5, 2018 at 4:47 AM, Jeffrey Walton wrote: > Hi Everyone, > > I have a local copy of libpsl

[Bug-wget] Wget not building with libpsl?

Hi Everyone, I have a local copy of libpsl (https://github.com/rockdaboot/libpsl). Wget was configured with: $ ./configure --prefix=/usr/local --libdir=/usr/local/lib64 --with-ssl=openssl --with-libssl-prefix=/usr/local --with-libiconv-prefix=/usr/local --with-libunistring-prefix=/usr/local

Re: [Bug-wget] wget from a subfolder of a site

Remember to send the message to the bug-wget mailing list!xo "ifffam ..." writes: > I have tried these two ways: > > wget -r --no-parent --include-directories > http://www.astrosurf.com/luxorion/menu-quantique.htm > > wget -r --include-directories >

Re: [Bug-wget] wget from a subfolder of a site

"ifffam ..." writes: > Hello! I wanted to ask you how to download just a part of a site, I > mean, starting from a subfolder. I have tried > > wget -r --no-parent http://www.astrosurf.com/luxorion/menu-quantique.htm > > but didn't work, I mean, it downloaded the whole >

[Bug-wget] wget from a subfolder of a site

Hello! I wanted to ask you how to download just a part of a site, I mean, starting from a subfolder. I have tried wget -r --no-parent http://www.astrosurf.com/luxorion/menu-quantique.htm but didn't work, I mean, it downloaded the whole www.astrosurf.com site (more

Re: [Bug-wget] Wget does not work on windows 10

On 08.12.2017 13:09, Aram Alaverdyan wrote: > Hello, dear wget project developers, > > I am trying to download a zip file from web using the wget -O > format on my windows 10 machine. The cmd output > shows that the command was successful, but the mentioned file was not saved > in the

[Bug-wget] Wget does not work on windows 10

Hello, dear wget project developers, I am trying to download a zip file from web using the wget -O format on my windows 10 machine. The cmd output shows that the command was successful, but the mentioned file was not saved in the destination defined. Can you please, clarify, what is the

Re: [Bug-wget] wget 1.19.2 fails on Test-metalink-http.py and Test-metalink-http-quoted.py

On 10/30/2017 12:49 PM, Arkadiusz Miśkiewicz wrote: > On Monday 30 of October 2017, Tim Rühsen wrote: >> On 10/29/2017 09:39 PM, Arkadiusz Miśkiewicz wrote: >>> On Sunday 29 of October 2017, Tim Rühsen wrote: On Sonntag, 29. Oktober 2017 21:00:35 CET Arkadiusz Miśkiewicz wrote: > On

Re: [Bug-wget] wget 1.19.2 fails on Test-metalink-http.py and Test-metalink-http-quoted.py

On Sonntag, 29. Oktober 2017 21:00:35 CET Arkadiusz Miśkiewicz wrote: > On Sunday 29 of October 2017, Tim Rühsen wrote: > > On Sonntag, 29. Oktober 2017 13:45:53 CET Arkadiusz Miśkiewicz wrote: > > > Hi. > > > > > > Test suite for wget fails here on Test-metalink-http.py and > > > Test-metalink-

[Bug-wget] wget 1.19.2 fails on Test-metalink-http.py and Test-metalink-http-quoted.py

Hi. Test suite for wget fails here on Test-metalink-http.py and Test-metalink- http-quoted.py test-suite.log attached. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) = wget 1.19.2: testenv/test-suite.log

Re: [Bug-wget] Wget cannot validate https://ftp.gnu.org?

On Wed, Oct 18, 2017 at 7:58 PM, Jeffrey Walton wrote: > On Mon, Oct 16, 2017 at 4:52 AM, Tim Rühsen wrote: >> ... >> >> Caveat: wget has been build with GnuTLS (3.5.15). The OpenSSL (1.1.0f) >> code seems not to support --ca-directory !? It succeeds with

Re: [Bug-wget] Wget cannot validate https://ftp.gnu.org?

On Mon, Oct 16, 2017 at 4:52 AM, Tim Rühsen wrote: > ... > > Caveat: wget has been build with GnuTLS (3.5.15). The OpenSSL (1.1.0f) > code seems not to support --ca-directory !? It succeeds with both the > above tests. While we only actively support GnuTLS, we accept OpenSSL >

  1   2   3   4   5   6   7   8   9   >