RE: Release: GNU Wget 1.11.4
I've published the Windows versions of Wget 1.11.4 on my web site. http://www.christopherlewis.com/Wget/WGetFiles.htm Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Sunday, June 29, 2008 11:35 PM To: Wget; [EMAIL PROTECTED] Subject: Release: GNU Wget 1.11.4 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Announcing GNU Wget 1.11.4, a bugfix release. The source code is available at - http://ftp.gnu.org/gnu/wget/ - ftp://ftp.gnu.org/gnu/wget/ Documentation is at - http://www.gnu.org/software/wget/manual/ More information about Wget is on the official GNU web page at http://www.gnu.org/software/wget/, and on the Wget Wgiki, http://wget.addictivecode.org/ Here's the relevant NEWS entries: * Changes in Wget 1.11.4 ** Fixed an issue (apparently a regression) where -O would refuse to download when -nc was given, even though the file didn't exist. ** Fixed a situation where Wget could abort with --continue if the remote server gives a content-length of zero when the file exists locally with content. ** Fixed a crash on some systems, due to Wget casting a pointer-to-long to a pointer-to-time_t. ** Translation updates for Catalan. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaGJs7M8hyUobTrERApiRAJ9H7aElziLZ6qQrSHiG4YyaZBSG5wCfaI9J EFfMg67SazmrKekuxvq6zX8= =+IwS -END PGP SIGNATURE-
RE: Release: GNU Wget 1.11.4
I've published the Windows versions of Wget 1.11.4 on my web site. http://www.christopherlewis.com/Wget/WGetFiles.htm Christopher G. Lewis http://www.ChristopherLewis.com smime.p7s Description: S/MIME cryptographic signature
FW: GNU Coding Standard compliance
Eric - Why are you trying to package Wget for cygwin when there is a *native* win32 exe? Seems like a whole *lot* of work for something that really doesn't gain you anything. I'm quite interested in your response. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 7:52 AM To: [EMAIL PROTECTED] Subject: GNU Coding Standard compliance -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to package wget-1.11.3 for cygwin. But you have several GNU Coding Standard compliance problems that is making this task more difficult than it should be. GCS requires that your testsuite be run by 'make check', but yours is a no-op. Instead, you provide 'make test', but that fails to compile if you use a VPATH build. And even when using an in-tree build, it fails as follows: ./Test-proxied-https-auth.px echo echo /bin/sh: ./Test-proxied-https-auth.px: No such file or directory After commenting that line out, the following tests are also missing: ./Test-proxy-auth-basic.px ./Test-N-current-HTTP-CD.px Test-N-HTTP-Content-Disposition.px fails, since it didn't add the - --content-disposition flag to the wget invocation. Several Test--spider-* tests fail, because an expected error code of 256 is impossible (exit status is truncated to 8 bits). Also, your hand-rolled Makefile.in don't support --datarootdir. I'm not sure whether you are interested in migrating to using Automake, which would solve a number of these issues; let me know if you would be interested in such a patch. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhGkA0ACgkQ84KuGfSFAYAyvgCffHFFioWeTT+8sTn8O6YzdfM1 y7MAn12XTpxo1PiMtIwALxm1KrqsKROS =xKOZ -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature
RE: GNU Coding Standard compliance
Eric - Why are you trying to package Wget for cygwin when there is a *native* win32 exe? Seems like a whole *lot* of work for something that really doesn't gain you anything. I'm quite interested in your response. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 7:52 AM To: [EMAIL PROTECTED] Subject: GNU Coding Standard compliance -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to package wget-1.11.3 for cygwin. But you have several GNU Coding Standard compliance problems that is making this task more difficult than it should be. GCS requires that your testsuite be run by 'make check', but yours is a no-op. Instead, you provide 'make test', but that fails to compile if you use a VPATH build. And even when using an in-tree build, it fails as follows: ./Test-proxied-https-auth.px echo echo /bin/sh: ./Test-proxied-https-auth.px: No such file or directory After commenting that line out, the following tests are also missing: ./Test-proxy-auth-basic.px ./Test-N-current-HTTP-CD.px Test-N-HTTP-Content-Disposition.px fails, since it didn't add the - --content-disposition flag to the wget invocation. Several Test--spider-* tests fail, because an expected error code of 256 is impossible (exit status is truncated to 8 bits). Also, your hand-rolled Makefile.in don't support --datarootdir. I'm not sure whether you are interested in migrating to using Automake, which would solve a number of these issues; let me know if you would be interested in such a patch. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhGkA0ACgkQ84KuGfSFAYAyvgCffHFFioWeTT+8sTn8O6YzdfM1 y7MAn12XTpxo1PiMtIwALxm1KrqsKROS =xKOZ -END PGP SIGNATURE-
RE: wget running in windows Vista
OK - ignore what I said - I've been immersed in vista security these days, so thought there might be some issues with wget and uac. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Alan Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 31, 2008 4:06 PM To: Liz Labbe; wget@sunsite.dk Subject: Re: wget running in windows Vista What version of wget? What edition of Vista? I have used the wget 1.10.2 on Vista before. Alan - Original Message - From: Christopher G. Lewis [EMAIL PROTECTED] To: Liz Labbe [EMAIL PROTECTED]; wget@sunsite.dk Sent: Thursday, January 31, 2008 8:22 AM Subject: RE: wget running in windows Vista On Vista, you probably have to run in an administrative command prompt. Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Liz Labbe [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 10:57 PM To: wget@sunsite.dk Subject: wget running in windows Vista I just downloaded WGET and am trying to get it to work under Window's Vista operating system. I cannot get it to connect: for example, I tried wget http://www.yahoo.com/ wget force_html=on http://www.yahoo.com/ etc. I consistently get the message connecting to www.yahoo.com|99.99.99.99|99., Failed...network is down. Is there an issue with Vista or am I doing something wrong? Thanks, Liz __ __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
RE: wget running in windows Vista
On Vista, you probably have to run in an administrative command prompt. Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Liz Labbe [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 10:57 PM To: wget@sunsite.dk Subject: wget running in windows Vista I just downloaded WGET and am trying to get it to work under Window's Vista operating system. I cannot get it to connect: for example, I tried wget http://www.yahoo.com/ wget force_html=on http://www.yahoo.com/ etc. I consistently get the message connecting to www.yahoo.com|99.99.99.99|99., Failed...network is down. Is there an issue with Vista or am I doing something wrong? Thanks, Liz __ __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs smime.p7s Description: S/MIME cryptographic signature
RE: Release: GNU Wget 1.11
You've all trumped my announcement! :-) Anyway - I've built the windows files for 1.11 and posted them to my web site: http://www.christopherlewis.com/WGet/WGetFiles.htm . The SSL libraries are still 0.9.8b, and are included in the download. Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 12:19 AM To: Wget Subject: Re: Release: GNU Wget 1.11 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Accidentally hit Reply instead of Reply-All) Willener, Pat wrote: Are there any 1.11 executables available for any platforms? Not from us; we just release the source packages. I suspect that Noèl Köthe will probably have Debian unstable packages out before too long (and RedHat and derivatives already have a large portion of the 1.11 code in their 1.10.2 packages ;) ). Windows binaries are kept regularly updated by Christopher Lewis (http://www.christopherlewis.com); I imagine there'll be an official 1.11 package there shortly, but actually, the existing TRUNK package there is not very dissimilar from the final 1.11 release, so might as well grab that (if you're looking for Windows binaries). However, if you're on a Unix-like system, the source packages are intended to be pretty easy to compile into binaries (read the INSTALL instructions provided). You should probably have the development version of the OpenSSL packages (the libssl-dev package on Debian systems; openssl-devel on RedHat derivatives). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHnXPI7M8hyUobTrERAlazAJ9lFaH3XGBRD95h4MMGxe3O+O/TPwCgimkr cR7C+gDTbikB/H+q8EIaCuQ= =NKks -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature
RE: wget 1.11
Micah - I've been quite busy with work stuff (end of the year is killer for me) so can you give me a quick update on what needs to be done for wget for 1.11 Currently, I've got a batch file for getting the current wget: C:\Projects\Hg\Wgettype HgGet_1.11.bat @ECHO OFF Pushd 1.11 hg pull http://hg.addictivecode.org/wget/1.11 hg update PopD Which, I believe, gets the current wget from the 1.11 branch and applies (updates) the changes. As stated below, nothing has changed recently. Building this shows the following version: C:\CVSProjects\Hg\Wget\1.11src\wget.exe --help GNU Wget 1.10+devel, a non-interactive network retriever. Usage: wget [OPTION]... [URL]... So this is still flagged as 1.10+dev. Note that I was never able to get *any* of the automated stuff into the MAKE file for the windows version. NMake just doesn't have the capabilities that you are putting into the unix versions, and (reiterating) I am quite hesitant to put something into the build process that requires anything but the basic compiler. I really believe that having the build process dependant on the source control system is a *bad* idea. Also, as it stands - I haven't updated my automated build to Hg - so it's still building off of SVN. I'm tempted to just post the 1.11 branch as it stands as a beta release, but again, haven't had much time. Any insight would be indeed helpful at this point. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Sunday, January 20, 2008 4:19 PM To: Jochen Roderburg Cc: wget@sunsite.dk Subject: Re: wget 1.11 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jochen Roderburg wrote: Hi Michael, Just curious: what is now holding back a release of the 1.11 version? *sigh*, just waiting on the disclaimer from my employer. I actually really expect to get that finished up this week, though. I'm told that the company lawyer has already approved it, but they need to get that approval back in writing, so it should be _really_ soon. I have not seen any changes in the source repository for a month. Well, that's a separate issue. :) There'll be an influx of check-ins releated to new translations shortly before 1.11 goes out. However, holdups in 1.11 are no excuse for me not to be working on 1.12. I've been a bit short on time lately, but hope to get back into the swing of things. Even so, I think some of the changes I was last working on may not have been complete enough to check into public repos. I'm currently working on some of the things to do with make check, which is currently broken in the mainline repo. I'm not certain whether I intend to fix it as it is. The unit tests will definitely stay, and perhaps be augmented; however, the functionality, .px tests, I'm less sure about. They would be a terrific asset if they were all returning pass/fail values instead of relying on human analysis; probably I need to manually prowl through them and modify them so they're suitable for automation, and discard those that cannot be. I do not intend to make testing involve a lot of manual labor: that labor should go into bug-smashing. :) After that, I'll probably be doing some non-functional changes, such as refactoring. I wasn't planning on doing public checkins of that until it's complete, but perhaps it would be wise at this juncture, given my rate of progress, to start a new repo to hold that work, so it's at least visible. I have been spending some time in thought and rough design for Wget 2.0 stuff, but nothing worth sharing just yet. And I have already again a number of my strange cases which I did not want to report during the last minutes before the anticipated release ;-) Oh noes!... well, better sock 'em to me. Better to know about them than to remain ignorant, at any rate. The worst that can happen is I decide to punt 'em until a 1.11 patch release, or later: and if they're really _really_ awful (which seems relatively unlikely at this point, but...), then I'll want to fix them ASAP before the release. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHk8ju7M8hyUobTrERAnlXAJ4uAiuPA540xYARCOYvBL6EHPU5AACePUOz iSWr+wXyx09YfKeaeFRnnWA= =btLR -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature
RE: .1, .2 before suffix rather than after
Hmm - changing the rename schema would potentially create a HUGE issue with clobbering. For example, and quite hypothetical... Given a directory with the following: index.html index-1.html index.1.html All three are served by the server and rendered by the browser. They are distinct files given the file system and the URL interpretation of the file system by the web server. Now, Wget downloads index.html, then downloads it again. Our choices for the second file are: 1) index.html.1 2) index-1.html 3) index.1.html Of the three, only #1 is pretty much guaranteed *not* to exist on the web server. Why? Because by changing the extension, we've changed the content type. So if our intentions are to not clobber (which, I believe, is the whole point) we are *much* better off sticking with the current schema and creating a file that most can't be served by the web server. Note that this is quite a contrived example to illustrate the point. However, my 2 cents on the behavior - It would be *wonderful* if wget could look at the local file system and rename each version to file.ext.n+1 so the new download is index.html, not index.html.1. I've been caught a couple of times with this, so to me the default behavior is backwards (ie, new file s/b the URL, older files get versioned) Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] Sent: Sunday, November 04, 2007 4:19 PM To: Wget Cc: Christian Roche Subject: Re: .1, .2 before suffix rather than after Hrvoje Niksic [EMAIL PROTECTED] writes: Micah Cowan [EMAIL PROTECTED] writes: Christian Roche has submitted a revised version of a patch to modify the unique-name-finding algorithm to generate names in the pattern foo-n.html rather than foo.html.n. The patch looks good, and will likely go in very soon. foo.html.n has the advantage of simplicity: you can tell at a glance that foo.n is a duplicate of foo. Also, it is trivial to remove the unwanted files by removing foo.*. It just occurred to me that this change breaks backward compatibility. It will break scripts that try to clean up after Wget or that in any way depend on the current naming scheme. smime.p7s Description: S/MIME cryptographic signature
RE: version.c take two
Micah -
I haven't tested this yet, but I've been pondering on the impact of having
a dependency on Hg for the actual build process of Wget. Seems like an
awful lot of trouble for a product that in the past has only needed
Make|Nmake and a C compiler.
Is it possible with Hg to create a file that consists of the TIP Output?
We could then echo this back through this section of the make file rather
then using Hg to create it.
What I'm concerned with is someone who downloads the source from a
zip/tarball. Requiring them to have Make|Nmake and a C compiler is
reasonable. Requiring a source control tool (Hg, svn, etc) is not.
Chris
Christopher G. Lewis
http://www.ChristopherLewis.com
-Original Message-
From: Micah Cowan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 16, 2007 6:07 PM
To: wget@sunsite.dk
Cc: Gisle Vanem; Christopher G. Lewis
Subject: Re: version.c take two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Micah Cowan wrote:
Gisle and Chris, you should be able to write this rule in your
Makefiles. Something like:
version.c: $(SOURCES)
echo 'const char *version_string = @VERSION@' $@
-hg log -r tip --template=' ({node|short})\n' $@
echo ';' $@
Actually, the hg line ought to be:
-hg log -r . --template=' ({node|short})\n' $@
As the user may not necessarily be building from tip. If
closing stderr
or directing it to the equivalent of /dev/null (2NULL?) is
possible,
that should also be included.
- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFUQu7M8hyUobTrERCJORAJ4uOqqiuBCyjqGJMnBWIy8xlOeZ/wCggYTt
Saas407pZa3Xpb9joJcxEts=
=kX7O
-END PGP SIGNATURE-
smime.p7s
Description: S/MIME cryptographic signature
RE: Version tracking in Wget binaries
OK, so I'm trying to be open minded and deal with yet another version control system. I've cloned the repository and built my mainline. I do not autogenerate a version.c file in windows. Build fails missing version.obj. Note that in the windows world, we use Nmake from the MSVC install - no GNU tools required. An aside on Hg... Confirm for me that I basically need to do the following: Create a clone repository: hg clone http://hg.addictivecode.org/wget/mainline Get any changes from mainline into my clone hg pull http://hg.addictivecode.org/wget/mainline Make my src changes, create a changeset... And then I'm lost... And as a follow-up question - what does Hg get you above and beyond CVS or SVN? I kind of get the non-centralized aspect of repositories and clones, but I don't understand how changesets and tips work. My thoughts are that there is *one* source of the code (with histories) regardless of SVN, Hg or whatever. Hg's concept of multiple clones and repositories is quite interesting, but doesn't feel right for the remote, non-connected group of developers that wget gathers input from. If we were all behind a firewall or could share out each user's repository, it might make more sense, but I (for one) wouldn't be able to share my repository (NAT'd, firewalled, corporate desktop), so I just don't get it. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Saturday, October 13, 2007 4:59 AM To: Wget Subject: Re: Version tracking in Wget binaries -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Micah Cowan wrote: Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Among other things, version.c is now generated rather than parsed. Every time make all is run, which also means that make all will always relink the wget binary, even if there haven't been any changes. I personally find that quite annoying. :-( I hope there's a very good reason for introducing that particular behavior. Well, making version.c a generated file is necessary to get the most-recent revision for the working directory. I'd like to avoid it, obviously, but am not sure how without making version.c dependent on every source file. But maybe that's the appropriate fix. It shouldn't be too difficult to arrange; probably just version.c: $(wget_SOURCES) or similar. version.c is no longer unconditionally generated. The secondary file, hg-id, which is generated to contain the revision id (and is used to avoid using GNU's $(shell ...) extension, which autoreconf complains about), depends on $(wget_SOURCES), and $(LDADD) (so that it properly includes conditionally-used sources such as http-ntlm.c or gen-md5.c when applicable). This has the advantage that every make does not result in regenerating version.c, recompiling version.c and relinking wget. It has the potential disadvantage that, since $(wget_SOURCES) includes version.c itself, there is the circular dependency: version.c - hg-id - version.c. GNU Make is smart enough to catch that and throw that dependency out. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHEJb07M8hyUobTrERCE4rAJ9gKXonGN9bRydErVkxtZF8g723CACeLbhD VYUyd0MnjBdjcRXMSTge0ZE= =cC2V -END PGP SIGNATURE-
Fix for Warning C4142 in windows
Warning_C4142_Fix.diff Windows added support of intptr_t and uintptr_t with Visual Studio 2003 (MSVER 1310) This patch removes 60+ warnings from the MSWindows build Chris Christopher G. Lewis http://www.ChristopherLewis.com Warning_C4142_Fix.diff Description: Warning_C4142_Fix.diff
Spider.C
Micah - Your latest checkin for Spider.C breaks the windows build: link @C:\DOCUME~1\chris\LOCALS~1\Temp\nm142.tmp /opt:ref /out:wget.exe cmpt.obj safe-ctype.obj convert.obj conne ct.obj host.obj http.obj netrc.obj ftp-basic.obj ftp.obj ftp-ls.obj ftp-opie.obj getopt.obj hash.obj html-pars e.obj html-url.obj progress.obj retr.obj recur.obj res.obj url.obj cookies.obj init.obj utils.obj main.obj ptimer.obj v ersion.obj xmalloc.obj mswindows.obj gen-md5.obj gnu-md5.obj log.obj openssl.obj http-ntlm.obj spider.obj kernel32.lib advapi32.lib wsock32.lib user32.lib gdi32.lib libeay32.lib ssleay32.lib Microsoft (R) Incremental Linker Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. spider.obj : error LNK2019: unresolved external symbol _ngettext referenced in function _print_broken_links wget.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\link.EXE' : return code '0x460' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : return code '0x2' Stop. Looks like here: logprintf (LOG_NOTQUIET, ngettext(Found %d broken link.\n\n, Found %d broken links.\n\n, num_elems), num_elems); ngettext not defined anywhere Christopher G. Lewis http://www.ChristopherLewis.com smime.p7s Description: S/MIME cryptographic signature
RE: Man pages [Re: ignoring robots.txt]
Micah et al. - Just for an FYI - the whole texi-info, texi-html and (texi-rtf-hlp) is *very* fragile in the windows world. You actually have to download a *very* old version of makeinfo (1.68, not even on available on http://www.gnu.org/software/texinfo/) that supports RTF generation. Any progress that we take to work on this should look at a new texi-hlp (or chm) process or abandon the HLP format completely. The HLP format is kind of nice since you don't get one large HTML file, and has searching etc. But I believe there are issues w/ HLP files on either x64 or Vista (can't recall off the top of my head). So if it has to go away, so be it. Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 1:16 PM To: WGET@sunsite.dk Subject: Man pages [Re: ignoring robots.txt] -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel Stenberg wrote: On Wed, 18 Jul 2007, Micah Cowan wrote: The manpage doesn't need to give as detailed explanations as the info manual (though, as it's auto-generated from the info manual, this could be hard to avoid); but it should fully describe essential features. I know GNU projects for some reason go with info, but I'm not in fan of that. Personally I always just use man pages and only revert to using info pages when forced. I simply don't like it when projects hide information in info pages. Well, the original intention, I think, is that the GNU operating system would use info as its primary documentation system, and avoid man altogether. However, since in reality people just used GNU programs on their own preexisting operating systems, which used nroff/man as their primary documentation system, it was useful to provide man pages as well. (AIUI.) Info is, IMO, a superior format to manpages (but only because that's really not saying much). However, my fingers still type man wget rather than info wget much more readily, for two reasons: (1) because only GNU programs tend to use Texinfo, whereas practically everything (including GNU software) uses man pages, so it's far more ubiquitous/habit-forming, and (2) I'm usually looking for a quick reference, not an easy-reading manual: I'm pulling man up to type /something-or-otherRET, which, for me, is easiest on an all-in-one reference page, than in a separated-by-node info manual. However, when I'm actually looking to read up on a _subject_, rather than an option or rc command, I'll use the Texinfo manual, since that's what it's better-suited for. Regardless of personal or group feelings about info, though, I pretty much have to have documentation in Texinfo format, as it's expected of GNU projects. However, Texinfo doesn't need to be the _source_ format; and this discussion makes me toy with the prospect of switching to DocBook XML. But I'm not sure I want to be rewriting the manual at this point. :p - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn6ps7M8hyUobTrERCIn5AKCAAk0/4ThESmTO82CYlfye+cNaKQCfVbJI c/w+nbC8zasi0gS1VNkkETs= =ZkQE -END PGP SIGNATURE-
RE: WGET Dev branch BROKEN
Micah - If I revert HTTP.C to version 2206, the tree builds fine, and http://curl.haxx.se/ca/cacert.pem works. Newest version is 2211, and the request fails. Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 5:12 PM To: Christopher G. Lewis Cc: wget@sunsite.dk Subject: Re: WGET Dev branch BROKEN -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christopher G. Lewis wrote: OK - (First of all, welcome to Micah - thanks for working with us :-) My pleasure! :-) Sorry I didn't catch this earlier, but it looks like something broke in the dev branch recently. I've got a batch that autobuilds the SVN dev tree and posts the results to my windows wget page. Part of that build is to grab the cacert.PEM from the curl site. Recently, the SRC\WGET.EXE file wasn't able to download this URL _http://curl.haxx.se/ca/cacert.pem_ Can you tell me when this build's working directory was updated? The debug output seems to indicate that Mauro's recent change to not issue HEAD unless we're timestamping and there's a local file isn't in this version (or else, that change wasn't complete). If the breakage is recent, can you tell me around what date it had been known to be working last? BTW, Chris, no need to send mail to both wget@sunsite.dk and [EMAIL PROTECTED]: the latter is actually just aliased to the former! :) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjWzA7M8hyUobTrERCEruAJ9WlAq1WN/siDiXKd4Q0yq/82RwSQCfWjEX RvnUU7IlnOCwZQOSPDS28vk= =rSA1 -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature
WGET Dev branch BROKEN
, awaiting response... ---response begin--- HTTP/1.1 200 OK Date: Thu, 05 Jul 2007 05:45:03 GMT Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-19 mod_ssl/2.8.22 OpenSSL/0.9.7e Last-Modified: Wed, 04 Jul 2007 03:14:18 GMT ETag: 15e9b8-68168-468b108a Accept-Ranges: bytes Content-Length: 426344 Keep-Alive: timeout=15, max=80 Connection: Keep-Alive Content-Type: text/plain; charset=iso-8859-1 ---response end--- 200 OK Length: 426344 (416K) [text/plain] 00:45:20 (0.00 B/s) - Connection closed at byte 0. Giving up. Christopher G. Lewis http://www.ChristopherLewis.com smime.p7s Description: S/MIME cryptographic signature
Patch for Windows Build
The following patch adds support for adding required files to the wget.zip file when running NMAKE wget.zip -or- NMAKE bindist This patch also fixes the missing msvcr80.dll file from my original patch. It's dependant on OpenSSL being installed to the default directory C:\OpenSSL. ChangeLog 2006-06-25 Christopher Lewis chris at christopherlewis.com * Windows\Makefile.top: Added OpenSSL dlls and cacert.pem to wget.zip to further automate the Win32 build process * Windows\Makefile.top.bor: Added OpenSSL dlls and cacert.pem to wget.zip to further automate the Win32 build process 2007-01-23 Christopher Lewis chris at christopherlewis.com * Windows\Makefile.top: Added the required file msvcr80.dll. This file is required by OpenSSL. * Windows\Makefile.top.bor: Added the required file msvcr80.dll. This file is required by OpenSSL. Christopher G. Lewis http://www.ChristopherLewis.com makefile.top.diff Description: Binary data smime.p7s Description: S/MIME cryptographic signature
Windows build process is now automated
Hey everyone - While the Beta build of 1.11 is going on, I've hacked together an automated script to build the SVN trunk for the Windows version. Files are located here: http://www.christopherlewis.com/WGet/WGetFiles.htm Chris Christopher G. Lewis http://www.ChristopherLewis.com smime.p7s Description: S/MIME cryptographic signature
RE: wget 1.11 beta 1 released
I've updated the Windows binaries to include Beta 1, and included a binary with Beta 1 + today's patch 2186 2187 for spider recursive mode. Available here: http://www.ChristopherLewis.com\wget And sorry to those who have been having some problems downloading the ZIPs from my site. I had some weird IIS gzip compression issues. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 10:01 AM To: wget@sunsite.dk Subject: wget 1.11 beta 1 released hi to everybody, i've just released wget 1.11 beta 1: ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-beta-1.tar.gz you're very welcome to try it and report every bug you might encounter. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
RE: Non-debug build in Win32
OK, I'm not a big C programmer, so please bear with me. What I'm trying to do is do a build in win32 without debug support. Fine, should be simple :-) Reading the windows\README file is no help - it states to build in Win32 use the following commands: Configure.bat --msvc Nmake Hmm. OK, there's the config.h file. Lets edit that and comment out ENABLE_DEBUG: config.h /* Define if you want the debug output support compiled in. */ /* #define ENABLE_DEBUG 1 */ After futzing around for a little while, I got it to work. I had Whole Program Optimization (CC's /GL and link's /LTCG) turned on in my VS project file, and I think it was trying to optimize a header issue btwn log.h and log.c when ENABLE_DEBUG wasn't defined. Still - I'd like to figure out some better way of dealing with the configure options in the windows world: --without-ssl disable SSL autodetection (used for https support) --with-libssl-prefix=DIR search for libssl in DIR/lib --disable-opie disable support for opie or s/key FTP login --disable-digestdisable support for HTTP digest authorization --disable-ntlm disable support for HTTP NTLM authorization --disable-debug disable support for debugging output --disable-nls do not use Native Language Support --disable-largefile omit support for large files --disable-ipv6 disable IPv6 support --disable-rpath do not hardcode runtime library paths Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 11:58 AM To: Christopher G. Lewis Cc: wget@sunsite.dk Subject: Re: Non-debug build in Win32 Christopher G. Lewis [EMAIL PROTECTED] writes: For some reason, a change that was made in log.c between 1.8 and 1.9 has broken the ability to do a build without debug enabled. Basically, in config.h if you change ENABLE_DEBUG to 0, wget will no longer build. That's not how it works, you're supposed to not #define ENABLE_DEBUG in the first place (or #undef it), not #define it to 0. If you configure Wget with --disable-debug, this is done for you automatically. As far as I know, setting ENABLE_DEBUG to 0 has never been supported. For me, setting ENABLE_DEBUG to 0 still builds, but you get a Wget that has debugging support anyway. I'm wondering if it makes sense to even have the ability to create a non-debug build at this point. It makes sense now as much as it did before -- there are people who prefer their executables small, and since we have a macro for debug prints anyway, the option comes with no additional price.
Non-debug build in Win32
Title: Non-debug build in Win32 Hi everyone - For some reason, a change that was made in log.c between 1.8 and 1.9 has broken the ability to do a build without debug enabled. Basically, in config.h if you change ENABLE_DEBUG to 0, wget will no longer build. Hrvoje made a change on 2003-10-08 2003-10-08 Hrvoje Niksic [EMAIL PROTECTED] * config.h.in: Renamed DEBUG to ENABLE_DEBUG. ENABLE_DEBUG is, I think, a better name, because it implies that debugging output is merely possible, not on by default, as might be construed from just DEBUG. That possibly broke it. I'm wondering if it makes sense to even have the ability to create a non-debug build at this point. Chris Christopher G. Lewis http://www.ChristopherLewis.com BEGIN:VCARD VERSION:2.1 N:Lewis;Christopher;G. FN:Christopher G. Lewis (Christopher G. Lewis) ([EMAIL PROTECTED]) ORG:Bank Of America TEL;WORK;VOICE:(312) 234-2398 TEL;HOME;VOICE:(773) 529-8401 TEL;CELL;VOICE:(312) 758-2610 TEL;WORK;FAX:(773) 529-8402 TEL;HOME:(773) 529-8402 ADR;WORK:;;233 S Wacker Dr.;Chicago;IL;60606-6306;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:233 S Wacker Dr.=0D=0AChicago, IL 60606-6306=0D=0AUnited States of America ADR;HOME:;;2030 W. Fletcher St.;Chicago;IL;60618;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:2030 W. Fletcher St.=0D=0AChicago, IL 60618=0D=0AUnited States of America URL;WORK:http://www.christopherlewis.com EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20060328T041956Z END:VCARD smime.p7s Description: S/MIME cryptographic signature
Wget Win32 Visual Studio project
Hi everyone - I've uploaded a working Visual Studio project file for the current TRUNK in subversion. I'm pretty sure this is the 1.11 Alpha branch. The project allows building a debug and release version, although the release version still is compiled with ENABLE_DEBUG on. See my previous post for some concerns about this. Note that the debug build of Win32 Wget allows debugger attachment, stepping through code, etc. http://www.christopherlewis.com/WGet/default.htm Christopher G. Lewis http://www.ChristopherLewis.com BEGIN:VCARD VERSION:2.1 N:Lewis;Christopher;G. FN:Christopher G. Lewis (Christopher G. Lewis) ([EMAIL PROTECTED]) ORG:Bank Of America TEL;WORK;VOICE:(312) 234-2398 TEL;HOME;VOICE:(773) 529-8401 TEL;CELL;VOICE:(312) 758-2610 TEL;WORK;FAX:(773) 529-8402 TEL;HOME:(773) 529-8402 ADR;WORK:;;233 S Wacker Dr.;Chicago;IL;60606-6306;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:233 S Wacker Dr.=0D=0AChicago, IL 60606-6306=0D=0AUnited States of America ADR;HOME:;;2030 W. Fletcher St.;Chicago;IL;60618;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:2030 W. Fletcher St.=0D=0AChicago, IL 60618=0D=0AUnited States of America URL;WORK:http://www.christopherlewis.com EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20060328T041956Z END:VCARD
RE: 1.11 Alpha 1 Win32 files
http://support.microsoft.com/default.aspx?scid=kb;en-us;326922 Using the ResKit tool Depends on the SSL libs, it looks like the MSVCR80.dll will need to be included. However, WGET itself doesn't have the dependancy. I'm researching this, and should be able to have an answer today. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: www.mail [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 5:12 AM To: Christopher G. Lewis; wget@sunsite.dk Subject: Re: 1.11 Alpha 1 Win32 files Hi Chris, Thanks for the new binaries. The new SSL libraries, v0.9.8b, on your site require msvcr80.dll, which v0.9.7g didn't. Please could you tell me where to get this DLL. I tried the one from http://www.dll-files.com/dllindex/pop.php?msvcr80 but wget gave the error: The procedure entry point _encode_pointer could not be located in the dynamic link library MSVCR80.dll Regards, Jonny At 21:30 25/06/2006, you wrote: Hi all - I've published the latest alpha Win32 binaries using a similar format to Heiko's Win32 page. Hopefully I'll be able to keep up with what Heiko's done in the past, which has been excellent. Heiko deserves a big round of cheers for his work. The location for the downloads will be http://www.christopherlewis.com/wget/default.htm. Right now this is just a page off my personal web site, hopefully we'll just be able to add these to the normal wget site. Christopher G. Lewis http://www.ChristopherLewis.com
RE: 1.11 Alpha 1 Win32 files
Jonny - I've updated the wget-1.11-alpha-1b.zip and the ssllibs.098b.b.zip to include the MSVCR80.DLL file. http://www.ChristopherLewis.com/WGet I'm not sure when I'll have the ability to check on Windows 2000, but since it's so similar to XP/2003 I don't think it will be a problem. The current compile passed a smoke test on Win98 - I really should have a test script :-) Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: www.mail [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 5:12 AM To: Christopher G. Lewis; wget@sunsite.dk Subject: Re: 1.11 Alpha 1 Win32 files Hi Chris, Thanks for the new binaries. The new SSL libraries, v0.9.8b, on your site require msvcr80.dll, which v0.9.7g didn't. Please could you tell me where to get this DLL. I tried the one from http://www.dll-files.com/dllindex/pop.php?msvcr80 but wget gave the error: The procedure entry point _encode_pointer could not be located in the dynamic link library MSVCR80.dll Regards, Jonny At 21:30 25/06/2006, you wrote: Hi all - I've published the latest alpha Win32 binaries using a similar format to Heiko's Win32 page. Hopefully I'll be able to keep up with what Heiko's done in the past, which has been excellent. Heiko deserves a big round of cheers for his work. The location for the downloads will be http://www.christopherlewis.com/wget/default.htm. Right now this is just a page off my personal web site, hopefully we'll just be able to add these to the normal wget site. Christopher G. Lewis http://www.ChristopherLewis.com
RE: 1.11 Alpha 1 Win32 files
Currently, I'm just doing the compile with the following from my Wget root: Configure.bat --msvc NMAKE My config is as follows: Active Perl 5.8.4.810 VC++ 2005 Express (free from Microsoft) http://msdn.microsoft.com/vstudio/express/visualc/ Current MS Platform SDK Full Install: http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4 969-ACE8-E4C0C0716ADBdisplaylang=en Note that I only selected Win32 CORE for the SDK components, so it's only 750 MB MakeInfo stuff (to be determined) Either A) OpenSSL 0.9.8b LIB, H and DLL files B) OopenSSL 0.9.8b source (See below) Start up a VC++ environment, either by selecting Visual Studio 2005 Command Prompt from the start menu or starting a CMD and running C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat x86 To do your compile, make sure that the OpenSSL files are installed and the environ vars are set correctly: Set INCLUDE=%Include%;C:\OpenSSL\Include Set LIB=%LIB%;C:\OpenSSL\Lib Set PATH=%PATH%;C:\OpenSSL\Bin To compile OpenSSL, you will also need the following: MASM for VC++ 2005 Express http://www.microsoft.com/downloads/details.aspx?familyid=7A1C9DA0-0510-4 4A2-B042-7EF370530C64displaylang=en OpenSSL 0.9.8b from http://www.openssl.org/ I've included my full OpenSSL directory (extract to C:\) on the download page, available here: http://www.christopherlewis.com/WGet/openssl.098b.full.zip Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: bruce [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 10:13 PM To: Christopher G. Lewis Cc: wget@sunsite.dk Subject: RE: 1.11 Alpha 1 Win32 files hey chris... did you use the msoft ide visual studio? or did you simply do a configure/nmake process i'm looking to figure out how to set up the visual studio ide... thanks bruce -Original Message- From: Christopher G. Lewis [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 7:11 PM To: www.mail; wget@sunsite.dk Subject: RE: 1.11 Alpha 1 Win32 files Jonny - I've updated the wget-1.11-alpha-1b.zip and the ssllibs.098b.b.zip to include the MSVCR80.DLL file. http://www.ChristopherLewis.com/WGet I'm not sure when I'll have the ability to check on Windows 2000, but since it's so similar to XP/2003 I don't think it will be a problem. The current compile passed a smoke test on Win98 - I really should have a test script :-) Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: www.mail [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 5:12 AM To: Christopher G. Lewis; wget@sunsite.dk Subject: Re: 1.11 Alpha 1 Win32 files Hi Chris, Thanks for the new binaries. The new SSL libraries, v0.9.8b, on your site require msvcr80.dll, which v0.9.7g didn't. Please could you tell me where to get this DLL. I tried the one from http://www.dll-files.com/dllindex/pop.php?msvcr80 but wget gave the error: The procedure entry point _encode_pointer could not be located in the dynamic link library MSVCR80.dll Regards, Jonny At 21:30 25/06/2006, you wrote: Hi all - I've published the latest alpha Win32 binaries using a similar format to Heiko's Win32 page. Hopefully I'll be able to keep up with what Heiko's done in the past, which has been excellent. Heiko deserves a big round of cheers for his work. The location for the downloads will be http://www.christopherlewis.com/wget/default.htm. Right now this is just a page off my personal web site, hopefully we'll just be able to add these to the normal wget site. Christopher G. Lewis http://www.ChristopherLewis.com
1.11 Alpha 1 Win32 files
Hi all - I've published the latest alpha Win32 binaries using a similar format to Heiko's Win32 page. Hopefully I'll be able to keep up with what Heiko's done in the past, which has been excellent. Heiko deserves a big round of cheers for his work. The location for the downloads will be http://www.christopherlewis.com/wget/default.htm. Right now this is just a page off my personal web site, hopefully we'll just be able to add these to the normal wget site. Christopher G. Lewis http://www.ChristopherLewis.com BEGIN:VCARD VERSION:2.1 N:Lewis;Christopher;G. FN:Christopher G. Lewis (Christopher G. Lewis) ([EMAIL PROTECTED]) ORG:Bank Of America TEL;WORK;VOICE:(312) 234-2398 TEL;HOME;VOICE:(773) 529-8401 TEL;CELL;VOICE:(312) 758-2610 TEL;WORK;FAX:(773) 529-8402 TEL;HOME:(773) 529-8402 ADR;WORK:;;233 S Wacker Dr.;Chicago;IL;60606-6306;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:233 S Wacker Dr.=0D=0AChicago, IL 60606-6306=0D=0AUnited States of America ADR;HOME:;;2030 W. Fletcher St.;Chicago;IL;60618;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:2030 W. Fletcher St.=0D=0AChicago, IL 60618=0D=0AUnited States of America URL;WORK:http://www.christopherlewis.com EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20060328T041956Z END:VCARD
RE: Windows compler need (was RE: wget 1.11 alpha 1 released)
OK, the Win32 compile is working, I've got both the SVN Trunk and the 1.11 alpha branch from ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz . We'll obviously work through the warnings that are coming up, and re-address the CL parameters to fit with the VS 2005 C Compiler. I think we should make this the default supported compiler for the 1.11 release if we can confirm that we compile with VC++ Express (which is free from MS). We should also double check on OpenSSL, since MS has now includes MASM as a free download for VC++ Express users. I'm going to have to spin up a VM to test the VC++ Express compile - I should be able to do this sometime this weekend. The only other issue I have right now is the MakeInfo program doesn't seem to be working correctly. I downloaded the latest version from GNU (TextInfo 4.8), but it doesn't seem to support the --hpj parameter: c:\CVSProjects\Wget\wget-1.11-alpha-1\docmakeinfo --version makeinfo (GNU texinfo) 4.8 Copyright (C) 2004 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. c:\CVSProjects\Wget\wget-1.11-alpha-1\docnmake Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. makeinfo.exe --no-validate --no-warn --force --hpj wget.hpj --output wget.rtf wget.texi C:\Program Files\GnuWin32\bin\makeinfo.exe: unrecognized option `--hpj' Try `makeinfo --help' for more information. hcrtf -xn wget.hpj So am not able to produce the Help file. Note that I do remember at one point in around the 1.6 or 1.8 branch I was able to get this to work. I guess that's what I get for Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Herold Heiko [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 8:02 AM To: Christopher G. Lewis Subject: RE: Windows compler need (was RE: wget 1.11 alpha 1 released) Hi, only Travis Loyd, however from what I've seen I don't think he realized we'd been talking about visual c, so I think you would be the only candidate. Thanks for your offer, we will all be grateful! Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 / +39-041-5917073 ph -- +39-041-5907472 / +39-041-5917472 fax -Original Message- From: Christopher G. Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 4:10 AM To: Herold Heiko Subject: RE: Windows compler need (was RE: wget 1.11 alpha 1 released) Herold - Has anyone volunteered for the Win32 native build yet? I'd be willing to at least attempt the build process, although the last build I did was 1.9 (to attempt to work out some ntlm proxy issues I was having) Thanks for all the work. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Herold Heiko [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:37 AM To: wget@sunsite.dk Subject: Windows compler need (was RE: wget 1.11 alpha 1 released) Everybody, if there is somebody willing to step in as compiler of official windows binaries please let yourself heared. As I mentioned before currently I've have neither means nor time to provide even release version binaries, develpoment-HEAD/alpha/beta builds are stuff of dreams; yet there should be downloadable builds for all these, too. Beside that I think the current (soon-to-be old) release 1.10 binary should be moved from my home page to the official site, possibly the ftp server (which needs a good cleaning out) or somewhere else. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 / +39-041-5917073 ph -- +39-041-5907472 / +39-041-5917472 fax -Original Message- From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 5:06 PM To: wget@sunsite.dk Subject: wget 1.11 alpha 1 released hi to everybody, i've just released wget 1.11 alpha 1: ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz you're very welcome to try it and report every bug you might encounter. with this release, the development cicle for 1.11 officially enters the feature freeze state. wget 1.11 final will be released when all the following tasks are completed: 1) win32 fixes (setlocale, fork) 2) last fixes to -r and --spider 3) update documentation 4) return error/warning if multiple HTTP headers w/ same name are given 5) return error/warning if conflicting options are given 6) fix Saving to: output in case
RE: wget 1.11 alpha 1 released
Attempting a build with VC 2005: C:\CVSProjects\Wget\trunkconfigure.bat --msvc Type NMAKE to start compiling. If it doesn't work, try executing MSDEV\BIN\VCVARS32.BAT first, and then NMAKE. C:\CVSProjects\Wget\trunknmake Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. cd src C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. cl /nologo /MT /O2 /I. /DWINDOWS /D_CONSOLE /DHAVE_CONFIG_H /DHAVE_SSL /c http.c retr.c utils.c openssl.c http-n tlm.c http.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type http.c(540) : warning C4090: 'function' : different 'const' qualifiers http.c(558) : warning C4090: 'function' : different 'const' qualifiers http.c(736) : warning C4090: 'function' : different 'const' qualifiers retr.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type utils.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type utils.c(1917) : error C2036: 'const void *' : unknown size utils.c(1917) : error C2036: 'const void *' : unknown size openssl.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type http-ntlm.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type Generating Code... c:\cvsprojects\wget\trunk\src\openssl.c(152) : warning C4715: 'key_type_to_ssl_type' : not all control paths return a va lue c:\cvsprojects\wget\trunk\src\http.c(2941) : warning C4715: 'create_authorization_line' : not all control paths return a value NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\cl.EXE' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : return code '0x2' Stop. Looks like the big error is here: utils.c(1902) base64_encode (const void *data, int length, char *dest) A change to char fixes it for Win32 ... base64_encode (const char *data, int length, char *dest) Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 10:06 AM To: wget@sunsite.dk Subject: wget 1.11 alpha 1 released hi to everybody, i've just released wget 1.11 alpha 1: ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz you're very welcome to try it and report every bug you might encounter. with this release, the development cicle for 1.11 officially enters the feature freeze state. wget 1.11 final will be released when all the following tasks are completed: 1) win32 fixes (setlocale, fork) 2) last fixes to -r and --spider 3) update documentation 4) return error/warning if multiple HTTP headers w/ same name are given 5) return error/warning if conflicting options are given 6) fix Saving to: output in case -O is given unfortunately, this means that all the planned major changes (gnunet support, advanced URL filtering w/ regex, etc...) will have to wait until 1.12. however, i think that the many important features and bugfixes recently commited into the trunk more than justify the new, upcoming 1.11 release. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Small change to print SSL version
Here's a small change to print out the OpenSSL version with the -V
--help parameters.
2003-09-16 Christopher G. Lewis [EMAIL PROTECTED]
* main.c (main): Trivial change to show OpenSSL libray version
in
--help and -V
--- wget20030915s/wget.20030915/src/main.c 2003-09-16
12:32:42.0 -0500
+++ wget20030915s_original/wget.20030915/src/main.c 2003-09-15
00:04:14.0 -0500
@@ -131,14 +131,8 @@
static void
print_help (void)
{
-#ifndef HAVE_SSL
printf (_(GNU Wget %s, a non-interactive network retriever.\n),
version_string);
-#else
- printf (_(GNU Wget %s %s, a non-interactive network retriever.\n),
-version_string, SSLeay_version(SSLEAY_VERSION));
-#endif
-
print_usage ();
/* Had to split this in parts, so the #@@#%# Ultrix compiler and cpp
don't bitch. Also, it makes translation much easier. */
@@ -510,11 +504,8 @@
setval (recursive, on);
break;
case 'V':
-printf (GNU Wget %s\n, version_string);
-#ifdef HAVE_SSL
-printf( %s\n,SSLeay_version(SSLEAY_VERSION));
-#endif
-printf (\n%s, _(\
+ printf (GNU Wget %s\n\n, version_string);
+ printf (%s, _(\
Copyright (C) 1995, 1996, 1997, 1998, 2000, 2001 Free Software
Foundation,
Inc.\n));
printf (%s, _(\
This program is distributed in the hope that it will be useful,\n\
