Re: Bug in collation functions?

[Ken Brown]

On 10/29/2015 4:30 AM, Corinna Vinschen wrote:

On Oct 29 08:50, Corinna Vinschen wrote:

On Oct 28 21:58, Eric Blake wrote:

On 10/28/2015 04:14 PM, Ken Brown wrote:

It's my understanding that collation is supposed to take whitespace and
punctuation into account in the POSIX locale but not in other locales.


Not quite right. It is up to the locale definition whether whitespace
affects collation.  But you are correct that in the POSIX locale,
whitespace must not be ignored in collation.


This doesn't seem to be the case on Cygwin.  Here's a test case using
wcscoll, but the same problem occurs with strcoll.


That's because the locale definitions are different in cygwin than they
are in glibc.  But it is not a bug in Cygwin; POSIX allows for different
systems to have different locale definitions while still using the same
locale name like en_US.UTF-8.


Btw, strcoll and wcscoll in Cygwin are implemented using the Windows
function CompareStringW with the LCID set to the locale matching the
POSIX locale setting.  I'm rather glad I didn't have to implement this
by myself... :}


OTOH, CompareString has a couple of flags to control its behaviour, see
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx

Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there
are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS.  I'm open to a
discussion how to change the settings to more closely resemble the rules
on Linux.

E.g.  wcscoll simply calls wcscmp rather than CompareStringW for the
C/POSIX locale anyway.  So, would it makes sense to set the flags to
NORM_IGNORESYMBOLS in other locales?


I think so.  That's what the native Windows build of emacs does in this 
situation.  (I came across the issue because one of the tests in the 
emacs test suite was failing on Cygwin.)


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

Re: How to run xinit without first entering a cygwin terminal

[Jon Turney]

On 29/10/2015 06:25, Xuehan Xu wrote:

Hi, everyone

I'm trying to run xinit.exe to start a GUI program in a windows cmd
prompt. The command I run:

"c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe
/home/Administrator/rdesktop.exe -f 192.168.1.79

But, it seems that rdesktop.exe isn't running, the window was just
showing a terminal prompt.


Using the command lines from the start menu items created for the xinit 
package as a template (see [1]), I think you need something like:


c:\cygwin\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit.exe 
/home/Administrator/rdesktop.exe -f 192.168.1.79"


The command string being given to bash -c needs quoting, otherwise 
subsequent words are assumed to be parameters to that command.


run needs to be given the -quote option to protect those quotes.

[1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args

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

Re: Bug in collation functions?

[Ken Brown]

On 10/29/2015 11:45 AM, Ken Brown wrote:

On 10/29/2015 11:35 AM, Corinna Vinschen wrote:

On Oct 29 08:59, Ken Brown wrote:

On 10/29/2015 4:30 AM, Corinna Vinschen wrote:

On Oct 29 08:50, Corinna Vinschen wrote:

On Oct 28 21:58, Eric Blake wrote:

On 10/28/2015 04:14 PM, Ken Brown wrote:

It's my understanding that collation is supposed to take
whitespace and
punctuation into account in the POSIX locale but not in other
locales.


Not quite right. It is up to the locale definition whether whitespace
affects collation.  But you are correct that in the POSIX locale,
whitespace must not be ignored in collation.


This doesn't seem to be the case on Cygwin.  Here's a test case
using
wcscoll, but the same problem occurs with strcoll.


That's because the locale definitions are different in cygwin than
they
are in glibc.  But it is not a bug in Cygwin; POSIX allows for
different
systems to have different locale definitions while still using the
same
locale name like en_US.UTF-8.


Btw, strcoll and wcscoll in Cygwin are implemented using the Windows
function CompareStringW with the LCID set to the locale matching the
POSIX locale setting.  I'm rather glad I didn't have to implement this
by myself... :}


OTOH, CompareString has a couple of flags to control its behaviour, see
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx


Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but
there
are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS.  I'm open to a
discussion how to change the settings to more closely resemble the
rules
on Linux.

E.g.  wcscoll simply calls wcscmp rather than CompareStringW for the
C/POSIX locale anyway.  So, would it makes sense to set the flags to
NORM_IGNORESYMBOLS in other locales?


I think so.  That's what the native Windows build of emacs does in this
situation.


Is that all it's doing?  I'm asking because using NORM_IGNORESYMBOLS
does not exaclty resemble the behaviour on Linux on my W10 box:

 "11" > "1.1" in POSIX locale
!!! "11" > "1.1" in en_US.UTF-8 locale
 "11" > "1 2" in POSIX locale
 "11" < "1 2" in en_US.UTF-8 locale


I just noticed that myself and was going to ask about that difference. I
don't see anything else that emacs is doing on native Windows.  But in
the test I referred to above, the locale is set to "enu_USA" in the
native Windows build.  Does that explain the discrepancy?  If not, I can
ask on the emacs-devel list whether the test passes on Windows.


Never mind.  My test case was flawed, because it didn't check for the 
possibility that wcscoll might return 0.  Here's a revised definition of 
the "compare" function:


void
compare (const wchar_t *a, const wchar_t *b, const char *loc)
{
  setlocale (LC_COLLATE, loc);
  int res = wcscoll (a, b);
  char c = res < 0 ? '<' : res > 0 ? '>' : '=';
  printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc);
}

With this change (and the use of NORM_IGNORESYMBOLS) the test returns 
the following on Cygwin:


$ ./wcscoll_test
"11" > "1.1" in POSIX locale
"11" = "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1 2" in en_US.UTF-8 locale

It still differs from Linux, but it's good enough to make the emacs test 
pass.  Moreover, this behavior actually seems more reasonable to me than 
the Linux behavior.  After all, if you're ignoring punctuation, how can 
you decide which of "11" or "1.1" comes first?


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

New: lz4-131-1

[Yaakov Selkowitz]

The following packages have been added to the Cygwin distribution:

* lz4-131-1
* liblz4_1-131-1
* liblz4-devel-131-1

LZ4 is a lossless compression algorithm, providing compression speed at
400 MB/s per core. It features an extremely fast decoder, with speed in
multiple GB/s per core. A high compression derivative, called LZ4_HC, is
available, trading customizable CPU time for compression ratio.

--
Yaakov

Re: Bug in collation functions?

[Eric Blake]

On 10/29/2015 09:35 AM, Corinna Vinschen wrote:

>>> Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there
>>> are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS.  I'm open to a
>>> discussion how to change the settings to more closely resemble the rules
>>> on Linux.
>>>
>>> E.g.  wcscoll simply calls wcscmp rather than CompareStringW for the
>>> C/POSIX locale anyway.  So, would it makes sense to set the flags to
>>> NORM_IGNORESYMBOLS in other locales?
>>
>> I think so.  That's what the native Windows build of emacs does in this
>> situation.
> 
> Is that all it's doing?  I'm asking because using NORM_IGNORESYMBOLS
> does not exaclty resemble the behaviour on Linux on my W10 box:
> 
> "11" > "1.1" in POSIX locale
> !!! "11" > "1.1" in en_US.UTF-8 locale
> "11" > "1 2" in POSIX locale
> "11" < "1 2" in en_US.UTF-8 locale
> 

I'm not sure if blindly enabling the flags for all locales makes sense,
though.  I haven't audited glibc locales to know for sure, but it is my
impression that it is up to the locale author on whether whitespace
affects collation; and while the author of glibc en_US.UTF-8 may have
chosen that way, I can't guarantee that some other locales in glibc
still treat whitespace as significant.

POSIX has a notion of writing your own locale definition - and glibc
definitely supports that (although I haven't personally tried doing it),
where you can set your OWN collation rules while inheriting the bulk of
the work from an existing locale.   So in glibc, it is possible to have
a locale similar to en_US.UTF-8 but where whitespace IS significant in
collation.  I know cygwin isn't there yet (we expose the Windows locale,
but do not let you define your own).

This seems like the sort of thing where maybe we'd want support for
user-defined locales, compiled into a binary format, and then cygwin
opens the binary locale definition for deciding which flags to use
according to the locale being used.  But that sounds like a LOT of work,
for a questionable amount of gain.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

RE: pthread_kill: signals remain pending after target thread exits

[John Carey]

> From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> Sent: Thursday, October 29, 2015 1:02 AM
> On Oct 28 10:14, Corinna Vinschen wrote:
...
> > > Thanks; that was fast!  I tried replacing cygwin1.dll with 
> > > cygwin1-20151023.dll .
> > >
> > > The original test case now works.  I checked some of my other tests,
> > > and unfortunately some of them failed, so I extracted out a new test
> > > case, which is attached.  My guess is that something is subtly different
> > > about the timing on this test.
> >
> > Is this a regression?  Did it work with 2.2.1?
> 
> Answering myself here, this didn't work at all in 2.2.1.  I can
> reproduce the problem and I'm going to take a look.  Not sure if
> there's a quick solution, though.  This looks like a deadlock
> situation.  The signal definitely got send, I just don't see yet
> why it's not handled in wait_sig.

Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms
differ: there is no Cygwin process left hanging that cannot be
killed by a Cygwin signal.

But both tests appear to pass in Cygwin 1.7.9, so in that sense
it is a regression, just not a recent one.

-- John Carey

--
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] New: lz4-131-1

[Yaakov Selkowitz]

The following packages have been added to the Cygwin distribution:

* lz4-131-1
* liblz4_1-131-1
* liblz4-devel-131-1

LZ4 is a lossless compression algorithm, providing compression speed at
400 MB/s per core. It features an extremely fast decoder, with speed in
multiple GB/s per core. A high compression derivative, called LZ4_HC, is
available, trading customizable CPU time for compression ratio.

--
Yaakov

--
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: audiofile-0.3.6-2

[Yaakov Selkowitz]

The following packages have been updated in the Cygwin distribution:

* audiofile-0.3.6-2
* libaudiofile1-0.3.6-2
* libaudiofile-devel-0.3.6-2

The Audio File Library provides a uniform programming interface to
standard digital audio file formats. This library allows the processing
of audio data to and from audio files of many common formats (currently
AIFF, AIFF-C, WAVE, NeXT/Sun .snd/.au, IRCAM, AVR, Amiga IFF/8SVX, and
NIST SPHERE). The library also supports compression (currently G.711
mu-law and A-law and IMA and MS ADPCM) as well as PCM formats of all
flavors (signed and unsigned integer, single- and double-precision
floating point).

This release includes a patch for CVE-2015-7747:
https://bugzilla.redhat.com/show_bug.cgi?id=1269766

--
Yaakov

--
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: exiv2-0.25-1

[Yaakov Selkowitz]

The following packages have been updated in the Cygwin distribution:

* exiv2-0.25-1
* libexiv2_14-0.25-1
* libexiv2-devel-0.25-1

Exiv2 is a C++ library and a command line utility to manage image
metadata. It provides fast and easy read and write access to the Exif,
IPTC and XMP metadata of digital images in various formats.

This is an update to the latest upstream release, with an ABI version
bump to the library.  Packages dependent on the previous version of the
library are in the process of being rebuilt.

--
Yaakov

--
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: Unison 2.43.3 fails to synchronize execute permission bit

[Ms. Alex Hankins]

On Wed, Oct 28, 2015 at 2:55 PM,   wrote:
> When synchronizing two directories on the same NTFS-formatted drive, unison 
> (with -perms 0o1777) fails to set execute permissions on new files.  (It also 
> fails to detect changes in execute permissions and to set them on existing 
> files.)
>...

I forgot cygcheck.out.  I have attached it.

Ms. Alex Hankins


cygcheck.out
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: Bug in collation functions?

[Corinna Vinschen]

On Oct 29 08:59, Ken Brown wrote:
> On 10/29/2015 4:30 AM, Corinna Vinschen wrote:
> >On Oct 29 08:50, Corinna Vinschen wrote:
> >>On Oct 28 21:58, Eric Blake wrote:
> >>>On 10/28/2015 04:14 PM, Ken Brown wrote:
> It's my understanding that collation is supposed to take whitespace and
> punctuation into account in the POSIX locale but not in other locales.
> >>>
> >>>Not quite right. It is up to the locale definition whether whitespace
> >>>affects collation.  But you are correct that in the POSIX locale,
> >>>whitespace must not be ignored in collation.
> >>>
> This doesn't seem to be the case on Cygwin.  Here's a test case using
> wcscoll, but the same problem occurs with strcoll.
> >>>
> >>>That's because the locale definitions are different in cygwin than they
> >>>are in glibc.  But it is not a bug in Cygwin; POSIX allows for different
> >>>systems to have different locale definitions while still using the same
> >>>locale name like en_US.UTF-8.
> >>
> >>Btw, strcoll and wcscoll in Cygwin are implemented using the Windows
> >>function CompareStringW with the LCID set to the locale matching the
> >>POSIX locale setting.  I'm rather glad I didn't have to implement this
> >>by myself... :}
> >
> >OTOH, CompareString has a couple of flags to control its behaviour, see
> >https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx
> >
> >Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there
> >are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS.  I'm open to a
> >discussion how to change the settings to more closely resemble the rules
> >on Linux.
> >
> >E.g.  wcscoll simply calls wcscmp rather than CompareStringW for the
> >C/POSIX locale anyway.  So, would it makes sense to set the flags to
> >NORM_IGNORESYMBOLS in other locales?
> 
> I think so.  That's what the native Windows build of emacs does in this
> situation.

Is that all it's doing?  I'm asking because using NORM_IGNORESYMBOLS
does not exaclty resemble the behaviour on Linux on my W10 box:

"11" > "1.1" in POSIX locale
!!! "11" > "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1 2" in en_US.UTF-8 locale


Corinna

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


pgpofEpwqtRBJ.pgp
Description: PGP signature

Re: Bug in collation functions?

[Ken Brown]

On 10/29/2015 11:35 AM, Corinna Vinschen wrote:

On Oct 29 08:59, Ken Brown wrote:

On 10/29/2015 4:30 AM, Corinna Vinschen wrote:

On Oct 29 08:50, Corinna Vinschen wrote:

On Oct 28 21:58, Eric Blake wrote:

On 10/28/2015 04:14 PM, Ken Brown wrote:

It's my understanding that collation is supposed to take whitespace and
punctuation into account in the POSIX locale but not in other locales.


Not quite right. It is up to the locale definition whether whitespace
affects collation.  But you are correct that in the POSIX locale,
whitespace must not be ignored in collation.


This doesn't seem to be the case on Cygwin.  Here's a test case using
wcscoll, but the same problem occurs with strcoll.


That's because the locale definitions are different in cygwin than they
are in glibc.  But it is not a bug in Cygwin; POSIX allows for different
systems to have different locale definitions while still using the same
locale name like en_US.UTF-8.


Btw, strcoll and wcscoll in Cygwin are implemented using the Windows
function CompareStringW with the LCID set to the locale matching the
POSIX locale setting.  I'm rather glad I didn't have to implement this
by myself... :}


OTOH, CompareString has a couple of flags to control its behaviour, see
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx

Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there
are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS.  I'm open to a
discussion how to change the settings to more closely resemble the rules
on Linux.

E.g.  wcscoll simply calls wcscmp rather than CompareStringW for the
C/POSIX locale anyway.  So, would it makes sense to set the flags to
NORM_IGNORESYMBOLS in other locales?


I think so.  That's what the native Windows build of emacs does in this
situation.


Is that all it's doing?  I'm asking because using NORM_IGNORESYMBOLS
does not exaclty resemble the behaviour on Linux on my W10 box:

 "11" > "1.1" in POSIX locale
!!! "11" > "1.1" in en_US.UTF-8 locale
 "11" > "1 2" in POSIX locale
 "11" < "1 2" in en_US.UTF-8 locale


I just noticed that myself and was going to ask about that difference. 
I don't see anything else that emacs is doing on native Windows.  But in 
the test I referred to above, the locale is set to "enu_USA" in the 
native Windows build.  Does that explain the discrepancy?  If not, I can 
ask on the emacs-devel list whether the test passes on Windows.


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

Updated: exiv2-0.25-1

[Yaakov Selkowitz]

The following packages have been updated in the Cygwin distribution:

* exiv2-0.25-1
* libexiv2_14-0.25-1
* libexiv2-devel-0.25-1

Exiv2 is a C++ library and a command line utility to manage image
metadata. It provides fast and easy read and write access to the Exif,
IPTC and XMP metadata of digital images in various formats.

This is an update to the latest upstream release, with an ABI version
bump to the library.  Packages dependent on the previous version of the
library are in the process of being rebuilt.

--
Yaakov

Updated: packages rebuilt for exiv2-0.25, openexr-2.2.0

[Yaakov Selkowitz]

The following packages (and their subpackages) have been updated, having
been rebuilt for exiv2-0.25 and/or openexr-2.2.0:

* calligra-2.9.8-2
* gegl-0.2.0-9
* gwenview-4.14.3-3
* kdelibs-4.14.13-1
* kde-runtime-15.04.3-2
* kf5-kimageformats-5.12.0-2
* kfilemetadata-4.14.3-2
* libkexiv2-15.04.3-2
* pdf2djvu-0.9.1-2
* strigi-0.7.8-5
* ufraw-0.22-2

--
Yaakov

Updated: tiff-4.0.6-1

[Yaakov Selkowitz]

The following packages have been updated for both arches:

* tiff-4.0.6-1
* tiff-doc-4.0.6-1
* tiff-opengl-4.0.6-1
* libtiff6-4.0.6-1
* libtiff-devel-4.0.6-1

libtiff is the reference implementation for reading and writing TIFF
images, along with a small collection of tools for doing simple
manipulations of TIFF images on UNIX systems, and documentation on the
library and tools.

This is an update to the latest upstream release.

--
Yaakov

[ANNOUNCEMENT] Updated: tiff-4.0.6-1

[Yaakov Selkowitz]

The following packages have been updated for both arches:

* tiff-4.0.6-1
* tiff-doc-4.0.6-1
* tiff-opengl-4.0.6-1
* libtiff6-4.0.6-1
* libtiff-devel-4.0.6-1

libtiff is the reference implementation for reading and writing TIFF
images, along with a small collection of tools for doing simple
manipulations of TIFF images on UNIX systems, and documentation on the
library and tools.

This is an update to the latest upstream release.

--
Yaakov

--
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: initial cygwin installation

[Warren Young]

On Oct 28, 2015, at 8:49 PM, Andrey Repin wrote:
> 
>> I only wanted to *reinstall*
>> everything I had installed previously
> 
> Solution is to run `cygcheck --check-setup` and manually select any packages
> reported incomplete for reinstall.

This solution and Achim Gratz’ assume your Cygwin installation still runs.

If your AV has so totally roached things that you can’t even get a bash prompt 
up, or run your text editor, or run sed, you still have one way to avoid 
reinstalling everything without guessing: 

Open c:\cygwin64\bin in Windows Explorer, and use the file listing you find 
there to choose packages to reinstall.  Many of these will belong to some 
umbrella package, like coreutils or cygutils, so use the Cygwin Package search 
engine to work out what to reinstall if you’re not sure:

  https://cygwin.com/packages

Searching for something like “ls” will return too many results.  Making it 
“ls.exe” helps, but will still include false positives.  But, searching for 
“/ls.exe” tells you what you want to know: it’s in coreutils.
--
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: poppler-0.36.0-2

[Yaakov Selkowitz]

The following packages have been updated for both arches:

* poppler-0.36.0-2
* libpoppler55-0.36.0-2
* libpoppler-devel-0.36.0-2
* libpoppler-cpp0-0.36.0-2
* libpoppler-cpp-devel-0.36.0-2
* libpoppler-glib8-0.36.0-2
* libpoppler-glib-devel-0.36.0-2
* libpoppler-glib-doc-0.36.0-2
* girepository-Poppler0.18-0.36.0-2
* libpoppler-qt4_4-0.36.0-2
* libpoppler-qt4-devel-0.36.0-2
* libpoppler-qt5_1-0.36.0-2
* libpoppler-qt5-devel-0.36.0-2

Poppler is a suite of PDF rendering libraries and utilities based on the
xpdf-3.0 code base.

This release re-enables OpenJPEG support.

--
Yaakov

--
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: Bug in collation functions?

[Eric Blake]

On 10/29/2015 10:13 AM, Ken Brown wrote:

> Never mind.  My test case was flawed, because it didn't check for the
> possibility that wcscoll might return 0.  Here's a revised definition of
> the "compare" function:
> 
> void
> compare (const wchar_t *a, const wchar_t *b, const char *loc)
> {
>   setlocale (LC_COLLATE, loc);
>   int res = wcscoll (a, b);
>   char c = res < 0 ? '<' : res > 0 ? '>' : '=';
>   printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc);
> }
> 
> With this change (and the use of NORM_IGNORESYMBOLS) the test returns
> the following on Cygwin:
> 
> $ ./wcscoll_test
> "11" > "1.1" in POSIX locale
> "11" = "1.1" in en_US.UTF-8 locale
> "11" > "1 2" in POSIX locale
> "11" < "1 2" in en_US.UTF-8 locale
> 
> It still differs from Linux, but it's good enough to make the emacs test
> pass.  Moreover, this behavior actually seems more reasonable to me than
> the Linux behavior.  After all, if you're ignoring punctuation, how can
> you decide which of "11" or "1.1" comes first?

Careful.  POSIX is proposing some wording that say that normal locales
should always implement a fallback of last resort (and that locales that
do not do so should have a special name including '@', to make it
obvious).  It is not standardized yet, but worth thinking about.

http://austingroupbugs.net/view.php?id=938
http://austingroupbugs.net/view.php?id=963

The intent of that wording is that if ignoring punctuation could cause
two strings to otherwise compare equal, the fallback of a total ordering
on all characters means that the final result of strcoll() will not be 0
unless the two strings are identical.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: packages rebuilt for exiv2-0.25, openexr-2.2.0

[Yaakov Selkowitz]

The following packages (and their subpackages) have been updated, having
been rebuilt for exiv2-0.25 and/or openexr-2.2.0:

* calligra-2.9.8-2
* gegl-0.2.0-9
* gwenview-4.14.3-3
* kdelibs-4.14.13-1
* kde-runtime-15.04.3-2
* kf5-kimageformats-5.12.0-2
* kfilemetadata-4.14.3-2
* libkexiv2-15.04.3-2
* pdf2djvu-0.9.1-2
* strigi-0.7.8-5
* ufraw-0.22-2

--
Yaakov

--
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] New: openjpeg2-2.1.0-1

[Yaakov Selkowitz]

The following packages have been added to the Cygwin distribution:

* openjpeg2-2.1.0-1
* libopenjp2_7-2.1.0-1
* libopenjp2-devel-2.1.0-1
* libopenjp2-doc-2.1.0-1

The OpenJPEG library is an open-source JPEG 2000 codec written in C
language. It has been developed in order to promote the use of JPEG
2000, the new still-image compression standard from the Joint
Photographic Experts Group (JPEG).

This is a new major release of the OpenJPEG library, and is parallel
installable with the 1.5 version still in use.

--
Yaakov

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

New: openjpeg2-2.1.0-1

[Yaakov Selkowitz]

The following packages have been added to the Cygwin distribution:

* openjpeg2-2.1.0-1
* libopenjp2_7-2.1.0-1
* libopenjp2-devel-2.1.0-1
* libopenjp2-doc-2.1.0-1

The OpenJPEG library is an open-source JPEG 2000 codec written in C
language. It has been developed in order to promote the use of JPEG
2000, the new still-image compression standard from the Joint
Photographic Experts Group (JPEG).

This is a new major release of the OpenJPEG library, and is parallel
installable with the 1.5 version still in use.

--
Yaakov

Re: Bug in collation functions?

[Ken Brown]

On 10/29/2015 12:51 PM, Eric Blake wrote:

On 10/29/2015 10:13 AM, Ken Brown wrote:


Never mind.  My test case was flawed, because it didn't check for the
possibility that wcscoll might return 0.  Here's a revised definition of
the "compare" function:

void
compare (const wchar_t *a, const wchar_t *b, const char *loc)
{
   setlocale (LC_COLLATE, loc);
   int res = wcscoll (a, b);
   char c = res < 0 ? '<' : res > 0 ? '>' : '=';
   printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc);
}

With this change (and the use of NORM_IGNORESYMBOLS) the test returns
the following on Cygwin:

$ ./wcscoll_test
"11" > "1.1" in POSIX locale
"11" = "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1 2" in en_US.UTF-8 locale

It still differs from Linux, but it's good enough to make the emacs test
pass.  Moreover, this behavior actually seems more reasonable to me than
the Linux behavior.  After all, if you're ignoring punctuation, how can
you decide which of "11" or "1.1" comes first?


Careful.  POSIX is proposing some wording that say that normal locales
should always implement a fallback of last resort (and that locales that
do not do so should have a special name including '@', to make it
obvious).  It is not standardized yet, but worth thinking about.

http://austingroupbugs.net/view.php?id=938
http://austingroupbugs.net/view.php?id=963

The intent of that wording is that if ignoring punctuation could cause
two strings to otherwise compare equal, the fallback of a total ordering
on all characters means that the final result of strcoll() will not be 0
unless the two strings are identical.


In that case, I think Cygwin should start by using NORM_IGNORESYMBOLS in 
non-POSIX locales, with the goal of eventually moving toward emulating 
glibc.  I don't know what fallback glibc uses or how hard it would be to 
implement this on Cygwin.


Here's a tangentially related issue, also motivated by a failing emacs 
test: Should setlocale return null to indicate an error if it's given an 
invalid locale name?  This happens on Linux but not on Cygwin, as the 
following modified test case shows:


$ cat wcscoll_test.c
#include 
#include 
#include 

void
compare (const wchar_t *a, const wchar_t *b, const char *loc)
{
  if (! setlocale (LC_COLLATE, loc))
printf ("Unable to set locale to %s\n", loc);
  else
{
  int res = wcscoll (a, b);
  char c = res < 0 ? '<' : res > 0 ? '>' : '=';
  printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc);
}
}

int
main ()
{
  compare (L"11", L"1.1", "POSIX");
  compare (L"11", L"1.1", "en_US.UTF-8");
  compare (L"11", L"1 2", "POSIX");
  compare (L"11", L"1 2", "en_US.UTF-8");
  compare (L"11", L"1 2", "en_DE.UTF-8");
}

On Cygwin (with NORM_IGNORESYMBOLS), the output is

"11" > "1.1" in POSIX locale
"11" = "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1 2" in en_US.UTF-8 locale
"11" < "1 2" in en_DE.UTF-8 locale

but on Linux it is

"11" > "1.1" in POSIX locale
"11" < "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1 2" in en_US.UTF-8 locale
Unable to set locale to en_DE.UTF-8

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

setup.exe with packages specified downloads multiple versions [?]

[Roger Pack]

As a note, running this:


setup-x86.exe ^
--quiet-mode ^
--no-admin ^
--no-startmenu ^
--no-shortcuts ^
--no-desktop ^
--site http://mirrors.xmission.com/cygwin/ ^
--root %cd% ^
--packages ^
ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch

downloads seemingly lots of versions of particular packages [?] (note
the duplicates of autoconf and automake, various versions:

Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/autoconf/autoconf-13-1.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/autoconf2.1/autoconf2.1-2.13-12.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/autoconf2.5/autoconf2.5-2.69-3.tar.xz
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake/automake-9-1.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake1.10/automake1.10-1.10.3-2.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake1.11/automake1.11-1.11.6-2.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm
peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin
%2f/x86/release/automake1.12/automake1.12-1.12.6-2.tar.bz2
Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm

Not sure if that's expected or not.
Cheers!
-roger-

--
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: xfig-3.2.5c-2.x86_64 crashes on save as or export on windows 10

[Hans-Georg Scherneck]

Hi too,
it crashes on x_86 (i.e. 32 bit version) too, even after re-installing the 
xorg-server packages.
xfig won't show the export window before it crashes. What else can I do? Any step-by-step procedure 
with xorg-server renewal?

Is there an issue with Athena widgets?
Cheers
Hans-Georg


Hi,

A follow up.

I down leveled the xorg-server* (5 packages from 1.17.2-4 to 1.17.2-3
-common, -devel, -dmx, -extra + servers) and this bad behavior
goes away (Xfig saves as and/or exports files).  There is a segfault
when it exits & some complaints re missing fonts (?) but I can
function.

Cheers,
Steve



--
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: setup.exe with packages specified downloads multiple versions [?]

[Marco Atzeri]

On 29/10/2015 20:53, Roger Pack wrote:

As a note, running this:


setup-x86.exe ^
--quiet-mode ^
--no-admin ^
--no-startmenu ^
--no-shortcuts ^
--no-desktop ^
--site http://mirrors.xmission.com/cygwin/ ^
--root %cd% ^
--packages ^
ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch

downloads seemingly lots of versions of particular packages [?] (note
the duplicates of autoconf and automake, various versions:


[cut]


Not sure if that's expected or not.
Cheers!
-roger-


Setup is correct.
Autoconf and automake are wrapper managing
 alternative version of the same package.
If you looks on setup.ini content:

@ autoconf
sdesc: "Wrapper scripts for autoconf commands"
ldesc: "Wrapper scripts for autoconf commands"
category: Devel
requires: bash sed autoconf2.1 autoconf2.5 cygwin

@ automake
sdesc: "Wrapper scripts for automake and aclocal"
ldesc: "Wrapper scripts for automake and aclocal"
category: Devel
requires: bash gawk automake1.4 automake1.5 automake1.6 automake1.7 
automake1.8 automake1.9 automake1.10 automake1.11 automake1.12 
automake1.13 automake1.14 automake1.15 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

64 bit has different dependencies somehow?

[Roger Pack]

As a note, when installing these packages:

setup-x86.exe ^
--quiet-mode ^
--no-admin ^
--no-startmenu ^
--no-shortcuts ^
--no-desktop ^
--site http://mirrors.xmission.com/cygwin/ ^
--root %cd% ^
--packages ^
ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch

and

setup-x86_64.exe ^
--quiet-mode ^
--no-admin ^
--no-startmenu ^
--no-shortcuts ^
--no-desktop ^
--site http://mirrors.xmission.com/cygwin/ ^
--root %cd% ^
--packages ^
ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch


for some reason with the 32 bit install, I get "libintl.a" installed:


 Directory of 
C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffmpeg_local_builds.good2\cygwin_local_install\lib

09/20/2015  02:02 PM   205,162 libintl.a
09/20/2015  02:02 PM39,098 libintl.dll.a
09/20/2015  02:02 PM   899 libintl.la

But not the same libs for the 64 bit install.
Just calling it out in case it's unexpected

Cheers!
-roger-

--
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: setup.exe with packages specified downloads multiple versions [?]

[Roger Pack]

On 10/29/15, Marco Atzeri  wrote:
>
>
> On 29/10/2015 20:53, Roger Pack wrote:
>> As a note, running this:
>>
>>
>> setup-x86.exe ^
>> --quiet-mode ^
>> --no-admin ^
>> --no-startmenu ^
>> --no-shortcuts ^
>> --no-desktop ^
>> --site http://mirrors.xmission.com/cygwin/ ^
>> --root %cd% ^
>> --packages ^
>> ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch
>>
>> downloads seemingly lots of versions of particular packages [?] (note
>> the duplicates of autoconf and automake, various versions:
>>
> [cut]
>>
>> Not sure if that's expected or not.
>> Cheers!
>> -roger-
>
> Setup is correct.
> Autoconf and automake are wrapper managing
>   alternative version of the same package.
> If you looks on setup.ini content:
>
> @ autoconf
> sdesc: "Wrapper scripts for autoconf commands"
> ldesc: "Wrapper scripts for autoconf commands"
> category: Devel
> requires: bash sed autoconf2.1 autoconf2.5 cygwin
> 
> @ automake
> sdesc: "Wrapper scripts for automake and aclocal"
> ldesc: "Wrapper scripts for automake and aclocal"
> category: Devel
> requires: bash gawk automake1.4 automake1.5 automake1.6 automake1.7
> automake1.8 automake1.9 automake1.10 automake1.11 automake1.12
> automake1.13 automake1.14 automake1.15 cygwin

OK thanks for the clarification.
-roger-

--
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: Bug in collation functions?

[Ken Brown]

On 10/29/2015 5:49 PM, Ken Brown wrote:

On 10/29/2015 2:42 PM, Ken Brown wrote:

On 10/29/2015 12:51 PM, Eric Blake wrote:

On 10/29/2015 10:13 AM, Ken Brown wrote:


Never mind.  My test case was flawed, because it didn't check for the
possibility that wcscoll might return 0.  Here's a revised
definition of
the "compare" function:

void
compare (const wchar_t *a, const wchar_t *b, const char *loc)
{
   setlocale (LC_COLLATE, loc);
   int res = wcscoll (a, b);
   char c = res < 0 ? '<' : res > 0 ? '>' : '=';
   printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc);
}

With this change (and the use of NORM_IGNORESYMBOLS) the test returns
the following on Cygwin:

$ ./wcscoll_test
"11" > "1.1" in POSIX locale
"11" = "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1 2" in en_US.UTF-8 locale

It still differs from Linux, but it's good enough to make the emacs
test
pass.  Moreover, this behavior actually seems more reasonable to me
than
the Linux behavior.  After all, if you're ignoring punctuation, how can
you decide which of "11" or "1.1" comes first?


Careful.  POSIX is proposing some wording that say that normal locales
should always implement a fallback of last resort (and that locales that
do not do so should have a special name including '@', to make it
obvious).  It is not standardized yet, but worth thinking about.

http://austingroupbugs.net/view.php?id=938
http://austingroupbugs.net/view.php?id=963

The intent of that wording is that if ignoring punctuation could cause
two strings to otherwise compare equal, the fallback of a total ordering
on all characters means that the final result of strcoll() will not be 0
unless the two strings are identical.


In that case, I think Cygwin should start by using NORM_IGNORESYMBOLS in
non-POSIX locales, with the goal of eventually moving toward emulating
glibc.  I don't know what fallback glibc uses or how hard it would be to
implement this on Cygwin.


I withdraw this suggestion.  I took a look at the glibc code, and I
don't see any reasonable way for Cygwin to emulate it precisely.  On the
other hand, I have an idea for a simple fallback.  I'll play with it a
little and then submit a patch.


The fallback I had in mind is to return the shorter string if they have 
different lengths and otherwise to revert to wcscmp.  Using this, both 
Cygwin and Linux give the following comparisons:


"11" > "1.1" in POSIX locale
"11" < "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1.2" in en_US.UTF-8 locale
"1 1" < "1.1" in POSIX locale
"1 1" < "1.1" in en_US.UTF-8 locale

If this seems reasonable, I'll test it more extensively and then submit 
a patch.


Ken

P.S. In case others want to test this in different locales, here's the 
patch so far, just for wcscoll:


diff --git a/winsup/cygwin/nlsfuncs.cc b/winsup/cygwin/nlsfuncs.cc
index f7031f9..c33aa24 100644
--- a/winsup/cygwin/nlsfuncs.cc
+++ b/winsup/cygwin/nlsfuncs.cc
@@ -1156,10 +1156,15 @@ wcscoll (const wchar_t *__restrict ws1, const 
wchar_t *__restrict ws2)


   if (!collate_lcid)
 return wcscmp (ws1, ws2);
-  ret = CompareStringW (collate_lcid, 0, ws1, -1, ws2, -1);
+  ret = CompareStringW (collate_lcid, NORM_IGNORESYMBOLS, ws1, -1, ws2, 
-1);

   if (!ret)
 set_errno (EINVAL);
-  return ret - CSTR_EQUAL;
+  ret -= CSTR_EQUAL;
+  if (!ret)
+ret = wcslen (ws1) - wcslen (ws2);
+  if (!ret)
+ret = wcscmp (ws1, ws2);
+  return ret;
 }

 extern "C" int


--
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: Bug in collation functions?

[Ken Brown]

On 10/29/2015 2:42 PM, Ken Brown wrote:

On 10/29/2015 12:51 PM, Eric Blake wrote:

On 10/29/2015 10:13 AM, Ken Brown wrote:


Never mind.  My test case was flawed, because it didn't check for the
possibility that wcscoll might return 0.  Here's a revised definition of
the "compare" function:

void
compare (const wchar_t *a, const wchar_t *b, const char *loc)
{
   setlocale (LC_COLLATE, loc);
   int res = wcscoll (a, b);
   char c = res < 0 ? '<' : res > 0 ? '>' : '=';
   printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc);
}

With this change (and the use of NORM_IGNORESYMBOLS) the test returns
the following on Cygwin:

$ ./wcscoll_test
"11" > "1.1" in POSIX locale
"11" = "1.1" in en_US.UTF-8 locale
"11" > "1 2" in POSIX locale
"11" < "1 2" in en_US.UTF-8 locale

It still differs from Linux, but it's good enough to make the emacs test
pass.  Moreover, this behavior actually seems more reasonable to me than
the Linux behavior.  After all, if you're ignoring punctuation, how can
you decide which of "11" or "1.1" comes first?


Careful.  POSIX is proposing some wording that say that normal locales
should always implement a fallback of last resort (and that locales that
do not do so should have a special name including '@', to make it
obvious).  It is not standardized yet, but worth thinking about.

http://austingroupbugs.net/view.php?id=938
http://austingroupbugs.net/view.php?id=963

The intent of that wording is that if ignoring punctuation could cause
two strings to otherwise compare equal, the fallback of a total ordering
on all characters means that the final result of strcoll() will not be 0
unless the two strings are identical.


In that case, I think Cygwin should start by using NORM_IGNORESYMBOLS in
non-POSIX locales, with the goal of eventually moving toward emulating
glibc.  I don't know what fallback glibc uses or how hard it would be to
implement this on Cygwin.


I withdraw this suggestion.  I took a look at the glibc code, and I 
don't see any reasonable way for Cygwin to emulate it precisely.  On the 
other hand, I have an idea for a simple fallback.  I'll play with it a 
little and then submit a patch.


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

Updated: pixman-0.32.8-1

[Yaakov Selkowitz]

The following packages have been updated in the Cygwin distribution:

* libpixman1_0-0.32.8-1
* libpixman1-devel-0.32.8-1

pixman is a library that provides low-level pixel manipulation features
such as image compositing and trapezoid rasterization.  It is used
primarily by the cairo library and the X servers.

This is an update to the latest upstream stable release, which includes
a fix for a potential stack overflow (which, FWIW, I have been unable to
reproduce on Cygwin):

https://bugs.freedesktop.org/show_bug.cgi?id=92027

--
Yaakov

[ANNOUNCEMENT] Updated: pixman-0.32.8-1

[Yaakov Selkowitz]

The following packages have been updated in the Cygwin distribution:

* libpixman1_0-0.32.8-1
* libpixman1-devel-0.32.8-1

pixman is a library that provides low-level pixel manipulation features
such as image compositing and trapezoid rasterization.  It is used
primarily by the cairo library and the X servers.

This is an update to the latest upstream stable release, which includes
a fix for a potential stack overflow (which, FWIW, I have been unable to
reproduce on Cygwin):

https://bugs.freedesktop.org/show_bug.cgi?id=92027

--
Yaakov

--
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: How to run xinit without first entering a cygwin terminal

[Xuehan Xu]

Thanks for your reply:-)

I followed your advice, now it seems that rdesktop is running, but the
window that xinit showed was just plain black. rdesktop is supposed to
be a remote desktop client that runs on linux and connect to a windows
remote desktop. When I use the command "/usr/bin/xinit.exe
./rdesktop/rdesktop.exe -f 192.168.1.79" in a cygwin terminal, it can
show the desktop of 192.168.1.79.

Could this be due to the same reason  that startx can't show the
cygwin desktop? What should I do? Thanks;-)

On 29 October 2015 at 21:23, Jon Turney  wrote:
> On 29/10/2015 06:25, Xuehan Xu wrote:
>>
>> Hi, everyone
>>
>> I'm trying to run xinit.exe to start a GUI program in a windows cmd
>> prompt. The command I run:
>>
>> "c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe
>> /home/Administrator/rdesktop.exe -f 192.168.1.79
>>
>> But, it seems that rdesktop.exe isn't running, the window was just
>> showing a terminal prompt.
>
>
> Using the command lines from the start menu items created for the xinit
> package as a template (see [1]), I think you need something like:
>
> c:\cygwin\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit.exe
> /home/Administrator/rdesktop.exe -f 192.168.1.79"
>
> The command string being given to bash -c needs quoting, otherwise
> subsequent words are assumed to be parameters to that command.
>
> run needs to be given the -quote option to protect those quotes.
>
> [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args
>
> --
> 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

Re: How to run xinit without first entering a cygwin terminal

[Xuehan Xu]

By the way, the error that popped up when running startx from the
windows command line was something like this:
"Failed to connect to socket /tmp/dbus-XsPeRupEi : connection refused"
and "environment variable $XDG_CONFIG_DIRS isn't properly configured"

On 30 October 2015 at 08:40, Xuehan Xu  wrote:
> Thanks for your reply:-)
>
> I followed your advice, now it seems that rdesktop is running, but the
> window that xinit showed was just plain black. rdesktop is supposed to
> be a remote desktop client that runs on linux and connect to a windows
> remote desktop. When I use the command "/usr/bin/xinit.exe
> ./rdesktop/rdesktop.exe -f 192.168.1.79" in a cygwin terminal, it can
> show the desktop of 192.168.1.79.
>
> Could this be due to the same reason  that startx can't show the
> cygwin desktop? What should I do? Thanks;-)
>
> On 29 October 2015 at 21:23, Jon Turney  wrote:
>> On 29/10/2015 06:25, Xuehan Xu wrote:
>>>
>>> Hi, everyone
>>>
>>> I'm trying to run xinit.exe to start a GUI program in a windows cmd
>>> prompt. The command I run:
>>>
>>> "c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe
>>> /home/Administrator/rdesktop.exe -f 192.168.1.79
>>>
>>> But, it seems that rdesktop.exe isn't running, the window was just
>>> showing a terminal prompt.
>>
>>
>> Using the command lines from the start menu items created for the xinit
>> package as a template (see [1]), I think you need something like:
>>
>> c:\cygwin\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit.exe
>> /home/Administrator/rdesktop.exe -f 192.168.1.79"
>>
>> The command string being given to bash -c needs quoting, otherwise
>> subsequent words are assumed to be parameters to that command.
>>
>> run needs to be given the -quote option to protect those quotes.
>>
>> [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args
>>
>> --
>> 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

Re: Proposal to use ThreadQuerySetWin32StartAddress inside munge_threadfunc (Cygwin randomly crashes on Wine)

[Corinna Vinschen]

On Oct 21 22:48, Qian Hong wrote:
> Hi Corinna,
> 
> On Wed, Oct 21, 2015 at 4:17 PM, Corinna Vinschen
>  wrote:
> > I simplified your patch, taking out the printf's and added a test in the
> > loop in case NtQueryInformationThread failed.  See below.  It's not
> > overly large, but it introduces new functionality.  It would be nice if
> > you could sign a copyright assignment and send it as PDF.  Please see
> > https://cygwin.com/assign.txt.
> 
> Thank you for the improvement!
> I sent an email with my signed pdf to ges-info AT redhat DOT com and
> CCed corinna-cygwin AT cygwin DOT com, but it was rejected by
> corrina-cygwin AT cygwin DOT com, did I miss anything?

All is well, patch applied.


Thanks,
Corinna

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


pgpdFhIz24H59.pgp
Description: PGP signature

[newlib-cygwin] Check for correct funtion entry address in munge_threadfunc

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ff3c4a7d2fd686543140b0d39177c3464d1444e1

commit ff3c4a7d2fd686543140b0d39177c3464d1444e1
Author: Qian Hong 
Date:   Thu Oct 29 09:17:46 2015 +0100

Check for correct funtion entry address in munge_threadfunc

* init.cc (munge_threadfunc): Check that we're actually replacing
the correct original function address on the stack.
* ntdll.h (enum _THREADINFOCLASS): Add ThreadQuerySetWin32StartAddress.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/ChangeLog | 6 ++
 winsup/cygwin/init.cc   | 9 +++--
 winsup/cygwin/ntdll.h   | 3 ++-
 winsup/cygwin/release/2.3.0 | 3 +++
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index afbe7a2..337a1d2 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,9 @@
+2015-10-29  Qian Hong  
+
+   * init.cc (munge_threadfunc): Check that we're actually replacing
+   the correct original function address on the stack.
+   * ntdll.h (enum _THREADINFOCLASS): Add ThreadQuerySetWin32StartAddress.
+
 2015-08-21  Jon Turney  
 
* cygwin-cxx.h: Remove execute permissions.
diff --git a/winsup/cygwin/init.cc b/winsup/cygwin/init.cc
index 56d4668..69e66a0 100644
--- a/winsup/cygwin/init.cc
+++ b/winsup/cygwin/init.cc
@@ -55,12 +55,17 @@ munge_threadfunc ()
 
   if (threadfunc_ix[0])
 {
-  char *threadfunc = ebp[threadfunc_ix[0]];
+  char *threadfunc = NULL;
+
+  NtQueryInformationThread (NtCurrentThread (),
+   ThreadQuerySetWin32StartAddress,
+   , sizeof threadfunc, NULL);
   if (!search_for || threadfunc == search_for)
{
  search_for = NULL;
  for (i = 0; threadfunc_ix[i]; i++)
-   ebp[threadfunc_ix[i]] = (char *) threadfunc_fe;
+   if (!threadfunc || ebp[threadfunc_ix[i]] == threadfunc)
+  ebp[threadfunc_ix[i]] = (char *) threadfunc_fe;
  TlsSetValue (_my_oldfunc, threadfunc);
}
 }
diff --git a/winsup/cygwin/ntdll.h b/winsup/cygwin/ntdll.h
index 13a131d..050e848 100644
--- a/winsup/cygwin/ntdll.h
+++ b/winsup/cygwin/ntdll.h
@@ -1162,7 +1162,8 @@ typedef enum _THREADINFOCLASS
 {
   ThreadBasicInformation = 0,
   ThreadTimes = 1,
-  ThreadImpersonationToken = 5
+  ThreadImpersonationToken = 5,
+  ThreadQuerySetWin32StartAddress = 9
 } THREADINFOCLASS, *PTHREADINFOCLASS;
 
 /* Checked on 64 bit. */
diff --git a/winsup/cygwin/release/2.3.0 b/winsup/cygwin/release/2.3.0
index 9a44bab..c6f70aa 100644
--- a/winsup/cygwin/release/2.3.0
+++ b/winsup/cygwin/release/2.3.0
@@ -50,3 +50,6 @@ Bug Fixes
 
 - Avoid SEGV when handling SIDs with 0 subauthorities.
   Addresses: https://cygwin.com/ml/cygwin/2015-10/msg00141.html
+
+- Fix a potential SEGV on (at least) Wine.
+  Addresses: https://cygwin.com/ml/cygwin/2015-10/msg00018.html

Re: initial cygwin installation

[Achim Gratz]

Am 28.10.2015 um 21:38 schrieb Duncan Roe:

As it happens, I also saw that message last night. I only wanted to *reinstall*
everything I had installed previously, owing to AVG antivirus having deleted I
don't know what.


One way to do that (if you really want to re-install instead of running 
cygcheck and just re-install those packages listed as incomplete) is to 
edit /etc/setup/installed.db so that each package version listed there 
is "outdated".  The next time you run setup it will upgrade everything, 
which is thre re-install you want.


sed -re 's/( [a-zA-Z].*-.*-)[0-9]+\./\10./' \
 -i.bak /etc/setup/installed.db

--
Achim.

(on the road :-)


--
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: Permissions on /var

[Corinna Vinschen]

On Oct 28 18:00, Jan Bruun Andersen wrote:
> Looks good. No errors are reported on my end now.

Thanks for testing.


Corinna

> 
> On 28 October 2015 at 14:28, Corinna Vinschen  
> wrote:
> > On Oct 28 01:33, Jan Bruun Andersen wrote:
> >> Today, as I installed inetutils (I needed telnet for Cygwin; telnet
> >> for Windows 10 does nothing; no error, no nothing) I got an error from
> >> setup-084_64. The error message directed me to look at
> >> /var/log/setup.log.full. Here is the relevant part, very near the end:
> >> [...]
> >> I tracked the check down to a function in
> >> /usr/share/csih/cygwin-service-installation-helper.sh. It checks the
> >> permissions with a call to function csih_check_dir_perms which ends up
> >> doing this:
> >
> > I just (belatedly) released a new version of the csih package, 0.9.9-1,
> > which is supposed to fix this installation problem.
> >
> >
> > HTH,
> > Corinna

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


pgpFQbjRhKiiP.pgp
Description: PGP signature

Re: Bash unable to print epoch timestamp

[Corinna Vinschen]

On Oct 28 17:20, Brian Inglis wrote:
> Corinna Vinschen  cygwin.com> writes:
> > On Oct 26 19:16, Brian Inglis wrote:
> > > Sorry - redo with the file existing!
> > 
> > No worries, I applied your other patch since it also cleaned up some
> > whitespaces and, for some reason, the below patch didn't apply cleanly.
> 
> Email paste may have converted tabs to spaces - need to work out how to
> email inline text attachments without tab expansion in tbird - paste on
> gmane (below) seems to retain tabs - may try that in future. 
> 
> > There was just one problem:
> > 
> > > +   {
> > > + long offset;/* offset < 0 => W of GMT, > 0 => E of GMT:
> > > + offset = 0;subtract to get UTC */
> > 
> > This setting the offset to 0 is necessary, but commented out.  Typo?
> > I fixed this before committing the patch.
> 
> Thanks - total brain fart - Doh! Interesting that gcc -Wall -Wextra did not
> catch this - used to be reliable warning about conditionally uninitialized
> variables! 
> 
> Please check that the second set of tests in Vec1 includes the following, as
> it was not in my very first patch email, which you may not have received: 
> @@ -1502,6 +1575,7 @@ const struct test  Vec1[] = {
>   { CQ("%p"), 2+1, EXP(CQ("PM")) },
>   { CQ("%r"), 11+1, EXP(CQ("11:01:13 PM")) },
>   { CQ("%R"), 5+1, EXP(CQ("23:01")) },
> + { CQ("%s"), 2+1, EXP(CQ("1215054073")) },
>   { CQ("%S"), 2+1, EXP(CQ("13")) },
>   { CQ("%t"), 1+1, EXP(CQ("\t")) },
>   { CQ("%T"), 8+1, EXP(CQ("23:01:13")) },

Check.  This was in your patch so it's upstream now.


Thanks,
Corinna

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


pgpJ2Uo9Z5615.pgp
Description: PGP signature

Re: Bug in collation functions?

[Corinna Vinschen]

On Oct 29 08:50, Corinna Vinschen wrote:
> On Oct 28 21:58, Eric Blake wrote:
> > On 10/28/2015 04:14 PM, Ken Brown wrote:
> > > It's my understanding that collation is supposed to take whitespace and
> > > punctuation into account in the POSIX locale but not in other locales.
> > 
> > Not quite right. It is up to the locale definition whether whitespace
> > affects collation.  But you are correct that in the POSIX locale,
> > whitespace must not be ignored in collation.
> > 
> > > This doesn't seem to be the case on Cygwin.  Here's a test case using
> > > wcscoll, but the same problem occurs with strcoll.
> > 
> > That's because the locale definitions are different in cygwin than they
> > are in glibc.  But it is not a bug in Cygwin; POSIX allows for different
> > systems to have different locale definitions while still using the same
> > locale name like en_US.UTF-8.
> 
> Btw, strcoll and wcscoll in Cygwin are implemented using the Windows
> function CompareStringW with the LCID set to the locale matching the
> POSIX locale setting.  I'm rather glad I didn't have to implement this
> by myself... :}

OTOH, CompareString has a couple of flags to control its behaviour, see
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx

Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there
are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS.  I'm open to a
discussion how to change the settings to more closely resemble the rules
on Linux.

E.g.  wcscoll simply calls wcscmp rather than CompareStringW for the
C/POSIX locale anyway.  So, would it makes sense to set the flags to
NORM_IGNORESYMBOLS in other locales?


Corinna

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


pgpBBoG4l1oGB.pgp
Description: PGP signature

How to run xinit without first entering a cygwin terminal

[Xuehan Xu]

Hi, everyone

I'm trying to run xinit.exe to start a GUI program in a windows cmd
prompt. The command I run:

"c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe
/home/Administrator/rdesktop.exe -f 192.168.1.79

But, it seems that rdesktop.exe isn't running, the window was just
showing a terminal prompt.

I also tried to run startx script through command like the following:
"c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startx"

But the X window cannot start, it failed after prompting several error box.

What should I do? Thanks:-)

--
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: Bug in collation functions?

[Corinna Vinschen]

On Oct 28 21:58, Eric Blake wrote:
> On 10/28/2015 04:14 PM, Ken Brown wrote:
> > It's my understanding that collation is supposed to take whitespace and
> > punctuation into account in the POSIX locale but not in other locales.
> 
> Not quite right. It is up to the locale definition whether whitespace
> affects collation.  But you are correct that in the POSIX locale,
> whitespace must not be ignored in collation.
> 
> > This doesn't seem to be the case on Cygwin.  Here's a test case using
> > wcscoll, but the same problem occurs with strcoll.
> 
> That's because the locale definitions are different in cygwin than they
> are in glibc.  But it is not a bug in Cygwin; POSIX allows for different
> systems to have different locale definitions while still using the same
> locale name like en_US.UTF-8.

Btw, strcoll and wcscoll in Cygwin are implemented using the Windows
function CompareStringW with the LCID set to the locale matching the
POSIX locale setting.  I'm rather glad I didn't have to implement this
by myself... :}


Corinna

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


pgpBeyjJoQCfN.pgp
Description: PGP signature

Re: [ITA] cygutils

[Corinna Vinschen]

On Oct 28 19:04, Andrew Schulman wrote:
> >  Corinna is climbing down the vaults to polish goldstars...
> > >>>
> > >>> Awarded!  http://cygwin.com/goldstars/#MG
> > >>
> > >> A bit early, this one ;)
> > >
> > > Oops
> > > Want me to add a stinkbomb to offset, until he makes good?
> > 
> > +1 motivational
> 
> I have the new icon ready to go

LOL.

I'd love to see the icon, but I really don't want to demotivate Mark :)


Corinna

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


pgpxH8p72bwmw.pgp
Description: PGP signature

Re: gcc: cannot find -lubsan

[Csaba Raduly]

On Wed, Oct 28, 2015 at 5:36 PM, Yaakov Selkowitz  wrote:
>
> The various sanitizers in recent versions of GCC are not currently
> supported on Cygwin.

Then it would be nicer if GCC reported an error (rather than compile
dozens of files and then fail to link them at the end).

This is likely a GCC issue (I don't know whether GCC can be
configured/built so it knows sanitizers are not supported).

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