Re: IBM AIX Unix xlC compiler internal compiler error
(Sorry for replying to such an old post, I found it unread in my mailing list backlog) On Mon, Dec 10, 2012 at 11:06 PM, Frank Chang frank_chan...@hotmail.com wrote: libcurl-7.28.1 IBM-AIX xlC internal compiler error which our project director and I found this afternoon? The error log is shown below. Thank you. 1) ./configure CC=xlC 2) make xlC: 1501-230 Internal compiler error; please contact your Service Representative Curl builds on AIX with the IBM compilers, if you check the autobuilds page on the curl home page you'll see my autobuilds with IBM Visual C version 5.0 and version 10.1. I've been running those for years. I build with 'CC=xlc', not xlC though - I believe the latter is meant to invoke the C++ variant but I'm not sure of the impact in this case. In any case you should build with a C compiler, not a C++ compiler. If that is not the cause of the failure you see then it's probably something wrong with your compiler installation. Looks that way actually, 'Internal compiler error' sounds like something is missing. -Tor CONFIDENTIALITY This e-mail and any attachment contain KONGSBERG information which may be proprietary, confidential or subject to export regulations, and is only meant for the intended recipient(s). Any disclosure, copying, distribution or use is prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in error, please delete it immediately from your system and notify the sender properly. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: QsoSSL - (Was: [vms] Fixes to get vms builds working again.)
John E. Malmberg wrote: On 1/20/2013 3:56 AM, Oscar Koeroo wrote: Hi, do you have access to QsoSSL, it's API and/or API docs? There is still an unresolved issue with that regarding RFC2818 checks in libcurl. I know what to do conceptually but need access to that library to code it and for somebody to check if it works. Never heard of it before. According to http://daniel.haxx.se/blog/tag/nss/ QsoSSL is only on the IBM AIX platform which has absolutely no relationship to VMS. Well, I don't know if it is implemented on the AIX, but I wrote it for the iSeries (formerly AS400) OS400 operating system. IMHO, it should not been used if another API is available, because it is not reentrant and deprecated (should be replaced with the new API... but I cannot find the time to write this code). Patrick --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [W32] Testsuite does not build in 7.28.1 anymore
On Sat, 19 Jan 2013, LRN wrote: `make check' log is attached. It worked in 7.28.0 (or, at least, 7.27.0). Tried rebuilding everything with --disable-shared, didn't help. In that massive log I could mostly see complaints on various *printf() functions. In which way have they changed between 7.27.0 and 7.28.0? I can't remember any change in that area for a very long time... -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [HTTP][POST] file upload speed is too low.
On Mon, 21 Jan 2013, Sang Young, Ryan, Lee wrote: And i wonder which one is the better performance between using the CURLOPT_READDATA or curl_formadd. I don't see how you'd get any notable difference in speed if you're just reading the files off a filesystem. i tried to upload via curl_formadd. As i remember, at that time, upload speed was better than now. But file header was cracked(added formadd and contect-disposition, etc. to file header.) Then presumably your receiver didn't expect a multipart formpost... Is my code not optimized?? Only you can tell that. We don't know the specifics of your system in enough detail to say. You use an embedded system and embedded systems are sometimes less powerful and sometimes storage are on slow media and convoluted file systems. You're doing SSL and you're reading directly off the file system. Those may be factors to the slow speed, or they may not. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] always multi v5
On Fri, 18 Jan 2013, Nick Zitzmann wrote: I tried running the test suite on this build. Test 254 always fails, and test 255 causes the curl tool to stall indefinitely, blocking execution of later tests. Here's a sample of curl in that test: Thanks for testing. Let's address the failures one at a time. Run test 254 only, and when it fails please tar up the entire tests/logs/ directory and post the contents here so that I can get a change to investigate all possible details that were recorded! -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [W32] Testsuite does not build in 7.28.1 anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21.01.2013 13:55, Daniel Stenberg wrote: On Sat, 19 Jan 2013, LRN wrote: `make check' log is attached. It worked in 7.28.0 (or, at least, 7.27.0). Tried rebuilding everything with --disable-shared, didn't help. In that massive log I could mostly see complaints on various *printf() functions. In which way have they changed between 7.27.0 and 7.28.0? I can't remember any change in that area for a very long time... I don't think the problem is in functions per se. The problem seems to be in the testsuite linking the tests in a way that doesn't quite work on W32. AFAIU, instead of linking to libcurl, as apps would do, test programs are assembled from some of the compiled object files that go into libcurl. So the header tells it to link to dllimport mprintf functions, while the object files provide only normal mprintf functions for internal use. Something like that. I've tested 7.28.0, testsuite doesn't build there too. 7.27.0 testsuite, however, builds correctly. That said, nothing stands out in 7.27.0-7.28.0 diff, and there are no intermediate releases to check. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ/Rn8AAoJEOs4Jb6SI2CwczUH/RMwBZkyGZFXiuGvdU7l9G7N ExKBS/Z7DMhabA+gfjncykhEYtGpqYUIwRRkZrr8kZSVIGf2V/GOui31NdkP4c6u VcLX1hink6VUHf1DbCw6LEBSSABP0OR7ymyY8HOxsivUaKPFUfOE6o7w7OYwoqXR 8j/zKXV5UaK1sOts6G9gxHPxjB5Xk06qfiXyS8Gx2uiYkjRsmnj+Xa02d059rw0A pLRTrmbfXs28R8e3Kh8YlnbbUeozKapLxJyqoxa3dGC4QpiSMnn3tFdjehrRVFGV KEwWN7ffXYdQvEPYRW7OJRdwO3naUhvuwywKGC0VheDqej4LuQRMxu3jw7Tg2v4= =pp0D -END PGP SIGNATURE- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] Fix CURLMOPT_MAXCONNECTS
On 01/18/2013 03:51 PM, Linus Nielsen Feltzing wrote:
Thanks! It seems we have a serious lack of tests for this. Have you done
any embryos of something we can use to build a test that can use to
verify that we don't break this functionality again at some point?
I'll whip up a test for you. Stay tuned.
Here is a new version. Fixed a bug in the first patch, and added a test
case.
Linus
From ecf99dcdf896cfa74d0ce717c2e58e318a973779 Mon Sep 17 00:00:00 2001
From: Linus Nielsen Feltzing li...@haxx.se
Date: Fri, 18 Jan 2013 14:11:14 +0100
Subject: [PATCH] Restore the functionality of CURLMOPT_MAXCONNECTS. When a
connection is no longer used, it is kept in the cache. If
the cache is full, the oldest idle connection is closed. If
no connection is idle, the current one is closed instead.
---
lib/url.c | 104 +
tests/data/Makefile.am |2 +-
tests/data/test1506| 95 ++
tests/libtest/Makefile.inc |6 ++-
tests/libtest/lib1506.c| 123
5 files changed, 317 insertions(+), 13 deletions(-)
create mode 100644 tests/data/test1506
create mode 100644 tests/libtest/lib1506.c
diff --git a/lib/url.c b/lib/url.c
index 80c8a99..918ce58 100644
--- a/lib/url.c
+++ b/lib/url.c
@@ -122,6 +122,7 @@ int curl_win32_idn_to_ascii(const char *in, char **out);
#include http_proxy.h
#include bundles.h
#include conncache.h
+#include multihandle.h
#define _MPRINTF_REPLACE /* use our functions only */
#include curl/mprintf.h
@@ -131,6 +132,8 @@ int curl_win32_idn_to_ascii(const char *in, char **out);
#include memdebug.h
/* Local static prototypes */
+static struct connectdata *
+find_oldest_idle_connection(struct SessionHandle *data);
static void conn_free(struct connectdata *conn);
static void signalPipeClose(struct curl_llist *pipeline, bool pipe_broke);
static CURLcode do_init(struct connectdata *conn);
@@ -2710,6 +2713,57 @@ static void signalPipeClose(struct curl_llist *pipeline, bool pipe_broke)
}
}
+/*
+ * This function kills and removes an existing connection in the connection
+ * cache. The connection that has been unused for the longest time.
+ *
+ * Returns the pointer to the oldest idle connection, or NULL if none was
+ * found.
+ */
+static struct connectdata *
+find_oldest_idle_connection(struct SessionHandle *data)
+{
+ struct conncache *bc = data-state.conn_cache;
+ struct curl_hash_iterator iter;
+ struct curl_llist_element *curr;
+ struct curl_hash_element *he;
+ long highscore=-1;
+ long score;
+ struct timeval now;
+ struct connectdata *conn_candidate = NULL;
+ struct connectbundle *bundle;
+
+ now = Curl_tvnow();
+
+ Curl_hash_start_iterate(bc-hash, iter);
+
+ he = Curl_hash_next_element(iter);
+ while(he) {
+struct connectdata *conn;
+
+bundle = he-ptr;
+
+curr = bundle-conn_list-head;
+while(curr) {
+ conn = curr-ptr;
+
+ if(!conn-inuse) {
+/* Set higher score for the age passed since the connection was used */
+score = Curl_tvdiff(now, conn-now);
+
+if(score highscore) {
+ highscore = score;
+ conn_candidate = conn;
+}
+ }
+ curr = curr-next;
+}
+
+he = Curl_hash_next_element(iter);
+ }
+
+ return conn_candidate;
+}
/*
* Given one filled in connection struct (named needle), this function should
@@ -2961,11 +3015,35 @@ ConnectionExists(struct SessionHandle *data,
return FALSE; /* no matching connecting exists */
}
-/* this connection can now be marked 'idle' */
-static void
-ConnectionDone(struct connectdata *conn)
+/* Mark the connection as 'idle', or close it if the cache is full.
+ Returns TRUE if the connection is kept, or FALSE if it was closed. */
+static bool
+ConnectionDone(struct SessionHandle *data, struct connectdata *conn)
{
+ /* data-multi-maxconnects can be negative, deal with it. */
+ size_t maxconnects =
+(data-multi-maxconnects 0) ? 0 : data-multi-maxconnects;
+ struct connectdata *conn_candidate = NULL;
+
+ /* Mark the current connection as 'unused' */
conn-inuse = FALSE;
+
+ if(maxconnects 0
+ data-state.conn_cache-num_connections maxconnects) {
+infof(data, Connection cache is full, closing the oldest one.\n);
+
+conn_candidate = find_oldest_idle_connection(data);
+
+if(conn_candidate) {
+ /* Set the connection's owner correctly */
+ conn_candidate-data = data;
+
+ /* the winner gets the honour of being disconnected */
+ (void)Curl_disconnect(conn_candidate, /* dead_connection */ FALSE);
+}
+ }
+
+ return (conn_candidate == conn) ? FALSE : TRUE;
}
/*
@@ -4907,6 +4985,7 @@ static CURLcode create_conn(struct SessionHandle *data,
* This is a brand new connection, so let's store it in the connection
* cache of ours!
*/
+conn-inuse = TRUE;
ConnectionStore(data, conn);
}
@@ -5182,14 +5261,17 @@ CURLcode
Re: cert verification problem on curl handle re-use
On Sun, 20 Jan 2013, Mischa Salle wrote: I wonder if this has to do with the re-use of the existing connection. I have seen it fail for SLC5.8, CentOS5.6 and CentOS 5.9. From the code it's not clear to me why the connection is being reused. Are you still referring to the ancient 7.15.5 version from the original report or are you suggesting you see something wrong in a modern version? This said, I can't recall any (such) bugs in the connection re-use logic in a very long time. * Re-using existing connection! (#0) with host www.nikhef.nl * Connected to www.nikhef.nl (192.16.199.166) port 443 (#0) So it re-uses the existing connection, while the CentOS based machine starts the second time with: ... * Connection #0 to host www.nikhef.nl left intact * About to connect() to www.nikhef.nl port 443 * Trying 192.16.199.166... * connected * Connected to www.nikhef.nl (192.16.199.166) port 443 * SSL certificate problem, verify that the CA cert is OK. Details: And this is the exact same resource you're getting? So no NOT reusing the connection, although it is kept open... For plain HTTP, the CentOS is also re-using the connection instead of opening a new one. It does show separate handling of when the connection can be re-used, yes. It does not really explain why it suddenly has a problem with the (ca) cert. It could possibly even be a problem with OpenSSL for all we know, as I figure you have an outdated such version as well... -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: cert verification problem on curl handle re-use
Hi Daniel, yes, this is a 7.15.5 version, which is the latest (and only) version on RedHat5 based systems. They are patched, the RPM dates from about a year ago. I didn't have time to look at all the patches in detail. Comparing it with a RedHat6 based version unfortunately doesn't help, as that also changes the backend from OpenSSL to NSS... OpenSSL is really pain if 'someone' is trying to clean-up stuff in mid-program. Is curl_easy_reset() doing any OpenSSL cleanup? It shouldn't, right? All tries were with exactly the same URL. The same website is listening both on 80 and 443. The OpenSSL on RH5 is also an old base version, 0.9.8e but RedHat and CentOS are bringing out frequent security patches (latest from May). Mischa On Mon, Jan 21, 2013 at 11:40 AM, Daniel Stenberg dan...@haxx.se wrote: On Sun, 20 Jan 2013, Mischa Salle wrote: I wonder if this has to do with the re-use of the existing connection. I have seen it fail for SLC5.8, CentOS5.6 and CentOS 5.9. From the code it's not clear to me why the connection is being reused. Are you still referring to the ancient 7.15.5 version from the original report or are you suggesting you see something wrong in a modern version? This said, I can't recall any (such) bugs in the connection re-use logic in a very long time. * Re-using existing connection! (#0) with host www.nikhef.nl * Connected to www.nikhef.nl (192.16.199.166) port 443 (#0) So it re-uses the existing connection, while the CentOS based machine starts the second time with: ... * Connection #0 to host www.nikhef.nl left intact * About to connect() to www.nikhef.nl port 443 * Trying 192.16.199.166... * connected * Connected to www.nikhef.nl (192.16.199.166) port 443 * SSL certificate problem, verify that the CA cert is OK. Details: And this is the exact same resource you're getting? So no NOT reusing the connection, although it is kept open... For plain HTTP, the CentOS is also re-using the connection instead of opening a new one. It does show separate handling of when the connection can be re-used, yes. It does not really explain why it suddenly has a problem with the (ca) cert. It could possibly even be a problem with OpenSSL for all we know, as I figure you have an outdated such version as well... -- / daniel.haxx.se --**--**--- List admin: http://cool.haxx.se/list/**listinfo/curl-libraryhttp://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/**etiquette.htmlhttp://curl.haxx.se/mail/etiquette.html -- Maasstraat 162-III 1079 BK Amsterdam The Netherlands Tel. (+31/0)20-4043782 --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Libcurl fails to work with server configured by SSL through forward proxy with NTLM authentication
On Mon, 21 Jan 2013, Dmitry Danilov wrote: Are there any updates? I eager to know if it is a defect of libcurl indeed ot it is the result of improper use of it. Sorry, it fell down through some cracks in my planning and I've not been able to get back to this topic. I'm behind on several fronts at the moment and I don't know when I'll be able to look deeper at this. It won't be before the next release... -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
anonymous ftp
I am using cURL on Linux and trying to both upload and download to different machines. I want to use the anonymous FTP. I have had success with using the command line curl -O ftp://anonymous@ipaddress/remotepath to receive files but I am having an issue going the other way. I have tried curl -T localpath ftp://anonymous@ipaddress/remotepath and get a curl: (25) Failed FTP upload: 550. If I use the same form and change it to sftp and actually use name and password it works. How can I use FTP and anonymous to successfully upload files? Thanks. - This message is intended only for the addressee and may contain information that is company confidential or privileged. Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. - --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] always multi v5
On Jan 21, 2013, at 3:02 AM, Daniel Stenberg dan...@haxx.se wrote: Let's address the failures one at a time. Run test 254 only, and when it fails please tar up the entire tests/logs/ directory and post the contents here so that I can get a change to investigate all possible details that were recorded! Hope this helps then! Nick Zitzmann http://www.chronosnet.com/ log254.tar.gz Description: GNU Zip compressed data --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] always multi v5
On Mon, 21 Jan 2013, Nick Zitzmann wrote: Let's address the failures one at a time. Run test 254 only, and when it fails please tar up the entire tests/logs/ directory and post the contents here so that I can get a change to investigate all possible details that were recorded! Hope this helps then! This seems to be related to the test server or at least sockfilt, which isn't part of the always-multi change: $ cat ftp_ipv6_server.log 11:04:30.683105 Failed to read input 11:04:30.683343 Error: FTP-IPv6 server, read zero 11:04:30.683660 Exited from sysread_or_die() at ./ftpserver.pl line 417. FTP-IPv6 server, read zero -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: anonymous ftp
On Mon, Jan 21, 2013 at 10:06:09AM -0500, Ashby, Nick wrote: I am using cURL on Linux and trying to both upload and download to different machines. I want to use the anonymous FTP. I have had success with using the command line curl –O ftp://anonymous@ipaddress/remotepath to receive files but I am having an issue going the other way. I have tried curl –T localpath ftp:// anonymous@ipaddress/remotepath and get a curl: (25) Failed FTP upload: 550. If I use the same form and change it to sftp and actually use name and password it works. How can I use FTP and anonymous to successfully upload files? Thanks. That is the correct syntax to use. It's likely that the ftp server doesn't allow anonymous uploads, or requires that they be uploaded to a different directory. The -v option may show a more detailed message from the server. Dan --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
IBM AIX xlc compiler internal compiler error
Tor Arnsten, We just tried ./configure CC=xlc followed by make. The IBM-AIX compiler error log is shown below. It may be either an IBM-AIX xlc internal compiler error or a problem in the progress.c source file. If you have time, could you please look at ./lib/progress.c? Thank you for your help in replying to my December 10, 2012 post. make all-am source='progress.c' object='libcurl_la-progress.lo' libtool=yes DEPDIR= .deps depmode=aix /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile xlc -DHAVE_CONFIG_H -I../include/curl -I../include -I../include -I../lib -I../lib-qthreaded -qnoansialias -qhalt=e -O2 -c -o libcurl_la-progress.lo `test -f 'progress.c' || echo './'`progress.c libtool: compile: xlc -DHAVE_CONFIG_H -I../include/curl -I../include -I../inclu de -I../lib -I../lib -qthreaded -qnoansialias -qhalt=e -O2 -c -M progress.c -DP IC -o .libs/libcurl_la-progress.o xlc: 1501-230 Internal compiler error; please contact your Service Representativ e make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 1. Stop. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] always multi v5
On Jan 21, 2013, at 12:25 PM, Daniel Stenberg dan...@haxx.se wrote: This seems to be related to the test server or at least sockfilt, which isn't part of the always-multi change: $ cat ftp_ipv6_server.log 11:04:30.683105 Failed to read input 11:04:30.683343 Error: FTP-IPv6 server, read zero 11:04:30.683660 Exited from sysread_or_die() at ./ftpserver.pl line 417. FTP-IPv6 server, read zero But it started happening once the change was made; that test used to pass. Would it help if I ran all tests and then submitted what was logged prior to the stall? Nick Zitzmann http://www.chronosnet.com/ --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [W32] Testsuite does not build in 7.28.1 anymore
Am 21.01.2013 11:35, schrieb LRN: I don't think the problem is in functions per se. The problem seems to be in the testsuite linking the tests in a way that doesn't quite work on W32. AFAIU, instead of linking to libcurl, as apps would do, test programs are assembled from some of the compiled object files that go into libcurl. So the header tells it to link to dllimport mprintf functions, while the object files provide only normal mprintf functions for internal use. Something like that. I've tested 7.28.0, testsuite doesn't build there too. 7.27.0 testsuite, however, builds correctly. That said, nothing stands out in 7.27.0-7.28.0 diff, and there are no intermediate releases to check. you should try a build with --disable-shared - I guess that will fix this issue; there's a problem in the testsuite, and I would say we should always link the test progs statically on all platforms, but there's a place I think in Makefile.am which needs to be fixed to do this ... Gün. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [W32] Testsuite does not build in 7.28.1 anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.01.2013 6:31, Guenter wrote: Am 21.01.2013 11:35, schrieb LRN: On 21.01.2013 13:55, Daniel Stenberg wrote: On Sat, 19 Jan 2013, LRN wrote: `make check' log is attached. It worked in 7.28.0 (or, at least, 7.27.0). Tried rebuilding everything with --disable-shared, didn't help. In that massive log I could mostly see complaints on various *printf() functions. In which way have they changed between 7.27.0 and 7.28.0? I can't remember any change in that area for a very long time... I don't think the problem is in functions per se. The problem seems to be in the testsuite linking the tests in a way that doesn't quite work on W32. AFAIU, instead of linking to libcurl, as apps would do, test programs are assembled from some of the compiled object files that go into libcurl. So the header tells it to link to dllimport mprintf functions, while the object files provide only normal mprintf functions for internal use. Something like that. I've tested 7.28.0, testsuite doesn't build there too. 7.27.0 testsuite, however, builds correctly. That said, nothing stands out in 7.27.0-7.28.0 diff, and there are no intermediate releases to check. you should try a build with --disable-shared Been there, done that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ/j0YAAoJEOs4Jb6SI2Cw2QwIAK4QXjCW6gS77ubpZVby00yv NXK5xmbshV71fzw7ZSL3htuc0zySE+bUyPC4J+kYrz6XU5+1iN7oEcAO83YVBuqj P231A0/MG7cLmfolJfj7PwNl7Eqc8xMqmrWSdmYjxosr540ELtVvFADsyJyhe/P3 uQ3OT7G3mRXVvX7Vps2LebwotDMtHyRBRq88JFYAnxFYe5ef4mekwA8WB5nq2nK/ 0d00QsmAp95jKJtk91FGISbIxUlFCiAVpDh4U8AShRZ/6KugZsK0mimWPnI8A8KG P+wD86JhlrN9l/lkg3tj2Zr8Hw/yhWt7fMJWPHuYAj3qJk1UpnzP3JPX8uRHbvg= =Ex3D -END PGP SIGNATURE- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
