On 8/7/2012 11:32 AM, David Rothenberger wrote:
On 8/6/2012 7:21 PM, Warren Young wrote:
Some time after *that*, at a future time entirely up to the Subversion
packages' maintainer, David Rothenberger, Subversion will be rebuilt
against those new SQLite packages.
Is that actually necessary?
On 8/6/2012 11:06 PM, Achim Gratz wrote:
Warren Young writes:
I think I've given Achim Gratz enough time to try and fix the bug
resulting from his build option changes.
I cannot fix something that I can't even reproduce.
I gave you some ideas of ways to reproduce it without TortoiseSVN.
On Mon, Aug 6, 2012 at 10:21 PM, Warren Young war...@etr-usa.com wrote:
What reason could there be for a new Cygwin DLL to be accompanied by a
new
version of SQLite? Their maintainerships are entirely decoupled.
Pardon my ignorance; I'm not familiar with the release process.
Well, to a
Christopher,
On Tue, Aug 7, 2012 at 12:07 AM, Christopher Faylor wrote:
Is the snapshot that cgf is testing going to roll back svn to SQLite
3.7.3?
Huh? No. I really have to point out that the Cygwin DLL != SQLite?
I'm not familiar with the snapshot process, and I didn't realize from
your
On 8/6/2012 7:21 PM, Warren Young wrote:
Some time after *that*, at a future time entirely up to the Subversion
packages' maintainer, David Rothenberger, Subversion will be rebuilt
against those new SQLite packages.
Is that actually necessary? SVN is dynamically linked to SQLite, so a
Hello,
On Fri, 15 Jun 2012, Warren Young wrote:
tl;dr: someone made the problem go away by rolling my recent 3.7.12 release
back to the prior 3.7.3 version.
I also have this problem (on a new Win7x64 machine with an SSD)
despite not having TortoiseSVN installed nor having Microsoft Security
On 8/6/2012 6:40 PM, Michael Gundlach wrote:
I'd be happy to revert SQLite to 3.7.3 and work around the problem.
However, I am unable to revert SQLite from 3.7.12 to 3.7.3, because I
get an svn error after doing that: SQLite compiled for 3.7.12, but
running with 3.7.3. Cygwin setup offers me
On Mon, Aug 6, 2012 at 9:09 PM, Warren Young war...@etr-usa.com wrote:
Is the snapshot that cgf is testing going to roll back svn to SQLite
3.7.3?
What reason could there be for a new Cygwin DLL to be accompanied by a new
version of SQLite? Their maintainerships are entirely decoupled.
On 8/6/2012 7:55 PM, Michael Gundlach wrote:
On Mon, Aug 6, 2012 at 9:09 PM, Warren Young war...@etr-usa.com wrote:
Is the snapshot that cgf is testing going to roll back svn to SQLite
3.7.3?
What reason could there be for a new Cygwin DLL to be accompanied by a new
version of SQLite? Their
On Mon, Aug 06, 2012 at 08:40:10PM -0400, Michael Gundlach wrote:
Hello,
On Fri, 15 Jun 2012, Warren Young wrote:
tl;dr: someone made the problem go away by rolling my recent 3.7.12 release
back to the prior 3.7.3 version.
I also have this problem (on a new Win7x64 machine with an SSD)
Warren Young writes:
I think I've given Achim Gratz enough time to try and fix the bug
resulting from his build option changes.
I cannot fix something that I can't even reproduce. I can however
reproduce the bug that led to and fixed by those changes. As said
before, if someone has an idea
David Rothenberger daveroth at acm.org writes:
The tests work for me, but I've never been able to get them to work
without first installing the newly built packages.
After some more investigations, this is because the dynamic linker seems to use
the libraries installed on the system rather than
On 7/11/2012 8:33 AM, Achim Gratz wrote:
David Rothenberger daveroth at acm.org writes:
The tests work for me, but I've never been able to get them to work
without first installing the newly built packages.
After some more investigations, this is because the dynamic linker seems to use
the
marco atzeri marco.atzeri at gmail.com writes:
a solution for testing is to add the new directory as first in the PATH.
I think it already tries to do that, I'll have to check more closely if it's
missing some directories or if the order is perhaps wrong. It may also be that
the Ruby and Perl
On 7/11/2012 9:47 AM, Achim Gratz wrote:
marco atzeri marco.atzeri at gmail.com writes:
a solution for testing is to add the new directory as first in the PATH.
I think it already tries to do that, I'll have to check more closely if it's
missing some directories or if the order is perhaps
Achim Gratz Stromeko at nexgo.de writes:
Strange. It works for me and the ldd output for _Core.dll is reasonable.
I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting the ldd output for
your _Core.dll?
On 6/28/2012 4:49 AM, Achim Gratz wrote:
Achim Gratz Stromeko at nexgo.de writes:
Strange. It works for me and the ldd output for _Core.dll is reasonable.
I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting
On 2012-06-27 14:17, David Rothenberger wrote:
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.
I just upgraded to the -5 package, and turned the TSVN icon caching back
on, and it very quickly failed
David Rothenberger writes:
I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting the ldd output for
your _Core.dll?
% ldd /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/SVN/_Core/_Core.dll
ntdll.dll
Rolf Campbell writes:
On 2012-06-27 14:17, David Rothenberger wrote:
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.
I just upgraded to the -5 package, and turned the TSVN icon caching
back on, and
On 6/28/2012 12:04 PM, Achim Gratz wrote:
David Rothenberger writes:
I can't seem to get this working. There are a few warnings, but nothing
that
would explain such a massive fail. Would you mind posting the ldd output
for
your _Core.dll?
% ldd
On 6/28/2012 1:11 PM, Achim Gratz wrote:
Rolf Campbell writes:
On 2012-06-27 14:17, David Rothenberger wrote:
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.
I just upgraded to the -5 package, and
Warren Young writes:
Now, if somebody could find out _where_ in SQLite it fails...
Is it not true that you're the only one in many years of SQLite's
availability in Cygwin who wanted it compiled the way it currently is?
Well yes, since one couldn't use temporary databases unless you have
On 6/28/2012 10:37 AM, Rolf Campbell wrote:
On 2012-06-27 14:17, David Rothenberger wrote:
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.
I just upgraded to the -5 package, and turned the TSVN icon
David Rothenberger writes:
I make two packages, one for 5.10 and one for 5.14. There's a separate
patch that's required for 5.14. Did you include it? The source package
for -4 includes it automatically.
Yes, I worked from the -4 package on one machine and the -3 package on
the other.
There
On 6/28/2012 2:35 PM, Achim Gratz wrote:
I can't easily test this myself
since I don't have TortoiseSVN installed
Me, too, but it seems to me that there's a better way to find the
problem than trying to replicate the problem reporters' exact
environment. That's too complicated. The leading
Achim Gratz wrote:
David Rothenberger writes:
I'm not sure that me running the test suite will prove much, so I'll
make the rebuild available as a test release in case someone that was
experiencing the problem would like to try it out.
Thanks, that should help as well if the OP could
Achim Gratz Stromeko at nexgo.de writes:
I'm not near my work machine, so this is from memory... the test suite
requires perl modules I didn't have installed and fails most perl tests
without them — not too worried about this, will install those later this
week.
The fail is not due to a
On 6/27/2012 7:06 AM, Achim Gratz wrote:
Achim Gratz Stromeko at nexgo.de writes:
I'm not near my work machine, so this is from memory... the test suite
requires perl modules I didn't have installed and fails most perl tests
without them — not too worried about this, will install those later
David Rothenberger writes:
Strange. It works for me and the ldd output for _Core.dll is reasonable.
What version of autotools, swig etc. are you using? The only swig
wrappers that work for me are those for Python. Both Ruby and Perl seem
to die on those strangely non-functional DLL the build
Achim Gratz writes:
Cygwin should (and apparently does) abstract away that difference. But
it seems that the locking strategy might be slightly different between
Win32 and POSIX, triggering a foray into that disk I/O error branch.
There may still be a bug some place else, i.e. it may get a
On 6/26/2012 9:45 AM, Achim Gratz wrote:
Achim Gratz writes:
I've tried to re-build svn against the new SQLite library, but I'm not
sure if that works correctly on my machine (the tests are still runnning
and I get some test failures already since apparently I'm still missing
some
David Rothenberger writes:
The cygport file should check for all required build dependencies. If
you find one missing, please let me know.
I'm not near my work machine, so this is from memory... the test suite
requires perl modules I didn't have installed and fails most perl tests
without them
Rolf Campbell wrote:
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
but I can't say for sure. The nature of these errors are as follows:
$ svn up
Updating '.':
svn: E200030: disk I/O error, executing
On 2012-06-19 05:29, Adam Dinwoodie wrote:
Rolf Campbell wrote:
$ svn up
Updating '.':
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file
$ svn cleanup
svn: E200030: disk I/O
Rolf Campbell writes:
I would hate to add TortoiseSVN to the BLODA.
The icon cache _is_ dodgy — at least the one for TortoiseGit, which
needs to be restarted regularly.
But getting back to SQLite, backing out the changes in the build would
get us back a different bug. So it would be very
On 6/19/2012 3:18 PM, Achim Gratz wrote:
I suspect that svn
does not deal with the file being locked exclusively (when TortoiseSVN
accesses the database) and some call through the windows interface
blocked.
It's possible svn has a timer on the call that results in a SQL call
through SQLite,
Warren Young writes:
Note that SQLite isn't really designed for concurrent access
to the database file from a different process.
There is a paucity of truth in that statement.
So let me re-formulate that sentence: concurrent access ultimately
relies on the file locking provided by the OS.
On 6/14/2012 4:00 PM, Garrison, Jim (ETW) wrote:
Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?
It is indeed AV related -- a race between SQLite and AV
That's one possibility, but
On 2012-06-15 06:37, Warren Young wrote:
On 6/14/2012 4:00 PM, Garrison, Jim (ETW) wrote:
Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?
It is indeed AV related -- a race between
On 2012-06-15 06:37, Warren Young wrote:
It is indeed AV related -- a race between SQLite and AV
That's one possibility, but check this out:
http://stackoverflow.com/questions/11007024/
tl;dr: someone made the problem go away by rolling my recent 3.7.12
release back to the prior 3.7.3
On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
but I can't say for sure. The nature of these errors are as follows:
$ svn up
Updating '.':
On 2012-06-14 15:55, Christopher Faylor wrote:
On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
Sometimes the errors happen, sometimes not. It seems to be about 50% of
the time svn has this type of
-Original Message-
Subject: Re: cygwin 1.7.15: svn disk I/O error
On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
but I can't say
-Original Message-
Subject: RE: cygwin 1.7.15: svn disk I/O error
-Original Message-
Subject: Re: cygwin 1.7.15: svn disk I/O error
On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
Recently, I've noticed cygwin svn getting a LOT of errors during
45 matches
Mail list logo
