Re: UAC .manifest files
Peter Rosin wrote: > ltwrappers are just replacing the old wrappers AFAIK, and those are > indeed needed by the MSVC patches, so that premise has already changed. > > If you can't be bothered to cooperate with those patches then I can > switch to arguing that cccl (wrapper for MSVC) is supported by libtool. > When you use cccl with a contemporary MSVC, MSVC will create the > manifest for you. You should not overwrite the manifest generated > by MSVC in that case. > > So again, please special case this to only be active for gcc (and > whatever else needs it). Peter: I don't know why you're arguing with Yaakov; you really should be talking to me. I've already said I want to take this to the libtool list and discuss it there, and you can be sure it won't go into *libtool-master* until everybody is happy. I just wanted to make sure the patch worked and didn't break any of the tests (Bzzt. bad formatting failed sh.test) before I posted it, on Yaakov's behalf, for discussion on libtool-patches. Now, today's cygwin-only libtool release did include Yaakov's patch, but only for this reason: we're coming up on the cygwin-1.7 release and I know that Yaakov has about 1500 packages to rebuild in the very near future. Anything to make that easier... Plus, because I've decided to start pushing again -- hard -- to get my existing patches into libtool-master, I *know* I'll be rolling a new libtool release fairly soon. So, today's -4/-13 packages will have a pretty short shelf life. If they cause a problem for you, don't use them... -3/-12 aren't going anywhere, and you'll probably like -5/-14 better. As an aside, it's a little ridiculous to badger Yaakov, or anybody else, about cooperating with out-of-tree patches. Now, it's not your fault that they are still out of tree. Frankly, I have no idea why they weren't merged months ago (same as certain OTHER patches I could mention). But until they are merged, and MSVC is fully supported...well, you know the score. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: {xz/liblzma-devel}-4.999.8beta_20090605-10; New: liblzma1-4.999.8beta_20090605-10
The xz package is the successor to lzma. Its command-line tools support both .lzma files and the new .xz format, and it ships with compatibility links so you don't even need to retrain your fingers: 'lzma', 'lzcat', etc, are all still present. However, you probably should: .xz files are already being used by some upstream source distribution sites, including GNU FSF, and the new format includes features (such as internal integrity checks) that the old .lzma format lacks. The xz package provides a new runtime library: liblzma supports encoding as well as decoding, both .lzma and .xz streams. The older liblzmadec library supported decoding .lzma streams only. Notes about stability: == >From the package README: This is a beta version. The .xz file format is now stable though, which means that files created with the beta version will be uncompressible with all future XZ Utils versions too (assuming that there are no catastrophical bugs). liblzma API is pretty stable now, although minor tweaks may still be done if really needed. The ABI is not stable yet. The major soname will be bumped right before the first stable release. Probably it will be bumped to something like .so.5.0.0 because some distributions using the alpha versions already had to use other versions than .so.0.0.0. For cygwin, this means that the current DLL number "0" will be changed to "5" (or whatever major soname upstream decides on) when xz-5.0 is released. This gives us plenty of room (1-4) for other DLL number changes between now and that release for any issues that pop up (esp. related to the gcc4 switch?) The final 5.0 release is expected relatively soon. However, I wanted cygwin to begin supporting the new (now stable) .xz file format as soon as possible -- and "soon" sounds dangerously close to the (laughable and always wrong) "Real Soon Now". [[ compiled using gcc-3.4.4-999 ]] This package differs from the simultaneously-released xz-4.999.8beta_20090605-1 package for cygwin-1.5 in only trivial ways: the README references cygport-0.9.7 and cygwin-1.7.0-50, and the /usr/share/doc/ layout is influenced by the cygport changes between 0.4.x and 0.9.x. CHANGES (since xz-4.999beta8-10) o Update to latest git master (author says current top-of-tree is "much better" than 4.999beta8, but is not going to release a new beta anytime soon. Go figure.) o However, there has been an ABI change so the DLL number needs to be bumped. liblzma0 remains, but is now obsolete. o Remove cygwin from requires: in hint files, as sourceware will take care of that. -- Charles Wilson volunteer xz maintainer for cygwin To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: {xz/liblzma-devel}-4.999.8beta_20090605-1; New: liblzma1-4.999.8beta_20090605-1
The xz package is the successor to lzma. Its command-line tools support both .lzma files and the new .xz format, and it ships with compatibility links so you don't even need to retrain your fingers: 'lzma', 'lzcat', etc, are all still present. However, you probably should: .xz files are already being used by some upstream source distribution sites, including GNU FSF, and the new format includes features (such as internal integrity checks) that the old .lzma format lacks. The xz package provides a new runtime library: liblzma supports encoding as well as decoding, both .lzma and .xz streams. The older liblzmadec library supported decoding .lzma streams only. Notes about stability: == >From the package README: This is a beta version. The .xz file format is now stable though, which means that files created with the beta version will be uncompressible with all future XZ Utils versions too (assuming that there are no catastrophical bugs). liblzma API is pretty stable now, although minor tweaks may still be done if really needed. The ABI is not stable yet. The major soname will be bumped right before the first stable release. Probably it will be bumped to something like .so.5.0.0 because some distributions using the alpha versions already had to use other versions than .so.0.0.0. For cygwin, this means that the current DLL number "1" will be changed to "5" (or whatever major soname upstream decides on) when xz-5.0 is released. This gives us plenty of room (1-4) for other DLL number changes between now and that release for any issues that pop up. The final 5.0 release is expected relatively soon. However, I wanted cygwin to begin supporting the new (now stable) .xz file format as soon as possible -- and "soon" sounds dangerously close to the (laughable and always wrong) "Real Soon Now". [[ compiled using gcc-3.4.4-999 ]] There WILL be additional releases of xz for the cygwin-1.5 distribution, but xz-5.0-1 will probably be the last one. Future development would then continue with xz-5.0-10 for cygwin-1.7. CHANGES (since xz-4.999beta8-1) o Update to latest git master (author says current top-of-tree is "much better" than 4.999beta8, but is not going to release a new beta anytime soon. Go figure.) o However, there has been an ABI change so the DLL number needs to be bumped. liblzma0 remains, but is now obsolete. o Remove cygwin from requires: in hint files, as sourceware will take care of that. -- Charles Wilson volunteer xz maintainer for cygwin To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: {libtool/libltdl7}-2.2.7a-4
GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. This is a bugfix update. [[ compiled using gcc-3.4.4-999 ]] Unless there are serious issues with this package, it is likely to be the last version of libtool released for cygwin-1.5. This release differs from the simultaneously-released libtool-2.2.7a-13 for cygwin-1.7 in only trivial ways. CHANGES SINCE 2.2.7a-3 = * Updated to latest git master version (2009-06-15, 2772d14559c584d142e44fdea69124ce62285b40 This incorporates all of the earlier patches from Yaakov Selkowitz. However, git master does not yet include the following patches - allow -dlpreopen with -disable-shared - enable cwrapper execution in unix-to-cygwin cross environment, assuming $build is x86, wine installed, and binfmt kernel extension in use. - additional cwrapper documentation These patches are still included in this cygwin release. * Include two new patches from Yaakov Selkowitz - Ensure LT_PATH_LD works when called before LT_INIT - [cygwin|mingw] Create UAC manifest files. * Remove explicit 'cygwin' requires: entry from .hint files as that is handled on sourceware. Test results -- old tests: All 113 tests passed 2 tests were not run Test results -- new tests: 80 tests behaved as expected. 8 tests were skipped. (no regressions from 2.2.7a-3) -- Charles Wilson volunteer libtool maintainer for cygwin To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-13
GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. This is a bugfix and feature enhancement update. [[ compiled using gcc-3.4.4-999 ]] This release is specific for cygwin-1.7, but it differs from the simultaneously-released libtool-2.2.7a-4 cygwin-1.5 in only trivial ways. CHANGES SINCE 2.2.7a-12 = * Updated to latest git master version (2009-06-15, 2772d14559c584d142e44fdea69124ce62285b40 This incorporates all of the earlier patches from Yaakov Selkowitz. However, git master does not yet include the following patches - allow -dlpreopen with -disable-shared - enable cwrapper execution in unix-to-cygwin cross environment, assuming $build is x86, wine installed, and binfmt kernel extension in use. - additional cwrapper documentation These patches are still included in this cygwin release. * Include two new patches from Yaakov Selkowitz - Ensure LT_PATH_LD works when called before LT_INIT - [cygwin|mingw] Create UAC manifest files. * Remove explicit 'cygwin' requires: entry from .hint files as that is handled on sourceware. Test results -- old tests: All 113 tests passed 2 tests were not run Test results -- new tests: 80 tests behaved as expected. 8 tests were skipped. (no regressions from 2.2.7a-12) -- Charles Wilson volunteer libtool maintainer for cygwin To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from 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://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.7.0-50
Don't know how you fix it but now I am able to use git on cygwin 1.7 and using cygwin protocol. So cygwin is as stable as 1.5 for my use. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Some files are missing from cygwin-doc version 1.5-1
setup-1.7.exe installs the package 'cygwin-doc', version 1.5-1. This package includes /usr/share/info/cygwin.info. cygwin.info references two files, 'cygwin-ug-net.info' and 'cygwin-api.info', which are not included in 'cygwin-doc': $ cygcheck -c cygwin-doc Cygwin Package Information Package Version Status cygwin-doc1.5-1 OK $ cygcheck -l cygwin-doc | grep /usr/share/info/cygwin /usr/share/info/cygwin.info -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
When I ran setup-1.7.exe with the default set of packages
selected, the following error message was displayed:
running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c
/etc/postinstall/base-files-profile.sh
abnormal exit: exit code=-1073741819
'base-files-profile.sh' contains the following line:
/bin/mkdir -p `dirname ${fDest}`
'dirname' is /usr/bin/dirname. Does setup-1.7.exe set
PATH before running 'base-files-profile.sh'? If not,
then this would account for the error.
It is possible to rewrite the command without using
'dirname':
/bin/mkdir -p ${fDest%/*}
$ cygcheck -f /etc/postinstall/base-files-profile.sh
base-files-3.8-3
$ cygcheck -c base-files-3.8
Cygwin Package Information
Package VersionStatus
base-files 3.8-3 OK
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: cygwin-1.7.0-50
On Sat, Jun 20, 2009 at 01:02:17AM -0400, Charles Wilson wrote: >Christopher Faylor wrote: >> On Sat, Jun 20, 2009 at 12:01:41AM -0400, Christopher Faylor wrote: >> And, just for the sake of accuracy, there should be fewer "unable to >> remaps" thanks to my 2009-06-07 change. > >Yeah -- now I remember Corinna tried a few things first, but then it was >your mod to use the cygheap for the "extra DLL data" rather than using >VirtualAlloc/NtCreateSection to put it "just after the DLL" that really >knocked that one down. > >Fewer "unable to remaps" -- yeah, I think we can say that... > >ZERO, is more like it! Woo hoo! Given the fact that I added the previous "add data after the dll was loaded" code, which apparently caused its share of remap problems, I think this particular "accomplishment" is pretty much a zero. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.7.0-50
On Sat, Jun 20, 2009 at 01:36:01PM +0200, Vincent R. wrote: >Don't know how you fix it but now I am able to use git on cygwin 1.7 and >using cygwin protocol. >So cygwin is as stable as 1.5 for my use. Now, *that* one was probably one of Corinna's many changes to networking. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
On Sat, Jun 20, 2009 at 11:39:59AM -0400, Mark Harig wrote:
>When I ran setup-1.7.exe with the default set of packages
>selected, the following error message was displayed:
>
>running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c
>/etc/postinstall/base-files-profile.sh
>abnormal exit: exit code=-1073741819
>
>'base-files-profile.sh' contains the following line:
>
>/bin/mkdir -p `dirname ${fDest}`
>
>'dirname' is /usr/bin/dirname. Does setup-1.7.exe set
>PATH before running 'base-files-profile.sh'? If not,
>then this would account for the error.
>
>It is possible to rewrite the command without using
>'dirname':
>
>/bin/mkdir -p ${fDest%/*}
>
>$ cygcheck -f /etc/postinstall/base-files-profile.sh
>base-files-3.8-3
>
>$ cygcheck -c base-files-3.8
>Cygwin Package Information
>Package VersionStatus
>base-files 3.8-3 OK
It does set the path. This is one of those cases where we really do
need to see the cygcheck output:
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Cygwin 1.7: Possible file permission errors in 'base-files'
The two files 'base-files-mketc.sh' and 'base-files-profiles.sh' included in the 'base-files' package have their permissions set to 644 while all other scripts in /etc/postinstall/ have their permissions set to 755. Is this a side-effect of 'base-files-profiles.sh' not completing without errors, or is this set in the packaging? (Technically, the files with the permission problems are /etc/postinstall/base-files-mketc.sh.done and /etc/postinstall/base-files-profiles.sh.done.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
'dirname' is /usr/bin/dirname. Does setup-1.7.exe set
PATH before running 'base-files-profile.sh'? If not,
then this would account for the error.
It is possible to rewrite the command without using
'dirname':
/bin/mkdir -p ${fDest%/*}
$ cygcheck -f /etc/postinstall/base-files-profile.sh
base-files-3.8-3
$ cygcheck -c base-files-3.8
Cygwin Package Information
Package VersionStatus
base-files 3.8-3 OK
It does set the path. This is one of those cases where we really do
need to see the cygcheck output:
Included below (as an attachment) is the file generated by:
$ cygcheck -s -v -r > cygcheck.out
Cygwin Configuration Diagnostics
Current System Time: Sat Jun 20 13:01:52 2009
Windows XP Media Center Edition Ver 5.1 Build 2600 Service Pack 3
Path: C:\cygwin-1.7\usr\local\bin
C:\cygwin-1.7\bin
C:\cygwin-1.7\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
Output from C:\cygwin-1.7\bin\id.exe (nontsec)
UID: 1007(a_user) GID: 513(None)
0(root) 544(Administrators) 545(Users) 513(None)
Output from C:\cygwin-1.7\bin\id.exe (ntsec)
UID: 1007(a_user) GID: 513(None)
0(root) 544(Administrators) 545(Users) 513(None)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
PWD = '/etc/postinstall'
CYGWIN = 'tty'
HOME = '/home/a_user'
HOMEPATH = '\Documents and Settings\a_user'
APPDATA = 'C:\Documents and Settings\a_user\Application Data'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel'
WINDIR = 'C:\WINDOWS'
WINDOWID = '8096040'
OLDPWD = '/etc'
USERDOMAIN = 'AHOSTNAME'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/c/DOCUME~1/a_user/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Program Files\Common Files\GTK\2.0\bin'
QTJAVA = 'C:\Program Files\Java\jre1.5.0_02\lib\ext\QTJava.zip'
USERNAME = 'a_user'
PROCESSOR_LEVEL = '6'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
__COMPAT_LAYER = 'EnableNXShowUI '
USERPROFILE = 'C:\Documents and Settings\a_user'
LOGONSERVER = '\\AHOSTNAME'
PROCESSOR_ARCHITECTURE = 'x86'
SHLVL = '1'
COLORFGBG = '0;default;15'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/c/DOCUME~1/a_user/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PROCESSOR_REVISION = '0f06'
CLASSPATH = '.;C:\Program Files\Java\jre1.5.0_02\lib\ext\QTJava.zip'
PROGRAMFILES = 'C:\Program Files'
DISPLAY = ':0'
NUMBER_OF_PROCESSORS = '2'
SESSIONNAME = 'Console'
COMPUTERNAME = 'AHOSTNAME'
COLORTERM = 'rxvt-xpm'
_ = '/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
Menu2\Programs\Cygwin
(default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = '/'
cygdrive flags = 0x002a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = 'C:\cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/desktop
(default) = 'c:\Documents and Settings\a_user\Desktop'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = 'C:\cygwin/bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = 'C:\cygwin/lib'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
(default) = 'C:\cygwin-1.7'
obcaseinsensitive set to 1
c: hd NTFS 55623Mb 72% CP CS UN PA FC
d: hd FAT32 6991Mb 49% CPUN RECOVERY
e: cd N/AN/A
C:\cygwin-1.7 / system binary,auto
c:\Documents and Settings\a_user\Desktop /desktop system binary
C:\cygwin-1.7\bin /usr/bin system binary,auto
C:\cygwin-1.7\lib /usr/lib system binary,auto
cygdrive prefix / user
binary,posix=0,auto
Found: C:\cygwin-1.7\bin\awk.exe
Found: C:\cygwin-1.7\bin\awk.exe
-> C:\cygwin-1.7\bin\gawk.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cp.exe
Found: C:\cygwin-1.7\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\WINDOWS\system32\find.exe
Re: cygwin-1.7.0-50
Christopher Faylor wrote: > Given the fact that I added the previous "add data after the dll was > loaded" code, which apparently caused its share of remap problems, I > think this particular "accomplishment" is pretty much a zero. Doesn't matter. I'm still overjoyed. If it wouldn't get me permanently disinvited from any and all social engagements for being just too darn geeky for words, I'd be annoying everybody in my Friends&Family calling plan to tell them how happy this has made me. Yay cgf! -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin 1.7: Uninstalling all (base) packages using setup-1.7.exe
After installing all default, base packages in Cygwin, I attempted to uninstall this base set by clicking on the "cycle" button/icon of the 'All' category (while the setup view for packages was set to 'Category') until 'Uninstall' was displayed for 'All' and for all sub-categories. When I clicked the 'Next' button, setup displays a window with the following text: Warning! Unmet Dependencies Found The following packages are required but have not been selected. Package: bash Required by: _update-info-dir Package: cygwin Required by: gcc4-runtime, libproj0, Numeric, _update-info-dir Package: python Required by: Numeric Package: texinfo Required by: _update-info-dir Should not 'setup' be uninstalling '_update-info-dir' and the other packages listed? When I removed the check from the check-box labeled: "Install these packages to meet dependencies (RECOMMENDED)" and click the 'Next' button, the following warning message is displayed: WARNING - Required Packages Not Selected If you continue without correcting the listed conflicts, your Cygwin installation will not function properly. We strongly recommend that you let Setup install the listed packages. Are you sure you want to proceed? After clicking on 'Yes', setup runs to completion and includes the text "Installation Status: Uninstalls complete." -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
read -t hangs sometimes with pipes
Hi, Sometimes pipes, created with mknod, seems not to be work fully correct. Most of the time I can do: mknod /var/run/CONT p read -t 2 signal < /var/run/CONT. After 2 seconds I receive a timeout and the read returns. But sometimes the read will wait forever. And also if I write something to /var/run/CONT, the read did not read it. Furthermore I can not "reset" anything. I have to reboot the workstation thats pipes works again. Is there any posibility to reset something that pipes will work again without reboot? Thanks Matthias -- Don't Panic -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: read -t hangs sometimes with pipes
On Sat, Jun 20, 2009 at 09:14:08PM +0200, Matthias Meyer wrote: >Sometimes pipes, created with mknod, seems not to be work fully correct. > >Most of the time I can do: >mknod /var/run/CONT p >read -t 2 signal < /var/run/CONT. > >After 2 seconds I receive a timeout and the read returns. >But sometimes the read will wait forever. And also if I write something >to /var/run/CONT, the read did not read it. > >Furthermore I can not "reset" anything. I have to reboot the workstation >thats pipes works again. > >Is there any posibility to reset something that pipes will work again >without reboot? >Problem reports: http://cygwin.com/problems.html ^^ Please provide the information listed here. 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: UAC .manifest files
Den 2009-06-20 09:05 skrev Charles Wilson: Peter Rosin wrote: ltwrappers are just replacing the old wrappers AFAIK, and those are indeed needed by the MSVC patches, so that premise has already changed. If you can't be bothered to cooperate with those patches then I can switch to arguing that cccl (wrapper for MSVC) is supported by libtool. When you use cccl with a contemporary MSVC, MSVC will create the manifest for you. You should not overwrite the manifest generated by MSVC in that case. So again, please special case this to only be active for gcc (and whatever else needs it). Peter: I don't know why you're arguing with Yaakov; you really should be talking to me. I've already said I want to take this to the libtool list and discuss it there, and you can be sure it won't go into *libtool-master* until everybody is happy. I just wanted to make sure the patch worked and didn't break any of the tests (Bzzt. bad formatting failed sh.test) before I posted it, on Yaakov's behalf, for discussion on libtool-patches. Now, today's cygwin-only libtool release did include Yaakov's patch, but only for this reason: we're coming up on the cygwin-1.7 release and I know that Yaakov has about 1500 packages to rebuild in the very near future. Anything to make that easier... Plus, because I've decided to start pushing again -- hard -- to get my existing patches into libtool-master, I *know* I'll be rolling a new libtool release fairly soon. So, today's -4/-13 packages will have a pretty short shelf life. If they cause a problem for you, don't use them... -3/-12 aren't going anywhere, and you'll probably like -5/-14 better. I argu because I'm peeved. One primary reason and a very secondary reason. Primary: Yaakov has been ignoring me. Hard! * http://www.cygwin.com/ml/cygwin/2008-11/msg00298.html * http://www.cygwin.com/ml/cygwin/2008-12/msg00448.html * http://www.cygwin.com/ml/cygwin/2009-06/msg00417.html I have made several attempts, but I have gotten zero feedback. Nothing whatsoever. Incredibly rude IMHO. How difficult is it to acknoledge a bug report? Even to say it is invalid (if that's the case)? I would have been satisfied with any response I'd gotten (well, any reasonably civil response), but total silence simply isn't acceptable. Secondary: Sitting for years waiting for libtool patches to get in while other libtool patches whissle past in the fast lane will do strange things to you. You mentioning patches that have not been merged for a couple of months seem /almost/ like a bad joke (I know it's not comparable, but that's what it tastes like). The combination of the above two and the fact that I'm only human made me lash out. As an aside, it's a little ridiculous to badger Yaakov, or anybody else, about cooperating with out-of-tree patches. Now, it's not your fault that they are still out of tree. Frankly, I have no idea why they weren't merged months ago (same as certain OTHER patches I could mention). But until they are merged, and MSVC is fully supported...well, you know the score. Ok, I was out of line about the MSVC patches and that was admittedly a bad start. I was somewhat upset. But do note that you apparently missed the passage in the second message where I explain that the changes are harming existing setups. My point is that the patch is not perfect and that it needs fixing. I don't care who fixes it, as long as it's not me. I wouldn't be surprised if I'm the one who fixes it eventually though. Cheers, Peter -- 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
Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh
After running setup-1.7.exe to install the package 'rxvt', I found the following error in /var/log/setup.log.full: 2009/06/20 16:00:17 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/rxvt.sh Using the default version of /etc/X11/app-defaults/Rxvt (/etc/defaults/etc/X11/app-defaults/Rxvt) /bin/touch: cannot touch `/etc/X11/app-defaults/Rxvt': No such file or directory /bin/cp: cannot create regular file `/etc/X11/app-defaults/Rxvt': No such file or directory The directory tree needed by the configuration file 'Rxvt' is missing. $ ls -l /etc/X11/app-defaults ls: cannot access /etc/X11/app-defaults: No such file or directory $ ls -l /etc/X11 ls: cannot access /etc/X11: No such file or directory Is the 'rxvt' package responsible for creating these missing directories? -- 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: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
Mark Harig wrote: > Potential app conflicts: > > Logitech Process Monitor service > Detected: HKLM Registry Key, Named process. You definitely need to stop and disable that service. It borks cygwin something rotten. cheers, DaveK -- 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
ITP on cygwin-apps
Hi! I was just wondering about the customs on cygwon-apps. I have posted an ITP for a package to be included in cygwin which is in Fedora, but haven't got any feedback yet. Before asking again for a review I wanted to know what are the general guidelines, customs on reposting requests for a review of an ITP. THX /Fredde -- 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: Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh
Mark Harig wrote: > Is the 'rxvt' package responsible for creating these > missing directories? Well, *I* think they ought to be created by the X system. Currently, you kinda get them by default IF you install any of the X-related packages, because unlike rxvt, those other package directly incorporate, eg. /etc/X11/app-defaults/XTerm so when the xterm-242-1.tar.bz2 package is unpacked: viola! you have /etc/X11/app-defaults/ But, none of those packages SHOULD be doing it that way. They SHOULD be doing it the rxvt way, where the "default defaults" are installed into /etc/defaults/etc/X11/app-defaults/ and a postinstall script copies the file from there into /etc/X11/app-defaults/ if and only if the current copy has not been changed from the previous /etc/default/ version. (That is, *preserve user customizations*). None of the other packages do that. That having been said...rxvt is stealing a march by assuming /etc/X11/app-defaults/ exists. It's not clear -- if all the other packages did it the "rxvt way" -- WHO exactly should be responsible for creating the directory. I'll enhance the rxvt postinstall script to handle that in a future release. -- Chuck -- 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: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
> Potential app conflicts: > > Logitech Process Monitor service > Detected: HKLM Registry Key, Named process. You definitely need to stop and disable that service. It borks cygwin something rotten. Thank you. I will try that (anything to give my cygwin processes better behavior than they have now). Is this problem with the Logitech Process Monitor service described in the Cygwin documentation? -- 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: Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh
That having been said...rxvt is stealing a march by assuming /etc/X11/app-defaults/ exists. It's not clear -- if all the other packages did it the "rxvt way" -- WHO exactly should be responsible for creating the directory. 1. 'rxvt' is advertised as being available without X, so it cannot depend on X installation actions, can it? 2. What are packages' responsibilities are with respect to 'setup.exe'? Naive users should be able to install the base set of packages without any errors appearing in /var/log/setup.log*, correct? And they should be able immediately upon successfully installing the base set of packages, be able to un-install that set of packages without any errors appearing in /var/log/setup.log, I would expect. 3. If each of the packages was during installation to adopt the responsibility of: - Checking for every directory it needs - If the directory (tree) does not exist, create it - Populating the directories with the files it uses and then during un-installation, un-do what it did during installation: - Remove any (non-modified configuration) files - Remove any directory (trees) that it created during installation (using 'rmdir --ignore-fail-on-non-empty') then 'setup.exe' ought to be able to install/uninstall reproducibly without errors. I'll enhance the rxvt postinstall script to handle that in a future release. Thank you. -- 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: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
Mark Harig wrote: >> >> > Potential app conflicts: >> > > Logitech Process Monitor service >> > Detected: HKLM Registry Key, Named process. >> >> You definitely need to stop and disable that service. It borks cygwin >> something rotten. >> > Thank you. I will try that (anything to give my cygwin > processes better behavior than they have now). > > Is this problem with the Logitech Process Monitor service > described in the Cygwin documentation? http://cygwin.com/faq/faq.using.html#faq.using.bloda http://cygwin.com/acronyms#BLODA cheers, DaveK -- 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: Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh
Mark Harig wrote: > 1. > 2. > 3. Sure, all those things would be great, and given the limited time the few volunteers have to address such things it'd be great to satisfy that checklist. But if we had to meet some zero-defect six-sigma policy, cygwin would have about four packages total. We'll do the best we can and respond to bug reports and enhancement requests, to the limit of available resources. -- Chuck -- 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: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
Dave Korn wrote: > > Is this problem with the Logitech Process Monitor service > described in the Cygwin documentation? http://cygwin.com/faq/faq.using.html#faq.using.bloda Thanks again for the additional information. I will be working my way through the entire FAQ at that link. http://cygwin.com/acronyms#BLODA From that link: FYI For Your Information. Also "Fix Yourself It" (for all the Star Wars fans out there) Perhaps, DIY (Do It Yourself) could be added. My guess is that it is more commonly used and understood than "fix yourself it." I am not yet using cygwin 1.7. I am trying to install it (and un-install it) as I think a naive user might. I read the following two links that were provided with the announcement for cygwin-1.7.0-50: We have a new User's Guide for 1.7, which is currently located at http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html and And we have a new FAQ, though very likely not quite complete since we still don't know what exactly *is* a FAQ related to Cygwin 1.7. http://cygwin.com/1.7/faq/faq.html I see that at http://cygwin.com/1.7/faq/faq.setup.html, item 8 references the link that you provided under the heading "My computer hangs when I run Cygwin Setup!" My computer is not "hanging" -- it is just issuing error messages during install/un-install using setup-1.7.exe. -- 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: ITP on cygwin-apps
Federico Hernandez wrote: Hi! I was just wondering about the customs on cygwon-apps. I have posted an ITP for a package to be included in cygwin which is in Fedora, but haven't got any feedback yet. Before asking again for a review I wanted to know what are the general guidelines, customs on reposting requests for a review of an ITP. No, not really. I'm sure you've just run into the normal issue of someone finding the cycles to do a proper review. Don't fret too much about it. :-) Just ping again. And you should feel free to address any questions, issues, or requests you have related to packages/packaging (yours or otherwise) at cygwin-apps. That's why it exists. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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
