Processed: Re: Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install
Processing control commands: > severity -1 normal Bug #858955 [subversion] subversion: Error unable to retrieve any working copy after upgrade/install Severity set to 'normal' from 'grave' -- 858955: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858955 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install
Control: severity -1 normal On Wed, Mar 29, 2017 at 08:21:23AM -0400, PICCORO McKAY Lenz wrote: > 2017-03-28 23:04 GMT-04:00 James McCoy : > > This discussion is specifically talking about when a 411 status is > returned, not a 413. > > the document only cited 411 error as example, could not cover all the cases > due > there are more, if u understand how to work http 1.1 vs other http 1.X and 2 You're right that it documented the known problems. However, given that 1.8.1 was published almost 4 years ago, I'd expect that common problems would have come up. Given that there's an easy workaround (set http-chunked-requests to off) I'm lowering the severity of the bug. I agree that the general setup you describe of having a proxy is common, but I think the particular proxy or proxy configuration you happen to be interacting with is rather broken. Making it more robust to standard HTTP headers is a much better fix than disabling auto-detection of the correct http-chunked-requests setting for a broader class of users. > well ist not working, i provide not only one, i provide two urls where u come > and get to test.. once with svn 1.6.12 and once with svn 1.7.0 rc1 and theres > no work > > seend to you in private mail: The IP URL is just plain broken. All I get is a 500 response, no matter how I try to run svn. The name-based URL does respond when http-chunked-requests is disabled, but breaks when auto-detection is enabled. I'll discuss this with upstream to see if there's something better than can be done here. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install
2017-03-28 23:04 GMT-04:00 James McCoy : > This discussion is specifically talking about when a 411 status is > returned, not a 413. > the document only cited 411 error as example, could not cover all the cases due there are more, if u understand how to work http 1.1 vs other http 1.X and 2 You talked about building subversion locally fixing the behavior, but > that wouldn't have changed the default value for the > http-chunked-requests configuration. > umm i build only 1.8.0, but 1.8.10, so then ok there a upstream bug here.. but debian could made something for users in transition... > Subversion 1.8.1 fixes this issue by detecting automatically whether > chunked requests are supported at the set up of a session. This is > done by issuing one additional request at the start of the session. > > Subversion 1.8.10 is newer than 1.8.1 and therefore has the above > mentioned fix. > as u said, i compiled 1.8.0 not 1.8.10, so these setting now its not work any more.. also documentation do not mention those problem in svn mail list: well ist not working, i provide not only one, i provide two urls where u come and get to test.. once with svn 1.6.12 and once with svn 1.7.0 rc1 and theres no work seend to you in private mail:
Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install
On Tue, Mar 28, 2017 at 10:50:20PM -0400, PICCORO McKAY Lenz wrote: > I cited why must be set for 1.8 and q.9 until 1.10 released: > > Users who wish to avoid the additional request may set that option to yes or > no > in order to short-circuit the additional request and avoid making it. This discussion is specifically talking about when a 411 status is returned, not a 413. You talked about building subversion locally fixing the behavior, but that wouldn't have changed the default value for the http-chunked-requests configuration. > later we have: > > The Serf-based HTTP access library would use chunked transfer encoding for > most > requests. When themod_dav_svn Subversion server is fronted by a proxy or > reverse proxy > > its common that well made configuration are a light webserver for front > request > and specialiced webserver for each specific task, in this case, apache2 for > subversion.. Yes, and later in that same document we have: Subversion 1.8.1 fixes this issue by detecting automatically whether chunked requests are supported at the set up of a session. This is done by issuing one additional request at the start of the session. Subversion 1.8.10 is newer than 1.8.1 and therefore has the above mentioned fix. > so obviously u dont have how to test, and package dont have any of these > guaranties.. I NOTE MANY SIMILAR CASES UNRESOLVED in large amount of bugs in > debian bug list for subversion package.. > > so then please leave aside the selft defensive excuses and please fix the > package.. I'm not being defensive. I'm trying to understand the actual problem, since what you're describing is not related to the release notes you are quoting. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install
I cited why must be set for 1.8 and q.9 until 1.10 released: Users who wish to avoid the additional request may set that option to yes or no in order to short-circuit the additional request and avoid making it. later we have: The Serf-based HTTP access library would use chunked transfer encoding for most requests. When themod_dav_svn Subversion server is fronted by a proxy or reverse proxy its common that well made configuration are a light webserver for front request and specialiced webserver for each specific task, in this case, apache2 for subversion.. so obviously u dont have how to test, and package dont have any of these guaranties.. I NOTE MANY SIMILAR CASES UNRESOLVED in large amount of bugs in debian bug list for subversion package.. so then please leave aside the selft defensive excuses and please fix the package.. Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-03-28 22:28 GMT-04:00 James McCoy : > On Tue, Mar 28, 2017 at 07:34:46PM -0400, PICCORO McKAY Lenz wrote: > > Package: subversion > > Version: 1.8.10-6+deb8u4 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer,the current package in debian are broken > > i upgrade clients to jeesie > > and now could'n chekout working copies from external networks, only > > internal local network > > > > but when i conpiled my own package, but version 1.8.0 im able to > > chekout from any svn of any version > > > >* What led up to the situation? > > I used debian wheeze (clients) and squeeze (servers) > > and then upgrade/install jeesie on clients, but servers leave intact > > due great performance > > (note that some tests on wheeze does not report good performance, no > > hardware update will) > >* What exactly did you do (or not do) that was effective (or > > ineffective)? > > svn co http:///svn/project1 > >* What was the outcome of this action? > > Unable to connect to a repository at URL 'http:///svn/project1' > > Unexpected HTTP status 413 'Request Entity Too Large' on '/svn/project1' > > You suggest that setting "http-chunked-requests = no" fixes this, when > the error in the release notes is a 411, not a 413. Are you sure that > has an impact? Without a server to test against, I can't investigate > the problem. > > As far as changing the config, the default value is to auto-detect > whether chunked requests are supported. If your specific proxy is > broken, then I would suggest following the directions in the release > notes and setting the config that's needed for you _just_ for that > server. > > Cheers, > -- > James > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB >
Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install
On Tue, Mar 28, 2017 at 07:34:46PM -0400, PICCORO McKAY Lenz wrote: > Package: subversion > Version: 1.8.10-6+deb8u4 > Severity: grave > Justification: renders package unusable > > Dear Maintainer,the current package in debian are broken > i upgrade clients to jeesie > and now could'n chekout working copies from external networks, only > internal local network > > but when i conpiled my own package, but version 1.8.0 im able to > chekout from any svn of any version > >* What led up to the situation? > I used debian wheeze (clients) and squeeze (servers) > and then upgrade/install jeesie on clients, but servers leave intact > due great performance > (note that some tests on wheeze does not report good performance, no > hardware update will) >* What exactly did you do (or not do) that was effective (or > ineffective)? > svn co http:///svn/project1 >* What was the outcome of this action? > Unable to connect to a repository at URL 'http:///svn/project1' > Unexpected HTTP status 413 'Request Entity Too Large' on '/svn/project1' You suggest that setting "http-chunked-requests = no" fixes this, when the error in the release notes is a 411, not a 413. Are you sure that has an impact? Without a server to test against, I can't investigate the problem. As far as changing the config, the default value is to auto-detect whether chunked requests are supported. If your specific proxy is broken, then I would suggest following the directions in the release notes and setting the config that's needed for you _just_ for that server. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install
Package: subversion Version: 1.8.10-6+deb8u4 Severity: grave Justification: renders package unusable Dear Maintainer,the current package in debian are broken i upgrade clients to jeesie and now could'n chekout working copies from external networks, only internal local network but when i conpiled my own package, but version 1.8.0 im able to chekout from any svn of any version * What led up to the situation? I used debian wheeze (clients) and squeeze (servers) and then upgrade/install jeesie on clients, but servers leave intact due great performance (note that some tests on wheeze does not report good performance, no hardware update will) * What exactly did you do (or not do) that was effective (or ineffective)? svn co http:///svn/project1 * What was the outcome of this action? Unable to connect to a repository at URL 'http:///svn/project1' Unexpected HTTP status 413 'Request Entity Too Large' on '/svn/project1' * What outcome did you expect instead? Clone and cekout lasted revision of the "project1" -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages subversion depends on: ii libapr11.5.1-3 ii libaprutil11.5.4-1 ii libc6 2.19-18+deb8u7 ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2 ii libsasl2-2 2.1.26.dfsg1-13+deb8u1 ii libsvn11.8.10-6+deb8u4 subversion recommends no packages. Versions of packages subversion suggests: pn db5.3-util ii patch 2.7.5-1 ii subversion-tools 1.8.10-6+deb8u4 -- no debconf information Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
