Re: [Bug-wget] pod2man --utf8 -> wget build failure
Did you already get any feedback from your colleagues ? They didn't rebuild (not easy in that environment), but they thought it should work too. Might as well go for it. Thanks for checking. --karl
Re: [Bug-wget] pod2man --utf8 -> wget build failure
Please test the attached patch that addresses the pod2man issue. I can't test it myself, but I'll pass it on to my Mac-using colleagues. It looks like it should do the job. Thanks. --karl
Re: [Bug-wget] --no-check-cert does not avoid cert warning
the right thing to do is to listen to the Tim's opinion, Sure. I meant no disrespect! Everything he said was perfectly reasonable, just insufficient for my purposes :). (Thanks Tim.) since he is one of the maintainers I did not know. He's not listed in the maintainers file ... maybe he should be listed as an official co-maintainer? How does the new version look? No complaints from me. I suppose it should also be listed in NEWS. The English could be tweaked if you wish, e.g.: <--check-certificate=quiet to ask wget to not print any warning about < invalid certificates, in most cases this is the wrong thing to do. - > --check-certificate=quiet to tell wget to not print any warning about > invalid certificates; in most cases, this is the wrong thing to do. Thanks for all, Karl
Re: [Bug-wget] --no-check-cert does not avoid cert warning
{ wget -d xxx 2>&1 1>&3 | grep -v Saving 1>&2; } 3>&1
This changes the exit value, so that's no good. Sure, with even more
complexity the exit status could be preserved too, but IMHO wrapping
wget in layers of shell mechanisms to work around a warning is crazy.
Giuseppe - please just do the right thing and provide a way to shut off
the warning. Especially since it's simple to do. -k
Re: [Bug-wget] --no-check-cert does not avoid cert warning
I understand, though don't completely agree with, Tim's pessimistic scenario. In any case, my wish is that there be a way to get rid of the warning message (other than being completely silent). Whether it is done via changing --no-check-cert or via some new/other option doesn't matter to me. I am using wget from a script, as surely many people do, and it is far too annoying for every invocation of wget to give a useless warning message. At present, I'm using curl -sS instead :(. On the other front, IMHO the text of the warning message is immaterial. Either people will understand, or care enough to look it up and figure out what's happening, or no text will be good enough. thanks, k
[Bug-wget] --no-check-cert does not avoid cert warning
With wget 1.17 (at least), $ wget -nv --no-check-cert https://www.gnu.org -O /dev/null WARNING: cannot verify www.gnu.org's certificate, issued by 'CN=Gandi Standard SSL CA 2,O=Gandi,L=Paris,ST=Paris,C=FR': Unable to locally verify the issuer's authority. Maybe I'm crazy, but it seems like pointless noise to complain that a certificate cannot be verified when wget has been explicitly told not to check it. Looking at the source, the only way I see to get rid of the warning is with --silent, which would also eliminate real errors. I have the sense that at one point the cert warning was not issued in this case, but I didn't go back and check old versions. Thanks, Karl
[Bug-wget] warning about unknown .wgetrc directives
Giuseppe et al., I suggest making unknown .wgetrc directives a warning (and just ignore them, proceeding on normally), rather than a failure. For purposes of compatibility - a person might have a brand-new wget on system A, but for whatever reason, have to run an older wget on system B. But it's convenient to have the same wget regardless. This came up for us in TeX Live, where we use an internal wget to download stuff -- a user had a new .wgetrc directive, which caused the (slightly older) wget we had to fail. It was not a simple thing to debug, or detect. best, karl
Re: [Bug-wget] libssl-prefix and wget 1.15
if someone has already a recipe for the openssl detection I could not debug it further than I did because the configure.ac in the tarball did not seem to match the generated configure. See items 1-2 in my report :). Hence I did not know where the /lib64 craziness was actually coming from. best, karl
[Bug-wget] libssl-prefix and wget 1.15
Hi Giuseppe and anyone, Congratulations on the new release. 1. configure.ac in wget-1.15 has a final copyright year of 2011. Surely that needs updating. 2. Although the generated configure script in the wget-1.15.tar.xz archive has stuff for --with-libssl-prefix (= LIBSSL_PREFIX), I do not see in configure.ac (or elsewhere). What gives? I am probably just blind. 3. On an x86_64 GNU/Linux system (CentOS 6.5, not that it matters), I ran configure with these options: configure --with-libssl-prefix=/usr/local/openssl --with-ssl=openssl I do have openssl (1.0.1f) in /usr/local/openssl, with the usual include/ and lib/ subdirectories. However, it turns out this still fails, because wget configure still does checking for libssl without the necessary -I/usr/local/openssl/include ... /usr/local/openssl/lib/libssl.a ... etc. I could not find any clues in config.log about why the options were missing (wget configure on 32-bit CentOS worked fine), but running configure under sh -vx turned up this: .. additional_libdir=/usr/local/openssl/lib64 .. Well, that directory doesn't exist, nor is it normal for it to exist, at least in my life (compiling and installing openssl from original sources). I see that wget configure is setting acl_libdirstem=lib64 based on the output of $CC -print-search-dirs. I don't know if this is part of autoconf or wget (see item 2 above), but surely this should not deny openssl detection. It seems something still needs to be tweaked. For now, I made a symlink /usr/local/openssl/lib64 - lib and, happily, the whole build succeeded. Thanks, Karl
[Bug-wget] texinfo @dir information
Tiny change for the manual to make its dir entry consistent with others, ok? Thanks, k --- /usr/local/gnu/src/wget-1.13.4/doc/ORIG/wget.texi 2011-08-06 03:22:58.0 -0700 +++ /usr/local/gnu/src/wget-1.13.4/doc/wget.texi2011-09-27 07:34:17.0 -0700 @@ -22,5 +22,5 @@ -@dircategory Network Applications +@dircategory Network applications @direntry -* Wget: (wget). The non-interactive network downloader. +* Wget: (wget). Non-interactive network downloader. @end direntry Diff finished at Tue Sep 27 07:34:18
[Bug-wget] --version copyright year stale
Hi Giuseppe, The copyright year in the wget --version output should be 2011, not 2009. As seen in 1.13.4. k
[Bug-wget] gnutls link failure, ssl
My initial build of wget failed due to gnutls version problems. configure said: .. checking for main in -lgnutls... yes configure: compiling in support for SSL via GnuTLS But then the link failed with: gcc -O2 -Wall -o wget cmpt.o connect.o convert.o cookies.o ftp.o css.o css-url.o ftp-basic.o ftp-ls.o hash.o host.o html-parse.o html-url.o http.o init.o log.o main.o netrc.o progress.o ptimer.o recur.o res.o retr.o spider.o url.o utils.o exits.o build_info.o iri.o version.o ftp-opie.o gnutls.o ../lib/libgnu.a -lgnutls -lgcrypt -lgpg-error -lz -lidn -lrt gnutls.o: In function `ssl_connect_wget': gnutls.c:(.text+0x4b0): undefined reference to `gnutls_priority_set_direct' gnutls.c:(.text+0x528): undefined reference to `gnutls_priority_set_direct' collect2: ld returned 1 exit status Evidently configure should check for gnutls_priority_set_direct also. And if it fails, hopefully it will fall back to openssl. (This was on CentOS 5.6, but presumably that doesn't especially matter.) Related, there used to be an option --with-libssl-prefix. I'm not sure when it was removed, but it was useful. Also, configure --help does not mention the possibility of --with-ssl=openssl. Finally, the NEWS file doesn't say anything about either of these: preferring tls to openssl or the --with-ssl=openssl option. I didn't look to see if there were other configure options that didn't make to the --help and/or NEWS. Thanks, Karl
Re: [Bug-wget] mirroring one sourceforge package?
ftp://ftp.heanet.ie/mirrors/sourceforge/b/project/bi/biblatex-biber/biblatex-biber/current/ Thank you, thank you! That is perfect. I wonder if it's possible that that file is a redirection from a Just FWIW, I also tried with --max-redirect=0 and --max-redirect=1, but they seemed to hang forever and/or have no effect, depending on exactly what options were specified. Not sure there is any bug there, just mentioning. Adding -R login.php seems a decent workaround Indeed, I tried that and it worked better. Then I thought I would try to exclude the numerous stats items, but failed. I tried wget -m -np -nv -R login.php -X stats http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/ wget -m -np -nv -R login.php,stats http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/ wget -m -np -nv -R login.php,stats\* http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/ and none of them actually stopped url's like http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/binaries/stats/timeline from showing up. Thanks again for all the responses, karl
[Bug-wget] mirroring one sourceforge package?
The bug (?) -- running wget -m -np -nv \ http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/ ends up downloading many things above that directory, despite the -np. Doesn't that seem wrong? This is with wget 1.12 compiled from the original source. The request: does anyone know a way to mirror one package (ideally a subdirectory thereof) from sourceforge? Specifically, I want http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/ (I don't actually care about using wget, could be anything. :) I did a bunch of searching to no avail. My friends at CTAN have tried from time to time over the years but never found any really reliable method -- always ends up coming down to scraping the HTML :(. One possible answer, Joining the sourceforge mirror network (http://sourceforge.net/apps/trac/sourceforge/wiki/Instructions for joining the SourceForge.net mirror network) is not what I want to do. I just want one package, not to help sf. I suspect there is no good way, given sf's policies and setup, but thought I would ask here. Thanks, Karl
[Bug-wget] new wget maintainer solicited
So, as Micah said, he is stepping down as the maintainer of wget. Is anyone here interested in volunteering to do the work? This list seems like the most likely place to find a new maintainer ... Please email me if you have time and interest. If you want to read about what it means to maintain a GNU package, see http://www.gnu.org/help/evaluation.html#whatmeans Thanks, Karl
[Bug-wget] supporting rsync?
Any prospect of wget supporting rsync urls? It sure would be useful. Thanks, Karl
