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: https://cygwin.com/ml/cygwin-xfree/2014-11/msg00029.html 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): http://semver.org/ 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 problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version. I would like to kindly request that this change is reverted, at least until the time that a proper and documented upgrade path is available. Now please don't take this the wrong way. Although I realize some probably will. I do appreciate all the time that everyone, and not in the least Yaakov, invests into maintaining Cygwin/X. However as a user and software engineer myself I also very much appreciate systems continuing to function after minor upgrades. Sincerely, Laurens Blankers -- 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/
Re: xinit-1.3.4-1: breaking backwards compatibility
Laurens Blankers wrote: 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. What about changing the way X server is started? I flagged here: https://cygwin.com/ml/cygwin-xfree/2014-11/msg00040.html my experience with which I have no problems. But it may be that you have other needs which require starting X differently.. Ciao, Angelo. -- 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/
Re: xinit-1.3.4-1: breaking backwards compatibility
On 30-12-2014 13:46, Angelo Graziosi wrote: What about changing the way X server is started? I could change the way I start X, and I have successfully gotten things to work by doing so. But that is not my point. My point is that I need to make significant changes to the configuration to get back to the functionality that used to work. But it may be that you have other needs which require starting X differently. I will describe my use case: I use PuTTY to connect to several Linux servers, sometimes I need to run a X11 program on those servers (e.g. virt-manager) and I would like to get the output on my Windows desktop. In order to do that I install Cygwin, check the xinit package, wait till everything is installed. Then I start X server using the icon in my Programs menu. The first time an annoying xterm window pops up, which I suppress by running 'touch .startxwinrc'. Then I drag the X icon to my Start-up folder, so that it starts every time my desktop boots and sits in the tray area, where it doesn't bother me, ready to be used when needed. With this update the X server fails to start, well actually it starts, but exists immediately because .startxwinrc is empty. But there is no error message, or warning, or something to tell me this. So it took me 30 minutes to figure this out. After fixing it (sleep inf) I now have a very annoying icon on my taskbar representing the .startxwinrc which is still 'running'. Once I got that figured out I started PuTTY. But things didn't work. As it turns out this is because of the nolisten, which is now the default. A workaround suggested is to use 'ssh -Y' in stead of 'ssh -X', but I don't use SSH I use PuTTY and it doesn't support 'trusted' X11 forwarding. So to fix this I would have to go and change the startxwin script, a change which will be reverted every time I upgrade. Once I figured this out I just reverted back to the previous version of xinit and went on to do the things I wanted to do. Now, I am not against changing the way things work. I am definitely not against making the default more secure. And I think it is perfectly fine to have things change when people install Cygwin fresh. However _please_ think of all the people who just upgrade for the bug/security fixes and just want things to work. Ideally there should be an automatic script that sets things up for us automatically so that everything works as we were used to (e.g. automatically adding 'sleep inf' to the end of .startxwin might do). And at the very least the changes should be clearly documented, preferably a pop-up when installing the update, but at the very least a notice on the main website and FAQ. Posting an announcement to a mailing list with a details list of changes from which one may infer that things completely break just doesn't qualify as proper documentation in this case. I would like to reiterate my request to revert these changes, e.g. by releasing a 1.3.6 which is identical to 1.3.2, so that people like me, those not normally following cygwin-xfree can continue to work. Laurens -- 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/
Re: xinit-1.3.4-1: breaking backwards compatibility
Laurens Blankers wrote: Then I drag the X icon to my Start-up folder, so that it starts every time my desktop boots The same you can do with the link created as suggested in my previous replay. When I had Win XP I did that way for almost 7 years without tacking care of any configuration and/or xinit upgrade. Now with Win7 I don't use much X so I have left the link on the task bar and start it manually when I need X. Ciao, Angelo. -- 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/
Re: xinit-1.3.4-1: breaking backwards compatibility
On 30-12-2014 17:04, Angelo Graziosi wrote: The same you can do with the link created as suggested in my previous replay. You are probably right, but again, that is not the issue. The point I am trying to make is that breaking configurations which have worked for many years in a patch release is very bad practice. Laurens -- 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/
[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 x86: 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 x86_64: da45f5fefd155bb604747157bfc3be7a *xorg-server-1.16.3-1-src.tar.xz 95700ab99e07e7317cd435c9ddae4db2 *xorg-server-1.16.3-1.tar.xz a5ae0aeb3c58b32815c0b592a759a276 *xorg-server-common-1.16.3-1.tar.xz 0c86cff698c11c342a3a34302ecfe39d *xorg-server-debuginfo-1.16.3-1.tar.xz 3d9380e8b77e4642becc0dfcd641fcae *xorg-server-devel-1.16.3-1.tar.xz f9cb68a0f918a7e95958fb0fae75bbf1 *xorg-server-dmx-1.16.3-1.tar.xz 916bb76e182feb846a28c0a26077fc08 *xorg-server-extra-1.16.3-1.tar.xz bd8a9b7ef2a922df47fce2879085c23c *xwinclip-1.16.3-1.tar.xz [1] http://lists.x.org/archives/xorg-announce/2014-December/002506.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/