Re: [ANNOUNCEMENT] Updated: bash-4.3.42-3

[Mikhail Usenko]

On Fri, 11 Sep 2015 12:48:59 +
Nellis, Kenneth <...> wrote:

> FWIW, back in 2012 there was a discussion on this behavior of sed.
> Apparently strong enough arguments were made to retain this behavior.
> 
> http://sourceware.org/ml/cygwin/2012-02/msg00301.html
> 

Hello, Ken.
Thank you for the notice about that thread. I didn't know about it.
As far as I understand that conversation, Paolo Bonzini changed the default 
open mode from 'rt' to 'r'.
And as it can be observed from the sed's sources now there are to variants for 
the value of the
global variable that is used to set file open mode for all read operations: "r" 
by default and "rb"
if the -b command flag is set.

So there is no text mode forcing as it has been and it is up to the underlying 
Cygwin level
in which actual mode the file to be opened. I suppose a package maintainer can 
also choose
which specific Cygwin library the application can be linked against to set the 
default open modes for it.

We have a shell pipeline here (basically it is a pipe or a FIFO file) which is 
normally expected to be opened in binary mode (and according to Cygwin user's 
guide pipes, sockets and non-file devices are opened in binary mode). Therefore 
I think it looks like a bug.

-- 
Mike

--
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: Fonts reorganization and additions

[Ken Brown]

On 9/11/2015 7:21 AM, Ola Strömfors wrote:

The update gave the following error:

   Unable to extract
   /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20

   The File is in use or some other error occurred.

   Please stop all Cygwin processes and select "Retry", or select
   "Continue" to go on anyway (the file will be updated after a reboot).

and a similar message about the misc fonts.

- Reboot did not help
- After uninstalling the packages, creating the directory
   /etc/X11/fontpath.d and installing them again,


This looks like a packaging error.  Yaakov, shouldn't installing 
xorg-x11-fonts-* create /etc/X11/fontpath.d if it doesn't exist?  From



https://cygwin.com/cgi-bin2/package-grep.cgi?grep=etc%2FX11%2Ffontpath.d=x86_64

it appears that terminus-fonts is the only package that creates this 
directory.


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: svn1.9.1, segmentation fault when calling "svn diff -c .", on MS Windows7

[David Rothenberger]

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

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

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

Cygwin Subversion maintainer


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

Re: Fonts reorganization and additions

[Nem W Schlecht]

I got these new font packages and although I saw the announcement, the
two mirrors I've tried do not have the updated xorg-server yet
(although they both have these updated font packages).  Is there a way
to make a sub-version (1.17.2-4 for xorg-server, not 1.17.2-3 as is
listed below, contains the font path changes) a requirement?  Would
have saved me a little bit of a headache this morning as well.

On Fri, Sep 11, 2015 at 11:40 AM, Yaakov Selkowitz
 wrote:
> On Fri, 2015-09-11 at 12:29 -0400, Ken Brown wrote:
>> On 9/11/2015 7:21 AM, Ola Strömfors wrote:
>> > The update gave the following error:
>> >
>> >Unable to extract
>> >/etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20
>> >
>> >The File is in use or some other error occurred.
>> >
>> >Please stop all Cygwin processes and select "Retry", or select
>> >"Continue" to go on anyway (the file will be updated after a reboot).
>> >
>> > and a similar message about the misc fonts.
>> >
>> > - Reboot did not help
>> > - After uninstalling the packages, creating the directory
>> >/etc/X11/fontpath.d and installing them again,
>>
>> This looks like a packaging error.  Yaakov, shouldn't installing
>> xorg-x11-fonts-* create /etc/X11/fontpath.d if it doesn't exist?  From
>>
>> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=etc%2FX11%2Ffontpath.d=x86_64
>>
>> it appears that terminus-fonts is the only package that creates this
>> directory.
>
> They do already, and they show up in the search.
>
> --
> 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
>



-- 
Nem W Schlecht   n...@emptec.com
Empyreal Technologieshttp://www.emptec.com/
 "Perl did the magic.  I just waved the wand."

--
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] Fonts reorganization and additions

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* adobe-source-code-pro-fonts-1.017-2
* adobe-source-sans-pro-fonts-1.050-2
* adobe-source-serif-pro-fonts-1.017-1
* alef-fonts-1.0-2
* artwiz-aleczapka-fonts-1.3-2
* cantarell-fonts-0.0.16-2
* culmus-fonts-0.130-1
* dejavu-fonts-2.35-1
* gnu-free-fonts-20120503-2
* inconsolata-fonts-1.010-1
* kanjistrokeorders-fonts-3.001-1
* liberation-fonts-1.07.4-1
* linux-libertine-fonts-5.3.0-1
* overpass-fonts-2.0-1
* oxygen-fonts-5.3.2-2
* sj-fonts-2.0.2-2
* terminus-fonts-4.40-1
* unifont-fonts-8.0.01-1
* xorg-x11-fonts-cyrillic-7.5-1
* xorg-x11-fonts-ethiopic-7.5-1
* xorg-x11-fonts-dpi100-7.5-1
* xorg-x11-fonts-dpi75-7.5-1
* xorg-x11-fonts-misc-7.5-1
* xorg-x11-fonts-Type1-7.5-1

These packages have been renamed and reorganized for the new font layout
used by xorg-server-1.17.2-4, xfs-1.1.4-1, and tigervnc-server-1.5.0-1.
X11 core fonts are installed into /usr/share/X11/fonts with the
necessary symlinks into the X11 font catalogue.  Other fonts are
installed in their own directories under /usr/share/fonts, along with
configuration files in the requisite locations, for use with fontconfig.

--
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: [ANNOUNCEMENT] Fonts reorganization and additions

[Tobias Zawada]

Maybe, this is the reason why `emacs -q` gives the error message:

Font `-adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1' is not
defined

and exits after the update on 2015-09-11?

Starting with `emacs -Q` and loading personal initialization file afterwards is
the current workaround for me.

`cygcheck -s` output is listed below.

Best regards,

Tobias

> Yaakov Selkowitz  hat am 11. September 2015 um 11:05
> geschrieben:
> 
> The following packages have been uploaded to the Cygwin distribution:
> 
> * adobe-source-code-pro-fonts-1.017-2
> * adobe-source-sans-pro-fonts-1.050-2
> * adobe-source-serif-pro-fonts-1.017-1
> * alef-fonts-1.0-2
> * artwiz-aleczapka-fonts-1.3-2
> * cantarell-fonts-0.0.16-2
> * culmus-fonts-0.130-1
> * dejavu-fonts-2.35-1
> * gnu-free-fonts-20120503-2
> * inconsolata-fonts-1.010-1
> * kanjistrokeorders-fonts-3.001-1
> * liberation-fonts-1.07.4-1
> * linux-libertine-fonts-5.3.0-1
> * overpass-fonts-2.0-1
> * oxygen-fonts-5.3.2-2
> * sj-fonts-2.0.2-2
> * terminus-fonts-4.40-1
> * unifont-fonts-8.0.01-1
> * xorg-x11-fonts-cyrillic-7.5-1
> * xorg-x11-fonts-ethiopic-7.5-1
> * xorg-x11-fonts-dpi100-7.5-1
> * xorg-x11-fonts-dpi75-7.5-1
> * xorg-x11-fonts-misc-7.5-1
> * xorg-x11-fonts-Type1-7.5-1
> 
> These packages have been renamed and reorganized for the new font layout
> used by xorg-server-1.17.2-4, xfs-1.1.4-1, and tigervnc-server-1.5.0-1.
> X11 core fonts are installed into /usr/share/X11/fonts with the
> necessary symlinks into the X11 font catalogue. Other fonts are
> installed in their own directories under /usr/share/fonts, along with
> configuration files in the requisite locations, for use with fontconfig.
> 
> --
> 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

Cygwin Configuration Diagnostics
Current System Time: Fri Sep 11 11:13:41 2015

Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Path: C:\Users\Tobias.Zawada\bin
 C:\cygwin64\usr\local\bin
 C:\cygwin64\bin
 C:\ProgramData\Oracle\Java\javapath
 C:\Program Files (x86)\ImageMagick-6.8.8-Q16
 C:\Program Files\ImageMagick-6.7.8-Q16
 C:\Windows\system32
 C:\Windows
 C:\Windows\System32\Wbem
 C:\Windows\System32\WindowsPowerShell\v1.0
 C:\Program Files\GetDP
 C:\Program Files (x86)\gmsh
 C:\Program Files\MATLAB\MATLAB Compiler Runtime\v79\runtime\win64
 C:\Program Files\PTC\Creo Elements\Pro5.0\bin
 C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86
 C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64
 C:\Program Files (x86)\VisualSVN\bin
 C:\Program Files (x86)\Bazaar
 C:\Program Files\Microsoft SQL Server\110\Tools\Binn
 C:\Program Files (x86)\GNU\GnuPG\pub
 C:\Program Files\TortoiseSVN\bin
 C:\Program Files\TortoiseGit\bin
 C:\Program Files (x86)\QuickTime\QTSystem
 T:\Testmodels\libraries\NumenGo\bin\win32
 T:\Testmodels\libraries\NumenGo_newRepo_ask_SBR\bin\win64
 C:\Program Files\Microsoft\ Visual\ Studio\ 8\VC\bin\
 C:\Program Files\Microsoft\ Visual\ Studio\ 8\VC\lib\
 C:\cygwin64\usr\local\msbin
 C:\spice_win\bin
 C:\OpenModelica1.4.5\bin
 C:\cygwin64\lib\lapack

Output from C:\cygwin64\bin\id.exe
UID: 1051397(tobias.zawada)
GID: 1049089(Domänen-Benutzer)
=1049089(Domänen-Benutzer)
... truncated for data protection ...

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

LIBRARY_PATH = '/usr/local/lib:/cygdrive/c/Users/Tobias.Zawada/lib'
C_INCLUDE_PATH = '/usr/local/include:/cygdrive/c/Users/Tobias.Zawada/include'
PWD = '/usr/share/emacs/24.5'
CYGWIN = 'winsymlinks:lnk'
HOME = '/cygdrive/c/Users/Tobias.Zawada'

Use '-r' to scan registry

obcaseinsensitive set to 1

Cygwin installations found in the registry:
 System: Key: e022582115c10879 Path: c:\cygwin64
 User: Key: e022582115c10879 Path: C:\cygwin64

c: hd NTFS 228833Mb 93% CP CS UN PA FC CRUZER
d: cd N/A N/A 
e: hd NTFS 476939Mb 65% CP CS UN PA FC Thoshiba500
f: fd FAT32 30211Mb 18% CP UN HOME
n: net NTFS 2097021Mb 90% CP CS UN PA FC Data-1
s: net NTFS 3810230Mb 27% CP CS UN PA Data
t: net NTFS 2097021Mb 90% CP CS UN PA FC Data-1
x: net NTFS 703872Mb 82% CP CS UN PA FC DLO Device (D)
y: net NTFS 2097021Mb 90% CP CS UN PA FC Data-1
z: net NTFS 2097021Mb 90% CP CS UN PA FC Data-1

Warning: Mount entries should not have a trailing (back)slash

\\Rechner81\Platte_c /BuildRechner user binary,posix=0
t:\ /Test user binary,posix=0
c:\tmp /tmp user binary,posix=0
C:\cygwin64 / system binary,auto
C:\cygwin64\bin /usr/bin system binary,auto
C:\cygwin64\lib /usr/lib system binary,auto
cygdrive prefix /cygdrive user binary,noacl,posix=0,auto

Found: C:\cygwin64\bin\awk
 -> C:\cygwin64\bin\gawk.exe
Found: C:\cygwin64\bin\bash.exe
Found: C:\cygwin64\bin\cat.exe
Found: C:\cygwin64\bin\cp.exe
Found: C:\cygwin64\bin\cpp.exe
Not Found: crontab
Found: C:\cygwin64\bin\find.exe
Found: C:\Windows\system32\find.exe
Found: C:\cygwin64\bin\gcc.exe
Found: C:\cygwin64\bin\gdb.exe
Found: 

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Takashi Yano]

Hi Corinna,

Regarding the first problem:
> > a) Group permissions on root folders

On Sun, 6 Sep 2015 13:44:44 +0200
Corinna Vinschen wrote:
> The group permission problem is easy (and I'm wondering if it really was
> such a bright idea to let user SID == group SID slip through in Cygwin,
> rather tnan  sticking to the former idea to change the group SID to
> "Users" in this case).  csih needs a patch to not check for the group
> x bit if user SID == group SID.

Do you intend a patch like this? I have confirmed that sshd
is successfully installed and works nicely with this patch
under a Microsoft Account.

--- cygwin-service-installation-helper.sh.orig  2015-02-24 04:57:56.0 
+0900
+++ cygwin-service-installation-helper.sh   2015-09-11 18:41:56.870882800 
+0900
@@ -2442,6 +2442,8 @@
 # ==
 _csih_setup()
 {
+  local perms="d..x..x..[xt]"
+
   csih_stacktrace "${@}"
   $_csih_trace
   if [ "$_csih_setup_already_called" -eq 0 ]
@@ -2462,7 +2464,13 @@
   csih_error "Problem with LocalSystem or Adminstrator IDs"
 fi
 
-if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
+if [ `/usr/bin/stat -c '%g' ${LOCALSTATEDIR}` -eq \
+`/usr/bin/stat -c '%u' ${LOCALSTATEDIR}` ]
+then
+  perms="d..x.[xt]"
+fi
+
+if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
 then
   csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
 fi

-- 
Takashi Yano 

--
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: tigervnc-1.5.0-1

[Yaakov Selkowitz]

The following packages have been added to the Cygwin distribution:

* tigervnc-1.5.0-1
* tigervnc-server-1.5.0-1
* tigervnc-server-module-1.5.0-1

TigerVNC is a high-performance implementation of VNC, a client/server
application that allows users to launch and interact with graphical
applications on remote machines. TigerVNC provides the levels of
performance necessary to run 3D and video applications, and it attempts
to maintain a common look and feel and re-use components, where
possible, across the various platforms that it supports. TigerVNC also
provides extensions for advanced authentication methods and TLS
encryption. 

Please note that, like other Cygwin graphical applications, these
packages are X11-based.  That means the client requires a running X
server in order to start, and the server will allow accessing X programs
or even entire X sessions remotely but not your Windows desktop.

--
Yaakov

[ANNOUNCEMENT] New: tigervnc-1.5.0-1

[Yaakov Selkowitz]

The following packages have been added to the Cygwin distribution:

* tigervnc-1.5.0-1
* tigervnc-server-1.5.0-1
* tigervnc-server-module-1.5.0-1

TigerVNC is a high-performance implementation of VNC, a client/server
application that allows users to launch and interact with graphical
applications on remote machines. TigerVNC provides the levels of
performance necessary to run 3D and video applications, and it attempts
to maintain a common look and feel and re-use components, where
possible, across the various platforms that it supports. TigerVNC also
provides extensions for advanced authentication methods and TLS
encryption. 

Please note that, like other Cygwin graphical applications, these
packages are X11-based.  That means the client requires a running X
server in order to start, and the server will allow accessing X programs
or even entire X sessions remotely but not your Windows desktop.

--
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: svn1.9.1, segmentation fault when calling "svn diff -c .", on MS Windows7

[Wb Yang]

Thanks Dave,

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

2. Your recipe works fine here;

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

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

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

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

cwdstuff::get: error on dlfcn.cc:174 /home/corinna/src/...

[Chevallier Yves]

Hi, 

How can I send this bug report to corinna?

-Message d'origine-
De : Chevallier Yves 
Envoyé : vendredi 11 septembre 2015 11:28
À : 'corinna-cyg...@cygwin.com'
Objet : cwdstuff::get: error on dlfcn.cc:174 /home/corinna/src/...

Dear Corinna, 

I have found your name on a `strace` log when using `dlopen` on Python. Is it 
normal?

symlink.check(C:\Users\user\Home\projects\foo\my.dll, 0x28AB88) (0x4022)
   35 2705178 [main] python2.7 16924 path_conv::check: 
this->path(C:\Users\user\Home\projects\foo\my.dll), has_acls(1)
   37 2705215 [main] python2.7 16924 cwdstuff::get: posix 
/cygdrive/c/Users/user/Home/projects/foo
   32 2705247 [main] python2.7 16924 cwdstuff::get: 
(C:\Users\user\Home\projects\foo) = cwdstuff::get (0x8006ECF0, 32768, 0, 0), 
errno 11
--- Process 14376, exception c138 at 7726163E
 3286 2708533 [main] python2.7 16924 seterrno_from_win_error: 
/home/corinna/src/cygwin/cygwin-1.7.35/cygwin-1.7.35-1.i686/src/src/winsup/cygwin/dlfcn.cc:174
 windows error 182
   42 2708575 [main] python2.7 16924 geterrno_from_win_error: unknown windows 
error 182, setting errno to 13
   36 2708611 [main] python2.7 16924 dlopen: ret 0x0

Depending if I use `python` or `ipython` I get a different behavior for 
cwdstuff:get. I don't know how to investigate on this. 

Here below what I get from strace when it works: 

symlink.check(C:\Users\user\Home\projects\foo\my.dll, 0x28B728) (0x4022)
   26 10440048 [main] python 12604 path_conv::check: 
this->path(C:\Users\user\Home\projects\foo\my.dll), has_acls(1)
   23 10440071 [main] python 12604 cwdstuff::get: posix 
/cygdrive/c/Users/user/Home/projects/foo
   25 10440096 [main] python 12604 cwdstuff::get: 
(C:\Users\user\Home\projects\foo) = cwdstuff::get (0x8006ECF0, 32768, 0, 0), 
errno 0
 3405 10443501 [main] python 12604 dlopen: ret 0x5B9C   


Regards, 
Yves



--
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: XWin.exe not running any more.

[Thomas Schweikle]

Added that to every file one of the other exec where mentioned.
Doesn't help. X starts and stops immediately again:

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.17.2.0
OS: CYGWIN_NT-6.1 nc403-muc 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
Package: version 1.17.2-3 built 2015-08-25

XWin was started with the following command line:

/usr/bin/XWin -multiwindow -clipboard

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 1200
winInitializeScreenDefaults - native DPI x 96 y 96
[ 86193.937] (II) xorg.conf is not supported
[ 86193.937] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html
for more information
[ 86193.937] LoadPreferences: /cygdrive/c/Users/sct-muc.BFS/.XWinrc not found
[ 86193.937] LoadPreferences: Loading /etc/X11/system.XWinrc
[ 86193.937] LoadPreferences: Done parsing the configuration file...
[ 86193.937] winDetectSupportedEngines - DirectDraw4 installed,
allowing ShadowDDNL
[ 86193.937] winDetectSupportedEngines - Returning, supported engines 0005
[ 86193.937] winSetEngine - Multi Window or Rootless => ShadowGDI
[ 86193.937] winScreenInit - Using Windows display depth of 32 bits per pixel
[ 86193.953] winAllocateFBShadowGDI - Creating DIB with width: 1920
height: 1200 depth: 32
[ 86193.953] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[ 86193.953] winInitVisualsShadowGDI - Masks 00ff ff00
00ff BPRGB 8 d 24 bpp 32
[ 86193,953] MIT-SHM extension disabled due to lack of kernel support
[ 86193,953] XFree86-Bigfont extension local-client optimization
disabled due to lack of shared memory support in the kernel
[ 86193,968] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'

I am not sure if startxwin is at all used by XWin.exe ...!

2015-09-05 22:45 GMT+02:00 Chris Louden :
> add "exec sleep infinity" to ~/.startxwinrc
>
> -Chris
>
>
> On Sat, Sep 5, 2015 at 6:14 AM, Thomas Schweikle  wrote:
>> Hi!
>>
>> Since yesterday starting "XWin.exe -multiwindow -clipboard" starts,
>> but stops after short. It doesn't keep running and X11 is not usable.
>>
>> After starting I only see:
>> Welcome to the XWin X Server
>> Vendor: The Cygwin/X Project
>> Release: 1.17.2.0
>> OS: CYGWIN_NT-6.1 nc403-muc 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64
>> OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
>> Package: version 1.17.2-3 built 2015-08-25
>>
>> XWin was started with the following command line:
>>
>> /usr/bin/XWin -multiwindow -clipboard
>>
>> ddxProcessArgument - Initializing default screens
>> winInitializeScreenDefaults - primary monitor w 1920 h 1200
>> winInitializeScreenDefaults - native DPI x 96 y 96
>> [   134.862] (II) xorg.conf is not supported
>> [   134.862] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html
>> for more information
>> [   134.862] LoadPreferences: /cygdrive/c/Users/sct-muc.BFS/.XWinrc not found
>> [   135.830] LoadPreferences: Loading /etc/X11/system.XWinrc
>> [   135.830] LoadPreferences: Done parsing the configuration file...
>> [   135.830] winDetectSupportedEngines - DirectDraw4 installed,
>> allowing ShadowDDNL
>> [   135.830] winDetectSupportedEngines - Returning, supported engines 
>> 0005
>> [   135.830] winSetEngine - Multi Window or Rootless => ShadowGDI
>> [   135.830] winScreenInit - Using Windows display depth of 32 bits per pixel
>> [   136.906] winAllocateFBShadowGDI - Creating DIB with width: 1920
>> height: 1200 depth: 32
>> [   136.906] winFinishScreenInitFB - Masks: 00ff ff00 00ff
>> [   136.906] winInitVisualsShadowGDI - Masks 00ff ff00
>> 00ff BPRGB 8 d 24 bpp 32
>> [   137,062] MIT-SHM extension disabled due to lack of kernel support
>> [   137,062] XFree86-Bigfont extension local-client optimization
>> disabled due to lack of shared memory support in the kernel
>> [   137,093] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
>>
>> The tray-icon is displayed, but vanishes as soon you try to hover it.
>> XWin.exe is terminated.
>>
>> If I start XWin.exe without any options it opens a window and keeps
>> running. Same if I start it without "-multiwindow". Looks to me like
>> "-multiwindow" is broken. Any ideas?
>>
>> --
>> 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
>>
>
> --
> 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
>
>



-- 
Thomas

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

Re: bogus subversion prerequisites

[Andrew Schulman]

> A bunch of *-devel packages are listed in the "requires" field of the 
> subversion
> setup hint.

Please see https://cygwin.com/ml/cygwin/2015-09/msg00130.html.


--
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: Fonts reorganization and additions

[Yaakov Selkowitz]

On Fri, 2015-09-11 at 15:12 -0400, Ken Brown wrote:
> I was referring to the fact that for terminus-fonts we see

>  2015-09-10 19:57   0 etc/X11/
>  2015-09-10 19:57   0 etc/X11/fontpath.d/
>  2015-09-10 19:57   0 etc/X11/fontpath.d/terminus:unscaled -> 
> /usr/share/fonts/terminus
> 
> whereas for xorg-x11-fonts-dpi75 we see only
> 
>  2015-09-10 20:44   0 
> etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 -> 
> /usr/share/X11/fonts/75dpi
> 
> and similarly for the other xorg-x11-fonts-* packages.
>  
> I interpreted this as meaning that /etc/X11/fontpath.d wouldn't get created, 
> but 
> maybe I was wrong.

Generally, the leading directories aren't required, setup should be
creating all parent directories regardless.

> In any case, it apparently didn't get created for the OP, and I had the same 
> experience.  On the other hand, it gets created when I manually unpack the 
> tarball, so I don't know what's going on.

If you remove your /etc/X11/fontpath.d and just (re)install
xorg-x11-fonts-Type1, does this occur?  (It shouldn't.)

The first thing that should be checked is if the code in setup which
allows it to unpack files with "illegal" characters in Windows also
makes sure to create parent directories.  Based on these reports my
*guess* is it doesn't but I haven't looked yet.

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

bogus subversion prerequisites

[Peter Kozich (UPC)]

With reference to https://www.cygwin.com/ml/cygwin/2012-01/msg00058.html :

With subversion 1.9 the problem still persists.
A bunch of *-devel packages are listed in the "requires" field of the subversion
setup hint.
Wouldn't it be more appropriate to list those devel's only for the subversion
-devel package?

Peter

--
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: Fonts reorganization and additions

[Ken Brown]

On 9/11/2015 12:40 PM, Yaakov Selkowitz wrote:

On Fri, 2015-09-11 at 12:29 -0400, Ken Brown wrote:

On 9/11/2015 7:21 AM, Ola Strömfors wrote:

The update gave the following error:

Unable to extract
/etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20

The File is in use or some other error occurred.

Please stop all Cygwin processes and select "Retry", or select
"Continue" to go on anyway (the file will be updated after a reboot).

and a similar message about the misc fonts.

- Reboot did not help
- After uninstalling the packages, creating the directory
/etc/X11/fontpath.d and installing them again,


This looks like a packaging error.  Yaakov, shouldn't installing
xorg-x11-fonts-* create /etc/X11/fontpath.d if it doesn't exist?  From

https://cygwin.com/cgi-bin2/package-grep.cgi?grep=etc%2FX11%2Ffontpath.d=x86_64

it appears that terminus-fonts is the only package that creates this
directory.


They do already, and they show up in the search.


I was referring to the fact that for terminus-fonts we see

2015-09-10 19:57   0 etc/
[...]
2015-09-10 19:57   0 etc/X11/
2015-09-10 19:57   0 etc/X11/fontpath.d/
2015-09-10 19:57   0 etc/X11/fontpath.d/terminus:unscaled -> 
/usr/share/fonts/terminus


whereas for xorg-x11-fonts-dpi75 we see only

2015-09-10 20:44   0 
etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 -> 
/usr/share/X11/fonts/75dpi


and similarly for the other xorg-x11-fonts-* packages.

I interpreted this as meaning that /etc/X11/fontpath.d wouldn't get created, but 
maybe I was wrong.


In any case, it apparently didn't get created for the OP, and I had the same 
experience.  On the other hand, it gets created when I manually unpack the 
tarball, so I don't know what's going on.


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: allowing gmane to post to cygwin-apps

[Yaakov Selkowitz]

On Fri, 2015-09-11 at 14:04 -0400, Andrew Schulman wrote:
> > On Sep  1 19:26, Achim Gratz wrote:
> > > Corinna Vinschen writes:
> > > >> I'd say that mail through Gmane is still filtered on Sourceware.
> > > >
> > > > I guess you're right.  What we got a while back was to remove the
> > > > extra-aggressive filters on the cygwin mailing lists, so the spam
> > > > filtering on those are the same now as for any other mailing list on
> > > > sourceware.  So I assume (but I don't know that, actually) that
> > > > the same gmane filtering is done for all mailing lists on sware.
> > > 
> > > No, it must be specific to cygwin-apps (or else the main cygwin list is
> > > excepted).  Posting through Gmane has and still does work on the main
> > > list, but on none of the others.  Gmane will send the mail as coming
> > > from your subscribed address (if you've configured it correctly), but of
> > > course it's still delivered by gmane's mailer.
> > 
> > Hmm, ok.  Care to ask overseers or even... postmaster?
> 
> I wrote to cygwin-apps-owner at sourceware.org on September 1, and
> postmaster at sourceware.org on September 9.  No one has answered either
> one.  Any other ideas?

This is not something we control ourselves, so please be patient.

--
Yaakov

Re: Fonts reorganization and additions

[Ken Brown]

On 9/11/2015 3:59 PM, Yaakov Selkowitz wrote:

On Fri, 2015-09-11 at 15:12 -0400, Ken Brown wrote:

I was referring to the fact that for terminus-fonts we see



  2015-09-10 19:57   0 etc/X11/
  2015-09-10 19:57   0 etc/X11/fontpath.d/
  2015-09-10 19:57   0 etc/X11/fontpath.d/terminus:unscaled -> 
/usr/share/fonts/terminus

whereas for xorg-x11-fonts-dpi75 we see only

  2015-09-10 20:44   0 
etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20 -> 
/usr/share/X11/fonts/75dpi

and similarly for the other xorg-x11-fonts-* packages.

I interpreted this as meaning that /etc/X11/fontpath.d wouldn't get created, but
maybe I was wrong.


Generally, the leading directories aren't required, setup should be
creating all parent directories regardless.


In any case, it apparently didn't get created for the OP, and I had the same
experience.  On the other hand, it gets created when I manually unpack the
tarball, so I don't know what's going on.


If you remove your /etc/X11/fontpath.d and just (re)install
xorg-x11-fonts-Type1, does this occur?  (It shouldn't.)


No, it doesn't.  So your guess below is probably correct.


The first thing that should be checked is if the code in setup which
allows it to unpack files with "illegal" characters in Windows also
makes sure to create parent directories.  Based on these reports my
*guess* is it doesn't but I haven't looked yet.


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: cwdstuff::get: error on dlfcn.cc:174 /home/corinna/src/...

[Corinna Vinschen]

On Sep 11 09:30, Chevallier Yves wrote:
> --- Process 14376, exception c138 at 7726163E
>  3286 2708533 [main] python2.7 16924 seterrno_from_win_error: 
> /home/corinna/src/cygwin/cygwin-1.7.35/cygwin-1.7.35-1.i686/src/src/winsup/cygwin/dlfcn.cc:174
>  windows error 182

This is not Cygwin's fault, AFAICS.  Cygwin never loads functions by
ordinal.  This is also a bit on the lean side as far as information is
concerned. One can't see how the process calls dlopen, for instance.


Corinna

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


pgp2HwxZhxNP7.pgp
Description: PGP signature

Re: Fonts reorganization and additions

[Ola Strömfors]

The update gave the following error:

  Unable to extract
  /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20

  The File is in use or some other error occurred.

  Please stop all Cygwin processes and select "Retry", or select
  "Continue" to go on anyway (the file will be updated after a reboot).

and a similar message about the misc fonts.

- Reboot did not help
- After uninstalling the packages, creating the directory
  /etc/X11/fontpath.d and installing them again, there are still
  fonts missing, e.g.

% xterm
Warning: Cannot convert string 
"-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*" to type FontStruct

Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset

/Ola


The following packages have been uploaded to the Cygwin distribution:

* adobe-source-code-pro-fonts-1.017-2
* adobe-source-sans-pro-fonts-1.050-2
* adobe-source-serif-pro-fonts-1.017-1
* alef-fonts-1.0-2
* artwiz-aleczapka-fonts-1.3-2
* cantarell-fonts-0.0.16-2
* culmus-fonts-0.130-1
* dejavu-fonts-2.35-1
* gnu-free-fonts-20120503-2
* inconsolata-fonts-1.010-1
* kanjistrokeorders-fonts-3.001-1
* liberation-fonts-1.07.4-1
* linux-libertine-fonts-5.3.0-1
* overpass-fonts-2.0-1
* oxygen-fonts-5.3.2-2
* sj-fonts-2.0.2-2
* terminus-fonts-4.40-1
* unifont-fonts-8.0.01-1
* xorg-x11-fonts-cyrillic-7.5-1
* xorg-x11-fonts-ethiopic-7.5-1
* xorg-x11-fonts-dpi100-7.5-1
* xorg-x11-fonts-dpi75-7.5-1
* xorg-x11-fonts-misc-7.5-1
* xorg-x11-fonts-Type1-7.5-1

These packages have been renamed and reorganized for the new font layout
used by xorg-server-1.17.2-4, xfs-1.1.4-1, and tigervnc-server-1.5.0-1.
X11 core fonts are installed into /usr/share/X11/fonts with the
necessary symlinks into the X11 font catalogue.  Other fonts are
installed in their own directories under /usr/share/fonts, along with
configuration files in the requisite locations, for use with fontconfig.

--
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: Cygwin 32bit: Can't use gcc -mfpmath=sse

[HK]

On Fri, 11 Sep 2015 10:16:56 +0200, Evgeny Grin  wrote:


10.09.2015, 23:52, "HK" :

On Thu, 10 Sep 2015 13:19:04 +0200, V?clav_Haisman wrote:

 On 10 September 2015 at 01:30, HK wrote:

 hello.c:1:0: warning: SSE instruction set disabled, using 387
 arithmetics


 Does it help to use `-march=native`? My hunch is that this is because
 the default CPU type is set to such that does not have SSE.


Yep, that did the trick. Thanks for the suggestion. Now, is this a gcc
build
build problem? The 64bit version doesn't need -march=native and that is  
on

the same computer.


It's not a problem as by default GCC generate code compatible with  
maximum number of CPU models.
If you need to generate an SSE instructions, you have to use at lest  
-march=pentium3.
For x86-64 version, SSE is always enabled as all x86-64 CPUs support SSE  
and SSE2.

See http://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#x86-Options


Thanks. While I don't quite agree with the choice of defaults it makes  
sense.
So does my 32bit window next to the 64bit window on the same computer  
really

have a different instruction set? Anyway, case closed.

--
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 32bit: Can't use gcc -mfpmath=sse

[Tim Prince]

On 9/11/2015 8:03 AM, HK wrote:
> On Fri, 11 Sep 2015 10:16:56 +0200, Evgeny Grin  wrote:
>
>> 10.09.2015, 23:52, "HK" :
>>> On Thu, 10 Sep 2015 13:19:04 +0200, V?clav_Haisman wrote:
  On 10 September 2015 at 01:30, HK wrote:
>  hello.c:1:0: warning: SSE instruction set disabled, using 387
>  arithmetics

  Does it help to use `-march=native`? My hunch is that this is because
  the default CPU type is set to such that does not have SSE.
>>>
>>> Yep, that did the trick. Thanks for the suggestion. Now, is this a gcc
>>> build
>>> build problem? The 64bit version doesn't need -march=native and that
>>> is on
>>> the same computer.
>>
>> It's not a problem as by default GCC generate code compatible with
>> maximum number of CPU models.
>> If you need to generate an SSE instructions, you have to use at lest
>> -march=pentium3.
>> For x86-64 version, SSE is always enabled as all x86-64 CPUs support
>> SSE and SSE2.
>> See http://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#x86-Options
>
> Thanks. While I don't quite agree with the choice of defaults it makes
> sense.
> So does my 32bit window next to the 64bit window on the same computer
> really
> have a different instruction set? Anyway, case closed.
Intel compilers made SSE2 the default even for 32-bit mode, subsequent
to all CPUs which supported 387 but not SSE3 going out of production. 
There's still a lot of interest in 387 mode, however. 
You might argue for making SSE3 the default, but it's generally
important nowadays to set an appropriate option for the target platforms.

-- 
Tim Prince


--
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: allowing gmane to post to cygwin-apps

[Andrew Schulman]

> On Sep  1 19:26, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > >> I'd say that mail through Gmane is still filtered on Sourceware.
> > >
> > > I guess you're right.  What we got a while back was to remove the
> > > extra-aggressive filters on the cygwin mailing lists, so the spam
> > > filtering on those are the same now as for any other mailing list on
> > > sourceware.  So I assume (but I don't know that, actually) that
> > > the same gmane filtering is done for all mailing lists on sware.
> > 
> > No, it must be specific to cygwin-apps (or else the main cygwin list is
> > excepted).  Posting through Gmane has and still does work on the main
> > list, but on none of the others.  Gmane will send the mail as coming
> > from your subscribed address (if you've configured it correctly), but of
> > course it's still delivered by gmane's mailer.
> 
> Hmm, ok.  Care to ask overseers or even... postmaster?

I wrote to cygwin-apps-owner at sourceware.org on September 1, and
postmaster at sourceware.org on September 9.  No one has answered either
one.  Any other ideas?

pthread_kill: signals remain pending after target thread exits

[John Carey]

There seems to be a problem with pthread_kill: a pending signal targeting a 
particular thread prevents other threads from receiving signals sharing the 
same signal number--even after the original target thread exits and is joined.

To reproduce the issue:

  1. Block signal number S.

  2. Create thread T.

  3. Send a signal with signal number S to thread T in particular (as opposed 
to the process in general).

  4. After that signal has been sent, allow T to terminate without unblocking S 
or calling sigwait().

  5. Join T.

  6. Create thread N.

  7. Have N call sigwait() with a signal set that contains S.

  8. Send to N a new signal with signal number S.

  9. N never receives the new signal--instead, the new signal is discarded 
because the earlier signal remains pending.

BUT: It seems possible that N might inadvertently inherit the pending signal if 
its _cygtls instance happens to be allocated at the same address as the _cygtls 
instance of T.  It would be hard to predict when that would happen.  See the 
discussion of the source code, below.

For comparison, note that when performing the same steps on Linux (Ubuntu 
14.04.3), N does in fact receive the second signal.

Here is the relevant Cygwin source code, if I am understanding things correctly:

  - sigproc.cc : wait_sig : calls pending_signals::add, then tries to process 
signals in the queue, but leaves queued any signal that failed to process

  - exceptions.cc : sigpacket::process : signal processing fails if it cannot 
find the target thread using init_cygheap::find_tls

  - sigproc.cc : pending_signals::add : discards new signals whose signal 
number matches that of a pending signal--regardless of target thread

  - cygheap.cc : init_cygheap::find_tls : looks for a thread by the address of 
its _cygtls instance, but a thread that has been joined might happen to have 
had the same _cygtls address as a thread that was subsequently created, and 
therefore pending signals for terminated threads might sometimes be inherited 
by unrelated new threads (or so it seems to me--as yet I have not managed to 
trigger such a scenario)

In my view it would be desirable if:

  - Pending signals targeting a particular thread would not outlast that thread.

  - Multiple pending signals targeting different threads could coexist, even if 
they shared the same signal number.  This happens on Linux (Ubuntu 14.04.3), 
where I can generate two signals for two different threads, then sleep for a 
bit in each target thread, and finally have each thread receive its signal with 
sigwait()--neither signal is lost during the sleeping period.

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

Re: cwdstuff::get: error on dlfcn.cc:174 /home/corinna/src/...

[Marco Atzeri]

On 11/09/2015 11:30, Chevallier Yves wrote:

Hi,

How can I send this bug report to corinna?



This is the right place.

It is usually considered not polite to send e-mail directly
as highlighted on the problem reporting guideline:
https://www.cygwin.com/problems.html

Regards
Marco

--
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: bash-4.3.42-3

[Mikhail Usenko]

On Tue, 25 Aug 2015 14:19:54 -0600
Eric Blake (cygwin) <...> wrote:

> A new release of bash, 4.3.42-3, has been uploaded and will soon reach a
> mirror near you; leaving 4.3.39-2 as the previous version.
> 

It is one more buggy release (cygwin-specific).

---8<---(cygwin-test.sh)---8<---
#! /bin/bash

sender()
{
  echo -n  '\r\n' >&2
  echo -ne '\r\n'
  sleep 1
  echo -n  '\r\r\n' >&2
  echo -ne '\r\r\n'
  sleep 1
  echo -n  '\r\r\r\n' >&2
  echo -ne '\r\r\r\n'
  sleep 1
}

receiver()
{
  t=""
  while read t || [ "$t" ]; do
echo -n ": "
od -A n -t x1  <<<"$t"
  done  >&2
}

# implicit pipe
receiver < <(sender)

# explicit pipeline
sender | receiver

--->8---(cygwin-test.sh)--->8---

$ ./cygwin-test.sh
\r\n:  0a
\r\r\n:  0d 0d 0a
\r\r\r\n:  0d 0d 0a
\r\n:  0a
\r\r\n:  0d 0d 0a
\r\r\r\n:  0d 0d 0a

There is also the similar problem found accidentally just now with sed in 
pipelines:
$ echo -ne "\r\n" | sed '' | od -A n -tx1  # should be: 0d 0a
 0a
$ echo -ne "\r\r\n" | sed '' | od -A n -tx1  # should be: 0d 0d 0a
 0d 0a


On Thu, 04 Jun 2015 06:16:04 -0600
Eric Blake <...> wrote:

> 
> 'echo -ne' is non-portable (I can break it with 'shopt -s xpg_echo');
> get used to using 'printf' instead.
> 

xpg_echo doesn't change 'echo -ne' behavior
('echo -e' force backslash-escape sequences expansion independently)

$ shopt xpg_echo
xpg_echooff
$ echo -e '\r\n' | od -tx1
000 0d 0a 0a
003
$ shopt -s xpg_echo
$ shopt xpg_echo
xpg_echoon
$ echo -e '\r\n' | od -tx1
000 0d 0a 0a
003
$ echo '\r\n' | od -tx1
000 0d 0a 0a
003


-- 
Mike


--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

Hi Takashi,

On Sep 11 19:04, Takashi Yano wrote:
> Hi Corinna,
> 
> Regarding the first problem:
> > > a) Group permissions on root folders
> 
> On Sun, 6 Sep 2015 13:44:44 +0200
> Corinna Vinschen wrote:
> > The group permission problem is easy (and I'm wondering if it really was
> > such a bright idea to let user SID == group SID slip through in Cygwin,
> > rather tnan  sticking to the former idea to change the group SID to
> > "Users" in this case).  csih needs a patch to not check for the group
> > x bit if user SID == group SID.
> 
> Do you intend a patch like this? I have confirmed that sshd
> is successfully installed and works nicely with this patch
> under a Microsoft Account.
> 
> --- cygwin-service-installation-helper.sh.orig2015-02-24 
> 04:57:56.0 +0900
> +++ cygwin-service-installation-helper.sh 2015-09-11 18:41:56.870882800 
> +0900
> @@ -2442,6 +2442,8 @@
>  # ==
>  _csih_setup()
>  {
> +  local perms="d..x..x..[xt]"
> +
>csih_stacktrace "${@}"
>$_csih_trace
>if [ "$_csih_setup_already_called" -eq 0 ]
> @@ -2462,7 +2464,13 @@
>csih_error "Problem with LocalSystem or Adminstrator IDs"
>  fi
>  
> -if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
> +if [ `/usr/bin/stat -c '%g' ${LOCALSTATEDIR}` -eq \
> +  `/usr/bin/stat -c '%u' ${LOCALSTATEDIR}` ]
> +then
> +  perms="d..x.[xt]"
> +fi
> +
> +if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
>  then
>csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
>  fi

In theory, yes.  The problem is just that checking the uid/gid equality
is not safe, given that you can easily create that via passwd/group
files.  What I was thinking of is to convert the uid/gid values into
SIDs using the `getent' tool and to compare those, along the lines of

  uid=$(/usr/bin/stat -c '%u')
  user_sid=$(getent passwd -w $uid | awk -F: '{print $4}')
  gid=$(/usr/bin/stat -c '%g')
  grp_sid=$(getent group -w $gid | awk -F: '{print $4}')
  if [ "${user_sid}" = "${grp_sid}" ]
...

Can you check if that works in your env and perhaps create a new patch
using the SIDs?


Thanks a lot,
Corinna

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


pgp6tqUH4SIDl.pgp
Description: PGP signature

Re: XWin.exe not running any more.

[Jon TURNEY]

On 05/09/2015 13:14, Thomas Schweikle wrote:

Since yesterday starting "XWin.exe -multiwindow -clipboard" starts,
but stops after short. It doesn't keep running and X11 is not usable.

After starting I only see:
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.17.2.0
OS: CYGWIN_NT-6.1 nc403-muc 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
Package: version 1.17.2-3 built 2015-08-25


Do you know what version you updated from?


[   137,093] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'


This looks like the xserver is crashing whilst trying to initialize WGL.

You might try adding '-nowgl' to the XWin options.

You may find that updating your graphics driver, if possible, resolves this.

(Since this seems to happen with some graphics drivers, there is code in 
the X server which attempts to catch crashes in WGL initialization and 
turn WGL off, but that doesn't seem to be getting control in this case)


--
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: [ANNOUNCEMENT] Updated: bash-4.3.42-3

[Nellis, Kenneth]

From: Mikhail Usenko

> There is also the similar problem found accidentally just now with sed in
> pipelines:
> $ echo -ne "\r\n" | sed '' | od -A n -tx1  # should be: 0d 0a
>  0a
> $ echo -ne "\r\r\n" | sed '' | od -A n -tx1  # should be: 0d 0d 0a
>  0d 0a

FWIW, back in 2012 there was a discussion on this behavior of sed.
Apparently strong enough arguments were made to retain this behavior.

http://sourceware.org/ml/cygwin/2012-02/msg00301.html

--Ken Nellis

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Takashi Yano]

Hi Corinna,

On Fri, 11 Sep 2015 13:10:12 +0200
Corinna Vinschen wrote:
> In theory, yes.  The problem is just that checking the uid/gid equality
> is not safe, given that you can easily create that via passwd/group
> files.  What I was thinking of is to convert the uid/gid values into
> SIDs using the `getent' tool and to compare those, along the lines of
> 
>   uid=$(/usr/bin/stat -c '%u')
>   user_sid=$(getent passwd -w $uid | awk -F: '{print $4}')
>   gid=$(/usr/bin/stat -c '%g')
>   grp_sid=$(getent group -w $gid | awk -F: '{print $4}')
>   if [ "${user_sid}" = "${grp_sid}" ]
> ...
> 
> Can you check if that works in your env and perhaps create a new patch
> using the SIDs?

I have made a new patch and confirmed that it also works.


--- cygwin-service-installation-helper.sh.orig  2015-02-24 04:57:56.0 
+0900
+++ cygwin-service-installation-helper.sh   2015-09-11 21:30:08.539361900 
+0900
@@ -2442,6 +2442,12 @@
 # ==
 _csih_setup()
 {
+  local uid
+  local gid
+  local user_sid
+  local grp_sid
+  local perms="d..x..x..[xt]"
+
   csih_stacktrace "${@}"
   $_csih_trace
   if [ "$_csih_setup_already_called" -eq 0 ]
@@ -2462,7 +2468,17 @@
   csih_error "Problem with LocalSystem or Adminstrator IDs"
 fi
 
-if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
+uid=$(/usr/bin/stat -c '%u' ${LOCALSTATEDIR})
+gid=$(/usr/bin/stat -c '%g' ${LOCALSTATEDIR})
+user_sid=$(/usr/bin/getent -w passwd $uid | awk -F: '{print $4}')
+grp_sid=$(/usr/bin/getent -w group $gid | awk -F: '{print $4}')
+
+if [ "${user_sid}" = "${grp_sid}" ]
+then
+  perms="d..x.[xt]"
+fi
+
+if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
 then
   csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
 fi



-- 
Takashi Yano 

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

On Sep 11 21:33, Takashi Yano wrote:
> Hi Corinna,
> 
> On Fri, 11 Sep 2015 13:10:12 +0200
> Corinna Vinschen wrote:
> > In theory, yes.  The problem is just that checking the uid/gid equality
> > is not safe, given that you can easily create that via passwd/group
> > files.  What I was thinking of is to convert the uid/gid values into
> > SIDs using the `getent' tool and to compare those, along the lines of
> > 
> >   uid=$(/usr/bin/stat -c '%u')
> >   user_sid=$(getent passwd -w $uid | awk -F: '{print $4}')
> >   gid=$(/usr/bin/stat -c '%g')
> >   grp_sid=$(getent group -w $gid | awk -F: '{print $4}')
> >   if [ "${user_sid}" = "${grp_sid}" ]
> > ...
> > 
> > Can you check if that works in your env and perhaps create a new patch
> > using the SIDs?
> 
> I have made a new patch and confirmed that it also works.
> 
> 
> --- cygwin-service-installation-helper.sh.orig2015-02-24 
> 04:57:56.0 +0900
> +++ cygwin-service-installation-helper.sh 2015-09-11 21:30:08.539361900 
> +0900
> @@ -2442,6 +2442,12 @@
>  # ==
>  _csih_setup()
>  {
> +  local uid
> +  local gid
> +  local user_sid
> +  local grp_sid
> +  local perms="d..x..x..[xt]"
> +
>csih_stacktrace "${@}"
>$_csih_trace
>if [ "$_csih_setup_already_called" -eq 0 ]
> @@ -2462,7 +2468,17 @@
>csih_error "Problem with LocalSystem or Adminstrator IDs"
>  fi
>  
> -if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
> +uid=$(/usr/bin/stat -c '%u' ${LOCALSTATEDIR})
> +gid=$(/usr/bin/stat -c '%g' ${LOCALSTATEDIR})
> +user_sid=$(/usr/bin/getent -w passwd $uid | awk -F: '{print $4}')
> +grp_sid=$(/usr/bin/getent -w group $gid | awk -F: '{print $4}')
> +
> +if [ "${user_sid}" = "${grp_sid}" ]
> +then
> +  perms="d..x.[xt]"
> +fi
> +
> +if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
>  then
>csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
>  fi

Thank you, patch applied.


Heading into vacation now.


Have fun,
Corinna

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


pgpsau6CgtDvu.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] Fonts reorganization and additions

[Yaakov Selkowitz]

On Fri, 2015-09-11 at 11:17 +0200, Tobias Zawada wrote:
> Maybe, this is the reason why `emacs -q` gives the error message:
> 
> Font `-adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1' is not
> defined
> 
> and exits after the update on 2015-09-11?
> 
> Starting with `emacs -Q` and loading personal initialization file afterwards 
> is
> the current workaround for me.
> 
> `cygcheck -s` output is listed below.

In the future, please *attach* cygcheck output as directed on our
website.  But the relevant part is here:

> xorg-server 1.17.2-3 OK
> xorg-server-common 1.17.2-3 OK

As mentioned in the announcement, these font changes were intended to be
used in conjunction with 1.17.2-4.  Please update again and make sure
you get that version.

--
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: Fonts reorganization and additions

[Yaakov Selkowitz]

On Fri, 2015-09-11 at 12:29 -0400, Ken Brown wrote:
> On 9/11/2015 7:21 AM, Ola Strömfors wrote:
> > The update gave the following error:
> >
> >Unable to extract
> >/etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20
> >
> >The File is in use or some other error occurred.
> >
> >Please stop all Cygwin processes and select "Retry", or select
> >"Continue" to go on anyway (the file will be updated after a reboot).
> >
> > and a similar message about the misc fonts.
> >
> > - Reboot did not help
> > - After uninstalling the packages, creating the directory
> >/etc/X11/fontpath.d and installing them again,
> 
> This looks like a packaging error.  Yaakov, shouldn't installing 
> xorg-x11-fonts-* create /etc/X11/fontpath.d if it doesn't exist?  From
>  
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=etc%2FX11%2Ffontpath.d=x86_64
> 
> it appears that terminus-fonts is the only package that creates this 
> directory.

They do already, and they show up in the search.

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