Re: subversion 1.9.3-1 segfault

2016-02-19 Thread Greg Chicares
On 2016-02-19 16:28, David Rothenberger wrote:
> Greg Chicares wrote:
[...]
>> /lmi/mirror/lmi[1]$svn update
>> Updating '.':
>> zsh: segmentation fault (core dumped)  svn update
[...non-helpful stackdump...]
>> I'll try running 'svn' under 'gdb'. Is there anything else I can do to help?
> 
> That's the only other thing I can think of. If you can catch the 
> segfault and get a backtrace, I may be able to track it down.

Thanks. The problem is no longer occurring. Let me state what I
know for the record in case it helps someone else someday.

This seems to be a heisenbug. When I ran it under gdb, repeatedly,
it refused to segfault. Outside gdb, with subversion-debuginfo
installed, I was unable to get a useful stackdump.

The problem has occurred only when gnu.org's svn server is slow:
on one isolated occasion a week or two ago, and throughout today.
And today there seems to have been a DDOS attack on gnu.org:
  https://savannah.gnu.org/support/?108973

While the problem lasted, sometimes I got one or both of these
messages:
  svn: E170013: Unable to connect to a repository
  svn: E175012: Connection timed out
and sometimes svn segfaulted with no message. I tried the same
operations on my debian-7 ("wheezy") system with its older
svn-1.6.17, where I got timeouts but no segfault.

My real problem was the gnu.org server. I can only conjecture
that attempting to work with a server under extreme load causes
svn-1.9.3-1 to follow some exceptional code path that attempts
to report a diagnostic and in doing so sometimes crashes.


--
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: trying to upload new wcd update (Erwin is new designated maintainer)

2016-02-19 Thread waterlan

Jon Turney schreef op 2016-02-19 20:38:

On 19/02/2016 19:18, waterlan wrote:
Thanks. Does this mean that the files I uploaded are accepted now? 
They

are gone. Or do I need to upload new files.


The 5.3.1-1 files you uploaded before have been moved into the
release, so you don't need to upload them again.

https://cygwin.com/packages/x86/wcd/
https://cygwin.com/packages/x86_64/wcd/


Yesterday version 5.3.2 was released. I uploaded new files. Tomorrow I 
will announce 5.3.2. I will skip the 5.3.1 announcement, because it 
would only be for one day.


regards,

--
Erwin


Re: trying to upload new wcd update (Erwin is new designated maintainer)

2016-02-19 Thread Jon Turney

On 19/02/2016 19:18, waterlan wrote:

Jon Turney schreef op 2016-02-19 16:57:

On 30/01/2016 08:54, Erwin Waterlander wrote:

Op 30-1-2016 om 9:25 schreef Jari Aalto:

On 2016-01-28 21:28, Corinna Vinschen wrote:
|
| Jari?  Ping?
|
| Erwin, if Jari doesn't reply until end of next week, wcd is your
packag

I'm ok with Erwin taking the maintainership.

Jari

OK. Thanks Jari.


I've updated the maintainer list to reflect this change, and marked
this upload for moving.


Hi,

Thanks. Does this mean that the files I uploaded are accepted now? They
are gone. Or do I need to upload new files.


The 5.3.1-1 files you uploaded before have been moved into the release, 
so you don't need to upload them again.


https://cygwin.com/packages/x86/wcd/
https://cygwin.com/packages/x86_64/wcd/



Re: trying to upload new wcd update (Erwin is new designated maintainer)

2016-02-19 Thread Achim Gratz
waterlan writes:
> Thanks. Does this mean that the files I uploaded are accepted now?

Yes, they are now up.

> They are gone. Or do I need to upload new files.

I guess Jon triggered the move manually, at least none of today's notice
emails had that package mentioned.


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: trying to upload new wcd update (Erwin is new designated maintainer)

2016-02-19 Thread waterlan

Jon Turney schreef op 2016-02-19 16:57:

On 30/01/2016 08:54, Erwin Waterlander wrote:

Op 30-1-2016 om 9:25 schreef Jari Aalto:

On 2016-01-28 21:28, Corinna Vinschen wrote:
|
| Jari?  Ping?
|
| Erwin, if Jari doesn't reply until end of next week, wcd is your 
packag


I'm ok with Erwin taking the maintainership.

Jari

OK. Thanks Jari.


I've updated the maintainer list to reflect this change, and marked
this upload for moving.


Hi,

Thanks. Does this mean that the files I uploaded are accepted now? They 
are gone. Or do I need to upload new files.


regards,

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/


Re: [ITP] cfitsio-3.380

2016-02-19 Thread Marco Atzeri

scrap it.

Yaakov already ported to cygwin.
I missed the announcement

On 19/02/2016 18:21, Marco Atzeri wrote:

CFITSIO is a library of C and Fortran subroutines for reading and
writing data files in FITS (Flexible Image Transport System) data
format. CFITSIO provides simple high-level routines for reading and
writing FITS files that insulate the programmer from the internal
complexities of the FITS format. CFITSIO also provides many advanced
features for manipulating and filtering the information in FITS files.



[ITP] cfitsio-3.380

2016-02-19 Thread Marco Atzeri
CFITSIO is a library of C and Fortran subroutines for reading and 
writing data files in FITS (Flexible Image Transport System) data 
format. CFITSIO provides simple high-level routines for reading and 
writing FITS files that insulate the programmer from the internal 
complexities of the FITS format. CFITSIO also provides many advanced 
features for manipulating and filtering the information in FITS files.


Version 3.350 is in Cygwin Ports

Version 3.380 has a API bump so libcfitsio4

Homepage
 http://heasarc.gsfc.nasa.gov/docs/software/fitsio/fitsio.html

Full Autoconf/Automake version taken from
 https://github.com/sfabbro/cfitsio


to download (remove the index.html's)
-
wget -r -np -nH --cut-dirs=0 \
http://matzeri.altervista.org/x86/cftisio/index.html
wget -r -np -nH --cut-dirs=0 \
http://matzeri.altervista.org/x86_64/cfitsio/index.html

find x86 x86_64 -name index.html -o -name md5.sum | xargs rm
--

File list

cfitsio-3.380-2-src.tar.xz
cfitsio-debuginfo/cfitsio-debuginfo-3.380-2.tar.xz
cfitsio-debuginfo/setup.hint
cfitsio-util/cfitsio-util-3.380-2.tar.xz
cfitsio-util/setup.hint
libcfitsio-devel/libcfitsio-devel-3.380-2.tar.xz
libcfitsio-devel/setup.hint
libcfitsio4/libcfitsio4-3.380-2.tar.xz
libcfitsio4/setup.hint
setup.hint

Regards
Marco



Re: Possible Security Hole in SSHD w/ CYGWIN?

2016-02-19 Thread Erik Soderquist
On Fri, Feb 19, 2016 at 6:10 AM, Corinna Vinschen wrote:

> Thanks for testing, I really appreciate that.


You're very welcome  :)

-- Erik

--
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: subversion 1.9.3-1 segfault

2016-02-19 Thread David Rothenberger

Greg Chicares wrote:

On 2016-02-13 18:41, David Rothenberger wrote:

On 2/9/2016 9:39 AM, Greg Chicares wrote:

'svn' segfaulted on a routine command:

/lmi/mirror/lmi[0]$svn status --show-updates

svn: E170013: Unable to connect to a repository at URL 
'http://svn.savannah.nongnu.org/svn/lmi/lmi/trunk'
svn: E000104: Error running context: Connection reset by peer
svn update
Updating '.':
zsh: segmentation fault (core dumped)

The command worked as expected when I reran it (after 'svn cleanup'):

[snip]


It's working now, and I can't reproduce the problem, but I thought
I should report it anyway. I've attached cygcheck -s -v -r output
and copied 'svn.exe.stackdump' below.

Exception: STATUS_ACCESS_VIOLATION at eip=
eax=200C61B8 ebx=200A8DE8 ecx=0022C39C edx= esi= edi=0011
ebp=200C01A0 esp=0022C35C program=C:\cygwin-lmi\bin\svn.exe, pid 1736, thread 
main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
200C01A0   (, , 6C1D5580, 200A0E90)
200A8DE8   (0002, 200A8DE8, 2009EDC0, 200AAEC8)
2009F5D8   (6C701180, 6C701160, , 2009F978)
2009EDC0  2009F628 (, 20052794, 200AAF00, )
20052790  200C81B8 (2004D788, 200430F4, , 20052C08)
200430F0  2009EDC0 (2003EF00, 20038D6C, 20054CB0, )
20038D68  20052790 (, , 20038E88, )


I wasn't able to get any useful information out of the stack trace.
Running addr2line does not show any functions. I'm not sure if this is
because you don't have the subversion-debuginfo package installed. I
would suggest you install this in case it makes a difference and the
failure happens again.


I've installed 'subversion-debuginfo' and rebooted. After working okay
for a few days, 'svn' is now segfaulting again. A coworker who did a
brand-new Cygwin installation on a new machine yesterday reports 'svn'
failing for her too, also with a stackdump.

Here's my failing command:

/lmi/mirror/lmi[1]$svn update

Updating '.':

zsh: segmentation fault (core dumped)  svn update


(The last line means that 'zsh' caught the segfault, not that zsh crashed.)

Today's stackdump looks much the same to me as last week's:

Exception: STATUS_ACCESS_VIOLATION at eip=
eax=200C6268 ebx=200A8E98 ecx=0022C39C edx= esi= edi=0011
ebp=200C0250 esp=0022C35C program=C:\cygwin-lmi\bin\svn.exe, pid 1164, thread 
main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
200C0250   (, , 6C1D5580, 200A0F40)
200A8E98   (0002, 200A8E98, 2009EE70, 200AAF78)
2009F688   (6C701180, 6C701160, , 2009FA28)
2009EE70  2009F6D8 (, 20052794, 200AAFB0, )
20052790  200C8268 (2004D788, 200430F4, , 20052C08)
200430F0  2009EE70 (2003EF00, 20038D6C, 20054CB0, )
20038D68  20052790 (, , 20038E88, )
End of stack trace

...and I don't see any useful information from 'addr2line':

$addr2line -e /usr/bin/svn 0x200c0250 0x2009ee70 0x2009f6d8

??:0

??:0

??:0


Attached is fresh 'cygcheck' output.

I'll try running 'svn' under 'gdb'. Is there anything else I can do to help?


That's the only other thing I can think of. If you can catch the 
segfault and get a backtrace, I may be able to track it down. Or if you 
can create a simple test case to reproduce the problem, I can use gdb. 
Honestly, though, it's been a long time since I've done C programming 
and used gdb in earnest, so it will be slow going for me to debug this.



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


--
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: Fwd: Limited clipboard buffer between X11 apps and Microsoft Windows

2016-02-19 Thread Jon Turney

On 19/11/2015 12:30, Jon Turney wrote:

On 17/11/2015 18:57, Kevin Connor Arpe wrote:

My issue: Copying text between X11 apps and Microsoft Windows has
limited clipboard buffer.  My office co-worker and I were able to
replicate the same issue on our machines.

To replicate:
1) Run Cygwin X Server locally.
2) Run gedit remotely (using company Linux hosts) and redirect display
to our local Cygwin X Server.
3) Copy some text in gedit, paste in Windows app, e.g. Notepad.

We are able to find a limit (approximately 1000+ lines of text).  To
be very clear:  We can copy small amounts to text, but not large
amounts of text.

My co-worker found this historical Cygwin mailing list item.  It looks
very similar:
http://cygwin.1069669.n5.nabble.com/emacs-x11-new-clipboard-size-limitation-td104696.html


When the copy/paste fails, I see the following in
/var/log/xwin/XWin.0.log:
[298268.591] winClipboardFlushXEvents - SelectionNotify -
X*TextPropertyToTextList returned: XConverterNotFound


Thanks for reporting this issue.

Unfortunately, I don't think this is a recurrence of the regression in
that old report.

Briefly, there is a different protocol [1] for transferring clipboard
contents too large to fit in a single X protocol message (approximately
262144 bytes), which is not currently implemented by the X11/Windows
clipboard synchronization code.

Your estimate of 1000 lines seems a little low, but in my testing this
is the limit I hit.

[1]
http://www.x.org/releases/X11R7.7/doc/xorg-docs/icccm/icccm.html#INCR_Properties


This should be fixed in X server 1.18.1-1 I uploaded today.

Note there is still a limit of approx. 16MB when copying in the opposite 
direction (from a Windows app to an X11 app), but that is harder to fix...


--
Jon TURNEY
Volunteer Cygwin/X X Server 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



[ANNOUNCEMENT] Updated: xorg-server-1.18.1-1

2016-02-19 Thread Jon Turney


The following packages have been updated in the Cygwin distribution:

*** xorg-server-*1.18.1-1

These packages contain XWin and the other X.Org X11 servers.

In addition to upstream fixes [1], the following cygwin-specific changes 
have been made since 1.18.0-2:


* Implement >256K X -> Windows clipboard pastes using INCR protocol
* Report >16MB Windows -> X clipboard pastes as not yet supported
* Always prefer UTF8_STRING to COMPOUND_TEXT clipboard encoding
* Fix build with latest Cygwin headers
* Raise RANDR limit on X display size from 4Kx4K to 32Kx32K

[1] https://lists.x.org/archives/xorg-announce/2016-February/002674.html

x86:

3d2d7b1eef206e752d527f2f0aace26016cf15ae9a0fc78e79640c8bdf4494d7e51bc1eaf0f5639916a9d17f72ecc057ba17c375e9ce03c9da0e0f446f0d5645 
*xorg-server-1.18.1-1-src.tar.xz
23f0e704e358e4a8b5b67325e91bd57b05c9967d6346c33c03becebb9e2e3478ed83d3876dcacc8f0d037a73cc1b88fe219a6ca3d3813ba5bd6e1aee7b33fae0 
*xorg-server-1.18.1-1.tar.xz
dade9b477511e26a4902d65f0518e0d4e5488c08a114b021a640fc95021a848f4000c6309fa45fe82a3881d1dd9bfb8e9d3cc934ffb9a6c75f6d934d4d01abc7 
*xorg-server-common-1.18.1-1.tar.xz
7c98ea2d33dd1569f35b4b83a26c1bf9726d4aaca0efb15b2e0b85665afca9a75fe5170d38abb9757fe5ef4125707d258d0472d9faf3024e10e9e32f2a33efba 
*xorg-server-debuginfo-1.18.1-1.tar.xz
0f2f3e567d836bc7fe71a1587073772987c924e4c1c555a1a69e739e964b19d969754f949822d621ffaf231a77678f888d5ddf5bf2854befcb17f3dd47f0c200 
*xorg-server-devel-1.18.1-1.tar.xz
5d5f4e7df343174a9582fa02ed4bbb249b6043fe08728212e1c961df624022f4a687ac73146311b45bba62c34a74e4332af4ab5f8d5f6acf3d6f5de85bf08034 
*xorg-server-dmx-1.18.1-1.tar.xz
a181e04ee0f7a96d90dac9fc1eb26e24ad8df665575f71fd62401f31d87de5a84b9628fcb8a00cb2fe9c6130d50533f26cc10d2d7a4596e8287ae815bb20 
*xorg-server-extra-1.18.1-1.tar.xz
09c06afac1687493b148a34873e1ef1e78a6c20b5c166a79da5b3d505cda8021359ea09b9980aab6120f1c10d9ca1b29503ce2c26e64be138584838ebc62ff95 
*xwinclip-1.18.1-1.tar.xz


x86_64:

0ff9c01f77662b7b0dc2bd01484b662effde077f0971114ea7e9b3382f9cd1f064e6c9c95ce8dace525d836a502b65e3b7b058b2c98db989c01fb2ff0f1cdc56 
*xorg-server-1.18.1-1-src.tar.xz
41ac362127a5531d3c62dafd08f423d94533e0b204f2bf72b219cdc9400de262e74c06b8b85732e2d2bf93999b5eba77a26207986dc8ae3647b6b3602db0a032 
*xorg-server-1.18.1-1.tar.xz
3dd6038b38c826ae370151521811f20ca9babe92c83d3b30271d8ddecbdf2915ac8b6f11c188bd22f1165f5560c23c16345bd9d87da7f458de26be1b29bfb7db 
*xorg-server-common-1.18.1-1.tar.xz
bc23930ce39ed2938b4a66fc31351b1808b774fa9f19488b8fcfbc797cdf2c8b0c0a7182c4c0e1cf43a2e4b489aaba726cf45da57b7e515f3979849ffcca311c 
*xorg-server-debuginfo-1.18.1-1.tar.xz
5045aa3151fe55b0f3f6e34de0faa92779f8f6c5b39184b28b1df19ad1ade895cf144a1d8e01a3490ebfd62d1b0fdaa612e8268b0f3bb2ae5a294f4d7ac31f82 
*xorg-server-devel-1.18.1-1.tar.xz
6a297d1fcadce2be4f0566692e1a4f73ab50287d736f6add181642fa7b6d5182bbc7a4b1548525af1d8cfd1ecae0c097c70561b04900dce9d76227cdaceb2c2a 
*xorg-server-dmx-1.18.1-1.tar.xz
c01145a4085d947699fc3e995c1a0c157218c64696684b2f69583a6bd2a9ba0a77bc89b3d84e41f81e8776ddc9abf4058c92792ae7f5cb449b0fd7bf7bc90202 
*xorg-server-extra-1.18.1-1.tar.xz
25d220b3f35b243e0c6b4d05f0f0d5048811a8bbfde64b5d520216026913a96591faf6e290afc198651b09452415677caa02fb76d3eb64b5ef1fb65f02ed4dc7 
*xwinclip-1.18.1-1.tar.xz


--
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



Updated: xorg-server-1.18.1-1

2016-02-19 Thread Jon Turney


The following packages have been updated in the Cygwin distribution:

*** xorg-server-*1.18.1-1

These packages contain XWin and the other X.Org X11 servers.

In addition to upstream fixes [1], the following cygwin-specific changes 
have been made since 1.18.0-2:


* Implement >256K X -> Windows clipboard pastes using INCR protocol
* Report >16MB Windows -> X clipboard pastes as not yet supported
* Always prefer UTF8_STRING to COMPOUND_TEXT clipboard encoding
* Fix build with latest Cygwin headers
* Raise RANDR limit on X display size from 4Kx4K to 32Kx32K

[1] https://lists.x.org/archives/xorg-announce/2016-February/002674.html

x86:

3d2d7b1eef206e752d527f2f0aace26016cf15ae9a0fc78e79640c8bdf4494d7e51bc1eaf0f5639916a9d17f72ecc057ba17c375e9ce03c9da0e0f446f0d5645 
*xorg-server-1.18.1-1-src.tar.xz
23f0e704e358e4a8b5b67325e91bd57b05c9967d6346c33c03becebb9e2e3478ed83d3876dcacc8f0d037a73cc1b88fe219a6ca3d3813ba5bd6e1aee7b33fae0 
*xorg-server-1.18.1-1.tar.xz
dade9b477511e26a4902d65f0518e0d4e5488c08a114b021a640fc95021a848f4000c6309fa45fe82a3881d1dd9bfb8e9d3cc934ffb9a6c75f6d934d4d01abc7 
*xorg-server-common-1.18.1-1.tar.xz
7c98ea2d33dd1569f35b4b83a26c1bf9726d4aaca0efb15b2e0b85665afca9a75fe5170d38abb9757fe5ef4125707d258d0472d9faf3024e10e9e32f2a33efba 
*xorg-server-debuginfo-1.18.1-1.tar.xz
0f2f3e567d836bc7fe71a1587073772987c924e4c1c555a1a69e739e964b19d969754f949822d621ffaf231a77678f888d5ddf5bf2854befcb17f3dd47f0c200 
*xorg-server-devel-1.18.1-1.tar.xz
5d5f4e7df343174a9582fa02ed4bbb249b6043fe08728212e1c961df624022f4a687ac73146311b45bba62c34a74e4332af4ab5f8d5f6acf3d6f5de85bf08034 
*xorg-server-dmx-1.18.1-1.tar.xz
a181e04ee0f7a96d90dac9fc1eb26e24ad8df665575f71fd62401f31d87de5a84b9628fcb8a00cb2fe9c6130d50533f26cc10d2d7a4596e8287ae815bb20 
*xorg-server-extra-1.18.1-1.tar.xz
09c06afac1687493b148a34873e1ef1e78a6c20b5c166a79da5b3d505cda8021359ea09b9980aab6120f1c10d9ca1b29503ce2c26e64be138584838ebc62ff95 
*xwinclip-1.18.1-1.tar.xz


x86_64:

0ff9c01f77662b7b0dc2bd01484b662effde077f0971114ea7e9b3382f9cd1f064e6c9c95ce8dace525d836a502b65e3b7b058b2c98db989c01fb2ff0f1cdc56 
*xorg-server-1.18.1-1-src.tar.xz
41ac362127a5531d3c62dafd08f423d94533e0b204f2bf72b219cdc9400de262e74c06b8b85732e2d2bf93999b5eba77a26207986dc8ae3647b6b3602db0a032 
*xorg-server-1.18.1-1.tar.xz
3dd6038b38c826ae370151521811f20ca9babe92c83d3b30271d8ddecbdf2915ac8b6f11c188bd22f1165f5560c23c16345bd9d87da7f458de26be1b29bfb7db 
*xorg-server-common-1.18.1-1.tar.xz
bc23930ce39ed2938b4a66fc31351b1808b774fa9f19488b8fcfbc797cdf2c8b0c0a7182c4c0e1cf43a2e4b489aaba726cf45da57b7e515f3979849ffcca311c 
*xorg-server-debuginfo-1.18.1-1.tar.xz
5045aa3151fe55b0f3f6e34de0faa92779f8f6c5b39184b28b1df19ad1ade895cf144a1d8e01a3490ebfd62d1b0fdaa612e8268b0f3bb2ae5a294f4d7ac31f82 
*xorg-server-devel-1.18.1-1.tar.xz
6a297d1fcadce2be4f0566692e1a4f73ab50287d736f6add181642fa7b6d5182bbc7a4b1548525af1d8cfd1ecae0c097c70561b04900dce9d76227cdaceb2c2a 
*xorg-server-dmx-1.18.1-1.tar.xz
c01145a4085d947699fc3e995c1a0c157218c64696684b2f69583a6bd2a9ba0a77bc89b3d84e41f81e8776ddc9abf4058c92792ae7f5cb449b0fd7bf7bc90202 
*xorg-server-extra-1.18.1-1.tar.xz
25d220b3f35b243e0c6b4d05f0f0d5048811a8bbfde64b5d520216026913a96591faf6e290afc198651b09452415677caa02fb76d3eb64b5ef1fb65f02ed4dc7 
*xwinclip-1.18.1-1.tar.xz




Re: subversion 1.9.3-1 segfault

2016-02-19 Thread Greg Chicares
On 2016-02-13 18:41, David Rothenberger wrote:
> On 2/9/2016 9:39 AM, Greg Chicares wrote:
>> 'svn' segfaulted on a routine command:
>> 
>> /lmi/mirror/lmi[0]$svn status --show-updates
>> 
>> svn: E170013: Unable to connect to a repository at URL 
>> 'http://svn.savannah.nongnu.org/svn/lmi/lmi/trunk'
>> svn: E000104: Error running context: Connection reset by peer
>> svn update
>> Updating '.':
>> zsh: segmentation fault (core dumped)
>> 
>> The command worked as expected when I reran it (after 'svn cleanup'):
> [snip]
>> 
>> It's working now, and I can't reproduce the problem, but I thought
>> I should report it anyway. I've attached cygcheck -s -v -r output
>> and copied 'svn.exe.stackdump' below.
>> 
>> Exception: STATUS_ACCESS_VIOLATION at eip=
>> eax=200C61B8 ebx=200A8DE8 ecx=0022C39C edx= esi= edi=0011
>> ebp=200C01A0 esp=0022C35C program=C:\cygwin-lmi\bin\svn.exe, pid 1736, 
>> thread main
>> cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
>> Stack trace:
>> Frame Function  Args
>> 200C01A0   (, , 6C1D5580, 200A0E90)
>> 200A8DE8   (0002, 200A8DE8, 2009EDC0, 200AAEC8)
>> 2009F5D8   (6C701180, 6C701160, , 2009F978)
>> 2009EDC0  2009F628 (, 20052794, 200AAF00, )
>> 20052790  200C81B8 (2004D788, 200430F4, , 20052C08)
>> 200430F0  2009EDC0 (2003EF00, 20038D6C, 20054CB0, )
>> 20038D68  20052790 (, , 20038E88, )
> 
> I wasn't able to get any useful information out of the stack trace.
> Running addr2line does not show any functions. I'm not sure if this is
> because you don't have the subversion-debuginfo package installed. I
> would suggest you install this in case it makes a difference and the
> failure happens again.

I've installed 'subversion-debuginfo' and rebooted. After working okay
for a few days, 'svn' is now segfaulting again. A coworker who did a
brand-new Cygwin installation on a new machine yesterday reports 'svn'
failing for her too, also with a stackdump.

Here's my failing command:

/lmi/mirror/lmi[1]$svn update

Updating '.':

zsh: segmentation fault (core dumped)  svn update


(The last line means that 'zsh' caught the segfault, not that zsh crashed.)

Today's stackdump looks much the same to me as last week's:

Exception: STATUS_ACCESS_VIOLATION at eip=
eax=200C6268 ebx=200A8E98 ecx=0022C39C edx= esi= edi=0011
ebp=200C0250 esp=0022C35C program=C:\cygwin-lmi\bin\svn.exe, pid 1164, thread 
main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
200C0250   (, , 6C1D5580, 200A0F40)
200A8E98   (0002, 200A8E98, 2009EE70, 200AAF78)
2009F688   (6C701180, 6C701160, , 2009FA28)
2009EE70  2009F6D8 (, 20052794, 200AAFB0, )
20052790  200C8268 (2004D788, 200430F4, , 20052C08)
200430F0  2009EE70 (2003EF00, 20038D6C, 20054CB0, )
20038D68  20052790 (, , 20038E88, )
End of stack trace

...and I don't see any useful information from 'addr2line':

$addr2line -e /usr/bin/svn 0x200c0250 0x2009ee70 0x2009f6d8

??:0

??:0

??:0


Attached is fresh 'cygcheck' output.

I'll try running 'svn' under 'gdb'. Is there anything else I can do to help?


Cygwin Configuration Diagnostics
Current System Time: Fri Feb 19 15:07:13 2016

Windows XP Professional Ver 5.1 Build 2600 Service Pack 3

Path:   C:\opt\lmi\local\bin
C:\opt\lmi\local\lib
C:\cygwin-lmi\usr\local\bin
C:\cygwin-lmi\bin
C:\cygwin-lmi\bin
C:\cygwin-lmi\usr\sbin
C:\cygwin-lmi\sbin
C:\cygwin-lmi\usr\local\bin
C:\cygwin-lmi\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Support Tools
C:\BC5\BIN

Output from C:\cygwin-lmi\bin\id.exe
UID: 197611(earl)   GID: 197121(None)
197121(None)544(Administrators) 545(Users)
4(INTERACTIVE)  11(Authenticated Users) 4095(CurrentSession)
66048(LOCAL)

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

HOME = '/home/earl'
PWD = '/home/earl'
USER = 'earl'

ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
APPDATA = 'C:\Documents and Settings\earl\Application Data'
CLIENTNAME = 'Console'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
COMPUTERNAME = 'ILUVATAR'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
FP_NO_HOST_CHECK = 'NO'
HOMEDRIVE = 'C:'
HOMEPATH = '\Documents and Settings\earl'
LOGONSERVER = '\\ILUVATAR'
NUMBER_OF_PROCESSORS = '8'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 42 Stepping 1, GenuineIntel'
PROCESSOR_LEVEL = '6'
PROCESSOR_REVISION = '2a01'
PROGRAMFILES = 'C:\Program Files'
SESSIONNAME = 'Console'
SYSTEMDRIVE = 'C:'
SYSTEMROOT = 'C:\WINDOWS'
USERDOMAIN = 'ILUVATAR'
USERNAME = 'earl'
USERPROFILE = 'C:\Documents and Settings\earl'
WINDIR 

Re: trying to upload new wcd update (Erwin is new designated maintainer)

2016-02-19 Thread Jon Turney

On 30/01/2016 08:54, Erwin Waterlander wrote:

Op 30-1-2016 om 9:25 schreef Jari Aalto:

On 2016-01-28 21:28, Corinna Vinschen wrote:
|
| Jari?  Ping?
|
| Erwin, if Jari doesn't reply until end of next week, wcd is your packag

I'm ok with Erwin taking the maintainership.

Jari

OK. Thanks Jari.


I've updated the maintainer list to reflect this change, and marked this 
upload for moving.


Jari,

Thanks for maintaining this package so far.

Erwin,

Thanks for taking over as maintainer.



Re: crypt mismatch

2016-02-19 Thread Corinna Vinschen
On Feb 19 00:38, Marco Atzeri wrote:
> on x86:
> 
> $ cygcheck -f /usr/bin/cygcrypt-0.dll
> crypt-1.2-1
> 
> $ cygcheck -l crypt
> /usr/bin/cygcrypt-0.dll
> /usr/bin/crypt.exe
> /usr/lib/libcrypt.a
> /usr/lib/libcrypt.dll.a
> /usr/include/crypt.h
> /usr/share/doc/Cygwin/crypt.README
> 
> 
> on x64
> 
> crypt   1.1-1
> libcrypt-devel  1.1-1
> libcrypt0   1.1-1

That's ok.  Crypt 1.2-1 for 32 bit is older than crypt 1.1-1 for 64 bit.
I could create a new 1.3-1 for both but... meh.


Corinna

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


signature.asc
Description: PGP signature


Re: Duplicity

2016-02-19 Thread Corinna Vinschen
Hi John,


Sidenote: This is the wrong mailing list.  cygwin-apps is for Cygwin
package maintainers only.  The user list is cygwin AT cygwin DOT com.
But, never mind for now.


On Feb 19 03:13, J2897 wrote:
> I've pretty much fixed my particular problem. I installed Cygwin years ago
> from another Windows account which I switched from to get rid of Current
> User registry problems. So I used Window's  takeown
>    command to recursively change the owner
> from my old account to my new account. I guess I should have just changed
> the owner to the Administrators group incase I ever need to switch again. I
> also reset the permissions of the source folders before backup as I think
> that's what may have caused the 'hist/install.txt' permission error. The
> "Cleanup of temporary directory problem" persists, although that may just be
> due to permission inheritance.

It would be nice to get a better description.  The code is obviously
rather new so there might be a bug lurking in the wings.  Please keep
in mind that Cygwin tries to emulate POSIX ACLs and permissions, unless
you mount a directory with the "noacl" mount flag.  So the permissions
created are reflecting POSIX defaults in the firsat place, not Windows
defaults.

As for the permission problem, is it related to execute permissions?
If so, this might be by design, but I can't be too sure without
seeing the getfacl and icacls output of the *unchanged* permissions
generated by Cygwin.  So, ideally, can you provide getfacl and icacls
output for the temporary directory as well as a file in there created by
Duplicity?  I take it Duplicity *is* a Cygwin tool?

One thing you should avoid is to call icacls or using the Windows GUI to
change the permissions created by Cygwin.  The native Windows tools
might reorder the ACL which is bad in terms of emulating POSIX
permissions.  Please try to fix your problem with Cygwin's chmod or
setfacl instead and if Cygwin screwed up, it would be nice to learn
how so to fix that for the future... as long as it's clear that we're
emulating POSIX perms.


Thanks,
Corinna

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


signature.asc
Description: PGP signature


[ANNOUNCEMENT] Updated: tesseract-ocr-3.04.00-4

2016-02-19 Thread Marco Atzeri

Version 3.04.00-4  of packages

   libtesseract-ocr_3
   tesseract-ocr
   tesseract-ocr-devel
   tesseract-training-util

are available in the Cygwin distribution:

Other language specific data are available upstream
  https://github.com/tesseract-ocr/tessdata

while training data for building new language data are in
  https://github.com/tesseract-ocr/langdata

CYGWIN CHANGES
Rebuilt with libleptonica_5-1.73-1

CHANGES
None. Last upstream release.
https://github.com/tesseract-ocr/tesseract/wiki


DESCRIPTION
Tesseract is probably the most accurate open source OCR engine
available. Combined with the Leptonica Image Processing Library
it can read a wide variety of image formats and convert them to
text in over 60 languages. It was one of the top 3 engines in
the 1995 UNLV Accuracy test.
Improved extensively by Google.
It is released under the Apache License 2.0.


HOMEPAGE
https://github.com/tesseract-ocr/


Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) 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



[ANNOUNCEMENT] Updated: glpk-4.58-1

2016-02-19 Thread Marco Atzeri

Version 4.58-1 of
   glpk
   libglpk39  (API bump)
   libglpk-devel
have been uploaded for cygwin.

The GLPK (GNU Linear Programming Kit) package is
intended for solving large-scale linear
programming (LP), mixed integer programming (MIP),
 and other related problems. It is a set of
routines written in ANSI C and organized in
the form of a callable library.

CHANGES
This is a new upstream relase:

http://lists.gnu.org/archive/html/info-gnu/2016-02/msg8.html


Regards

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) 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



[ANNOUNCEMENT] Updated: leptonica-1.73-1

2016-02-19 Thread Marco Atzeri

Version 1.73-1  of packages

   leptonica
   libleptonica-devel
   libleptonica_5(API Bump)

are available in the Cygwin distribution:

CYGWIN CHANGES
Modified tmp default dir settings that
impacted tesseract training script.

CHANGES
http://www.leptonica.org/source/version-notes.html


DESCRIPTION
Leptonica is a pedagogically-oriented open source site containing
software that is broadly useful for image processing and image analysis
 applications.

Featured operations are

Rasterop (a.k.a. bitblt)
Affine transformations (scaling, translation, rotation, shear) on
images of arbitrary pixel depth
Binary and grayscale morphology, rank order, and convolution
Seedfill and connected components
Image transformations combining changes in scale and pixel depth
Pixelwise masking, blending, enhancement, arithmetic ops, etc.

Before it was included as component of tesseract-ocr.

HOMEPAGE
http://www.leptonica.org

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) 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



Updated: tesseract-ocr-3.04.00-4

2016-02-19 Thread Marco Atzeri

Version 3.04.00-4  of packages

   libtesseract-ocr_3
   tesseract-ocr
   tesseract-ocr-devel
   tesseract-training-util

are available in the Cygwin distribution:

Other language specific data are available upstream
  https://github.com/tesseract-ocr/tessdata

while training data for building new language data are in
  https://github.com/tesseract-ocr/langdata

CYGWIN CHANGES
Rebuilt with libleptonica_5-1.73-1

CHANGES
None. Last upstream release.
https://github.com/tesseract-ocr/tesseract/wiki


DESCRIPTION
Tesseract is probably the most accurate open source OCR engine
available. Combined with the Leptonica Image Processing Library
it can read a wide variety of image formats and convert them to
text in over 60 languages. It was one of the top 3 engines in
the 1995 UNLV Accuracy test.
Improved extensively by Google.
It is released under the Apache License 2.0.


HOMEPAGE
https://github.com/tesseract-ocr/


Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .


Updated: leptonica-1.73-1

2016-02-19 Thread Marco Atzeri

Version 1.73-1  of packages

   leptonica
   libleptonica-devel
   libleptonica_5(API Bump)

are available in the Cygwin distribution:

CYGWIN CHANGES
Modified tmp default dir settings that
impacted tesseract training script.

CHANGES
http://www.leptonica.org/source/version-notes.html


DESCRIPTION
Leptonica is a pedagogically-oriented open source site containing
software that is broadly useful for image processing and image analysis
 applications.

Featured operations are

Rasterop (a.k.a. bitblt)
Affine transformations (scaling, translation, rotation, shear) on
images of arbitrary pixel depth
Binary and grayscale morphology, rank order, and convolution
Seedfill and connected components
Image transformations combining changes in scale and pixel depth
Pixelwise masking, blending, enhancement, arithmetic ops, etc.

Before it was included as component of tesseract-ocr.

HOMEPAGE
http://www.leptonica.org

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .


Updated: glpk-4.58-1

2016-02-19 Thread Marco Atzeri

Version 4.58-1 of
   glpk
   libglpk39  (API bump)
   libglpk-devel
have been uploaded for cygwin.

The GLPK (GNU Linear Programming Kit) package is
intended for solving large-scale linear
programming (LP), mixed integer programming (MIP),
 and other related problems. It is a set of
routines written in ANSI C and organized in
the form of a callable library.

CHANGES
This is a new upstream relase:

http://lists.gnu.org/archive/html/info-gnu/2016-02/msg8.html


Regards

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .


Re: Possible Security Hole in SSHD w/ CYGWIN?

2016-02-19 Thread Corinna Vinschen
On Feb 18 12:10, Erik Soderquist wrote:
> On Thu, Feb 18, 2016 at 10:12 AM, Corinna Vinschen wrote:
> >
> > I implemented and tested the idea and it seems to work.  Note that the
> > underlying problem that we can't generate our own login session when using
> > method 1 persists.  However, the new code should avoid spilling cyg_server
> > credentials into the user session.
> >
> > Please give the new Cygwin test release 2.5.0-0.4
> > (https://cygwin.com/ml/cygwin-announce/2016-02/msg00023.html) a try.
> 
> I've installed the test release and am no longer able to reproduce the
> issue; I get the expected "access denied" on all network shares as I
> should on this test account.  (pub key auth, no password stored with
> "passwd -R")
> 
> :)

Thanks for testing, I really appreciate that.


Corinna

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


signature.asc
Description: PGP signature


Re: [PATCH] Multiple timer issues + new [PATCH]

2016-02-19 Thread Corinna Vinschen
On Feb 19 00:39, Irányossy Knoblauch Artúr wrote:
> Hi,
> 
> On Thu, Feb 18, 2016 at 12:28 PM, Corinna Vinschen
>  wrote:
> 
> > Would you mind terribly to send a copyright assignment per
> > https://cygwin.com/contrib.html?  If you send it as PDF by mail it takes
> > usually just a few days to be countersigned.
> 
> OK, I will try my best. :-)

It's really simple, trust me :)

> I could not find any information regarding what the names 'gtod' and
> 'ntod' are supposed to mean, and their type names, hires_ms and
> hires_ns, respectively, aren't conveying that 'ntod' is monotonic
> while 'gtod' isn't.

Yeah, right.  Keep in mind that the original times.cc is from pre-2000
and hires.h is from 2002.  Way back when, source comments were
unnecessary because, as we all well know, source is self-documenting...

These days, I think what we should do here is

a) ignore the names and maybe even bulk-rename variables and types
   to something more speaking (rel_timer, abs_timer or whatever)

b) add comments, comments, comments.

> Also, as I have been writing this mail, I have noticed that there is
> still a data race left in the prime() function, so I have made a patch
> for that, too.

Cool, thank you!


Corinna

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


signature.asc
Description: PGP signature


Re: [PATCH] cygwin: Export clog10, clog10f

2016-02-19 Thread Corinna Vinschen
On Feb 18 10:53, Yaakov Selkowitz wrote:
>   winsup/cygwin/
>   * common.din: Add clog10, clog10f.
>   * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump.
> 
>   winsup/doc/
>   * posix.xml (std-gnu): Add clog10, clog10f.

Patch is ok if the newlib patch is ok.


Thanks,
Corinna

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


signature.asc
Description: PGP signature


Re: gprof profiling of multi-threaded Cygwin programs

2016-02-19 Thread Corinna Vinschen
On Feb 18 16:57, Mark Geisert wrote:
> On Thu, 18 Feb 2016, Corinna Vinschen wrote:
> >On Feb 17 22:35, Mark Geisert wrote:
> >>I do see that a case could be made for general profiling documentation in
> >>winsup/doc/programming.xml but that's more than I want to take on at the
> >>moment.
> >
> >It doesn't have to be part of the source patch.  It would just be nice
> >if you could write a few words about profiling.  I'm *not* asking for
> >a complete gprof doc or somehting like that, it's safe to assume that
> >the users of the tool know how to read man or info pages.  Therefore,
> >something short like gcc.xml or gdb.xml would be totally sufficient.
> >Even shorter than those.  Just a few words about profiling in general,
> >and an example would be cool.
> 
> Ah, OK.  That I can/will do after completing the source patch.

Thank you!


Corinna

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


signature.asc
Description: PGP signature


Re: Cygwin select() issues and improvements

2016-02-19 Thread Corinna Vinschen
On Feb 18 20:20, john hood wrote:
> On 2/15/16 7:57 AM, Corinna Vinschen wrote:
> > On Feb 14 03:09, john hood wrote:
> >> Various issues with Cygwin's select() annoyed me, and I've spent some
> >> time gnawing on them.
> > One of them is that they are not trivial enough to be acceptable without
> > copyright assignment (except patch 3, but see below).  Please have a
> > look at https://cygwin.com/contrib.html, the "Before you get started"
> > section.  There's a link to an "assign.txt" file with instructions.
> > 
> > The other one is just this:  Can you please describe each change in the
> > accompanying patch comment so that it's accessible from the git log?
> 
> Sorry for the slow response here.  I have a bad cold and I'm not getting
> to things quickly.

I know what you mean.  I'm still coughing badly from the flu I catched
lately.

> Microsoft official documentation:
> 
> 
> 
> 
> 
> Try running my socket-t program in
>  as 'socket-t 1'; it will
> report the actual time waited.  On Windows 10, you will see lots of
> variation in timeouts, with some of them shorter than the requested
> time.  My ancient Vista laptop has much less variation and is never
> shorter.  Win7 is similar.

In the second link it sounds like a change in W8 might causing this.

> The thing that I think should happen there is that fhandlers'
> select_{read,write,except}() functions should go away, and an fhandler
> should only have a poll() function that indicates what's available, and
> a get_waitable_object() function, that gives sel.wait() something to
> sleep on.  The select_{read,write,except}() functions, and the
> always_ready state variables, partially implement both of these pieces
> of functionality, and really complicate the implementation for select().
> 
> I'm not sure I'll ever get to it, these Cygwin issues are very much a
> side project for me.

That's ok, but the idea is nice.  It would be cool if we could improve
select.  From my POV it has at least three downsides.  It's pretty slow,
the code is complicated, and it's badly commented.  Also, IIRC, the number
of descriptors is restricted to 63 due to WFMO restricted to this number
of handles.  This is not a restriction for sockets since sockets are
using threads per each 63 objects, but the other objects are not doing
that.  So, yeah, there's a lot to improve on select alone.

> The last patch in my series reverts from the documented
> CreateWaitableTimer() interfaces to the ancient, undocumented
> NTCreateTimer() interfaces only for consistency with the rest of the
> Cygwin codebase, which only uses NTCreateTimer().  The documented
> interfaces are all present in XP.  The undocumented interfaces have all
> the functionality this code needs.

Using NtCreateTimer is perfectly fine and I think the API is cleaner
than the CreateWaitableTimer API.

> I'm on #cygwin and #cygwin-dev, ask questions there if you want.

Not ATM, but feel free to contact me on the dev channel.


Thanks,
Corinna

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


signature.asc
Description: PGP signature


Re: Duplicity

2016-02-19 Thread J2897
I've pretty much fixed my particular problem. I installed Cygwin years ago
from another Windows account which I switched from to get rid of Current
User registry problems. So I used Window's  takeown
   command to recursively change the owner
from my old account to my new account. I guess I should have just changed
the owner to the Administrators group incase I ever need to switch again. I
also reset the permissions of the source folders before backup as I think
that's what may have caused the 'hist/install.txt' permission error. The
"Cleanup of temporary directory problem" persists, although that may just be
due to permission inheritance.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Duplicity-tp124554p124586.html
Sent from the cygwin-apps mailing list archive at Nabble.com.


Motif: UIL support for more Cyrillic locales

2016-02-19 Thread Andrey ``Bass'' Shcheglov
Hi All,

Motif's UIL compiler has long had an annoying problem: it often reports 
"$LANG contains an unknown character set" error message for syntactically 
correct *.uil files
(see ,
more examples can be easily looked up).

The issue is caused by the fact that whenever an *.uil file doesn't declare its 
encoding explicitly,
UIL compiler assumes the encoding from the environment (namely, LANG variable). 
At the same time,
UIL doesn't rely on the underlying C library but rather maintains its own 
static list of supported encodings
(in tools/wml/motif.wml).

The above leads to inability to not only use UIL in certain locales,
but also build Motif itself (as UIL is bootstrapped and invoked during the 
build process).

Attached is the patch that fixes the problem for Cyrillic locales.
Support has been added for "ISO-8859-5" (LANG=ru_RU is currently valid, 
LANG=ru_RU.ISO-8859-5 is not),
"CP1251" and "IBM866" charsets.

Regards,
Andrey.

diff --git a/tools/wml/motif.wml b/tools/wml/motif.wml
index 1ad79e9..397040e 100644
--- a/tools/wml/motif.wml
+++ b/tools/wml/motif.wml
@@ -93,7 +93,8 @@ CharacterSet
   Alias = "ISOLatin5";
   Alias = "88595"; };
 iso_cyrillic
-{ XmStringCharsetName = "ISO8859-5"; };
+{ XmStringCharsetName = "ISO8859-5";
+  Alias = "ISO-8859-5"; };
 iso_arabic
 { XmStringCharsetName = "ISO8859-6";
   Alias = "iso_latin6";
@@ -161,6 +162,17 @@ CharacterSet
   Alias = "KOI8R";
   Alias = "KOI8U";
   Alias = "KOI8RU"; };
+ansi_cyrillic
+{ XmStringCharsetName = "CP1251";
+  Alias = "WINDOWS-1251";
+  Alias = "ANSI-1251";
+  ! The name of CP1251 in Solaris
+  Alias = "ANSI1251"; };
+dos_cyrillic
+{ XmStringCharsetName = "IBM866";
+  Alias = "IBM-866";
+  Alias = "CP866";
+  Alias = "866"; };
 XmFONTLIST_DEFAULT_TAG
 { FontListElementTag = XmFONTLIST_DEFAULT_TAG; };
 


signature.asc
Description: OpenPGP digital signature


Re: mktemp() fails on Wine 1.9.3 + Cygwin 2.5.0-0.2

2016-02-19 Thread Qian Hong
Wine use xattr to store Windows ACL information as extended
attribution, (well, it's an emulation for compatibility reason...)

fracting@fracting-ThinkPad-Edge-E431: ~/.wine/drive_c/cygwin$
$ getfattr tmp
# file: tmp
user.DOSATTRIB
user.wine.sd

fracting@fracting-ThinkPad-Edge-E431: ~/.wine/drive_c/cygwin$ getfattr
-n user.wine.sd tmp
# file: tmp
user.wine.sd=0sAQAUEAAAHBwA7AEFAAAFFQAAAOgDAAABBQAABRUBAgAAAgDsAAkBABQAAQACAAEBJAD/AR8AAQUAAAUV6AMAJACAABIAAQUAAAUVAQIAAAEAJAB/AQAAAQUAAAUVAQIAFAC/ARIAAQEAAAEAAQsUAgABAQAACxQA/wEfAAEBAAADAAALFACpABIAAQEAAAMBAAsUAKkAEgABAQAAAQA=

As a temporary hack, you can remove ~/.wine/drive_c/cygwin/tmp from
Linux and re-create using Linux mkdir (rather than Cygwin mkdir). Or
use Linux's `fgetxattr` to clear user.wine.sd attribution of
~/.wine/drive_c/cygwin/tmp, this should make `mktemp` and gcc work.

I'm still investigating what is the root cause.

--
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: [PATCH] Multiple timer issues + new [PATCH]

2016-02-19 Thread ikartur
Hi,

On Feb 19, 2016 2:35 AM, "john hood"  wrote:

> There's some information on the web discussing issues with
> QueryPerformanceCounter()

QueryPerformanceCounter() is the officially recommended method for time 
interval measurements:

https://blogs.msdn.microsoft.com/oldnewthing/20140822-01/?p=163/

https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx

Best Regards,
Artúr

-Original Message-
From: john hood 
To: cygwin-patches@cygwin.com
Sent: Fri, 19 Feb 2016 2:35
Subject: Re: [PATCH] Multiple timer issues + new [PATCH]

On 2/18/16 6:39 PM, Irányossy Knoblauch Artúr wrote:
> The ntod timer (type hires_ns), however, is getting its time value
> from QueryPerformanceCounter(), which, according to the MSDN
> documentation, will provide a "time stamp that can be used for
> time-interval measurements" -- that is just what the doctor ordered.
> :-)

I have some interest in this because my work on select() may interact
with what you're doing here.

There's some information on the web discussing issues with
QueryPerformanceCounter(), for example
.  This is mostly
an issue with CPUs available in the (I think) 2003-2006 time frame, such
as early AMD Athlons and early Intel Core iNNN and i CPUs.  Earlier
CPUs didn't have both changeable clock rates and RDTSC, and later CPUs
had RDTSC but the clock rate is constant for RDTSC.  It's also possible
that only some versions of Windows have issues in this area, maybe later
versions of Windows avoid this problem.  Does your code work properly in
this case?

regards,

  --jh