Re: [Ms-nfs41-client-devel] Cygwin svn fails on NFS4 share

[Mark Liam Brown via Cygwin]

On Fri, Jun 14, 2024 at 5:19 PM Roland Mainz  wrote:
>
> On Fri, Jun 14, 2024 at 12:14 PM Mark Liam Brown
>  wrote:
> > Cygwin 3.4/3.5 svn fails on a NFS4 share during checkout
> >
> > svn checkout https://svn.FreeBSD.org/base/head/share/man
> > Aman/man4
> > Aman/man4/tcp.4
> > Aman/man4/ndis.4
> > Aman/man4/Makefile
> > Aman/man4/altq.4
> > Aman/man4/miibus.4
> > Aman/man4/vlan.4
> > Aman/man4/ng_macfilter.4
> > Aman/man4/mn.4
> > Aman/man4/ossl.4
> > Aman/man4/ktls.4
> > Aman/man4/ftwd.4
> > Aman/man4/inet6.4
> > Aman/man4/crypto.4
> > Aman/man4/rtsx.4
> > A    man/man4/isp.4
> > svn: E200030: sqlite[S11]: database disk image is malformed
> > svn: E200042: Additional errors:
> > svn: E200030: sqlite[S11]: database disk image is malformed
> > svn: E200030: sqlite[S11]: database disk image is malformed
> > svn: E200030: sqlite[S11]: database disk image is malformed
> >
> > This works on C: (/cygdrive/c).
>
> Could you please try to mount the filesystem with "writethru", e.g. $
> /sbin/nfs_mount -o rw,writethru 'j'
> derfwpc5131_ipv4:/export/home2/rmainz #, and then do a $ svn checkout
> https://svn.FreeBSD.org/base/release/12.2.0/share/man/ # (e.g. testing
> using a FreeBSD stable release branch, so we always have the same
> files being checked out) ?

Yes, mounting the fs with -o rw,writethru fixes svn checkout

Mark
-- 
IT Infrastructure Consultant
Windows, Linux

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [Ms-nfs41-client-devel] Cygwin svn fails on NFS4 share

[Roland Mainz via Cygwin]

On Fri, Jun 14, 2024 at 12:14 PM Mark Liam Brown
 wrote:
> Cygwin 3.4/3.5 svn fails on a NFS4 share during checkout
>
> svn checkout https://svn.FreeBSD.org/base/head/share/man
> Aman/man4
> Aman/man4/tcp.4
> Aman/man4/ndis.4
> Aman/man4/Makefile
> Aman/man4/altq.4
> Aman/man4/miibus.4
> Aman/man4/vlan.4
> Aman/man4/ng_macfilter.4
> Aman/man4/mn.4
> Aman/man4/ossl.4
> Aman/man4/ktls.4
> Aman/man4/ftwd.4
> Aman/man4/inet6.4
> Aman/man4/crypto.4
> Aman/man4/rtsx.4
> Aman/man4/isp.4
> svn: E200030: sqlite[S11]: database disk image is malformed
> svn: E200042: Additional errors:
> svn: E200030: sqlite[S11]: database disk image is malformed
> svn: E200030: sqlite[S11]: database disk image is malformed
> svn: E200030: sqlite[S11]: database disk image is malformed
>
> This works on C: (/cygdrive/c).

Could you please try to mount the filesystem with "writethru", e.g. $
/sbin/nfs_mount -o rw,writethru 'j'
derfwpc5131_ipv4:/export/home2/rmainz #, and then do a $ svn checkout
https://svn.FreeBSD.org/base/release/12.2.0/share/man/ # (e.g. testing
using a FreeBSD stable release branch, so we always have the same
files being checked out) ?



Bye,
Roland

--
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Cygwin svn fails on NFS4 share

[Mark Liam Brown via Cygwin]

Greeting!

Cygwin 3.4/3.5 svn fails on a NFS4 share during checkout

svn checkout https://svn.FreeBSD.org/base/head/share/man
Aman/man4
Aman/man4/tcp.4
Aman/man4/ndis.4
Aman/man4/Makefile
Aman/man4/altq.4
Aman/man4/miibus.4
Aman/man4/vlan.4
Aman/man4/ng_macfilter.4
Aman/man4/mn.4
Aman/man4/ossl.4
Aman/man4/ktls.4
Aman/man4/ftwd.4
Aman/man4/inet6.4
Aman/man4/crypto.4
Aman/man4/rtsx.4
Aman/man4/isp.4
svn: E200030: sqlite[S11]: database disk image is malformed
svn: E200042: Additional errors:
svn: E200030: sqlite[S11]: database disk image is malformed
svn: E200030: sqlite[S11]: database disk image is malformed
svn: E200030: sqlite[S11]: database disk image is malformed

This works on C: (/cygdrive/c).

Any thoughts?

Mark
-- 
IT Infrastructure Consultant
Windows, Linux

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: svn crashes when connection to server refused

[Andrey Repin]

Greetings, Marco Atzeri!

> On 26.01.2022 21:16, Andrey Repin wrote:
>> Greetings, marco atzeri!
>> 
>> Marco, on an unrelated note, can you please package Subversion with
>> alternatives support?
>> I understand that the request is uncommon, but I do have uncommon
>> requirements. I'm using a custom Subversion build, which is good for common
>> use, but have a small deficiency in LC_TIME handling (simply put, it always
>> output localized dates, regardless of the settings).
>> Thus I have to use a different Subversion binary for release automation.
>> I already do some massaging to a similar extent, but a proper alternatives
>> support would be much more convenient.
>> 
>> Thank you in advance.
>> 
>> 

> Hi Andrey
> what exactly do you mean ?

> is you need svn to point to another program than

>/usr/bin/svn.exe

> can not you set Alternatives to use a

>/usr/local/bin/svn

> as switch point between /usr/bin/svn.exe and your alternate ?
> What am I missing ?

Hm, point. :) That did not occurred to me. thanks for the idea!


-- 
With best regards,
Andrey Repin
Friday, January 28, 2022 11:00:07

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: svn crashes when connection to server refused

[Marco Atzeri]

On 26.01.2022 21:16, Andrey Repin wrote:

Greetings, marco atzeri!

Marco, on an unrelated note, can you please package Subversion with
alternatives support?
I understand that the request is uncommon, but I do have uncommon
requirements. I'm using a custom Subversion build, which is good for common
use, but have a small deficiency in LC_TIME handling (simply put, it always
output localized dates, regardless of the settings).
Thus I have to use a different Subversion binary for release automation.
I already do some massaging to a similar extent, but a proper alternatives
support would be much more convenient.

Thank you in advance.




Hi Andrey
what exactly do you mean ?

is you need svn to point to another program than

  /usr/bin/svn.exe

can not you set Alternatives to use a

  /usr/local/bin/svn

as switch point between /usr/bin/svn.exe and your alternate ?
What am I missing ?

Regards
Marco


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: svn crashes when connection to server refused

[Andrey Repin]

Greetings, marco atzeri!

Marco, on an unrelated note, can you please package Subversion with
alternatives support?
I understand that the request is uncommon, but I do have uncommon
requirements. I'm using a custom Subversion build, which is good for common
use, but have a small deficiency in LC_TIME handling (simply put, it always
output localized dates, regardless of the settings).
Thus I have to use a different Subversion binary for release automation.
I already do some massaging to a similar extent, but a proper alternatives
support would be much more convenient.

Thank you in advance.


-- 
With best regards,
Andrey Repin
Wednesday, January 26, 2022 22:57:02

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [EXTERNAL] Re: svn crashes when connection to server refused

[Marco Atzeri]

On 18.01.2022 18:31, Brian Inglis wrote:

On 2022-01-17 23:15, Marco Atzeri wrote:

On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:


Submitted details for adding Cygwin packages to the Apache Subversion 
Binary Packages web page:


 https://subversion.apache.org/packages.html

to the Subversion ML:

 https://lists.apache.org/list?us...@subversion.apache.org:2022-1

Also noticed that current subversion cygport, patches, etc. are not yet 
checked in to the git-cygwin-packages repo:


https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/subversion.git;a=summary 



Now they are in sync.

Uploading to git repository is always one of the things to do later ...

Regards
Marco



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [EXTERNAL] Re: svn crashes when connection to server refused

[Brian Inglis]

On 2022-01-17 23:15, Marco Atzeri wrote:

On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:

Subversion seems to have along list of upstream issues
can you check if the issue was already noted and solved upstream ?
If so I can deploy a new release.


Looks like 1.14.1 dated Feb 2021 is the latest official release, per 
their website;

and that's what we have in Cygwin.

I also tried to check out and build it right from the repository, but 
there were some
issues  Once finally built I got an error message that the 
https:// scheme wasn’t
supported.  I guess I missed some configuration peculiarities for 
Cygwin (but also,
I noticed that for some reason the source code treats Cygwin as 
Windows -- particularly
how the pathname is assumed to have the drive letters, and that is 
really baffling --

so I am not exactly sure what was meant by that by the SVN developers).



you can rebuild with the same Cygwin setting and patches reusing the
content of the cygwin source packages. You can use Setup to download it.
It should appear under /usr/src.

You will need to install the package cygport to replicate the build

There is large manual to understand the script settings in
usr/share/doc/cygport/html/manual/toc_index.html


Submitted details for adding Cygwin packages to the Apache Subversion 
Binary Packages web page:


https://subversion.apache.org/packages.html

to the Subversion ML:

https://lists.apache.org/list?us...@subversion.apache.org:2022-1

Also noticed that current subversion cygport, patches, etc. are not yet 
checked in to the git-cygwin-packages repo:


https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/subversion.git;a=summary

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [EXTERNAL] Re: svn crashes when connection to server refused

[Brian Inglis]

On 2022-01-17 19:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:

Subversion seems to have along list of upstream issues
can you check if the issue was already noted and solved upstream ?
If so I can deploy a new release.



Thanks for the suggestion!
Looks like 1.14.1 dated Feb 2021 is the latest official release, per their 
website;
and that's what we have in Cygwin.
I also tried to check out and build it right from the repository, but there 
were some
issues  Once finally built I got an error message that the https:// scheme 
wasn’t
supported.  I guess I missed some configuration peculiarities for Cygwin (but 
also,
I noticed that for some reason the source code treats Cygwin as Windows -- 
particularly
how the pathname is assumed to have the drive letters, and that is really 
baffling --
so I am not exactly sure what was meant by that by the SVN developers).


You should normally be able to build from git-cygwin-packages repo for 
subversion containing cygport, patches, and any other Cygwin files, but 
the current release has not yet been checked in at:


https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/subversion.git

although you can see from the tree 21 patches were available to apply.

So you have to download the source package which will include the 
current cygport, patches, and any other Cygwin files.


It is often a good idea also to look for relevant source patches 
available in packages' sources from upstream, as well as other distros 
such as Fedora (closely related to and used by some to build some Cygwin 
tools, parts of releases, and packages), Debian, MacPorts, and OpenSuSE 
where available:


https://src.fedoraproject.org/rpms/subversion/tree/rawhide
https://salsa.debian.org/lts-team/packages/subversion/-/tree/master/debian/patches
https://github.com/macports/macports-ports/tree/0a3636ef019083102b8eb19ba230d173a2a37afe/devel/subversion/files
https://github.com/bmwiedemann/openSUSE/tree/master/packages/s/subversion
[Thanks to those who pointed me to those package sources repos]

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [EXTERNAL] Re: svn crashes when connection to server refused

[Marco Atzeri]

On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:

Subversion seems to have along list of upstream issues

can you check if the issue was already noted and solved upstream ?
If so I can deploy a new release.


Thanks for the suggestion!

Looks like 1.14.1 dated Feb 2021 is the latest official release, per their 
website;
and that's what we have in Cygwin.

I also tried to check out and build it right from the repository, but there 
were some
issues  Once finally built I got an error message that the https:// scheme 
wasn’t
supported.  I guess I missed some configuration peculiarities for Cygwin (but 
also,
I noticed that for some reason the source code treats Cygwin as Windows -- 
particularly
how the pathname is assumed to have the drive letters, and that is really 
baffling --
so I am not exactly sure what was meant by that by the SVN developers).

Anton Lavrentiev
Contractor NIH/NLM/NCBI




you can rebuild with the same Cygwin setting and patches reusing the
content of the cygwin source packages. You can use Setup to download it.
It should appear under /usr/src.

You will need to install the package cygport to replicate the build

There is large manual to understand the script settings in
usr/share/doc/cygport/html/manual/toc_index.html



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: [EXTERNAL] Re: svn crashes when connection to server refused

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin]

> Subversion seems to have along list of upstream issues
> 
> can you check if the issue was already noted and solved upstream ?
> If so I can deploy a new release.

Thanks for the suggestion!

Looks like 1.14.1 dated Feb 2021 is the latest official release, per their 
website;
and that's what we have in Cygwin.

I also tried to check out and build it right from the repository, but there 
were some
issues  Once finally built I got an error message that the https:// scheme 
wasn’t
supported.  I guess I missed some configuration peculiarities for Cygwin (but 
also,
I noticed that for some reason the source code treats Cygwin as Windows -- 
particularly
how the pathname is assumed to have the drive letters, and that is really 
baffling --
so I am not exactly sure what was meant by that by the SVN developers).

Anton Lavrentiev
Contractor NIH/NLM/NCBI


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: svn crashes when connection to server refused

[marco atzeri]

On Sun, Jan 16, 2022 at 11:55 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
via Cygwin  wrote:
>
> Hi all,
>
> Before I go ahead and try to submit this as a bug report with the Apache 
> Subversion project, I wanted to ask
> if anybody experiences the same issue as me (or, maybe it's a Cygwin issue, 
> not svn's)...
>
> I use svn at home on Cygwin via a tunneled connection to my SVN server at 
> work, so when the tunnel is
> not up (and basically, svn connects to localhost:SVN-port and supposedly 
> receives "connection refused"),
> it crashes ungracefully with SEGFAULT leaving the repo locked ("svn cleanup" 
> is required).  When the tunnel
> is up, everything goes well.  Also, I could not reproduce any such behavior 
> at work, because the server there
> is readily available, so the connection always succeeds.
>
> It's not new, but it reached a tipping point, and I would rather try to have 
> it fixed.
>
> So this is how it looks like when the tunnel is down:
>
> $ svn --version
> svn, version 1.14.1 (r1886195)
>compiled Feb 12 2021, 17:58:10 on x86_64-unknown-cygwin
> ...
> $ svn up
> Updating '.':
> Segmentation fault (core dumped)

Subversion seems to have along list of upstream issues

can you check if the issue was already noted and solved upstream ?
If so I can deploy a new release.

Regards
Marco

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

svn crashes when connection to server refused

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin]

Hi all,

Before I go ahead and try to submit this as a bug report with the Apache 
Subversion project, I wanted to ask
if anybody experiences the same issue as me (or, maybe it's a Cygwin issue, not 
svn's)...

I use svn at home on Cygwin via a tunneled connection to my SVN server at work, 
so when the tunnel is
not up (and basically, svn connects to localhost:SVN-port and supposedly 
receives "connection refused"),
it crashes ungracefully with SEGFAULT leaving the repo locked ("svn cleanup" is 
required).  When the tunnel
is up, everything goes well.  Also, I could not reproduce any such behavior at 
work, because the server there
is readily available, so the connection always succeeds.

It's not new, but it reached a tipping point, and I would rather try to have it 
fixed.

So this is how it looks like when the tunnel is down:

$ svn --version
svn, version 1.14.1 (r1886195)
   compiled Feb 12 2021, 17:58:10 on x86_64-unknown-cygwin
...
$ svn up
Updating '.':
Segmentation fault (core dumped)
$ svn up
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for 
details)
svn: E155004: Working copy '/cygdrive/g/cygwin/cxx' locked.
svn: E155004: '/cygdrive/g/cygwin/cxx' is already locked.

(it does not crash the second time because it does not attempt to connect, but 
once "svn cleanup"
is done, it's going to do exactly the same as above and coredump)

The stackdump file does not look very useful, but here it is:

$ cat svn.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at rip=000
rax= rbx= rcx=0008000E7388
rdx=0008000EF6C8 rsi=0008000DE348 rdi=0011
r8 = r9 =000800118088 r10=0001
r11=0003F4F45359 r12=B9E0 r13=B9E8
r14=0008000DE3D8 r15=0008000E7388
rbp=B9F8 rsp=B988
program=C:\cygwin64\bin\svn.exe, pid 51421, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
FrameFunctionArgs
End of stack trace

Also, I tried to strace svn in this situation, and this is what has transpired:

$ strace -m all -n -o svn.strace /usr/bin/svn up
Updating '.':
2943523 [main] svn 51421 cygwin_exception::open_stackdumpfile: Dumping stack 
trace to svn.exe.stackdump

The bottom portion of svn.strace (after the connect attempt) follows below.

Thanks for any insights!

P.S. I'm a little behind with my Cygwin version, but like I said, this problem 
was going on for me for many
versions, both SVN and Cygwin...  SVN seems current per Cygwin Setup, though.

$ uname -a
CYGWIN_NT-6.1 X 3.2.0(0.340/5/3) 2021-03-29 08:42 x86_64 Cygwin

P.P.S. I actually tried my recent own build (from Jan 14) of Cygwin, and the 
behavior did not change at all:

$ uname -a
CYGWIN_NT-6.1 X 3.4.0(0.341/5/3) 2022-01-14 21:40 x86_64 Cygwin

$ svn up
Updating '.':
Segmentation fault (core dumped)

...
11708  397483 [main] svn 51421 cygwin_socket: socket (2, 1 (flags 0x2000000), 6)
   47  397530 [main] svn 51421 build_fh_pc: fh 0x1803632C0, dev 001E0024
  148  397678 [main] svn 51421 fhandler_base::set_close_on_exec: set 
close_on_exec for  to 1
   28  397706 [main] svn 51421 fhandler_base::set_flags: flags 0x50002, 
supplied_bin 0x0
   29  397735 [main] svn 51421 fhandler_base::set_flags: O_TEXT/O_BINARY set in 
flags 0x1
   28  397763 [main] svn 51421 fhandler_base::set_flags: filemode set to binary
   23  397786 [main] svn 51421 cygwin_socket: 3 = socket(2, 1 (flags 
0x2000000), 6)
   29  397815 [main] svn 51421 fcntl64: fcntl(3, 3, ...)
   29  397844 [main] svn 51421 fhandler_base::fcntl: GETFL: 0x50002
   25  397869 [main] svn 51421 fcntl64: 327682 = fcntl(3, 3, 0x0)
   30  397899 [main] svn 51421 fcntl64: fcntl(3, 4, ...)
   37  397936 [main] svn 51421 fhandler_socket_wsock::ioctl: socket is now 
nonblocking
   28  397964 [main] svn 51421 fhandler_socket_wsock::ioctl: 0 = 
ioctl_socket(8004667E, 0xFFFFB86C)
   31  397995 [main] svn 51421 fhandler_base::set_flags: flags 0x54002, 
supplied_bin 0x0
   33  398028 [main] svn 51421 fhandler_base::set_flags: O_TEXT/O_BINARY set in 
flags 0x1
   27  398055 [main] svn 51421 fhandler_base::set_flags: filemode set to binary
   31  398086 [main] svn 51421 fcntl64: 0 = fcntl(3, 4, 0x54002)
   59  398145 [main] svn 51421 fhandler_socket_inet::setsockopt: setsockopt 
optval=1
   27  398172 [main] svn 51421 cygwin_setsockopt: 0 = setsockopt(3, 6, 0x1, 
0xB9D0, 4)
--- Process 8520 (pid: 51421) thread 8552 created
  437  398609 [main] svn 51421 __set_errno: void __set_winsock_errno(const 
char*, int):206 setting errno 119
   71  398680 [main] svn 51421 __set_winsock_errno: connect:821 - winsock error 
10036 -> errno 119
   55  398735 [main] svn 51421 cygwin_connect: -1 = connect(3, 0x8000D5878, 
16), errno 119
 3250  401985 [main] svn 51421 __set_errno: char* strerror(int):397 setting 
errno 22
   52  402037 [main] svn 51421 __set_errno: char* strerror(int):397 setting 

Re: Error using git-svn (module List::Util: No such process at /usr/share/perl5/5.26/XSLoader.pm line 96)

[Achim Gratz]

Ivan Garcia Sainz-Aja writes:
> I fixed my problem with git-svn downgrading  perl-Scalar-List-Utils to
> version 1.49 (instead of 1.50) from here
>
> http://mirrors.kernel.org/sourceware/cygwin/x86/release/
> perl-Scalar-List-Utils/
>
> I'm  attaching the file cygcheck.out

This doesn't show the module you talked about installed at all, several
other base packages seem to be missing from your installation and you've
apparently got some really unhealthy mixture of versions w.r.t. Git
itself (but I can't be sure about that information based on the other
two observations).  Whatever you're using to install your Cygwin is
probably not setup.exe or you've been messing with the installation in
some other way that fools cygcheck.  Please properly re-install Cygwin
with setup.exe before asking for further assistance here.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Error using git-svn (module List::Util: No such process at /usr/share/perl5/5.26/XSLoader.pm line 96)

[Ivan Garcia Sainz-Aja]

 Hi Adam

I fixed my problem with git-svn downgrading  perl-Scalar-List-Utils to
version 1.49 (instead of 1.50) from here

http://mirrors.kernel.org/sourceware/cygwin/x86/release/
perl-Scalar-List-Utils/

I'm  attaching the file cygcheck.out

Thanks a lot for your help

Iván García

-- cygchek.out ---

Cygwin Configuration Diagnostics
Current System Time: Tue May 22 12:40:02 2018

Windows 10 Professional Ver 10.0 Build 16299

Running under WOW64 on AMD64

Path: C:\Users\IGSAIN~1\DOCUME~1\MOBAXT~1\slash\bin
C:\Users\IGSAIN~1\DOCUME~1\MobaXterm\slash\bin
C:\WINDOWS
C:\WINDOWS\system32

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

LD_LIBRARY_PATH = '/bin'
PWD = '/home/mobaxterm'
CYGWIN = 'nodosfilewarning glob:ignorecase proc_retry:360'
HOME = '/home/mobaxterm'

USERDOMAIN_ROAMINGPROFILE = 'INDRA'
HOMEPATH = '\Users\igsainzaja'
APPDATA = 'C:\Users\igsainzaja\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
MOBANOACL = 'true'
OneDrive = 'C:\Users\Administrator\OneDrive'
SSH_PAGEANT_PID = '11924'
SHELL = '/bin/bash.exe'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 94 Stepping 3, GenuineIntel'
HISTSIZE = '36000'
WINDIR = 'C:\WINDOWS'
HADOOP_HOME = 'D:\workspaces\bin\hadoop-common-2.2.0-bin-master'
SYMLINKS = 'C:/Users/IGSAIN~1/DOCUME~1/MobaXterm/slash/'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/home/mobaxterm/eclipse/PortalXunta.svn'
USERDOMAIN = 'INDRA'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
UATDATA = 'C:\WINDOWS\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
LC_ALL = 'es_ES.UTF-8'
GIT_EDITOR = '/bin/vim.exe'
!:: = '::\'
TEMP = '/tmp'
EXPORTED_DISPLAY = '10.8.0.193:0.0 '
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
SSH_AUTH_SOCK = '/tmp/ssh-WzgHrK/agent.2892'
TMOUT = '0'
USERNAME = 'igsainzaja'
PROCESSOR_LEVEL = '6'
CURRENT_USER_NAME = 'igsainzaja  '
ProgramFiles(x86) = 'C:\Program Files (x86)'
LIBGL_ALWAYS_INDIRECT = '1'
DWMMODE = 'no'
PSModulePath = 'C:\Program
Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules'
LOCALE = 'es_ES.UTF-8'
PUTTYHOME = 'D:\workspaces'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
JAVA_HOME = 'D:\workspaces\java\jdk1.8.0_161'
EDITOR = '/bin/vim.exe'
POPUPMODE = 'no'
MY_IP_ADDRESS = '10.8.0.193  '
VERSION = '10.5'
USERPROFILE = 'C:\Users\igsainzaja'
LANG = 'es_ES.UTF-8'
WINPATH =
'C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;D:\workspaces\java\jdk1.8.0_161\bin;D:\workspaces\bin\apache-maven-3.5.3\bin;C:\Program
Files\nodejs\;C:\Program Files (x86)\Yarn\bin\;C:\Program Files\Sublime
Text
3;D:\workspaces\bin\apache-ant-1.10.3\bin;D:\workspaces\bin\hadoop-common-2.2.0-bin-master\bin;C:\Users\igsainzaja\AppData\Local\Microsoft\WindowsApps;C:\Users\igsainzaja\AppData\Roaming\npm;C:\Users\igsainzaja\AppData\Local\Yarn\bin;'
PS1 = '\[\033]0;$PWD\007\]
\[\033[33m\][\D{%Y-%m-%d %H:%M.%S}]\[\033[0m\]  \[\033[35m\]\w\[\033[0m\]
\[\033[36m\][\u.\h]\[\033[0m\] \[\033(0\]b\[\033(B\] '
LOGONSERVER = '\\CORGRE12GC01'
KRB5_CONFIG = '/etc/krb5.conf'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\igsainzaja\AppData\Local'
KRB5CCNAME = 'FILE:/etc/krb5_cc_cache'
HISTCONTROL = 'ignoredups'
ProgramData = 'C:\ProgramData'
EXECIGNORE = '*.dll'
SHLVL = '1'
USERDNSDOMAIN = 'INDRA.ES'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
LANGUAGE = 'es_ES.UTF-8'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/tmp'
SYSTEMROOT = 'C:\WINDOWS'
PROCESSOR_REVISION = '5e03'
LC_CTYPE = 'es_ES.UTF-8'
PROMPT_COMMAND = 'r0=$?;if [ -z "$NP" ]; then i0=0;s0="";while [ "$i0" -lt
"${COLUMNS:-80}" ];do s0="q$s0";i0=$[$i0+1];done;builtin echo -ne
"\n\E[1;30m\E(0$s0\E(B\E[0m"; [ $r0 == 0 ] && builtin echo -ne
"\e[1A\e[32m\e(0d\e(B\e[0m\e[1B" || builtin echo -ne
"\e[1A\e[31m\e(0e\e(B\e[0m\e[1B";else unset NP;fi;history -a'
MY_COMPUTER_NAME = 'IGSAINZAJA10   '
VAGRANT_DETECTED_OS = 'cygwin'
PROGRAMFILES = 'C:\Program Files (x86)'
DISPLAY = '127.0.0.1:0.0'
NUMBER_OF_PROCESSORS = '4'
GIT_PAGER = '/bin/busybox.exe less -R'
SESSIONNAME = 'Console'
PUTTYTMP = 'C:\Users\IGSAIN~1\DOCUME~1\MobaXterm\slash\tmp'
HISTTIMEFORMAT = '[%Y-%m-%d %H:%M:%S] '
HISTFILE = '/home/mobaxterm/.bash_history'
TERMNUM = '2'
COMPUTERNAME = 'IGSAINZAJA10'
_ = '/bin/cygcheck'


obcaseinsensitive set to 1

Cygwin installations found in the registry:

c:  hd  NTFS122879Mb  44% CP CS UN PA FC OSDisk
d:  hd  NTFS350169Mb   3% CP CS UN PA FC Datos
f:  cd N/AN/A

D:\workspaces  /home/igsainzaja  user
binary,posix=0
D:\workspaces  /home/mobaxterm   user
binary,posix=0
C:\Users\IGSAIN~1\DOCUME~1\MOBAXT~1\slash  / system
binary,auto
C:\U

Re: Error using git-svn (module List::Util: No such process at /usr/share/perl5/5.26/XSLoader.pm line 96)

[Adam Dinwoodie]

On Tue, 22 May 2018 at 09:35, Ivan Garcia Sainz-Aja wrote:
> Hi all,

> I'm getting the following error using git-svn (I think the only change I
> made was that I updated subversion)

> ➤ git svn rebase
> Can't load

'/usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int/auto/List/Util/Util.dll'
> for module List::Util: No such process at
/usr/share/perl5/5.26/XSLoader.pm
> line 96.
>   at /usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int/List/Util.pm
> line 23.
> Compilation failed in require at
> /usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int/Scalar/Util.pm
> line 23.
> Compilation failed in require at
/usr/share/perl5/vendor_perl/5.26/Error.pm
> line 48.
> BEGIN failed--compilation aborted at
> /usr/share/perl5/vendor_perl/5.26/Error.pm line 48.
> Compilation failed in require at /usr/share/perl5/vendor_perl/5.26/Git.pm
> line 104.
> BEGIN failed--compilation aborted at
> /usr/share/perl5/vendor_perl/5.26/Git.pm line 104.
> Compilation failed in require at /usr/share/perl5/Git/SVN.pm line 24.
> BEGIN failed--compilation aborted at /usr/share/perl5/Git/SVN.pm line 24.
> Compilation failed in require at /usr/libexec/git-core/git-svn line 21.
> BEGIN failed--compilation aborted at /usr/libexec/git-core/git-svn line
21.

> --
> versions are:
> svn, version 1.9.7 (r1800392)
> git version 2.16.2
> perl (v5.26.1)


> Any idea how to make git-svn work again?

Hi Iván,

It looks like something has gone wrong with the Perl dependencies. Can you
please send in a cygcheck.out file per the problem report guidelines:

> Problem reports:   http://cygwin.com/problems.html

That should help us work out what's gone wrong here.

Adam

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Error using git-svn (module List::Util: No such process at /usr/share/perl5/5.26/XSLoader.pm line 96)

[Ivan Garcia Sainz-Aja]

Hi all,

I'm getting the following error using git-svn (I think the only change I
made was that I updated subversion)

➤ git svn rebase
Can't load
'/usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int/auto/List/Util/Util.dll'
for module List::Util: No such process at /usr/share/perl5/5.26/XSLoader.pm
line 96.
 at /usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int/List/Util.pm
line 23.
Compilation failed in require at
/usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int/Scalar/Util.pm
line 23.
Compilation failed in require at /usr/share/perl5/vendor_perl/5.26/Error.pm
line 48.
BEGIN failed--compilation aborted at
/usr/share/perl5/vendor_perl/5.26/Error.pm line 48.
Compilation failed in require at /usr/share/perl5/vendor_perl/5.26/Git.pm
line 104.
BEGIN failed--compilation aborted at
/usr/share/perl5/vendor_perl/5.26/Git.pm line 104.
Compilation failed in require at /usr/share/perl5/Git/SVN.pm line 24.
BEGIN failed--compilation aborted at /usr/share/perl5/Git/SVN.pm line 24.
Compilation failed in require at /usr/libexec/git-core/git-svn line 21.
BEGIN failed--compilation aborted at /usr/libexec/git-core/git-svn line 21.

--
versions are:
svn, version 1.9.7 (r1800392)
git version 2.16.2
perl (v5.26.1)


Any idea how to make git-svn work again?


Thanks all
Iván García

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygwin's subversion-1.10 broke zsh's svn-completion

[Chris via cygwin]

Hi,

after upgrading to subversion-1.10 in cygwin, the command completion in zsh for 
svn no longer works.
I don't get the same problem on Linux where the completion still works with 
subversion 1.10, so to me it looks like something cygwin-specific, but I can't 
be sure. I don't know if I should direct this issue here, to zsh or subversion, 
but since it does works in Linux, I suspect this is the right place.

When pressing tab after writing "svn ", I'm getting:
_svn:33: bad set of key/value pairs for associative array

Anyone has any ideas?

/Chris

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn segfault when using svn+ssh schema

[Sam Edge]

On 16/01/2017 20:26, Jon Turney wrote:
> On 16/01/2017 20:07, Sam Edge wrote:
>> On 09/01/2017 19:07, Sam Edge wrote:
>>> On 09/01/2017 02:04, Eliot Moss wrote:
>>>> On 1/8/2017 3:45 PM, David Rothenberger wrote:
>>>>> On 1/8/2017 6:12 AM, Sam Edge wrote:
>>>>>> I've seen a number of 'svn segfault' threads on the mailing list
>>>>>> archive
>>>>>> but none of them seem to cover this specific failure mode.
>>>>>> (Apologies if
>>>>>> one of them does!)
>>>>>>
>>>>>> I'm getting segfaults from svn but only when using ssh as the
>>>>>> schema.
>>>>>> The following three commands are all accessing the same server, the
>>>>>> name
>>>>>> of which has been changed to protect the guilty.
>>>>>>
>>>>>> 
>>>>>> SamEdge@thor ~
>>>>>> $ ssh cmserver.XX.com
>>>>>> ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
>>>>>> commit-revprops depth log-revprops atomic-revprops partial-replay
>>>>>> inherited-props ephemeral-txnprops file-revs-reverse ) ) )
>>>>>> SamEdge@thor ~
>>>>>> $ svn ls svn+ssh://cmserver.XX.com/edl/
>>>>>> Segmentation fault (core dumped)
>>>> Assuming this is repeatable behavior, perhaps getting a trace using
>>>> strace would reveal some more useful information.
>>>>
>>>> Regards - Eliot Moss
>>>>
>>> Good idea.
>>>
>>> Strangely, on another Windows 7 64-bit machine svn+ssh to the same
>>> server is working fine for me. The most significant differences are
>>> that
>>> the 'working' machine is running Windows 7 Pro on an Intel CPU with
>>> Sophos AV and domain accounts whereas the 'failing' machine is
>>> Windows 7
>>> Home Premium on an AMD with MS Security Essentials and local accounts.
>>> These differences may or may not be relevant of course.
>>>
>>> Anyway, attached are the two strace outputs. Diffing them suggests that
>>> it's segfaulting in the fork() "system" call.
>
> Not quite, this strace has...
>
>> --- Process 5436 loaded C:\cygwin64\lib\sasl2_3\cygcrammd5-3.dll at
>> 0003EA09
>> --- Process 5436, exception c005 at 0003EA023780
>> --- Process 5436 unloaded DLL at 0003EA09
>>   333   52465 [main] svn 5436 seterrno_from_win_error:
>> /home/corinna/src/cygwin/cygwin-2.6.1/cygwin-2.6.1-1.x86_64/src/newlib-cygwin/winsup/cygwin/dlfcn.cc:304
>> windows error 998
>>24   52489 [main] svn 5436 geterrno_from_win_error: windows error
>> 998 == errno 14
>>20   52509 [main] svn 5436 dlopen: ret 0x0
>
> and then a bit later
>
>>21   91851 [main] svn 5436 fork: entering
>>   168   92019 [main] svn 5436 sig_send: sendsig 0x80, pid 5436,
>> signal -72, its_me 1
>>19   92038 [main] svn 5436 sig_send: wakeup 0x28C
>>24   92062 [main] svn 5436 sig_send: Waiting for pack.wakeup 0x28C
>>36   92098 [sig] svn 5436 wait_sig: signalling pack.wakeup 0x28C
>>27   92125 [main] svn 5436 sig_send: returning 0x0 from sending
>> signal -72
>> --- Process 5436, exception c005 at 000180053D3F
>
> So it looks like perhaps cygcrammd5 is faulting during it's DllMain,
> and perhaps this leaves things in a state that dll_list::topsort can't
> handle...
>
>>> I don't have time in the week to run it in a debug session but I'll try
>>> to do so at the weekend given the advice I've been given here. I will
>>> also do a rebaseall after I've tracked down the
>>>
>>> Thanks for the feedback folks. Much appreciated.
>>>
>>> BR
>>
>> Hi again.
>>
>> I've downloaded the debug symbols for subversion & the Cygwin dll and
>> run the command in gdb. Output attached. Not really giving me any clues
>> so far.
>
> You also need the symbols for the DLL loaded at the faulting address.
>
> From previous information I'd guess that is cyrus-sasl-debuginfo.
>
> (you can check this using gdb's 'info shared' command)
>
>> I've also run 'rebaseall' on the off chance that it would help - it
>> didn't!
>>
>> Still open to suggestions if anyone has any "light bulb" notions. :-)
>
Hi Jon. Thanks for the swift reply.

I've installed the debug as you suggested but it doesn't shed much light
to me. The attached gdb output doesn't seem any more enlightening. I'm a
li

Re: svn segfault when using svn+ssh schema

[Jon Turney]

On 16/01/2017 20:07, Sam Edge wrote:

On 09/01/2017 19:07, Sam Edge wrote:

On 09/01/2017 02:04, Eliot Moss wrote:

On 1/8/2017 3:45 PM, David Rothenberger wrote:

On 1/8/2017 6:12 AM, Sam Edge wrote:

I've seen a number of 'svn segfault' threads on the mailing list
archive
but none of them seem to cover this specific failure mode.
(Apologies if
one of them does!)

I'm getting segfaults from svn but only when using ssh as the schema.
The following three commands are all accessing the same server, the
name
of which has been changed to protect the guilty.


SamEdge@thor ~
$ ssh cmserver.XX.com
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
commit-revprops depth log-revprops atomic-revprops partial-replay
inherited-props ephemeral-txnprops file-revs-reverse ) ) )
SamEdge@thor ~
$ svn ls svn+ssh://cmserver.XX.com/edl/
Segmentation fault (core dumped)

Assuming this is repeatable behavior, perhaps getting a trace using
strace would reveal some more useful information.

Regards - Eliot Moss


Good idea.

Strangely, on another Windows 7 64-bit machine svn+ssh to the same
server is working fine for me. The most significant differences are that
the 'working' machine is running Windows 7 Pro on an Intel CPU with
Sophos AV and domain accounts whereas the 'failing' machine is Windows 7
Home Premium on an AMD with MS Security Essentials and local accounts.
These differences may or may not be relevant of course.

Anyway, attached are the two strace outputs. Diffing them suggests that
it's segfaulting in the fork() "system" call.


Not quite, this strace has...


--- Process 5436 loaded C:\cygwin64\lib\sasl2_3\cygcrammd5-3.dll at 
0003EA09
--- Process 5436, exception c005 at 0003EA023780
--- Process 5436 unloaded DLL at 0003EA09
  333   52465 [main] svn 5436 seterrno_from_win_error: 
/home/corinna/src/cygwin/cygwin-2.6.1/cygwin-2.6.1-1.x86_64/src/newlib-cygwin/winsup/cygwin/dlfcn.cc:304
 windows error 998
   24   52489 [main] svn 5436 geterrno_from_win_error: windows error 998 == 
errno 14
   20   52509 [main] svn 5436 dlopen: ret 0x0


and then a bit later


   21   91851 [main] svn 5436 fork: entering
  168   92019 [main] svn 5436 sig_send: sendsig 0x80, pid 5436, signal -72, 
its_me 1
   19   92038 [main] svn 5436 sig_send: wakeup 0x28C
   24   92062 [main] svn 5436 sig_send: Waiting for pack.wakeup 0x28C
   36   92098 [sig] svn 5436 wait_sig: signalling pack.wakeup 0x28C
   27   92125 [main] svn 5436 sig_send: returning 0x0 from sending signal -72
--- Process 5436, exception c005 at 000180053D3F


So it looks like perhaps cygcrammd5 is faulting during it's DllMain, and 
perhaps this leaves things in a state that dll_list::topsort can't handle...



I don't have time in the week to run it in a debug session but I'll try
to do so at the weekend given the advice I've been given here. I will
also do a rebaseall after I've tracked down the

Thanks for the feedback folks. Much appreciated.

BR


Hi again.

I've downloaded the debug symbols for subversion & the Cygwin dll and
run the command in gdb. Output attached. Not really giving me any clues
so far.


You also need the symbols for the DLL loaded at the faulting address.

From previous information I'd guess that is cyrus-sasl-debuginfo.

(you can check this using gdb's 'info shared' command)


I've also run 'rebaseall' on the off chance that it would help - it didn't!

Still open to suggestions if anyone has any "light bulb" notions. :-)


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn segfault when using svn+ssh schema

[Sam Edge]

On 09/01/2017 19:07, Sam Edge wrote:
> On 09/01/2017 02:04, Eliot Moss wrote:
>> On 1/8/2017 3:45 PM, David Rothenberger wrote:
>>> On 1/8/2017 6:12 AM, Sam Edge wrote:
>>>> I've seen a number of 'svn segfault' threads on the mailing list
>>>> archive
>>>> but none of them seem to cover this specific failure mode.
>>>> (Apologies if
>>>> one of them does!)
>>>>
>>>> I'm getting segfaults from svn but only when using ssh as the schema.
>>>> The following three commands are all accessing the same server, the
>>>> name
>>>> of which has been changed to protect the guilty.
>>>>
>>>> 
>>>> SamEdge@thor ~
>>>> $ ssh cmserver.XX.com
>>>> ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
>>>> commit-revprops depth log-revprops atomic-revprops partial-replay
>>>> inherited-props ephemeral-txnprops file-revs-reverse ) ) )
>>>> SamEdge@thor ~
>>>> $ svn ls svn+ssh://cmserver.XX.com/edl/
>>>> Segmentation fault (core dumped)
>> Assuming this is repeatable behavior, perhaps getting a trace using
>> strace would reveal some more useful information.
>>
>> Regards - Eliot Moss
>>
> Good idea.
>
> Strangely, on another Windows 7 64-bit machine svn+ssh to the same
> server is working fine for me. The most significant differences are that
> the 'working' machine is running Windows 7 Pro on an Intel CPU with
> Sophos AV and domain accounts whereas the 'failing' machine is Windows 7
> Home Premium on an AMD with MS Security Essentials and local accounts.
> These differences may or may not be relevant of course.
>
> Anyway, attached are the two strace outputs. Diffing them suggests that
> it's segfaulting in the fork() "system" call.
>
> I don't have time in the week to run it in a debug session but I'll try
> to do so at the weekend given the advice I've been given here. I will
> also do a rebaseall after I've tracked down the
>
> Thanks for the feedback folks. Much appreciated.
>
> BR

Hi again.

I've downloaded the debug symbols for subversion & the Cygwin dll and
run the command in gdb. Output attached. Not really giving me any clues
so far.

I've also run 'rebaseall' on the off chance that it would help - it didn't!

Still open to suggestions if anyone has any "light bulb" notions. :-)

-- 
Sam Edge

SamEdge@thor ~
$ gdb svn
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from svn...Reading symbols from 
/usr/lib/debug//usr/bin/svn.exe.dbg...done.
done.
(gdb) set cygwin-exceptions on
(gdb) run ls svn+ssh://cmserver.XX.com/edl/
Starting program: /usr/bin/svn ls svn+ssh://cmserver.XX.com/edl/
[New Thread 2096.0xf4c]
[New Thread 2096.0x157c]
[New Thread 2096.0x1264]
[New Thread 2096.0x15d8]

Program received signal SIGSEGV, Segmentation fault.
0x0003e9f63780 in ?? ()
(gdb) bt
#0  0x0003e9f63780 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info threads
  Id   Target Id Frame
  4Thread 2096.0x15d8 0x0000000076cfd63a in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
  3Thread 2096.0x1264 0x76cfc2ea in ntdll!ZwWaitForMultipleObjects
() from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  2Thread 2096.0x157c 0x76cfbd9a in ntdll!ZwReadFile ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
* 1Thread 2096.0xf4c 0x0003e9f63780 in ?? ()
(gdb) list
3098  err, _("When using svn+ssh:// URLs, keep in mind that 
the "
3099 "--username and --password options are ignored 
"
3100 "because authentication is performed by SSH, 
not "
3101 "Subversion"));
3102}
3103
3104  return err;
3105}
3106
3107  return SVN_NO_ERROR;
(gdb)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn segfault when using svn+ssh schema

[Eliot Moss]

On 1/8/2017 3:45 PM, David Rothenberger wrote:

On 1/8/2017 6:12 AM, Sam Edge wrote:

I've seen a number of 'svn segfault' threads on the mailing list archive
but none of them seem to cover this specific failure mode. (Apologies if
one of them does!)

I'm getting segfaults from svn but only when using ssh as the schema.
The following three commands are all accessing the same server, the name
of which has been changed to protect the guilty.


SamEdge@thor ~
$ ssh cmserver.XX.com
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
commit-revprops depth log-revprops atomic-revprops partial-replay
inherited-props ephemeral-txnprops file-revs-reverse ) ) )
SamEdge@thor ~
$ svn ls svn+ssh://cmserver.XX.com/edl/
Segmentation fault (core dumped)


Assuming this is repeatable behavior, perhaps getting a trace using
strace would reveal some more useful information.

Regards - Eliot Moss

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn segfault when using svn+ssh schema

[Jon Turney]

On 08/01/2017 20:45, David Rothenberger wrote:

On 1/8/2017 6:12 AM, Sam Edge wrote:

[...]


I've attached cygcheck & the segfault stackdump.

I'm at a loss. Any ideas?


[Cygwin subversion maintainer here.]

Sorry, I have no further ideas. svn+ssh is working fine for me here
using both Cygwin and Debian as the server. Debian is running Subversion
1.8.10.

I personally lack the technical skills to decode the stack trace. Maybe
someone else can. Alternatively, you could theoretically download the


The script at [1] shows how to do this. Unfortunately...


$ stackdump2backtrace svn.stackdump
0x000180053d3fdll_list::populate_deps(dll*)dll_init.cc:271
0x000180053f9adll_list::topsort()  dll_init.cc:309
0x0001800ab62dfork fork.cc:597
0x00018011882bxc   sigfe.s:43
0x0003fa778644xc   ??:0
0x0003ed275773xc   ??:0
0x0003ed275e3dxc   ??:0
0x0003ed2d41f4xc   ??:0
0x0003ed40fc0fxc   ??:0
0x0003ed41079exc   ??:0
0x0003ed3f2d59xc   ??:0
0x0003ed3f3320xc   ??:0
0x00010040b9f9svn_cl__list list-cmd.c:387
0x0001004178fdsub_main svn.c:3042
0x00010041b755main svn.c:3126
0x000180047902dll_crt0_1(void*)dcrt0.cc:1018


... this is a crash in the cygwin DLL.

Also unfortunately, the stackdump doesn't record the DLLs loaded and 
their bases addresses, so we can only guess which one ended up at 
0x0003e000



subversion debug package and reproduce the error in gdb to get a
backtrace. Again, my C/gdb skills are rusty, so I can't provide any
details about how to do that.


So see also [2] and note well the point about 'set cygwin-exceptions on'

[1] https://cygwin.com/ml/cygwin/2015-08/msg00311.html
[2] https://cygwin.com/faq.html#faq.programming.debugging-cygwin


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn segfault when using svn+ssh schema

[David Rothenberger]

On 1/8/2017 6:12 AM, Sam Edge wrote:

I've seen a number of 'svn segfault' threads on the mailing list archive
but none of them seem to cover this specific failure mode. (Apologies if
one of them does!)

I'm getting segfaults from svn but only when using ssh as the schema.
The following three commands are all accessing the same server, the name
of which has been changed to protect the guilty.


SamEdge@thor ~
$ ssh cmserver.XX.com
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
commit-revprops depth log-revprops atomic-revprops partial-replay
inherited-props ephemeral-txnprops file-revs-reverse ) ) )
SamEdge@thor ~
$ svn ls svn+ssh://cmserver.XX.com/edl/
Segmentation fault (core dumped)

SamEdge@thor ~
$ svn ls https://cmserver.XX.com/edl/
branches/
tags/
trunk/

SamEdge@thor ~
$


Access using TortoiseSVN using either schema is working fine, as is
access from Linux svn.

The server is Ubuntu 14.04.5 LTS with package subversion
1.8.8-1ubuntu3.2, openssh-server 1:6.6p1-2ubuntu2.8 and openssl
1.0.1f-1ubuntu2.21.

The secure shell access is using public key authentication.

I've attached cygcheck & the segfault stackdump.

I'm at a loss. Any ideas?


[Cygwin subversion maintainer here.]

Sorry, I have no further ideas. svn+ssh is working fine for me here 
using both Cygwin and Debian as the server. Debian is running Subversion 
1.8.10.


I personally lack the technical skills to decode the stack trace. Maybe 
someone else can. Alternatively, you could theoretically download the 
subversion debug package and reproduce the error in gdb to get a 
backtrace. Again, my C/gdb skills are rusty, so I can't provide any 
details about how to do that.


--
David Rothenberger    daver...@acm.org

Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git svn -T svn://svn. ...

[Adam Dinwoodie]

On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> > Using the latest production release 2.4.1(1) the command is removing the
> > / after the svn: leaving svn:/svn which isn't correct.  Using
> > 'svn://svn' doesn't help either.
> > 
> > (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
> > E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
> > URL  and a separate URL is not specified
> 
> I'm seeing the same behaviour on local builds of both v2.7.0 and v2.2.0,
> and when using http:// URIs as well as svn:// ones.  Very sad.
> 
> It's not immediately obvious what's going wrong here, and I don't
> currently have much spare time for digging, but I'll add it to my queue
> to investigate the problem / report it upstream to see if anyone else
> has any cunning ideas.

This has now been fixed upstream; the fix should be available from
v2.8.0.

Adam

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git svn -T svn://svn. ...

[cyg Simple]

On 3/16/2016 2:39 PM, Adam Dinwoodie wrote:
> On Wed, Mar 09, 2016 at 07:56:36PM +, Adam Dinwoodie wrote:
>> On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
>>> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
>>>> Using the latest production release 2.4.1(1) the command is removing the
>>>> / after the svn: leaving svn:/svn which isn't correct.  Using
>>>> 'svn://svn' doesn't help either.
>>>>
>>>> (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
>>>> E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
>>>> URL  and a separate URL is not specified
>>>
>>> I'm seeing the same behaviour on local builds of both v2.7.0 and v2.2.0,
>>> and when using http:// URIs as well as svn:// ones.  Very sad.
>>>
>>> It's not immediately obvious what's going wrong here, and I don't
>>> currently have much spare time for digging, but I'll add it to my queue
>>> to investigate the problem / report it upstream to see if anyone else
>>> has any cunning ideas.
>>
>> I've found a work-around.  I'm surprised it works, but it evidently
>> does, so...
>>
>> If you do the `git svn init` without the `-T` argument, then set up the
>> branches to fetch explicitly using `git config`, everything seems to
>> work fine:
>>
>> $ git svn init svn://svn.code.sf.net/p/squirrelmail/code
>> Initialized empty Git repository in /home/add/tmp/.git/
>>
>> $ git config svn-remote.svn.fetch trunk:refs/remotes/origin/trunk
>>
>> $ git svn fetch
>> r1 = 12dc820c417dc5f12723307a3fcfa4629ea972fb (refs/remotes/origin/trunk)
>> A   squirrelmail/ATHORS
>> A   squirrelmail/login.php3
>> A   squirrelmail/signout.php3
>> ...
> 
> A better work-around: don't specify the full URL in the -T argument:
> 
> git svn init svn://svn.code.sf.net/p/squirrelmail/code -T trunk
> 
> The underlying bug here is that Git treats anything passed in a -T
> argument as if it were a directory, and attempts to "canonicalize" it,
> which includes squashing consecutive "/"s.
> 
> That doesn't match the Git SVN man page, which states "The Subversion
> URL may be specified as ...  full URL arguments to -T/-t/-b" and "[The
> -T flag] can point to a relative repository path ... or a full url", but
> it looks like all the test scripts in Git only handle relative paths in
> the -T argument.
> 
> Specifying the URL as a positional argument, and just the directory name
> in the -T argument is what all the Git test scripts do, which is
> presumably why this has never previously been spotted.
> 
> I'm in the process of writing this up to submit upstream.
> 
> As much for my own benefit: the reason I don't see this bug on my CentOS
> box is that it has Subversion 1.6; the canonicalization function in
> Subversion 1.6 (and earlier?) is different and doesn't cause this bug to
> manifest.

Thanks for the work on this and the upstream fixes.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git svn -T svn://svn. ...

[Adam Dinwoodie]

On Wed, Mar 09, 2016 at 07:56:36PM +, Adam Dinwoodie wrote:
> On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
> > On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> > > Using the latest production release 2.4.1(1) the command is removing the
> > > / after the svn: leaving svn:/svn which isn't correct.  Using
> > > 'svn://svn' doesn't help either.
> > > 
> > > (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
> > > E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
> > > URL  and a separate URL is not specified
> > 
> > I'm seeing the same behaviour on local builds of both v2.7.0 and v2.2.0,
> > and when using http:// URIs as well as svn:// ones.  Very sad.
> > 
> > It's not immediately obvious what's going wrong here, and I don't
> > currently have much spare time for digging, but I'll add it to my queue
> > to investigate the problem / report it upstream to see if anyone else
> > has any cunning ideas.
> 
> I've found a work-around.  I'm surprised it works, but it evidently
> does, so...
> 
> If you do the `git svn init` without the `-T` argument, then set up the
> branches to fetch explicitly using `git config`, everything seems to
> work fine:
> 
>     $ git svn init svn://svn.code.sf.net/p/squirrelmail/code
>     Initialized empty Git repository in /home/add/tmp/.git/
> 
> $ git config svn-remote.svn.fetch trunk:refs/remotes/origin/trunk
> 
> $ git svn fetch
> r1 = 12dc820c417dc5f12723307a3fcfa4629ea972fb (refs/remotes/origin/trunk)
> A   squirrelmail/ATHORS
>     A   squirrelmail/login.php3
> A   squirrelmail/signout.php3
> ...

A better work-around: don't specify the full URL in the -T argument:

git svn init svn://svn.code.sf.net/p/squirrelmail/code -T trunk

The underlying bug here is that Git treats anything passed in a -T
argument as if it were a directory, and attempts to "canonicalize" it,
which includes squashing consecutive "/"s.

That doesn't match the Git SVN man page, which states "The Subversion
URL may be specified as ...  full URL arguments to -T/-t/-b" and "[The
-T flag] can point to a relative repository path ... or a full url", but
it looks like all the test scripts in Git only handle relative paths in
the -T argument.

Specifying the URL as a positional argument, and just the directory name
in the -T argument is what all the Git test scripts do, which is
presumably why this has never previously been spotted.

I'm in the process of writing this up to submit upstream.

As much for my own benefit: the reason I don't see this bug on my CentOS
box is that it has Subversion 1.6; the canonicalization function in
Subversion 1.6 (and earlier?) is different and doesn't cause this bug to
manifest.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git svn -T svn://svn. ...

[cyg Simple]

On 3/9/2016 2:56 PM, Adam Dinwoodie wrote:
> On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
>> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
>>> Using the latest production release 2.4.1(1) the command is removing the
>>> / after the svn: leaving svn:/svn which isn't correct.  Using
>>> 'svn://svn' doesn't help either.
>>>
>>> (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
>>> E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
>>> URL  and a separate URL is not specified
>>
>> I'm seeing the same behaviour on local builds of both v2.7.0 and v2.2.0,
>> and when using http:// URIs as well as svn:// ones.  Very sad.
>>
>> It's not immediately obvious what's going wrong here, and I don't
>> currently have much spare time for digging, but I'll add it to my queue
>> to investigate the problem / report it upstream to see if anyone else
>> has any cunning ideas.
> 
> I've found a work-around.  I'm surprised it works, but it evidently
> does, so...
> 
> If you do the `git svn init` without the `-T` argument, then set up the
> branches to fetch explicitly using `git config`, everything seems to
> work fine:
> 
>     $ git svn init svn://svn.code.sf.net/p/squirrelmail/code
>     Initialized empty Git repository in /home/add/tmp/.git/
> 
> $ git config svn-remote.svn.fetch trunk:refs/remotes/origin/trunk
> 
> $ git svn fetch
> r1 = 12dc820c417dc5f12723307a3fcfa4629ea972fb (refs/remotes/origin/trunk)
> A   squirrelmail/ATHORS
> A   squirrelmail/login.php3
> A   squirrelmail/signout.php3
> ...
> 
> HTH
> 

Thanks - my workaround involved a turtle. :D  I'll mark this mail to
remember it for a future try if the problem isn't resolved by then.

The issue seems to be in the git-svn module and not an issue of Cygwin
or git itself.  Maybe some magic with the double // in trying to be
copacetic in a Windows environment.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git svn -T svn://svn. ...

[Adam Dinwoodie]

On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> > Using the latest production release 2.4.1(1) the command is removing the
> > / after the svn: leaving svn:/svn which isn't correct.  Using
> > 'svn://svn' doesn't help either.
> > 
> > (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
> > E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
> > URL  and a separate URL is not specified
> 
> I'm seeing the same behaviour on local builds of both v2.7.0 and v2.2.0,
> and when using http:// URIs as well as svn:// ones.  Very sad.
> 
> It's not immediately obvious what's going wrong here, and I don't
> currently have much spare time for digging, but I'll add it to my queue
> to investigate the problem / report it upstream to see if anyone else
> has any cunning ideas.

I've found a work-around.  I'm surprised it works, but it evidently
does, so...

If you do the `git svn init` without the `-T` argument, then set up the
branches to fetch explicitly using `git config`, everything seems to
work fine:

$ git svn init svn://svn.code.sf.net/p/squirrelmail/code
Initialized empty Git repository in /home/add/tmp/.git/

$ git config svn-remote.svn.fetch trunk:refs/remotes/origin/trunk

$ git svn fetch
r1 = 12dc820c417dc5f12723307a3fcfa4629ea972fb (refs/remotes/origin/trunk)
A   squirrelmail/ATHORS
A   squirrelmail/login.php3
A   squirrelmail/signout.php3
...

HTH

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git svn -T svn://svn. ...

[Adam Dinwoodie]

On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> Using the latest production release 2.4.1(1) the command is removing the
> / after the svn: leaving svn:/svn which isn't correct.  Using
> 'svn://svn' doesn't help either.
> 
> (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
> E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
> URL  and a separate URL is not specified

I'm seeing the same behaviour on local builds of both v2.7.0 and v2.2.0,
and when using http:// URIs as well as svn:// ones.  Very sad.

It's not immediately obvious what's going wrong here, and I don't
currently have much spare time for digging, but I'll add it to my queue
to investigate the problem / report it upstream to see if anyone else
has any cunning ideas.

Adam

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

git svn -T svn://svn. ...

[cyg Simple]

Using the latest production release 2.4.1(1) the command is removing the
/ after the svn: leaving svn:/svn which isn't correct.  Using
'svn://svn' doesn't help either.

(1) CYGWIN_NT-10.0 HAL2002 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin

(2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
URL  and a separate URL is not specified

(3) $ git svn init --trunk='svn://svn.code.sf.net/p/squirrelmail/code/trunk'
E: 'svn:/svn.code.sf.net/p/squirrelmail/code/trunk' is not a complete
URL  and a separate URL is not specified

strace @ https://drive.google.com/open?id=0B6c3VsMjSWW6eWZjLU1IYml6ZVk

-- 
cyg Simple


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gcc segfault on cygwin 2.3.1-1 with aircrack-ng svn r2719

[Corinna Vinschen]

On Nov 14 12:59, tdotre...@aircrack-ng.org wrote:
> Hi,
> 
> I just updated to cygwin 2.3.1-1 after
> https://cygwin.com/ml/cygwin/2015-11/msg00186.html1 to see if the update
> solves the issue but it still segfaults. I only tested gcc 5.2.0-1 and I'm
> pretty sure it's gonna happen on every other gcc version available since the
> output is exactly the same as on 2.3.0:

I tried to build aircrack-ng-1.2-rc2 on 2.3.1 and didn't encounter this
problem.  If that's not the right thing to do to test the issue, please
provide the full set of commands to reproduce the issue.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgppauOJ1jlBb.pgp
Description: PGP signature

gcc segfault on cygwin 2.3.1-1 with aircrack-ng svn r2719

[tdotreppe]

Hi,

I just updated to cygwin 2.3.1-1 after 
https://cygwin.com/ml/cygwin/2015-11/msg00186.html1 to see if the update 
solves the issue but it still segfaults. I only tested gcc 5.2.0-1 and 
I'm pretty sure it's gonna happen on every other gcc version available 
since the output is exactly the same as on 2.3.0:


$ make
make -C src all
make[1]: Entering directory '/home/Thomas/aircrack-ng-trunk/src'
gcc -g -W -Wall -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=2719  -DCYGWIN 
-fstack-protector-strong -Wno-unused-but-set-variable -Wno-array-bounds 
-Iinclude   -c -o aircrack-ng.o aircrack-ng.c

gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
: recipe for target 'aircrack-ng.o' failed
make[1]: *** [aircrack-ng.o] Error 4
make[1]: Leaving directory '/home/Thomas/aircrack-ng-trunk/src'
Makefile:25: recipe for target 'all' failed
make: *** [all] Error 2

Here is gcc info (5.2):
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/5.2.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: 
/cygdrive/i/szsz/tmpp/gcc/gcc-5.2.0-1.i686/src/gcc-5.2.0/configure 
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.2.0-1.i686/src/gcc-5.2.0 
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc 
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C 
--build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin 
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib 
--enable-shared --enable-shared-libgcc --enable-static 
--enable-version-specific-runtime-libs --enable-bootstrap 
--enable-__cxa_atexit --with-dwarf2 --with-arch=i686 --with-tune=generic 
--disable-sjlj-exceptions 
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ 
--enable-graphite --enable-threads=posix --enable-libatomic 
--enable-libgomp --disable-libitm --enable-libquadmath 
--enable-libquadmath-support --enable-libssp --enable-libada 
--enable-libjava --enable-libgcj-sublibs --disable-java-awt 
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld 
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl 
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib 
--enable-linker-build-id

Thread model: posix
gcc version 5.2.0 (GCC)

I'm attaching 'cygcheck -s -v -r' output to this email.

Since I remembered it still worked with 2.2.1 on this computer, I tried 
to compile it on another computer I hadn't updated and compilation 
worked as expected.


Let me know if there is any more information needed to help you debug 
the issue.


Best regards,

Thomas
Cygwin Configuration Diagnostics
Current System Time: Sat Nov 14 19:45:14 2015

Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Running under WOW64 on AMD64

Path:   C:\cygwin32\usr\local\bin
C:\cygwin32\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files\Intel\WiFi\bin
C:\Program Files\Common Files\Intel\WirelessCommon
C:\Program Files (x86)\Microchip\xc32\v1.34\bin
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files (x86)\Universal Extractor
C:\Program Files (x86)\Universal Extractor\bin
C:\Program Files (x86)\Skype\Phone
C:\Program Files\OpenVPN\bin
C:\Program Files\TortoiseSVN\bin
C:\Program Files\Intel\WiFi\bin
C:\Program Files\Common Files\Intel\WirelessCommon

Output from C:\cygwin32\bin\id.exe
UID: 197608(Thomas)GID: 197121(None)
197121(None)   197609(HomeUsers)
545(Users) 4(INTERACTIVE)
66049(CONSOLE LOGON)   11(Authenticated Users)
15(This Organization)  113(Local account)
4095(CurrentSession)   66048(LOCAL)
262154(NTLM Authentication)401408(Medium Mandatory Level)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'Thomas'
PWD = '/home/Thomas/aircrack-ng-trunk'
HOME = '/home/Thomas'

HOMEPATH = '\Users\Thomas'
APPDATA = 'C:\Users\Thomas\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'Thomas-PC'
SHELL = '/bin/bash'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 42 Stepping 7, GenuineIntel'
PROFILEREAD = 'true'
WINDIR = 'C:\Windows'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/home/Thomas'
ORIGINAL_PATH = 
'/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
 Files/Intel/WiFi/bin:/cygdrive/c/Program Files/Common 
Files/Intel/WirelessCommon:/cygdrive/c/Program Files 
(x86)/Microchip/xc32/v1.34/bin:/cygdrive/c/Program Files (x86)/NVIDIA 
Corporation/PhysX/Common:/cygdrive/c/Program Files (x86)/Universal 
Extractor:/cygdrive/c/Program Files (x86)/Universal 
Extractor/bin:/cygdrive/c/Program Files 

Re: svn1.9.1, segmentation fault when calling "svn diff -c .", on MS Windows7

[David Rothenberger]

Wb Yang wrote:
> 3. I also tried to run this with gdb this afternoon.  How ever, since
> the 1.9.1-1's "subversion-debuginfo" is not available from the
> setup-x86_64.exe yet, I was not able to figure out the exact exception
> source.  Do you know where-else can I download a copy of the debug
> info?

Something went wrong with the packaging for 1.9.1-1 and the debuginfo
package wasn't generated. I didn't have time last weekend to investigate
it. I'll try to look at it this weekend if I have time.

-- 
David Rothenberger    daver...@acm.org

Cygwin Subversion maintainer


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn1.9.1, segmentation fault when calling "svn diff -c .", on MS Windows7

[Wb Yang]

Thanks Dave,

1. I didn't type in the command correctly, it was like "svn diff -c
12345 MY-REPO-URL";

2. Your recipe works fine here;

3. I also tried to run this with gdb this afternoon.  How ever, since
the 1.9.1-1's "subversion-debuginfo" is not available from the
setup-x86_64.exe yet, I was not able to figure out the exact exception
source.  Do you know where-else can I download a copy of the debug
info?
//////

$ gdb --args svn diff --internal-diff -c 123456
http://subversion.TestProjX.com/projX/trunk
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from svn...done.
(gdb) break main
Breakpoint 1 at 0x10041b477: file
/usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c, line 3112.
(gdb) run
Starting program: /usr/bin/svn diff --internal-diff -c 123456
http://subversion.TestProjX.com/projX/trunk
[New Thread 44912.0xad34]
[New Thread 44912.0xad30]
[New Thread 44912.0xaf78]
[New Thread 44912.0xae5c]

Breakpoint 1, main (argc=6, argv=0x22cab0) at
/usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c:3112
3112/usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c: No
such file or directory.
(gdb) n
3114in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
3118in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
3119in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
3118in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
3124in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
3126in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
3124in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
3126in /usr/src/debug/subversion-1.9.1-1/subversion/svn/svn.c
(gdb) n
[New Thread 44912.0xaff8]
[New Thread 44912.0xae0c]
  0 [main] svn 44912 cygwin_exception::open_stackdumpfile: Dumping
stack trace to svn.exe.stackdump
[Thread 44912.0xaff8 exited with code 35584]
[Thread 44912.0xae0c exited with code 35584]
[Thread 44912.0xad30 exited with code 35584]
[Thread 44912.0xaf78 exited with code 35584]
[Inferior 1 (process 44912) exited with code 0105400]
(gdb)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn1.9.1, segmentation fault when calling "svn diff -c .", on MS Windows7

[Wb Yang]

This is the "cygcheck.out".

I removed the information under "id.exe" and "UATDATA" since it's my
company's working desktop:
///
Cygwin Configuration Diagnostics
Current System Time: Thu Sep 10 07:50:41 2015

Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1

Path:C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Users\yangwe\algs4\java\bin
C:\ProgramData\Oracle\Java\javapath
C:\Program Files (x86)\CollabNet\Subversion Client
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files\Intel\WiFi\bin
C:\Program Files\Common Files\Intel\WirelessCommon
C:\Program Files\TortoiseSVN\bin
C:\Program Files (x86)\Code Collaborator Client
C:\Program Files (x86)\MATLAB\R2012a Student\bin
C:\Go\bin
C:\WS\gocode\bin
C:\Xilinx\13.4\LabTools\LabTools\bin\nt64
C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy
C:\Program Files (x86)\Beyond Compare 4
C:\Users\yangwe\algs4\bin
C:\Users\yangwe\algs4\java\bin
C:\cygwin64\bin
C:\GNUtoolsForVim\cscope157
C:\GNUtoolsForVim\ctags58
C:\GNUtoolsForVim\TrueGNUTools
C:\WS\zeal

Output from C:\cygwin64\bin\id.exe

/
/// omitted by wenbo
/

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'yangwe'
PWD = '/cygdrive/c/svn/OlympusIoBox/IoBox_MCU/trunkC'
HOME = '/home/yangwe'

HOMEPATH = '\Users\yangwe'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man'
APPDATA = 'C:\Users\yangwe\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'PCSZYANGWE01'
SHELL = '/bin/bash'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 60 Stepping 3, GenuineIntel'
PROFILEREAD = 'true'
WINDIR = 'C:\Windows'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/cygdrive/c/svn/OlympusIoBox/IoBox_MCU'
ORIGINAL_PATH =
'/cygdrive/c/Users/yangwe/algs4/java/bin:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program
Files (x86)/CollabNet/Subversion
Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/Intel/WiFi/bin:/cygdrive/c/Program Files/Common
Files/Intel/WirelessCommon:/cygdrive/c/Program
Files/TortoiseSVN/bin:/cygdrive/c/Program Files (x86)/Code
Collaborator Client:/cygdrive/c/Program Files (x86)/MATLAB/R2012a
Student/bin:/cygdrive/c/Go/bin:/cygdrive/c/WS/gocode/bin:/cygdrive/c/Xilinx/13.4/LabTools/LabTools/bin/nt64:/cygdrive/c/Program
Files (x86)/Microsoft SDKs/Azure/AzCopy:/cygdrive/c/Program Files
(x86)/Beyond Compare
4:/cygdrive/c/Users/yangwe/algs4/bin:/cygdrive/c/Users/yangwe/algs4/java/bin:/usr/bin:/cygdrive/c/GNUtoolsForVim/cscope157:/cygdrive/c/GNUtoolsForVim/ctags58:/cygdrive/c/GNUtoolsForVim/TrueGNUTools:/cygdrive/c/WS/zeal'
USERDOMAIN = 'SHURE'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
//
UATDATA = "Omitted by Wenbo"
//
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
windows_tracing_flags = '3'
windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log'
VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\'
!:: = '::\'
TEMP = '/tmp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
SAPLOGON_INI_FILE = 'c:\windows\saplogon.ini'
USERNAME = 'yangwe'
PROCESSOR_LEVEL = '6'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;c:\Program
Files\Microsoft Security Client\MpProvider\'
WRSD_LICENSE_FILE = '27009@ms-vm16'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
VS120COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\Tools\'
USERPROFILE = 'C:\Users\yangwe'
TZ = 'Asia/Shanghai'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\MS-SZ12'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'AMD64'
LOCALAPPDATA = 'C:\Users\yangwe\AppData\Local'
ProgramData = 'C:\ProgramData'
EXECIGNORE = '*.dll'
SHLVL = '1'
USERDNSDOMAIN = 'SHURE.COM'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
GOROOT = 'C:\Go\'
BONJOUR_SDK_HOME = 'C:\Program Files\Bonjour SDK\'
HOMEDRIVE = 'C:'
BW = 'c:\SAP'
COMSPEC = 'C:\Windows\system32\cmd.exe'
TMP = '/tmp'
SYSTEMROOT = 'C:\Windows'
PRINTER = '\\ms-sz11\Canon iR2022/2025/2030 UFRII LT'
PROCESSOR_REVISION = '3c03'
KSDK_PATH = 'C:\Freescale\KSDK1.1.0_K21DA_KW24D_1.0.0'
SAPLOGON_FILE = 'c:\windows\saplogon.ini'
GOPATH = 'C:\WS\gocode'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '8'
SESSIONNAME = 'Console'
COMPUTERNAME = 'PCSZYANGWE01'
_ = '/usr/bin/cygc

svn1.9.1, segmentation fault when calling "svn diff -c .", on MS Windows7

[Wb Yang]

Segmentation fault happens 100% when calling:

svn diff -c .

In "svn.exe.stackdump":
/
Exception: STATUS_ACCESS_VIOLATION at rip=00180198BAD

rax= rbx=0006002409F8 rcx=

rdx=0006002409F8 rsi=0006000571D8 rdi=0022B848

r8 =0006002409F8 r9 =0006002409F8 r10=FEFEFEFEFEFEFEFF

r11=000F r12= r13=0022B8F0

r14=000600242130 r15=0022B848

rbp= rsp=0022B708

program=C:\cygwin64\bin\svn.exe, pid 4812, thread main

cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

Stack trace:

FrameFunctionArgs

000  00180198BAD (006000B1FA8, 000, 006000B21C0, 00600242130)

000  003EFFC6D47 (00600241F48, 003F1840980, 006002409F8, 006002409F8)

00600242130  003F1836398 (006002409F8, 00277D0, 00600240B18, 006002409F8)

006002409F8  003F182C729 (018, 00277D0, 003EFFB0D3F, 00277D0)

000  003F1825272 (00600214588, 022BA48, 022BA50, 000)

006002409F8  003F1C92CBF (00600214600, 00F, 003F213111A, 006000EF31C)

006002409F8  003F1C92D9B (0060021F0E8, 00600214588, 000, 0060023CFD0)

0060023CEC8  003F18311E6 (005, 00600214600, 006000EFBD2, 00600214588)

0060021F0E8  003F18332B8 (006, 017FFE8, 006000EFB88, 006000A2F48)

006000EFBD2  003F183717D (00180300778, 001, 0001B20, 006000EFBC0)

0060020B5D0  003FBFB7937 (400, 004, 0060023F448, 0060023FD61)

006000ED6B8  003FBFB85D3 (006000DC85C, 004, 022BF90, 006000ED6B8)

006000ED6B8  003FBFBA52F (006000EAF28, 000, 346DC5D63886594B,
008)

006000ED6B8  003F1837A7B (000, 006000ED6B8, 006000AAF88, 006000A1A38)

00600201358  003F1833AD8 (006000DA8A8, 006000B8068, 003F2504E09, 006000B5FD8)

006000ED6B8  003F1835EC0 (003F2503143, 008, 006000AAF88, 00600218DD8)

End of stack trace (more stack frames may be present



In "cygcheck.out"
/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn1.9.1, segmentation fault when calling "svn diff -c .", on MS Windows7

[David Rothenberger]

Wb Yang wrote:
> Segmentation fault happens 100% when calling:
> 
> svn diff -c .

"svn diff -c ." is not a valid command. The "-c" switch expects a
numeric argument. I get an error message when I try it, not a segfault.

Does this recipe work for you?

% mkdir /tmp/svn
% cd /tmp/svn
% svnadmin create repos
% r=file:///tmp/svn/repos
% svn co $r work
Checked out revision 0.
% cd work
% date > file
% svn add file
A file
% svn commit -m 1
Adding file
Transmitting file data .done
Committing transaction...
Committed revision 1.
% date > file
% svn diff -c .
svn: E205000: Non-numeric change argument (.) given to -c
% svn diff -c 1
Index: file
===
--- file(nonexistent)
+++ file(revision 1)
@@ -0,0 +1 @@
+Thu, Sep 10, 2015 10:23:38 AM


-- 
David Rothenberger    daver...@acm.org

Cygwin Subversion maintainer


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [Attn Maintainer] git git-svn

[Adam Dinwoodie]

On Sun, Aug 02, 2015 at 08:35:25AM +0200, Achim Gratz wrote:
 The tests for 2.5.0 just completed:
 
 --8---cut here---start-8---
 fixed   1
 success 12528
 failed  0
 broken  179
 total   12808
 --8---cut here---end---8---
 
 …on both architectures.  I do not have cvs installed, so those tests (as
 well as Perforce) have not run.

I'm going to continue to be cautious: while I think the risk of bumping
up to v2.5.0 is very low, if there are problems with that or any of the
other numerous recent changes (this has been the first time a release
has got above the -1 version since I took over maintainership), I want
to keep the changes reasonably slow to help narrow down where the
problem comes from.

 A few suggestions for changes to the cygport:
 
 --8---cut here---start-8---
 SRC_URI=https://git.kernel.org/cgit/git/git.git/snapshot/${PN}-v${PV}.tar.gz;
 SRC_DIR=${PN}-v${PV}
 --8---cut here---end---8---
 
 Then not inherit git, a snapshot is less wasteful then the cloning
 unless you plan to really work with the repository which cygport makes
 difficult anyway.

Done.  I switched from something similar when I took over the
maintainership, as using inherit git seemed like The Right Thing To Do
when I was first playing around with Cygport.  As you say, though, it's
just adding overhead with no advantage.  (Indeed if I want to play
around with the Git repository itself, I already have a copy of that
ready to go.)


 --8---cut here---start-8---
 [[ $ARCH_x86_64 ]]  DEPEND=$DEPEND libiconv libiconv-devel
 --8---cut here---end---8---
 
 Drop this line and add libiconv, libiconv-devel plus dblatex to the
 DEPENDS unconditionally.

I'm sure when I first added that line, it made sense with the
dependencies.  I've made this change as well now, though, as it seems to
be the right thing to do at this point.

Thanks!

Adam

Re: [Attn Maintainer] git git-svn

[Adam Dinwoodie]

On Sat, Aug 01, 2015 at 08:17:59PM +0200, Achim Gratz wrote:
 Adam Dinwoodie writes:
  I think git-svn should and used to depend on subversion-perl, but
  this seems to have gone missing, somehow.
 
  How very odd! That was one of the automatically generated
  dependencies, so presumably the dependency generation has just gone a
  bit sideways, probably because of the Perl version change.
 
 I don't think so, that package hasn't been renamed or anything like
 that.  As long as the installed.db and the *.lst.gz files are OK, it
 should find these.

Well my latest rebuild picked up the dependency automatically, and the
only thing I can think of that changed between the two is that I picked
up the latest version of subversion-perl.

Whatever it was, it's fixed now :)

Re: [Attn Maintainer] git git-svn

[Achim Gratz]

Adam Dinwoodie writes:
 I'm going to continue to be cautious: while I think the risk of bumping
 up to v2.5.0 is very low, if there are problems with that or any of the
 other numerous recent changes (this has been the first time a release
 has got above the -1 version since I took over maintainership), I want
 to keep the changes reasonably slow to help narrow down where the
 problem comes from.

No problem.  I just had to run the build box overnight anyway and
figured it would get through a Git build until I looked at it in the
morning.

 Done.  I switched from something similar when I took over the
 maintainership, as using inherit git seemed like The Right Thing To Do
 when I was first playing around with Cygport.  As you say, though, it's
 just adding overhead with no advantage.  (Indeed if I want to play
 around with the Git repository itself, I already have a copy of that
 ready to go.)

I have a few packages that use Git repositories, but I always clone them
from local repos.  That won't work for official packages obviously, but
if cygport gets smarter and caches the repos someplace else (like
already possible with package archives) it might be more useful to work
from a Git repo.  Especially if cygport was getting smart enough to get
a tarball instead of cloning if it isn't set up to cache the repo.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [Attn Maintainer] git git-svn

[Achim Gratz]

Adam Dinwoodie writes:
 I'm going to look at taking the latest upstream releases once the new
 version of Perl has been released; I didn't want to take a version bump
 while we are also taking other changes.

The tests for 2.5.0 just completed:

--8---cut here---start-8---
fixed   1
success 12528
failed  0
broken  179
total   12808
--8---cut here---end---8---

…on both architectures.  I do not have cvs installed, so those tests (as
well as Perforce) have not run.

A few suggestions for changes to the cygport:

--8---cut here---start-8---
SRC_URI=https://git.kernel.org/cgit/git/git.git/snapshot/${PN}-v${PV}.tar.gz;
SRC_DIR=${PN}-v${PV}
--8---cut here---end---8---

Then not inherit git, a snapshot is less wasteful then the cloning
unless you plan to really work with the repository which cygport makes
difficult anyway.

--8---cut here---start-8---
[[ $ARCH_x86_64 ]]  DEPEND=$DEPEND libiconv libiconv-devel
--8---cut here---end---8---

Drop this line and add libiconv, libiconv-devel plus dblatex to the
DEPENDS unconditionally.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [Attn Maintainer] git git-svn

[Jon TURNEY]

On 30/07/2015 20:41, Achim Gratz wrote:

Adam Dinwoodie writes:

These packages are now uploaded, with a !perl file instead of a
!ready file.


Thanks.


I'm going to look at taking the latest upstream releases once the new
version of Perl has been released; I didn't want to take a version bump
while we are also taking other changes.


I think git-svn should and used to depend on subversion-perl, but this 
seems to have gone missing, somehow.

Re: [Attn Maintainer] git git-svn

[Adam Dinwoodie]

On 01/08/2015 15:18, Jon TURNEY wrote:

On 30/07/2015 20:41, Achim Gratz wrote:

Adam Dinwoodie writes:

These packages are now uploaded, with a !perl file instead of a
!ready file.


Thanks.


I'm going to look at taking the latest upstream releases once the new
version of Perl has been released; I didn't want to take a version bump
while we are also taking other changes.


I think git-svn should and used to depend on subversion-perl, but this 
seems to have gone missing, somehow.


How very odd! That was one of the automatically generated dependencies, 
so presumably the dependency generation has just gone a bit sideways, 
probably because of the Perl version change.


I'm expecting to be away for most of the weekend, so I'll try and 
rebuild early next week; hopefully once all the other Perl-related 
packages have stabilised, it'll pick up the dependency automatically 
again, but if not, I'll just add it manually.


(In theory I could go digging into how Cygport works out such 
dependencies, but it's all black magic to me so I'm just going to take 
the lazy option for now.)

Re: [Attn Maintainer] git git-svn

[Achim Gratz]

Adam Dinwoodie writes:
 I think git-svn should and used to depend on subversion-perl, but
 this seems to have gone missing, somehow.

 How very odd! That was one of the automatically generated
 dependencies, so presumably the dependency generation has just gone a
 bit sideways, probably because of the Perl version change.

I don't think so, that package hasn't been renamed or anything like
that.  As long as the installed.db and the *.lst.gz files are OK, it
should find these.  Here's what I get from cygport git pkg:

 git requires: bash libcurl4 libexpat1 libgcc1 libiconv2 libintl8 
 libopenssl100 libpcre1 perl perl-Error perl-TermReadKey perl_base python 
 zlib0 cygutils less openssh rsync
 gitk requires: bash tcl-tk git font-adobe-dpi75
 gitweb requires: bash perl-Plack perl_base ruby git lighttpd
 git-completion requires:  bash bash-completion git
 git-cvs requires: git perl perl-DBI perl_base cvsps perl-DBD-SQLite
 git-email requires: git perl perl-Error perl-IO-Socket-SSL perl_base 
 git-gui requires: bash tcl-tk git gitk
 git-svn requires: git perl perl-YAML perl_base subversion-perl 

 I'm expecting to be away for most of the weekend, so I'll try and
 rebuild early next week; hopefully once all the other Perl-related
 packages have stabilised, it'll pick up the dependency automatically
 again, but if not, I'll just add it manually.

 (In theory I could go digging into how Cygport works out such
 dependencies, but it's all black magic to me so I'm just going to take
 the lazy option for now.)

Basically it looks for executable and scripts and determines which
packages these belong to by looking at the package list files.  For Perl
scripts in particular it then tries to find out which modules are used
and then which package these belong to.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [Attn Maintainer] git git-svn

[Achim Gratz]

Adam Dinwoodie writes:
 These packages are now uploaded, with a !perl file instead of a
 !ready file.

Thanks.

 I'm going to look at taking the latest upstream releases once the new
 version of Perl has been released; I didn't want to take a version bump
 while we are also taking other changes.

That's probably a good idea.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [Attn Maintainer] git git-svn

[Adam Dinwoodie]

On Tue, Jul 28, 2015 at 07:43:56AM +0200, Achim Gratz wrote:
 Adam Dinwoodie writes:
  I'm just waiting for it to finish running through the test suite
  before I upload :)
 
 Thank you.

These packages are now uploaded, with a !perl file instead of a
!ready file.

I'm going to look at taking the latest upstream releases once the new
version of Perl has been released; I didn't want to take a version bump
while we are also taking other changes.

[Attn Maintainer] git git-svn

[Achim Gratz]

The update to Perl 5.22 is planned for the end of this week.  Please
notify immediately if you cannot provide the updated packages indicated
below by then to your package upload area on cygwin.com.

Your following packages place Perl modules into vendor_perl and need an
update or re-release using Perl version 5.22:

git
git-svn


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Waldorf MIDI Implementation  additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [Attn Maintainer] git git-svn

[Adam Dinwoodie]

On 27/07/2015 20:45, Achim Gratz wrote:

The update to Perl 5.22 is planned for the end of this week.  Please
notify immediately if you cannot provide the updated packages indicated
below by then to your package upload area on cygwin.com.

Your following packages place Perl modules into vendor_perl and need an
update or re-release using Perl version 5.22:

git
git-svn


I'm just waiting for it to finish running through the test suite before 
I upload :)

Re: [Attn Maintainer] git git-svn

[Achim Gratz]

Adam Dinwoodie writes:
 I'm just waiting for it to finish running through the test suite
 before I upload :)

Thank you.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Re: Problem using svn 1.8.13 accessing UNC network pathes under cygwin 1.7.35-1

[Tobias Zawada]

Dear David, dear Corinna,
thanks for your fast response and the workaround, David.

I know the possibility to mount network paths via /etc/fstab.
Pityingly, this is not a good alternative for me because I am in a productive
environment and use a series of existing links in a series of orgmode files (for
emacs). Changing the links would mean to change existing logs. Up to now I use
symbolic links as a workaround. This works from the command line but not from
within emacs since emacs vc-mode resolves the links before it uses them.

Could it be that the problem is related to the following one:

https://cygwin.com/ml/cygwin/2013-07/msg00376.html

If this is the case I assume that the problem has little to do with svn itself
but with the cygwin-dll and should be fixed by Corinna. But, that is just my
humble guess.

Note, that I tried to give the link already in the previous mail but everything
I wrote was rejected by the mail server because of an exceeded spam-level. I
tried to keep the spam level low in avoiding the verbatim link.
I finally succeeded in subscribing to the mailing list. So, I am trying again...

Best regards,
Tobias Zawada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem using svn 1.8.13 accessing UNC network pathes under cygwin 1.7.35-1

[David Rothenberger]

Tobias Zawada wrote:
 Dear David, dear Corinna,
 thanks for your fast response and the workaround, David.
 
 Could it be that the problem is related to the following one:
 
 https://cygwin.com/ml/cygwin/2013-07/msg00376.html

I believe Corinna has fix the issue in that message.

I've made some attempts to get UNC paths working with svn in the past,
but obviously I have not succeeded. I urge you to try to patch either
libapr1 or subversion yourself to correct the problem, if you have the
necessary coding skills. I honestly don't forsee myself having the time
or interest to fix this myself, especially since I no longer use svn.

-- 
David Rothenberger    daver...@acm.org

Sweater, n.:
A garment worn by a child when its mother feels chilly.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem using svn 1.8.13 accessing UNC network pathes under cygwin 1.7.35-1

[David Rothenberger]

On 4/24/2015 8:53 AM, Tobias Nähring wrote:
 Hi,
 I am experiencing the following problem again:
 
 
 2013-07 msg00376.html
 
 UNC paths are not recognized by svn.
 The double slash at the beginning of UNC paths gets lost:
 
 svn status -u //servername/some/path/under/svn
 svn: warning: W155007: '/servername/some/path/under/svn ' is not a working 
 copy

I'm the maintainer of svn and libapr1. I'm sure there is a bug in there
somewhere, but I haven't been able to find it myself. I don't use svn
much and don't have much free time, so I don't expect to investigate this.

If you want to provide a patch to fix the problem, I'm willing to run
the libapr1 and subversion unit tests with it.

Otherwise, I suggest you mount the UNC path through /etc/fstab and use
the mount point instead of the UNC path with svn.

-- 
David Rothenberger    daver...@acm.org

hacker, n.:
A master byter.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Problem using svn 1.8.13 accessing UNC network pathes under cygwin 1.7.35-1

[Tobias Nähring]

Hi,
I am experiencing the following problem again:


2013-07 msg00376.html

UNC paths are not recognized by svn.
The double slash at the beginning of UNC paths gets lost:

svn status -u //servername/some/path/under/svn
svn: warning: W155007: '/servername/some/path/under/svn ' is not a working copy

The output of svn --version:

svn, version 1.8.13 (r1667537)
   compiled Apr  3 2015, 11:17:12 on x86_64-unknown-cygwin

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE file
for more information.
Subversion is open source software, see http...

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.8
  - handles 'http' scheme
  - handles 'https' scheme

Parts of the output of cygcheck -c:
cygwin  1.7.35-1  OK
subversion  1.8.13-1  OK
subversion-apache2  1.8.13-1  OK
subversion-gnome1.8.13-1  OK
subversion-perl 1.8.13-1  OK
subversion-python   1.8.13-1  OK
subversion-tools1.8.13-1  OK

I hope this helps to locate the source of the problem.

Best regards,
Tobias Zawada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[Csaba Raduly]

On Wed, Mar 18, 2015 at 7:45 PM, David Stacey  wrote:
 I have a PC with both Cygwin and TortoiseSVN.

Using both Cygwin svn and TortoiseSVN on the same repo is problematic.
Even if you don't run into locking problems, the native line-ending
differs (Cygwin's svn uses LF, TortoiseSVN uses CR LF). I've had these
problems in the past :(

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
Ok, it boots. Which means it must be bug-free and perfect.  -- Linus Torvalds
People disagree with me. I just ignore them. -- Linus Torvalds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[Jan Nijtmans]

2015-03-19 5:01 GMT+01:00 Eric Pement eric.pem...@gmail.com:
 The TortoiseSVN FAQ file, answering the question of whether one can
 use different SVN clients on the same working copy, says this is not
 recommended.
 The FAQ mentions Cygwin in particular:

I am aware of this FAQ entry, but with latest SQLite versions this
is not a problem any more, as cygwin SQLite uses the
same locking semantics as the sqlite client in TortoiseSVN does.
I am using TortoiseSVN in combination with the cygwin svn client
without any problem (but I understand the suspicion due to
past experience).

Another reason why I don't think the locking is the problem:
 svn: E13: Can't open file '/cygdrive/D/xxx/yyy/.svn/tmp/svn-sckggY': 
 Permission denied

The SQLite database file can be found in /cygdrive/D/xxx/yyy/.svn/wc.db',
so any file opened by SQLite can only be this file (or related .wal/.journal
file), or some temporary file named something like '/tmp/etilqs*'. The file,
'svn-sckggY' doesn't look like that, so it's opened by subversion, not by
SQLite. That's why the recent ACL-related changed in cygwin are
more likely causing the problem here.

Anyway, thanks for your report!

Regards,
  Jan Nijtmans

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[Jan Nijtmans]

2015-03-19 10:55 GMT+01:00 Csaba Raduly rcs...@gmail.com:
 Using both Cygwin svn and TortoiseSVN on the same repo is problematic.
 Even if you don't run into locking problems, the native line-ending
 differs (Cygwin's svn uses LF, TortoiseSVN uses CR LF). I've had these
 problems in the past :(

Me too, but it is very well workable with the following two measures:

- Change the svn config and servers files to being hyperlinks to
  the windows version of those file. For example:
$ pwd
/home/nijtmaj/.subversion
$ ls -la
total 14
drwxr-xr-x+ 1 nijtmaj None0 Mar 19 12:20 .
drwxr-xr-x+ 1 nijtmaj None0 Mar  3 17:12 ..
drwx--+ 1 nijtmaj None0 Nov 14  2013 auth
lrwxrwxrwx  1 nijtmaj None   59 Mar 19 12:20 config -
/cygdrive/c/Users/nijtmaj/AppData/Roaming/Subversion/config
-rw-r--r--  1 nijtmaj None 4276 Nov 14  2013 README.txt
lrwxrwxrwx  1 nijtmaj None   60 Mar 13  2014 servers -
/cygdrive/c/Users/nijtmaj/AppData/Roaming/Subversion/servers
  This way, the settings for cygwin and win32 are always consistant.
  (maybe it works for the auth directory as well, didn't try/need that)
- Never user svn:eo-style=native, always either svn:eo-style=LF or
svn:eo-style=CRLF

This way, it works very well for me.

Regards,
 Jan Nijtmans

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[David Stacey]

On 19/03/15 04:01, Eric Pement wrote:

On Wed, Mar 18, 2015 at 2:45 PM, David Staceydrsta...@tiscali.co.uk  wrote:


I have a PC with both Cygwin and TortoiseSVN. When I try to commit through
Cygwin svn, I get the following:

... [rest omitted] ...

The TortoiseSVN FAQ file, answering the question of whether one can
use different SVN clients on the same working copy, says this is not
recommended.


Whilst that might be the official line from TortoiseSVN, I've been using 
Cygwin svn and TortoiseSVN together for quite a few years. With the 
exception of the locking problem 2 or 3 years ago (which Warren fixed), 
the two work happily on the same working copy.


I *am* careful to force my line endings in the auto-props settings though.

Dave.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[David Stacey]

On 18/03/15 20:57, Denis Excoffier wrote:

On 2015-03-18 19:45, David Stacey wrote:

I have a PC with both Cygwin and TortoiseSVN. When I try to commit through 
Cygwin svn, I get the following (slightly redacted):

Committed revision n.
svn: E20: Commit succeeded, but other errors follow:
svn: E155009: Error bumping revisions post-commit (details follow):
svn: E155009: Failed to run the WC DB work queue associated with 
'/cygdrive/D/xxx/yyy', work item 528 (file-commit aaa/bbb.c)
svn: E13: Can't open file '/cygdrive/D/xxx/yyy/.svn/tmp/svn-sckggY': 
Permission denied

Just in case: mount the appropriate part of your D disk with the 'noacl' 
option, ie add something like
D:/Wherever/Is/Your/SVNRepository /svnR ntfs cygexec,noacl
at the end of your /etc/fstab


Thank you so much for reminding me about the 'noacl' mount option. I set 
that in /etc/fstab, and have been flitting between Cygwin svn and 
TortoiseSVN all day and it has worked fine.


Dave.

PS: This is my third attempt at sending this reply - not sure where the 
other two went. Apologies if you receive several copies...



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[David Stacey]

On 18/03/15 20:57, Denis Excoffier wrote:

On 2015-03-18 19:45, David Stacey wrote:

I have a PC with both Cygwin and TortoiseSVN. When I try to commit through 
Cygwin svn, I get the following (slightly redacted):

Committed revision n.
svn: E20: Commit succeeded, but other errors follow:
svn: E155009: Error bumping revisions post-commit (details follow):
svn: E155009: Failed to run the WC DB work queue associated with 
'/cygdrive/D/xxx/yyy', work item 528 (file-commit aaa/bbb.c)
svn: E13: Can't open file '/cygdrive/D/xxx/yyy/.svn/tmp/svn-sckggY': 
Permission denied

Just in case: mount the appropriate part of your D disk with the 'noacl' 
option, ie add something like
D:/Wherever/Is/Your/SVNRepository /svnR ntfs cygexec,noacl
at the end of your /etc/fstab,
and use
file:///svnR
for your repo.


Thank you for your reply. It's a good thought about ACLs - my immediate 
thought was that this must be a locking problem, so I never considered ACLs.


My repository is on a server, accessed over https. The errors are coming 
from the svn client updating the working copy. This working copy is on 
the 'D' drive, so I'll try mounting '/cygdrive/d' as 'noacl' and see if 
that helps.


Dave.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[Eric Pement]

On Wed, Mar 18, 2015 at 2:45 PM, David Stacey drsta...@tiscali.co.uk wrote:

 I have a PC with both Cygwin and TortoiseSVN. When I try to commit through
 Cygwin svn, I get the following:
... [rest omitted] ...

The TortoiseSVN FAQ file, answering the question of whether one can
use different SVN clients on the same working copy, says this is not
recommended.
The FAQ mentions Cygwin in particular:

You must also be sure that all the clients are built for the same
OS. Client compatibility
is only guaranteed for a particular OS type and metadata
representations may differ.
You must not use a native Windows client and the Cygwin client on
the same working copy.
( from http://tortoisesvn.net/faq.html#multiclients )

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Cygwin svn vs. TortoiseSVN?

[David Stacey]

I have a PC with both Cygwin and TortoiseSVN. When I try to commit 
through Cygwin svn, I get the following (slightly redacted):


Committed revision n.
svn: E20: Commit succeeded, but other errors follow:
svn: E155009: Error bumping revisions post-commit (details follow):
svn: E155009: Failed to run the WC DB work queue associated with 
'/cygdrive/D/xxx/yyy', work item 528 (file-commit aaa/bbb.c)
svn: E13: Can't open file '/cygdrive/D/xxx/yyy/.svn/tmp/svn-sckggY': 
Permission denied


Once in this state, the working copy has to be cleaned up (using 
TortoiseSVN; attempting a 'svn cleanup' from Cygwin results in similar 
errors). Is this to do with the VFS locking semantics in sqlite3 that 
replaced the CYGWIN_SQLITE_LOCKING environment variable?


I'm using TortoiseSVN-1.8.10 (built against Subversion 1.8.11). The 
pertinent Cygwin packages are as follows:


Package  VersionStatus
cygwin   1.7.35-1   OK
libsqlite3_0 3.8.8.3-1  OK
subversion   1.8.11-1   OK

Any help would be greatly appreciated.

Thanks in advance,

Dave.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin svn vs. TortoiseSVN?

[Denis Excoffier]

On 2015-03-18 19:45, David Stacey wrote:
 
 I have a PC with both Cygwin and TortoiseSVN. When I try to commit through 
 Cygwin svn, I get the following (slightly redacted):
 
 Committed revision n.
 svn: E20: Commit succeeded, but other errors follow:
 svn: E155009: Error bumping revisions post-commit (details follow):
 svn: E155009: Failed to run the WC DB work queue associated with 
 '/cygdrive/D/xxx/yyy', work item 528 (file-commit aaa/bbb.c)
 svn: E13: Can't open file '/cygdrive/D/xxx/yyy/.svn/tmp/svn-sckggY': 
 Permission denied

Just in case: mount the appropriate part of your D disk with the 'noacl' 
option, ie add something like
D:/Wherever/Is/Your/SVNRepository /svnR ntfs cygexec,noacl
at the end of your /etc/fstab,
and use
file:///svnR
for your repo.

See also for https://cygwin.com/cygwin-ug-net/using.html#mount-table, 
especially the word suddenly.

Hope this helps.

Denis Excoffier.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn-bisect no longer in subversion-tools

[Csaba Raduly]

On Wed, Jan 7, 2015 at 7:14 PM, David Rothenberger  wrote:
...

 I no longer use Subversion, having switched to git,

Heretic!

(: Csaba :)
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
Ok, it boots. Which means it must be bug-free and perfect.  -- Linus Torvalds
People disagree with me. I just ignore them. -- Linus Torvalds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn-bisect no longer in subversion-tools

[David Stacey]

On 07/01/2015 18:14, David Rothenberger wrote:

On 1/7/2015 7:18 AM, Ken Brown wrote:

/usr/bin/svn-bisect is not in the current release of subversion-tools,
but it's in the previous release.  Is this a packaging oversight or a
deliberate decision?

It was an explicit decision by me, the package maintainer. The 1.7
release series had an svn-bisect that I grabbed from Debian. It is not
part of the official Subversion repository. In 1.8, Subversion upstream
decided to remove many of the contributed tools from their repository. I
decided at the same time to drop svn-bisect and a few other tools from
Debian because Debian does not have 1.8 and it felt to me like
svn-bisect should be a separate package.


I took a brief look at this. For the record, there are two completely 
different scripts called svn-bisect, depending on which Linux distro you 
use. The script mentioned above is a shell script found in Debian / 
Ubuntu. The entire script is patched in during the subversion build 
process, and it is packaged in Debian's 'subversion-tools'.


Fedora / Centos have a perl script (also called svn-bisect) coming from 
the App-SVN-Bisect perl module. The script is in its own package, also 
called 'svn-bisect'. This won't run in Cygwin as things stand, as a 
number of dependent perl modules are missing.


The two scripts perform the same function, and the calling syntax is 
/nearly/ the same...


Dave.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn-bisect no longer in subversion-tools

[David Rothenberger]

On 1/7/2015 7:18 AM, Ken Brown wrote:
 /usr/bin/svn-bisect is not in the current release of subversion-tools,
 but it's in the previous release.  Is this a packaging oversight or a
 deliberate decision?

It was an explicit decision by me, the package maintainer. The 1.7
release series had an svn-bisect that I grabbed from Debian. It is not
part of the official Subversion repository. In 1.8, Subversion upstream
decided to remove many of the contributed tools from their repository. I
decided at the same time to drop svn-bisect and a few other tools from
Debian because Debian does not have 1.8 and it felt to me like
svn-bisect should be a separate package.

I no longer use Subversion, having switched to git, so it's unlikely
that I'll package svn-bisect. Any other interested parties are certain
welcome to create a package for it, though.

-- 
David Rothenberger    daver...@acm.org

QOTD:
I haven't come far enough, and don't call me baby.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

svn-bisect no longer in subversion-tools

[Ken Brown]

/usr/bin/svn-bisect is not in the current release of subversion-tools, but it's 
in the previous release.  Is this a packaging oversight or a deliberate decision?


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Issue with cygwin svn and files with unicode characters

[olivier barthelemy]

Hi,

I am sending this here and not to subversion project directly, since i
am seeing my problem in svn 1.8.1 of cygwin, but not on SVN 1.8.1 of
TortoiseSVN.

I just added a file with unicode chinese characters in a folder where
a repository is checked out. I didn't add that file to the repository,
it's only present locally. However, when i do a svn update from
cygwin, i get the errror :

svn: E22: Error converting entry in directory '/my/path' to UTF-8
svn: E22: Can't convert string from native encoding to 'UTF-8':
svn: E22: File?\232?\139?\185?\230?\158?\156.txt

Numeric codes correspond to 苹果

As far as i know, windows file paths are always encoded in unicode, so
why is it assuming that my locale encoding is different than that?
And why is this error on a file that is not versionned preventing me
from updating my repository?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issue with cygwin svn and files with unicode characters

[Eliot Moss]

On 7/21/2014 10:15 AM, olivier barthelemy wrote:

Hi,

I am sending this here and not to subversion project directly, since i
am seeing my problem in svn 1.8.1 of cygwin, but not on SVN 1.8.1 of
TortoiseSVN.

I just added a file with unicode chinese characters in a folder where
a repository is checked out. I didn't add that file to the repository,
it's only present locally. However, when i do a svn update from
cygwin, i get the errror :

svn: E22: Error converting entry in directory '/my/path' to UTF-8
svn: E22: Can't convert string from native encoding to 'UTF-8':
svn: E22: File?\232?\139?\185?\230?\158?\156.txt

Numeric codes correspond to 苹果

As far as i know, windows file paths are always encoded in unicode, so
why is it assuming that my locale encoding is different than that?
And why is this error on a file that is not versionned preventing me
from updating my repository?


Perhaps you can tell us how you have your locale set up in cygwin.
I think it *might* affect things, though you *are* talking about
file names (paths), as opposed to their contents.  The locale is
affected by things like the LANG environment variable, etc.

Regards -- Eliot Moss

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Unable to update svn to 1.8.8.1

[Robert Mark]

Hi All,

I am using setup-x86_64.exe and choosing the latest SVN clients:
http://i.imgur.com/TUyRyAq.png

But after installing (and a reboot), SVN still shows up as the old version.

Sun Mar 02 - 10:26 PM  svn --version
svn, version 1.7.6 (r1370777)
   compiled Aug 22 2012, 15:38:04

It doesn't appear to be aliases anywhere else..

Sun Mar 02 - 10:30 PM  type svn
svn is hashed (/usr/bin/svn)

Sun Mar 02 - 10:30 PM  which svn
/usr/bin/svn

Any idea what I am doing wrong?

Rob
:)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to update svn to 1.8.8.1

[Andrey Repin]

Greetings, Robert Mark!

 I am using setup-x86_64.exe and choosing the latest SVN clients:
 http://i.imgur.com/TUyRyAq.png

 But after installing (and a reboot), SVN still shows up as the old version.

 Sun Mar 02 - 10:26 PM  svn --version
 svn, version 1.7.6 (r1370777)
compiled Aug 22 2012, 15:38:04

 It doesn't appear to be aliases anywhere else..

 Sun Mar 02 - 10:30 PM  type svn
 svn is hashed (/usr/bin/svn)

 Sun Mar 02 - 10:30 PM  which svn
 /usr/bin/svn

 Any idea what I am doing wrong?

Should be /bin/svn
There's no separate /usr/bin in Cygwn. Most likely, you're looking at the
wrong place.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 15:54

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to update svn to 1.8.8.1

[Robert Mark]

/bin/svn is the old version too...

Sun Mar 02 - 11:43 PM  /bin/svn --version
svn, version 1.7.6 (r1370777)
   compiled Aug 22 2012, 15:38:04



On Sun, Mar 2, 2014 at 10:55 PM, Andrey Repin anrdae...@yandex.ru wrote:
 Greetings, Robert Mark!

 I am using setup-x86_64.exe and choosing the latest SVN clients:
 http://i.imgur.com/TUyRyAq.png

 But after installing (and a reboot), SVN still shows up as the old version.

 Sun Mar 02 - 10:26 PM  svn --version
 svn, version 1.7.6 (r1370777)
compiled Aug 22 2012, 15:38:04

 It doesn't appear to be aliases anywhere else..

 Sun Mar 02 - 10:30 PM  type svn
 svn is hashed (/usr/bin/svn)

 Sun Mar 02 - 10:30 PM  which svn
 /usr/bin/svn

 Any idea what I am doing wrong?

 Should be /bin/svn
 There's no separate /usr/bin in Cygwn. Most likely, you're looking at the
 wrong place.


 --
 WBR,
 Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 15:54

 Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to update svn to 1.8.8.1

[Robert Mark]

Oh, I think I see what I have done - I seem to have both C:\cygwin64
and C:\cygwin installed. :/

On Sun, Mar 2, 2014 at 11:44 PM, Robert Mark
robertmarkbram.li...@gmail.com wrote:
 /bin/svn is the old version too...

 Sun Mar 02 - 11:43 PM  /bin/svn --version
 svn, version 1.7.6 (r1370777)
compiled Aug 22 2012, 15:38:04



 On Sun, Mar 2, 2014 at 10:55 PM, Andrey Repin anrdae...@yandex.ru wrote:
 Greetings, Robert Mark!

 I am using setup-x86_64.exe and choosing the latest SVN clients:
 http://i.imgur.com/TUyRyAq.png

 But after installing (and a reboot), SVN still shows up as the old version.

 Sun Mar 02 - 10:26 PM  svn --version
 svn, version 1.7.6 (r1370777)
compiled Aug 22 2012, 15:38:04

 It doesn't appear to be aliases anywhere else..

 Sun Mar 02 - 10:30 PM  type svn
 svn is hashed (/usr/bin/svn)

 Sun Mar 02 - 10:30 PM  which svn
 /usr/bin/svn

 Any idea what I am doing wrong?

 Should be /bin/svn
 There's no separate /usr/bin in Cygwn. Most likely, you're looking at the
 wrong place.


 --
 WBR,
 Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 15:54

 Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to update svn to 1.8.8.1

[Andrey Repin]

Greetings, Robert Mark!

 I am using setup-x86_64.exe and choosing the latest SVN clients:
 http://i.imgur.com/TUyRyAq.png

 But after installing (and a reboot), SVN still shows up as the old version.

 Sun Mar 02 - 10:26 PM  svn --version
 svn, version 1.7.6 (r1370777)
compiled Aug 22 2012, 15:38:04

 It doesn't appear to be aliases anywhere else..

 Sun Mar 02 - 10:30 PM  type svn
 svn is hashed (/usr/bin/svn)

 Sun Mar 02 - 10:30 PM  which svn
 /usr/bin/svn

 Any idea what I am doing wrong?

 Should be /bin/svn
 There's no separate /usr/bin in Cygwn.

 Oh, I think I see what I have done - I seem to have both C:\cygwin64
 and C:\cygwin installed. :/

 Most likely, you're looking at the wrong place.
^

Also, please don't http://cygwin.com/acronyms/#TOFU


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 17:05

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with SVN?

[David Stacey]

On 30/09/2013 13:08, Angelo Graziosi wrote:

David Stacey wrote:

Here are some ideas:

Firstly, check to see which versions of subversion, sqlite3 and 
cygwin you're using. Check the output of the following command, and 
if you're using older packages then try updating:


$ cygcheck -c cygwin sqlite3 subversion
Cygwin Package Information
Package  VersionStatus
cygwin   1.7.25-1   OK
sqlite3  3.7.17-3   OK
subversion   1.8.3-1OK


Same here (on XP 32)...


I have checked out the repo a second time, using the Cygwin packages 
listed above on Windows XP SP3. The operation completed successfully, 
checking out revision 203048. The operation took around 45 minutes.




Thirdly, if the database file is locked then that could point to an 
old version of sqlite3 (namely 3.7.12.1) clashing with another 
subversion client (e.g. TortoiseSVN), or some anti-virus software 
locking a file in the '.svn' directory (e.g. 'wc.db'). See if you can 
check out into an area of the drive that isn't being virus scanned.


For years I have the same AV (MSE) and I have used SVN without 
problems...


I think what you're seeing here is what we term a BLODA - some 
non-Cygwin application interfering with a Cygwin application. In your 
case, if you're not running a native Windows svn client then anti-virus 
is top of the suspect list. I know you claim that you have used MSE for 
years, but anti-virus tools update very frequently, and their behaviour 
can (and does) change. See the following link, under File access problems:

http://cygwin.com/faq/faq.html#faq.using.bloda

Your best bet is to either disable or tune the anti-virus tool so that 
it doesn't scan the '.svn' directory inside your working copy. If you do 
this, does the check out complete successfully? If you are not able to 
try this, can you get svn to recover? Try these two commands in succession:


$ svn cleanup directory
$ svn update directory

Does the check out complete (or at least get a little further)?

I've taken a look at the cygcheck output that you attached and it seems 
to be OK. So unless anyone else on this list can provide further 
insight, it really looks as if a third party (probably your anti-virus) 
is locking the 'wc.db' file whilst svn is trying to update it - and 
there's not much we can do about that.


Cheers,

Dave.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with SVN?

[Angelo Graziosi]

David Stacey wrote:

I think what you're seeing here is what we term a BLODA - some non-Cygwin application 
interfering with a Cygwin application. In your case, if you're not running a native 
Windows svn client then anti-virus is top of the suspect list. I know you claim that you 
have used MSE for years, but anti-virus tools update very frequently, and their behaviour 
can (and does) change. See the following link, under File access problems:
http://cygwin.com/faq/faq.html#faq.using.bloda

Your best bet is to either disable or tune the anti-virus tool so that it 
doesn't scan the '.svn' directory inside your working copy. If you do this, 
does the check out complete successfully? If you are not able to try this, can 
you get svn to recover? Try these two commands in succession:

$ svn cleanup directory
$ svn update directory

Does the check out complete (or at least get a little further)?

I've taken a look at the cygcheck output that you attached and it seems to be 
OK. So unless anyone else on this list can provide further insight, it really 
looks as if a third party (probably your anti-virus) is locking the 'wc.db' 
file whilst svn is trying to update it - and there's not much we can do about 
that.


As suggested here,

  http://gcc.gnu.org/ml/fortran/2013-09/msg00067.html

there is a git mirror which allows to download the fortran-dev branch..

Thanks,
 Angelo.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with SVN?

[Angelo Graziosi]

David Stacey wrote:

Here are some ideas:

Firstly, check to see which versions of subversion, sqlite3 and cygwin you're 
using. Check the output of the following command, and if you're using older 
packages then try updating:

$ cygcheck -c cygwin sqlite3 subversion
Cygwin Package Information
Package  VersionStatus
cygwin   1.7.25-1   OK
sqlite3  3.7.17-3   OK
subversion   1.8.3-1OK


Same here (on XP 32)...


Secondly, make sure you're using the cygwin version of 'svn' (i.e. check that 
some other subversion client isn't in your path):

$ which svn
/usr/bin/svn


I use only Cygwin...



Thirdly, if the database file is locked then that could point to an old version 
of sqlite3 (namely 3.7.12.1) clashing with another subversion client (e.g. 
TortoiseSVN), or some anti-virus software locking a file in the '.svn' 
directory (e.g. 'wc.db'). See if you can check out into an area of the drive 
that isn't being virus scanned.


For years I have the same AV (MSE) and I have used SVN without problems...


Fourth, the branch you're trying to check out is quite large. Are you running 
out of drive space?


No, I have about 30 GB free..

Attached the cygcheck...


Ciao,
 Angelo.


cygcheck_-svr.out.bz2
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with SVN?

[Warren Young]

On 9/29/2013 13:39, Angelo Graziosi wrote:

What is wrong with this command:

$ svn co svn://gcc.gnu.org/svn/gcc/branches/fortran-dev fortran-dev


What happens if you modify it a bit:

$ CYGWIN_SQLITE_LOCKING=posix svn co svn://...

That forces the SQLite library that Cygwin's svn is linked to to use 
POSIX compatible locking, instead of the Windows compatible locking it 
uses by default.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with SVN?

[Angelo Graziosi]

Warren Young wrote:

What happens if you modify it a bit:

$ CYGWIN_SQLITE_LOCKING=posix svn co svn://...


It works for almost an hour (I started to think it was a good fix for 
me...) but then it stopped in the same way... :-(


[...]
Afortran-dev/gcc/testsuite/gcc.c-torture/execute/pr42006.c
Afortran-dev/gcc/testsuite/gcc.c-torture/execute/pr20466-1.c
Afortran-dev/gcc/testsuite/gcc.c-torture/execute/980929-1.c
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file


Ciao,
 Angelo.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

What is wrong with SVN?

[Angelo Graziosi]

What is wrong with this command:

$ svn co svn://gcc.gnu.org/svn/gcc/branches/fortran-dev fortran-dev


On GNU/Linux (kubuntu 12.04 64 bit) it is completed successfully but on 
Cygwin (32 bit) it fails after a while in this way:


[...]
Afortran-dev/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb
Afortran-dev/gcc/testsuite/gnat.dg/renaming4.ads
Afortran-dev/gcc/testsuite/gnat.dg/loop_optimization14.ads
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file


Previous I have used many times SVN on Cygwin successfully..

Ciao,
 Angelo.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: What is wrong with SVN?

[David Stacey]

On 29/09/2013 20:39, Angelo Graziosi wrote:

What is wrong with this command:

$ svn co svn://gcc.gnu.org/svn/gcc/branches/fortran-dev fortran-dev


On GNU/Linux (kubuntu 12.04 64 bit) it is completed successfully but 
on Cygwin (32 bit) it fails after a while in this way:


[...]
A fortran-dev/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb
Afortran-dev/gcc/testsuite/gnat.dg/renaming4.ads
Afortran-dev/gcc/testsuite/gnat.dg/loop_optimization14.ads
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file


Works for me. Using your command (above), I checked out revision 203020 
successfully in 32-bit Cygwin running under Windows 7 Ultimate. Here are 
some ideas:


Firstly, check to see which versions of subversion, sqlite3 and cygwin 
you're using. Check the output of the following command, and if you're 
using older packages then try updating:


$ cygcheck -c cygwin sqlite3 subversion
Cygwin Package Information
Package  VersionStatus
cygwin   1.7.25-1   OK
sqlite3  3.7.17-3   OK
subversion   1.8.3-1OK

Secondly, make sure you're using the cygwin version of 'svn' (i.e. check 
that some other subversion client isn't in your path):


$ which svn
/usr/bin/svn

Thirdly, if the database file is locked then that could point to an old 
version of sqlite3 (namely 3.7.12.1) clashing with another subversion 
client (e.g. TortoiseSVN), or some anti-virus software locking a file in 
the '.svn' directory (e.g. 'wc.db'). See if you can check out into an 
area of the drive that isn't being virus scanned.


Fourth, the branch you're trying to check out is quite large. Are you 
running out of drive space?


Finally, if all of the above fail, follow the problem reporting 
guidelines carefully:

http://cygwin.com/problems.html

Cheers,

Dave.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

git-svn is broken

[nu774]

Currently, git-svn of Cygwin is unusable because of this:
http://git.661346.n2.nabble.com/Git-pm-with-recent-File-Temp-fail-td7580381.html

FYI, it was fixed on git 1.8.3:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.3.txt

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn 1.7.10-1 on x86_64 does not work

[Corinna Vinschen]

On Aug 28 11:16, David Rothenberger wrote:
 Corinna Vinschen wrote:
  On Aug 28 09:05, Robert Klemme wrote:
  On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger
  daver...@acm.org wrote:
  On 8/27/2013 9:04 AM, Robert Klemme wrote:
  $ svn --version /usr/bin/svn.exe: error while loading shared
  libraries: ?: cannot open shared object file: No such file or
  directory
  
  Check that you have libneon27 installed. That's missing from
  the dependencies. If that doesn't work, try cygcheck
  /usr/bin/svn, which might tell you what else is missing.
  
  $ fgrep -i libneon /etc/setup/installed.db $ cygcheck $(type -p
  svn) /dev/null cygcheck: track_down: could not find
  cygneon-27.dll
  
  Bingo!  I installed it and now it works.
  
  So libneon27 should be added to subversion's setup.hint requires?
 
 Sigh. I guess. It's only required by 1.7, not by the latest 1.8, so
 it's not caught by cygport automatically. (I know, I know, I should
 review the auto-generated requires.)

No worries.  I added libneon27 to both setup.hint files, 32 and 64 bit.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp4gjpcIVwA4.pgp
Description: PGP signature

Re: svn 1.7.10-1 on x86_64 does not work

[Robert Klemme]

On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger daver...@acm.org wrote:
 On 8/27/2013 9:04 AM, Robert Klemme wrote:
 $ svn --version
 /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
 shared object file: No such file or directory

 Check that you have libneon27 installed. That's missing from the
 dependencies. If that doesn't work, try cygcheck /usr/bin/svn, which
 might tell you what else is missing.

$ fgrep -i libneon /etc/setup/installed.db
$ cygcheck $(type -p svn) /dev/null
cygcheck: track_down: could not find cygneon-27.dll

Bingo!  I installed it and now it works.

 If all that fails, follow the instructions at
 http://cygwin.com/problems.html. The cygcheck output will help us figure
 out what else is missing.

There does not seem to be anything else missing.  Thank you, David!

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn 1.7.10-1 on x86_64 does not work

[Corinna Vinschen]

On Aug 28 09:05, Robert Klemme wrote:
 On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger daver...@acm.org wrote:
  On 8/27/2013 9:04 AM, Robert Klemme wrote:
  $ svn --version
  /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
  shared object file: No such file or directory
 
  Check that you have libneon27 installed. That's missing from the
  dependencies. If that doesn't work, try cygcheck /usr/bin/svn, which
  might tell you what else is missing.
 
 $ fgrep -i libneon /etc/setup/installed.db
 $ cygcheck $(type -p svn) /dev/null
 cygcheck: track_down: could not find cygneon-27.dll
 
 Bingo!  I installed it and now it works.

So libneon27 should be added to subversion's setup.hint requires?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpG2V7lpW9pb.pgp
Description: PGP signature

Re: svn 1.7.10-1 on x86_64 does not work

[David Rothenberger]

Corinna Vinschen wrote:
 On Aug 28 09:05, Robert Klemme wrote:
 On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger
 daver...@acm.org wrote:
 On 8/27/2013 9:04 AM, Robert Klemme wrote:
 $ svn --version /usr/bin/svn.exe: error while loading shared
 libraries: ?: cannot open shared object file: No such file or
 directory
 
 Check that you have libneon27 installed. That's missing from
 the dependencies. If that doesn't work, try cygcheck
 /usr/bin/svn, which might tell you what else is missing.
 
 $ fgrep -i libneon /etc/setup/installed.db $ cygcheck $(type -p
 svn) /dev/null cygcheck: track_down: could not find
 cygneon-27.dll
 
 Bingo!  I installed it and now it works.
 
 So libneon27 should be added to subversion's setup.hint requires?

Sigh. I guess. It's only required by 1.7, not by the latest 1.8, so
it's not caught by cygport automatically. (I know, I know, I should
review the auto-generated requires.)

-- 
David Rothenberger    daver...@acm.org

This restaurant was advertising breakfast any time. So I ordered
french toast in the renaissance.
-- Steven Wright, comedian

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

svn 1.7.10-1 on x86_64 does not work

[Robert Klemme]

Hi folks,

even obtaining the version fails with this:

$ svn --version
/usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory

I have a pretty fresh installation (only selected the older version of
svn) and am not aware of anything I missed during installation (such
as preventing installation of automatically selected dependencies).

Version:
$ uname -a
CYGWIN_NT-6.1  1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin

Unfortunately I don't have strace (see earler email) so at the moment
I cannot easily check which file is missing.

Is this a known issue? Is there some configuration change I can apply
to get it working?

Kind regards

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: svn 1.7.10-1 on x86_64 does not work

[David Rothenberger]

On 8/27/2013 9:04 AM, Robert Klemme wrote:
 $ svn --version
 /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
 shared object file: No such file or directory

Check that you have libneon27 installed. That's missing from the
dependencies. If that doesn't work, try cygcheck /usr/bin/svn, which
might tell you what else is missing.

If all that fails, follow the instructions at
http://cygwin.com/problems.html. The cygcheck output will help us figure
out what else is missing.

-- 
David Rothenberger    daver...@acm.org

Gold's Law:
If the shoe fits, it's ugly.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

ETA for 64-bit SVN?

[Ryan Johnson]

Hi SVN maintainer,

Is a 64-bit release going to come out soon? SVN is quite a pain to build 
manually, compared with most other packages, especially if support for 
SSL, etc. is configured...


Thanks!
Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ETA for 64-bit SVN?

[Corinna Vinschen]

On Aug 21 12:04, Ryan Johnson wrote:
 Hi SVN maintainer,
 
 Is a 64-bit release going to come out soon? SVN is quite a pain to
 build manually, compared with most other packages, especially if
 support for SSL, etc. is configured...

Subversion is part of the 64 bit distro already before the distro has
gone release...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgppEvRDcLffZ.pgp
Description: PGP signature

Re: ETA for 64-bit SVN?

[Ryan Johnson]

On 21/08/2013 12:11 PM, Corinna Vinschen wrote:

On Aug 21 12:04, Ryan Johnson wrote:

Hi SVN maintainer,

Is a 64-bit release going to come out soon? SVN is quite a pain to
build manually, compared with most other packages, especially if
support for SSL, etc. is configured...

Subversion is part of the 64 bit distro already before the distro has
gone release...

Right then... thanks for fixing that little PEBKAC...

(slinks away sheepishly after realizing that he'd searched for SVN 
instead of Subversion all this time)


Ryan

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git-svn died of signal 6

[Christian Franke]

Christian Franke wrote:

Christian Franke wrote:

Christian Franke wrote:

Pawel Jasinski wrote:

hi,

after recent update I noticed a problem with 'git svn'

first, it was complaining about 'address already taken'
After restart and rebaseall I am getting:

$ git svn rebase
Current branch master is up to date.
error: git-svn died of signal 6


I can confirm this:

$ git svn fetch
error: git-svn died of signal 6

This results in a perl.exe.stackdump file in cwd.



Workaround: use cygwin to 1.7.18 (instead of 1.7.20)

This also worked for me.



With 1.7.18 the error message is not printed but an empty 
perl.exe.stackdump file is created.




Problem does no longer occur with Cygwin 1.7.21.


... but reappears in 1.7.22 and .23.

Christian


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git-svn died of signal 6

[Christian Franke]

Christian Franke wrote:

Christian Franke wrote:

Pawel Jasinski wrote:

hi,

after recent update I noticed a problem with 'git svn'

first, it was complaining about 'address already taken'
After restart and rebaseall I am getting:

$ git svn rebase
Current branch master is up to date.
error: git-svn died of signal 6


I can confirm this:

$ git svn fetch
error: git-svn died of signal 6

This results in a perl.exe.stackdump file in cwd.



Workaround: use cygwin to 1.7.18 (instead of 1.7.20)

This also worked for me.



With 1.7.18 the error message is not printed but an empty 
perl.exe.stackdump file is created.




Problem does no longer occur with Cygwin 1.7.21.

Christian


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.21: Problem using svn accessing UNC network pathes

[Corinna Vinschen]

On Jul 18 11:38, Roland Schwingel wrote:
 Hi...
 
 Today I updated my cygwin to version 1.7.21. Due to a bunch of
 lockup problems I was previously sticking to 1.7.17. A short test
 shows that the lockups appears to be solved (that are the good news
 - thanks to all involved) - but I got a new problem now. Performing
 a svn st on a subversion working copy residing on a UNC share is
 broken now.
 
 I do get this error message:
 svn: E078: Can't read directory '//server/share/path': Partial
 results are valid but processing is incomplete.
 
 When I exchange cygwin1.dll with the one from 1.7.20 the svn st
 command works as expected.
 
 So I did an strace with both cygwin1.dll versions (I attached the
 outputs of both runs to this email in a tarball).
 
 svn_st_1720.txt contains the working trace when doing svn st on 1.7.20
 svn_st_1721.txt contains the output of my broken run on 1.7.21
 
 The output is pretty much in sync up to line 824. It starts to differ
 heavily in 825. In line 825 of svn_st_1721.txt it appears that maybe
 in normalize_posix_path() a / too much is cut off from the beginning
 of the unc path and it might mess up local and network pathes.
 
 BTW: I still have to run a self compiled version subversion 1.7.2 as
 you can see from the strace logs. I recompiled it today freshly on
 1.7.21 but this does not make any change.
 
 Thanks for your help,

Bug in the new code recognizing invalid path preceeding a .. path
component.  It ignores one leading slash in case of UNC paths and so
accidentally checks for /server/share/path rather than //server/share/path.

I fixed that in CVS and I just generated new x86 and x86_64 snapshots.
Please take your pick at http://cygwin.com/snapshots/ and report back if
you still see problems with it.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: SVN::Ra problems

[Mikko Rapeli]

  cygcheck output from the working setup is:
  Found: C:\cygwin\bin\perl.exe
  Found: C:\Testwell\CTC\perl
  Warning: C:\cygwin\bin\perl.exe hides C:\Testwell\CTC\perl

  I wonder if this is the reason? Perhaps Cygwin was picking up the wrong
  perl?
 
 Without any perhaps.

Yes! This was the problem. Damn these multiple copies.

Now I know to read cygcheck output in detail. Thanks!

-Mikko

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: SVN::Ra problems

[Mikko Rapeli]

 SVN/_Ra/_Ra.dll is part of the subversion-perl package, as is
 SVN/Base.pm. You have one but not the other. Do you have

There is a _Ra.dll and a Base.pm, files are there.

 /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/auto/SVN/_Ra/_Ra.dll.new?
 If so, you have to reboot your computer.

Reboots done too many times. Cygwin reinstalled too. Forgot to mention
that subversion is downgraded to 1.7.10 since HTTPS authentication is broken
with 1.8. Few days ago on an older cygwin installation everything was working
just fine (until an 'rm -rf C:' happened with git, another story).

cygcheck reports this:

Cygwin Configuration Diagnostics
Current System Time: Mon Jul 15 09:21:58 2013

Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1

Running under WOW64 on AMD64

Path:   C:\Apps\ARM\bin\win_32-pentium
C:\Testwell\CTC
c:\Oracle\Client64\bin\
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
c:\Program Files (x86)\Microsoft Application Virtualization Client
C:\Apps\cygwin\bin
C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium\bin
C:\Apps\ARM\Utilities\FLEXlm\10.8.5.0\1\win_32-pentium
C:\Apps\ARM\RVCT\Programs\4.1\561\win_32-pentium
C:\Apps\ARM\RVI\Tools\4.1\32\programs\win_32-pentium
C:\Program Files\TortoiseSVN\bin
C:\Program Files (x86)\Subversion\bin
C:\Apps\apache-ant\bin
C:\Apps\Python27

Output from C:\Apps\cygwin\bin\id.exe
UID: 805092(user) GID: 10513(Domain Users)
10513(Domain Users)  0(root)  544(Administrators)
545(Users)

SysDir: C:\Windows\system32
WinDir: C:\Windows

PWD = '/'
HOME = '/home/user'

HOMEPATH = '\'
APPDATA = 'C:\Users\user\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
ARMCC41LIB = 'C:\Apps\ARM\RVCT\Data\4.1\561\lib'
ARM_ENABLED_PRODUCTS = 
'C:\Apps\ARM|RVDS/Contents/4.1/158:platform=win_32-pentium,extras_dir=professional\,encryption=none,regime=rel,capability=professional'
ARMCC41BIN = 'C:\Apps\ARM\RVCT\Programs\4.1\561\win_32-pentium'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 26 Stepping 5, GenuineIntel'
WINDIR = 'C:\Windows'
PUBLIC = 'C:\Users\Public'
ISSM_ARM_CORTEXDLL = 'C:\Apps\ARM\ISSModel\Cortex\4.0\18\win_32-pentium'
USERDOMAIN = 'MUC'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
UATDATA = 'C:\Windows\SysWOW64\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
windows_tracing_flags = '3'
ARMCONF = 
'C:\Apps\ARM\RDI\armperip\1.3\50;C:\Apps\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium;C:\Apps\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Apps\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium'
windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log'
VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\'
TEMP = '/cygdrive/c/Users/user/AppData/Local/Temp'
OSVersion = 'Windows 7 Enterprise (x64)'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
RVDEBUG_SDK = 'C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium\sdk'
MasterImageVer = 'x64-5.12'
USERNAME = 'user'
ARMLMD_LICENSE_FILE = 'foo.bar'
PROCESSOR_LEVEL = '6'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
RVD_FLASH_BASE = 'C:\Apps\ARM\RVD\Flash\4.0\18\all\flash'
PROCESSOR_ARCHITEW6432 = 'AMD64'
HLPPATH = 'C:\Apps\ARM\Documentation\RVD\4.1\11\onlinehelp'
USERPROFILE = 'C:\Users\user'
ARMCC41INC = 'C:\Apps\ARM\RVCT\Data\4.1\561\include\windows'
LOGONSERVER = '\\HEU0MUC07'
CTCHOME = 'C:\Testwell\CTC'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\user\AppData\Local'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
USERDNSDOMAIN = 'COMPANY.CORP'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
ARMDLL = 
'C:\Apps\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium;C:\Apps\ARM\RDI\rdimsvr\1.3.1\129\win_32-pentium;C:\Apps\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Apps\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium'
HOMEDRIVE = 'U:'
PROMPT = '$P$G'
COMSPEC = 'C:\Windows\system32\cmd.exe'
TMP = '/cygdrive/c/Users/user/AppData/Local/Temp'
SYSTEMROOT = 'C:\Windows'
PROCESSOR_REVISION = '1a05'
VS100COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 
10.0\Common7\Tools\'
ARM_PROFILER_RTSM_PATH = 
'C:\Apps\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release'
RVDEBUG_INSTALL = 'C:\Apps\ARM\RVD\Core\4.1.1\25\win_32-pentium'
RVDEBUG_HLPPATH = 'C:\Apps\ARM\Documentation\RVD\4.1\11\onlinehelp'
PROGRAMFILES = 'C:\Program Files (x86)'
HOMESHARE = '\\foo.bar\user'
ARMROOT = 'C:\Apps\ARM'
NUMBER_OF_PROCESSORS = '4'
ARM_RTSM_PATH = 'C:\Apps\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release'
FM_TRACE_PLUGINS = 
'C:\Apps\ARM\RVDS\ProfilerPlugIn\2.1\3\plugins\Win32_VC2005

Re: SVN::Ra problems

[Mikko Rapeli]

With latest cygwin packages, including subversion 1.8,
perl -e 'require SVN::Ra' works, but svn 1.8 breaks HTTPS NTML
authentication which works with 1.7.10.

Downgrading to subversion 1.7.10 worked well a few weeks back but not
anymore. Would be nice to figure out what changed.

-Mikko

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: SVN::Ra problems

[Mikko Rapeli]

As a workaround, I copied a full cygwin directory from another machine
where subversion-perl is working with svn 1.7.10 packages, and this works.
cygcheck output from the working setup is:

Cygwin Configuration Diagnostics
Current System Time: Mon Jul 15 11:59:04 2013

Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Testwell\CTC
C:\Program Files\ARM\bin\win_32-pentium
C:\Program Files\PC Connectivity Solution
C:\Oracle\Client\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files\Microsoft Application Virtualization Client
C:\Program Files\TortoiseSVN\bin
C:\Program Files\cygwin\bin
C:\Program Files\ARM\RVCT\Programs\4.1\561\win_32-pentium
C:\Program Files\ARM\RVD\Core\4.1.1\25\win_32-pentium\bin
C:\Program Files\ARM\RVI\Tools\4.1\32\programs\win_32-pentium
C:\Program Files\ARM\Utilities\FLEXlm\10.8.5.0\1\win_32-pentium
C:\Program Files\Microsoft SQL Server\100\Tools\Binn
C:\Program Files\Microsoft SQL Server\100\DTS\Binn
C:\Program Files\CMake 2.8\bin
C:\Program Files\Dr. Memory\bin

Output from C:\cygwin\bin\id.exe
UID: 1793714(user)GID: 10513(Domain Users)
10513(Domain Users)  0(root)  544(Administrators)
545(Users)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'user'
PWD = '/cygdrive/c'
CYGWIN = 'nodosfilewarning'
HOME = '/home/user'

HOMEPATH = '\'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Users\user\AppData\Roaming'
ARMCC41LIB = 'C:\Program Files\ARM\RVCT\Data\4.1\561\lib'
HOSTNAME = 'COMPUTER'
ARM_ENABLED_PRODUCTS = 'C:\Program 
Files\ARM|RVDS/Contents/4.1/158:platform=win_32-pentium,encryption=none,extras_dir=professional\,regime=rel,capability=professional'
ARMCC41BIN = 'C:\Program Files\ARM\RVCT\Programs\4.1\561\win_32-pentium'
CTCWRAPDIR = 'C:\Users\user\AppData\Local\Temp\ctc'
SHELL = '/bin/bash'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 42 Stepping 7, GenuineIntel'
WINDIR = 'C:\Windows'
ArchivePath = 'c:\Program Files\archive'
PUBLIC = 'C:\Users\Public'
ISSM_ARM_CORTEXDLL = 'C:\Program 
Files\ARM\ISSModel\Cortex\4.0\18\win_32-pentium'
OLDPWD = '/cygdrive/c/cygwin'
ARMCC41_CCOPT = '--licretry'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
windows_tracing_flags = '3'
ARMCONF = 'C:\Program Files\ARM\RDI\armperip\1.3\50;C:\Program 
Files\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium;C:\Program 
Files\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Program
 Files\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium'
temp = 'C:\Users\user\AppData\Local\Temp'
VS90COMNTOOLS = 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\'
OSVersion = 'Windows 7 Enterprise (x86)'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
TMP = '/tmp'
RVDEBUG_SDK = 'C:\Program Files\ARM\RVD\Core\4.1.1\25\win_32-pentium\sdk'
USERNAME = 'user'
PROCESSOR_LEVEL = '6'
ARMCC41_ASMOPT = '--licretry'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
RVD_FLASH_BASE = 'C:\Program Files\ARM\RVD\Flash\4.0\18\all\flash'
HLPPATH = 'C:\Program Files\ARM\Documentation\RVD\4.1\11\onlinehelp'
LANG = 'en_US.UTF-8'
USERPROFILE = 'C:\Users\user'
TZ = 'Europe/Berlin'
ARMCC41INC = 'C:\Program Files\ARM\RVCT\Data\4.1\561\include\windows'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
PROCESSOR_ARCHITECTURE = 'x86'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
ARMDLL = 'C:\Program 
Files\ARM\RVARMulator\v6ARMulator\1.4.1\285\win_32-pentium;C:\Program 
Files\ARM\RDI\rdimsvr\1.3.1\129\win_32-pentium;C:\Program 
Files\ARM\RVARMulator\MPCore\ARMulator\1.4.1\20\rvds30\win_32-pentium;C:\Program
 Files\ARM\RVARMulator\ARMulator\1.4.1\313\win_32-pentium'
HOMEDRIVE = 'U:'
COMSPEC = 'C:\Windows\system32\cmd.exe'
SYSTEMROOT = 'C:\Windows'
ARMCC41_LINKOPT = '--licretry'
PRINTER = '\\foo.bar'
PROCESSOR_REVISION = '2a07'
VS100COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\'
ARM_PROFILER_RTSM_PATH = 'C:\Program 
Files\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
RVDEBUG_INSTALL = 'C:\Program Files\ARM\RVD\Core\4.1.1\25\win_32-pentium'
RVDEBUG_HLPPATH = 'C:\Program Files\ARM\Documentation\RVD\4.1\11\onlinehelp'
PROGRAMFILES = 'C:\Program Files'
ARMROOT = 'C:\Program Files\ARM'
NUMBER_OF_PROCESSORS = '4'
ARM_RTSM_PATH = 'C:\Program 
Files\ARM\RVDS\Models\5.2\16\lib\Win32_VC2005\Release'
FM_TRACE_PLUGINS = 'C:\Program 
Files\ARM\RVDS\ProfilerPlugIn\2.1\3\plugins\Win32_VC2005\FMProfilerPlugin.dll'
SESSIONNAME = 'Console'
ARM_RVI_TOOLS = 'C:\Program Files\ARM\RVI\Tools\4.1\32\programs\win_32-pentium'
_ = '/usr/bin/cygcheck.exe

Re: SVN::Ra problems

[Csaba Raduly]

Hi Mikko,

On Mon, Jul 15, 2013 at 1:20 PM, Mikko Rapeli  wrote:
 As a workaround, I copied a full cygwin directory from another machine
 where subversion-perl is working with svn 1.7.10 packages, and this works.
 cygcheck output from the working setup is:

 Cygwin Configuration Diagnostics
(snip)

Please don't put the output of cygcheck in the body of the email.
Attach it as a text file, as recommended by:

 Problem reports:   http://cygwin.com/problems.html


Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
Ok, it boots. Which means it must be bug-free and perfect.  -- Linus Torvalds
People disagree with me. I just ignore them. -- Linus Torvalds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: SVN::Ra problems

[David Rothenberger]

Mikko Rapeli wrote:
 As a workaround, I copied a full cygwin directory from another machine
 where subversion-perl is working with svn 1.7.10 packages, and this works.

I'm glad you got it working.

 With latest cygwin packages, including subversion 1.8,
 perl -e 'require SVN::Ra' works
 
 Downgrading to subversion 1.7.10 worked well a few weeks back but not
 anymore.

I tried downgrading to 1.7.10 this morning and perl -e 'require SVN::Ra'
worked fine for me.

[cygcheck from broken setup is]:
 Found: C:\Testwell\CTC\perl
 Found: C:\Apps\cygwin\bin\perl.exe
 Warning: C:\Testwell\CTC\perl hides C:\Apps\cygwin\bin\perl.exe

 cygcheck output from the working setup is:
 Found: C:\cygwin\bin\perl.exe
 Found: C:\Testwell\CTC\perl
 Warning: C:\cygwin\bin\perl.exe hides C:\Testwell\CTC\perl

I wonder if this is the reason? Perhaps Cygwin was picking up the wrong
perl?

Anyway, I don't see anything else to explain this. It works fine for me.
It appears your subversion-perl installation was complete on the broken
installation. I don't know why it wouldn't be able to find that DLL.

-- 
David Rothenberger    daver...@acm.org

QOTD:
If it's too loud, you're too old.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple