Re: ATWIL ?

2020-10-27 Thread Hamish MB via Cygwin-apps
Yeah, I meant to ask this too, it doesn't seem to be on the acronyms list.

Hamish
On Oct 27, 2020, at 11:23 PM, Mark Geisert 
mailto:m...@maxrnd.com>> wrote:

Does it mean "All The World Is Linux" or something else?

..mark


Re: Missing 'sphinx-build' command from python37-sphinx package

2020-08-08 Thread Hamish MB via Cygwin
Perhaps versioned commands like sphinx-build36, 37, 38 and a sphinx-build 
command that defaults to 3.8?

Hamish
On 8 Aug 2020, at 20:07, Marco Atzeri via Cygwin 
mailto:cygwin@cygwin.com>> wrote:

On 08.08.2020 09:44, Xavier Delaruelle via Cygwin wrote:
 Hello,

 I am using cygwin through the AppVeyor CI environment to check my software
 build process and non-regression testsuite :

 https://ci.appveyor.com/project/xdelaruelle/modules

 In this environment I use python37-sphinx package to build the
 documentation of the software, which requires the 'sphinx-build' command.

 It seems that this 'sphinx-build' command has disappeared from
 python37-sphinx package recently:

 
https://ci.appveyor.com/project/xdelaruelle/modules/builds/34537360/job/870u7prqtwgbwtnk

 Which is confirmed by listing package content:

 
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fpython37-sphinx%2Fpython37-sphinx-3.1.2-1=sphinx

 This issue is also affecting the python36-sphinx package.

36 was not changed from before, I will look for a way to provide a
suitable sphinx-build that works with all 3.x versions


 python38-package contains the 'sphinx-build' command, however it seems
 there are some missing requirements to make this package operational. I get
 an "Could not import extension sphinx.builders.epub3 
(exception: No module
 named 'sphinxcontrib')" error, see build log:

 
https://ci.appveyor.com/project/xdelaruelle/modules/builds/34542552/job/9tw241syk4upr4r1

 Regards,
 Xavier

noted.
It is always difficult to establish which submodule are mandatory
and which are just optional.

It seems I nedd to deploy

  python38-sphinxcontrib-websupport
  python38-sqlalchemy
  python38-whoosh

let me fews days

Regards
Marco

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa

2019-09-14 Thread Hamish MB
On 13/09/2019 19:53, Andrey Repin wrote:
> Greetings, Hamish MB!
>
>> On 13/09/2019 01:41, Andrey Repin wrote:
>>> Greetings, Hamish MB!
>>>
>>> Please no top-posting in this channel.
>>>
>>>> Note: I've just realised this only happens when 3D acceleration is
>>>> enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a
>>>> Cygwin bug. Thoughts?
>>> What video mode did you select for your system?
>>> Which driver (standard or improved) did you install?
>>>
>> Thanks for letting me know about the top-posting. I'll see if my email
>> client has a setting to disable that by default.
>> I'm using the "VBoxSVGA" mode, but I also tried the "VBoxVGA" mode. I'm
>> using the standard 3D driver, not the experimental one that supports
>> Aero because that didn't work well for me.
> I've found "experimental" one working quite well for the last decade.
> 128MB+ Video RAM, enabled 3D acceleration… There's minor issues with canvas
> redraw of some apps, but nothing crash-level.

Yeah, it did that for me too, but I guess I find it more annoying :)

It seems after the latest update to Virtualbox and the guest additions,
this is now working again. If it stops, I'll reply again, but I reckon
this was probably a problem with Virtualbox.

Hamish


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa

2019-09-13 Thread Hamish MB
On 13/09/2019 01:41, Andrey Repin wrote:
> Greetings, Hamish MB!
>
> Please no top-posting in this channel.
>
>> Note: I've just realised this only happens when 3D acceleration is
>> enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a
>> Cygwin bug. Thoughts?
> What video mode did you select for your system?
> Which driver (standard or improved) did you install?
>
Thanks for letting me know about the top-posting. I'll see if my email
client has a setting to disable that by default.

I'm using the "VBoxSVGA" mode, but I also tried the "VBoxVGA" mode. I'm
using the standard 3D driver, not the experimental one that supports
Aero because that didn't work well for me.

Hamish



Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa

2019-09-12 Thread Hamish MB
Note: I've just realised this only happens when 3D acceleration is
enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a
Cygwin bug. Thoughts?

Hamish

On 12/09/2019 12:33, Hamish McIntyre-Bhatty wrote:
> Okay, so after the latest set of updates, this still seems to happen.
> Attached is the XWin.0.log file. I am running this in Virtualbox, so it
> is possible that this issue has something to do with that?
>
> Hamish
>
> On 07/09/2019 19:50, Hamish McIntyre-Bhatty wrote:
>> I was starting with "startxwin &" in the Cygwin terminal. Is this the
>> wrong way to do it?
>>
>> I'll try that soon and get back to you.
>>
>> This was before the latest set of updates to Xorg and the openGL
>> libraries, so it could be that it had something to do with the missing
>> libEGL dependency - I will try again now, and hopefully it will work
>> :). If it's any help, I'm running Cygwin on Windows 7.
>>
>> Hamish
>>
>> On 07/09/2019 16:11, Jon Turney wrote:
>>> On 05/09/2019 11:28, Hamish MB wrote:
>>>> libraries. Additionally, the xwin server refuses to start if more than
>>>> one display is present, for reasons I don't understand.
>>> That is unusual.
>>>
>>> I assume you are trying to start via the start menu shortcut?
>>>
>>> Does starting it as 'XWin -multiwindow' work?
>>>
>>> If not, can you provide the /var/log/xwin/XWin.0.log?
>>>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa

2019-09-12 Thread Hamish MB
Okay, so after the latest set of updates, this still seems to happen.
Attached is the XWin.0.log file. I am running this in Virtualbox, so it
is possible that this issue has something to do with that?

Hamish

On 07/09/2019 19:50, Hamish McIntyre-Bhatty wrote:
> I was starting with "startxwin &" in the Cygwin terminal. Is this the
> wrong way to do it?
>
> I'll try that soon and get back to you.
>
> This was before the latest set of updates to Xorg and the openGL
> libraries, so it could be that it had something to do with the missing
> libEGL dependency - I will try again now, and hopefully it will work
> :). If it's any help, I'm running Cygwin on Windows 7.
>
> Hamish
>
> On 07/09/2019 16:11, Jon Turney wrote:
>> On 05/09/2019 11:28, Hamish MB wrote:
>>> libraries. Additionally, the xwin server refuses to start if more than
>>> one display is present, for reasons I don't understand.
>>
>> That is unusual.
>>
>> I assume you are trying to start via the start menu shortcut?
>>
>> Does starting it as 'XWin -multiwindow' work?
>>
>> If not, can you provide the /var/log/xwin/XWin.0.log?
>>
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.4.0
OS: CYGWIN_NT-6.1-7601 Hamish-PC 3.0.7-338.x86_64 2019-04-30 18:08 UTC x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
Package: version 1.20.4-1 built 2019-03-15

XWin was started with the following command line:

XWin -multiwindow 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 920
winInitializeScreenDefaults - native DPI x 96 y 96
[   392.984] (II) xorg.conf is not supported
[   392.984] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
[   392.984] LoadPreferences: /home/Hamish/.XWinrc not found
[   392.984] LoadPreferences: Loading /etc/X11/system.XWinrc
[   392.984] LoadPreferences: Done parsing the configuration file...
[   392.984] winDetectSupportedEngines - RemoteSession: no
[   393.000] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
[   393.000] winDetectSupportedEngines - Returning, supported engines 0005
[   393.000] winSetEngine - Multi Window or Rootless => ShadowGDI
[   393.000] winScreenInit - Using Windows display depth of 24 bits per pixel
[   393.000] winScreenInit - Monitors do not all have same pixel format / display depth.
[   393.000] winScreenInit - Performance may suffer off primary display.
[   393.015] winQueryRGBBitsAndMasks - GetDeviceCaps (BITSPIXEL) returned 24 for the screen.  Using default 24bpp masks.
[   393.015] winAllocateFBShadowGDI - Creating DIB with width: 3840 height: 986 depth: 24
[   393.015] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[   393.015] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 24
[   393.015] winFinishScreenInitFB - fbFinishScreenInit failed
[   393.015] winScreenInit - winFinishScreenInit () failed
[   393.015] (EE) Fatal server error:
[   393.015] (EE) InitOutput - Couldn't add screen 0(EE) 
[   393.015] (EE) Server terminated with error (1). Closing log file.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa

2019-09-07 Thread Hamish MB
I was starting with "startxwin &" in the Cygwin terminal. Is this the 
wrong way to do it?

I'll try that soon and get back to you.

This was before the latest set of updates to Xorg and the openGL 
libraries, so it could be that it had something to do with the missing 
libEGL dependency - I will try again now, and hopefully it will work :). 
If it's any help, I'm running Cygwin on Windows 7.

Hamish

On 07/09/2019 16:11, Jon Turney wrote:
> On 05/09/2019 11:28, Hamish MB wrote:
>> libraries. Additionally, the xwin server refuses to start if more than
>> one display is present, for reasons I don't understand.
>
> That is unusual.
>
> I assume you are trying to start via the start menu shortcut?
>
> Does starting it as 'XWin -multiwindow' work?
>
> If not, can you provide the /var/log/xwin/XWin.0.log?
>


Re: Updated cygport for for wxwidgets 3.0 package

2019-09-07 Thread Hamish MB
Yes, I realise now that I should have done that. I apologise if I caused 
any irritation or offence.

I guess I might as well provide explanations now for the sake of 
completeness, if nothing else.

1: This was a mistake, and I got confused because I was attempting to 
build wxPython at the same time, and the patches for that no longer 
apply because the build system has changed.

2: This reflects the new version number of wxwidgets - 3.0.4.

3: I needed these in order to build without the patches. I'm not sure 
why, but these aren't needed when the patches are used. This is 
documented at https://forums.wxwidgets.org/viewtopic.php?f=19=46091

4: That was another mistake, I didn't realise I did that.

5: I looked in the location the tests were meant to be, but they weren't 
there, so the test section didn't work. Perhaps this has something to do 
with the patches as well?

All that said, I should also have made it clear that I didn't think the 
patch was 100% ready - I thought more work was going to be required at 
any rate.

Hamish

On 07/09/2019 16:07, Jon Turney wrote:
> On 05/09/2019 17:36, Hamish MB wrote:
>> Attached is a patch from git format-patch to upgrade the wxwxidgets
>> version to 3.0.4. Next up I'll try to make a package for wxPython 4, but
>> I have to get it to build first.
>
> Thanks for attempting this.
>
> Going forward, please consider that this patch does (at least) the 
> following things:
>
> * Removes existing patches
> * Updates the version number
> * Adds '-D_XOPEN_SOURCE=500 -D_DEFAULT_SOURCE' to CPPFLAGS
> * Disables the webviewwebkit configuration option
> * Removes the tests
>
> It makes it a lot easier for someone to evaluate your patch if you 
> give reasons for the changes in the patch commentary.


Re: Updated cygport for for wxwidgets 3.0 package

2019-09-06 Thread Hamish MB
On 05/09/2019 22:19, Yaakov Selkowitz wrote:
> Patches have been written, or applied from other sources, for any
> number of reasons.  It would be wise to attempt to understand why.

Yes. I'm now rebuilding using your updated cygport file and examining
the patches in order to better understand how it works. I think I must
have gotten confused - I think it was the wxpython patches that can't be
applied any more because the codebase has changed a lot, but I'll
investigate that further. I did hear that some of the patches come from
Gentoo, is that right? As you can tell, I'm very new to using patches
and packaging for Cygwin, and I apologise for my newbie questions.

>> We could have a wxPython 4 build for Python 3 only, and leave the Python 
>> 2 version as it is?
> I'd be willing to consider that.

Great, when I get it working, I'll see if I can get the existing patches
to apply and then go from there.

Hamish



Re: Updated cygport for for wxwidgets 3.0 package

2019-09-05 Thread Hamish MB
I thought those were patches that were needed in order to get it to 
build? They didn't seem to apply when I tried them, so maybe I did it 
wrong. Sorry, anyway.

We could have a wxPython 4 build for Python 3 only, and leave the Python 
2 version as it is?

Hamish

On 05/09/2019 20:35, Yaakov Selkowitz wrote:
> On Thu, 2019-09-05 at 16:36 +0000, Hamish MB wrote:
>> Attached is a patch from git format-patch to upgrade the wxwxidgets
>> version to 3.0.4.
> Obviously, I'm not going to accept this patch as is, since it removes
> all the modifications I have made to the package.  However, I did go
> ahead and update to 3.0.4, which is now working its way to mirrors.
>
>> Next up I'll try to make a package for wxPython 4, but I have to get
>> it to build first.
> Since this would conflict with the existing python-wx package, either
> this needs to be a compatible replacement for 3.0, or the packaging
> needs to be modified to be parallel-installable.
>
> --
> Yaakov
>
>


Updated cygport for for wxwidgets 3.0 package

2019-09-05 Thread Hamish MB
Attached is a patch from git format-patch to upgrade the wxwxidgets
version to 3.0.4. Next up I'll try to make a package for wxPython 4, but
I have to get it to build first.

Hamish

From ea95be9a014d823ffecc541ff97613a798c98d44 Mon Sep 17 00:00:00 2001
From: Hamish McIntyre-Bhatty 
Date: Thu, 5 Sep 2019 15:00:14 +0100
Subject: [PATCH] Remove unneeded patches, and update for wxWidgets 3.0.4

---
 3.0.2-cygwin-auto-import.patch |  12 
 3.0.2-cygwin-dlopen.patch  |  46 ---
 3.0.2-cygwin-gcc5.patch|  21 ---
 3.0.2-cygwin-unix.patch| 100 -
 3.0.3-autoreconf.patch |  21 ---
 3.0.3-cygwin-ftm.patch |  11 
 wxWidgets3.0.cygport   |  38 +
 7 files changed, 13 insertions(+), 236 deletions(-)
 delete mode 100644 3.0.2-cygwin-auto-import.patch
 delete mode 100644 3.0.2-cygwin-dlopen.patch
 delete mode 100644 3.0.2-cygwin-gcc5.patch
 delete mode 100644 3.0.2-cygwin-unix.patch
 delete mode 100644 3.0.3-autoreconf.patch
 delete mode 100644 3.0.3-cygwin-ftm.patch

diff --git a/3.0.2-cygwin-auto-import.patch b/3.0.2-cygwin-auto-import.patch
deleted file mode 100644
index a2c09f9..000
--- a/3.0.2-cygwin-auto-import.patch
+++ /dev/null
@@ -1,12 +0,0 @@
 origsrc/wxPython-src-3.0.2.0/include/wx/dlimpexp.h	2013-12-31 15:47:57.0 -0600
-+++ src/wxPython-src-3.0.2.0/include/wx/dlimpexp.h	2015-01-04 14:56:39.870827000 -0600
-@@ -56,9 +56,6 @@
- #define WXEXPORT _Export
- #define WXIMPORT _Export
- #endif
--#elif defined(__CYGWIN__)
--#define WXEXPORT __declspec(dllexport)
--#define WXIMPORT __declspec(dllimport)
- #endif
- 
- /* for other platforms/compilers we don't anything */
diff --git a/3.0.2-cygwin-dlopen.patch b/3.0.2-cygwin-dlopen.patch
deleted file mode 100644
index 43bedc6..000
--- a/3.0.2-cygwin-dlopen.patch
+++ /dev/null
@@ -1,46 +0,0 @@
 origsrc/wxPython-src-3.0.2.0/src/common/dynlib.cpp	2013-12-16 07:42:30.0 -0600
-+++ src/wxPython-src-3.0.2.0/src/common/dynlib.cpp	2015-01-04 15:00:38.988043900 -0600
-@@ -165,7 +165,7 @@ void *wxDynamicLibrary::GetSymbol(const
- wxString wxDynamicLibrary::GetDllExt(wxDynamicLibraryCategory cat)
- {
- wxUnusedVar(cat);
--#if defined(__WINDOWS__) || defined(__WXPM__) || defined(__EMX__)
-+#if defined(__WINDOWS__) || defined(__WXPM__) || defined(__EMX__) || defined(__CYGWIN__)
- return ".dll";
- #elif defined(__HPUX__)
- return ".sl";
-@@ -197,7 +197,11 @@ wxDynamicLibrary::CanonicalizeName(const
- {
- case wxDL_LIBRARY:
- // Library names should start with "lib" under Unix.
-+#ifdef __CYGWIN__
-+nameCanonic = "cyg";
-+#else
- nameCanonic = "lib";
-+#endif
- break;
- case wxDL_MODULE:
- // Module names are arbitrary and should have no prefix added.
 origsrc/wxPython-src-3.0.2.0/src/unix/dlunix.cpp	2013-12-31 15:47:57.0 -0600
-+++ src/wxPython-src-3.0.2.0/src/unix/dlunix.cpp	2015-01-04 14:58:20.943403200 -0600
-@@ -184,7 +184,11 @@ public:
- details->m_length = (char *)end - (char *)start;
- 
- // try to extract the library version from its name
-+#ifdef __CYGWIN__
-+const size_t posExt = path.rfind(wxT(".dll"));
-+#else
- const size_t posExt = path.rfind(wxT(".so"));
-+#endif
- if ( posExt != wxString::npos )
- {
- if ( path.c_str()[posExt + 3] == wxT('.') )
-@@ -213,7 +217,7 @@ wxDynamicLibraryDetailsArray wxDynamicLi
- {
- wxDynamicLibraryDetailsArray dlls;
- 
--#ifdef __LINUX__
-+#if defined(__LINUX__) || defined(__CYGWIN__)
- // examine /proc/self/maps to find out what is loaded in our address space
- wxFFile file(wxT("/proc/self/maps"));
- if ( file.IsOpened() )
diff --git a/3.0.2-cygwin-gcc5.patch b/3.0.2-cygwin-gcc5.patch
deleted file mode 100644
index ce9f3ae..000
--- a/3.0.2-cygwin-gcc5.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Sometimes when called from wxLocale::GetSystemEncodingName, 'ascii' gets
-clobbered by the subsequent wxStringInternalBuffer ctor.  CoW issues?
-
 origsrc/wxPython-src-3.0.2.0/src/common/string.cpp	2014-10-08 11:51:06.0 -0500
-+++ src/wxPython-src-3.0.2.0/src/common/string.cpp	2017-03-29 01:20:26.947989900 -0500
-@@ -1168,11 +1168,13 @@ int wxString::CmpNoCase(const wxString&
- 
- #if wxUSE_UNICODE
- 
--wxString wxString::FromAscii(const char *ascii, size_t len)
-+wxString wxString::FromAscii(const char *orig, size_t len)
- {
--if (!ascii || len == 0)
-+if (!orig || len == 0)
-return wxEmptyString;
- 
-+char *ascii = strndupa (orig, len);
-+
- wxString res;
- 
- {
diff --git a/3.0.2-cygwin-unix.patch b/3.0.2-cygwin-unix.patch
deleted file mode 100644
index 8e9749b..000
--- a/3.0.2-cygwin-unix.patch
+++ /dev/null
@@ -1,100 +0,0 @@
 origsrc/wxPython-src-3.0.2.0/build/aclocal/bakefile.m4	2013-12-16 07:42:29.0 -0600
-+++ 

Re: [ITP] wxwidgets 3.0.4

2019-09-05 Thread Hamish MB
On 05/09/2019 15:33, Yaakov Selkowitz wrote:
> On Thu, 2019-09-05 at 14:11 +0000, Hamish MB wrote:
>> I understand that there is an existing Cygwin package for wxWidgets
>> 3.0.3. However, this is not new enough to build wxPython 4, and hence
>> support wxPython apps that use Python 3 on Cygwin.
> Then you should be asking for an update to the existing wxWidgets3.0
> package.  Since 3.0.3 and 3.0.4 cannot be installed in parallel, an ITP
> is not appropriate.
>
> --
> Yaakov

Okay, that makes sense. I have a working cygport file ready in a
repository, so shall I submit a pull request instead then?

My apologies,

Hamish



[ITP] wxwidgets 3.0.4

2019-09-05 Thread Hamish MB
Hello,

I understand that there is an existing Cygwin package for wxWidgets
3.0.3. However, this is not new enough to build wxPython 4, and hence
support wxPython apps that use Python 3 on Cygwin.

As a result of a desire for this in order to support Windows, I would
like to propose adding wxWidgets 3.0.4 to the Cygwin repositories. I
have successfully created a .cygport file that can build packages for
wxWidgets 3.0.4. I'm unsure what to do next. Do I need to submit a pull
request to "https://github.com/cygwinports/wxWidgets3.0; as well?

Thanks,

Hamish



Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa

2019-09-05 Thread Hamish MB
Hello,

After installing the latest updates to cygwin, including the new X
server, openGL libraries, and mesa, I'm having issues with a configure
script that was previously working. It no longer finds the openGL
libraries. Additionally, the xwin server refuses to start if more than
one display is present, for reasons I don't understand.

If it's of any use, the package I'm trying to build is wxWidgets 3.0.4,
in the hope of eventually getting it and wxPython 4 into the cygwin
package repositories.

This happens on both the 32-bit and 64-bit versions of Cygwin. Does
anyone have any idea why this could be happening?

Hamish



Re: gstreamer-plugins-dev packages not available?

2019-05-23 Thread Hamish MB
I see, I missed the -devel package - thanks for your help.

Hamish


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



gstreamer-plugins-dev packages not available?

2019-05-22 Thread Hamish MB
Hello,

I've been trying to build wxpython 4 under Cygwin, and I have realised 
that one of the build dependencies - gstreamer-plugins-bad-dev - doesn't 
seem to be in the repository. This is the same for all of the other 
plugin sets. I'm wondering if the package name is just different and I'm 
missing it or not? There is a dev package for the library that I 
installed, but this isn't enough to satisfy wxpython's configure script.

I'm happy to try to modify the build recipe for the gstreamer packages 
to include this, or do something similar. I might need some initial 
pointers - I'm not experienced compiling under Cygwin, or using Cygwin's 
package management system. If I get it working, I will also be happy to 
contribute a python3-wxpython4 package as well.

Can anyone help me?

Hamish McIntyre-Bhatty



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple