Re: Problems downloading files on Windows with wget2 2.0.0
640 No cached TLS session available. Will run a full handshake. 03.142046.648 No HPKP pinning found for host 'eternallybored.org' 03.142046.649 OCSP URI not given and not found in certificate. Skipping OCSP check for cert 0. 03.142046.652 OCSP URI not given and not found in certificate. Skipping OCSP check for cert 1. 03.142046.655 No HPKP pinning found for host 'eternallybored.org' 03.142046.656 No HPKP pinning found for host 'eternallybored.org' 03.142046.658 *** OCSP response status: 03.142046.659 successful 03.142046.660 No HPKP pinning found for host 'eternallybored.org' 03.142046.663 No HPKP pinning found for host 'eternallybored.org' 03.142046.664 *** OCSP cert status: 03.142046.665 good 03.142046.666 Got a stapled OCSP response. Length: 503. Status: OK 03.142046.667 Handshake completed (full handshake - not resumed) 03.142046.669 TLS session discarded 03.142046.670 established connection eternallybored.org [0] Downloading 'https://eternallybored.org/misc/bigtest' ... 03.142046.673 cookie_create_request_header for host=eternallybored.org path=misc/bigtest 03.142046.675 host_increase_failure: eternallybored.org failures=3 03.142046.676 [0] action=3 pending=1 host=0x2a8f0 03.142046.678 closing connection 03.142046.679 released job https://eternallybored.org/misc/bigtest 03.142046.681 [0] action=1 pending=0 host=0x0 03.142046.682 host eternallybored.org is paused 2993ms 03.142046.683 main: wake up ^C -- < Jernej Simončič ><><><><>< https://eternallybored.org/ > When a problem goes away, the people working to solve it do not. -- Law of Bureaucracy
Re: [Bug-wget] RESEND1: wget-1.20-win32
On Sunday, May 12, 2019, 17:45:31, Darshit Shah wrote:
> Could you please let us know which sites?
It happens everywhere, as long as the filename is long enough to
require scrolling. I received a patch from Bykov Alexey
that supposedly fixes this a few days ago, but
haven't had time to test it yet:
diff --git a/src/progress.c b/src/progress.c
index 8e5709c7..6a69b4e2 100644
--- a/src/progress.c
+++ b/src/progress.c
@@ -845,8 +845,8 @@ static int count_cols (const char *mbs) { return (int)
strlen(mbs); }
static int
cols_to_bytes (const char *mbs _GL_UNUSED, const int cols, int *ncols)
{
- *ncols = cols;
- return cols;
+ *ncols = min(strlen(mbs),cols);
+ return *ncols;
}
#endif
--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >
Needs are a function of what other people have.
-- Jones's Principle
Re: [Bug-wget] * src/openssl.c: fix ssl_init for openssl 1.1.1
On Monday, April 22, 2019, 16:03:25, Eneas U de Queiroz wrote: > ssl_init fails with openssl 1.1.1 when openssl.cnf is not found. > Redundant calls to intialization functions were removed as > OPENSSL_config takes care of them for openssl versions < 1.1.0. > For versions > 1.1.0, OPENSSL_init_ssl is preferred. > Signed-off-by: Eneas U de Queiroz > --- > wget currently fails to use SSL with openssl 1.1.1b: > $ wget https://google.com > --2019-04-22 10:10:16-- https://google.com/ > Disabling SSL due to encountered errors. > This may be considered a workaround, as it should not generate the > error, but it really is an API update, as openssl 1.1.1 deprecated > OPENSSL_config in favor of OPENSSL_init_crypto anyway. See > https://github.com/openssl/openssl/issues/8528 > OPENSSL_init_ssl can be seen as a superset of OPENSSL_init_crypto (it > calls OPENSSL_init_crypto), and we are already calling it, so we just > need to pass these flags: OPENSSL_INIT_LOAD_CONFIG to load the > openssl.cnf file, and OPENSSL_INIT_ENGINE_ALL_BUILTIN to load the > builtin engines. Thanks, this fixed the problem I had with the Windows release of wget 1.20.3. -- < Jernej Simončič ><><><><>< https://eternallybored.org/ > The most expensive component is the one that breaks. -- Law of New Fangled Gadgetry
Re: [Bug-wget] Report of potential bug in wget-1.19.1-win64
On Tuesday, August 8, 2017, 16:35:50, Darshit Shah wrote: > It is an interesting bug when it works on a 32-bit build but not a > 64-bit build. I tested all three URLs on my local Linux machine with > both a 32-bit and 64-bit build of Wget 1.19 and found no issues. The bug is not 64-bit specific - it also happens with 32-bit wget on Windows. It's completely random, and I've never been able to reproduce it under a debugger (not even with a JIT debugger, such as Dr.MinGW), so I'm not sure what causes it. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > In the fight between you and the world, back the world. -- Kafka's Law
Re: [Bug-wget] Wget keeps crashing on me
On Sunday, May 14, 2017, 21:38:15, Tim Rühsen wrote: > Oh, sorry. Yeah, I meant Jernej. Here are Win64 builds of current wget git: https://eternallybored.org/misc/wget/test/ wget.exe is straight 40c0d, while wget-patched.exe includes taskbar progress and OpenSSL Windows Certificate Store patches. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > Those who have the shortest distance to travel invariably arrive latest. -- Law of Late-Comers
Re: [Bug-wget] Wget keeps crashing on me
On Sunday, May 14, 2017, 20:19:16, Eli Zaretskii wrote: > Is that binary also of wget 1.19.1? If so, perhaps there's a bug in > that particular version. The crashes started with version 1.17 IIRC. > Also, is your build with libssl or libgnutls? Does it support ipv6? I use OpenSSL, 1.19.1 is built with 1.1.0e. Here's the full --version output: ,- | GNU Wget 1.19.1 built on mingw32. | | -cares +digest -gpgme +https +ipv6 +iri +large-file +metalink -nls | +ntlm +opie -psl +ssl/openssl | | Wgetrc: | /win32dev/misc/wget/out64/etc/wgetrc (system) | Compile: | x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H | -DSYSTEM_WGETRC="/win32dev/misc/wget/out64/etc/wgetrc" | -DLOCALEDIR="/win32dev/misc/wget/out64/share/locale" -I. -I../lib | -I../lib -I/win32dev/misc/wget/out64/include | -I/win32dev/misc/wget/out64/include | -I/win32dev/misc/wget/out64/include -DHAVE_LIBSSL | -I/win32dev/misc/wget/out2/include -DNDEBUG | Link: | x86_64-w64-mingw32-gcc -I/win32dev/misc/wget/out64/include | -I/win32dev/misc/wget/out64/include -DHAVE_LIBSSL | -I/win32dev/misc/wget/out2/include -DNDEBUG | -L/win32dev/misc/wget/out64/lib -lidn2 | -L/win32dev/misc/wget/out64/lib -lmetalink -lunistring -liconv | -L/win32dev/misc/wget/out64/lib -lssl -lcrypto | -L/win32dev/misc/wget/out2/lib -lz -lws2_32 ftp-opie.o mswindows.o | openssl.o http-ntlm.o ../lib/libgnu.a -lws2_32 -lws2_32 -lws2_32 | -lws2_32 /win32dev/misc/wget/out64/lib/libiconv.a | /win32dev/misc/wget/out64/lib/libunistring.a | /win32dev/misc/wget/out64/lib/libiconv.a -lws2_32 | | Copyright (C) 2015 Free Software Foundation, Inc. | License GPLv3+: GNU GPL version 3 or later | <http://www.gnu.org/licenses/gpl.html>. | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. | | Originally written by Hrvoje Niksic . | Please send bug reports and questions to . `- I build everything with static libraries, to have a wget.exe that doesn't need additional DLLs. My binary also includes 2 patches that aren't part of wget: https://eternallybored.org/misc/wget/src/taskbar-progress.patch https://eternallybored.org/misc/wget/src/openssl-windows-cert-store.patch -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > Never buy a car that has a wick. -- Ford Pinto Rule
Re: [Bug-wget] Wget keeps crashing on me
On Sunday, May 14, 2017, 19:46:45, Darshit Shah wrote: > Then could you please provide us with a command line that sometimes > crashes and preferably the debug output from Wget when it crashes. Not the > debugger, but just the debug. I use either wget -t0 -c -S or wget -t0 -c -S --trust-server-names Seems to happen more often with larger files. I don't remember any special output when the crash happens - just the standard progress bar, and Windows' crash notification. > I would like to reduce it to some kind of a minimal test case. Maybe the > progress bar routines are crashing, or maybe it is something to do with how > we access the filesystem, or something entirely different. I thought about the progress bar, since it does behave a bit weird on Windows - specifically, if the filename is scrolling, once it starts off-screen, the last letter keeps getting repeated, while the rest of the progress bar stops updating, however the crashes seem to happen regardless of how the filename is displayed. > However, since you say you can't reproduce it inside a debugger, I would > hazard a guess that the issue lies somewhere in using uninitialized memory. > The debugger will initialize the memory and hence prevent some class of > bugs from occurring. An audit of the WIndows-specific code might be in > order for this since I haven't heard of such an issue on *nix machines. The annoying thing is that I haven't even had a crash since I set up DrMingw as just-in-time debugger (debugger that Windows invokes only when a crash occurs, and which otherwise isn't running). The last time my build crashed for me was about a month ago, downloading some ISO file at work, while I hadn't had it crash on my home computer in well over a year (I even tried setting up a batch file that just ran wget in a loop and leaving it in the background, but it wouldn't crash). -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > The bus that left the stop just before you got there is your bus. -- First Law of Bus Transportation
Re: [Bug-wget] Wget keeps crashing on me
On Sunday, May 14, 2017, 19:07:49, Darshit Shah wrote: > I'm not sure what the exact issue here is. But it indeed seems like the > issue lies somewhere in how your particular binary of Wget was built. I > can't reproduce the issue on my Linux system, and as Eli says he can't > reproduce it with his binaries either. Of course, he has linked to a much > older version of Wget, but if I understand right, he even has newer builds > available. The wget binary I have on my site (https://eternallybored.org/misc/wget/) sometimes crashes when finishing download, but I haven't been able to reproduce the crash under a debugger (and I haven't had it crash since I installed DrMingw as JIT debugger either), so I'm not sure where the problem is. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > It's better to be rich and healthy than poor and sick. -- Carson's Law
Re: [Bug-wget] Query about correcting for DST with Wget
On Sunday, November 13, 2016, 19:53:06, Eli Zaretskii wrote: > Does "while DST is in effect" mean that you download the file when DST > is in effect, or you examine the timestamp of the file when the DST is > in effect? I download the file when DST is(n't) in effect (I download that specific URL quite often, on different computers). > Also, how do you display the timestamp of the file? with what program? Windows Explorer, or dir in command prompt. I just remembered that there may be a 3rd explanation: some msvcrt functions return different timestamps depending on whether DST is in effect or not - at least with GIMP you can observe that it'll rescan all fonts the first time it's run after DST change (I'm not sure if this applies only to msvcrt.dll [which MinGW uses by default], or also to the runtimes shipped with newer Visual Studio versions). -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > If you need n items of anything, you will have n-1 in stock. -- Sueker's Note
Re: [Bug-wget] Query about correcting for DST with Wget
On Friday, November 11, 2016, 8:52:49, Eli Zaretskii wrote: > Can you tell more details, like the exact URL you downloaded and how > you see the 1-hour difference? I'd like to try to reproduce this > here. I'm not sure if this is a problem with wget, Windows or the server hosting the file, but I observed this happening with <https://live.sysinternals.com/procexp.exe> - while DST is in effect, the file gets timestamp of 22:19, and when it's not it's 23:19 (I'm in the CET timezone). -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > Being sure mistakes will occur is a good frame of mind for catching them. -- Berkeley's Thirteenth Law
Re: [Bug-wget] bug #45790: wget prints it's progress even when background
On Sunday, October 2, 2016, 21:54:58, pwa...@gmail.net.pl wrote: > Is there a instruction on how to compile current wget version on windows? You can cross-compile from Linux by running configure somewhat like this: ./configure --host=i686-w64-mingw32 --without-ssl --without-libidn --without-metalink --with-gpgme-prefix=/dev/null -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > The usefulness of any meeting is in inverse proportion to the attendance. -- Kirkland's Law
Re: [Bug-wget] Progress bar on MS-Windows
On Saturday, June 4, 2016, 10:27:56, Eli Zaretskii wrote: > Sorry, no. Not unless someone will be kind enough to produce a > complete tarball. Building from Git requires all kinds of utilities > that are not simple to set up on Windows. Here's a build as of commit 7c0752c4cb6575c6720d6e2d4bf4eda61b63e0f1: https://eternallybored.org/misc/wget/test/wget.exe -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > Speak softly and own a big, mean Doberman. -- Dave's Rule of Street Survival
Re: [Bug-wget] Wget 1.17.1 bug?
On Monday, May 16, 2016, 9:24:25, Zeroes & Ones wrote: > i update Wget 1.11.4 to latest 1.17.1 and i have troubles > output file have wrong permission on NTFS (checked on W2008R2, Win8.1) If you're using cygwin's wget, that's normal - use chmod +x to make the file executable. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > Nothing ever comes out as planned. -- Law of Future Results
[Bug-wget] -w on Windows doesn't wait less than 1001 seconds
There's a bug in xsleep in mswindows.c:
--- src/mswindows.c.orig2015-11-09 16:24:07.0 +0100
+++ src/mswindows.c 2016-04-25 12:29:49.291555801 +0200
@@ -63,7 +63,7 @@
xsleep (double seconds)
{
#if defined(HAVE_USLEEP) && defined(HAVE_SLEEP)
- if (seconds > 1000)
+ if (seconds >= 1)
{
/* Explained in utils.c. */
sleep (seconds);
--
< Jernej Simončič ><><><><><><><><><><><>< https://eternallybored.org/ >
Because 10 billion years' time is so fragile, so ephemeral...
it arouses such a bittersweet, almost heartbreaking fondness.
Re: [Bug-wget] Marking Release v1.17.1?
On Saturday, December 12, 2015, 13:58:07, Gisle Vanem wrote: > But I don't really understand why. Care to explain? No idea - the patch was posted to the mailing list by Eli Zaretskii on March 17th. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > The fact that monkeys have hands should give us pause. -- Malloy's Maxim
Re: [Bug-wget] Marking Release v1.17.1?
On Tuesday, December 8, 2015, 21:45:31, Darshit Shah wrote: > With my last set of patches, we have fixed all the issues reported / > identified > after the 1.17 release. Hence, maybe we should consider releasing a 1.17.1 > bugfix release? Here's another one that I thought was already fixed, but apparently wasn't - --connect-timeout doesn't work on Windows without this patch (it's not included in my 1.17 Win32 builds, and I got an e-mail about this in the morning): https://eternallybored.org/misc/wget/src/old/fix-timeout-win32.patch -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > It is better to have a horrible ending than to have horrors without end. -- Matsch's Law
Re: [Bug-wget] Marking Release v1.17.1?
On Tuesday, December 8, 2015, 21:45:31, Darshit Shah wrote: > With my last set of patches, we have fixed all the issues reported / > identified > after the 1.17 release. Hence, maybe we should consider releasing a 1.17.1 > bugfix release? Sorry about reporting this late, it forgot about it a bit: when I was preparing my Windows release, I noticed that metalink support first didn't want to compile (due to missing sys/errno.h - just #ifdefing it out didn't seem to break anything), and then that hash validation failed, because the file was being opened in text mode. I did a quick and dirty fix for my build <https://eternallybored.org/misc/wget/src/wget-1.17-win32-metalink.patch>, but this probably isn't correct for non-Windows systems. Another thing that would be nice to include is the taskbar progressbar patch: <https://eternallybored.org/misc/wget/src/taskbar-progress.patch> This one is based on patch by Ángel González and tbprogress.c from Gisle Vanem. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > When you are over the hill, you pick up speed. -- Baker's Byroad
[Bug-wget] Wget 1.17 doesn't compile on Windows (hsts.c)
Looks like hsts.c tries to use flock with a parameter that doesn't
work on Windows:
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\"/win32dev/misc/wget/out64/etc/wgetrc\"
-DLOCALEDIR=\"/win32dev/misc/wget/out64/share/locale\" -I. -I../lib -I../lib
-I/win32dev/misc/wget/out64/include -I/win32dev/misc/wget/out64/include
-DHAVE_LIBSSL -DNDEBUG -MT hsts.o -MD -MP -MF .deps/hsts.Tpo -c -o hsts.o
hsts.c
hsts.c: In function 'hsts_store_dump':
hsts.c:329:20: warning: format '%lu' expects argument of type 'long unsigned
int', but argument 6 has type 'time_t' [-Wformat=]
khi->created, khi->max_age) < 0)
^
hsts.c:329:20: warning: format '%lu' expects argument of type 'long unsigned
int', but argument 7 has type 'time_t' [-Wformat=]
hsts.c: In function 'hsts_store_save':
hsts.c:505:22: error: 'LOCK_EX' undeclared (first use in this function)
flock (fd, LOCK_EX);
^
hsts.c:505:22: note: each undeclared identifier is reported only once for each
function it appears in
--
< Jernej Simončič ><><><><><><><><><><><>< http://eternallybored.org/ >
Because 10 billion years' time is so fragile, so ephemeral...
it arouses such a bittersweet, almost heartbreaking fondness.
Re: [Bug-wget] Feature: Disabling progress bar when wget is backgrounded
On Tuesday, September 22, 2015, 12:38:02, Tim Ruehsen wrote: > I would like to see that (if I was using Windows). > Should be activated by a switch (maybe windows only). > Feel free to create a patch. There already is a patch for this, but it's C++: <https://eternallybored.org/misc/wget/src/taskbar-progress.patch> -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > A chain of reasoning is no stronger than its weakest link. -- Berkeley's Seventh Law
Re: [Bug-wget] Eternallybored Windows binary Wget safe?
On Monday, August 10, 2015, 18:42:36, tomtid...@sigaint.org wrote: > Has anyone looked over the code for the Windows binary of wget at this site? > https://eternallybored.org/misc/wget/ > Does anyone have opinion about that site's binaries and if it's safe build > of wget? Well, I'm guaranteeing for them with my digital signature (and if you don't know who I am, I also provide the Windows installer for GIMP). -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > When all else fails, read the instructions. -- Cahn's Axiom (Allen's Axiom)
[Bug-wget] --connect-timeout doesn't work on Windows
It appears that --connect-timeout doesn't work on recent versions of wget when running on Windows (compiled with mingw). I have confirmed this with my own builds of wget (available at <https://eternallybored.org/misc/wget/>, both 1.16.3 and 1.13), and with the builds available here: <http://opensourcepack.blogspot.com/2010/05/wget-112-for-windows.html>. This is pretty trivial to test - I used wget --connect-timeout=1 http://192.0.2.1:12345/ ...and wget just hung there (I left it for a few minutes). The old gnuwin32 build (1.11.4) doesn't have this problem. -- < Jernej Simončič ><><><><><><><><><><><>< http://eternallybored.org/ > Because 10 billion years' time is so fragile, so ephemeral... it arouses such a bittersweet, almost heartbreaking fondness.
