Edvardsen Kåre | 1 Nov 09:21 2011
Picon
Picon

Re: Default settings for XTerm

On Mon, 31 Oct 2011, Eliot Moss wrote:

        On 10/31/2011 3:45 PM, Eliot Moss wrote:
                I think that's "customization: -color" (note the
                dash), but yes :-) ... Eliot Moss

        Sheesh, I also typed it wrong, corrected above! EM

:-)

I think I'll find it :)

Cheers,
Kåre
Jon TURNEY | 1 Nov 14:52 2011
Picon

Re: -nolisten tcp -multiwindow combination crashes in XWin startup

On 31/10/2011 19:22, Dave wrote:
> Sadly this one wants to play a little hard to get...
>
> I have tried this on two somewhat similar machines - 5 years difference in hardware, but both XP Pro
up-to-date on Microsoft Update, and both running the cygwin versions present on mirror.mcs.anl.gov as
of this weekend - both were upgraded, then after both were, I checked that there were no further upgrades
posted in between.  The two differ regarding which packages are present, but for those present, they'd
seem to be at the same versions.
>
> One shows this problem quite consistently, the other doesn't show it at all.  It's the newer one, which has a
good amount of memory to spare and is usually the more reliable these days, that is showing the problem.
>
> I can recreate the problem at will on the one that shows it by starting XWin at the command line directly,
under xinit, or under startxwin.  But if I try to start XWin under gdb, I don't see the problem; see below. 
(The page you pointed me to suggests attaching gdb after startup, but that doesn't seem reasonable in this case.)
>
> I notice in the output from starting XWin at the command line there's the line
>        3 [main] XWin 4520 fork: child 5408 - died waiting for dll loading, errno 11
> I didn't see this output or captured in /var/log/xwin/XWin.0.log when I ran via xinit or startxwin.   I
don't know if that line got generated but lost in output redirections, or if this way of starting X is maybe
seeing yet a different problem.  This line seems similar to that reported by Denis Beauchemin, Wed, 19 Oct
2011 14:17:54 +0000.

Yes, this line is output directly by the cygwin DLL, so you won't see it in 
XWin.0.log

This output is typical of some other software causing cygwin problems with 
fork emulation, see [1] and [2] in the FAQ.

> Any suggestions re how else to get the backtrace you desire, or any other info that might be helpful?
(Continue reading)

J. Offerman | 1 Nov 18:57 2011
Picon

Re: wglext.h

FYI, I also had to specify --disable-unit-test to finish compiling successfully.

Thanks for your help. I really appreciate your perpetual efforts on
this. I admire you. People should worship you. If I were 20 years
younger with a tank full of energy... :-)

On Mon, Oct 31, 2011 at 6:43 AM, Jon TURNEY <jon.turney <at> dronecode.org.uk> wrote:
> On 31/10/2011 03:33, J. Offerman wrote:
>>
>> Okay, I went with --disable-aiglx, and it moved on, but I got this at
>> the very last stage of the build process:
>>
>>
>>   CCLD   XWin.exe
>> ../../glx/.libs/libglx.a(glxcmds.o): In function `FlushContext':
>>
>> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:219:
>> undefined reference to `__glapi_tls_Dispatch'
>> ../../glx/.libs/libglx.a(glxcmds.o): In function `DoMakeCurrent':
>>
>> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:598:
>> undefined reference to `__glapi_tls_Dispatch'
>> ../../glx/.libs/libglx.a(glxcmds.o): In function `__glXDisp_WaitGL':
>>
>> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:767:
>> undefined reference to `__glapi_tls_Dispatch'
>> ../../glx/.libs/libglx.a(glxcmds.o): In function `__glXDisp_CopyContext':
>>
>> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:864:
>> undefined reference to `__glapi_tls_Dispatch'
(Continue reading)

Ryan Pavlik | 1 Nov 21:39 2011

Built XWin on mingw - with patches

All,
Not sure if this is the right forum for this, but it seemed more
specific and probably more appropriate than the overall xorg lists.
I wanted to build a native windows X server (essentially an
open-source Xming). I had to patch a number of the packages along the
way, but did eventually arrive at a build that worked.  I looked at
and used a few of the Xming patches, but only generally went to those
when the naive approach didn't work.

I'm looking for some feedback on the patches so that they can get into
the main line of the projects.

I built using mingw-cross-env, with my fork here that includes the
dependency packages: https://bitbucket.org/rpavlik/mingw-cross-env/
This builds everything except the xorg-server module (ignore the fact
there's an xorg-server makefile there - the patches aren't up to date
for that module.)

Patches for these dependencies are as follows, in that mingw-cross-env
repo (These should all have commit messages from being exported from
git format-patch):
libX11-1-add-xwinsock-include, libX11-2-windows-threads,
libX11-3-MinGW-lacks-caddr_t
libXaw-1-need-winsock
libXfont-1-dummy-readlink
libxcb-1-fix-include-order-with-Xdmcp, libxcb-2-wsastartup - this last
one fixes running libX11 apps built for Windows, including the
integrated multi-window WM.
xkbcomp-1-Use-X11-Xwindows.h, xkbcomp-2-Look-in-windows-base-dir-too -
this last one supports the "RELOCATE_PROJECTROOT" option in the XWin
(Continue reading)

Dave | 1 Nov 22:50 2011

Re: -nolisten tcp -multiwindow combination crashes in XWin startup

Jon:  Thanks for the pointers to the fork() problem faqs.  That and a bit of googling led me to give
rebaseall a try, and
that appears to have cured my issue.  (For others, instructions can be found at
http://www.heikkitoivonen.net/blog/2008/11/26/cygwin-upgrades-and-rebaseall/ .)

Suggestion, perhaps more to the main cygwin team:  Since this issue is cygwin specific and is a bit
obscure (I've
been using cygwin for a good many years, but this is the first time I've recognized I had issues from this),
it'd be nice
if users didn't have to learn about this the hard way.  Could running rebaseall perhaps be automated as
part of setup.com?

----- Original Message -----
From: Jon TURNEY

Sent: Tuesday, November 1, 2011 6:52 AM
Subject: Re: -nolisten tcp -multiwindow combination crashes in XWin startup

On 31/10/2011 19:22, Dave wrote:
> Sadly this one wants to play a little hard to get...
> 
> I have tried this on two somewhat similar machines - 5 years difference in hardware, but both XP Pro
up-to-date on Microsoft Update, and both running the cygwin versions present on mirror.mcs.anl.gov as
of this weekend - both were upgraded, then after both were, I checked that there were no further upgrades
posted in between.  The two differ regarding which packages are present, but for those present, they'd
seem to be at the same versions.
> 
> One shows this problem quite consistently, the other doesn't show it at all.  It's the newer one, which
has a good amount of memory to spare and is usually the more reliable these days, that is showing the problem.
> 
(Continue reading)

Charles Wilson | 1 Nov 23:34 2011

Re: -nolisten tcp -multiwindow combination crashes in XWin startup

On 11/1/2011 5:50 PM, Dave wrote:
> Suggestion, perhaps more to the main cygwin team:  Since this issue is cygwin specific and is a bit obscure (I've
> been using cygwin for a good many years, but this is the first time I've recognized I had issues from this),
it'd be nice
> if users didn't have to learn about this the hard way.  Could running rebaseall perhaps be automated as part
of setup.com?

Rebase recently (4.0) gained the ability to use a database of
already-rebased DLLs, thanks to Corinna's efforts. I think part of the
purpose was to enable this setup-triggered behavior.

IF setup always ran rebase(all), then with the old rebase, (a) it would
appear to hang for a long time every time you tried to install anything,
while rebaseall was running, and (b) you'd always have to kill ALL
cygwin processes and services, even just to install some simple utility.

With rebase-4.0, those drawbacks won't occur (unless you have to rebase,
say, cygintl-8.dll for some reason).

But, since rebase-4.0 was just released, I think we're letting it simmer
on low heat for a while, before "forcing" everybody to use it during
every setup.exe instance.  It'd be a real shame if rebase-4.0 had some
undiscovered bug...and EVERYBODY got bit with it at once due to a new
"feature" of setup.exe!

--
Chuck

Jon TURNEY | 3 Nov 20:18 2011
Picon

Re: Built XWin on mingw - with patches

On 01/11/2011 20:39, Ryan Pavlik wrote:
> Not sure if this is the right forum for this, but it seemed more

This is absolutely the correct list.

Thanks very much for putting in the effort to do this.

> specific and probably more appropriate than the overall xorg lists.
> I wanted to build a native windows X server (essentially an
> open-source Xming). I had to patch a number of the packages along the
> way, but did eventually arrive at a build that worked.  I looked at
> and used a few of the Xming patches, but only generally went to those
> when the naive approach didn't work.

This may be a problem.

The material on the Xming website is licensed under a Creative Commons 
license, which is not compatible with the X11 license.  So, patches from the 
Xming website are not acceptable unless the author has agreed to re-license 
them appropriately.

> I'm looking for some feedback on the patches so that they can get into
> the main line of the projects.
>
> I built using mingw-cross-env, with my fork here that includes the
> dependency packages: https://bitbucket.org/rpavlik/mingw-cross-env/
> This builds everything except the xorg-server module (ignore the fact
> there's an xorg-server makefile there - the patches aren't up to date
> for that module.)
>
(Continue reading)

Timothy Madden | 3 Nov 20:27 2011
Picon

Re: Title bar of X apps, no host name?

On 24.10.2010 04:59, Jerry Cloe wrote:
> When I start individual windows between two linux boxes I always get the
> host name in the title bar of the window.
>
> For example from my desktop linux box:
>
> ssh -X jerry <at> prodserver
> then
> gedit&
>
> The title bar of the resulting gedit window will be along the lines of:
> "gedit (on prodserver.host.com)"
>
> But, when I do this from my windows/cygwin desktop, the title bar is simply
> "gedit" without the host name.
>
> On the linux side, I've never done anything to set this up or make it work,
> it just always worked, so I'm not even sure where to begin looking.
>
> Any ideas?

Does anyone know how to change the window title to include the hostname 
please ?

Connecting to 4 machines (with *ssh -Y*) and starting the *gvim* on all 
of them can be really frustrating when you have no indication what 
machine each instance is running on.

Thank you,
Timothy Madden
(Continue reading)

Csaba Raduly | 4 Nov 10:09 2011
Picon

Re: Title bar of X apps, no host name?

On Thu, Nov 3, 2011 at 8:27 PM, Timothy Madden  wrote:
>
> Does anyone know how to change the window title to include the hostname
> please ?
>

Put the following into your PS1 (on the remote machines) :

\[\e]0;\h:\w\a\]

Or you could google for "xterm window title"

Csaba
--

-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

Timothy Madden | 4 Nov 12:46 2011
Picon

Re: Title bar of X apps, no host name?

On 04.11.2011 11:09, Csaba Raduly wrote:
> On Thu, Nov 3, 2011 at 8:27 PM, Timothy Madden  wrote:
>>
>> Does anyone know how to change the window title to include the hostname
>> please ?
>>
>
> Put the following into your PS1 (on the remote machines) :
>
> \[\e]0;\h:\w\a\]
>
> Or you could google for "xterm window title"

I would like to change the title of all my X windows, so as to include 
the hostname of the X client for the window (that is, the hostname 
running the application in the window).

If you connect with *ssh -Y* to several machines, than you can run GUI 
applications on those machines, and the windows will open up on your X 
desktop. If you start gvim on each of these machines, you have 4 gvim 
windows on your desktop, with no easy way to tell to which machine each 
window belongs.

Some Linux X servers have this by default (I have CentOS), and it allows 
me to run *knosole* or *gnome-terminal* or *gvim* or any other 
application on several machines at the same time, with the X windows for 
them all on my desktop, without confusing the host machine for each window.

Thank you,
Timothy Madden
(Continue reading)


Gmane