Re: [ANNOUNCEMENT] Uploads for 12 August

2013-08-13 Thread Charles Wilson

On 8/13/2013 2:09 PM, Yaakov (Cygwin/X) wrote:

For now, I think you'll have to add a wrapper script.


Which would cause issues (dos boxes, etc) when launching from a 
shortcut, unless you use run.exe or run2.exe.  With run2 (assuming the 
upcoming(?) release fixes the known issues), you can set environment 
vars directly in the xml script:



?xml version=1.0 encoding=us-ascii?
Run2Config
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:noNamespaceSchemaLocation=run2.xsd
  Global
Environment
  Set var=G_SLICE value=always-malloc/
/Environment
Target filename=/usr/bin/emacs.exe startin=~
  Arg...various stuff.../Arg
  Arg...various stuff.../Arg
  Arg...various stuff.../Arg
/Target
  /Global
/Run2Config


...ought to work.  But there are still extant issues with run2 IIRC 
(been on vacation for a while so my memory from pre-vacation is still 
fuzzy).


--
Chuck


--
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: Cygwin 1.7.22 calls dumper when starting X

2013-08-01 Thread Charles Wilson

On 8/1/2013 7:19 AM, Angelo Graziosi wrote:

Charles Wilson wrote:

Is there a way to test run-2.0?  What is the syntax to replace:

C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe

Sure:


and how to replace

C:\cygwin-2\bin\run.exe bash -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*};
XWin -nowgl -multiwindow -clipboard -silent-dup-error 2/dev/null '


(which works fine with run-1.2!)

I have tried this:

$ cat /home/angelo/XWinServer.xml
?xml version=1.0 encoding=UTF-8?
Run2Config
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;;
   xsi:noNamespaceSchemaLocation=run2.xsd
   SelfOptions /
   Global
 Environment /
 Target filename=/usr/bin/bash.exe startin=/usr/bin
   Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl
-multiwindow -clipboard -silent-dup-error 2/dev/null '/Arg
 /Target
   /Global
/Run2Config

with this target in the link (.lnk):

C:\cygwin-2\bin\run2.exe /home/angelo/XWinServer.xml


Two errors: the extra semicolon after XMLSchema-instance, and you do 
need to use the 'amp;' construction instead of ''.  See attached.


(I'm not sure why you need  at all; unless it allows the bash shell to 
exit, where otherwise it would hang around?)


FWIW, I've never tested run2 with multibyte UTF-8, so...you might be 
better off setting the encoding to us-ascii.


--
Chuck

?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=run2.xsd
  SelfOptions /
  Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
  Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard -silent-dup-error 2/dev/null amp;'/Arg
/Target
  /Global
/Run2Config


--
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: Cygwin 1.7.22 calls dumper when starting X

2013-07-31 Thread Charles Wilson

On 7/31/2013 9:41 AM, Jim Reisert AD1C wrote:
 [1] http://cygwin.com/ml/cygwin/2013-07/msg00532.html

Yeah, I need to add even more runtime-debugging in run-1.0 and put out a 
test release, so we can figure out what's going wrong there.



Is there a way to test run-2.0?  What is the syntax to replace:


C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe


Sure:

1. create an XML file describing the program you want to launch. Here's 
an example:


?xml version=1.0 encoding=us-ascii?
Run2Config
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:noNamespaceSchemaLocation=run2.xsd
  SelfOptions /
  Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
  Arg-l -c /usr/bin/startxwin.exe/Arg
/Target
  /Global
/Run2Config

2. Make sure all the arguments you want to pass to the target program 
are represented in (the|one of the) Arg / elements.  Be sure that all 
sequences of two '-' characters are replaced by -!- (e.g. -!-login for 
--login, etc).


3. Create a shortcut with the following target:
C:\cygwin\bin\run2.exe /cygwin/path/to/your/xml/file

Enjoy.  (Try

C:\cygwin\bin\run2.exe --debug=3 --notty /cygwin/path/to/your/xml/file

if it doesn't work).

--
Chuck


--
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: coredumps with fc-cache, fc-list

2012-08-29 Thread Charles Wilson

On 8/28/2012 4:26 AM, Yaakov (Cygwin/X) wrote:

Fontconfig is WJFFM (Win7 x64, 290 .ttf files in Windows fontdir, none
with spaces).  I suspect you have a corrupt or otherwise incorrect font
file in your Windows fontdir.  What happens if you remove that directory
from /etc/fonts/fonts.conf?  Can you try to narrow it down further to a
specific font file?


Yes, that was it. The Thai font Angsana New (Regular) was corrupt; 
removing it and all the other Angsana TTF files fixed that problem.  Now 
I'm back to debugging, on the Vista machine where gdb actually works 
[1], the original problem with rxvt-unicode which I encountered on W7 -- 
that is, whenever I do anything interesting (like, say, simply 
starting vi), my rxvt-unicode terminal crashes with a SIGABRT:


Program received signal SIGABRT, Aborted.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x77015490 in ntdll!ZwWaitForSingleObject ()
   from /c/Windows/system32/ntdll.dll
#2  0x757b9aa4 in WaitForSingleObjectEx ()
   from /c/Windows/system32/kernel32.dll
#3  0x0564 in ?? ()
#4  0x in ?? ()


No idea why. I have debugging symbols available but...the abort appears 
to occur down in ntdll somewhere, and I have nothing informative in the 
remaining backtrace. Sigh.  I'm pretty much stumped at this point; my 
next try will be to build a completely minimal, zero frills, version and 
see if it works better. If so, then slowly add features back...


[1] Space key + gdb: http://cygwin.com/ml/cygwin/2012-08/msg00571.html

--
Chuck

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



coredumps with fc-cache, fc-list

2012-08-28 Thread Charles Wilson
While trying to debug the problem with my new build of rxvt-unicode, I 
find that I am getting a segfault way down deep in libfreetype. I 
rebuilt libfreetype with the new cygport, so I could get those handy 
debug symbols, and spent some time trudging thru that.


Then, since libfreetype is actually called by libfontconfig, and not 
directly by rxvt-unicode, I decided to download the -src package and 
rebuild THAT, too -- again, so I could have debug symbols for a few of 
my intervening stack frames.


The (re)build of fontconfig-2.8.0-2 went fine, but when setup installed 
it, I got an error during postinstall. Setup.log.full says:


2012/08/28 01:38:48 running: C:\cygwin-1.7\bin\bash.exe --norc 
--noprofile /etc/postinstall/fontconfig.sh
/etc/postinstall/fontconfig.sh: line 2:  4164 Segmentation fault 
(core dumped) /usr/bin/fc-cache -r


Ick.  So, I reinstalled the real version...and I got the same message:

2012/08/28 01:53:01 running: C:\cygwin-1.7\bin\bash.exe --norc 
--noprofile /etc/postinstall/fontconfig.sh
/etc/postinstall/fontconfig.sh: line 2:  6856 Segmentation fault 
(core dumped) /usr/bin/fc-cache -r



Running 'fc-list : family' also coredumps (using the official 
fontconfig-2.8.0-2).


*=-=-=-=-=-=-=-=-=*
I next ran 'fc-cache -fsv' as Adminstrator, and everything went 
swimmingly...until I got to the Windows dir:


...
/usr/share/texmf-dist/fonts/type1/urw/times: caching, new cache 
contents: 4 fonts, 0 dirs
/usr/share/texmf-dist/fonts/type1/urw/zapfchan: caching, new cache 
contents: 1 fonts, 0 dirs
/usr/share/texmf-dist/fonts/type1/urw/zapfding: caching, new cache 
contents: 1 fonts, 0 dirs

/cygdrive/c/Windows/Fonts: Segmentation fault (core dumped)

FWIW, I have 469 true type fonts in Windows/Fonts.  There are a mixture 
of fonts identified by Windows as TrueType and OpenType even tho 
they all end in .ttf.  Three of the font files have spaces in their names.

/cygdrive/c/Windows/Fonts/Envy Code R Bold.ttf
/cygdrive/c/Windows/Fonts/Envy Code R Italic.ttf
/cygdrive/c/Windows/Fonts/Envy Code R.ttf
I tried removing those three offenders, just in case, and re-running 
fc-cache but it still dumped core.


Any ideas? I'm going to try, just for grins and giggles, installing a 
self-built version of fontconfig-2.10.$latest and see if that helps 
matters...but I won't be able to do so until Thursday at the earliest.

--
Chuck

--
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: Built XWin on mingw - with patches

2011-11-10 Thread Charles Wilson

On 11/10/2011 11:29 AM, Ryan Pavlik wrote:

On Wed, Nov 9, 2011 at 1:11 PM, Charles Wilson  wrote:

You *think* you're safe in assuming that WIN32 == !__CYGWIN__,
but...#includejpeg.h  breaks all your assumptions.  But jpeg.h *did
nothing wrong*.

It's better to be explicit.

--
Chuck


OK, so this leads me to the next question: The existing codebase has
substantial numbers of places with #if defined(WIN32) - do these all
imply #if defined(WIN32)  !defined(__CYGWIN__) ?


That I don't know.


I generally
avoided touching things I didn't have to,


A good policy.


but this may be worth
clarifying codebase-wide.


Perhaps -- I'll leave that call to others. I suspect a global patch that 
affected only #if lines should be a separate patch from any other 
changes, if taking this action was desirable.


--
Chuck

--
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: Built XWin on mingw - with patches

2011-11-09 Thread Charles Wilson

On 11/9/2011 1:46 PM, Jon TURNEY wrote:

On 07/11/2011 19:36, Charles Wilson wrote:

But this isn't true if you ever #include any of the w32api headers. Then
you get WIN32 defined, even on cygwin...


True. I guess what I meant to say is that there isn't any compiler which
defines both WIN32 and CYGWIN (I hope :-)).

Any portable code which includes w32api headers before checking if WIN32
is defined isn't going to be very portable :-)


But it's perfectly portable to check for __CYGWIN__ (or, for that 
matter, __MINGW32__) instead of WIN32 before #including w32api headers, 
because you know that the windows API will be available in those cases 
as well.


The difference is, IF you do this (perfectly fine, legal, and portable) 
thing:


#if defined(WIN32) || defined(__CYGWIN__)
# include windows.h
#endif

then you can no longer rely on

#if defined(WIN32)
...stuff that applies only for truly native windows (e.g.
...msvc or mingw), but not cygwin
#endif

even though both hunks above are legal and make perfect sense *in 
isolation*.  The problem occurs when both hunks are present in the same 
translation unit -- and that's not always under your control.  What if 
libjpeg's header does the first hunk (it doesn't, but assume that it 
does for argument's sake), and your project's headers only do the second?


You *think* you're safe in assuming that WIN32 == !__CYGWIN__, 
but...#include jpeg.h breaks all your assumptions.  But jpeg.h *did 
nothing wrong*.


It's better to be explicit.

--
Chuck



--
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: Built XWin on mingw - with patches

2011-11-07 Thread Charles Wilson
On 11/7/2011 1:10 PM, Jon TURNEY wrote:
 I see what you are trying to do here, but I'm not sure it actually adds
 any clarity.
 
 I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN
 are mutually exclusive, so '#if defined(WIN32)  !defined(__CYGWIN__)'
 can just be written '#ifdef WIN32'

But this isn't true if you ever #include any of the w32api headers. Then
you get WIN32 defined, even on cygwin...

windef.h:

#ifndef WIN32
#define WIN32
#endif
#ifndef _WIN32
#define _WIN32
#endif

--
Chuck

--
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: rsh from other linux machines on the network to my cygwin machine

2011-02-16 Thread Charles Wilson
On 2/16/2011 6:17 PM, Srikanth Katkam wrote:
 I can do rsh/ssh onto other linux machines in the network and use
 all the resources on those machines but I cannot do the reverse, i.e., rsh
 on to my windows machine (i.e., Cygwin X server), why the other machines
 not able to see my cygwin/windows machine?

 This is why I am not able to run any DISPLAY required applications
 on the other linux machines (which rsh'ed on to from my cygwin/windows
 machine). The main reason is when I set the DISPLAY environment variable
 on the linux machines as my_windows_machine:0.0 it says cannot
 open DISPLAY

Your title does not appear to match the question you are asking.

If you are logged on to a linux box, and want to rsh over to your cygwin
box ... then you need to set up the rshd server on your cygwin box.  See
/usr/share/doc/Cygwin/rsh-server.README

If you are logged on to a linux box, and want to ssh over to your cygwin
box ... then you need to setup up the sshd server on your cygwin box.
See /usr/share/doc/Cygwin/openssh.README (but basically, run
/usr/bin/ssh-host-config and answer the questions).

That answers what your TITLE appears to ask.  However, the TEXT of your
question appears to ask a completely different question:

You are ssh'ing from cygwin to linux, and want to run an X application
on the linux machine, and have the display show up on your local cygwin
box -- but it's not working.

OK, FIRST you have to install and configure the cygwin Xserver, and have
it running.

SECOND, you need to be able to display X apps LOCALLY on cygwin box.
e.g. launch an xterm on the cygwin box.

THEN, from /that xterm/ on your cygwin box, do this:
ssh -Y remote_linux_host

FINALLY, once logged on to the linux host, launch an X app.  It should work.

Read about the -Y (and -X) options...

--
Chuck

--
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: Can't use mintty instead of rxvt for ssh -Y using cygwin xserver

2010-10-11 Thread Charles Wilson
On 10/11/2010 1:21 PM, Christopher Faylor wrote:
 You probably could try to figure out if the X server is working and then
 see which display is being used from that but I really don't think it
 makes sense to slow down mintty to perform this check.  FWIW, this
 wouldn't work with the linux console either.
 
 IMO, it just boils down to a situation where, if the user wants to have
 things display remotely, they have to go to the effort to properly set
 the DISPLAY environment variable.  Modifying mintty, the cygwin console,
 or any other non-X application to do the right thing isn't the way to
 go.

FYI, the 'checkX' program from the run2 package could be useful here, as
part of a script the end user could run, within mintty or the cygwin
console...

--
Chuck

--
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: X Server no longer launches urxvtc-X

2010-08-20 Thread Charles Wilson

On 8/20/2010 10:48 AM, Jay Goldman wrote:

I have the following menu items in my .XWinrc:
Black EXEC  /bin/urxvtc-X -fg green -bg black   -cr dodgerblue -g 80x40 -e 
/bin/bash -l -I
dodger EXEC  urxvtc-X -fg white -bg dodgerblue   -cr blue -g 80x42 -e 
/bin/bash -l -I

Which have been working for months .

Today I upgraded my cygwin install and all my menu items like the above no 
longer work.
(as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X
If, however, I open up a command window using rxvt and then enter the above
Line (by copy and paste) it works fine.


My first guess was that the urxvt daemon (urxvtd-X) was not running, so 
the client failed. But if you can launch the client using some 
incantation, then that means the daemon is running.




Note, menu items like:
 Xterm exec xterm
Work correctly,
While menu items such as:
 Notepad exec notepad
Do not.


Ah. Here's the clue: launching a native win32 program fails.  I bet this 
is related to the change in cygwin-1.7.6 where the cygwin current 
working directory and the win32 CWD are no longer automatically kept in 
sync (there are good reasons for this new behavior).


This change has caused a number of problems, and it is not yet clear how 
they will be resolved.  Stay tuned to the main cygwin list -- and 
meanwhile, revert to cygwin-1.7.5.


--
Chuck

--
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: problem with startxwin.exe and a possible solution

2010-01-21 Thread Charles Wilson
Marco Atzeri wrote:
 Today I start some experiments and I have found that
 changing the menu target from 
 
 C:\cygwin2\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
 
 to 
 
 C:\cygwin2\bin\run.exe -p /usr/bin /usr/bin/startxwin.exe
 
 all the problems seem gone. 
 The Xserver is stable and all the Xterms run smoothly.
 
 I suppose that my login shell redefine some parameters that
 startxwin.exe needs, while a much simpler 
 run.exe -p /usr/bin is what is really needed.

The real issue, I think, is that your mechanism doesn't allow you to set
OTHER environment variables that might need to be defined before
launching XWin, such as LC_ALL etc -- which would get set by the
original formula, since 'bash -l' reads your startup files like
~/.bash_profile where they might get set.

Another (untested!) possibility is to use run2.exe (which is kinda
wierd: use a launcher to start a launcher that starts X...)

== startxwin.xml ===
?xml version=1.0 encoding=us-ascii?
Run2Config
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:noNamespaceSchemaLocation=run2.xsd
  Global
Environment
  !-- set environment variables here --
  Append var=PATH  value=/usr/bin/
  Set var=LC_ALL  value=en_US.UTF-8/
/Environment
Target filename=/usr/bin/startxwin.exe startin=~
/Target
  /Global
/Run2Config

Shortcut target:
C:/cygwin/bin/run2.exe --notty /usr/bin/startxwin.xml

--
Chuck


--
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: xserver bug?

2010-01-20 Thread Charles Wilson
Jon TURNEY wrote:
 On 20/01/2010 09:13, Sylvain RICHARD wrote:
 Charles Wilson wrote:
 I've noticed that with XWin 1.7.3 (and perhaps earlier versions; not
 sure), the key combination CTRL-SHIFT-0 (zero) doesn't generate any
 events. CTRL-SHIFT-1 thru -9, alphabetic keys, no problem -- just not
 zero.
 
 I'm afraid I can't reproduce this problem; xev and urxvt both respond to
 ctrl-shift-0.

Humph. Well, good, I guess.  (Even if it doesn't work for me, this means
that OTHER users will probably be able to use the ISO14755 entry mode
without trouble).

 snip
 Is this a bug, or a designed behavior, in XWin?
 This may be designed behaviour /in windows/. Just out of curiosity, can
 you check your language bar options. If I remember correctly, you can
 set Ctrl+Shift global hotkeys there to shift between keyboard layouts
 and input languages.

My user account doesn't have the language bar enabled at all.
Hmm...maybe it's sticky. I *used* to have it enabled, and I *used* to
have hotkeys enabled -- but the only hotkey was/is left-alt + shift.
Not ctrl+shift.

 If it is the case that Windows is treating ctrl-shift-0 as a special
 keypress for some reason and processing it without offering it to
 applications, starting the X server with the -keyhook option should help.

Odd. With -keyhook, I do NOT see Alt-Tab being intercepted by the
Xserver. BUT, CTRL-ALT-0 does work.

$ startxwin -- :0 -keyhook

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.7.3.0 (10703000)
Build Date: 2009-12-22

Contact: cygwin-xfree@cygwin.com
XWin was started with the following command line:

X :0 -keyhook -multiwindow

winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
(II) xorg.conf is not supported
...


Vista SP2, 32bit.


Oh, WIERD.  Now, I just tried it again *without* -keyhook, and
CTRL-SHIFT-0 still works.  That's just bizarre.

All I can figure is, I turned on the language bar, switched keyboards,
switched back, and then turned off the language bar.  And now, I can't
break the CTRL-SHIFT-0.

Well...I'm happy, I guess.

--
Chuck


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



xserver bug?

2010-01-19 Thread Charles Wilson
I've noticed that with XWin 1.7.3 (and perhaps earlier versions; not
sure), the key combination CTRL-SHIFT-0 (zero) doesn't generate any
events.  CTRL-SHIFT-1 thru -9, alphabetic keys, no problem -- just not zero.

This came up as I was testing the new rxvt-unicode release; it has a
special ISO14755 entry mode, where you hold down CTRL-SHIFT and type
the unicode value (in hex) of the codepoint you want, and then release
the CTRL-SHIFT keys -- urxvt inserts the correct character. This works
-- as long as the unicode value doesn't contain 0.

e.g. CTRL-SHIFT 3-b-2 gives 'beta'
 CTRL-SHIFT 2-0-a-c should be the Euro symbol, but the '0' never has
any effect.

As I said, you can verify this behavior (this missing 0 events) using
xev, so it's not specific to rxvt-unicode.

Is this a bug, or a designed behavior, in XWin?

--
Chuck

--
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: [ANNOUNCEMENT] Updated: xinit-1.2.0-2

2009-12-29 Thread Charles Wilson
Yaakov (Cygwin/X) wrote:
 IMPORTANT: THE startxwin.bat AND startxwin.sh SCRIPTS ARE NO LONGER
 SUPPORTED.
 
 This release replaces those scripts with a startxwin executable.

facepalm!

Sounds like a good idea, but I wish I'd known this was coming before
wasting time on:

2009-12-29  run2-0.4.0 (release)
...
* Improve checkX behavior when used as 'barrier' in startxwin.
...

Oh, well.

--
Chuck


--
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: [ANNOUNCEMENT] Updated: xinit-1.2.0-2

2009-12-29 Thread Charles Wilson
Yaakov (Cygwin/X) wrote:
 On 29/12/2009 16:27, Charles Wilson wrote:
 Sounds like a good idea, but I wish I'd known this was coming before
 wasting time on:

  * Improve checkX behavior when used as 'barrier' in startxwin.
 
 Sorry about that, Chuck, but this was just the latest of a long string
 of issues involving these scripts.  We've been talking about replacing
 them for a while, and the recent traffic on the list was enough of an
 impetus to make me finally stop bandaging the scripts and find a better
 solution.  Plus, we gain argument handling and .startxwinrc, something
 the scripts would likely never do.

Like I said, it sounds to me like a good idea; there's just so many
issues that can go (and have gone) wrong in these scripts -- PLUS, whose
idea was it to have TWO, one .sh and one .bat?!!?  Yeeesh.  We're well
rid of them.

 Honestly, this wasn't even checkX's fault, so we weren't expecting you
 to fix it.  The real problem here is a corner-case bug in the server;
 the race condition that checkX was causing was just the trigger.  We
 still need to get to the bottom of that, but in the meantime we have a
 solution that completely avoids the problem and gives us new features to
 boot.

Yes, it definitely seemed like some sort of race going on -- I even
noticed sometimes that checkX would return success (e.g. was able to
call XOpenDisplay()), but that the very next command in my startxwin.sh
script would fail with a can't open display error.  Err...what?

So, yeah, I think startxwin.exe/.startxwinrc is a really excellent step
forward.

--
Chuck

--
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: X server fails to start

2009-12-28 Thread Charles Wilson
Feng Dai wrote:

 The root cause is checkX doesn't work properly. It cause XWin failed on
 initClipboard and exit itself. The work around is either comment out checkX or
 have a sleep 3 to let XWin server startup before checkX runs.

It's actually not checkX's fault that the Xserver dies.  All checkX does
is try to call XOpenDisplay(). However, in the current usage by the
startup scripts, checkX will do so /repeatedly/ during the period when
the Xserver is just getting started.

XWin appears to be fragile at that stage in its execution.

So, the latest version of checkX tries to be gentle with the Xserver
when that Xserver is just launching.

To try it out, you should make the relevant part of startxwin.bat look
like this:

...
%RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error

REM Make sure XWin is ready to accept connections before proceeding
checkX -d %DISPLAY% -t 12
...

That is, don't use %RUN% to invoke checkX.

--
Chuck

--
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: X server fails to start

2009-12-28 Thread Charles Wilson
Charles Wilson wrote:
 So, the latest version of checkX 

I guess I should be specific: that's checkX from the run2-0.4.0-1
package, which should begin hitting the mirrors soon.

--
Chuck

--
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: X11R7.5 and C.UTF-8

2009-12-02 Thread Charles Wilson
Linda Walsh wrote:
 C.UTF_8 doesn't exist.

You're wrong. Please read the whole of this thread -- and the last two
months' worth of cygwin-developers.

 mintty is broken.

No, it isn't.  It just doesn't work the way *you* expect it to.

 Might want to try 'Console' nstead of using mintty.  Not perfect either,
 but fewer compatibility problems that I've noticed.
 
 Examples of valid LANG values:
   C, ca_FR, en_US, fr_FR, it_IT, nl_NL, wa...@euro
 
 You can't have C and UTF-8, because C means no encoding (default).

No, it doesn't.  C means POSIX and is defined here:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
Note how all the glyphs are defined in terms of character NAMES, not
hexadecimal values?  That's because C, all by itself, just doesn't
SPECIFY any encoding.  You're still allowed to HAVE one -- in fact, you
ALWAYS have one.

On most systems, that has historically been the plain ASCII 7-bit
encoding; many others used the EBCDIC encoding and were not considered
in violation of the POSIX C locale specification.  Now, many systems
are starting to use the UTF-8 encoding by default, even in the C locale.

C/POSIX locale (without an additional .ENCODING suffix) is
encoding-AGNOSTIC, that's all.  So, you're allowed to add an .ENCODING
suffix to force a specific encoding if you like, without violating
POSIX.  (And your system is also allowed, in that case, to IGNORE that
.ENCODING suffix, and still be Posix-compliant IIUC, so it's rather a
hole in the spec IMO).

 UTF-8 IS an encoding, so they are mutually exclusive.  I don't
 know under what circumstances C might imply UTF-8.

Whenever the platform decides to use UTF-8 as its default encoding,
which is perfectly acceptable according to Posix.  Cygwin-1.7 has
decided to do that.  So, on cygwin-1.7, C implies .UTF-8.  X11R7.5
doesn't yet know that, without outside help (e.g. explicitly setting
$LANG to C.UTF-8 by default, so that XWin knows about the new
default behavior).

  If the definition
 of C changes?  It might be easier than changing c (as used in physics).
 
 My understanding of locale issues is also limited and subject to change or
 re-education...

Uhm, yeah.

--
Chuck

--
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: xterm not working

2009-11-30 Thread Charles Wilson
Thomas Dickey wrote:
 On Mon, 30 Nov 2009, Andy Koppe wrote:
 The latest termcap, which was automatically generated from terminfo,
 has entries longer than 1K in it.
 
 ok... (I thought cygwin was using GNU termcap, which supposedly works
 with longer entries - though I recall _that_ being fixed more than once).

Red herring.  The problem IS with the latest /etc/termcap, but it isn't
an entry too long problem.  It is an entries contain multiple :tc=
options problem. This can be fixed by generating /etc/termcap using
tic's '-r' option.  Look for a new /etc/termcap soon.

It'd be nice if xterm didn't coredump, but I suspect the coredump
actually occurs inside code from the (obsoleted on cygwin) libtermcap.a
-- so there's nothing to fix, except to recompile xterm on cygwin to not
use libtermcap and instead use libncurses.

Which is exactly what Yaakov has already done, for cygwin-1.7 only.

--
Chuck


--
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: xterm not working

2009-11-30 Thread Charles Wilson
Corinna Vinschen wrote:

 Isn't xterm linked against ncurses?

The new 1.7 xterm is.  The old 1.5 xterm is still termcap based.

 Why does it break on a termcap
 file at all?  

1.5 only, and it breaks because the termcap file was NOT generated using
'-r' to limit the number of allowed ':tc=' options in a single termcap
definition.

Will be fixed soon.

--
chuck

--
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: xterm not working

2009-11-30 Thread Charles Wilson
Yaakov (Cygwin/X) wrote:
 On 29/11/2009 21:28, Joe Java wrote:
Gone for Thanksgiving break, return and update cygwin, and now
 xterm does not show anymore.  I have not upgraded to the latest 1.7 (I
 am waiting for the official release).  I read the other messages and
 nothing seems to work.

Does anyone have a SIMPLE solution to this problem.
 
 Downgrade the termcap package until there is another update thereto.

Should be fixed by termcap-5.7_20091114-4 (cygwin-1.5) or
termcap-5.7_20091114-13 (cygwin-1.7).

--
Chuck

--
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: checkX problems

2009-11-25 Thread Charles Wilson
Lothar Brendel wrote:
 Unfortunately the situatiuon with ``startxwin.bat'' is worse now:
 
 * ``checkX -t 12'' still doesn't wait (?!?)

I can't reproduce this.

 * After again inserting a sleep between checkXing and starting the
 xterm, the latter is marginally successful: The process is shown as
 running but no xterm is showing up :-(

That's an xterm/XWin issue.

 I really would investigate this further, but I only get diagnostic
 output from ``checkX'' (--verbose or --debug) when running it from
 within an xterm, and that's obviously pointless.
 
 Thus, how to obtain output from ``checkX`` in Windows' Command Prompt,
 how to get it in Cygwin's bash window?

checkX --notty --debug -t 12

--
Chuck

--
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: Problem with new xinit - console window doesn't open (but bash starts)

2009-11-25 Thread Charles Wilson
Jon TURNEY wrote:
 This is typical of the current issue we have where 'run xterm' blocks when
 xterm tries to output 'Warning: Missing charsets in String to FontSet 
 conversion'

 Any one of:
 - installing the CJK fonts
 - having 'tty' in the CYGWIN environment variable
 - having the LANG environment set to a non-UTF-8 locale
 should work around this problem
 
 Note that the environment variable will have to be set via the system
 applet in the Windows control panel, as only that controls the environment
 for the startxwin.bat started from the start menu...

There's another option. In startxwin.bat, you could use run2.exe instead
of run.  Instead of:

%RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error

Use

%RUNTWO% /usr/bin/XWin.xml

where XWin.xml is something like the following (untested):

?xml version=1.0 encoding=us-ascii?
Run2Config
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:noNamespaceSchemaLocation=run2.xsd
  SelfOptions /
  Global
Environment
  !-- either of these, or both, and modified as desired --
  Set var=LANG  value=C.ASCII/
  Append var=CYGWIN  value= tty/
/Environment
Target filename=/usr/bin/bash.exe startin=~
  Arg-l/Arg
  Arg-c/Arg
  ArgXWin -multiwindow -clipboard -silent-dup-error/Arg
/Target
  /Global
/Run2Config

--
Chuck


--
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: checkX problems

2009-11-23 Thread Charles Wilson
Lothar Brendel wrote:
 checkX fails due to a missing cygustr-1.dll. That's contained in which
 package?

From http://cygwin.com/packages/ and typing in 'cygustr-1.dll', I get:

libustr1

This *should* have been installed by setup automatically, as the run2
package now lists libustr1 as a dependency.

--
Chuck

--
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: checkX problems

2009-11-23 Thread Charles Wilson
Lothar Brendel wrote:
 It should list, but it doesn't:
 
 $ grep -A9 '@ run2' setup-2.ini
  ^^^
This was the clue.

As it happens, the union mount stuff had an override for setup.hint, but
not the entire directory.  So, the tarballs themselves magically showed
up in the release-2 area when I installed them in the release/ area,
but release-2 retained the old setup.hint.  Fixed.

Thanks for tracking it down.

--
Chuck

--
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: checkX problems

2009-11-20 Thread Charles Wilson
I've integrated Lothar's patch into run2/checkX (along with some other
internal changes), and published a test release.  Please try run-0.3.1-1
and let me know if it fixes your problems with checkX.

--
Chuck

--
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: checkX problems

2009-11-15 Thread Charles Wilson
Lothar Brendel wrote:
 Ok, this can be cured by
 
if (pthread_cond_timedwait (cv_xopenOK, mtx_xopenOK, then) ==
 ETIMEDOUT) {
  xopenOK = XSERV_TIMEDOUT; /* it's okay, we have the mutex */
  xopenTrying = 0;  /* allow open_display() to give up */
 +  pthread_mutex_unlock(mtx_xopenOK); /* allow for a last minute
 change */
}/* else open_display() was successful */
pthread_detach(id);  /* leave open_display() on its own */

Not, that won't do it -- because now that you've unlocked the mutex, you
can't guarantee that the worker thread hasn't locked it again by the
time you try to destroy the mutex.  You can't move the
pthread_mutex_destroy call to the worker thread -- because what if there
never IS a successful return from the call to XOpenDisplay?  And finally
-- a little bit later in the main thread you are going to USE the value
of xopenOK to compute your return value -- but it's not an atomic
operation so you don't know if the worker thread is going to change
xopenOK's value in the middle of that operation.

AFAICT, the cure for all of these problems is worse than the disease
-- and the only *total* fix is for the main thread to always join() the
worker.  Which is precisely what we want to avoid.

There are a few *minor* tweaks that could improve things, but I'm
willing to go ahead with the current as a test release (as soon as my
ITP for libustr is approved; it's a new dependency for run2).

 But the problem is not so much destroying a locked mutex, but rather
 locking a destroyed mutex, right?

Well, frankly by the time that could happen I really don't care what the
worker thread does, so long as it doesn't crash the whole process. We've
already detached from it, and just want it to finish its call to
XOpenDisplay() and terminate.

 This happens in your race condition but also whenever ``delay'' is
 shorter than the time spent in a successful XOpenDisplay(). The failure
 doesn't really harm, but we can be less dirty by checking the result of
 pthread_mutex_unlock(), cf. the new patch.

No, I don't think we should unlock the mutex in the main thread, at
least until after we've computed the return value.  And once we DO
unlock the mutex, there just is NO WAY to guarantee that the worker
won't (successfully) lock the mutex, but not also have unlocked it, by
the time we try to call pthread_mutex_destroy -- except by waiting until
the worker thread exits (e.g. pthread_join()). Which we don't want to
do.  (If you try to relock the mutex in the main thread, you're right
back where we started...)

--
Chuck

--
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: checkX problems

2009-11-14 Thread Charles Wilson
Lothar Brendel wrote:
 Charles Wilson already set up this kind of infrastructure, I just had to
 introduce one more communication variable, cf. the patch below
 (positively tested on my system).
 
 Yep, there are really two different purposes for a setting a timeout [i)
 Just check whether an X server is available, but don't struggle with
 that too long. and ii) There *should* be an X server coming up, just
 be a little patient.], but now both can be achieved by choosing either
 a short or a long duration.

Looks pretty good.  There's still one problematic case -- but it
actually already existed; your change doesn't make it any worse than
what was already there.

 +  do
 +if((dpy = (*(data-xopendis))(data-displayname))) {

The call to XOpenDisplay can take up to 12 seconds. Suppose the main
thread times out after say 5 seconds, and then just after that we have a
*successful* return in the worker thread.  The worker thread tries to
get the mutex:

 +  (*(data-xclosedis))(dpy);
 +  pthread_mutex_lock (mtx_xopenOK);

But the main thread, if you follow the timed-out codepath, never
releases the mutex.  Instead, it destroys it while still having it
locked.  Then, it evaluates xopenOK to compute the return value.  The
spec says:

It shall be safe to destroy an initialized mutex that is unlocked.
Attempting to destroy a locked mutex results in undefined behavior.

So, the child thread might be stuck waiting for a mutex that has already
been destroyed.  That could be a problem -- but a very very rare one, I
think.  It only happens if you time out on the worker -- and THEN,
before the main app gets to exit(), the worker successfully returns from
XOpenDisplay. (If the main thread exits(), that should kill the worker
thread...so it never gets a chance to return successfully or otherwise).

 +  xopenOK = XSERV_FOUND;
 +  pthread_cond_signal(cv_xopenOK);
 +  pthread_mutex_unlock (mtx_xopenOK);
 +}
 +  while (xopenTrying  xopenOK == XSERV_NOTFOUND);
 
   pthread_exit((void*)0);
 }

However, (a) it's working now, even if it is technically wrong to do
it that way, and (b) it gets real complicated to figure out how to
guarantee the mutex is unlocked, in both threads, before destroying it
-- without forcing the calling thread to join() the worker, which is
explicitly what we DON'T want to do in this case.

So, I'm just going to leave it, and take your patch as-is.

Thanks!

--
Chuck


--
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: checkX problems

2009-11-12 Thread Charles Wilson
Jon TURNEY wrote:
 But why would you fix the timeout problem by doing some horrible
 horrible iteration in the DOS batch script (horrible) (which would
 probably have to busy-wait (also horrible) as there's no sleep command),
 when you can fix checkX, which has the bonus of fixing other uses of it?

I actually wrote a version of this. It IS horrible -- but no need for a
busywait, I used the ping trick:

C:\windows\system32\ping -n 2 127.0.0.1nul

sleeps for (n-1)==1 seconds.

 Since more people seem to have this problem (cf. also Olivia's post), I
 repeat my question (essentially already posed by Ken Brown:
 http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19402.html): Why
 using ``run'' at all? If we really need a wrapper (do we?) wouldn't
 ``sh'' be a better one?
 
 I guess we use run for the reason run exists: to hide the console
 window, which otherwise would be shown?

But checkX is compiled as a GUI program, so it really shouldn't need
run to hide its (non-existent) console:

$ objdump -p /usr/bin/checkX.exe | grep ^Subsystem
Subsystem   0002(Windows GUI)

Now, in startxwin.bat, we actually use:

%RUN% checkX -wait other args

run.exe is peculiar. The first argument is the target, and IF the VERY
NEXT argument is -wait, run usurps that argument.  That is, run will
invoke:
checkX other args
and checkX will never see -wait.  So, what does run.exe do with
-wait? It...waits.  run.exe won't exit, until after the inferior does.
 So, if checkX takes 12 seconds to come back, then run will take 12
seconds ... and the entire script is paused until checkX exits.

HOWEVER, since checkX is a GUI program, you SHOULD get the same result
from both of these two commands:

%RUN% checkX -wait other args
checkX other args

 Perhaps if you look how startxwin.bat is started from the start menu
 shortcut, (as 'run startxwin.bat') you can see why this might be useful?
 
 To push this even further: Do we really need two *independent* scripts,
 ``starxwin.bat'' and ``starxwin.sh''? Why can't the former just delegate
 to the latter?
 
 Indeed.  They are useless to me for starting the server and a continual
 source of problems.  I would be quite happy to just delete them
 completely.  :-)

Well, I think the OP is suggesting that one or the other go away, not
both. g  However, what is /your/ preferred way of starting the Xserver
from a shortcut, Jon? launching xinit via run?  or do you always start
the server from within an existing shell session?

 Looking forward to reading your patches to address any of these problems.

It shouldn't be too hard to add an option to checkX to make it retry
if ECONNREFUSED. This would have to manually track the elapsed time for
each attempt, charging against the specified -t waittime. Just look at
run2-0.3.0/lib/checkX.c::try_with_timeout().  Some function signatures
might need to be changed in order to pass opt.retry down to that level,
but it'd be a nice short project for someone.

I'll try to get to this but it'll be a few weeks, unless somebody sends
me a patch sooner.

--
Chuck


--
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: X11R7.5 and C.UTF-8

2009-10-28 Thread Charles Wilson
Thomas Dickey wrote:
 On Wed, 28 Oct 2009, Ken Brown wrote:
 
 X11R7.5 doesn't like the (default) locale C.UTF-8.  If I start the server
 
 technically speaking, there's no such locale as C.UTF-8,
 so I'd not expect portable code to accept it (C and UTF-8 are
 mutually exclusive).

No, actually they are not.  The C or POSIX locale is defined
entirely in terms of character values -- not hexidecimal equivalents.
That is, the set alpha shall contain 'a', 'b'... etc.

The standard actually doesn't require that an implementation specify the
encoding in which those character values are represented at all. You
can, if you want, use 'HEX_CHAR', 'OCTAL_CHAR', and 'DECIMAL_CHAR'
representations -- which implicitly require a specific encoding -- but
the standard defines the 'C' locale entirely in terms of CHAR and
CHARSYMBOL, which are encoding-agnostic.

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html#tag_07_03

Personally, I think it's a hole in the standard that it doesn't actually
talk about the POSIX locale with encoding Y -- but then, they don't
want to show preference between ASCII and EBCDIC, so UTF-8 sneaks in there.

--
Chuck

--
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: [ANNOUNCEMENT] [1.7] Updated: xinit-1.1.1-5

2009-10-01 Thread Charles Wilson
Angelo Graziosi wrote:

 In 'startxwin.bat' I see:
 
 %RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error
 
 Shouldn't it be
 
 %RUN% bash -l -c XWin -multiwindow -clipboard -silent-dup-error  ?

No, run implicitly puts the target in the background, unless you add
the '-w' (wait) option.

--
Chuck


--
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: [1.7] On checkX

2009-09-04 Thread Charles Wilson
Angelo Graziosi wrote:
 Charles Wilson wrote:
 Unfortunately, I can't reproduce.
 
 Ugh! I forgot to say that I start those scripts with links on desktop...
 
 For example:
 
 mkshortcut -AD \
 -n ${urxvt} \
 -a bash -l start_urxvt.sh \
 -i /usr/bin/XWin.exe \
 -d Console unicode \
 /usr/bin/run.exe

Using a short cut to my script, just like your shortcut (except mine is
on my own desktop, not all-users'), I...can't reproduce your problem. WJJFM.

 Indeed, if I start the script from Cygwin.bat, there is not
 checkX.exe.stackdump in the HOME! It is created ONLY starting the script
 with the link...
 
 ...and, in that case, the lines:
 
 [...]
 while ! /usr/bin/checkX
 do
   printf waiting for xserver to start\n
   sleep 1
 done
 [...]
 
 cause a NON-empty checkX.exe.stackdump:
 
 $ cat checkX.exe.stackdump
 Exception: STATUS_ACCESS_VIOLATION at eip=6E7C3CD0

I don't know what to tell you.  Please try to use the -debug options, as
I recommended before.

 Not only, also a bad interference between XWin and clipboard: trying to
 copy/paste (double click in urxvt shell), they hang and when I try to
 'Restart Now' the PC, Windows says 'xwinclip has not finished yet...'

Also can't reproduce. WJFFM.

 Now, If I want start your script from the link, How can I capture the
 output?
 
 For example, I have tried modifying it with:

Try this:


#!/bin/sh
export DISPLAY=127.0.0.1:0.0
let -a n=0
DBGLVL=1

start_XWin()
{
# Cleanup from last run.
rm -rf /tmp/.X11-unix
printf starting xserver\n ~/checkX_${n}.log

XWin -multiwindow -clipboard -silent-dup-error 2/dev/null 
}

/usr/bin/checkX --debug=$DBGLVL ~/checkX_${n}.log 21 || start_XWin
n=`expr $n + 1`

while ! /usr/bin/checkX --debug=$DBGLVL ~/checkX_${n}.log 21
do
  printf waiting for xserver to start [$n]\n ~/checkX_${n}.log
  sleep 1
  n=`expr $n + 1`
done
sleep 1
/usr/bin/urxvt-X 


--
Chuck


--
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: [1.7] On checkX

2009-09-04 Thread Charles Wilson
Charles Wilson wrote:
 Angelo Graziosi wrote:
 Charles Wilson wrote:
 Unfortunately, I can't reproduce.
 Ugh! I forgot to say that I start those scripts with links on desktop...

 For example:

 mkshortcut -AD \
 -n ${urxvt} \
 -a bash -l start_urxvt.sh \
 -i /usr/bin/XWin.exe \
 -d Console unicode \
 /usr/bin/run.exe
 
 Using a short cut to my script, just like your shortcut (except mine is
 on my own desktop, not all-users'), I...can't reproduce your problem. WJJFM.

Hmm. Spoke too soon.  It appears, that if I turn on --debug, then I get the

  5 [main] checkX 5048 fhandler_console::fixup_after_fork_exec:
error opening input console handle for /dev/console after fork/exec,
errno 13, Win32 error 5
   2342 [main] checkX 5048 fhandler_console::fixup_after_fork_exec:
error opening output console handle for /dev/console after fork/exec,
errno 13, Win32 error

errors in my log, but only when launching from a shortcut.  However, I
think that's expected...since checkX deliberately does not allocate a
console, and is *supposed* to use the presence/absence of a console to
determine whether to create MessageBoxes for log entries, or send them
to the (redirected?) stdout.

Try adding --notty to each invocation of checkX...that works for me.
It's annoying, but it works and allows you to see the debug messages.
Interestingly, the log files are now much smaller as expected -- what
isn't expected is they STILL get the fhandler_console error messages.

I wonder if /that/ is just a cygwin bug, in that it tries to open the
consoles of an exec'ed program, even if that program is not a console
program...I'll look in to that, later.

--
Chuck

--
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: Problems starting rxvt from startxwin.bat

2009-09-03 Thread Charles Wilson
Jon TURNEY wrote:

 Is there a reason why we can't do 'checkx -d %DISPLAY% -t 30' rather
 than counting up to 30 ourselves?

Well, -t with a number larger than 12 is not useful. Xlib itself will
timeout after 12 seconds if it can't contact the xserver.  The -t option
for checkx (and run2) simply says how long checkx will wait for the
worker thread that's actually trying to contact the Xserver, before
giving up and detaching the thread.

--
Chuck


--
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: [1.7] On checkX

2009-08-28 Thread Charles Wilson
[Redirecting to cygwin-xfree; Reply-To set]

Angelo Graziosi wrote:

 /usr/bin/checkX || start_XWin
 [...]
 
 Now, it happens that, often (perhaps always), if the x-server is not
 running, then checkX stackdumps, in the sense I find
 checkX.exe.stackdump in HOME, but it is empty! 0 bytes.

What version of checkX.exe? Please do:

$ cygcheck -cd checkx run2

Also,

$ uname -a

--
Chuck

--
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: [1.7] On checkX

2009-08-28 Thread Charles Wilson
[redirecting, AGAIN, to cygwin-xfree. This is OT for the main cygwin list]

Unfortunately, I can't reproduce.  Try running checkX with (progressively):
  --no-silent
  --verbose
  --debug
  --debug=2
  --debug=3
  --debug=4
this should help to narrow down how far it gets (and perhaps why) before
dying. You may also need to use the --nogui option, and redirect stderr
to a logfile.

--
Chuck


#!/bin/sh
export DISPLAY=127.0.0.1:0.0

start_XWin()
{
# Cleanup from last run.
rm -rf /tmp/.X11-unix

XWin -multiwindow -clipboard -silent-dup-error 2/dev/null 
}

/usr/bin/checkX || start_XWin

while ! /usr/bin/checkX
do
  printf waiting for xserver to start\n
  sleep 1
done
sleep 1
/usr/bin/urxvt-X 


--
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: broken checkx on mirrors

2009-07-08 Thread Charles Wilson
Guenter Millahn wrote:
 just now I tried an update of my CygWin. I realized
 that checkx-0.2.1-1.tar.bz is broken on all mirrors.

The checkx-0.2.1-1 package is an empty upgrade helper. It is present
only to force an update to the new package, which is called run2 --
this should have happened automatically. If it didn't, then just use
setup to install the run2 package manually.

run2 contains the old checkx program, as well as a new, enhanced version
of run.exe, that combines the capabilities of checkx, run, and some new
features.

--
Chuck


--
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: [1.7] Updated: cygwin-1.7.0-45

2009-04-06 Thread Charles Wilson
Thomas Wolff wrote:
 Now that cygwin supports UTF-8 in a standard fashion, I think it's time 
 to also add Unicode fonts to the Cygwin/X distribution. Otherwise the 
 additional value of running xterm or rxvt in UTF-8 mode is quite limited.
 
 I would be willing to provide the Unicode versions of the standard 
 misc-fixed fonts (source: http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html) 
 as a package maintainer, if that's accepted.
 (I would appreciate some positive feedback before taking the effort 
 to prepare the package.)

I think this is a great idea. Please do prepare a package and post an
official ITP (I'm not sure if X-specific package proposals should be
ITP'ed on cygwin-xfree or cygwin-apps).

I'm hoping that cygwin-1.7 + rxvt-unicode-8.x (+ ncurses configured for
wide char support?) will replace the need for your earlier unicode
shims contribution to rxvt-unicode. It'd certainly be easier to test
that with some unicode fonts already in the distro...

It might also be a good idea to supplement the existing
font-bitstream-vera-ttf package with the DejaVu fonts
http://dejavu-fonts.org/wiki/index.php?title=Main_Page (or DejaVu-LGC
[Latin-Greek-Cyrillic] for the less-ambitious). Fedora packages them as
   dejavu-sans-fonts
   dejavu-sans-mono-fonts
   dejavu-serif-fonts 
   dejavu-fonts-common
since unicode fonts can get rather large...

--
Chuck

--
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: New Maintainer

2008-03-28 Thread Charles Wilson

Christopher Faylor wrote:

On Thu, Mar 27, 2008 at 08:58:17PM -0500, Charles Wilson wrote:

DRC wrote:

Is there a spec for which files go in which packages, etc.?  Any other
advice to get started, or should I just start downloading and tinkering?
Given the new modular structure of the X.org releases, it seems to me 
that each module should be treated independently.  However, that being 
said, each module may represent multiple tarballs.  E.g.


I don't think it makes sense to invent a new scheme for what goes where.

Just pick a distro (Fedora, Gentoo, SuSE, Ubuntu, etc.) and mimic that.


Chris, this is NOT a new scheme, and the linux distros' methods cannot 
be directly mapped to cygwin with regards to shared libraries, because 
.so's != dlls, and ld.so != Windows Runtime Loader.  There will always 
be some differences between our packaging and the *nixes.


But in this particular case, what is new about the breakdown iisted 
below? Doesn't it map almost exactly to how Fedora distributes libXext 
in rpms?


libXext-1.0.3-1-src.tar.bz2
libXext-1.0.3-1.tar.bz2

libXext-devel-1.0.3-1.tar.bz2
libXext6-1.0.3-1.tar.bz2

(These filenames were taken directly from Yaakov's libXext cygport.)

The only real difference is that the *nixes would provide only the DLL 
(so) package 'libxext6' and the -devel package 'libxext-devel'; there's 
nothing specific in this case that really needs to go in a base 
package 'libxext'.  However, in Cygwin's case I've noticed that 
setup.exe (at least in the past) got annoyed if you have:

  foo-*-src.tar.bz2
  libfoo6-*.tar.bz2  (external-source: foo)
  libfoo-devel-*.tar.bz2 (external-source: foo)
but do not have
  foo-*.tar.bz2
Maybe this is a bug in setup and we should fix it, or maybe it is not a 
problem anymore.  In any case, we need to put the cygwin README, and the 
normal README/THANKS/AUTHORS/ChangeLog goobledygook somewhere. Might 
as well be in the (otherwise empty) foo-*.tar.bz2 package.


As it happens, Yaakov chose to put the man3 docs in the main foo-* 
package, instead of the libfoo-devel-* package. I'd probably do it more 
like the *nixes, in this case. But really, is THIS significant?



We can and should, of course, use the Linux distro's packaging choices 
as informed guidance, and I'm sure that's exactly what Yaakov did when 
he created his cygports. (The *nixes whose X components are based on the 
modular X.org source DO treat each module as independent subsets [that 
is, separate *.src.rpm's, separate lib*N rpms, separate lib*-devel rpms 
etc]...although they naturally tend to update/release them in 
simultaineous waves).



Frankly, I'd want to make things as easy as possible for the new X 
maintainer -- and since an experienced, knowledgeable person has already 
done a HUGE portion of the necessary work, I'd /start/ with Yaakov's 
cygports...and *maybe* make some slight modifications if 
SuSe/Fedora/Debian did something the new X maintainer particularly 
likes.  (Not the other way around, as you seem to suggest).



My email was an attempt to explain the general way that dll-providing 
cygwin packagesets are and should be subdivided, with a short 
description of the 'why' behind it all.  It's the way I've been 
providing DLL packagesets since 2002 or before. I'm surprised you 
consider it new.


--
Chuck

--
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: Checking if the X Server is running

2007-09-30 Thread Charles Wilson

O. Olson wrote:


Is there any way of checking if the X Server is
currently running? Because if you try this again, it
gives you “A fatal error” … which does not crash your
computer – but is a bit annoying to me. 


The checkX program is written specifically to do this.

  #!/bin/sh
  if checkX ; then
# X is running
  else
# X is not running
  fi

--
Chuck

--
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: Xterm, rxvt, mrxvt, etc....

2007-05-07 Thread Charles Wilson
 
often notifies me directly of upcoming changes and asks for testing.  So 
who is the 'C' maintainer: probably Bruno, but I reckon I help, somewhat.


Anyway, back on topic: I apologize for ignoring category C; that 
confusion is what led to our miscommunication (see below).



When I've seen - say - more than 10% of your work in the latter, you'll
have something to argue about.  You're not there.


Fine.  In your opinion I'm a bad maintainer.  But I do release 
updates, and I do fix bugs.  Since rxvt has no 'A', nor 'C' -- you call 
it unmaintained.  We say it IS maintained -- because there is a 'B' 
maintainer (and let's defer arguing about how *well* it is maintained, 
even in the 'B' sense, ok?)


Now, consider xterm: it has an 'A' maintainer, and a 'C' maintainer -- 
both you.  However, on the cygwin lists, we'd call it unmaintained -- 
because there is no 'B' at all. In fact, cygwin's xterm package is 
almost two years old:

http://www.cygwin.com/ml/cygwin-apps/2005-05/msg00327.html
And Harold, who released that package, is no longer with cygwin, 
having taken a job with StarNet(?) -- there were some contractual 
issues, IIRC.  Because there is no 'B' maintainer, I'd say that *xterm* 
is unmaintained -- at least as far as *cygwin* is concerned -- even 
though cygwin users of Harold's ancient package still benefit from your 
support.



Don't try to retcon this thread.


that remark reflects poorly on you.

For the casual reader, google suggests that Charles Wilson called me a 
liar.


No, it looked to me like you were trying to redefine the terms used in 
earlier emails, to change the meaning of those emails to something other 
than what they meant at the time they were originally sent.


I now realize that both you *and* I were using different semantics ALL 
ALONG.  Sorry for the confusion.


Frankly, I prefer rxvt-unicode on X -- even in non-unicode mode -- 
because


yes (does cygwin finally have unicode support? - no one's mentioned it
on this list at all).


No, cygwin does not. Cygwin's rxvt-unicode port has limited unicode 
support because Thomas Wolff provided me with a patch (to 
rxvt-unicode) that shims unicode support by intercepting certain X calls.


You're apparently still confused: the terminal emulator can certainly
implement something, but if the applications running in it can't (except 
as implied, for self-contained locale support), then it's of limited use.


That's why I said it was limited, and why I said *I* only used it 
regularly in non-unicode mode.  However, if you

  LC_CTYPE=en_US.UTF-8 urxvt-X.exe
you WILL get UTF-8 support on display, and with appropriate kbd settings 
in your X-server and .inputrc, limited UTF-8 input support.  Also, the 
'mined' package provides a fully unicode-aware editor that works pretty 
well within a unicode-mode urxvt window.  See

  /usr/share/doc/Cygwin/rxvt-unicode-X-7.7.README



But all that's not important.  Forget that 'unicode' appears in the name 
of the package, or that the package has some limited support for unicode 
if you jump thru enough hoops and use some limited set of application 
progs that understand unicode.  Let's call it rxvt-new-version, instead:


rxvt-new-version has an upstream maintainer, and active upstream 
development.  So there is an 'A' maintainer for rxvt-new-version.  I 
figured 'A' + 'B' is better than 'B' alone; so I'm promoting 
rxvt-new-version over plain old rxvt, even if nobody EVER sets LC_CTYPE 
to anything other than C.  But I still maintain (in the 'B' sense, 
badly, if you like) plain old rxvt.


Look, it's not a competition.  I like rxvt-new-version AND plain old 
rxvt, so I'll keep maintaining both for cygwin (however bad I may be 
doing at that job, in your opinion).  If the rest of the world switches 
to using xterm, more power to 'em, I'll cheer them on.  xterm has an 'A' 
maintainer, and a 'C' maintainer -- both you.  It'd be nice if it had a 
'B' maintainer, tho...


[[[ subthread #2 ]]]

Again, if there were an upstream _maintainer_ for rxvt (the point of this 

 thread), they'd have done something useful with the win32 bits
 mentioned.

Well, back when there WAS an upstream maintainer, they kinda DID do 
something useful with the win32 bits that existed at that time.  All of 
the /old/ win32 bits are in the upstream CVS (such as it is).  But all 
that happened when SteveO was still around, and was the 'B' maintainer 
for cygwin's rxvt (he also worked closely with the 'A' folks).  But all 
of them, and SteveO, disappeared long ago.


So I picked up the pieces as best I could: the current cygwin version of 
rxvt has a few additional patches beyone what those guys did, but 
nothing spectacular.  Mostly mechanical, and adapting to our build 
systems (first g-b-s, then cygport).


The really *new* win32 bits are in the (currently incomplete) standalone 
libW11 package, but that and rxvt-W, is a wholly separate effort.



There's certainly no cygwin maintainer for that,


Here, I believe you mean

Re: Xterm, rxvt, mrxvt, etc....

2007-05-06 Thread Charles Wilson

Thomas Dickey wrote:

On Sat, 5 May 2007, Charles Wilson wrote:

The fact is, rxvt upstream is dead, dead, dead. It has shuffled off 
this mortal coil.  Joined the choir invisible. It is an EX-terminal. 
The terminal is terminal.


thanks for agreeing with me.  It has no maintainer.


Not so fast, Thomas.  I did not and do not agree with your previous 
posts: neither of your messages claimed that upstream rxvt has no 
maintainer.  (If they did, then I would have agreed with that.)   Your 
messages claimed that rxvt had no cygwin maintainer.  That claim is 
false: I am the cygwin maintainer for rxvt.


Don't try to retcon this thread.

Frankly, I prefer rxvt-unicode on X -- even in non-unicode mode -- 
because


yes (does cygwin finally have unicode support? - no one's mentioned it
on this list at all).


No, cygwin does not. Cygwin's rxvt-unicode port has limited unicode 
support because Thomas Wolff provided me with a patch (to rxvt-unicode) 
that shims unicode support by intercepting certain X calls.


--
Chuck

--
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: Xterm, rxvt, mrxvt, etc....

2007-05-05 Thread Charles Wilson

Thomas Dickey wrote:
support is relative.  There's apparently no X maintainer, so no 
updated

packages.  On the other hand, while I respond to xterm issues(*) on this
and other lists, I don't recall _ever_ seeing support from rxvt's
maintainers on this list.


It's a two-way street. I put out a call for assistance -- backed up with 
ITPs of five packages, so I put my money where my mouth was -- and a 
whole long forward-looking plan concerning a revived libW11


http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00122.html
(and other messages in this thread, plus):

http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00118.html
http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00119.html
http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00120.html
http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00121.html

but no one cared.  I certainly got no interest in libW11, or rxvt-W11 -- 
such that their ITP's expired.


The fact is, rxvt upstream is dead, dead, dead. It has shuffled off this 
mortal coil.  Joined the choir invisible. It is an EX-terminal. The 
terminal is terminal.


Frankly, I prefer rxvt-unicode on X -- even in non-unicode mode -- 
because it's actively maintained upstream.   That's why I also maintain 
THAT package for cygwin.  Being monolingual, I can't vouch for the 
actual unicode support as I never use anything other than ASCII and US 
english.  For US/en input and non-unicode display, it works well and I 
use it daily.  For unicode display, it seems alright if you work very 
hard -- that is, read LOTS of FM and do LOTS of STFW -- at getting 
appropriate fonts installed.  For input other than US/en, I've had mixed 
success using US-intl kbd -- but then, I'm not really certain what true 
success should look like.  Please see /usr/share/doc/rxvt-unicode-7.7/* 
and /usr/share/doc/Cygwin/rxvt-unicode-X-7.7.README.


Concerning cygwin's rxvt-unicode-X: Yes, yes, I know: I need to update 
from 7.7 to 8.x.  But there's two problems there: (1) I need to forward 
port Wolff's unicode shims, and I'm not looking forward to that, and (2) 
I don't know what's going on with cygwin-1.7.0; IIRC there was talk -- 
just TALK -- about switching over to the *W win32api functions instead 
of the *A win32api ones.  Is that actually going to happen?  Will that 
affect the shims?  Obsolete them?  Require changes?  I dunno -- and I 
don't want to waste time on it before 1.7.0 is released.



rxvt is not an X package...


rxvt could run in X, but I agree it has a win32-specific chunk of code.

However, the last I read of _that_ was that it was no longer supported.
For example

http://www.cygwin.com/ml/cygwin-announce/2006-05/msg2.html


Wait: an announcement of a release (and not even the most recent 
announcement) is your evidence that a package is unmaintained?  Isn't 
that a bit backwards?


Granted, there have been only a few releases since I picked up that 
package: the one you mention last May, two last June, and the most 
recent last December.


All three updates were specifically in response to bug reports. *BUGS* I 
try to fix, if I have time.  *PATCHES* to fix existing bugs are even 
better.  But since the upstream is dead, there's no real impetus for 
releasing new versions -- except when bugs are reported or patches are 
provided.


Helping people fix their borked-up Xserver is not my bag.  Nor is 
providing the same old answer to the same old questions, that could be 
answered by reading any one of

  (a) the man page
  (b) the shipped documentation (/usr/share/doc/Cygwin/rxvt* and
  /usr/share/doc/rxvt-*/*)
  (c) or if the questioner would simple STFW.
or simply spending some time testing a few alternatives rather than 
running to the mailing list at the first sign of difficulty.  Like 
everyone else, my time for cygwin is a scarce resource -- I prefer to 
spend it on coding, bugfixing or functionality improvements (recently, 
gcc-4.x and, separately, libtool-2.x) than pretending to be a human 
interface to the man pages and READMEs.



google's not showing me a recent maintainer for the code.


Hmm. 
http://www.google.com/search?q=site:cygwin.com+inurl:cygwin-announce+rxvt+20050409hl=enfilter=0


rxvt-20050409-4
http://www.cygwin.com/ml/cygwin-announce/2006-12/msg00018.html

rxvt-20050409-3 (and also belatedly mentioned the unannounced -2)
http://www.cygwin.com/ml/cygwin-announce/2006-06/msg4.html

Also:
http://cygwin.com/ml/cygwin-apps/2006-05/msg00036.html
was only a year ago.

If there's no maintainer, it's not supported, no matter what the mailing 
list is. 


Your algorithm for determining which packages are maintained and which 
are not seems somewhat suspect.


--
Chuck


--
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: rxvt-20050409-4 compilation issues

2006-12-21 Thread Charles Wilson

Jason Curl wrote:

Hello all,

I'm having compilation issues with RXVT-20050409-4, after following 
instructions in the /usr/share/doc/Cygwin/rxvt-20050409.README file.


In particular I'm doing:
  cygport ./rxvt-20050409-X.cygport all

and it appears to fail because the xpm.h libraries don't exist. I 
checked the W11 directory, and sure enough it isn't there.


That's because the rxvt cygport file has this:

src_prep_init_hook() {
cd ${SRC_DIR}
apply_patch ${origsrcdir}/${PN}-import-xpm.patch
}

But the official cygport has not yet integrated my patches that enable 
this bit of magic to work.  You need a modified cygport...this is true 
of a lot of my packages, unfortunately.  I needed facilities that were 
not present in cygport, so I added 'em and posted my cygport patches (7 
or 8 of them, at last count) to the mailing list. However, Yaakov is 
quite busy at the moment 
(http://cygwin.com/ml/cygwin-talk/2006-q4/msg00159.html) so rather than 
delay my packages until the cygport changes were integrated, I released 
them anyway.


But you can't build them without the update cygport.  This particular 
.cygport requires the patch posted here:


http://cygwin.com/ml/cygwin/2006-11/msg00719.html
patch #1

--
Chuck

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



gtk2/glib version mismatch?

2006-11-11 Thread Charles Wilson

The current version of glib2 on cygwin is 2.10.3-1.
The current version of gtk2 on cygwin is 2.6.10-1.

gtk2 (prior to 2.8.x) uses the GMemChunk interface.  2.8.x and later use 
the slice allocator.


glib-2.10.x deprecates the GMemChunk interface:

#if !defined (G_DISABLE_DEPRECATED) || defined (GTK_COMPILATION) || 
defined (GDK_COMPILATION)

typedef struct _GAllocator GAllocator;
typedef struct _GMemChunk  GMemChunk;
...


Now, this causes no problems when building gtk2(2.6.x) *itself*, thanks 
to the GTK_COMPILATION switch.  However, many of gtk2(2.6.x)'s public 
interfaces use the GMemChunk symbol:



gtk-2.0/gtk/gtkstatusbar.h
---
...
struct _GtkStatusbarClass
{
  GtkHBoxClass parent_class;

  GMemChunk *messages_mem_chunk;
...
---

This means that gtk clients may NOT compile with -DG_DISABLE_DEPRECATED. 
 Disallowing deprecated interfaces is a good thing -- because 
deprecated interfaces bitrot quickly.  However, on cygwin we're stuck, 
because our gtk2 packages are older than our glib, and use/expose 
interfaces that are deprecated in our newer glib.


Gerritt -- can you update the gtk* packages to 2.10.x?

--
Chuck

--
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: Default directory is C:\PROGRA~1\RATIONAL\RATION~1\NUTCROOT\mksnt\?

2006-04-24 Thread Charles Wilson

Larry Hall (Cygwin X) wrote:


Without the benefit of all the info that http://cygwin.com/problems.html
recommends, I can hazard a guess that you have a copy of the MKS tools
installed.  These tools will conflict with the like named tools in Cygwin.
Your best bet is to remove them.  You'll likely find little advantage to
having them both and you certainly invite difficulties if you decide to 
keep
them both. 



Not entirely true, Larry.  If he *were* to remove that installation of 
MKS, he would then discover that his Rational Rose/Clearcase/Clearquest 
installation was broken.  IBM's Rational toolkit relies on having those 
MKS tools available (and no, they cannot be coerced into using cygwin's 
tools instead).


(It's the automation stuff behind the scenes which requires MKS, not the 
cmdline 'cleartool' app; you can still call the cmd line 'cleartool' 
executable from cygwin if you want, without conflicting with MKS)


 If you want both installed, you must make sure that one

environment doesn't see the other.  That includes manipulating your PATH
appropriately and all your other shell variables.  In particular, you've
already found that MKS has set SHELL to point to it's version.  


Yep, that's the key.  I simply set my cygwin dotfiles to override those 
nasty Rational variable values.

  PATH
  TERM
  SHELL
  TERMINFO
will do it.  (you can include the dir in which cleartool.exe lives in 
your cygwin PATH; that's a different dir than the MKS junk).


You'll

likely
see other problems like this as well.  As I said, the easiest thing to 
do is
to uninstall MKS and rely on the Cygwin version of these tools for your 
needs.


Unless, of course, he actually wants to be able to USE the 
Clearcase/Clearquest/Rose tools AT ALL.  Which is likely, as he's got 
them installed.



Obviously, you are free not to take this advice but your configuration will
generally be considered non-standard by those who frequent the Cygwin 
lists so
further problems you may have as a result your MKS installation is 
likely to

fall on deaf ears. ;-)



Or, he could get it working and assist Corinna in testing the latest 
snapshot...



- Reintroducing the dirent member d_ino.  1.5.20 tries hard to return a
  useful d_ino value, which is supposed to be also the same as st_ino as
  returned by stat(2) in all cases, regardless of the obstacles to do
  this on Windows.  Do you have strange file systems like HPFS or 


 ClearCase?

--
Chuck





--
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: Looking for Cygwin/X maintainer

2006-03-03 Thread Charles Wilson

Alan Hourihane wrote:


But, yet more thoughts. Given that Chris  Corinna want a more active
person to maintain Cygwin/X - I should stand down anyway.

Thanks for having me.


Please don't go away mad. :-)  Better, please don't go away, even if you 
do stand down.


Even beyond the be really active on the mailing list thing, tho, the 
current status of cygwin/x needs a bit of explanation if ANYbody is 
going to take over the maintainership.  I'd be a bad choice -- heck, I'm 
doing a pretty poor job with the packages I supposedly DO maintain -- so 
I'm not volunteering -- but I can see some issues even so.  Before Alan 
steps down, or during his transition period, there are a few questions 
that need answering before the next sucker^Wvolunteer could even begin 
to get a handle on things.


What is the current status of cygwin/X source code, release methodology, 
and what are the plans for the future and the status of their 
implementation?  I'll tick off what I think is true, and look forward to 
being corrected.


6.8.2.0-x

(where x=1,2,3,4 depending on the specific package)

The current stable cygwin-xorg release is 6.8.2.0, which is a monolithic 
imake-driven build and lives in /usr/X11R6.  It can be built by either 
downloading all the relevant -src packages, unpacking them in the same 
location, OR doing a cvs checkout from the CYGWIN branch
   cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r 
CYGWIN-6_8_2-MERGE xc


I'm ignoring cygwin-x-docs for right now.

Because this is a monolithic release, the instructions here or here
  http://x.cygwin.com/docs/cg/prog-build-native.html
  http://x.cygwin.com/docs/cg/prog-build-cross.html
will work.

This release was originally packaged by Alexander Gottwald in July 2005. 
It is a mystery how this packaging was accomplished, as

   http://x.cygwin.com/docs/cg/prog-distribution.html
was never updated (it currently reads Wait for these instructions to be 
updated, sometime after 2004-04-03.)


ago is still around, monitors the list, and maintains a few (non-core) 
X-related packages like X-startup-scripts, X-start-menu-icons, and run. 
 However, he is unavailable for advice or assistance with the core 
cygwin/x stuff:

   http://cygwin.com/ml/cygwin-xfree/2005-07/msg00118.html



6.8.99.901-1
--
The cygwin-xorg test release is 6.8.99.901-1 which is a monolithic 
imake-driven build, based off of one of the final release candidates for 
xorg-6.9.0 (aka X11R6.9).  It also lives in /usr/X11R6.  It can be built 
by either downloading all the -src packages, unpacking them in the same 
location, or doing a cvs checkout from the main branch
   cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -r 
XORG-6_8_99_901 xc


Again, ignoring cygwin-x-docs.

Also again, because this is a monolithic release, these instructions
  http://x.cygwin.com/docs/cg/prog-build-native.html
  http://x.cygwin.com/docs/cg/prog-build-cross.html
will work.

This release was originally packaged by Alan Hourihane in October 2005. 
 Obviously there were changes to the source code between 27 Oct 2005 
(when Alan packaged our 6.8.99.901 version) and 21 Dec 2005 (when the 
real xorg 6.9.0 was released, and the xc monolithic tree was frozen). 
 It is unknown if any of those changes materially affect cygwin/X.


Again, the packaging is a mystery, because while Alan stated in
   http://cygwin.com/ml/cygwin-xfree/2005-10/msg00100.html
that currently the scripts that build and package Cygwin/X are based on 
the monolithic tree I, at least, can't find those scripts in the cvs 
repository.


BUGS:
-
Nicholas Wourms reported in
http://cygwin.com/ml/cygwin-xfree/2005-10/msg00127.html
that 'xcursorgen and the icon sets' were missing from this test package. 
(He also mentioned the DPS libraries, but that's not a bug: they are 
being phased out by xorg team).


This release is still in 'test' after four months.




Plans and status thereof


(1) CYGWIN branch merge-to-HEAD

Alan originally planned to migrate any specific changes in the CYGWIN 
branch over to HEAD:


http://cygwin.com/ml/cygwin-xfree/2005-10/msg00122.html
I'll be working on getting whatever changes exist on [the CYGWIN] 
branchover into the mainline trunk code next.


But that statement was made AFTER the 6.8.99.901 test release and there 
is no indication of whether that actually happened -- or if it was even 
necessary (it's possible that there were no differences between the 
CYGWIN branch and the HEAD branch as of 27-Oct-2005).   Nor is it known 
whether any of these CYGWIN-branch-only changes, IF they even exist, 
were merged to the modular codebase.



(2) Migration to modular tree

Because xorg is transitioning to a modularized build architecture using 
the autotools instead of imake, X11R6.9 is the last monolithic release 
-- and the xc directory is now CLOSED for any further development as of 
21 Dec 2005 
(http://lists.freedesktop.org/archives/xorg/2005-December/011752.html). 
 Thus, any 

Re: rxvt fonts size setting problem for X/Cygwin

2005-11-22 Thread Charles Wilson

Igor Pechtchanski wrote:

I don't know of an easy way to dispatch to a font name based on whether
you're running X or native.  You could try playing with window names and
using this as a selector in your .Xdefaults...
Igor


Here's what I do:

(1) ~/.Xdefaults has the following (if you ignore the silly mailer line 
wrapping):


rxvt*background:#40
rxvt*foreground:#bf
rxvt*scrollBar: true
rxvt*scrollBar_right:   true
rxvt*font:  -bitstream-bitstream vera sans 
mono-medium-r-normal--*-120-*-*-m-*-iso8859-1
rxvt*boldfont:  -bitstream-bitstream vera sans 
mono-bold-r-normal--*-120-*-*-m-*-iso8859-1

rxvt*saveLines: 1
rxvt*loginshell:true
rxvt.backspacekey:  ^H

(2) I have a shortcut to start rxvt-X with the following target (where 
'runrxvt.exe' is a copy of run.exe):


C:\cygwin\bin\runrxvt.exe -display 127.0.0.1:0.0 -tn rxvt-cygwin -e 
/usr/bin/bash --login -i


One thing I haven't worked out is, if I click this shortcut with no X 
server running, I get a gigantic rxvt-native window with absolutely huge 
font.  But that's my error; I just close the window, start the X server, 
and go again.  Problem solved.


(3) I have a shortcut to start rxvt-native with the following target 
(ditto runrxvt.exe):


C:\cygwin\bin\runrxvt.exe -display :0 -fn Bitstream Vera Sans Mono-16 
-tn rxvt-cygwin-native -e /usr/bin/bash --login -i


The colors and other settings from the .Xdefaults file are actually used 
by both versions -- but the rxvt-native one uses the command line -fn 
font instead of the .Xdefaults value.


(I also have 'rxvt' aliased depending on the current value of $TERM, so 
that subsidiary rxvt windows launched from the command line 'inherit' 
X-ness or Native-ness, but that's a different issue).


--
Chuck

--
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: Consensus about man and doc X11 directory structure

2005-10-10 Thread Charles Wilson

Yaakov S (Cygwin Ports) wrote:


What does Cygwin native mean?  If Cygwin is meant to be a POSIX
environment, then X11 should be the standard for GUI apps.


Not gonna happen: it has been stated before on this list that 'insight' 
*must* run without X -- which means that tk will remain Win32GUI.


It may be possible, eventually, to have both win32GUI-cygwin-runtime-tk 
and XGUI-cygwin-runtime-tk on the same machine, but nobody has 
undertaken the daunting task to make that happen.  Ditto gtk.


However, I don't see the problem in assuming that GUI apps are presumed 
to be X-flavor (with the tk exception, above).  If at some point 
somebody figures out how to build a similar GUI app/toolkit in the 
opposite flavor, it can go in /opt/.


--
Chuck



--
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: Consensus about man and doc X11 directory structure

2005-10-10 Thread Charles Wilson

Yaakov S (Cygwin Ports) wrote:

Others have mentioned building *NIX tcl/tk on Cygwin, and I wouldn't
call building gtk2 daunting; 


Daunting to build it in such a way that (a) the win32 version doesn't 
interfere with the X version, (b) vice versa, and (c) you're SURE that 
nothing win32-runtime 'leaks' into either version, but ONLY win32-GUI 
gets into the win32 version.



I'm not personally interested, as I'm
focusing on the X11 ports.



What's stopping us from moving the Win32 tcltk in /opt/win32, and making
new *NIX tcl and tk packages in /usr?  Then all that's necessary for
insight is to add /opt/win32 to PATH (either through a script,
profile.d, or manually).  Similar packages (i.e. that have both X11/*NIX
and Win32 flavors) could use /opt/win32 as well.


All of this mucking about with tk and insight requires the concurrence 
of -- and oodles of extra work by -- the tk maintainer and the insight 
maintainer.  Plus, speculation alert given the centrality of the 
debugger to the GNUPro product, this sort of change might meet 
resistance from the PowersThatBe channeled thru our local Benign 
Dictator(s).


Good luck with that.

--
Chuck

--
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: Emacs problem after rebaseall: some progresses?

2005-09-16 Thread Charles Wilson

Angelo Graziosi wrote:

After the new release of rebase-2.4-1, the problem remains 


   BUT
   
this time reinstalling, with setup, ONLY the
package libncurses7 (whose current release is 5.3-4), 
EMACS works again!


Rebasing all and then reinstalling a package that has just rebased :
is it a valid procedure? 


Sure, this is fine.

But what you're really saying is that one of the dlls in libncurses7 
used by xemacs


/usr/bin/cygform7.dll
/usr/bin/cygmenu7.dll
/usr/bin/cygncurses7.dll
/usr/bin/cygpanel7.dll

is not rebase-able.  I'm not clear on the history; there was a time when 
a number of DLLs were considered not rebase-able but I don't remember 
why, or whether the issue was ever fixed (in rebase.exe, or in the DLLs 
themselves).


*I* wonder, if xemacs were rebuilt against the CURRENT ncurses libraries 
(libncurses8), would it still have similar problems -- e.g. would you 
need to rebaseall and then reinstall libncursesEIGHT?


If so, it's a problem I need to track down, as the ncurses maintainer. 
If not, then the XEmacs maintainer should simply release a new version, 
recompiled against the new ncurses.


--
Chuck

--
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: Emacs problem after rebaseall: some progresses?

2005-09-16 Thread Charles Wilson

Angelo Graziosi wrote:


as the title of this mail says, it is Emacs (21.2-13, 21.3.50-2, started
from X), NOT XEmacs (21.4.17-1, 21.5.16-1), that has problems after
rebasing all the system.


Fine, Emacs, XEmacs, whatever.  That's not the point



The problem.

There are applications that need rebasing (... unable to remap...). But
after rebasing all, Emacs does not show its window and take almost 100% of
CPU (one can only kill it). If one reinstall libncurses7-5.3-4, Emacs
works again as it should.  


For what I know, Emacs is the only X application that has this problem.


And, is it the only X application that links against an obsolete version 
of the ncurses library?  e.g. is it simply that cygncurses-7.dll cannot 
be rebased without causing troubles for client apps -- and 
cygncurses-8.dll, used by all other X apps, is fine?


The *E*macs maintainer should relink/rebuild *E*macs against 
cygncurses-8.dll, rebase, and see if the problem (e.g. the necessity of 
undoing the rebase of cygncurses-8.dll by reinstalling that package) 
remains.


If the new *E*macs works with a rebased cygncurses-8.dll, then the 
problem is solved: cygncurses-7.dll is broken, and if it weren't 
obsolete it should be fixed.  But, since it IS obsolete...


Now, if the *E*macs maintainer does all this and the problem remains -- 
after rebasing, *E*macs is broken unless cygncurses-8.dll is reinstalled 
-- THEN we'll have something to talk about.


--
Chuck

--
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: Obtaining older packages...

2005-04-26 Thread Charles Wilson
Don't forget the Cygwin Time Machine:
http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine
ftp://www.fruitbat.org/pub/cygwin/circa/index.html
--
Chuck


Re: Tcl/Tk wish and Cygwin/X

2005-02-24 Thread Charles Wilson
Markus Jung wrote:
I have a strange effect with my cygwin/x environment.
I've downloaded a Tcl/Tk application called secpanel. secpanel is a 
application tho manage ssh connection with a x-window interface.
Now, my problem is if I start the secpanel application with wish, it won't 
come up in my windowmaker x-environment. It comes up in my
normal XP environment an thats not the way I want it. I need this 
application in my x-window environment.
Search the archives for tcl/tk and X.  It comes up every blue moon, but 
cygwin's tcl/tk package is really only there as a prerequisite for the 
insight debugger.  Which, if you're debugging an X app -- or any 
embedded app for, say, Red Hat eCOS -- you want the debugger to appear 
as a native Windows app.  No X server.

So, cygwin's tk package is MSWin, not X.
There was some talk about providing a split personality version of tk 
(either X or MSWin, like XEmacs is) -- but that talk only got to the 
dabbling stage.  The current maintainer of tcl/tk, cgf, is 
understandably not enthusiastic about embarking on this effort.

However, if somebody else would like to make it happen, cgf might be 
convinced to turn over official maintainership of the package to that 
person.  Maybe.

--
Chuck



Re: LoadLibrary(cygx11-6.dll) results in STATUS_ACCESS_VIOLATION

2004-10-24 Thread Charles Wilson
Alexander Gottwald wrote:
I am trying to write an x client application that will run on a windows xp
machine. When I try to load any X related dll (in order to be able to call
for example XOpenDisplay) the executable exits whith the message
5 [main] test3 2820 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
648 [main] test3 2820 open_stackdumpfile: Dumping stack trace to
test3.exe.tackdump
This dump occurs when the system tries to load the library.

Why not link the library directly into the program? I'm not sure if LoadLibrary
works well with cygwin dlls.
LoadLibrary usually works okay --- but it'd certainly be better, from a 
cygwin POV, to use cygwin1.dll's dlopen() instead.  And there is 
sometimes a good reason to avoid direct linking: what if you want to 
turn on various windowing/GUI modes...e.g. rxvt on cygwin can 
currently be used without an Xserver running, without even having the X 
libs installed.  If $DISPLAY is :0, it never tries to load the X stuff, 
but simply uses Windows GDI.  If the Xlibs were linked directly into the 
app, you'd always have to have the Xlibs installed, even if you didn't 
want to ever use rxvt in X11 mode.

--
Chuck


Re: Installing tcltk does not force installation of XFree86-prog

2004-03-18 Thread Charles Wilson
Marc Daumas wrote:
...although X11/Xlib.h is needed.
You've stuck your finger right on a sore spot.

tcltk is a *native MS windowing* port of tk (tcl is GUI-agnostic; tk is 
the important bit wrt display technology).  The X11/Xlib.h file that 
cygwin's tk wants is NOT the one distributed by cygwin-xfree.  Neither 
will tk work with the X11/Xlib.h file distributed with xpm-nox.

Both tk and xpm-nox have their own fake Xlib.h files -- xpm-nox ships 
it in /usr/local/xpm-nox/X11/xlib.h.  cygwin's tk doesn't ship its 
version of that file at all.

Go here
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
and download
tk-includes-8.4.tar.bz2
Unpack it somewhere so that you can explicitly use
  -I /this/way/to/tk's/X11/Xlib.h
but be careful not to clobber the real X11/Xlib.h
--
Chuck


Re: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault

2003-12-04 Thread Charles Wilson
Brian Ford wrote:
Charles Wilson,

Could you look at the problem discovered in the thread below and give us a
comment?  Thanks.
http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html
There are a couple of problems.

  1) OOB, DDD uses libtool-1.4.2 -- which has very minimal support for 
cygwin.  It works (barely) -- and it takes a whole chapter in the 
autobook http://sources.redhat.com/autobook/ to explain the differences 
from normal unix shared lib creation.  The new 1.5+ procedure (with 
binutils/gcc autoimport, autoexport, and .dll.a naming convention 
support) is much more unix-like.  Although ltmodules don't seem to work 
very well, except in toy cases. :-(

  2) Old libtool, when it finds a .la file (which specifies the DLL 
name and the static lib name, AND the import lib name) doesn't appear to 
handle the implib properly -- it thinks that it does not exist, and 
attempts to recreate it from scratch using the export table from the 
DLL.  But it uses old, buggy, obsolete, unmaintained, code to do so.

Now, there are only four libraries in your link list that have .la 
files: expat, fontconfig, freetype, and Xm.  And whaddaya know -- those 
are precisely the libs that cause problems in your link command.

QuickNDirty answer: hide those four .la files and re-run configure.

Long answer: update to the most recent autotools (relibtoolize). 
However

bash-2.05b$ autoreconf --install --force


These are just warnings, so I think this part worked fine.  I guess the
ddd people should clean these up?
Yes, they should -- when they are ready to move to autoconf-2.5x, 
automake-1.7.x, and libtool-1.5+.  But as you can see, there are 
incompatibilities between autoconf-2.13 and -2.5x.  Basically, you CAN 
write a configure.in file that works with both -- but 2.13 was much more 
forgiving than 2.5x, so most existing configure.in's need to be brought 
up to 'spec' in order to work with 2.5x.

And the _easiest_ way to do THAT is to make changes to the configure.in 
that are NOT backwards compatible with 2.13!  So, it's possible to allow 
both versions to work with your configure.in, but much harder than just 
upgrading in a non-backwards-compatible way.

So most projects (like gcc/binutils until recently) have taken a 
wait-and-see approach to autoconf-2.5x.  Which leaves us poor cygwin 
folks, who NEED libtool-1.5 for decent DLL support, out in the cold -- 
because libtool-1.5 requires automake-1.7.x which requires autoconf-2.5x...

(And, even though it is conceivable to use ac-2.5x with old-style 
automake-1.4p6, the cygwin wrapper system doesn't let you do that.  So, 
if you re-autoconf with ac-2.5x, you'll also need to re-automake with 
am-1.[67].x -- which brings its own share of possible incompatibilities 
in the Makefile.am's.  And you'll want to add -no-undefined to the 
libX_LDFLAGS setting for any libraries that DDD builds)

configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
autoconf/specific.m4:363: AC_CYGWIN is expanded from...
configure.ac:248: the top level
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see
the
autoheader: WARNING: documentation.
Yep, you're gonna have to take care of this stuff by hand.  I believe 
that support for config.h.top etc will be going away in autoconf-2.60, 
but that's **just** a guess.  And anyway, 2.60 isn't expected for at 
least several months (and 2.59 won't go 'poof' then, anyway)

Here is where we should have stopped, although I don't know how to do
that with autoreconf.  The following are errors from subdirectories that
use older (circa 2.13) autoconf scripts.  autoreconf does not support
mixed versions, I guess?
No, not at all.  That's why Zack Weinberg (Nathaniel Nerode?) over on 
the gcc list are updating gcc's (and friends') configure.in's by hand, 
one directory at a time.

Bringing the autotool infrastructure up to snuff for a large project, 
like DDD, is a significant challenge.  And it's not a job that anyone 
really wants to do -- so if you've the itch, the only person who will 
scratch it is you.  You'll need to do all this work yourself, and then 
send your patches back to the DDD developers as a fait accompli, and 
HOPE that they are ready to 'take the plunge', accept your patch, and 
**force all of their developers to switch to using the new autotools**.

It's that last bit that causes trouble.  And until they accept the 
patches and take the plunge, you'll

Re: Updated: xfig-3.2.4-4 and xfig-lib-3.2.4-4

2003-10-29 Thread Charles Wilson
Harold L Hunt II wrote:

2) Consolidate the packages into xfig-lib (graphic symbols library), 
xfig (everything else).

When you remove packages completely, you need to provide a compatibility 
 package that has the same name but higher version number.  That way, 
setup.exe will Do The Right Thing:

1) update obsolete package xfig-etc (or whatever)
   --- remove xfig-etc(old version)
   --- install xfig-etc(new version)
2) update xfig
   --- remove xfig(old)
   --- install xfig(new == consolidated)
But setup reshuffles this into remove and install:

1) remove xfig-etc(old version)
   remove xfig(old)
2) install xfig-etc(new version = empty, so this is a no-op)
   install xfig(new == consolidated)
And everything Just Works.  If you DON'T do that, then setup.exe would 
just update xfig -- but both xfig-etc(old) and xfig(new) would claim to 
own the files that were consolidated into xfig(new).

So, compatibility packages.  (Now, it's possible that setup.exe could 
[does?] support conflicts: and obsoletes: keywords, in which case that's 
a better solution than compat pkgs.  Ask Robert...)

Me, since I'm paying attention, I'll just do it manually: setup-remove 
all currently installed xfig-related packages, and then setup-install 
just the new pkgs.  But not everybody pays attention -- or reads these 
little announcements.

--
Chuck


Re: AW: cygwin.rules - Enabling shared libXt finally?

2003-10-21 Thread Charles Wilson
Errm, this isn't going to change the public interface is it?  That is, 
if Harold releases another libXt with this change, would that break the 
recently re-compiled and released lesstif, etc etc?

--
Chuck
Ralf Habacker wrote:

Not sure I understand.  What should be changed in the current version of 
the Xt code?


only note 1, chaning the label. The second note is only for completeness. 



Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. 
Please send a diff against these if anything should be changed.  Note 
that these are intentionally from the 4.3 branch.

--- Initialize-old.c   2003-10-21 20:21:18.0 +0200
+++ Initialize.c   2003-10-21 20:23:25.0 +0200
@@ -236,8 +236,8 @@
 asm (.data\n\
  .globl __XtInherit\n\
- __XtInherit:  jmp *_$$y \n\
-  _$$y: .long ___XtInherit   \n\
+ __XtInherit:  jmp *__$XtInherit \n\
+ __$XtInherit: .long ___XtInherit   \n\
 .text \n);
 #define _XtInherit __XtInherit



Re: [ITP] freetype2 2.1.5

2003-10-21 Thread Charles Wilson
Harold L Hunt II wrote:
Original from http://www.freetype.org/

Questions for other maintainers
===
1) freetype2 is built as part of XFree86 right now as a shared library, 
but configuring with --enable-shared and --disable-static doesn't 
produce a .dll when building the standalone tree.

2) Any tips for getting the standalone tree to emit a shared library?  I 
tried relibtoolizing it (aclocal, autoheader, autoconf, libtoolize, 
forcing copy of files) to no avail.
Well, it's a bit confusing to me without actually running configure 
myself, but I can't tell if fontconfig really actually use 
autoconf/automake/libtool the right way, or if instead it merely uses 
them to generate a JamFile for the 'jam' package building tool.

3) There is a warning coming from libtool:

libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin 
shared libraries
Well, that's either (a) a warning that the relevant libtool link command 
line does not contain the -no-undefined flag, which indicates that the 
maintainer asserts that the library will have no undefined symbols at 
link time, or (b) an indication that, contrary to expectations, the 
library DID have undefined symbols at link time.

When I get a chance, I'll download your source and see what I can make 
of it.  Ping me if you don't hear in a few days.

--
Chuck




Re: AW: Enabling SHM support in default build of XWin.exe

2003-09-17 Thread Charles Wilson
Ralf Habacker wrote:


... if linked to the static ipc-library. Using the cygipc dll results in an
additional runtime dependency, which will produce windows runtime linking
errors if the cygipc package isn't installed, which will produce more
support noise dealing with this issue. Using the static library avoids this
problem.
I think that you *should* use the DLL.  And add cygipc to the setup.hint 
requires: of XFree86.  Not because I think that everyone should or will 
'turn on' the daemon, but because:

you can't use libtool to make a DLL that has static dependencies 
(without heroic effort).

Now, I know that XFree86 does not use libtool, but maybe I want to build 
gtk or something that (a) does, and (b) links to XFree86 libs.   Since, 
in this scenario, the XFree86 libs will have a link time dependency on 
libcygipc.a -- I won't be able to build a DLL version of gtk (without 
heroic effort).

What's the support issue you're worried about, Ralf?  One more 
requires: library?  When Harold is busy spinning out expat, fontconfig, 
and freetype -- what's one more?

--
Chuck



Re: cygwin 1.5.3-1

2003-09-04 Thread Charles Wilson
Ralf --
  What happens when you run your cygipc-based build of X11, but do not 
have the ipc-daemon running?  You can't run KDE, of course, but does the 
Xserver itself still work properly?  Can non-KDE X apps work?

--
Chuck
Harold L Hunt II wrote:

Well, that makes it easy.  SHM will not be supported by this new build.

Harold

Christopher Faylor wrote:

On Thu, Sep 04, 2003 at 04:45:34PM -0400, Harold L Hunt II wrote:

I am not sure.  How automagically is the IPC daemon installed?  If 
it requires user intervention, then we cannot really have XShm in the 
default install.


You could make it a setup.hint dependency, of course, but that's only
half the battle.  The next step would be to get the cygipc daemon
started.  I don't think you want to go through that pain unless there is
a clean fallback for when cygipc isn't working right.




Re: Error building glib-2.2.1 from source 8-(

2003-03-03 Thread Charles Wilson
You have to re-libtoolize using the latest libtool.  I posted a patch 
(for 2.2.0) to the main cygwin list on Jan 03, 2003.

--Chuck

Chris Olive wrote:
I'm trying to build glib from source (from www.gtk.org FTP mirror), and I end up with the following error during make:

OUTPUT
make[2]: Entering directory `/cygdrive/c/xfer/glib-2.2.1/gobject'
/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall  -o libgobject-2.0.la -rpath /usr/local/lib -version-info 200:1:200 -export-dynamic -no-undefined gboxed.lo gclosure.lo genums.lo gobject.lo gparam.lo gparamspecs.lo gsignal.lo gsourceclosure.lo gtype.lo gtypemodule.lo gtypeplugin.lo gvalue.lo gvaluearray.lo gvaluetransform.lo gvaluetypes.lo ../glib/libglib-2.0.la -lintl  

*** Warning: This system can not link to static lib archive ../glib/libglib-2.0.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: warning: `/lib/libintl.la' seems to be moved
/OUTPUT
I've tried ./configure --enable-shared=yes (it's 'yes' by default anyway), but this seems to have no effect.  As to the libtool warning after the error, '/lib/libintl.la' seems to be moved, this seems to be bogus since the file IS there.

My guess is that somehow libtool is not resolving libraries properly, but I'm not really at all familiar with how this all works under Cygwin (I know there are .a and .DLL mapping things going on, but that's about it.)  My version of libtool is 1.4.3.

Any help getting over this hump would be appreciated.  I loathe bothering people on lists unless I'm just out of options, which I feel I a (again after much research).  I don't see any other options under ./configure for building glib-2.2.1 that present any other possibilities.

Even if there is no known solution, if someone could just help me decipher the above errors -- what it probably means -- I can go from there most likely.





Re: how to enable magic cookies on W2K cygwin X11?

2003-02-18 Thread Charles Wilson
Alexander Gottwald wrote:
[some stuff about magic cookies]

cygutils contains the mcookie program from util-linux, if that helps. 
(It may not; I don't know much about X)

NAME
   mcookie - generate magic cookies for xauth

SYNOPSIS
   mcookie [-v] [-f filename ]

DESCRIPTION
   mcookie  generates a 128-bit random hexadecimal number for use 
with the
   X authority system.  Typical usage:
  xauth add :0 . `mcookie`

--Chuck



Re: new runtime pseudo-reloc in cygwin 1.3.18

2002-12-31 Thread Charles Wilson
Alexander Gottwald wrote:

So I don't even know where _XtInherit is called and whats different with the 
relocation.


gdb revealed:

Dll1 (libXt) defines void _XtInherit(). Dll2 (libXaw) uses _XtInherit and 
passes it to a function in libXt which does 
if (x == _XtInherit) { foo() };

Unfortunatly it is not the same if _XtInherit is used in libXt or libXaw. 
the statement x = _XtInherit for example resulted in
x = 0xb38478 for libXt and
x = 0x641550 for libXaw. And thats why the if condition failed. 

I seem to remember that pointer comparisons across a DLL boundary is a 
Bad Thing; relocations and such.  But I don't remember where I saw that 
-- MSDN or ld docs, and I can't find it now. :-(

--Chuck



Re: new runtime pseudo-reloc in cygwin 1.3.18

2002-12-27 Thread Charles Wilson


Alexander Gottwald wrote:

Alan Hourihane wrote:



I'm about to commit a patch to the XFree86 CVS that uses the new relocation
code in cygwin 1.3.18. This allows us to create the last few libraries
as shared code.



How will this affect people with cygwin 1.3.18?


It won't affect them (adversely).  All that matters is that the 
developer's system has cygwin = 1.3.18 (and developer also means 
anyone who is attempting to *compile* an X-based program, not just those 
who are compiling XFree86 itself).

E.g. pure users who don't compile anything, will be fine.  They can 
run the new binaries.

--enable-pseudo-reloc tells the linker don't worry about multi-word 
data imports; the runtime will fix them up.  And, the runtime is 
actually a snippet of *static* code that gets linked into the dll/exe -- 
this static code is included in libcygwin1.a.  Since it's static (e.g. 
not in cygwin1.dll), every compiled program/dll that needs it will have 
its very own copy; it doesn't matter if the user has an old version of 
cygwin1.dll.

--Chuck



Re: 8 bit PseudoColor problem

2002-12-08 Thread Charles Wilson
Harold L Hunt II wrote:


I wouldn't say that PseudoColor support is sketchy.  I mean, it works fine
either in fullscreen or if you are running Windows in 8 bit color mode.
Granted, PseudoColor is not available when you are running in windowed mode
with Windows set at higher than 8 bit color.


Correct.


Are you telling me that Cadence still does not work with Cygwin/XFree86 even
when you are using one of the two options outlined above?  That would be
disappointing because I did put a lot of time into the PseudoColor support
and I was pretty certain that it was working properly.  Hmm...


Well, it's also the fact that *cadence* uses PsuedoColor poorly.  It 
wants a private colormap, which means lots of fun colorflashing, unless 
you have support for multiple 256color psuedocolor maps within the same 
display.  AFAIK, only Solaris's Xserver actually implements this.

Now, Cadence is ALSO ugly when hosted by XWin32.  *But*, because Xwin32 
supports multiple windows, the ugliness only affects cadence, and not 
any other windows you might have open.  In my case, if I'm using an 
Xserver in full screen mode, then I tend to open up xterms and other 
windows inside it -- which means they all get affected by the 8bit 
colorflashing.

OTOH, if I'm Xhosting an app using an Xserver that supports multiple 
windows, then I open up cygwin rxvt (native) rxvt windows, and native 
windows editors, etc.  And only cadence is affected by the 8bit issue -- 
so it's tolerable.

As I said, it has been a long time since I've tried it using the 
cygwin-xfree server, but that's my recollection.

--Chuck



Re: 8 bit PseudoColor problem

2002-12-07 Thread Charles Wilson
He's referring to a very old message on this list concerning 8bit 
PseudoColor support in cygwin-xfree and Cadence.  Cadence is a CAD 
package that requires that feature -- and since PseudoColor support in 
cygwin-xfree is sketchy at best, you can't really use it to xhost 
cadence.  (Which is the primary reason I'm still using XWin32, personally).

Stephen -- nope, I don't think you can xhost cadence using cygwin-xfree 
yet.  (And next time, include a little background.  Not everybody 
instantly recalls every message on this list from the past four years)

--Chuck

Harold L Hunt II wrote:
Wow, with all of that information that you gave, we will be sure to 
answer your question very quickly!

Harold

Allott, Stephen wrote:

I have just run across this problem using Cadence and wondered if it 
ever got solved?




Re: Incorrect version in packages names

2002-07-14 Thread Charles Wilson



Ralf Habacker wrote:

The naming was probably inherited from linux, where it is possible to 
have both kde (1) and kde (2) and kde (3) all installed on the same 
machine.  Therefore, each needs different basename.

If the kde-cygwin folks want to maintain that package-name distinction, 
then they should just use kdelibs_2 instead of kdelibs-2 as their 
basename.  Then upset and setup will be happy -- and end users will be 
able to install both kdelibs_2 and kdelibs_3.


 What about kde-x. Must it be named kde_x ? 


No, kde-x is fine.  The problem is, the parser can't tell if the 
grouping after a '-' is part of the package name or package version, 
when the grouping begins with a numeral.

kde-2  -- confusinng
kde-x  -- not confusing

--Chuck





Re: [packages] gtk+, glib, imlib

2002-07-12 Thread Charles Wilson



Nicholas Wourms wrote:


 So?  Your point?  I don't want to run linux on this machine.  My question
 above was partially a joke and partially a rhetorical one.  I don't need
 to be lectured on the joy and simplicity of the explorer interface (tho
 neither seem to apply).  Let's not turn this into a Microsoft lovefest. 
 My point was that Rootless mode is a fluff setting, something that really
 isn't that important.  Perhaps a better use of time could be spent
 figuring out how to profile and improve the performance of the X server? 
 Or perhaps making truetype fonts easier for people to use in X?


Nicholas --
   There are lots of worthy areas why Xserv on cygwin can be improved. 
You have your priorities, other people have theirs.  Unfortunately, you 
ARE in the extreme minority, so you're going to have to sit back and 
watch rootless be discussed an implemented.  Probably before TT or 
profiling or ...

Why?

Go read the Slashdot thread from Sunday, 7 July 2002.  Almost every 
third message was It's pretty good, but it doesn't have a rootless 
mode.  All commercial Xservs on windows have one; this won't be a 
[serious|real|usable|finished] product until it does, too.

There was even one message that basically said This thing sucks ***. It 
doesn't have a rootless mode.  Okay, so the guy was a troll, but nobody 
contradicted him...

We even got two or three spill-over questions which were obviously 
stimulated by the Slashdot story, where folks we'd never heard of wrote 
to the mailing list to say Cygwin Xserver is really cool, but I 
[won't|can't] use it until it has a rootless mode.  When will that be?

Finally, and most importantly, Harold *wants* to work on a rootless 
mode.  He's scratching his own itch.  If you want to work on TT support, 
nobody is stopping you. -- go scratch.  g

--Chuck








Re: Incorrect version in packages names

2002-07-08 Thread Charles Wilson



Christopher Faylor wrote:


 upset would probably do the right thing with the above but I really don't
 see any reason to use it, regardless.  I don't see any reason why a user
 would need to know that these are kdelibs-2 when it is pretty obvious from
 the version number.


The naming was probably inherited from linux, where it is possible to 
have both kde (1) and kde (2) and kde (3) all installed on the same 
machine.  Therefore, each needs different basename.

If the kde-cygwin folks want to maintain that package-name distinction, 
then they should just use kdelibs_2 instead of kdelibs-2 as their 
basename.  Then upset and setup will be happy -- and end users will be 
able to install both kdelibs_2 and kdelibs_3.

--Chuck





Re: Problem with cygwin1.dll and xfree

2002-07-08 Thread Charles Wilson

Nicholas Wourms wrote:

 If I'm not mistaken, I believe WinCVS does tell them to put the dll in
 system.


If so, then they should be vigorously insulted, and possibly shunned. 
Think of the frenchmen in Monty Python's The Holy Grail.  However, I 
can't find anything prominent on their site that says put cygwin1.dll 
in naughty places.

--Chuck





Re: New xlauncher (was: Re: Success with Java prog in XFree)

2002-07-07 Thread Charles Wilson



Harold Hunt wrote:

 I haven't had any comments on this program yet because, while it is a neat
 exercise and will be useful for other work, it will not be distributed with
 Cygwin/XFree86 until it is written in a language that can be compiled with a
 free software compiler, preferrably gcc or g++.


That's a bit harsh.  If you're following the main list, you'll note that 
there is a large effort right now to get libgcj and the java extensions 
to gcc working, in the default cygwin gcc package.

If you can compile java code with cygwin's gcc, then java progs should 
be just dandy.

Of course, your java app must not rely on opaque native methods (e.g. 
the Java Foundation Crap^WClasses from MS)


--Chuck






Re: New xlauncher (was: Re: Success with Java prog in XFree)

2002-07-07 Thread Charles Wilson

Robert Collins wrote:

 * It's possible, but will need research. I think there is a mklink.exe or
 something in one of the packages that creates windows shortcuts for you.
 Make your package depend on that package.


mkshortcut.  It's in the cygutils package.

--Chuck






Re: New xlauncher (was: Re: Success with Java prog in XFree)

2002-07-07 Thread Charles Wilson

Harold Hunt wrote:

 
 That's fine about Java... but that last I knew this xlauncher was a Delphi
 app.  What have you got to say about that :)


WTF?  I don't follow the xfree list all that closely, but didn't this 
thread start out as Success with Java prog in XFree?  I just assumed 
that 'xlauncher' WAS that Java prog.  Sorry for the confusion.

You're right about delphi. :-)

On the other hand, there's no reason that Tim couldn't create a package, 
create a setup.ini, put it up on a web page, and tell folks to point 
setup there.  In fact, setup in its current form, without ANY changes, 
could be used to install just about anything that's shipped as a tarball 
-- the end user need only NOT select any official cygwin mirrors, and 
add user URLs for the desired targets.

--Chuck






Re: New xlauncher (was: Re: Success with Java prog in XFree)

2002-07-07 Thread Charles Wilson

Harold Hunt wrote:

WTF?  I don't follow the xfree list all that closely, but didn't this
thread start out as Success with Java prog in XFree?  I just assumed
that 'xlauncher' WAS that Java prog.  Sorry for the confusion.

 
 You know... sometimes I'm just not paying any attention at all.  What has
 happened to me?!?
 
 A Java xlauncher sounds fine to me, for now.  I'd eventually prefer that it
 be written in C or C++.
 
 How large are the Java runtimes for Cygwin?  I'm sure we'll get complains
 along the lines of, ``before I had to install 100 MB for Cygwin/XFree86, now
 I have to install XX MB more for the xlauncher program, blah''.  So I'm not
 really excited about sticking with Java forever.
 
 Feeling like an idiot,


You shouldn't.  You were correct originally.  The xlauncher program IS 
written in Delphi.

The first message in this thread contained the following postscript:

 PS: I am working on a xlauncher based on the one made available by Tim
 Thomson but for Cygwin(not only the cuted package from him).
 I want to include a file text that will contains some definition
 of servers to access (as IP address, OS, and so on).
 I will try to make it available. Where should I send it when ready
 (probably in 1 or 2 weeks) ?


That launched the subthread, which was properly marked using the [was: ] 
construction.

The problem here was *my* connection between the xlauncher subthread 
--- and java.


You're not the idiot -- I am.

--Chuck






Re: Using only the X server of Cygwin

2002-07-07 Thread Charles Wilson

Hey, Nicholas -- don't squish Rhialto that quickly.  He's probably one 
of our new users who knows nothing about the cygwin project except what 
he read on slashdot this morning.

The fact is, Rhialto, we focus on cygwin -- as an environment all by 
itself, *and* independent of any specific intended use or resource 
availability(*).  You have a specific setup, where you want to leverage 
you existing resources (e.g. a local linux-based font server) to avoid 
downloading extra stuff.

You are an advanced (linux) user, with a very specific purpose in mind. 
  That's not the target of the cygwin (or cygwin-xfree) project.  It 
*IS* possible to do what you want -- but there isn't a super-simple 
one-click path to do it.  [Think about user interface design: there can 
only be a limited number of 'easy' [one-click, two-click] 
configurations.  We use those for the normal users -- folks who want 
the cygwin environment, not folks who want JUST 'Xwin -broadcast' and 
nothing else -- or JUST ssh and nothing else).

However, it SHOULD be possible -- and checking the ml archives on this 
will help -- to create a custom 'setup.ini' script or pseudo-package 
that setup.exe can read, to install ONLY what you want -- but this will 
take a little work on your part.  Again, check the archives.

The basic thing is, setup is configured to install the 'Base' package by 
default (think Debian's 'base' category).  Base is about 50Meg unpacked 
I think.  Then, on top of that, there are certain things that the xserv 
program itself needs -- like libpng's DLL, zlib's DLL, etc.

 And it downloaded a
 lot more which it apparently did not even install, such as bash, diff,
 diffutils, fileutils, etc.


These are all part of the 'Base' category.  If you explicitly 
de-selected specific items -- even if they are in the 'Base' category -- 
then setup shouldn't even download them.  There may be a bug in 
setup.exe's handling of the Base category.  Sorry about that.


(*) that is, cygwin-xfree should work OOB on a standalong machine 
without any external font server, at least by default.  Do we really 
want a windows newbie to understand oh, I also need to install the 
fonts.  Of course not -- we do that by default IF the user installs X. 
  [Linux distros do this too, you know -- if you install XFree86 on Red 
Hat, you *will* get the fonts.]

--Chuck






gcc-3.1.x [was: Re: Using only the X server of Cygwin]

2002-07-07 Thread Charles Wilson

[follow up to the cygwin list; this is getting off-topic for cygwin-xfree.]

Nicholas Wourms wrote:

Hey, Nicholas -- don't squish Rhialto that quickly.  He's probably one 
of our new users who knows nothing about the cygwin project except what 
he read on slashdot this morning.
 
 I am still cranky about the refusal to include objc in cygwin/gcc-3.1.


Look, now is NOT the time for objc.  It's too early.

gcc-3.1.x is a MAJOR change from 2.95.3.  Let's make sure the transition 
hasn't broken the frontends we CURRENTLY have, before we worry about 
adding more frontends.

(IMO, this holds for java/libgcj, too)

gcc-2.95.3:
   provides gcc,g++, and g77.  gcc works in -mno-cygwin mode and 
regular mode.  g++ doesn't really work in -mno-cygwin mode, but it 
does work in regular mode, with certain threading and exception 
caveats.  g77 is regular only.

gcc-3.1.x:
Let's insure that cygwin's gcc-3.1.x still works in regular and 
-mno-cygwin mode.  Ditto g++ (and since cgf already made changes to 
enable better -mno-cygwin operation in g++, let's verify that, too). 
Does g77 still work?

The spec file has been totally rewritten.  Can we still build DLLs? 
Does auto-import still work (technically a binutils issue, but that's 
been upgraded for the first time in eight months just now, too).

How about exceptions and threading?  Supposedly those are better behaved 
now -- is it true?  What about raising exceptions from within DLLs -- 
cgf hinted that this probably won't work; also there's a recent binutils 
patch from Egor that should help with that issue but it hasn't yet been 
accepted b/c egor needs to fill out the assignment paperwork for 
FSF...PLUS egor has a cygwin kernel patch that USES his binutils patch...

My point: there's a LOT to do right now, with just gcc and g++.  Let's 
not borrow ObjC/Ada/Java trouble just yet.

Good grief, the first test release of cygwin-gcc-3.1 was ONLY released 
less than 24 hours ago.  !! Test what we HAVE, before piling on with 
feature requests !!

Boy, I'll bet cgf now knows what Linus feels like the day after a kernel 
freeze is announced...

--Chuck

P.S. follow up to the cygwin list; this is getting off-topic for 
cygwin-xfree.




Re: Possible bug of the M$ windows manager ? or, XFree bug ?

2002-06-06 Thread Charles Wilson

Nicholas Wourms wrote:

 People,
 
 For the love of God, bzip2 is there for a reason, please use it.  Some of
 us have high mail volume and low mailbox quotas.


actually, bzip2 would probably not do a very good job compressing a png. 
  (I said PROBABLY.  No need to post 27 counterexamples).  However, 
pngcrush would probably help.

--Chuck





Re: By the way...

2002-05-21 Thread Charles Wilson

Harold Hunt wrote:

 2) In libiconv-1.7-2.sh, prefix is set to 'prefix=/usr/local'.  That should
 be changed to '/usr' before this package is released, right?

Yes.

 I'm sorry Chuck.  I just read the link that you sent to an email that you
 wrote... with very detailed answers to both of my questions.

Don't sweat it.

  What Cygwin directory do you think libiconv should go in?

The regular one -- cygwin/release/*.  It's not x-specific.

But now that I look closer, you should probably refactor the .sh script 
to package things up right from the beginning:

release/iconv/
release/iconv/iconv-1.7-X.tar.bz2 (*)
release/iconv/iconv-1.7-X-src.tar.bz2

release/iconv/libiconv2/libiconv2-1.7-X.tar.bz2 (**)
release/iconv/libcharset1/libcharset1-1.7-X.tar.bz2 (**)

(*) contains everything except cygiconv-2.dll and cygcharset-1.dll
(**) the setup.hint file uses the 'external-source: iconv' incantation

I wouldn't bother with splitting out the development files into -devel 
packages -- iconv doesn't seem to version those as strongly as, for 
instance, libpng does.

--Chuck




Re: Repackaging of WindowMaker and openbox needed ?

2002-05-13 Thread Charles Wilson

Ton van Overbeek wrote:

 Now it seems that there is a consensus that all X specific stuff should
 go in /usr/X11R6/bin, /usr/X11R6/lib, 


Well, if you call Chuck reversing his original position, and Harold 
agreeing with Chuck's new position, and Earnie smugly thinking 'I was 
right all along' :-) -- and cgf saying basically 'I don't care' a 
consensus, then sure...

 etc. it seems to me that both
 WindowMaker and openbox should be repackaged to install in /usr/X11R6.
 Now both WindowMaker and openbox install into /usr/bin and /usr/lib etc.
 Maybe also libPropList is afected.


That's up to the WindowMaker/openbox/libPropList maintainerHarold, I 
guess.

--Chuck





Re: Repackaging of WindowMaker and openbox needed ?

2002-05-13 Thread Charles Wilson

Christopher Faylor wrote:


 Just to clarify, here's what I said:
 
 *I don't think I ever gave an opinion on the /usr/bin vs.
 */usr/X11R6/bin.  My preference is that all official X stuff goes in
 */usr/X11R6/bin but that seems to be counter to the way most modern
 *distributions do things.
 
 So, if we have good justifications for putting things in /usr/X11R6/bin
 then I'm happy.


Mostly here:


http://cygwin.com/ml/cygwin-xfree/2002-05/msg00178.html

http://cygwin.com/ml/cygwin-xfree/2002-05/msg00179.html


--Chuck




Re: lesstif mwm bug

2002-05-10 Thread Charles Wilson

Christopher Faylor wrote:


 I don't think I ever gave an opinion on the /usr/bin vs.
 /usr/X11R6/bin.  My preference is that all official X stuff goes in
 /usr/X11R6/bin but that seems to be counter to the way most modern
 distributions do things.
 
 So, I don't know that we have an actual policy.


I was one of the main proponents of all the other dists put everything 
into /usr/bin, so we should too.  Earnie raised the issue about 
binaries that can exist as either X- or MS-native-windowing, but not 
simultaneously as both in a single executable (e.g. rxvt).

I said fuhgeddaboutit until we actually SEE the problem.

And then I saw the problem.  tcl/tk.  The cygwin version that is 
currently distributed uses MS-native windowing, for lots of very good 
reasons.  It is installed into /usr/bin, /usr/include, /usr/lib.  But 
what if I want to build an X-based application with tk?  I'd need a 
X-based tk -- which obviously cannot go into /usr/bin, /usr/include, and 
/usr/lib.

So, now I think that REGARDLESS of what those other distributions do, 
we should segregate X- linked apps and libraries into /usr/X11R6/.  Very 
few other platforms have multiple windowing environments to deal with. 
The closest similarities I can think of are:

1) X- and terminal-.  Two common solutions:
   a) single binary, operates in either mode (FSF-Emacs)
   b) two different binaries with different names (vim, gvim)

2) X- and svgalib-.
   a) Two different binaries with the same name; only one may be 
installed on a system at a time (Mandrake's graphical Aurora bootup)
   b) two different binaries with different names ()

3) regular X and gtk
   a) two different binaries with the same name; only one installed on 
the system at a given time (XEmacs.  In fact, Mandrake for instance ONLY 
provides the gtk version; the normal X- version is no longer available 
officially).

But, these are all VERY rare.  Of the thousands of apps out there, most 
are JUST terminal, or JUST X-, or JUST svgalib.   The conflicts just 
haven't happened often enough for the distributions to come up with a 
cohesive plan -- they just seem to special case the rare conflicts.

I think Earnie's right: these problems will not be rare for us.  We want 
native-windowing apps, and we want X-windowing apps, and sometimes, we 
want the same program in either/both/ forms (tk, XEmacs, rxvt, gtk(?), 
etc).

To see a real comparison between what they do and what we do, imagine 
what would happen if Berlin or W or another 2nd-generation X became 
really popular...

So, finally, in summary, IMO, X- linked apps should be compiled and 
installed with --prefix=/usr/X11R6/

--Chuck





Re: Legacy Installation of XFree86/Cygwin vs. Setup.exe XFree86 Packages

2002-05-09 Thread Charles Wilson

Randall R Schulz wrote:

 More problem 
 symptoms followed. When the boot process completed the hardware scan and 
 got to the point where the Welcome to Windows 2000 low-resolution 
 splash screen would be taken down and the monitor resolution switched, I 
 instead got a long period of disk activity, which I took to be an 
 automatically invoked file system check (I have all NTFS systems, so I'm 
 not used to this happening and it alarmed me). There was no indication 
 of what was happening (as their ordinarily would be for a checkdsk, 
 either manually requested or automatically invoked). However, once that 
 was done, the system booted normally. Nonetheless, I don't like things 
 like this happening to my system.


Actaully, I think the long delay was the copy-on-reboot stage of the 
cygwin upgrade.  I vaguely remember something about XFree needing to 
update a LOT of in use files, so setup puts those files in the 
copy-on-reboot list.  Fonts?  Anyway, copying hundreds of files, one at 
a time, can take a while...

We should probably warn people about this; they could really scrog their 
cygwin if they interrupt the copy-on-reboot.

--Chuck





Re: MIT shared memory extension

2002-05-06 Thread Charles Wilson

Robert Collins wrote:

 
-Original Message-
From: Ralf Habacker [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, May 07, 2002 7:41 AM

 
What about using a new type respective casts for cygdaemon. 
This would not break key_t compatibility and allows to 
migrate single application to cygdaemon, while others works 
with cygipc (at least for a limited time) ?

 
 At the moment key_t's are generated locally without the cygserver. This
 means that in theory a cygipc linked app will still work with the new
 key_t code after recompiling (I think we do need to remove ftok from
 cygipc at that point though). If we have a list of key_t's, then it must
 be global, so cygserver will have to be running. I think that that is
 bad.


Hmmm???  Where would clients get ftok() from, then?  Do the cygserver 
patches to CVS cygwin1.dll add that function to the kernel?

  
 Also at the moment, we know that the same file will generate the same
 key_t every time. (because it's inode based). 


Ah, a quick 'cvs update' and I see the answer to my question is yes. 
So, I can't really remove ftok() from cygipc until after cygwin-1.3.11 
is released...


 In short, I don't like the idea of making key_t 32 bits.


Yep.

--Chuck







Re: MIT shared memory extension

2002-05-03 Thread Charles Wilson

Ralf Habacker wrote:

It is possible though to compile xfree86 for cygwin with that enabled,
but it haven't been tested, check the mailinglist.

 
 It works, we have done so for the kde-cygwin port 


Yeah, but it requires CygIPC, doesn't it?

BTW, has anybody tried to run kde-cygwin using the new cygwin-daemon to 
provide the IPC services?  Currently, the cygwin daemon implements some 
subset of the three main IPC mechanisms (semaphores, messages. shared 
memory) -- but I don't remember if shm was part of that subset...

Anyway, even if the cygwin-daemon DOES provide the necessary IPC 
features, you'd probably need to recompile kde-cygwin against it instead 
of CygIPC.

--Chuck

the cygwin-daemon code was recently merged into CVS; the snapshots have 
the functionality but the daemon itself is not turned on by default. 
Just like ipcdaemon.exe, you have to start up the cygwin-daemon 
yourself.  For more info, see the cygwin-developers mailing list archives.





Re: pkgconfig [Was By the way... ]

2002-05-01 Thread Charles Wilson

Steven O'Brien wrote:

 
 There was no circular dependency for glib-1.2.10. In fact when I ported
 it I had never heard of pkg-config. 


Oh, I misunderstood you.  When you said you configured pkgconfig to 
build against your installed version of glib, I thought your installed 
version was 1.3.x, not 1.2.10.  (1.3.x does depend on pkgconfig)

Sorry for the confusion.

 Anyway, I have built
 pkgconfig-0.12.0, with your patch, and gnome-vfs configure works fine
 with it. So if/when it is adopted as the official cygwin version I
 will remove pkg-config from my website.


Look for an updated package soon, and thanks for taking the time to test 
this.

--Chuck







Re: mkdll.sh

2002-04-30 Thread Charles Wilson

You could probably do the following:

get rid of mkdll.sh
relibtoolize/autoconf using the -devel tools (e.g. make sure that 
configure.in has AC_PREREQ(2.52))

./configure; make;

It oughta work. /famous last words

--chuck


Harold Hunt wrote:

 Steve,
 
 I'm working on creating Cygwin setup.exe packages for Gnome... I know, it's
 buggy but I'd like to get a start.  One problem I'm having with your patches
 is that they use mkdll.sh but they don't cause configure to copy the file to
 a build directory.
 
 For example:
 
 tar xzf glib-1.2.10.tar.gz
 cd glib-1.2.10
 patch -p1  ../glib-1.2.10-cygwin.patch
 mkdir build
 cd build
 ../configure
 [yada yada yada]
 make
 [yada yada yada]
 mkdir .libs
 ar cru .libs/libglib.a  garray.o gcache.o gcompletion.o gdataset.o gdate.o
 gerro
 r.o ghash.o ghook.o giochannel.o giounix.o glist.o gmain.o gmem.o
 gmessages.o gm
 utex.o gnode.o gprimes.o grel.o gscanner.o gslist.o gstrfuncs.o gstring.o
 gtimer
 .o gtree.o gutils.o
 ranlib .libs/libglib.a
 creating libglib.la
 (cd .libs  rm -f libglib.la  ln -s ../libglib.la libglib.la)
 cd .libs  PREFIX=/usr sh ../mkdll.sh libglib.la
 ../mkdll.sh: Can't open ../mkdll.sh: No such file or directory
 make[2]: *** [libglib.la] Error 2
 make[2]: Leaving directory
 `/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
 10/.build'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory
 `/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
 10/.build'
 make: *** [all-recursive-am] Error 2
 
 
 Eventually I always reach a point where mkdll.sh can't be found because
 configure didn't copy it to the out-of-the-tree build directory.
 
 Got any ideas on how to fix this?
 
 Harold
 
 
 





Re: By the way...

2002-04-30 Thread Charles Wilson

Harold Hunt wrote:

 ... I added a link to your Cygwin Gnome page to Cygwin/XFree86's Ported
 Software page:
 http://xfree86.cygwin.com/ported-software.html
 
 I'm very impressed with your work to compile Gnome with DLLs.  Keep it up!


A couple of things:

1) pkgconfig.  I'm the cygwin pkgconfig maintainer, and I'd like to 
insure that you can use the official version in your port.  You are 
using a patched version of 0.8.0; cygwin distributes 0.10.0; but 0.12.0 
is now available.  Could you try 0.12.0 (unpatched and/or patched) and 
see if that works for you?

If you must use a patched version of 0.12.0, then I'd consider 
incorporating that patch into the official cygwin dist; also, in that 
case, we could submit your patch upstream for incorporation into the 
real 0.13.0...

2) libiconv/gettext: If someone 'adopts' my setup-compatible package for 
libiconv -- see thes3 messages:
http://cygwin.com/ml/cygwin/2002-04/msg01558.html
http://cygwin.com/ml/cygwin/2002-02/msg00467.html

and it is included in the official cygwin dist, then I would rebuild the 
official gettext package to use it.  (Yes, I'm also the cygwin gettext 
maintainer).

3) cygextras: why not submit these as patches to the cygwin DLL? If it 
is because the code is from gnu libc, then you could in partnership with 
someone else, reimplement them and submit the result: your partner would 
actually write the code to the specifications you develop; you would 
verify that the result operates the same as the current version. 
(Chinese Firewall).  Then, assign copyright on the reimplementations 
to Red Hat/Cygwin, and submit!

4) berkeley db: folks have been asking for this for a long time.  Would 
you consider packaging it up and submitting it as an official package? 
(Don't worry about the tcl thing; you needn't be able to run the test 
suite on an official ports only system).  side note: any idea why 
Gnome doesn't use the GNU database instead? gdbm?

5) libungif: just like libiconv, I have a setup-compatible package for 
this.  If someone wants to adopt it and submit it for official 
inclusion, contact me offline.

--Chuck






Re: mkdll.sh

2002-04-30 Thread Charles Wilson
=${sysconfdir} \
   --libdir=${prefix}/lib --includedir=${prefix}/include \
   --enable-shared --enable-static )
}


  Is the general idea here that I would just be working on the config files
  and makefiles, rather than having to make extensive internal changes 
to the
  way that libraries are loaded?


Yes.

--Chuck


Harold Hunt wrote:

 Chuck,
 
 Could you give a few more notes on relibtoolize?  A pointer to some good
 documentation would be helpful...
 
 Is the general idea here that I would just be working on the config files
 and makefiles, rather than having to make extensive internal changes to the
 way that libraries are loaded?
 
 Harold
 
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson
Sent: Tuesday, April 30, 2002 2:48 AM
To: [EMAIL PROTECTED]
Cc: cygx
Subject: Re: mkdll.sh


You could probably do the following:

get rid of mkdll.sh
relibtoolize/autoconf using the -devel tools (e.g. make sure that
configure.in has AC_PREREQ(2.52))

./configure; make;

It oughta work. /famous last words

--chuck


Harold Hunt wrote:


Steve,

I'm working on creating Cygwin setup.exe packages for Gnome...

I know, it's

buggy but I'd like to get a start.  One problem I'm having with

your patches

is that they use mkdll.sh but they don't cause configure to

copy the file to

a build directory.

For example:

tar xzf glib-1.2.10.tar.gz
cd glib-1.2.10
patch -p1  ../glib-1.2.10-cygwin.patch
mkdir build
cd build
../configure
[yada yada yada]
make
[yada yada yada]
mkdir .libs
ar cru .libs/libglib.a  garray.o gcache.o gcompletion.o

gdataset.o gdate.o

gerro
r.o ghash.o ghook.o giochannel.o giounix.o glist.o gmain.o gmem.o
gmessages.o gm
utex.o gnode.o gprimes.o grel.o gscanner.o gslist.o gstrfuncs.o

gstring.o

gtimer
.o gtree.o gutils.o
ranlib .libs/libglib.a
creating libglib.la
(cd .libs  rm -f libglib.la  ln -s ../libglib.la libglib.la)
cd .libs  PREFIX=/usr sh ../mkdll.sh libglib.la
../mkdll.sh: Can't open ../mkdll.sh: No such file or directory
make[2]: *** [libglib.la] Error 2
make[2]: Leaving directory
`/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
10/.build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2.
10/.build'
make: *** [all-recursive-am] Error 2


Eventually I always reach a point where mkdll.sh can't be found because
configure didn't copy it to the out-of-the-tree build directory.

Got any ideas on how to fix this?

Harold






 



diff -urN libiconv-1.7-orig/CYGWIN-PATCHES/libiconv.README 
libiconv-1.7/CYGWIN-PATCHES/libiconv.README
--- libiconv-1.7-orig/CYGWIN-PATCHES/libiconv.READMEWed Dec 31 19:00:00 1969
+++ libiconv-1.7/CYGWIN-PATCHES/libiconv.README Mon Feb  4 18:46:11 2002
@@ -0,0 +1 @@
+placeholder
diff -urN libiconv-1.7-orig/acinclude.m4 libiconv-1.7/acinclude.m4
--- libiconv-1.7-orig/acinclude.m4  Wed Dec 31 19:00:00 1969
+++ libiconv-1.7/acinclude.m4   Mon Feb  4 18:48:03 2002
@@ -0,0 +1,363 @@
+dnl local autoconf macros
+dnl Bruno Haible 2001-02-04
+dnl Marcus Daniels 1997-04-10
+dnl
+AC_PREREQ(2.50)dnl
+dnl
+dnl without AC_MSG_...:   with AC_MSG_... and caching:
+dnl   AC_TRY_CPP  CL_CPP_CHECK
+dnl   AC_TRY_COMPILE  CL_COMPILE_CHECK
+dnl   AC_TRY_LINK CL_LINK_CHECK
+dnl   AC_TRY_RUN  CL_RUN_CHECK - would require cross-compiling support
+dnl Usage:
+dnl AC_TRY_CPP(INCLUDES,
+dnlACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl CL_CPP_CHECK(ECHO-TEXT, CACHE-ID,
+dnl  INCLUDES,
+dnl  ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl AC_TRY_xxx(INCLUDES, FUNCTION-BODY,
+dnlACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl CL_xxx_CHECK(ECHO-TEXT, CACHE-ID,
+dnl  INCLUDES, FUNCTION-BODY,
+dnl  ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl
+define(CL_CPP_CHECK,
+[AC_MSG_CHECKING(for $1)
+AC_CACHE_VAL($2,[
+AC_TRY_CPP([$3], $2=yes, $2=no)
+])
+AC_MSG_RESULT([$]$2)
+if test [$]$2 = yes; then
+  ifelse([$4], , :, [$4])
+ifelse([$5], , , [else
+  $5
+])dnl
+fi
+])dnl
+dnl
+define(CL_COMPILE_CHECK,
+[AC_MSG_CHECKING(for $1)
+AC_CACHE_VAL($2,[
+AC_TRY_COMPILE([$3],[$4], $2=yes, $2=no)
+])
+AC_MSG_RESULT([$]$2)
+if test [$]$2 = yes; then
+  ifelse([$5], , :, [$5])
+ifelse([$6], , , [else
+  $6
+])dnl
+fi
+])dnl
+dnl
+define(CL_LINK_CHECK,
+[AC_MSG_CHECKING(for $1)
+AC_CACHE_VAL($2,[
+AC_TRY_LINK([$3],[$4], $2=yes, $2=no)
+])
+AC_MSG_RESULT([$]$2)
+if test [$]$2 = yes; then
+  ifelse([$5], , :, [$5])
+ifelse([$6], , , [else
+  $6
+])dnl
+fi
+])dnl
+dnl
+dnl CL_PROTO(IDENTIFIER, ACTION-IF-NOT-FOUND, FINAL-PROTOTYPE)
+define(CL_PROTO,
+[AC_MSG_CHECKING([for $1 declaration])
+AC_CACHE_VAL(cl_cv_proto_[$1], [$2
+cl_cv_proto_$1=$3])
+cl_cv_proto_$1=`echo [$]cl_cv_proto_$1 | tr -s ' ' | sed -e 's/( /(/'`
+AC_MSG_RESULTPROTO([$]cl_cv_proto_$1)
+])dnl
+dnl
+dnl CL_PROTO_RET(INCLUDES, DECL, CACHE-ID, TYPE-IF-OK, TYPE-IF-FAILS)
+define(CL_PROTO_RET,
+[AC_TRY_COMPILE([$1]
+AC_LANG_EXTERN[$2

Re: By the way...

2002-04-30 Thread Charles Wilson

Steven O'Brien wrote:
  1) pkgconfig.  I'm the cygwin pkgconfig maintainer, and I'd like
 
  I'll add that to the list of jobs ... When I started work on
  gnome-vfs pkg-config was not in the official cygwin distribution
  and 0.8.0 was the latest version. I patched it to remove the
  included glib, so that it uses my glib port. When pkgconfig was
  added to cygwin I tried it, but gnome-vfs would not build, so I
  just ignored it. My focus was, and still is, on gnome so doing more
   work on pkgconfig was of no interest. But I'll certainly try the
  new one.

What was the rationale for removing the included glib?  It was put into 
pkgconfig in order to break the recursive dependence: glib requires 
pkgconfig which requires glib which ...

Granted, the version of glib included in pkgconfig is old (but it's 
capable enough for what pkgconfig needs) and has a one-line bug when 
compiling on cygwin; I just patch that and move on...

Anyway, if your version of pkgconfig (0.8.0 + local glib) compiled 
gnome-vfs (on a particular date), yet the official cygwin version of 
pkgconfig (0.10.0) failed to do so:

I would think the problem is either:
   something broke in the real pkgconfig sources between 0.8.0 and 0.10.0
or
   gnome-vfs (on the particular date) was either exploiting a bug in 
pkgconfig-0.8.0, or was otherwise broken.

I don't think the answer is to use (and recommend) that cygwinners who 
want gnome use a old version of pkgconfig with a circular dependency...

Thanks for offering to try with real pkgconfig-0.12.0.  You'll 
probably need to apply this patch (if you keep the included static glib):

--- pkgconfig-0.10.0-orig/glib-1.2.8/gstrfuncs.cMon Apr 17 
11:05:16 2000
+++ pkgconfig-0.10.0/glib-1.2.8/gstrfuncs.c Sat Feb 23 01:38:15 2002
 -671,7 +671,7 
char *msg;

  #ifdef HAVE_STRSIGNAL
-  extern char *strsignal (int sig);
+  extern const char *strsignal (int sig);
return strsignal (signum);
  #elif NO_SYS_SIGLIST
switch (signum)

I look forward to seeing the results of your experiment.

  If you must use a patched version of 0.12.0, then I'd consider 
incorporating
   that patch into the official cygwin dist; also, in that  case,
  we could submit your patch upstream for incorporation into the  real
   0.13.0...
 
 
  As the patch just removes the embedded glib, I think its of no use
  to the real pkgconfig.

Yep, you're right.

  3) cygextras: why not submit these as patches to the cygwin DLL?
 
  cygextras contains strptime and getdelim. I understand the strptime
  is coming soon to cygwin anyway, so I'll just drop mine then.
  getdelim came from the gnu C library. Again its just a distraction
  from working on gnome, and I'll leave it to others to add it to
  cygwin.

Understood.

  4) berkeley db: folks have been asking for this for a long time.
 
  No. I don't have any free time to support cygwin packages, although
  I do have great respect for those, such as yourself, who do. I
  think that gnome no longer requires version 2.7.7, but has moved on
   to version 3.x.x. This patched version did actually pass its test
  suite when I first did it, but I no longer have access to the
  cygwin tcl port I used, so I cannot reproduce the result.

'Kay.  Looks like there's a volunteer on the case...

--Chuck




Re: cygjpeg6b.dll not found

2002-04-29 Thread Charles Wilson

Dawson, David W wrote:

 Goodness!!
 
 
cygjpeg6b.dll is part of the jpeg package of Cygwin.

 WindowMaker depends upon this package.
 As noted in another post, WindowMaker also depends on the tiff package.

 Now that it has become evident that WindowMaker also needs these
 (non-default) packages, it could be so-noted in Howard's setup.ini file.
 (IIF he wants to.)


Actually, this is a packaging error in windowmaker.  The setup.hint / 
setup.ini MUST list the required dependencies, for packages intended for 
distribution via the offiical mirror network.

requires:    tiff jpeg

should appear in the setup.hint.  Then, when the website maintainer runs 
upset, setup.ini will specify the correct dependencies -- and when a 
users runs setup.exe and selects windowmaker, setep will automatically 
select the tiff and jpeg packages to satisfy those dependencies.

Cool, huh?

--Chuck




Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing

2002-04-21 Thread Charles Wilson

Robert Collins wrote:

 
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, April 21, 2002 8:33 AM

 
if you select the source for more than one of [bob|bobx|boby], then it 
is downloaded only once (good) but is unpacked three times.  This isn't

 
a terrible thing, but it is a waste of effort

 
 This won't change anytime soon. Long term we'll have the concept of a
 source package - as opposed to a src attribute of an existing package.
 This will require setup.ini changes to represent properly, so I want all
 the kinks out first...


Like I said, NOT a showstopper.  you ONLY see this behavior if you click 
the src checkbox for multiple packages that all share the same source. 
It's only downloaded once.  When setup is done, you have the source. 
Behind the scenes, that source package gets installed multiple times. 
Big deal.

IMO, if upset gets the ability to do the right thing with an 
'external-src:' directive in setup.hint, then everything necessary for 
multiple-bin/single-src packages would be in place.

--Chuck


--Chuck





Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing

2002-04-20 Thread Charles Wilson



Robert Collins wrote:

 
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, April 20, 2002 12:59 PM

 
Also, setup must do the following (even without new 'views' 
and whatnot)

 
 Setup should already do that, why not make a test setup.ini and see what
 happens :]. It's all data driven and there is no requirement for -src
 packages to follow the same name as the base.

Whaddaya know.  It works.  point setup.exe here:

http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/

There are 3 packages, bob, bobx, and boby.  only bob has a -src package, 
the other two have source: lines that explicitly specify bob's source 
package.

It seems to work perfectly -- with only a single niggle:

if you select the source for more than one of [bob|bobx|boby], then it 
is downloaded only once (good) but is unpacked three times.  This isn't 
a terrible thing, but it is a waste of effort

If you play around with this, you can clean up by uninstalling the 
binary packages, and deleting the file /usr/src/bob.file.src.  (Or, 
you can delete /bob.file, /bobx.file, /boby.file, and 
/usr/src/bob.file.src, and remove the bob, bobx, and boby entries from 
/etc/setup/installed.db)

So, except for the niggle above, if upset were modified to allow the 
external-src: keyword, then multiple-binary-packages from one -src 
package would work!  (and the niggle isn't a show stopper).

--Chuck





Re: xfree packages

2002-04-16 Thread Charles Wilson

Oh okay -- then I can go home (nothin to see here; nope, NOT using the 
superfast net connection at work for non-work related stuff...nope, not 
me...)

--Chuck


Harold Hunt wrote:

 Charles,
 
 Don't bother... I'm already on it.  The scripts are modified and I'm just
 working on packaging it up.
 
 Harold
 
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson
Sent: Tuesday, April 16, 2002 11:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: xfree packages


I can do this -- but what was the outcome of the package name argument?
  Was it xfree-foo-4.2.0-1.tar.bz2 or xfree86-... or XFree86-...?

I'll need to modify the znark script accordingly.

--Chuck


Christopher Faylor wrote:


On Wed, Apr 10, 2002 at 01:22:52PM -0700, Ian Burrell wrote:


Christopher Faylor wrote:


Yes, please post the setup.hint files that you used.



Check out http://www.znark.com/cygwin/. It doesn't include the archive
files; my web account doesn't have the bandwidth or quota for them. To
generate the packages, download the *.tgz files from
cygwin/xfree/binaries/4.2.0


If someone wants to repackage these files into .bz2 format, I'll upload
them to a temporary area on sourceware.

cgf



 





Re: info: single install xfree86 + minimal cygwin?

2002-04-09 Thread Charles Wilson



Ian Burrell wrote:


 That is a list of subdirectories. But it won't work since the each 
 package needs its own subdirectory. A better hiearchy would use the 
 components from the package names. Hopefully, multiple levels of 
 subdirectories will work.


Yep.  Subdirs work fine.  For instance, the following are *currently* in 
use:

cygwin/latest/ncurses/
cygwin/latest/ncurses/setup.hint
cygwin/latest/ncurses/ncurses-5.2-?.tar.bz2
cygwin/latest/ncurses/ncurses-5.2-?-src.tar.bz2
cygwin/latest/ncurses/libncurses5/
cygwin/latest/ncurses/libncurses5/setup.hint
cygwin/latest/ncurses/libncurses5/libncurses5-5.2-?.tar.bz2
cygwin/latest/ncurses/libncurses5/libncurses5-5.2-?.tar.bz2
cygwin/latest/ncurses/libncurses6/
cygwin/latest/ncurses/libncurses6/setup.hint
cygwin/latest/ncurses/libncurses6/libncurses6-5.2-?.tar.bz2
cygwin/latest/ncurses/libncurses6/libncurses6-5.2-?.tar.bz2

Also, see gettext/libintl, readline/libreadline, etc.

--Chuck





Re: info: single install xfree86 + minimal cygwin?

2002-04-09 Thread Charles Wilson



Robert Collins wrote:


They were simple changes to the script I wrote to repackage the 
distributed archives. I'll try to write proper setup.hint 
files for all 
the packages.

 
 Cool.


I'm unclear about how the -src packages (are/should be) handled, since 
there are a great many binary packages in XFree, but only a few 
original source packages.  In the past, when multiple binary 
packages are generated from a single source package, we've done the 
following:

ncurses-5.2-?-src.tar.bz2
   contains the actual src dist for ncurses/libncurses, with
   cygwin patches, build scripts, etc

However, building this -src generates two binary packages:
   ncurses-5.2-?.tar.bz2
   libncurses6-5.2-?.tar.bz2

So, we create an empty
   libncurses6-5.2-?-src.tar.bz2
that contains only a single README that says go look over there, in 
ncurses-5.2-?-src.tar.bz2.

Now, this works, and upset/setup are happy (every binary package has a 
src package) but it is hackish, ugly, and a pain to maintain.  Is 
there a better solution?  (Or can we discard the psuedo-src packages 
without repurcussion?  Won't upset be upset by the bin without src 
problem?)

--Chuck






Re: info: single install xfree86 + minimal cygwin?

2002-04-09 Thread Charles Wilson

Christopher Faylor wrote:

 On Tue, Apr 09, 2002 at 09:22:30PM -0400, Charles Wilson wrote:
 
Now, this works, and upset/setup are happy (every binary package has a 
src package) but it is hackish, ugly, and a pain to maintain.  Is 
there a better solution?  (Or can we discard the psuedo-src packages 
without repurcussion?  Won't upset be upset by the bin without src 
problem?)

 
 If it is upset I'll be upset.
 
 It should be acceptable to have bin without source.
 
 If it causes a problem, I'll fix it.


That's great.  (I'm not planning on needlessly changing my packages, but 
perhaps the next time they must be updated for other reasons, I'll drop 
the psuedo-src packages).

However, is there any way we can add to the setup/upset grammar an 
optional keyword like:

(within libncurses6's setup.hint)
external-src: ncurses

which instructs upset to fill the setup.ini thus:

 ncurses
sdesc: blah blah
ldesc: blah blah
category: Base Libs
requires: cygwin terminfo libncurses6
version: 5.2-8
install: latest/ncurses/ncurses-5.2-8.tar.bz2
source: latest/ncurses/ncurses-5.2-8-src.tar.bz2
[prev]
install: latest/ncurses/ncurses-5.2-7.tar.bz2
source: latest/ncurses/ncurses-5.2-7-src.tar.bz2

libncurses6
sdesc: blah blah
ldesc: blah blah
category: Base Libs
requires: cygwin terminfo
version: 5.2-8
install: latest/ncurses/libncurses6/libncurses6-5.2-8.tar.bz2
source: latest/ncurses/ncurses-5.2-8-src.tar.bz2
[prev]
install: latest/ncurses/libncurses6/libncurses6-5.2-7.tar.bz2
source: latest/ncurses/ncurses-5.2-7-src.tar.bz2

e.g. keying off the version of libncurses, find the matching versioned 
-src package of whatever is specified in the external-src: field in 
libncurses6's setup.hint...

This would require conflict avoidance within setup.exe, too -- the src 
chkboxes for ncurses and libncurses6 should be tied together in this case...

Or is this just not worth worrying about?

--Chuck






Speaking of debian cygwin

2001-12-04 Thread Charles Wilson

There's another slashdot article:

http://slashdot.org/article.pl?sid=01/12/04/13552388

Seems the debian-devel folks aren't too happy about this...

--Chuck




  1   2   >