Den tors 21 okt. 2021 kl 17:56 skrev Nathan Hartman <
hartman.nat...@gmail.com>:
> On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn wrote:
>
>
>
> > > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski <
> t.lubin...@verocel.pl>:
> > >> Very strange problem with assembly code in zlib 1.2.11.
>
: Subversion ; Johan Corveleyn
; Daniel Sahlberg
Subject: Re: Subversion 1.14.1 and serf 1.3.9
On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn wrote:
> > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski
> > :
> >> Very strange problem with assembly code in zlib 1.2.11.
>
...@gmail.com>; Daniel Sahlberg
> Subject: Re: Subversion 1.14.1 and serf 1.3.9
>
> On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn wrote:
>
>
>
> > > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski <
> t.lubin...@verocel.pl>:
> > >> Ve
On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn wrote:
> > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski
> > :
> >> Very strange problem with assembly code in zlib 1.2.11.
> Indeed, zlib's assembly code seems to be unreliable on Windows. When I
> build / test (for signing new release
Den tors 21 okt. 2021 kl 14:05 skrev Johan Corveleyn :
> On Thu, Oct 21, 2021 at 2:00 PM Daniel Sahlberg
> wrote:
> >
> > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski <
> t.lubin...@verocel.pl>:
> >>
> >> I’m using Virtual SVN, server shows accepted connection with code 200.
> >>
> >>
> >
On Thu, Oct 21, 2021 at 2:00 PM Daniel Sahlberg
wrote:
>
> Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski :
>>
>> I’m using Virtual SVN, server shows accepted connection with code 200.
>>
>>
>>
>> I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib
>> 1.2.7 (that was use
Kind regards,
Daniel
>
> *From:* Daniel Sahlberg
> *Sent:* Thursday, October 21, 2021 10:36 AM
> *To:* Tomasz Lubinski
> *Cc:* Subversion
> *Subject:* Re: Subversion 1.14.1 and serf 1.3.9
>
>
>
> Den tors 21 okt. 2021 kl 07:58 skrev Tomasz Lubinski <
> t.lubin...@v
From: Daniel Sahlberg
Sent: Thursday, October 21, 2021 10:36 AM
To: Tomasz Lubinski
Cc: Subversion
Subject: Re: Subversion 1.14.1 and serf 1.3.9
Den tors 21 okt. 2021 kl 07:58 skrev Tomasz Lubinski mailto:t.lubin...@verocel.pl> >:
I tried once again, now with svn.exe built from
ion compared to top-posting).
>
>
> Tomek L
>
>
>
> *From:* Daniel Sahlberg
> *Sent:* Wednesday, October 20, 2021 3:21 PM
> *To:* Tomasz Lubinski
> *Cc:* Subversion
> *Subject:* Re: Subversion 1.14.1 and serf 1.3.9
>
>
>
> Den ons 20 okt. 2021 13:49
and serf 1.3.9
Den ons 20 okt. 2021 13:49Tomasz Lubinski mailto:t.lubin...@verocel.pl> > skrev:
I’ve checked with OPENSSL 1.1.1l, it seems that it solves problem with
segmentation fault. Now I receive message:
Error running context: The server unexpectedly closed the connection.
OK.
is
blocking the connection?
Kind regards
Daniel
>
>
>
> Tomek L
>
>
>
> *From:* Daniel Sahlberg
> *Sent:* Wednesday, October 20, 2021 12:03 PM
> *To:* Tomasz Lubinski
> *Cc:* Subversion
> *Subject:* Re: Subversion 1.14.1 and serf 1.3.9
>
>
>
>
: Subversion
Subject: Re: Subversion 1.14.1 and serf 1.3.9
Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski mailto:t.lubin...@verocel.pl> >:
Yes problem occurs only with correct user/password (self-signed SSL certificate
used). In case of incorrect user/password or repository name, i
I suppose that openssl is not a problem becuase when I used http protocol
instead of https the problem is still the same.
Tomek L
From: Daniel Sahlberg
Sent: Wednesday, October 20, 2021 11:18 AM
To: Tomasz Lubinski
Cc: Subversion
Subject: Re: Subversion 1.14.1 and serf 1.3.9
Den
using my build.
Regards,
Tomek L
From: Daniel Sahlberg
Sent: Wednesday, October 20, 2021 11:18 AM
To: Tomasz Lubinski
Cc: Subversion
Subject: Re: Subversion 1.14.1 and serf 1.3.9
Den ons 20 okt. 2021 kl 10:35 skrev Tomasz Lubinski mailto:t.lubin...@verocel.pl> >:
Is it possi
Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski :
> Yes problem occurs only with correct user/password (self-signed SSL
> certificate used). In case of incorrect user/password or repository name,
> it ends with correct error message without segmentation fault.
>
> The problem is when I’m tryin
Den ons 20 okt. 2021 kl 10:35 skrev Tomasz Lubinski :
> Is it possible to use subversion 1.14.1 with serf 1.3.9?
> Documentation says: ' 7. Apache Serf library 1.3.4 or newer (OPTIONAL)'
> but when used with
> - SERF 1.3.9, and
> - OpenSSL 3.0
>
> I've go
Is it possible to use subversion 1.14.1 with serf 1.3.9?
Documentation says: ' 7. Apache Serf library 1.3.4 or newer (OPTIONAL)' but
when used with
- SERF 1.3.9, and
- OpenSSL 3.0
I've got segmentation fault from SERF, near:
svn_ra_serf__open ->
svn_ra_serf__exc
>
> Does serf's test suite pass?
>
This was the prompt I was hoping for. I bleeped over "scons check" in haste.
It failed.
The ldd of serf-1.3.9/test/test_all had multiple entries for the openssl
libs. Not sure how that happened or how to fix.
Going to start over with a
Michael Mueller wrote on Wed, 15 May 2019 20:34 +00:00:
> dev@cardamom:~/wrk/sandbox/svn/serf-1.3.9> scons
> OPENSSL=/home/dev/wrk/openssl_build/save/1.0.2n APR=/usr/local/apr
> APU=/usr/local/apr
>
>
>
> Ran "scons install" as root.
Does serf&
Wondering if I could get help with configuring serf 1.39 with subversion
1.12 on a SLES 11.4 box.
Background
SLES 11.4 just came off long term support.
We still have to support quite a few SLES 11.4 machines. Our svn admin has
tightened security requirements and the svn revisions we were
On Mon, Dec 17, 2018 at 12:54 PM Cotrut, Michael <
michael.cot...@cbsa-asfc.gc.ca> wrote:
> Hi,
>
> It looks like ra-serf is missing from svn 1.11 client for windows
>
>
>
> Svn –version
>
> svn, version 1.11.0 (r1845130)
>
>compiled Nov 1
Hi,
It looks like ra-serf is missing from svn 1.11 client for windows
Svn -version
svn, version 1.11.0 (r1845130)
compiled Nov 1 2018, 12:47:00 on x86/x86_64-microsoft-windows10.0.17134
Copyright (C) 2018 The Apache Software Foundation.
This software consists of contributions made by many
> Thanks very much for this patch, it does indeed fix the problem for me.
>
> My use case is pretty much as you describe.
> I'm building a Subversion client RPM which includes serf.
>
> During the %build phase serf is built as so:
>
> scons PREFIX=%{pref
Thanks very much for this patch, it does indeed fix the problem for me.
My use case is pretty much as you describe. I'm building a Subversion client
RPM which includes serf.
During the %build phase serf is built as so:
scons PREFIX=%{prefix} install --install-sandbox=%{buildroot}
It ther
Gretton, Liam wrote on Wed, 07 Jun 2017 10:44 +:
> At some point since 1.8.13 the logic in the configure script for dealing with
> the --with-serf option has changed.
>
> Now pkg-config overrides the use of the --with-serf value and this breaks the
> build if serf has
I've been packaging 1.9.5 for our environment, having missed a few versions
since 1.8.13.
At some point since 1.8.13 the logic in the configure script for dealing with
the --with-serf option has changed.
Now pkg-config overrides the use of the --with-serf value and this breaks the
bui
Alexander Teut wrote on Thu, Nov 03, 2016 at 16:58:33 +0300:
> Firstly, the serf version is 1.3.8, but there's already 1.3.9.
That's intentional. We don't bump recommended dependency versions in
patch releases unless required to pick up a bug fix. (1.3.9 should
stlil work;
Hi!
There's a problem with get-debs.sh in current svn source (version 1.9.4
(r1740329))
Firstly, the serf version is 1.3.8, but there's already 1.3.9.
Secondly, it's impossible to install it, because of wrong URL at get_serf()
section. Google Code repo is deprecated. I guess, li
> -Original Message-
> From: Andreas Stieger [mailto:andreas.stie...@gmx.de]
> Sent: woensdag 7 september 2016 10:32
> To: "Alexandre C. Guimarães"
> Cc: users@subversion.apache.org
> Subject: Aw: Can't compile Subversion against Serf-1.3.9.
>
>
Hi,
Alexandre C. Guimarães wrote:
> I am getting trouble to rebuild subversion-1.9.4 on my
> FreeBSD-10.3 box after Serf be updated to 1.3.9:
[...]
> /usr/local/lib/libserf-1.so: undefined reference to `BIO_meth_set_gets'
Looks like an OpenSSL linking problem. Ensure Apache S
Dear Sir,
I am getting trouble to rebuild subversion-1.9.4 on my FreeBSD-10.3 box
after Serf be updated to 1.3.9:
cd subversion/svn && /bin/sh
"/usr/ports/devel/subversion/work/subversion-1.9.4/libtool" --tag=CC
--silent --mode=link cc -Werror=unknown-warning-option
On 22.06.2016 21:19, Stefan wrote:
> Hi Anup,
>>
>> Hello,
>>
>>
>>
>> Thank you. I am able to install using root.
>>
>>
>>
>>
>>
>> But SVn version is not been displayed in GUI ( at bottom of the
>> page). What changes to be made to get that?
>>
>>
>>
>> Example:
>>
>>
>>
> I fear we are
ed. That should be faster than passing
on several mails here trying to explain how this is done on your
platform, I think.
>
>
>
>
> *From:*Stefan [mailto:luke1...@posteo.de]
> *Sent:* 2016, June, 21 6:11 PM
> *To:* users@subversion.apache.org
> *Subject:* Re: Serf
>
>
@subversion.apache.org
Subject: Re: Serf
Hi Anup,
On 6/20/2016 15:48, Somashekarappa, Anup (CWM-NR) wrote:
Hi Team,
I am installing svn 1.9.4 and got the below error.
Which distribution do you use? Or did you compile SVN yourself?
“unrecognized url scheme for svn”
When I searched it is because of
Hi Anup,
On 6/20/2016 15:48, Somashekarappa, Anup (CWM-NR) wrote:
>
> Hi Team,
>
> I am installing svn 1.9.4 and got the below error.
Which distribution do you use? Or did you compile SVN yourself?
>
> “unrecognized url scheme for svn”
>
> When I searched it is beca
Hi Team,
I am installing svn 1.9.4 and got the below error.
"unrecognized url scheme for svn"
When I searched it is because of serf/neon lib. So trying to install using the
below link but it is not working.
Any other steps to install those lib. Can that be installed using "yu
>scons: warning: Support for pre-2.7.0 Python version (2.6.4) is
deprecated.
> If this will cause hardship, contact scons-...@scons.org
I think you are using old version of python try to upgrade python version
2.7 then try to install serf on Solaris environment.
Mohsin
On Fri, Jan 30, 2
Which Python Version you are using on Solaris environment ?
Mohsin
On Fri, Jan 30, 2015 at 12:15 AM, kay [via Subversion] <
ml-node+s1072662n191737...@n5.nabble.com> wrote:
> I am currently having the same issues as previous author (Mohsin). I am
> trying to install serf 1.3.8 fo
writes:
> Can you please confirm that the downgrading from v2 to v1 is away now?
Yes, that is v2.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Freitag, 9. Januar 2015 16:25
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: Segmentation Fault with SVN Client
writes:
> Question: do you know when the patch for the header field name
> case-sensitiveness will be delivered? Is it planned for 1.8.12 SVN
> client?
It's approved for 1.8.12, see:
http://svn.apache.org/repos/asf/subversion/branches/1.8.x/STATUS
--
Philip Martin | Subversion Committer
WAN
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Freitag, 9. Januar 2015 12:19
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: Segmentation Fault with SVN Client related to
&
writes:
> Yes you are right, I have not looked at the wireshark output good
> enough! Unfortunately I cannot change it in our HttpProxy: this
> change of the case of the header keys is performed by the underlying
> HTTP Layer in java and not by our own code. I think the reason for
> this is that
;> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
>>
>> writes:
>>
>>> You asked for the whole sequence of request, here is the whole tracing
>>> of our proxy: I hope this helps. But as already said: the svn client
>>> does not c
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Freitag, 9. Januar 2015 10:48
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: AW: Segmentation Fault with SVN Client related to
>
writes:
> I have captured the http traffic, you will find it in the attachment
> crash_http_capture.pcap. The debugging output of the HttpProxy is in
> the attachment crash_http.txt, it differs from the output when using
> https. I had to switch from https to http for this. Please note that
> th
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Mittwoch, 7. Januar 2015 14:51
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
>
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Donnerstag, 8. Januar 2015 14:34
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
t-Length: 425' and then sending 426 bytes. This
spurious extra byte causes serf to crash when it reads the extra data
without a proper handler in place.
What we need is an exact trace of every byte sent by your proxy to the
client so we can check whether it is also sending an extra byte.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Philip Martin writes:
> I've converted your trace into a Python script to implement a server
> that behaves like yours.
I may have reproduced the problem. If I remove the 'Connection: close'
headers and continue to force v1 I can get the client to crash using the
dummy server. I suppose that m
s if you do not have KeepAlive enabled on the server, or
perhaps the proxy does not support pipelining. That is going to result
in poor performance for clients that use serf.
All the above is probably irrelevant to the problem.
I've converted your trace into a Python script to implement a serve
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Mittwoch, 7. Januar 2015 14:51
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
>
t;>>Content-length: 131
> 2015-01-06 15:43:24,114 DEBUG ProxyHttpHandler - >>>>>Dav:
> http://subversion.tigris.org/xmlns/dav/svn/depth,http://subversion.tigris.org/xmlns/dav/svn/mergeinfo,http://subversion.tigris.org/xmlns/dav/svn/log-revprops
> 2015-01-06 15:43:24,115 DEBUG Pr
> -Ursprüngliche Nachricht-
> Von: Stefan Sperling [mailto:s...@elego.de]
> Gesendet: Dienstag, 6. Januar 2015 15:59
> An: Philip Martin
> Cc: Viret Pierre, PF54; users@subversion.apache.org
> Betreff: Re: AW: Segmentation Fault with SVN Client related to serf
>
&
On Tue, Jan 06, 2015 at 02:01:52PM +, Philip Martin wrote:
> Typically the client will first send an OPTIONS request and get back a
> 401 or a 200. The client will then send further OPTIONS and PROPFIND
> requests. Can you identify which request and response is causing the
> crash? Also whic
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Dienstag, 6. Januar 2015 15:02
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: Segmentation Fault with SVN Client related to serf
>
[...]
;1'
> 0x46b790: 32 ' ' 50 '2' 48 '0' 48 '0' 32 ' ' 79 'O' 75 'K'
> (gdb) p reason
> $9 = 0x46b795 "OKext/html; charset=iso-8859-1ry\"OpenSSL/1.0.1e DAV"
Note that this code fails to che
he
> mail).
>
> About network traffic: I have analysed the traffic between the local
> http-proxy and the svn client because I had supposed that some packet
> length was wrongly set, but could not find any clue about the reason
> for the segmentation fault. I have compared the traffic
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Dienstag, 6. Januar 2015 12:49
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: Segmentation Fault with SVN Client related to serf
>
> wri
writes:
> viretp@mwbox:~$ svn ls https://127.0.0.1:7771/svn/t_sponis_testrepo
> Segmentation fault
>
> In /var/log/syslog:
> Jan 5 14:31:23 mwbox kernel: [14750.072747] svn[21822]: segfault at
> 7f3733f39000 ip 7f37328ae3cf sp 7fff9e3df468 error 7 in
> libc-2.13.so[7f373278a000+182000]
ons of SVN client (SlikSvn 1.6.x /
1.7.x or TurtoiseSVN 1.7.x on windows) we never get this error if we use the
neon module but we get it with the serf module. Note that with SVNKit we have
no problem. So it seems that the error is related to serf.
The problem must be related to some timing is
Hello,
There is bug in serf 1.3.8 version because we can't compile serf on Solaris
environment.Fix for said issue was there was patch which I had applied on
serf code and was able to install serf on Solaris . Patch is already shared
in this thread . For those who face issue in serf install
Hi ,
I am getting following error while installing serf on my solaris machine .
Please suggest
-bash-3.2# scons install
scons: Reading SConscript files ...
File "/export/home/mabbas/svn1.8.10/serf-1.3.8/SConstruct", line 275:
lib_shared = env.SharedLibrary(LIBNAM
On Wed, Sep 11, 2013 at 7:19 PM, Curt Sellmer wrote:
>>>
>>> You said you dumped and loaded your repository. You also have
>>> corruption shown by apache that is not shown by svnadmin. When you
>>> dump/load are you also putting the new repository in the same place as
>>> the old repository? If
On Wed, Sep 11, 2013 at 7:04 PM, Curt Sellmer wrote:
> On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin
> wrote:
>> Curt Sellmer writes:
>>
>>> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote:
On 9/11/13 12:24 PM, Curt Sellmer wrote:
> Here is a tail of the error.log. This is from when
On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin
wrote:
> Curt Sellmer writes:
>
>> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote:
>>> On 9/11/13 12:24 PM, Curt Sellmer wrote:
Here is a tail of the error.log. This is from when I was running the
tests earlier.
I was hoping to pin
Curt Sellmer writes:
> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote:
>> On 9/11/13 12:24 PM, Curt Sellmer wrote:
>>> Here is a tail of the error.log. This is from when I was running the
>>> tests earlier.
>>> I was hoping to pinpoint which set of log messages corresponded to
>>> each error,
On Wed, Sep 11, 2013 at 3:04 PM, Curt Sellmer wrote:
> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote:
>> On 9/11/13 12:24 PM, Curt Sellmer wrote:
>>> Here is a tail of the error.log. This is from when I was running the
>>> tests earlier.
>>> I was hoping to pinpoint which set of log messages
On 9/11/13 12:24 PM, Curt Sellmer wrote:
> Here is a tail of the error.log. This is from when I was running the
> tests earlier.
> I was hoping to pinpoint which set of log messages corresponded to
> each error, but of
> course I cannot get it to fail at all right now. I'll keep trying
> througho
On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote:
> On 9/11/13 12:24 PM, Curt Sellmer wrote:
>> Here is a tail of the error.log. This is from when I was running the
>> tests earlier.
>> I was hoping to pinpoint which set of log messages corresponded to
>> each error, but of
>> course I cannot get
at 2:32 AM, Ben Reser wrote:
>>>>> On 9/10/13 10:41 PM, Curt Sellmer wrote:
>>>>>> I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn:
>>>>>> E120104: ra_serf: An error occurred during decompression" error as
>>>&
clients have had any issues and also running
>>> the 1.8.1 client on the server box using the file:// scheme has never
>>> produced an error.
>>>
>>> On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser wrote:
>>>> On 9/10/13 10:41 PM, Curt Sellmer wr
rror.
>
> On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser wrote:
>> On 9/10/13 10:41 PM, Curt Sellmer wrote:
>>> I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn:
>>> E120104: ra_serf: An error occurred during decompression" error as
>>> oft
the server box using the file:// scheme has never
>> produced an error.
>>
>> On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser wrote:
>>> On 9/10/13 10:41 PM, Curt Sellmer wrote:
>>>> I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn:
>&g
:41 PM, Curt Sellmer wrote:
>> I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn:
>> E120104: ra_serf: An error occurred during decompression" error as
>> often at the moment. Have seen it a few times.
>>
>> But I do intermittently
On 9/10/13 10:41 PM, Curt Sellmer wrote:
> I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn:
> E120104: ra_serf: An error occurred during decompression" error as
> often at the moment. Have seen it a few times.
>
> But I do intermittently get several
I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn:
E120104: ra_serf: An error occurred during decompression" error as
often at the moment. Have seen it a few times.
But I do intermittently get several different errors as show below.
- Note that I am running the co
4: Corrupt node-revision '3-1.0-489.r495/2100'
>>
>> And again both errors can be seen against both repos.
>> I ran svnadmin verify again against both repos with no errors reported.
>
> Can you please post the output of:
> svn --version --verbose
>
> If th
gainst both repos with no errors reported.
Can you please post the output of:
svn --version --verbose
If that command doesn't show that you're using serf 1.3.1 can you please
rebuild using the 1.3.1 version of the serf library?
The minimum required serf version is still 1.2.1 in 1.8
gt;> svn --version
>> svn, version 1.8.0 (r1490375)
>>compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0
>>
>> Copyright (C) 2013 The Apache Software Foundation.
>> This software consists of contributions made by many people;
>> see
490375)
>>>compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0
>>>
>>> Copyright (C) 2013 The Apache Software Foundation.
>>> This software consists of contributions made by many people;
>>> see the NOTICE file for more information.
>>> Subv
ons made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn network protocol.
>
Simon Wilson writes:
> Subversion 1.8 throws up errors when I specify HTTP/HTTPS URLs that
> contain usernames to svn, i.e.
>
> svn --username user ls https://server.com/repos/project/
>
> works fine but
>
> svn ls https://u...@server.com/repos/project/
>
> results in errors. The same URL wor
ficate path and passphrase
prompts.
The fact that 1.7/Neon supported such URLs indicates that this is a significant
regression in 1.8. Can anyone throw any light on the cause of these errors? Is
this a known issue with Serf/ra_serf?
Some additional info:
- This behavior is not specific to svn
On Wed, 2013 Aug 28 6:39+0300, Daniel Shahaf wrote:
>
> So that would appear to be a bug in serf's pkg-config file, no?
No, Serf's doing the right thing:
$ grep ^Libs.private: /tmp/serf-build/_install/lib/pkgconfig/serf-1.pc
Libs.private: -lm /tmp/apr-util-build/_install/lib
Daniel Richard G. wrote on Sun, Aug 25, 2013 at 18:12:05 -0400:
> The problem, however, is that...
>
> $ grep ^dep /tmp/apr-build/_install/lib/libapr-1.la
> dependency_libs=' -lresolv -luuid -lsendfile -lrt -lsocket -lnsl
> -lpthread'
>
> $ grep ^Libs: /tmp/apr-build/_install/lib/pkg
I am building Subversion 1.8.1 on Solaris. The dependent libraries
(APR, APR-util, Serf) are built, specified, and ready to go, and yet
this happens:
configure: serf library configuration via prefix
checking serf.h usability... yes
checking serf.h presence... yes
checking for serf.h... yes
y wrote:
>>>>
>>>>> Unless bulk updates are disabled when using the serf access method
>>>>> (the only one available with svn 1.8) for https?: urls,
>>>>> apply_textdelta does indeed get called multiple times in a row
>>>&g
On 07.07.2013 19:40, Jonathan Nieder wrote:
> (cc-ing subversion's users@ list for advice)
> Kyle McKay wrote:
>> On Jul 6, 2013, at 18:37, Jonathan Nieder wrote:
>>> Kyle McKay wrote:
Begin forwarded message:
> [2] http://subversion.tigris.org/issues/show_bug.cgi?id=2932
>>> Ah, thanks fo
d in a row without an intervening close?
>
> I believe serf is doing the following for a number of files in parallel:
> 1. open_file
> 2. apply_textdelta
> 3. change_file_prop, change_file_prop, ...
> 4. close_file
Ah, that makes more sense. It is not about traversal order but
(cc-ing subversion's users@ list for advice)
Kyle McKay wrote:
> On Jul 6, 2013, at 18:37, Jonathan Nieder wrote:
>> Kyle McKay wrote:
>>> Begin forwarded message:
[2] http://subversion.tigris.org/issues/show_bug.cgi?id=2932
>>
>> Ah, thanks for the context.
>>
>> It's still not clear to me h
On Jul 7, 2013, at 06:39, Daniel Shahaf wrote:
Kyle McKay wrote on Sat, Jul 06, 2013 at 19:46:40 -0700:
On Jul 6, 2013, at 19:23, Jonathan Nieder wrote:
Kyle McKay wrote:
Unless bulk updates are disabled when using the serf access method
(the only one available with svn 1.8) for https?: urls
On 7/7/2013 6:39 AM, Daniel Shahaf wrote:
> Kyle McKay wrote on Sat, Jul 06, 2013 at 19:46:40 -0700:
>> On Jul 6, 2013, at 19:23, Jonathan Nieder wrote:
>>> Kyle McKay wrote:
>>>
>>>> Unless bulk updates are disabled when using the serf access method
>>
> up:
>
> It's not in any of the repositories, and Fedora is still trying to
> figure out how to lay it out. (Use /usr/include/*.h, or
> /usr/include/serf-1/*.h for the files).
>
> In the meantime, you're quite welcome to my RPM building tools at
> https://github.co
ased access). So there's something wrong with our network setup.
Server machine is joined to domain2.com, my machine and my user are in
domain1.com.
Svn 1.7 client works if serf http library is used, i.e.
svn list https://svnserver.domain2.com/svn --config-option
servers:global:http-library=
t is obtained from currently
> logged in windows user, not to type user name/password manually. That part
> is failing...
>> Apparently, if the server uses NTLM only, serf cannot authenticate
>> to it, while neon could. serf supports SPNego though:
>> http://en.wikipedia.org
> If I enable the ‘SSPIPackage Negotiate’ line (which I just added) then my
> Subversion 1.8 clients appear to authenticate correctly, but my neon based
> 1.7 clients fail with an even worse error that can’t be resolved by just
> typing the password.
>
Seems like for me the SSPIPackage Negotiate i
ensdag 19 juni 2013 14:01
To: users@subversion.apache.org
Subject: Re: Automatic windows authentication using serf/svn 1.8
Sorry, I did not mention it specifically:
I can authenticate when I type in my domain user name/password when
prompted. And, they are cached so they must be entered o
chine by Apache
> and
> > https protocol and is using SSPI authentication. With svn 1.7 everything
> > works fine, including automatic authentication with currently logged in
> > windows user.
> >
> > Today I upgraded to svn 1.8 and the automatic authentication does
ently logged in
> windows user.
>
> Today I upgraded to svn 1.8 and the automatic authentication does not work
> anymore. If I set http-library = serf then 1.7 client fails to perform
> automatic authentication as well.
>
> Is there some configuration setting I am missing o
1 - 100 of 134 matches
Mail list logo
