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
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
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 ...
{ 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
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
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
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
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.
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
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 @@
Hi Giuseppe,
The copyright year in the wget --version output should be 2011, not 2009.
As seen in 1.13.4.
k
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://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
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
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
Any prospect of wget supporting rsync urls? It sure would be useful.
Thanks,
Karl
16 matches
Mail list logo
