Yaakov Selkowitz | 9 Feb 01:54 2015


The following packages, and their subpackages, have been added to the
Cygwin distribution:

* anthy-9100h-2
* eekboard-1.0.8-1
* kasumi-2.5-2
* ibus-1.5.4-1
* ibus-anthy-1.5.4-1
* ibus-chewing-1.4.3-1
* ibus-gucharmap-1.4.0-2
* ibus-handwrite-2.1.4-2
* ibus-hangul-1.4.2-1
* ibus-input-pad-1.4.0-2
* ibus-m17n-1.3.4-2
* ibus-pinyin-1.5.0-2
* ibus-qt-1.3.2-1
* ibus-skk-1.4.1-2
* ibus-unikey-0.6.1-2
* ibus-xkb-
* input-pad-1.0.2-1
* libchewing-0.3.5-1
* libhangul-0.1.0-1
* libskk-1.0.1-1
* m17n-contrib-1.1.14-1
* m17n-db-1.6.4-1
* m17n-lib-1.6.4-1
* pyzy-0.1.0-2
* zinnia-0.06-5
* zinnia-tomoe-0.6.0_20080911-1

(Continue reading)

Yaakov Selkowitz | 9 Feb 01:43 2015

[ANNOUNCEMENT] Updated: xinit-1.3.4-4

The following package has been updated in the Cygwin distribution:

* xinit-1.3.4-4

xinit contains commands used for starting X sessions.

This release includes the following changes:

* ~/.startxwinrc files which are not executable are warned about and
skipped by startxwin.

* Fixes for gnome-keyring-daemon and evolution-alarm-notify in the
default startxwinrc.

* The Xsession script will read /usr/share/xsessions/$NAME.desktop, if
present, when passed NAME as an argument.

* Avoid collisions with the Start Menu shortcuts if both 32-bit and
64-bit Cygwin are installed.

* Silences the harmless XFree86_VT warning.

* Add a profile.d for the fish shell.


Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
(Continue reading)

David Stacey | 5 Feb 00:20 2015

Cannot run Qt5 applications.

I'm having difficulty running any Qt5 application. These are the 
commands I'm issuing:

     XWin -multiwindow &
     export DISPLAY=:0.0
     xclock &

and I see the clock, so X is up and running. Then:

     QXcbConnection: XCB error: 145 (Unknown), sequence: 162, resource 
id: 0, major c
     ode: 140 (Unknown), minor code: 20
     Bad system call (core dumped)

and no clock.

I've tried compiling a really trivial Qt5 example (attached):

     g++ -I/usr/include/qt5 -I/usr/include/qt5/QtWidgets 
-I/usr/include/qt5/QtGui \
     -o qt5-demo qt5-demo.cpp -lQt5Widgets -lQt5Core

And then running ./qt5-demo gives:

     QObject::connect: signal not found in QPushButton
     QObject::connect: signal not found in QWidget
     QObject::connect: signal not found in QWidget
     QXcbConnection: XCB error: 145 (Unknown), sequence: 162, resource 
id: 0, major
(Continue reading)

mjmv | 3 Feb 04:43 2015

Cygwin, Python Anaconda 32-bit, Google Cloud SDK: Issues with Python functionality inside of Cygwi


I am new to Cygwin, and am not sure what to make of my current issue regarding Python and, ultimately, Google
Cloud's SDK and bdutl package, required for me to deploy a Hortonworks platform Hadoop/Apache toolkit
NoSQL db et al.
When I went to install Cygwin, I did not see an option for Python 2.7, which is what the GC SDK requires (more
specifically, 2.7 32-bit).  As such, I installed an Anaconda distro version.  After fighting with Cygwin
to use this install as my Python of choice for Cygwin applications (I ended up actually having to delete
from my environmental variables reference to the native 64-bit version I usually use, as modifications
to the $PATH did not change anything), I am left with a half-functional version of Python, and
non-functional GC SDK.

Pasted below are snippets from my terminal sessions.  If anyone can make sense of this, and point me in the
direction of resolving the issue(s), I will be very greatful.


MJ <at> Speed_rAcer ~
$ which python

MJ <at> Speed_rAcer ~
$ pwd

MJ <at> Speed_rAcer ~
$ python test.py
(Continue reading)

Jim Garrison | 3 Feb 01:52 2015

startxwin failing after most recent updates

I updated Cygwin (which pulled in a bunch of Cygwin-X updates) and
now startxwin no longer works.  According to the log (below) it starts
the XServer successfully but then shuts down.

My .startxwinrc is an empty (zero-length) file to prevent automatic
launching of the default clients, which I don't need.

The log output is

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
OS: CYGWIN_NT-6.1-WOW64 home 1.7.33-2(0.280/5/3) 2014-11-13 15:45 i686
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64)
Package: version 1.16.3-1 built 2014-12-30

XWin was started with the following command line:

/usr/bin/XWin :0 -multiwindow -nolisten tcp -auth

(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /home/jim/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 00000015
winSetEngine - Multi Window or Rootless => ShadowGDI
(Continue reading)

Lavelle Welles | 28 Jan 18:20 2015


44 Clockhouse Rd Farnborough Hampshire GU14 7QZ
+44 (1252) 97 22 60
Attachment (thames_and_hudson_ltd.cab): application/vnd.ms-cab-compressed, 24 KiB
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/
Maarten Hoes | 17 Jan 12:49 2015

Cygwin/X XDMCP Issue


Im having some issues when running Cygwin/X in combination with XDMCP. 
Opening a cygwin prompt and running 'startx' works as expected. When I 
try to connect to my remote Linux system with the command 'xwin -query' (or with the 'XLaunch' program and choose XDMCP) the 
screen stays black. I get the impression that I do get an connection, 
but that there is a display problem. When I try to close the blacked out 
Window, I get the message 'Exiting will close all screens on this 
display. There are currently 6 clients connected. Proceed with the 
shutdown of this display/server ?'

When i specify 'xwin -retro -query', the cursor appears 
and the screen gets gray-ish, but mouse clicking has no effect.

Setting 'xwin -engine 16 -query' results in a blue 
background and an error: 'Failed asserion key -> size == 0 at line 147 
of file

in function dixSetPrivate' and a core dump.

Any and all ideas are more than welcome, as I have no idea whats going 
on here.

This is the output of the 'xwin -query' command :

$ xwin -query
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
(Continue reading)

Ben | 8 Jan 18:13 2015

Q: What is the correct configuration for client and server when using '-nolisten'?

Due to the recent changes to Xorg et al., I've had two major breakages; one
with the update to `xinit` which now requires a `.startxwinrc`, and one
this week with the update to `xorg-server`.
I managed to work around the first breakage, but the second has required me
to roll back to the previous packages for both.
The issue I'm having is that, in spite of Doing It Right (`ssh -f -Y
user <at> remote_host xterm`), I'm now getting `connect /tmp/.X11-unix/X0:
Connection refused` when trying to connect to my servers (which are also
now, and always have been, running with `-nolisten tcp`).
To be explicit; rolling `xinit` back to 1.3.4-1 and `xorg-server` back to
1.16.3-1 fixed this immediately with no other changes, although I suspect
that the `xinit` downgrade may not be necessary.
What am I doing wrong?

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

Laurens Blankers | 5 Jan 12:46 2015

Suggestion for improving xinit 1.3.4


As requested [1] a separate thread for suggesting improvements to xinit,
in order to solve some of the issues people have been having since the
release of 1.3.4-1 [2].

1. Handling of empty .startxwinrc
Given the new behaviour of startxwin having an empty is never a correct
configuration. It would be really nice if startxwin could check for a
zero length .startxwinrc and in that case just start the X server
without any programs, as it used to do in 1.3.2-1. This would solve a
problem reported several times [3, 4] and also solve the problem of
having an icon on the task bar for 'sleep inf' [5].

2. Adding a hint about 'sleep inf' to the FAQ
Not everyone reads the release notes, most people, when running into
problems will read the FAQ first. How about adding an entry similar to
this one:

Q: startxwin exits immediately on start-up without error
A: ~/.startxwinrc must be executable and block or else X server will
exist, adding a 'sleep inf' to the end of the file should help, also see [2]

3. Adding 'listen' option to the FAQ
Consider adding something similar:

Q: X server is no longer accepting client connections, how come?
A: For security reasons, by default the X server no longer listen for
tcp connections, if you really want this add '-listen' to the start-up
(Continue reading)

Laurens Blankers | 5 Jan 12:31 2015

Can't open display with PuTTY and xinit 1.3.4-1

When using PuTTY with X11 forwarding enabled X clients are no longer
able to connect to the X server running locally. When reverting back to
1.3.2-1 the problem goes away.

This may be related to the -nolisten tcp which is now the default[1]. If
this is indeed the case it would be create of adding the '-listen' flag
to startxwin could be added to the FAQ. Or another, more secure,
solution would also be appreciated.

[1] https://cygwin.com/ml/cygwin-xfree/2014-12/msg00024.html


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

Larry Hall (Cygwin-X | 3 Jan 04:48 2015

Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3

On 01/02/2015 03:35 PM, schilpfamily wrote:
> rolling back to 1.3.2-1 fixed it. thank you very much for this, i was
> really pulling my hair out on this. i read your request to the
> maintainers and fully agree. while i  only brought up this one bug,
> since it was basically making cygwin/x useless, there were other
> issues that made it annoying.

Certainly it is good feedback to know that the issue you were seeing
is related to the new version of xinit.  I would encourage you and others
that see issues with the latest release to report the problems (as you
have) and to try the solutions offered in the cygwin-xfree mailing list
discussions from the last couple of months.  If there are technical
issues with those solutions, they need to be reported as well.  Obviously,
the key thing here is to figure out how to make this transition smoother,
so the more useful feedback there is, the better.  Downgrading may be a
practical short-term solution to the problems you're having at the moment
and that's fine.  But the functionality in the latest release of the xinit 
corrects some long-standing Cygwin incompatibilities with startx, so there's
no benefit to turning back as a strategy.




A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

(Continue reading)