Re: How is setup.ini generated these days?
On Sat, Apr 16, 2011 at 11:20:47PM -0500, Yaakov (Cygwin/X) wrote: # On Sat, 2011-04-16 at 21:01 +0200, Jens Schweikhardt wrote: # > I'm trying to make a package server as described on # > http://sourceware.org/cygwin-apps/package-server.html # > # > I've rsynced the complete "release" tree (skipping *-legacy). However, # > running # > # > genini release/* > setup.ini # > # > with genini 1.13 from # > http://cygwin.com/cgi-bin/cvsweb.cgi/genini/?cvsroot=cygwin-apps) # > produces a lot of errors and warnings and the resulting setup.ini # > is much smaller than the official one that comes with rsyncing # > (300k vs 1300k). # # Many packages are in subdirectories of release. Try this instead: # # genini --output=setup.ini `find release/ -name setup.hint | sed 's|/setup\.hint$||g'` Thanks, and I also found the --recursive option. Now I'm running this: genini --output=setup.ini --recursive --okmissing=source release This gets close to 1300k but not quite. There are small differences that apparently result from some sort of postprocessing, such as: * If a package has no "requires" tag, it gets one with "cygwin" * If a "requires:" tag does not include "cygwin" it gets one Apart from that many "source", "install" and "version" tags are different. What is the script that the official setup.ini is generated with? Is this list the right place to ask this? If not, where should I ask? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) -- 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: failure to install on xp
On 2011-04-16 02:34Z, Dov Kruger wrote: > We have two fairly identical windows XP boxes. On mine, cygwin is working > beautifully, with X. My coworker tried, but she didn't have admin rights > and X wouldn't install right. Then she got the coveted admin rights, so we > tried to re-install. It failed. So we thought we would install clean, > deleting c:\cygwin and starting over. The installation fails in the > middle with the following error: Because the first attempt failed, I'd do this: http://www.cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all > Microsoft visual c++ runtime library > Runtime Error! > Program: C:\cygwin\bin\bash.exe > ? This application has requested the Runtime to terminate it in an > unusual way 11:09:10 AM That's weird: 'cygcheck /bin/bash' should confirm that bash.exe does not depend on the msvc runtime. Yet there have been a few similar reports: http://www.google.com/search?q=site%3Acygwin.com+"Microsoft+visual+c%2B%2B+runtime+library"; Based on them, I'd suggest that you - remove cygwin completely as above, but in step four also remove the download directory; - set a minimal %PATH% before starting setup.exe to reinstall; - run cygcheck -s -v -r as suggested here: http://cygwin.com/problems.html being especially wary of multiple cygwin dlls...and post the output here as an attachment if there are any further problems > I have Microsoft Visual Studio 2003.net and 2005 installed. She does not. > How can I view a log so we can determine what DLL is failing? One of the messages found by googling as above suggests Dependency Walker. -- 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: How is setup.ini generated these days?
On Sun, Apr 17, 2011 at 02:28:00PM +0200, Jens Schweikhardt wrote: >On Sat, Apr 16, 2011 at 11:20:47PM -0500, Yaakov (Cygwin/X) wrote: ># On Sat, 2011-04-16 at 21:01 +0200, Jens Schweikhardt wrote: ># > I'm trying to make a package server as described on ># > http://sourceware.org/cygwin-apps/package-server.html ># > ># > I've rsynced the complete "release" tree (skipping *-legacy). However, ># > running ># > ># > genini release/* > setup.ini ># > ># > with genini 1.13 from ># > http://cygwin.com/cgi-bin/cvsweb.cgi/genini/?cvsroot=cygwin-apps) ># > produces a lot of errors and warnings and the resulting setup.ini ># > is much smaller than the official one that comes with rsyncing ># > (300k vs 1300k). ># ># Many packages are in subdirectories of release. Try this instead: ># ># genini --output=setup.ini `find release/ -name setup.hint | sed >'s|/setup\.hint$||g'` > >Thanks, and I also found the --recursive option. Now I'm running this: > > genini --output=setup.ini --recursive --okmissing=source release > >This gets close to 1300k but not quite. There are small differences that >apparently result from some sort of postprocessing, such as: > > * If a package has no "requires" tag, it gets one with "cygwin" > * If a "requires:" tag does not include "cygwin" it gets one > >Apart from that many "source", "install" and "version" tags are different. > >What is the script that the official setup.ini is generated with? >Is this list the right place to ask this? If not, where should I ask? setup.ini is generated by a program called "upset". The current sources are not available to the public since the program is not intended for "roll-your-own-setup.ini" and the program is not something that I want to receive patches for or questions about. Older versions of the program are probably not kicking around out they are not supported here. If you want to generate a setup.ini use genini. If you find bugs, then proposed patches will be thoughtfully considered as long as they aren't band-aids. cgf -- 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: failure to install on xp
On Sun, Apr 17, 2011 at 02:21:15PM +, Greg Chicares wrote: >On 2011-04-16 02:34Z, Dov Kruger wrote: >> We have two fairly identical windows XP boxes. On mine, cygwin is working >> beautifully, with X. My coworker tried, but she didn't have admin rights >> and X wouldn't install right. Then she got the coveted admin rights, so we >> tried to re-install. It failed. So we thought we would install clean, >> deleting c:\cygwin and starting over. The installation fails in the >> middle with the following error: > >Because the first attempt failed, I'd do this: > http://www.cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all > >> Microsoft visual c++ runtime library >> Runtime Error! >> Program: C:\cygwin\bin\bash.exe >> ? This application has requested the Runtime to terminate it in an >> unusual way 11:09:10 AM > >That's weird: 'cygcheck /bin/bash' should confirm that bash.exe does not >depend on the msvc runtime. Yet there have been a few similar reports: > > http://www.google.com/search?q=site%3Acygwin.com+"Microsoft+visual+c%2B%2B+runtime+library"; >Based on them, I'd suggest that you Unfortunately msv*.dll runtime dependencies have crept into some system dlls for some flavors of Cygwin. That is something that Corinna, and to a lesser degree I, have been trying to fix. cgf -- 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
[ANNOUNCEMENT] Updated: {libao,libao-dev,libao4}-1.1.0-1
New versions of the libao packages are now available for download. NEWS: = This is a new upstream release, with upstream changes listed below. See also the package documentation in /usr/share/doc/libao. DESCRIPTION: Libao is a cross-platform audio library that allows programs to output audio using a simple API on a wide variety of platforms. It currently supports: * Null output (handy for testing without a sound device) * WAV files * AU files * OSS (Open Sound System, used on Linux and FreeBSD) * ALSA (Advanced Linux Sound Architecture) * polypaudio (next generation GNOME sound server) * esd (EsounD or Enlightened Sound Daemon) * AIX * Sun/NetBSD/OpenBSD * IRIX * NAS (Network Audio Server) DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org 1.1.0 - February 21, 2011 - Add autofoo ld symbol versioning to build system - Update Roar driver to latest API - Fix Roar driver to not block on SLP lookup during probe - Improve/correct latency setup in ALSA (see Trac #1762) - Add missing ctype.h header in build (see Trac #1760) - Move toward more consistent option naming across drivers - Fix Mac OS X AUHAL support to properly handle suspend/wakeup, headphone plug/unplug, other hardware events - Correct ao_example.c source to not pass dangling pointer for the matrix argument. - Add 24 bit playback to Pulse plugin - Fix 24 bit playback in ALSA plugin - Fix segfaults when closing a driver that did not successfully open. - Fix compilation of sndio plugin - Fix building Mac OS X driver AUHAL compilation for 10.5, restore Mac OS X 10.4 support -- 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: 1.7.9-1: typeahead queue not flushed when Ctrl+C pressed
On Mon, Apr 04, 2011 at 01:39:23PM -0500, Edward McGuire wrote: >When I type ahead in an uncustomized terminal window, I expect my >keyboard input to be queued until it is called for. When I press >Ctrl+C, I expect the queue to be flushed. Any keyboard input still >in the queue should be lost. > >The trouble I am having is that my keyboard input is preserved when >I press Ctrl+C. I can easily reproduce the problem with the >following keyboard input at a bash prompt: > > $ tail -f /dev/null [Enter] > [Enter] > [Enter] > [Enter] > [Ctrl+C] > >If the typeahead queue is flushed by the Ctrl+C, then a bash prompt >will appear. But if the queue is not flushed, then four bash prompts >will appear. In my case, four bash prompts appear. > >I have reproduced the problem in a Cygwin (cmd.exe) window, in a >mintty window, and in an xterm window. > >There is a termio mode bit, NOFLSH, which disables flush after >interrupt. If this bit were set, it would explain why I am having >the problem. But "stty -a" shows that this mode bit is not set. I >checked this bit before and after reproducing the problem. > >I was still able to reproduce the problem after setting and clearing >the NOFLSH bit with "stty noflsh; stty -noflsh". > >I have attached the output of "stty -a" below, along with the output >of "cygcheck -s -v -r" and of "cat /var/log/xwin/XWin.0.log". > >I have not found this problem mentioned on the Cygwin list. > >Where might I be going wrong? Is this a limitation of the Cygwin >termio? Thanks for the testcase. This was a limitation of the Cygwin DLL but it should now be fixed in the latest snapshot: http://cygwin.com/snapshots/ -- 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: 1.7.9-1: kill( pid, 0 ) on child before waitpid returns -1.
On Sat, Apr 02, 2011 at 03:12:44PM +0100, Andy Koppe wrote: >2011/4/2 Marcin Konarski: >> Subject says it all. > >Nope, it doesn't actually. Explaining why it's wrong would have been >nice. Here's the relevant bit from POSIX: > >"Existing implementations vary on the result of a kill() with pid >indicating an inactive process (a terminated process that has not been >waited for by its parent). Some indicate success on such a call >(subject to permission checking), while others give an error of >[ESRCH]. Since the definition of process lifetime in this volume of >IEEE Std 1003.1-2001 covers inactive processes, the [ESRCH] error as >described is inappropriate in this case." Thanks for the test case and the definitive source. I've checked in a fix and am in the process of building a snapshot to fix the problem. It should be available in a few minutes at http://cygwin.com/snapshots/ . cgf -- 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
