Re: Case sensitive filenames for non-NTFS filesystems

Hi, On 02 Aug 2013 20:29+1000, Corinna Vinschen wrote: On Aug 2 19:05, Shaddy Baddah wrote: Hi, On 02 Aug 2013 18:31+1000, Corinna Vinschen wrote: Correction, not only NTFS. Here's the source code comment: Sorry, yes I forgot that it was coded to let Windows make the decision. Unfortuna

Re: Postinsall script errrors "Unknown package" if running Cygwin setup.exe to update my installation

Hello Larry, >> Does anybody know what cause this problem and how to fix it? > [...] > > Perfect. Thank you. All is working fine now. T. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/

[ANNOUNCEMENT] Updated: ninvaders-0.1.1-2 (32-bit) / ninvaders-0.1.1-1 (64-bit)

A new build of ninvaders has been uploaded: 32-bit: ninvaders-0.1.1-2 64-bit: ninvaders-0.1.1-1 This build fixes a bug with 'ninvaders -gpl' and is the first 64-bit build of ninvaders. DESCRIPTION === Ever wanted to place space invaders when you can't find a GUI? Now you can

Re: Postinsall script errrors "Unknown package" if running Cygwin setup.exe to update my installation

Greetings, Thomas Jung! > After I stoped all runnning services "cygrunserv", "portmap", > "sshd" and starting "setup.exe --no-shortcuts" to update all > my packages I got an error since I insalled some additional > packages [I assume and AFAIR which are necessary for some > (command line) pdf tool

Re: Arrow keys do not function as expected when running programs

On 8/2/2013 11:15, Weston Turner wrote: When I run a program from the shell, ...under what console/terminal? The Windows native console? MinTTY? xterm under Cygwin/X11? pressing the arrow keys sends console input to the program and moves the cursor around the terminal Attach cygcheck ou

Arrow keys do not function as expected when running programs

I am having a problem with Cygwin DLL 1.7.22./bash-4.1 (I believe the newest version). When I run a program from the shell, pressing the arrow keys sends console input to the program and moves the cursor around the terminal rather than having the expected behavior of cycling through the input bu

Re: Postinsall script errrors "Unknown package" if running Cygwin setup.exe to update my installation

On 8/2/2013 10:46 AM, Thomas Jung wrote: Package: Unknown package pango1.0.sh exit code 1 Does anybody know what cause this problem and how to fix it? -- Larry

Postinsall script errrors "Unknown package" if running Cygwin setup.exe to update my installation

Hello, After I stoped all runnning services "cygrunserv", "portmap", "sshd" and starting "setup.exe --no-shortcuts" to update all my packages I got an error since I insalled some additional packages [I assume and AFAIR which are necessary for some (command line) pdf tools, like pdftk or ghostscrip

[ANNOUNCEMENT] Updated: automake1.11-1.11.6-2

Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This package contains the latest version of automake 1.11 system, automake-1.11.6. This is a routine packaging upd

[ANNOUNCEMENT] Updated: automake1.10-1.10.3-2

Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This is routine packaging update for automake-1.10, and contains the latest version of the automake 1.10 series, automake-1.10.3. This cygwin package, automake1.10, can be installed withou

[ANNOUNCEMENT] Updated: automake1.12-1.12.6-2

Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This is package contains the latest version of automake system in the 1.12.x series, automake-1.12.6. This release

[ANNOUNCEMENT] NEW: automake1.13-1.13.4-1

Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This is the first release in the automake-1.13 release series, and contains the latest version of automake system,

[ANNOUNCEMENT] NEW: automake1.14-1.14-1

Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This is the first release in the automake-1.14 release series, and contains the latest version of automake system,

[ANNOUNCEMENT] Updated: automake-9-1

This package provides a wrapper system for the various automakeX.Y packages, and plays a role similar to that of the long-standing autoconf wrapper package. This wrapper system is based on the am-wrapper POSIX shell script developed by the gentoo distribution, with tweaks to support cygwin's exist

[ANNOUNCEMENT] Updated: gcc-tools-epoch2-automake-1.11.6-1

Gcc requires that an unpatched, pristine version of automake be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing automake packages in /usr. gcc-4.3.x and gcc-4.4.x development requires the latest release in the au

[ANNOUNCEMENT] Updated: gcc-tools-epoch1-automake-1.9.6-2

Gcc requires that an unpatched, pristine version of automake be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing automake packages in /usr. gcc-4.3.x and gcc-4.4.x development requires the latest release in the au

xterm preventing shutdown

I had just done a new Cygwin install due to a collection of (seemingly unrelated) errors. (The workaround for a python fork::failed where rebaseall didn't help was to do a new Cygwin install. I was having the same error but with perl instead of python.) The new install fixed that problem. In fact,

[ANNOUNCEMENT] Updated: gcc-tools-epoch2-autoconf-2.64-2

Gcc requires that an unpatched, pristine version of autoconf be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing autoconf packages in /usr. gcc-4.3.x and gcc-4.4.x development requires autoconf-2.59 gcc-4.5.x thru

[ANNOUNCEMENT] Updated: gcc-tools-epoch1-autoconf-2.59-2

Gcc requires that an unpatched, pristine version of autoconf be used when preparing patches for official submission. For various reasons [1] these pristine versions cannot coexist with the existing autoconf packages in /usr. gcc-4.3.x and gcc-4.4.x development requires autoconf-2.59 gcc-4.5.x thru

Re: 64-bit emacs crashes a lot

On 02/08/2013 7:04 AM, Ken Brown wrote: On 8/2/2013 4:02 AM, Corinna Vinschen wrote: On Aug 1 22:46, Ryan Johnson wrote: On 26/07/2013 11:32 PM, Ryan Johnson wrote: On 26/07/2013 10:50 PM, Ken Brown wrote: On 7/26/2013 8:32 PM, Ryan Johnson wrote: Hi all, Running 64-bit cygwin 1.7.22(0.268

Re: 64-bit emacs crashes a lot

On 8/2/2013 4:02 AM, Corinna Vinschen wrote: On Aug 1 22:46, Ryan Johnson wrote: On 26/07/2013 11:32 PM, Ryan Johnson wrote: On 26/07/2013 10:50 PM, Ken Brown wrote: On 7/26/2013 8:32 PM, Ryan Johnson wrote: Hi all, Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside mintt

Re: Case sensitive filenames for non-NTFS filesystems

On Aug 2 19:05, Shaddy Baddah wrote: > Hi, > > On 02 Aug 2013 18:31+1000, Corinna Vinschen wrote: > >Correction, not only NTFS. Here's the source code comment: > > Sorry, yes I forgot that it was coded to let Windows make the decision. > > >>Unfortunately, in providing EXFAT, Microsoft has not

Re: Case sensitive filenames for non-NTFS filesystems

Hi, On 02 Aug 2013 18:31+1000, Corinna Vinschen wrote: Correction, not only NTFS. Here's the source code comment: Sorry, yes I forgot that it was coded to let Windows make the decision. Unfortunately, in providing EXFAT, Microsoft has not seen fit to carry over the same handling in the kern

Re: Case sensitive filenames for non-NTFS filesystems

On Aug 2 16:50, Shaddy Baddah wrote: > Hi, > > As per: > > http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive > > Cygwin act on filenames on NTFS in with case preservation/sensitivity. Correction, not only NTFS. Here's the source code comment: /* Case sensitivi

Re: setsockopt support for SO_RCVTIMEO

On Aug 1 20:41, Sean Daley wrote: > On Thu, Aug 1, 2013 at 7:41 PM, Balaji Venkataraman <> wrote: > > > > It appears Cygwin setsockopt doesn't do anything with the socket > > options SO_RCVTIMEO or SO_SNDTIMEO. Then I also found this: > > http://cygwin.com/ml/cygwin/2003-01/msg00833.html > > > > B

Re: 64-bit emacs crashes a lot

On Aug 1 22:46, Ryan Johnson wrote: > On 26/07/2013 11:32 PM, Ryan Johnson wrote: > >On 26/07/2013 10:50 PM, Ken Brown wrote: > >>On 7/26/2013 8:32 PM, Ryan Johnson wrote: > >>>Hi all, > >>> > >>>Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside > >>>mintty 1.2-beta1-1, I keep

RE: make-3.82.90-1-use-spawn-on-cygwin.diff

Hello! > The errors i obtain are as follows: > /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 2: > use: command not found > /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 3: > use: command not found > /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/

RE: building Perl module DBD-ODBC-4.3 under 64-bit cygwin

> ...is a typical type conflict. ULONG is a Windows type defined as > unsigned long in the Win32 API. The Win32 data model is LLP64, so > unsigned long is 4 bytes. However, Cygwin is LP64, so unsigned long is > 8 bytes. Therefore the `typedef unsigned long ULONG;' is wrong for 64 > bit. Either