[Bug-wget] PATCH: tests for SSL
Added a framework for perl based SSL tests, and some tests to start with. In case this is of interest, I will add more tests for SSL: client certificates, CRLs, negative tests etc. Also not included : making these tests a part of "make check". TESTING : only on ubuntu 16 Best, Vijo. 0001-Added-Some-Tests-for-SSL.patch.v2 Description: Binary data
Re: [Bug-wget] Too verbose version information
Mojca Miklavecwrites: > I find it a bit annoying that I end up with all of the following > information after building wget: [...] > The first part is reasonable (even if I don't like the fact that the > exact OS version is hardcoded; after security updates the binary will > change only due to the increased minor version, so reproducibility is > lost): Mostly, --version is so that if someone wants to know if the documentation they're reading matches the executable they're running, they can tell. And as Tim said, --version gives the information that a developer needs for a bug report. But you say "reproducibility is lost"... It sounds like you have a need that the current --version cannot be used to satisfy. What is that need? Dale
Re: [Bug-wget] Too verbose version information
On 04/18/2017 04:40 AM, Mojca Miklavec wrote: > Hello, > > I find it a bit annoying that I end up with all of the following > information after building wget: > >> ./src/wget --version > GNU Wget 1.19.1.25-92bf-dirty built on darwin10.8.0. > > -cares +digest -gpgme -https +ipv6 -iri +large-file -metalink -nls > -ntlm +opie -psl -ssl > > Wgetrc: > /usr/local/etc/wgetrc (system) > Compile: > /usr/bin/gcc -DHAVE_CONFIG_H > -DSYSTEM_WGETRC="/usr/local/etc/wgetrc" > -DLOCALEDIR="/usr/local/share/locale" -I. -I../../wget-from-git/src > -I../lib -I../../wget-from-git/lib > -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -DNDEBUG -arch ppc > -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 > Link: > /usr/bin/gcc -DNDEBUG -arch ppc -isysroot > /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch ppc > -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib -isysroot > /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 ftp-opie.o > ../lib/libgnu.a -liconv > > In particular: why should the user be aware of the exact path where I > had wget stored on my hard drive (-I../../wget-from-git/src), of the > fact that I didn't configure in-place and why should the user bother > with so many environmental variables and the fact that the binary was > cross-compiled? > > Is there any way to remove all that information? > > > The first part is reasonable (even if I don't like the fact that the > exact OS version is hardcoded; after security updates the binary will > change only due to the increased minor version, so reproducibility is > lost): > > GNU Wget 1.19.1.25-92bf-dirty built on darwin10.8.0. > > -cares +digest -gpgme -https +ipv6 -iri +large-file -metalink -nls > -ntlm +opie -psl -ssl > > Wgetrc: > /usr/local/etc/wgetrc (system) > > but I would like to have a way to avoid storing so many details in the > second part. This is basically not for the user but for us developers. If someone opens a bug report, (s)he should give us this output, so we can try to reproduce the problem with as less effort as possible. We don't want you to remove this information :-). The users of your package will address us (and not you) with problems. But you are free to privately keep a set of patches to remove this information (and maybe add your own, e.g. your email address for bug reports). Regards, Tim signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 04/18/2017 12:57 PM, Tim Rühsen wrote: > On 04/18/2017 04:27 AM, Mojca Miklavec wrote: >> I copiled a folder with bootstrapped wget to the Solaris box, but as >> expected I ended up with: >> >>> ldd src/wget >> libsocket.so.1 =>/lib/libsocket.so.1 >> libnsl.so.1 => /lib/libnsl.so.1 >> librt.so.1 =>/lib/librt.so.1 >> libiconv.so.2 => /opt/csw/lib/libiconv.so.2 >> libunistring.so.2 => /opt/csw/lib/libunistring.so.2 >> ... >> >> And having libraries from /opt/csw there is simply not acceptable >> since the binaries won't work on machines without OpenCSW installed. >> >> So my next question would be: how can I get rid of dependency on libiconv? >> >> I didn't have this problem in version 1.17.1. >> >> Repeating the configure string: >> >> --enable-ipv6 --disable-iri --disable-nls --disable-ntlm \ >> --disable-pcre --without-libiconv-prefix --without-libintl-prefix \ >> --without-libuuid --without-libpsl --without-ssl --without-zlib > > The OpenCSW Solaris box "unstable10x" and likely all others are > configured to use a GNU environment for building. That includes a > separate 'libiconv.so' as well as system headers being loaded from the > GNU environment. > > ./configure correctly finds and uses the 'iconv.h' and 'libiconv.so' > within the GNU environment. That's not what you want - you basically > want a build on a plain Solaris box so that the 'wget' executable does > not reference any GNU libraries. > > Solaris has iconv functionality built into the libc - so there is no > reason for you not to use it. The question is, how you can do do that. > > You have to do some manual changes (you could set up a shell script > doing that with 'sed'): > > 1. Change include of iconv.h in src/url.h: > > diff --git a/src/url.c b/src/url.c > index 4aaef63..35b8a49 100644 > --- a/src/url.c > +++ b/src/url.c > @@ -44,7 +44,7 @@ as that of the covered work. */ > #include "c-strcase.h" > > #ifdef HAVE_ICONV > -# include > +# include "/usr/include/iconv.h" > #endif > #include > > 2. edit src/Makefile.am to remove -liconv and -lunistring (each has two > occurrences) > > > Now cd into src and 'make clean && make' and your 'wget' executable is > clean: > > ldd wget: > libsocket.so.1 =>/lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > librt.so.1 =>/lib/librt.so.1 > libc.so.1 => /lib/libc.so.1 > libmp.so.2 =>/lib/libmp.so.2 > libmd.so.1 =>/lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libgen.so.1 => /lib/libgen.so.1 > libm.so.2 => /lib/libm.so.2 > > > Maybe there is an easier way on OpenCSW. If you find out, let us know. > > > The problem with using the Solaris compiler and/or iconv() is that there > is a known bug in the implementation that ./configure checks for. > If it finds this bug, HAVE_ICONV will not be defined and compilation of > src/url.c then fails. Just pushed some commits. That should enable you to $ CC=cc ./configure ... (all your options) to get a clean wget executable (with just Solaris system libraries). Regards, Tim signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] Problems with (not) building wget against libiconv
Hi Mojca, On 04/18/2017 04:27 AM, Mojca Miklavec wrote: > On 16 April 2017 at 18:54, Tim Rühsen wrote: >> >> Please make sure, you test with latest wget git. > > I have some problems with bootstrapping. > > On Solaris it's: > >> ./bootstrap > ./bootstrap: syntax error at line 91: `me_=$' unexpected I experience this as well and use 'bash ./bootstrap'. Just pushed a commit to mention this in README.checkout. > On Mac it's: > > sed: 1: "lib/unicase/special-cas ...": extra characters at the end of l > command > ./bootstrap: bootstrap_post_import_hook failed The 'sed' command used in 'bootstrap.conf' seems to be incompatible to GNU sed. Just pushed a commit to make this more portable. Please test and report. > After that the build succeeds, but it's linking against libiconv > (contrary to --without-libiconv-prefix): > >> otool -L wget > wget: > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 125.2.11) > > On Mac that should be OK (I hope), but on Solaris there is no libiconv > by default. > > I copiled a folder with bootstrapped wget to the Solaris box, but as > expected I ended up with: > >> ldd src/wget > libsocket.so.1 =>/lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > librt.so.1 =>/lib/librt.so.1 > libiconv.so.2 => /opt/csw/lib/libiconv.so.2 > libunistring.so.2 => /opt/csw/lib/libunistring.so.2 > ... > > And having libraries from /opt/csw there is simply not acceptable > since the binaries won't work on machines without OpenCSW installed. > > So my next question would be: how can I get rid of dependency on libiconv? > > I didn't have this problem in version 1.17.1. I'll have a look into this. Regards, Tim signature.asc Description: OpenPGP digital signature