On Thu, 4 Jul 2024, Jan Schlien wrote:
curl upstream has fixed a few x509asn.1 bugs since 8.8.0 that will be included
in the pending 8.9.0 release that ships in three weeks.
I believe this specific bug is fixed by this commit:
On Tue, 6 Feb 2024, Ian Jackson wrote:
See https://github.com/curl/curl/pull/12842
--
/ daniel.haxx.se
On Tue, 30 Jan 2024, Samuel Henrique wrote:
Can you tell us which case it is?
Is it confirmed affected or is this a guess?
I believe these are the two cases:
- The public 'struct curl_fileinfo' contains a time_t struct member, used for
FTP wildcard callbacks.
- The public API
On Wed, 9 Aug 2023, FC Stegerman wrote:
It seems that the unescaped dashes become U+2010. I was not expecting
that, hence my not realising what was going on. Sorry about that.
Thanks for this. I just filed this issue upstream:
https://github.com/curl/curl/issues/11635
With a pending
On Tue, 8 Aug 2023, FC Stegerman wrote:
$ curl ‐‐connect‐timeout
curl: (6) Could not resolve host: xn--connecttimeout-462hah
$ curl ‐‐connect‐timeout 2 -I example.com
curl: (6) Could not resolve host: xn--connecttimeout-462hah
Those dashes in there are not ascii minuses, they are unicode e2
On Fri, 10 Mar 2023, Samuel Henrique wrote:
I couldn't find anything in the release notes which look like a
breaking change[0]
Lots of people and CI systems run all the tests flawlessly all the time, so
there is reason to suspect that there is something slightly unusual in your
test setup
On Tue, 15 Mar 2022, Cantor, Scott wrote:
Looking more closely, I'm going to hope curl is at fault and that this is
actually "just" a CA list issue.
This is probably the same issue as Bug #1007739. Triggered by a bug in curl
for CN-only certificates:
On Tue, 15 Mar 2022, Paul Gevers wrote:
This is likely this same issue:
https://github.com/curl/curl/issues/8559
Fixed in curl (after the 7.82.0 release) via this PR:
https://github.com/curl/curl/pull/8560
--
/ daniel.haxx.se
On Sun, 26 Dec 2021, Samuel Henrique wrote:
1. How is it "a better maintained library" ?
I assume this is judging by the amount of recent commits on both projects,
so it's not a perfect metric and it's gonna be hard to argue for it in case
of disagreement. My assumption might be wrong
On Sun, 26 Dec 2021, Samuel Henrique wrote:
Well, since we're here now, we should be good to actually switch curl from
libssh2 to libssh.
Anybody against it?
What the reason for the switch to begin with? The only reason state in 897950
seems to be "that's a better maintained library and
On Mon, 16 Sep 2019, Antoni Villalonga wrote:
HTTP/3 support in curl is marked *EXPERIMENTAL* for several reasons.
- The project reserves itself the right in changing how it works in ways that
may change behavior and ABI/API in ways that otherwise curl would never do.
- The HTTP/3
Package: libtool
Version: 2.4.6-2.1
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I ran libtoolize in the curl project and shipped that ltmain.sh in a tarball
when I relased curl 7.60.0 a
On Tue, 20 Feb 2018, Steve Langasek wrote:
In fact, some of us who remember are still around ;-) The historical
context here is that curl upstream made a determination that the SONAME
should be bumped for an "ABI break" that was not an ABI break in any
traditional sense, didn't appear to
On Fri, 31 Mar 2017, Ackak wrote:
curl: symbol lookup error: /usr/lib/x86_64-linux-gnu/libcurl.so.4: undefined
symbol: libssh2_scp_recv2
#ldd -r libcurl.so.4
...
libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x7f72ba333000)
Look, this is a custom/private build if libssh2 that
On Sat, 4 Feb 2017, j.wuttke wrote:
For me to investigate further, the first thing I need to understand is where
the symbol psl_builtin is required, and by which library it ought to be
provided. Can you find out?
That function is provided by libpsl, used by libcurl.
--
/ daniel.haxx.se
On Sun, 6 Nov 2016, gregor herrmann wrote:
There's an upstream bug at
https://rt.cpan.org/Public/Bug/Display.html?id=117793
which also contains a patch.
Confirmation from the curl maintainers that the patch makes sense would be
welcome.
Seems sensible. CURL_STRICTER is just a define an
On Thu, 29 Sep 2016, Gregor Jasny wrote:
Wheezy with c-ares 1.9.1 in not affected (stated in upstream announcement).
That isn't entirely accurate. This flaw is present in every c-ares release
ever made until 1.12.0 unless you've done some changes not provided by
upstream.
Before c-ares
On Tue, 23 Aug 2016, Fulano Diego Perez wrote:
is this deemed a bug based upon head request phenomena observed with proxy ?
You have not shown a (reproducible) bug yet here so its hard to tell.
Can you show us a complete command line with the unwanted behavior?
On Tue, 2 Aug 2016, Fulano Diego Perez wrote:
$ curl --verbose --noproxy localhost --header https://www.google.com/
$ curl --verbose --noproxy "*" --header https://www.google.com/
$ curl --verbose --noproxy google.com --header https://www.google.com/
curl: no URL specified!
Maybe you
On Mon, 1 Aug 2016, Fulano Diego Perez wrote:
$ curl --noproxy ...
curl: (7) Can't complete SOCKS5 connection to 0.0.0.0:0. (4)
The --noproxy option takes a required list of host names following the option,
to which the proxy shouldn't be used. That's what --noproxy does. The line
On Sat, 25 Jun 2016, Kurt Roeckx wrote:
The openssl 1.1 API has been evolving over time and it was not very long since
the most recent change. curl works fine with openssl 1.1 but only builds
warning-free with the current openssl master branch if you use curl from it's
master git branch.
Seeing that nghttp2 was just updated in Sid to 1.3.0, is there a chance now
for curl to get HTTP/2 enabled?
Hey
Is there any actual reason why we can't just package and include the latest
nghttp2? 1.3.0 was just released.
--
/ daniel.haxx.se
On Thu, 27 Jun 2013, jari wrote:
Hi Daniel,
Any progress with this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584519
Nope. It is not a problem for me and nobody else have stepped up to work on
it...
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to
On Tue, 13 Nov 2012, Alessandro Ghedini wrote:
IIRC that was added to enable debug symbols (i.e. what's shipped in the -dbg
package). See #648902 [0] and LP#855291 [1].
Even explicitly passing -g to ./configure CFLAGs doesn't work:
I'm sorry, but I don't understand why curl and libcurl need
Package: curl
Version: 7.28.0-2
Severity: normal
Dear Maintainer,
curl -V displays 'Debug' as a feature, which indicates that curl and
libcurl are built with 'configure --enable-debug' or similar.
The effect if this is that verbose outputs include a lot of debug info
and other data and texts
On Mon, 15 Oct 2012, Alessandro Ghedini wrote:
D'oh. The attached patch seems to fix this.
Thanks, applied and pushed!
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Mon, 20 Aug 2012, Alessandro Ghedini wrote:
Attached is a patch that calls gnutls_error_is_fatal() on the
gnutls_handshake() error code to check if it's fatal.
Thanks, looks good to me. Merged and pushed!
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to
Hi,
Allow me to point out that libcurl's API exposes both a suitable timeout value
AND what actions to wait for on the socket (as can read is too naive).
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
On Mon, 23 Apr 2012, Roman Mamedov wrote:
FYI:
This is known bug #30 in curl upstream:
http://curl.haxx.se/docs/knownbugs.html
Feel free to work on it!
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
On Mon, 23 Apr 2012, Roman Mamedov wrote:
Okay, with -g
$ curl -gv 2a02:1788:4fd:cd::c742:cde2
Eeek. That's an invalid URL syntax. curl should probably flat out reject it.
* About to connect() to 2a02:1788:4fd:cd::c742 port 80 (#0)
* Trying 2a02:1788:4fd:cd::c742...
Nothing changed.
On Mon, 23 Apr 2012, Alessandro Ghedini wrote:
I can confirm that that address is truncated in v7.25.0 but not v7.21.0.
Similarily, if I try any funny string with ':' in it, curl truncates it too.
Right, and both these input strings are invalid URLs so a user should not
expect them to work
On Sat, 17 Dec 2011, Alessandro Ghedini wrote:
Apple has modified OpenSSL so that cacerts work differently with curl on thay
platform. We cannot compare with that nor should we aim to.
Here's some background:
http://daniel.haxx.se/blog/2011/11/05/apples-modified-ca-cert-handling-and-curl/
On Sat, 17 Dec 2011, Vincent Lefevre wrote:
Note that I was using OpenSSL and curl from MacPorts, thus not modified by
Apple. However I don't remember whether I checked if there was a patch in
the ports or some particular configure option.
I'm not aware of any MacPorts-specific patch of
On Tue, 6 Sep 2011, Simon Josefsson wrote:
| $ ls -l /etc/ssl/certs/ca-certificates.crt
| -rw-r--r-- 1 root root 0 Sep 2 00:07 /etc/ssl/certs/ca-certificates.crt
This is probably a libgnutls bug, but since I haven't pinned it down
I'm filing it here. Known problem?
I recall similar
I strongly disagree with this patch.
It has never been discussed or motivated upstrem in the curl project.
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Sat, 13 Aug 2011, Bilbo wrote:
This is a regression in the 1.2.8 release that has since been fixed in the
upstrem git repo.
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Sat, 30 Jul 2011, Jan Niehusmann wrote:
I had the same problem, here.
Downgrading libcurl3-gnutls from 7.21.6-3 to 7.21.0-1 fixed it for me.
On a different system, I have the same issue with versions
7.18.2-8lenny4 and 7.18.2-8lenny5 (or at least the same symptoms...).
I believe this
Can anyone please explain how and why this is a libcurl bug?
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Sat, 30 Apr 2011, Louis Opter wrote:
When Louis tries to access some files through https using a proxy
(squid/2.6.STABLE16), curl returns the error
gnutls_handshake() failed: A TLS warning alert has been received.
It works fine when using a direct (no proxy) connection. Any ideas?
We
Unfortunately I have no way to repeat this problem. The test suite runs fine
and all live HTTPS servers I've tried works even with the most recent code and
7.21.4-2.
I'm puzzled.
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Hi
This is not a curl bug. Marking it as such is not constructive.
This is an autoconf bug. It generates bad/ineffective output that isn't very
good to run on OpenVMS.
Possibly curl can add a local hack to work around the flaw, but it cannot be
more than a work-around then.
--
/
On Fri, 31 Dec 2010, Samuel Thibault wrote:
Committed upstream:
https://github.com/bagder/curl/commit/2b3fbc8cdb3ddaec159d4ad693474eb84e5ee34d
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Fri, 31 Dec 2010, Build Daemon wrote:
Since the addition of curl-nss, curl FTBFS on hurd-i386. The patch below
fixes it.
This particular patch will not be accepted by the curl project though as it is
not C89 compliant.
Does hurd really not have a PATH_MAX define? Perhaps a suitably made
Hi,
I'm sorry but I'm completely missing the point here.
What are you suggesting (lib)curl should do and when?
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi
The Fedora project has shipped libcurl built with NSS for a while, and I
wanted to mention that they ship their NSS built with a PKCS#11 PEM Reader
[1] part which makes it a lot more useful for something like (lib)curl.
Unfortunately, it doesn't seem like that functionality is due to
On Thu, 2 Dec 2010, Salvatore Bonaccorso wrote:
Thanks for reporting this observation. What was added in curl 7.21.2-2
compared to -1 is the support for c-ares. Searching the web, I found this
email
http://curl.haxx.se/mail/lib-2009-08/0014.html
Allow me to mention that this is rather a
On Sat, 13 Nov 2010, Simon McVittie wrote:
# GNUTLS backend, zero timeout, fails ./debian/build-gnutls/src/curl -k
https://apt-test.aviatis.com/apt-cacher/ftp.us.debian.org/debian/dists/squeeze/Release
--cert ../test-client.apt-test.aviatis.com.crt --key
On Sat, 13 Nov 2010, Steve M. Robbins wrote:
Does curl really treat the default value as 0 seconds timeout on the
connection? Or does it treat 0 as unlimited (i.e. no timeout)? The manpage
for curl_easy_setopt is unclear on this.
curl treats a TIMEOUT explicitly set to 0 as a way to
On Thu, 4 Nov 2010, Liam Healy wrote:
I cannot connect to a kerberized ftp server with valid tickets:
I believe the FTP kerberos problems were fixed in curl 7.21.2.
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Hi
Can you please try to make a reproducable source code that can repeat this
problem? I mean, without the tool's logic but a clean C source using libcurl.
And it is probably a good idea to take this to the curl-library mailing
list...
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to
On Fri, 4 Jun 2010, Jari Aalto wrote:
Instead of span class=bold use b or strong.
Instead of span class=emphasis use i or emph.
This may make HTML simpler, but the change would actually degrade the
versality. The SPAN elements can be freely manipulated via CSS, whereas the
B and I tags have
Hi
The NTLM code in wget is based on the curl code, and I wrote both versions.
The original curl one I wrote from scratch based on the docs I cite in the
code. I've never even seen the libntlm source code.
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to
Hey
Concerning this bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572276, please subscribe to
and continue this talk on the curl-library list instead (this mail is sent
that way as well).
The Debian bug tracker is a horrible place (to try to debug things in).
Your provided
On Tue, 23 Mar 2010, Daniel Stenberg wrote:
Can you you please see why lib/http.c:3340 isn't enough to cover for this
problem?
Hm, it's because of line lib/http.c:3561 which sets maxdownload so it is
already set later on when it spots that both chunked encoded and
content-length
Hello
Allow me to repeat myself: this is not a bug, this is by design. This will not
be changed in the upstream project so I think you were entirely correct to
close this issue.
--
/ daniel.haxx.se - lead of the curl and libcurl project
--
To UNSUBSCRIBE, email to
Hello!
Thanks for the report, but somehow I fail to repeat this issue. Can you edit
test 34 accordingly so that it fails the way you describe and then attach that
new test file?
I've tried to insert Content-Length: 12 both before and after the
Transfer-Encoding: chunked header but they
See --data-urlencode
curl supports urlencoding just fine.
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This is a duplicate of bug #476470
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Sun, 18 Oct 2009, J.H.M. Dassen (Ray) wrote:
RFC 822's date format allows for the use of single letter military
timezones; see
http://www.rfc-ref.org/RFC-TEXTS/822/chapter5.html
For example, Sat, 17 Oct 2009 20:00:00 Z is a valid date string according
to RFC822, and such date
Correction: curl has a completely separate NTLM implementation, it is not a
fork of libntlm.
As a maintainer of curl I can see how libntlm could be used (assuming its
licensing terms are fine with us) but asking for it in the debian bug tracker
is not likely to help the matter much.
--
To
This may come as news to you, but you don't reach the libcurl hackers with a
comment in a debian bug tracker.
If you want the upstream curl project to participate, take the issue to the
libcurl mailing list.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Eh,
Why pass in a URL with spaces in the first place then? curl's just very
liberal in what it accepts but proxies are of course perfectly permitted to
reject such URLs.
This is not a bug in curl, this is in bad URL passed in by the user.
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to
On Fri, 7 Nov 2008, Sandro Tosi wrote:
May I ask you if there is any planned upload for this new upstream release
(even to experimental)?
Just FYI: upstream is on 7.19.1 now...
--
/ daniel.haxx.se
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Hey
May I (as upstream maintainer of libcurl) just mention that this bug report is
pretty useless to the (lib)curl community as-is, unless there happens to be
someone who also knows a lot about the boinc internals.
I would also of course like to see A) debian update to libcurl 7.19.0 before
On Sun, 22 Jun 2008, Eduard Bloch wrote:
this is an upstream issue: specify a custom range with -r 1-2 or so and
watch the generated header with Wireshark.
No need for wireshark, curl can show its own headers. And they disagree with
your report:
$ curl -v -r 1-2 daniel.haxx.se
* About to
Hi
No, libcurl cannot add that define in its headers. Or rather, if it would add
it, it would risk that the application has included system headers before the
libcurl headers and thus get a mixed and totally confused opinion about the
large file status.
In the libcurl project we're striving
On Sun, 22 Jun 2008, Eduard Bloch wrote:
No need for wireshark, curl can show its own headers. And they disagree
with your report:
Indeed. But now, please also add --head parameter and you will see...
Indeed that looks a bit strange, but then I think using a range in a HEAD
request is a
On Sun, 22 Jun 2008, Eduard Bloch wrote:
The code currently switches to Content-Range when another request than
GET is used, as then the resume is believed to be for content that is
sent. This is actually the first time I see somehow send range with HEAD
(and care about the header).
Maybe,
On Thu, 8 May 2008, Liam Healy wrote:
I don't see a file ftp.h anywhere in the source. Is it supposed to be in
the curl source package?
Yes, it is supposed to be in there since it is present in the upstream source
tarball and required to be able to build (lib)curl...
--
To UNSUBSCRIBE,
On Wed, 7 May 2008, Liam Healy wrote:
* Trying against [EMAIL PROTECTED]
* Error creating security contextAUTH GSSAPI
Segmentation fault
Any chance you could (use a debug version and) show us a stack trace or
something from the segfault?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Wed, 7 May 2008, Liam Healy wrote:
Curl_GetFTPResponse (nreadp=0x7fffa69c79c8, conn=0x648eb0,
ftpcode=0x0) at ftp.c:623
623 ftp.c: No such file or directory.
in ftp.c
(gdb) where
#0 Curl_GetFTPResponse (nreadp=0x7fffa69c79c8, conn=0x648eb0,
ftpcode=0x0) at ftp.c:623
Thanks,
On Thu, 8 May 2008, Domenico Andreoli wrote:
Changing the names --disable-* to --toggle-* would be more intuitive, and I
wouldn't call that a redesign.
I admit to have not even though at this solution. Surely I find it more
intuitive than something named *disable* which actually _may_ enable
Yes,
This has been documented in the KNOWN_BUGS for quite some time. #30 is also
found online here:
http://curl.haxx.se/docs/knownbugs.html
We'll appreciate patches...
--
Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
--
To UNSUBSCRIBE, email to [EMAIL
Perhaps something like this?
diff -u -r1.466 ftp.c
--- lib/ftp.c 7 Feb 2008 22:25:04 - 1.466
+++ lib/ftp.c 5 Apr 2008 18:06:53 -
@@ -2563,7 +2563,8 @@
switch(ftpc-state) {
case FTP_WAIT220:
if(ftpcode != 220) {
-failf(data, This doesn't seem like a
On Wed, 23 Jan 2008, Adrian Bridgett wrote:
Using curl in scripts you normally do not want the statistics. I'd
like a way to shut this up - -q is fairly traditional.
You mean curl -s ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Hey
Bug #444093 and #444095 seem to be due to #445214
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445214), fixed in upstream
libcurl.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Yeps,
This bug has been confirmed and fixed in upstream CVS, with an added test case
to prevent future regressions in this manner.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Thanks for this!
This problem has now been addressed in the upstream curl CVS repository,
although I rephrased the sentense somewhat differently than this suggested
patch.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Sat, 15 Sep 2007, Domenico Andreoli wrote:
curl 7.17.0 breaks the build of openoffice.org. Rene has already found the
cause, it is described below.
Eh, no. curl 7.17.0 does *not* break this as you will see below.
Is it only a formal error by the curl side or openoffice.org requires to be
On Sat, 15 Sep 2007, Rene Engelhard wrote:
Nope. We still support the option as described above.
Not when you define CURL_NO_OLDIES.
You've received (at least) two mails describing the purpose of this define,
and it is even explained in the public libcurl header.
Feel free to tell us
On Sat, 15 Sep 2007, Rene Engelhard wrote:
I didn't. I just said that you was wrong saying globally that curl 7.17.0
doesn't break builds. In some circumstances it does. You also claimed
without making an exception that you still supported the options above.
Which evidently is not true with
On Thu, 13 Sep 2007, Jose Luis Rivas Contreras wrote:
While building curl with libssh2-1-dev
libssh2-1 is currently libssh2 0.17 so it can't build with any libcurl version
before 7.17.0.
libcurl 7.16.4 only built fine with libssh2 0.15.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Hey
The only really fine fix for this is to use a later libssh2 package that is
built against libgcrypt, but that of course requires that two wishes come
true:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409362
and
On Mon, 13 Aug 2007, A. Costa wrote:
Found some typos in '/usr/share/man/man1/curl.1.gz', see attached '.diff'.
Already fixed upstream since may 9th, present in 7.16.3 and later.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hey
Now 0.16 is out and we still want libssh2 in Debian...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hey
This was reported and fixed upstream in CVS. See this bug report and patch:
http://curl.haxx.se/bug/view.cgi?id=1757328
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hey
Regarding users of this, it makes sense to ask Domenico Andreoli to build curl
/ libcurl with SSH-related support once 0.15 is in Debian (he's the maintainer
of the debian curl package).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Thu, 21 Jun 2007, Adrian Bunk wrote:
Having consistent so-names as defined by upstream on different distributions
has the advantage for users of creating some binary compatibility between
different distributions. If Debian starts to diverge from upstream so-names
this becomes much harder.
On Thu, 21 Jun 2007, Bryan Donlan wrote:
Debian has not actually changed the upstream so-name. The libcurl3 package
actually contains libcurl.so.4, and a symlink to that from libcurl.so.3.
Please see the debian.release thread for more details:
On Fri, 18 May 2007, Sven Koch wrote:
./configure: line 26646: GNUTLS_ENABLED: command not found
Confirmed, already fixed in upstream CVS.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Sun, 20 May 2007, Domenico Andreoli wrote:
Daniel, would you please hand me to the right commit? I was not able to
figure it out. Maybe it is url.c 1.615-1.616?
cvs diff -D 21 april 2007 -D 22 april 2007 sslgen.c gtls.c
The gtls.c one is a different flaw but since you're out to fix
FYI: This problem is fixed in upstream's CVS.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The fellows in the Gentoo project have an equally vague and unspecific bug
report about curlftpfs and libcurl and they claim it works fine with libcurl
7.16.1 again:
http://bugs.gentoo.org/show_bug.cgi?id=163331
But no details on the problem nor exactly what fixed it.
--
To
On Thu, 8 Feb 2007, Denis Dzyubenko wrote:
I would like to do this, but I don't know what to show you - even after
enabling 'debug' in curlftpfs, it doesn't show much info. But anyway here it
is, maybe this can help, if it doesn't, please tell me what kind of
information you need.
To start
On Wed, 7 Feb 2007, Denis Dzyubenko wrote:
googling tells that this is a bug in libcurl3, not in fuse or curlftpfs. For
example, see news '22-Jan-2007' at http://curlftpfs.sourceforge.net/ After
it freezes the only way to do anything with mount ftp is to do 'killall -9
curlftpfs'.
Yes,
This bug report is incorrect.
Every separate use of --disable-epsv toggles the use of EPSV, and those
occurances used in the config file are no different than others. So, once in
the config file and once on the command line puts the state back to where it
started.
You may of course consider
Hey
Jari Sundell's patch as mentioned on this URL
(http://curl.haxx.se/mail/lib-2006-07/0169.html) seems to correct this
problem.
It is already committed to curl's CVS.
--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([s\x]\)\([\xoi]\)xo un\2\1
curl_multi_timeout().
Using curl I wouldn't be interested in its internal details, anyway.
Why would you? But hacking in workarounds is hardly what I call using
curl.
--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([s\x]\)\([\xoi]\)xo un\2\1 is xg
anything though, they just hide the
problem.
--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([s\x]\)\([\xoi]\)xo un\2\1 is xg'`ol
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 143 matches
Mail list logo
