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:
Problem reports:

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.



Unsubscribe info:
Problem reports:

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:
Problem reports:

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)

Ben Richards | 23 Dec 19:24 2014

Need help to replicate old behavior of my X setup scripts with latest Xfree86 update

Up until the recent update to xinit-1.3.4-1 which overhauled X session
handling, I had my session set up nicely for my purposes. With the
following code in my .zshrc and an empty .startxwinrc, when I launched
Cygwin, Xwin.exe would start on display :0.0, it would set the
$DISPLAY variable, and automatically kill the X server when I exited
that terminal. I like mintty so this let me use that as my shell.

.zshrc contents:
startxwin &> xserver.log
if [[ $x_start_success == 0 ]]; then
   export DISPLAY=:0.0

   pid=`ps | grep '/usr/bin/XWin' | awk '{print $1;}'`
   alias kill_xwin="kill $pid"
   if [[ $TMUX == "" ]] && [[ $x_start_success == 0 ]]; then
    alias exit="kill $pid ; \exit"

The aforementioned update disrupted this flow so I’m wondering if
anyone has any suggestions on how I can regain a similar sort of
functionality. I don’t like using xterm in Cygwin and would like to
keep using mintty as my main terminal interface. Before, when I ran
startxwin it would launch the server and quit with an error status as
to whether it was successful or not, leaving Xwin.exe running in the
background. Now it stays in the foreground unless I specify otherwise.
However, my startup script relied on the assumption that Xwin.exe was
running by the time startxwinrc finished, which I cannot guarantee if
(Continue reading)

Yaakov Selkowitz | 19 Dec 19:04 2014

[ANNOUNCEMENT] Updated: python-xdg-0.25-3, python3-xdg-0.25-3

The following package has been updated for the Cygwin distribution:

*** python-xdg-0.24-1
*** python3-xdg-0.24-1 (NEW)

PyXDG is a python library to access standards. Currently 
supported are:

* Base Directory Specification
* Menu Specification
* Desktop Entry Specification
* Icon Theme Specification
* Recent File Specification
* Shared-MIME-Database Specification

This release includes a patch for CVE-2014-1624:


Unsubscribe info:
Problem reports:

Yaakov Selkowitz | 19 Dec 18:57 2014

[ANNOUNCEMENT] Updated: xterm-313-1

The following package has been updated in the Cygwin distribution:

*** xterm-313-1

The xterm program is a terminal emulator for the X Window System. It 
provides DEC VT102 and Tektronix 4014 compatible terminals for programs 
that can't use the window system directly.

This is an update to the latest upstream release.


Unsubscribe info:
Problem reports:

Yaakov Selkowitz | 19 Dec 18:49 2014

[ANNOUNCEMENT] Updated: qt4-4.8.6-3

The following packages have been updated for the Cygwin distribution:

*** qt4-*-4.8.6-3
*** libQt*4-4.8.6-3
*** libQt*4-devel-4.8.6-3

Qt is a cross-platform application framework for desktop and embedded 
development. Qt enables programmers to create advanced GUI applications 
once and deploy them to Windows, Mac OS X and Linux without rewriting 
the source code.

This release includes various fixes from Fedora's latest patchset.


Unsubscribe info:
Problem reports: