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)

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)

schilpfamily | 2 Jan 21:10 2015

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

i have been running cygwin/x for a long time. i was on 1.14.4 and
decided to upgrade to 1.16.3. the problem is that i am unable to start
an xterm from a dos prompt. i have been using the following command
line for years now:

D:\cygwin\bin\run.exe -p /bin bash ~/scripts/xtermLaptop

the contents of xtermLaptop are:

#!/usr/bin/env bash

export DISPLAY=
xterm -geometry 80x75 -sb -rightbar &

this has worked for years, now when i run this command, a window very
briefly blinks into existence but then goes away. any idea why this
would stop working now?

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/

Jon TURNEY | 30 Dec 19:51 2014

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

The following packages have been updated in the Cygwin distribution:

*** xorg-server-*1.16.3-1

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

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

* Defend against and report crashes while checking Windows OpenGL 
capabilities at startup
* Add a tentative entry for the Korean keyboard to the list of known 
keyboards (Thanks to Colin Harrison for the patch)
* Typo fix in "Fix a crash which could occur when a client exits without 
deleting it's GL contexts"
* Improve WGL thunks code generator to deal with Khronos OpenGL registry 
XML since svn r27498
* Enable GLX TLS
* Remove the workaround for binutils bug #16807

2000b777841da8ddbbed3f6f2c162a59 *xorg-server-1.16.3-1-src.tar.xz
d35d98ee574d31c3a0f1eb383cd311ca *xorg-server-1.16.3-1.tar.xz
8affa3343b245ca39ea5ad045c8b0e31 *xorg-server-common-1.16.3-1.tar.xz
437ec870e16be593eb439dd4bb4a7fde *xorg-server-debuginfo-1.16.3-1.tar.xz
32794401f82dab76451d9ff1ca0c57b8 *xorg-server-devel-1.16.3-1.tar.xz
1d7b2d9fdd0eb05f2df53210440ba6d1 *xorg-server-dmx-1.16.3-1.tar.xz
2607bda544ef688c55f62ea7d803f551 *xorg-server-extra-1.16.3-1.tar.xz
7c441cebf48a31e78475f4c8bd631ec9 *xwinclip-1.16.3-1.tar.xz
(Continue reading)

Laurens Blankers | 30 Dec 12:07 2014

xinit-1.3.4-1: breaking backwards compatibility

I noticed that updating to the latest xinit (1.3.4-1) from the previous
one (1.3.2 I believe) completely breaks existing configurations.

The changes have been mentioned in the release announcement:


And numerous posts have since reported bugs regarding these changes. For
most a workaround has been provided, except for the 'icon in the
taskbar' issue.

I would like to express my wonder and dismay that such a seamingly minor
version change includes functionality which completely and utterly
breaks many, if not most, existing configurations. I am not sure what
versioning strategy is being used for Cygwin/X but I would like to call
attention to the semantic versioning standard (currently version 2.0.0):


Signalling this major change by increasing the major version number of
the xinit package (e.g. 2.0.0) would have made it a lot clearer what the
impact of the change would have been.

I would also like to call attending to the following FAQ item from the
same website:

Q: What do I do if I accidentally release a backwards incompatible
change as a minor version?
A: As soon as you realize that you've broken the Semantic Versioning
spec, fix the problem and release a new minor version that corrects the
(Continue reading)