Re: Unknown+User Unix_Group+505 on smb shares in a domian

2016-10-02 Thread Linda Walsh 

Wayne Porter wrote:

This is how it is currently set up. I can log in to the server via ssh
or use the current method, which is to map the network share using my
account credentials that they have set up for me. This works just fine
in Windows and for the most part in Cygwin. I can read/write from the
files but vim opens all files in read-only mode and I have to save using
:w!


I hate it when that happens!  ;-)

So the files you are trying to access are from your own local login on those
machines?

Is there a reason why the login you have on those machines is a machine-local
login?

I.e. I believe you said earlier, that the machines are joined to the domain.
Say your domainname="domain", and you have a domain login "wporter".  


Can you login (or can anyone login) using domain credentials to those linux
machines?  OR can you arrange to be able to, then copy your files on those
machines to your domain account.  


If the remote files are owned by you and you are logged into your domain
account on your usual cygwin machine, then the permissions should match.

There's alot of permissions/privileges on Windows that don't map to anything
on Linux or cygwin.  So while cygwin can compare the access rights in the
things it knows about, it can't begin to know about various windows permissions
and controls that might allow you to override the normal file-access controls.

If you can't login to the linux machines on your domain account, could
you get root access long enough to chown the files over to your domain
account?

If you can't login to the linux machines w/your dom account, authenticating
your login w/the domain server might not be enabled.  Might also have
to create home directory for your domain account manually.

If they need to setup login checks for domain logins on those
machines, they need to add some windbind rules to the 
/etc/pam.d/common-...  Just to give you an idea (they

should figure out the order by looking at relevant docs):


grep winbind /etc/pam.d/common*

/etc/pam.d/common-account:account sufficient pam_winbind.so
/etc/pam.d/common-auth:auth sufficient  pam_winbind.so
/etc/pam.d/common-password:password sufficient  pam_winbind.so
/etc/pam.d/common-session:session sufficient pam_winbind.so


--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-02 Thread Tony Kelman 
>> Still a problem in 14936. Folks, this could be very bad. Anyone at all
>> testing the insider builds, or are we going to be blindsided when an
>> update goes out to everyone that breaks cygwin?
>
> How about you start with a sane PATH that doesn#t contain all the
> Windows stuff?  Set a system variable CYGWIN_NOWINPATH=true and try
> again.

Didn't help. BTW, that remains undocumented, ref
https://cygwin.com/ml/cygwin/2014-08/msg00418.html

C:\cygwin64\bin>set CYGWIN_NOWINPATH=true

C:\cygwin64\bin>sh -l

Tony@LAPTOP-O230JCFF ~
$ cd github/curl

Tony@LAPTOP-O230JCFF ~/github/curl
$ rm -rf build && mkdir build && cd build

Tony@LAPTOP-O230JCFF ~/github/curl/build
$ cmake .. && make -j4 && echo ok
-- The C compiler identification is GNU 5.4.0
CMake Warning at /usr/share/cmake-3.6.2/Modules/Platform/CYGWIN.cmake:15 
(message):
  CMake no longer defines WIN32 on Cygwin!

  (1) If you are just trying to build this project, ignore this warning or
  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
  the CMake cache.  If later configuration or build errors occur then this
  project may have been written under the assumption that Cygwin is WIN32.
  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.

  (2) If you are developing this project, add the line

set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required

  at the top of your top-level CMakeLists.txt file or set the minimum
  required version of CMake to 2.8.4 or higher.  Then teach your project to
  build on Cygwin without WIN32.
Call Stack (most recent call first):
  /usr/share/cmake-3.6.2/Modules/CMakeSystemSpecificInformation.cmake:36 
(include)
  CMakeLists.txt:47 (project)


-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
CMake Warning at CMakeLists.txt:49 (message):
  the curl cmake build system is poorly maintained.  Be aware


-- curl version=[7.51.0-DEV]
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_ADDR
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_ADDR - Success
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID - Success
Found *nroff option: -- -man
-- Looking for dlopen in dl;
-- Looking for dlopen in dl; - found
-- Looking for connect in socket;dl
-- Looking for connect in socket;dl - not found
-- Looking for gethostbyname in c
-- Looking for gethostbyname in c - found
-- Looking for gethostname
-- Looking for gethostname - found
  0 [main] cmake 1280 child_info_fork::abort: 
C:\cygwin64\bin\cygintl-8.dll: Loaded to different address: parent(0x3E368) 
!= child(0xC)

[1]+  Stopped(SIGSTOP)cmake ..




> Something occupies the heap area for Cygwin, based on the low address.
> What does /proc/self/maps tell you?


$ cat /proc/self/maps
0001-0002 rw-s  : 0   [win heap 1 
default shared]
0002-00021000 rw-s  : 0
0003-00048000 r--s  : 0
0005-00054000 r--s  : 0
0006-00061000 r--s  : 0
0007-00072000 rw-p  : 0
0009-00099000 rw-p  : 0   [win heap 0 
default grow]
00099000-0019 ===p 9000 : 0   [win heap 0 
default grow]
0019-00191000 rw-p  : 0   [win heap 0 
default grow]
00191000-001C2000 ===p 1000 : 0   [win heap 0 
default grow]
0020-00352000 ===p  : 0
00352000-00353000 rw-p 00152000 : 0   [peb]
00353000-00355000 rw-p 00153000 : 0   [teb (tid 7204)]
00355000-00357000 rw-p 00155000 : 0   [teb (tid 7552)]
00357000-00359000 rw-p 00157000 : 0   [teb (tid 7648)]
00359000-0035B000 rw-p 00159000 : 0   [teb (tid 10468)]
0035B000-0035D000 rw-p 0015B000 : 0   [teb (tid 3876)]
0035D000-0040 ===p 0015D000 : 0
0060-006C1000 r--s  C225:5FBC 1407374885978955
/cygdrive/c/Windows/System32/locale.nls
006D-008CB000 ===p  : 0   [stack (tid 7552)]
008CB000-008CE000 rw-g 001FB000 : 0   [stack (tid 7552)]
008CE000-008D rw-p 001FE000 : 0   [stack (tid 7552)]
008D-00ACB000 ===p  : 0   [stack (tid 7648)]
00ACB000-00ACE000 rw-g 001FB000 : 0   [stack (tid 7648)]
00ACE000-00AD rw-p 001FE000 : 0   [stack (tid 7648)]
00AD-00CCB000 ===p  : 0   [stack (tid 
10468)]
00CCB000-00CCE000 rw-g 001FB000 : 0   [stack (tid 
10468)]
00CCE000-00CD rw-p 001FE000 : 0   [stack

Re: Unknown+User Unix_Group+505 on smb shares in a domian

2016-10-02 Thread Wayne Porter 
On Sun, Oct 02, 2016 at 04:43:42PM -0700, Linda Walsh wrote:
> Wayne Porter wrote:
> > >   Essentially you have a bunch of users on different machines that aren't
> > > sharing their files under any common (or shared) security authority
> > > (like a single domain).  Until you persuade the owners of those linux 
> > > machines
> > > to move the linux machines under a common security authority (like a 
> > > windows
> > > domain) and moving the user accounts into the domain.  Each local account
> > > would have to be moved to a domain account with the files under each
> > > machine-local account being moved (or "chown'ed") to the new, 
> > > corresponding
> > > domain account).
> > 
> > The shares are mapped and working just fine in Windows. To IT, there isn't
> > anything that needs to be done. It just happens that Cygwin, which I'm the 
> > only
> > one using, maps the Windows mapped drives to an unknown user account and 
> > makes
> > using it difficult.
> ---
>   Working in windows where?  What does "working just fine in Windows" 
> mean?
> That people in explorer on your machine have read+write access to the 
> linux-shares?
> 
>   Or do you have domain access to the machines running Windows?
> Are those machine in your Domain or are they outside your domain like the 
> linux
> machines?
> 

If I open the W:\ drive in Windows, I have full read/write access. This
is established via NET USE commands at boot. Then when I open Cygwin and
navigate to the same location, which has been mapped by Cygwin to
/cygdrive/w/ the user permissions appear as in my first email. Even
though it says I have read-only access, I have full read/write ability.

> 
> > 
> > >   This is an organizational problem that has nothing to do with
> > > cygwin, but whether windows and linux machines are using domain or 
> > > machine-local
> > > security.  Until your linux machines and their local user become part of 
> > > the
> > > domain, you can't expect any "write" privileges granted to you under the
> > > domain to work on the linux machines.
> > > 
> > 
> > I have write permissions on those machines from Windows. Cygwin thinks I 
> > don't so
> > files are opened in read-only mode but when I force them to be written, it 
> > works.
> > I'm not sure if maybe I left this out of my initial information, but these 
> > are
> > shares that are mapped in Windows on login and there are no issues there, 
> > but once
> > I open Cygwin, I don't appear to have write access even though I do.
> ---
>   If you have write access, then you are saying the permission are not 
> displaying
> properly in Cygwin.  So do you have the same, *actual* access in Cygwin as
> windows (ignoring what permissions may be displayed)?  It could be that you
> have domain-admin
> access and are overriding listed permissions on remote machines.  If it's the 
> case
> that your user doesn't have R+W access, but you are a domain admin, you might 
> just
> be overriding the write-restrictions in windows as well as cygwin.
> 

Yes, I have the same permissions, Cygwin is just displaying the wrong
thing.

> 
> 
> > When mapping the drives in Windows, a username and password are given. Is 
> > there no
> > way to let Cygwin know about that username without joining the servers to 
> > the domain?
> > I know that this setup isn't ideal, which is why I'm trying to find a 
> > work-around.
> ---
>   Bingo!  You need to try something like
> "runas [alternate credentials + alternate password] net use W: ..."
> 
> That might work... but is really icky, since you can't easily automate that
> without storing the password in clear-text in some file in your profile... 
> that's
> not a good solution.
> 

There are many things currently wrong with our setup and passwords in
clear-text wouldn't be anything out of the ordinary, I'm afraid. The
script that maps these shares with NET USE already have them in it and
load on boot, so I just need to adjust them to use "runas" instead of
the current way, which is just to specify the username and password in
the command? If you look at the info I provided in my first message, the
NET USE script I use is there, with the username and passwords redacted.


signature.asc
Description: PGP signature

Re: Unknown+User Unix_Group+505 on smb shares in a domian

2016-10-02 Thread Wayne Porter 
On Sun, Oct 02, 2016 at 04:35:21PM -0700, Linda Walsh wrote:
> Wayne Porter wrote:
> > The server that the W: drive is mapped on is not using domain accounts. As 
> > far as I know,
> > all Linux servers we have are running local accounts. Is there something I 
> > can set in
> > my local /etc/passwd to convince Cygwin to map it to my user account?
> ---
>   Let me phrase this differently.
> 
>   The linux accounts that are not in your domain and are under
> private user-names, are NOT something that you have "write" permission to.
> It sounds like those users (users outside your domain -- and not within
> your administrative group) have allowed "anyone" to have read access, but
> it makes sense that they wouldn't trust "anonymous" (that's you, if you
> haven't authenticated against their machine).  You seem to be asking
> for access to files owned by people outside your group (or maybe outside
> your company, for that matter, it's not known).

This is correct, the linux machines have local accounts that I have
mapped to drive letters in Windows. They are my accounts set up with my
username and password and I have full read/write access to the folders
in question. Cygwin just thinks I have read-only access and when I
attempt to write to the files, I can.

> 
>   The Domain is a means to provide common trusted access to a group
> of people who have agreed to honor each others' permission settings.  Right
> now, the linux people are not in a common-trust group, so you can't force
> your wanted access upon them.
> 
>   Until you and their machines share a common security token (the Domain
> token), you can't have shared permission settings.
> 
>   Alternatively , you might be able to convince the linux people to
> give you an account on each linux machine, and use that login when attaching
> to a share on that linux machine -- but that would be a pain.  Certainly,
> if they agreed to use a common domain and shared things with other domain
> users, that would be easier, but until they agree to be in a common domain,
> you can't force your desired access upon them.
> 

This is how it is currently set up. I can log in to the server via ssh
or use the current method, which is to map the network share using my
account credentials that they have set up for me. This works just fine
in Windows and for the most part in Cygwin. I can read/write from the
files but vim opens all files in read-only mode and I have to save using
:w!



signature.asc
Description: PGP signature

Re: Unknown+User Unix_Group+505 on smb shares in a domian

2016-10-02 Thread Linda Walsh 

Wayne Porter wrote:

Essentially you have a bunch of users on different machines that aren't
sharing their files under any common (or shared) security authority
(like a single domain).  Until you persuade the owners of those linux machines
to move the linux machines under a common security authority (like a windows
domain) and moving the user accounts into the domain.  Each local account
would have to be moved to a domain account with the files under each
machine-local account being moved (or "chown'ed") to the new, corresponding
domain account).


The shares are mapped and working just fine in Windows. To IT, there isn't
anything that needs to be done. It just happens that Cygwin, which I'm the only
one using, maps the Windows mapped drives to an unknown user account and makes
using it difficult.

---
Working in windows where?  What does "working just fine in Windows" 
mean?
That people in explorer on your machine have read+write access to the 
linux-shares?

Or do you have domain access to the machines running Windows?
Are those machine in your Domain or are they outside your domain like the linux
machines?





This is an organizational problem that has nothing to do with
cygwin, but whether windows and linux machines are using domain or machine-local
security.  Until your linux machines and their local user become part of the
domain, you can't expect any "write" privileges granted to you under the
domain to work on the linux machines.



I have write permissions on those machines from Windows. Cygwin thinks I don't 
so
files are opened in read-only mode but when I force them to be written, it 
works.
I'm not sure if maybe I left this out of my initial information, but these are
shares that are mapped in Windows on login and there are no issues there, but 
once
I open Cygwin, I don't appear to have write access even though I do.

---
If you have write access, then you are saying the permission are not 
displaying
properly in Cygwin.  So do you have the same, *actual* access in Cygwin as windows 
(ignoring what permissions may be displayed)?  It could be that you have domain-admin

access and are overriding listed permissions on remote machines.  If it's the 
case
that your user doesn't have R+W access, but you are a domain admin, you might 
just
be overriding the write-restrictions in windows as well as cygwin.




When mapping the drives in Windows, a username and password are given. Is there 
no
way to let Cygwin know about that username without joining the servers to the 
domain?
I know that this setup isn't ideal, which is why I'm trying to find a 
work-around.

---
Bingo!  You need to try something like
"runas [alternate credentials + alternate password] net use W: ..."

That might work... but is really icky, since you can't easily automate that
without storing the password in clear-text in some file in your profile... 
that's
not a good solution.



--
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: Unknown+User Unix_Group+505 on smb shares in a domian

2016-10-02 Thread Linda Walsh 

Wayne Porter wrote:

The server that the W: drive is mapped on is not using domain accounts. As far 
as I know,
all Linux servers we have are running local accounts. Is there something I can 
set in
my local /etc/passwd to convince Cygwin to map it to my user account?

---
Let me phrase this differently.

The linux accounts that are not in your domain and are under
private user-names, are NOT something that you have "write" permission to.
It sounds like those users (users outside your domain -- and not within
your administrative group) have allowed "anyone" to have read access, but
it makes sense that they wouldn't trust "anonymous" (that's you, if you
haven't authenticated against their machine).  You seem to be asking
for access to files owned by people outside your group (or maybe 
outside your company, for that matter, it's not known).  


The Domain is a means to provide common trusted access to a group
of people who have agreed to honor each others' permission settings.  Right
now, the linux people are not in a common-trust group, so you can't force
your wanted access upon them.

Until you and their machines share a common security token (the Domain
token), you can't have shared permission settings.  


Alternatively , you might be able to convince the linux people to
give you an account on each linux machine, and use that login when attaching
to a share on that linux machine -- but that would be a pain.  Certainly,
if they agreed to use a common domain and shared things with other domain
users, that would be easier, but until they agree to be in a common domain,
you can't force your desired access upon them.


--
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: Native symlinks and setup.exe

2016-10-02 Thread Gene Pavlovsky 
Thorsten,

That's a great pointer. I've just investigated using the `flex`
package as an example.
Untarring flex-2.6.1-1.tar.xz, usr/bin/flex++ is extracted as a Cygwin
symlink to usr/bin/flex.exe.
If I create a native symlink to flex.exe, tar it all up to a new tar
archive, then extract it somewhere else, the native symlink is
extracted as native, as expected.

So, when installing, the type of symlinks doesn't honor the CYGWIN
option since they are just unpacked by tar as is.

The question I'm proposing now - should `tar` be modified to honor the
CYGWIN option and automatically convert symlinks when extracting, if
necessary?

--Gene

On 2 October 2016 at 14:00, Thorsten Kampe  wrote:
> * Gene Pavlovsky (Sat, 1 Oct 2016 18:52:47 +0300)
>>
>> I'm installing Cygwin 64-bit on a fresh Win 7 x64 installation.
>> Before running setup.exe I've set the system env var 
>> CYGWIN=winsymlinks:native
>> After that I ran setup-x86_64.exe and installed cygwin64.
>> The symlinks to .exe files in bin, created by setup, are not native
>> symlinks, they are cygwin symlinks. Apparently, setup doesn't honor
>> the winsymlinks:native CYGWIN option. Is that intended (why?) or a
>> bug?
>
> Setup does not create symlinks. That's either done by the postinstall
> scripts or the contents of the package are simply unpacked to the
> folder. So the answer to your question is: the symlinks are not
> created but copied, that's why.
>
> Thorsten
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem 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: svn_load_dirs-1.9.2-2

2016-10-02 Thread David Rothenberger 
CYGWIN CHANGES:
===
Fix compatibility with svn 1.9 as described

  https://cygwin.com/ml/cygwin/2016-09/msg00205.html

Thanks to David Stacey for the information.

DESCRIPTION:

svn_load_dirs is a Perl script designed to load a number of
directories into Subversion. This is useful if you have a number of
.zip's or tar.{Z,gz,bz2}'s for a particular package and want to load
them into Subversion.

CYGWIN NOTES:
=
svn_load_dirs used to be included in the subversion-tools package,
but has been broken out into a separate package as Subversion no
longer distributes the contributed tools.

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

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

Updated: svn_load_dirs-1.9.2-2

2016-10-02 Thread David Rothenberger 
CYGWIN CHANGES:
===
Fix compatibility with svn 1.9 as described

  https://cygwin.com/ml/cygwin/2016-09/msg00205.html

Thanks to David Stacey for the information.

DESCRIPTION:

svn_load_dirs is a Perl script designed to load a number of
directories into Subversion. This is useful if you have a number of
.zip's or tar.{Z,gz,bz2}'s for a particular package and want to load
them into Subversion.

CYGWIN NOTES:
=
svn_load_dirs used to be included in the subversion-tools package,
but has been broken out into a separate package as Subversion no
longer distributes the contributed tools.

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.

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

Re: Native symlinks and setup.exe

2016-10-02 Thread Andrey Repin 
Greetings, Gene Pavlovsky!

> I'm installing Cygwin 64-bit on a fresh Win 7 x64 installation.
> Before running setup.exe I've set the system env var CYGWIN=winsymlinks:native
> After that I ran setup-x86_64.exe and installed cygwin64.
> The symlinks to .exe files in bin, created by setup, are not native
> symlinks, they are cygwin symlinks. Apparently, setup doesn't honor
> the winsymlinks:native CYGWIN option. Is that intended (why?) or a
> bug?

If your user is a member of Administrators group, you'd have to run setup in
privileged mode to even have a chance for that ability to actually work.
If not, you may control it with SeCreateSymlink privilege.


-- 
With best regards,
Andrey Repin
Sunday, October 2, 2016 21:22:34

Sorry for my terrible english...


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

[ANNOUNCEMENT] Updated: Onigurama 6.1.1-1

2016-10-02 Thread Marco Atzeri 

Versions 6.1.1-1 of
  onig  (source only)
  libonig4  (API bump)
  liboning-devel
have been uploaded.


DESCRIPTION
Oniguruma is a regular expressions library.
The characteristics of this library is that different character encoding
for every regular expression object can be specified.
(supported APIs: GNU regex, POSIX and Oniguruma native)

Supported character encodings:
ASCII, UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE,
EUC-JP, EUC-TW, EUC-KR, EUC-CN,
Shift_JIS, Big5, GB18030, KOI8-R, CP1251,
ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5,
ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10,
ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16

CHANGES
New upstream version
https://github.com/kkos/oniguruma/releases

HOMEPAGE
https://github.com/kkos/oniguruma

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

Updated: Onigurama 6.1.1-1

2016-10-02 Thread Marco Atzeri 

Versions 6.1.1-1 of
  onig  (source only)
  libonig4  (API bump)
  liboning-devel
have been uploaded.


DESCRIPTION
Oniguruma is a regular expressions library.
The characteristics of this library is that different character encoding
for every regular expression object can be specified.
(supported APIs: GNU regex, POSIX and Oniguruma native)

Supported character encodings:
ASCII, UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE,
EUC-JP, EUC-TW, EUC-KR, EUC-CN,
Shift_JIS, Big5, GB18030, KOI8-R, CP1251,
ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5,
ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10,
ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16

CHANGES
New upstream version
https://github.com/kkos/oniguruma/releases

HOMEPAGE
https://github.com/kkos/oniguruma

Regards
Marco Atzeri

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

Re: c++0x and locale_t

2016-10-02 Thread Ken Brown 

On 10/1/2016 10:58 AM, Brian Inglis wrote:

On 2016-10-01 07:30, Ken Brown wrote:

I'm having an issue building icu, which boils down to the following
test case:
$ cat foo.cc
#include 
locale_t foo;
$ g++ -c --std=c++0x foo.cc
foo.cc:2:1: error: ‘locale_t’ does not name a type
 locale_t foo;
 ^
If I remove '--std=c++0x', the error goes away.  I know nothing about
C++ standards, so I don't know if this is expected behavior or if it
indicates a bug in Cygwin's headers.


For C POSIX locale_t support, you have to do one or both of:

#define _XOPEN_SOURCE   700
#define _POSIX_C_SOURCE 200809L

to support multiple dynamic C locales and related functions.
This may be done automatically if you use the default -std=gnu++03,
which may
have been the intent in ICU and original interpretation by g++.
g++ now interprets (and deprecates) c++0x to mean c++11.
You could try changing it to explicitly c++03 and see if it works,
without the
GNU extensions.
Otherwise you should change it to explicitly gnu++03, as c++0x is
deprecated,
and may be dropped; g++ also deprecates c++1y aka c++14 and c++1z which
may be
c++17, and their gnu++ counterparts.

I don't understand why ICU C++ would use C locales, when C is now trying
to add
a subset of features C++ has supported better, more flexibly in 
for
over a decade; see:

https://sourceforge.net/p/msys2/discussion/general/thread/23e1b5ce/

for a similar problem to yours, and the solution in standard C++; and:

http://stdcxx.apache.org/doc/stdlibug/24-3.html

for an explanation of the differences between C++ and C locales.

OTOH ICU comes from IBM, and may be more interested in consistency across
languages: how else can you explain C++ methods called createInstance?

But you may just be the packager, porter, and builder, so may be unable
to fix
the implementation.


Thanks for the information.  I've submitted a patch upstream.

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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-02 Thread Achim Gratz 
Tony Kelman writes:
>> Could you paste a complete sample of the error message so we can
>> determine where in the Cygwin code it's coming from?
>
> Still a problem in 14936. Folks, this could be very bad. Anyone at all
> testing the insider builds, or are we going to be blindsided when an
> update goes out to everyone that breaks cygwin?

How about you start with a sane PATH that doesn#t contain all the
Windows stuff?  Set a system variable CYGWIN_NOWINPATH=true and try
again.

> Here's one:
>
>   1 [main] cp (6432) C:\cygwin64\bin\cp.exe: *** fatal error - cygheap 
> base mismatch detected - 0x180302408/0xD92408.
> This problem is probably due to using incompatible versions of the
> cygwin DLL.

Something occupies the heap area for Cygwin, based on the low address.
What does /proc/self/maps tell you?

> And another:
>
>   0 [main] cmake 10384 child_info_fork::abort: 
> C:\cygwin64\bin\cygintl-8.dll: Loaded to different address: 
> parent(0x3E368) != child(0x19)

Again either an address collision or some BLODA intercepting the DLL,
check the memory maps to see what might be going on.


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

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

--
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 problem: no /home/

2016-10-02 Thread Achim Gratz 
Matthijs Nescio writes:
> I am using Windows 7. During the setup, the install has hung after it
> was finished, running some postinstall script for quite some time.

It seems you aborted setup or your log files are truncated.  Unless you
let it finish the postinstall phase, you can't expect Cygwin to work
correctly or at all.  That said, after over an hour it hasn't got very
far into the autorebase based on your logs, so I suspect that the same
effect that makes the invocation of ls take so long is at play, most
likely some sort of BLODA.  It seems the install itself went OK, so if
you can temporarily suspend your virus scanner or except the Cygwin
install directory from any real-time checking, that would probably
help.

> One of the links suggests to run cygcheck -csv; the results are copied
> below. It sais my PC has multiple cygwin1.dll files.
>
> -bash-4.3$ find /cygdrive/c/cygwin64 -name "cygwin1.dll"
> /cygdrive/c/cygwin64/bin/cygwin1.dll
> /cygdrive/c/cygwin64/usr/i686-pc-cygwin/sys-root/usr/bin/cygwin1.dll
> ./cygwin1.dll
> /cygdrive/c/cygwin64/bin/cygwin1.dll
> /cygdrive/c/cygwin64/usr/i686-pc-cygwin/sys-root/usr/bin/cygwin1.dll
> -bash-4.3$

Don't put "." in your PATH.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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: Native symlinks and setup.exe

2016-10-02 Thread Thorsten Kampe 
* Gene Pavlovsky (Sat, 1 Oct 2016 18:52:47 +0300)
> 
> I'm installing Cygwin 64-bit on a fresh Win 7 x64 installation.
> Before running setup.exe I've set the system env var CYGWIN=winsymlinks:native
> After that I ran setup-x86_64.exe and installed cygwin64.
> The symlinks to .exe files in bin, created by setup, are not native
> symlinks, they are cygwin symlinks. Apparently, setup doesn't honor
> the winsymlinks:native CYGWIN option. Is that intended (why?) or a
> bug?

Setup does not create symlinks. That's either done by the postinstall 
scripts or the contents of the package are simply unpacked to the 
folder. So the answer to your question is: the symlinks are not 
created but copied, that's why.

Thorsten


--
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: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

2016-10-02 Thread Thomas Wolff 

Am 31.08.2016 um 15:58 schrieb Corinna Vinschen:

Hi folks,


I uploaded a new Cygwin release 2.6.0-1.

...
Somehow the way to setup the default locale has changed; raising 
problems as described in 
https://cygwin.com/ml/cygwin/2016-10/msg0.html .
This affects also bash (without -l). It is "healed" per /etc/profile. 
However, in all previous versions since 1.7 UTF-8 was the official 
default deployed from the cygwin DLL already, so calling cygwin apps 
from a Windows command line would work as expected, which is a valid use 
case. I don't think this change was on purpose.



- Support for POSIX-1.2008 locale objects and per-thread locales.

Maybe it slipped in here?
Thomas

--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-02 Thread Tony Kelman 
> You've got two different cygwin1.dll somewhere on your PATH.

For more information, I have one cygwin64 installation on C:, one
cygwin32 installation on E:, and they're never both on my path at
the same time. I'm not sure where that orphan registry entry that was
showing up in cygcheck.out came from, but I removed it and it made no
difference.

This is absolutely due to a change in Windows itself. 3 updates in
a row now, 14926, 14931, and now 14936, it's 100% reproducible just
from updating Windows. Downgrading to build 14915 gets everything back
working again, but that build is now expired so the only way for me to
get back to a supported build of Windows where cygwin works properly
is by totally reinstalling Windows. I haven't done that yet, but if
we can't identify the problem and a solution soon, I will have to.


--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-02 Thread Tony Kelman 
> You've got two different cygwin1.dll somewhere on your PATH. As your builds 
> proceed, they likely start out using the correct cygwin1.dll but sometimes 
> load 
> the wrong cygwin1.dll along the way. The error message tells you how to solve 
> the problem. But I usually use this method:
>  - open a Command Prompt running as Administrator
>  - cd c:\ or wherever the root of your Cygwin installation drive is
>  - dir /S cygwin1.dll
> You might see multiple listings of the same cygwin1.dll due to the crazy WoW 
> support but these will all have the same date and size. You want to find the 
> cygwin1.dll that has a different date (probably older) and size. That's the 
> problematic one; rename it or delete it.

And if not?

C:\>dir /S cygwin1.dll
 Volume in drive C is Windows
 Volume Serial Number is C225-5FBC

 Directory of C:\cygwin64\bin

08/31/2016  05:32 AM 3,306,962 cygwin1.dll
   1 File(s)  3,306,962 bytes

 Total Files Listed:
   1 File(s)  3,306,962 bytes
   0 Dir(s)  58,480,676,864 bytes free

C:\>


--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-02 Thread Mark Geisert 

Tony Kelman wrote:

Could you paste a complete sample of the error message so we can
determine where in the Cygwin code it's coming from?


Still a problem in 14936. Folks, this could be very bad. Anyone at all
testing the insider builds, or are we going to be blindsided when an
update goes out to everyone that breaks cygwin?

Here's one:

   1 [main] cp (6432) C:\cygwin64\bin\cp.exe: *** fatal error - cygheap base

 mismatch detected - 0x180302408/0xD92408.

This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.


OK, you're seeing two different problems. Solving the one above is critical. It 
might help solve the other problem shown below; we'll have to see.


You've got two different cygwin1.dll somewhere on your PATH. As your builds 
proceed, they likely start out using the correct cygwin1.dll but sometimes load 
the wrong cygwin1.dll along the way. The error message tells you how to solve 
the problem. But I usually use this method:

- open a Command Prompt running as Administrator
- cd c:\ or wherever the root of your Cygwin installation drive is
- dir /S cygwin1.dll
You might see multiple listings of the same cygwin1.dll due to the crazy WoW 
support but these will all have the same date and size. You want to find the 
cygwin1.dll that has a different date (probably older) and size. That's the 
problematic one; rename it or delete it.


Then try running your build again.




And another:

   0 [main] cmake 10384 child_info_fork::abort: 
C:\cygwin64\bin\cygintl-8.dll:

 Loaded to different address: parent(0x3E368) != child(0x19)

This is a garden-variety fork() failure due to the child having something in its 
address space at 0x3E368 such that Cygwin can't load cygintl-8.dll at that 
address where the parent has it. But since you've apparently got two Cygwin 
installations on your PATH, maybe that's complicating things. See if fixing the 
first problem above makes this problem go away too.


..mark

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

Re: Cygwin 2.6.0: unreadable UTF-8 in Windows console

2016-10-02 Thread Ivan Vanyushkin 
I want to share binary built under Cygwin 2.6.0 with other user, that has no 
LANG set.
In previous version all binaries worked correctly with UTF-8 input text.
But now this doesn't work as expected.

Some more simple tests.

// Run Windows console.
cmd

C:\Cygwin_2.6.0\bin\echo ±5°
▒▒5▒▒

C:\Cygwin_2.6.0\bin\echo ±5°|C:\Cygwin_2.6.0\bin\grep .
▒▒5▒▒
// Bad in Cywgin 2.6.0. Maybe this is UTF-8? See below.

// Now try in previous version.
C:\Cygwin_2.5.2\bin\echo ±5°
±5°

C:\Cygwin_2.5.2\bin\echo ±5°|C:\Cygwin_2.5.2\bin\grep .
±5°
// Good in Cygwin 2.5.2.


// Looks like changing console to UTF-8 codepage may fix the issue?
chcp 65001
Active code page: 65001

C:\Cygwin_2.6.0\bin\echo ±5°
▒▒5▒▒

C:\Cygwin_2.6.0\bin\echo ±5°|C:\Cygwin_2.6.0\bin\grep .
▒▒5▒▒

echo ±5°
±5°

echo ±5°|C:\Cygwin_2.6.0\bin\grep .
▒▒5▒▒
// Bad in Cygwin 2.6.0. Seems this is not UTF-8, just broken text.

// Now try in previous version.
C:\Cygwin_2.5.2\bin\echo ±5°
±5°

C:\Cygwin_2.5.2\bin\echo ±5°|C:\Cygwin_2.5.2\bin\grep .
±5°

echo ±5°
±5°

echo ±5°|C:\Cygwin_2.5.2\bin\grep .
±5°
// Works good in Cygwin 2.5.2 even with native "echo", because it produces 
UTF-8 now.


Sunday, October 2, 2016, 9:29:11 AM, you wrote:
> You don't have LANG set to "C.UTF-8". Do that.


--
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: Autotools support group, forum, mailing list, ???

2016-10-02 Thread Duncan Roe 
On Thu, Sep 22, 2016 at 06:13:07PM -0400, HiTech HiTouch wrote:
> Please forgive the somewhat off topic, but people who use Autotools and
> Mingw hang here and may be able to point me.
>
> I'm looking for a central place where people ask questions about Autotools
> (autoconf automake, etc.).  My google-ing finds (in addition to the manuals)
> only mailing list and blogs, all of which haven't had significant activity
> for years, like 2013, 2007, 2004. I find no BBS systems (forums) in use.
>
> The most questioners seem to be on the various stackexchange communities,
> pick one, pick many.
>
> Where should one go to ask questions, pray tell?
>
>
> PS:  I'm trying to build the tool chain for Arduino IDE by cross compiling.
> I am using MinGW 4.9.2 on WIndows XP SP3 32 bit to produce tools that run on
> native win32 (32 bit windows) and produce code for ARM.  I've been given the
> avr tool chain package produced using Autotools for my starting point.
>
> PPS: The Autotools anchor,
> https://www.gnu.org/software/autoconf/autoconf.html, has a bad pointer to
> its mailing list archive.  Letting google do the work, there is nothing in
> that last several years for XP, Windows, or win32 save for spam.
>
Hi HiTech,

Have you tried "info Automake" and "info Autoconf" on your installation?

They give you much more information than the man pages - automake even has a
"Hello World" example.

Cheers ... Duncan.

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

Re: Cygwin 2.6.0: unreadable UTF-8 in Windows console

2016-10-02 Thread Bengt Larsson 
Ivan Vanyushkin wrote:
>Something has changed in version 2.6.0, and now UTF-8 text can't be displayed 
>in Windows console (cmd).
>
>1. Create a file "test.txt" with non-ASCII text in UTF-8 encoding.
>2. Run "cmd".
>3. Run:
>
>C:\Cygwin\bin\cat test.txt
> ??  ?? 8000 ??.  
>?? ??.
>
>Non-ASCII text is not readable. Older Cygwin 2.5.2 has no such issue.
>
>C:\Cygwin\bin\uname -a
>CYGWIN_NT-10.0 PCName 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin
>
>C:\Cygwin\bin\locale
>LANG=
>LC_CTYPE="C.UTF-8"
>LC_NUMERIC="C.UTF-8"
>LC_TIME="C.UTF-8"
>LC_COLLATE="C.UTF-8"
>LC_MONETARY="C.UTF-8"
>LC_MESSAGES="C.UTF-8"
>LC_ALL=

You don't have LANG set to "C.UTF-8". Do that.

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

Re: Cygwin 2.6.0: unreadable UTF-8 in Windows console

2016-10-02 Thread Ivan Vanyushkin 
"set LANG=C.UTF-8" has fixed the issue on Cygwin 2.6.0. But documentation says 
[1], that
"The default locale in the absence of the aforementioned locale environment 
variables is "C.UTF-8"."
Seems this is broken in Cygwin 2.6.0.

"chcp 65001", console font or console charset doesn't matter here.

This is bad, because now I can't share compiled binaries to anyone, because 
users will have
no LANG in environment variable, and any non-ACSII text will not be readable.
For example, list running Windows services:
sc query | grep -i "running"
- will not work for not-English Windows, because output in console will not be 
readable.
Watch Windows log:
tail -f C:\Windows\Logs\SomeLog.log
- will be not readable if there are some non-English file names.

I think locale should remain default UTF-8, as in Cygwin 2.5.2. This is 
expected by both
applications and users.

Tests:

// Run Windows console.
cmd

C:\Cygwin_2.6.0\bin\echo ±5°> utf-8.txt

C:\Cygwin_2.6.0\bin\od -t x1z utf-8.txt
000 c2 b1 35 c2 b0 0d 0a >..5<
// We have UTF-8 now in "utf-8.txt" file.

C:\Cygwin_2.6.0\bin\locale
LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

C:\Cygwin_2.6.0\bin\cat utf-8.txt
▒▒5▒▒

C:\Cygwin_2.6.0\bin\env LANG=C.UTF-8 C:\Cygwin_2.6.0\bin\cat utf-8.txt
±5°
// Fixed! But what is default locale then?

C:\Cygwin_2.6.0\bin\env LANG=C.CP1251 C:\Cygwin_2.6.0\bin\cat utf-8.txt
В±5В°

C:\Cygwin_2.6.0\bin\env LANG=C.CP866 C:\Cygwin_2.6.0\bin\cat utf-8.txt
┬▒5┬░

C:\Cygwin_2.6.0\bin\env LANG=C.ISO8859-1 C:\Cygwin_2.6.0\bin\cat utf-8.txt
±5°
// Doesn't match. I have no idea what is default locale in Cygwin 2.6.0.

// Let's try console native encoding
echo ±5°> cp866.txt

C:\Cygwin_2.6.0\bin\od -t x1z cp866.txt
000 2b 35 f8 0d 0a   >+5...<

type cp866.txt
+5°

C:\Cygwin_2.6.0\bin\cat cp866.txt
+5▒
// Bad. Cygwin 2.6.0 can't display even non-UTF-8.


// Try filenames:
ls -al
lrwxrwxrwx  1 vanav▒▒   33 Sep 17 07:43 
''$'\320\234\320\276\320\270'' '$'\320\2
64\320\276\320\272\321\203\320\274\320\265\320\275\321\202\321\213' -> 
/cygdrive/c/Users/Vanav/Documents
// Bad.

C:\Cygwin_2.6.0\bin\env LANG=C.UTF-8 C:\Cygwin_2.6.0\bin\ls -al
lrwxrwxrwx  1 vanav  система 33 Sep 17 07:43 'Мои 
документы' -> /cygdrive/c/Users/Vanav/Documents
// Good.


// Now try previous Cygwin 2.5.2.
C:\Cygwin_2.5.2\bin\locale
LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

C:\Cygwin_2.5.2\bin\cat utf-8.txt
±5°
// Good.

C:\Cygwin_2.5.2\bin\env LANG=C.UTF-8 C:\Cygwin_2.5.2\bin\cat utf-8.txt
±5°
// Good.


[1] https://cygwin.com/cygwin-ug-net/setup-locale.html



Saturday, October 1, 2016, 8:15:02 AM, you wrote:

> On 2016-09-30 22:34, Brian Inglis wrote:
> Sorry - this was mintty - you used cmd!
> Saw similar problems you had until I set LC_ALL=C.UTF-8 (and LANG
> for consistency, but doesn't really matter) and chcp 65001.
> Then type and Cygwin commands produce the same output.
> Without CP65001 (and a Unicode console font mapping most characters
> - I use DejaVu Sans Mono everywhere I can) there may be no valid
> encoding for UTF-8 special characters in your default console CP
> (437 for US, 850 for non-US, others for localized versions).
> Unfortunately then less displays spaces as squares, so you may have
> to set PAGER=more for readability.



-- 
Best regards,
 Ivanmailto:va...@vanav.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