[RFU] qhull-2010.1-1
new upstream version, mainly bugfix wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/qhull libqhull-devel/libqhull-devel-2010.1-1.tar.bz2 libqhull-devel/setup.hint libqhull_5/libqhull_5-2010.1-1.tar.bz2 libqhull_5/setup.hint qhull-2010.1-1-src.tar.bz2 qhull-2010.1-1.tar.bz2 setup.hint Regards Marco
[RFU]libSuiteSparse-3.5.0-1
new upstream bugfix version to download wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/SuiteSparse libSuiteSparse-devel/libSuiteSparse-devel-3.5.0-1.tar.bz2 libSuiteSparse-devel/setup.hint setup.hint SuiteSparse-3.5.0-1-src.tar.bz2 SuiteSparse-3.5.0-1.tar.bz2 Regards Marco
[RFU] lapack-3.2.2-1
new upstream bugfix version to download wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/lapack lapack-3.2.2-1-src.tar.bz2 liblapack-devel/liblapack-devel-3.2.2-1.tar.bz2 liblapack-devel/setup.hint liblapack0/liblapack0-3.2.2-1.tar.bz2 liblapack0/setup.hint setup.hint
[ITP] ngspice-21-1
Hi, Ngspice is a mixed-level/mixed-signal circuit simulator based on Spice3f5 The package is already in Debian, and the licence is mainly BSD Built with ./configure --enable-xgraph --enable-x --with-editline=yes one patch taken by the development branch to avoid libedit consuming all CPU cycles. to download wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/ngspice ngspice-21-1-src.tar.bz2 ngspice-21-1.tar.bz2 setup.hint Regards Marco
Re: [RFU] qhull-2010.1-1
On Aug 25 09:42, Marco Atzeri wrote: new upstream version, mainly bugfix wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/qhull libqhull-devel/libqhull-devel-2010.1-1.tar.bz2 libqhull-devel/setup.hint libqhull_5/libqhull_5-2010.1-1.tar.bz2 libqhull_5/setup.hint qhull-2010.1-1-src.tar.bz2 qhull-2010.1-1.tar.bz2 setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU]libSuiteSparse-3.5.0-1
On Aug 25 09:48, Marco Atzeri wrote: new upstream bugfix version to download wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/SuiteSparse libSuiteSparse-devel/libSuiteSparse-devel-3.5.0-1.tar.bz2 libSuiteSparse-devel/setup.hint setup.hint SuiteSparse-3.5.0-1-src.tar.bz2 SuiteSparse-3.5.0-1.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] lapack-3.2.2-1
On Aug 25 09:50, Marco Atzeri wrote: new upstream bugfix version to download wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/lapack lapack-3.2.2-1-src.tar.bz2 liblapack-devel/liblapack-devel-3.2.2-1.tar.bz2 liblapack-devel/setup.hint liblapack0/liblapack0-3.2.2-1.tar.bz2 liblapack0/setup.hint setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] ngspice-21-1
On Aug 25 10:09, Marco Atzeri wrote: Hi, Ngspice is a mixed-level/mixed-signal circuit simulator based on Spice3f5 The package is already in Debian, and the licence is mainly BSD Built with ./configure --enable-xgraph --enable-x --with-editline=yes one patch taken by the development branch to avoid libedit consuming all CPU cycles. to download wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/ngspice ngspice-21-1-src.tar.bz2 ngspice-21-1.tar.bz2 setup.hint Packaging looks good. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] ngspice-21-1
--- Mer 25/8/10, Corinna Vinschen ha scritto: Packaging looks good. Uploaded. Thanks, Corinna Thanks, I forgot one question about the category. I used only Math as I see that Science is currently not used by any package. Can we add it for ngspice ? Marco
Re: bug tracker discussion
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com writes: Can I get a show of hands? How many package maintainers would like to have a bug tracker? There is only one good, easy to use, user/maintainer friendly bug tracker I know of: debbugs [1] The best thing about it is that it is very lightweight and controllable by email. There are exiting UI's for Emacs that make the management non-time consuming. I'm not in favor of any of the other exiting web based bug trackers. Jari [1] The code is freely available. E.g. It seems to have gained momentum amongst the GNU project as well.
Re: [ITP] ngspice-21-1
On Aug 25 12:58, Marco Atzeri wrote: --- Mer 25/8/10, Corinna Vinschen ha scritto: Packaging looks good. Uploaded. Thanks, Corinna Thanks, I forgot one question about the category. I used only Math as I see that Science is currently not used by any package. Can we add it for ngspice ? It's an offically supported category for Cygwin packages, so, sure, done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] cabextract 1.3 (Jari Aalto please respond)
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com writes: On Tue, Jul 27, 2010 at 06:08:51PM -0400, Christopher Faylor wrote: Oops. I should have checked the package maintainer list before encouraging you, Stuart. It looks like the maintainer for cabextract is still active. I assume he won't mind relinquishing maintainership to the person who actually wrote the program. But I'd like to get his ok before going further. I actually went as far as uploading this file before checking to see who used to maintain it. I did make one change: The new package relies on libgcc so I added a libgcc1 dependency to the setup.hint. If I get Jari's ok, I'll move the package to cygwin's release directory and, after I have sent an uploaded message here, you can then send an announcement to cygwin-announce patterned after what you see here: Sure, as the Stuart is the maintainer. http://cygwin.com/ml/cygwin-announce/2010-07/ Thanks for offering to do this. It is much appreciated. Well, I think that's a long enough wait. Well, I just got back from 3 month vacation. Jari
Re: bug tracker discussion
On Wed, Aug 25, 2010 at 05:06:42PM +0300, Jari Aalto wrote: Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com writes: Can I get a show of hands? How many package maintainers would like to have a bug tracker? There is only one good, easy to use, user/maintainer friendly bug tracker I know of: debbugs [1] You obviously weren't paying attention to the cygwin mailing list discussion. sourceware.org uses bugzilla (or gnats but no one wants to go there). That's what we'd be using. I wasn't soliciting for the best bug tracker. I was asking if maintainers wanted to use bugzilla. I should have made that clearer although I thought people would have been reading the discussion in the cygwin list. cgf
Re: [ITP] mingw-w64 Second try
On 8/25/2010 12:19, JonY wrote: Hi, since cygport and gcc has been updated, I can do the packaging without any local hacks. Here are the packages. mingw64-x86_64-pthreads https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-pthreads/mingw64-x86_64-pthreads-20100619-1-src.tar.bz2/download category: Devel requires: mingw64-x86_64-runtime sdesc: libpthread for MinGW-w64 Win64 toolchain mingw64-x86_64-headers https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-headers/mingw64-x86_64-headers-svn3433-1.tar.bz2/download category: Devel requires: sdesc: Mingw-w64 headers for Win64 target. ldesc: Mingw-w64 headers for Win64 target development. This package is for the mingw-w64 toolchain that targets 64bit. mingw64-x86_64-runtime https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-runtime/mingw64-x86_64-runtime-20100809-1-src.tar.bz2/download category: Devel requires: mingw64-x86_64-headers sdesc: CRT libraries for Win64 target. ldesc: Mingw-w64 CRT libraries for Win64 target development. mingw64-x86_64-binutils https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1-src.tar.bz2/download https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-binutils/mingw64-x86_64-binutils-2.20.51-1.tar.bz2/download category: Devel requires: libgcc1 libintl8 zlib0 sdesc: Binutils for MinGW-w64 Win64 toolchain ldesc: Mingw-w64 Cross binutils for Win64 target. mingw64-x86_64-gcc-fortran https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-fortran/mingw64-x86_64-gcc-fortran-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC gfortran for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-core https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-core/mingw64-x86_64-gcc-core-4.5.1-1.tar.bz2/download category: Devel requires: libcloog0 libgcc1 libgmp3 libiconv2 libintl8 libmpc1 libmpfr1 libppl mingw64-x86_64-binutils mingw64-x86_64-pthreads mingw64-x86_64-runtime sdesc: GCC for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-g++ https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-g%2B%2B/mingw64-x86_64-gcc-g%2B%2B-4.5.1-1.tar.bz2/download ategory: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc mingw64-x86_64-gcc-ada https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-ada/mingw64-x86_64-gcc-ada-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC ada for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc-objc https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-objc/mingw64-x86_64-gcc-objc-4.5.1-1.tar.bz2/download category: Devel requires: mingw64-x86_64-gcc external-source: mingw64-x86_64-gcc sdesc: GCC objc and objc++ for MinGW-w64 Win64 toolchain mingw64-x86_64-gcc https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1-src.tar.bz2/download Ping.
RE: X Server no longer launches urxvtc-X
Thanks Bob,
this eliminates the '/bin/find' error when starting rxvt or urxvt.
I just added
cd /
before the PATH= line.
Still cannot run urxvtc from X server tray app.
-Original Message-
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-
ow...@cygwin.com] On Behalf Of Rob Gillen
Sent: Tuesday, August 24, 2010 4:27 PM
To: cygwin-xfree@cygwin.com
Subject: RE: X Server no longer launches urxvtc-X
Another data point, when I try:
black EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g
80x40 -e /bin/bash -l -i
rxvt successfully starts up but displays:
/bin/find: failed to restore initial working directory: No such
file or directory
Before .bash_profile is invoked
Jay, I resolved the find issue by modifying the /etc/profile file.
The real issue is the change made in the latest release of the
cygwin1.dll where the current working directory is set to an invalid
directory. Until you set the current working directory to something
when find is called, you'll continue to see this. Try moving this
portion of the /etc/profile script:
# Make sure we start in home unless invoked by CHERE
if [ ! -z ${CHERE_INVOKING} ]; then
unset CHERE_INVOKING
else
cd ${HOME}
fi
so that it is located before the execution of all the /etc/profile.d
scripts.
--
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/
--
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/
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-25 08:51:46 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (rename): Open file with FILE_READ_ATTRIBUTES. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5007r2=1.5008 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.564r2=1.565
src/winsup/cygwin ChangeLog mount.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-25 09:20:11 Modified files: winsup/cygwin : ChangeLog mount.cc Log message: * mount.cc (fs_info::update): Fix comments. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5008r2=1.5009 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mount.cc.diff?cvsroot=srcr1=1.63r2=1.64
src/winsup/w32api ChangeLog include/winuser.h ...
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-08-25 23:39:29 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: winuser.h windef.h Log message: 2010-08-25 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/winuser.h (HHOOK): Move definition from here... * include/windef.h: ...to here, as per MSDN. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1045r2=1.1046 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winuser.h.diff?cvsroot=srcr1=1.131r2=1.132 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/windef.h.diff?cvsroot=srcr1=1.22r2=1.23
src/winsup/w32api ChangeLog include/shlwapi.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-08-26 02:05:58 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: shlwapi.h Log message: 2010-08-25 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/shlwapi (ASSOCDATA): Update definition. Thank you to Frederic Deschamps for reporting the issue. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1048r2=1.1049 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/shlwapi.h.diff?cvsroot=srcr1=1.8r2=1.9
src/winsup/w32api ChangeLog include/ocidl.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-08-26 02:13:12 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: ocidl.h Log message: 2010-08-25 Ali Sabil asa...@users.sourceforge.net * include/ocidl.h: Define COBJMACROS for IPropertyBag and IPropertyBag2. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1049r2=1.1050 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ocidl.h.diff?cvsroot=srcr1=1.12r2=1.13
src/winsup/w32api ChangeLog include/sspi.h lib ...
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-08-26 02:42:31 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: sspi.h winsup/w32api/lib: secur32.def Log message: 2010-08-25 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/sspi.h (QuerySecurityContextToken): Define. * lib/secur32.def: Regenerate using gendef on a Win7 machine. Thank you to Magnus Hagander for reporting the issue. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1050r2=1.1051 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/sspi.h.diff?cvsroot=srcr1=1.9r2=1.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/secur32.def.diff?cvsroot=srcr1=1.4r2=1.5
src/winsup/w32api ChangeLog include/winuser.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-08-26 02:51:37 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: winuser.h Log message: 2010-08-25 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/winuser.h (CF_DIBV5): Define. (CF_MAX): Adjust accordingly. Thank you to Lenard Lindstrom for reporting the issue. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1051r2=1.1052 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winuser.h.diff?cvsroot=srcr1=1.132r2=1.133
src/winsup/w32api ChangeLog include/oleacc.h
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-08-26 03:06:09 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: oleacc.h Log message: 2010-08-25 Chris Sutcliffe ir0nh...@users.sourceforge.net * include/oleacc.h (STATE_SYSTEM_HASPOPUP, STATE_SYSTEM_NORMAL, STATE_SYSTEM_PROTECTED): Define. Thank you to Marcus von Appen for reporting the issue. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1052r2=1.1053 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/oleacc.h.diff?cvsroot=srcr1=1.6r2=1.7
Re: 1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server
Am 24.08.2010 18:28, schrieb Corinna Vinschen: RCS now works again (also in Windows Emacs), and so does a ~ 1300 lines script I'm currently working on. Is it safe to use this cygwin1-test2.dll for serious work? We are just preparing a new master image for several PCs and would like to include a working Cygwin 1.7. Please wait. I was hoping that you could test a little bit further. Sure. I prepared another DLL, which is very close to the real thing. There's another flag which I have to know if it's required or not. http://cygwin.de/cygwin-ug-177/cygwin1-test4.dll.bz2 (md5sum 889a86df2c2aafd010249b27bf10f411) If it works, we're finished. If not, we probably need just one more iteration. Test4 works, great. In the meantime, can you send the output of `mount' to this list? I would like to make sure that the drives are really recognized as cifs. Testing was done in /mnt/testperms with the following mounts in effect: $ mount //dlanserv/kramski$ on /mnt type cifs (binary,notexec,ihash,user) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C:/bin32 on /usr/local/bin type ntfs (binary) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type cifs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type cifs (binary,posix=0,user,noumount,auto) G: on /cygdrive/g type cifs (binary,posix=0,user,noumount,auto) H: on /cygdrive/h type cifs (binary,posix=0,user,noumount,auto) I: on /cygdrive/i type cifs (binary,posix=0,user,noumount,auto) J: on /cygdrive/j type cifs (binary,posix=0,user,noumount,auto) O: on /cygdrive/o type cifs (binary,posix=0,user,noumount,auto) P: on /cygdrive/p type cifs (binary,posix=0,user,noumount,auto) R: on /cygdrive/r type cifs (binary,posix=0,user,noumount,auto) S: on /cygdrive/s type cifs (binary,posix=0,user,noumount,auto) T: on /cygdrive/t type cifs (binary,posix=0,user,noumount,auto) W: on /cygdrive/w type cifs (binary,posix=0,user,noumount,auto) X: on /cygdrive/x type cifs (binary,posix=0,user,noumount,auto) Y: on /cygdrive/y type cifs (binary,posix=0,user,noumount,auto) As for the ihash issue, after giving this some thought I tend to keep it as it is, so you will have to use it on your Tru64 drives. At least for the next Cygwin release 1.7.7. If it's getting too awkward at some point, we can discuss this again. As you see, I have quite a lot of network drives, so I'm considering putting the ihash option globally to the uncommented /cygdrive mountpoint in /etc/fstab to cure all drives altogether. Will that cause any disadvantages for the real hardware NTFS drives C: and D:? (Doesn't look so at a first glance.) Please note the nice effect that ihashing /cygdrive/e also cures //dlanserv/KRAMSKI$, my Cygwin $HOME, which - apart from this testing - is not explicitly listed by mount. (My home share //dlanserv/KRAMSKI$ is mapped to E: on Windows). Regards, Heinz -- 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: Basic file operations fail on network shares provided by Tru64 Advanced Server
On Aug 25 08:55, Heinz Werner Kramski wrote: Am 24.08.2010 18:28, schrieb Corinna Vinschen: I prepared another DLL, which is very close to the real thing. There's another flag which I have to know if it's required or not. http://cygwin.de/cygwin-ug-177/cygwin1-test4.dll.bz2 (md5sum 889a86df2c2aafd010249b27bf10f411) If it works, we're finished. If not, we probably need just one more iteration. Test4 works, great. Cool. Thank you. I applied the patch to CVS. This will be in Cygwin 1.7.7. $ mount //dlanserv/kramski$ on /mnt type cifs (binary,notexec,ihash,user) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C:/bin32 on /usr/local/bin type ntfs (binary) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type cifs (binary,posix=0,user,noumount,auto) [...] As for the ihash issue, after giving this some thought I tend to keep it as it is, so you will have to use it on your Tru64 drives. At least for the next Cygwin release 1.7.7. If it's getting too awkward at some point, we can discuss this again. As you see, I have quite a lot of network drives, so I'm considering putting the ihash option globally to the uncommented /cygdrive mountpoint in /etc/fstab to cure all drives altogether. Will that cause any disadvantages for the real hardware NTFS drives C: and D:? (Doesn't look so at a first glance.) As you can see in the User's Guide (http://cygwin.com/cygwin-ug-net/using.html#mount-table) the ihash mount option results in ignoring the real inode numbers and just fake them by computing a hash value from the full pathname of the file. The disadvantage is that you can't recognize hardlinks. That's the reason I don't want to enforce the option on all NTFS-faking file systems (== cifs). If you think that's not a problem for you, you're all set. Otherwise, just add explicit mount points for your two local NTFS drives with different mount options. Please note the nice effect that ihashing /cygdrive/e also cures //dlanserv/KRAMSKI$, my Cygwin $HOME, which - apart from this testing - is not explicitly listed by mount. (My home share //dlanserv/KRAMSKI$ is mapped to E: on Windows). Yep, that's noted in the news for 1.7.2: http://cygwin.com/cygwin-ug-net/ov-new1.7.html#ov-new1.7.2 UNC paths now default to the same mount options as the cygdrive prefix. Thanks again for testing, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Problem with php and/or tidy packages?
On Wed, 2010-08-25 at 09:04 +0200, Gary wrote: Today I updated my cygwin installation and found that afterwards php (from cygwin ports) no longer worked correctly with tidy (official package): Questions regarding Ports packages are off-topic on the Cygwin lists. I have answered this question on cygwin-ports-general, the correct forum for these questions. Yaakov -- 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
lighttpd, nano, tidy: update (ping?)
Lapo, Ping on updates for lighttpd, nano and tidy? http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=apps/nano http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=libs/tidy http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=www/lighttpd Yaakov -- 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: lighttpd, nano, tidy: update (ping?)
On 25 August 2010 10:50, Yaakov (Cygwin/X) wrote: Lapo, Ping on updates for lighttpd, nano and tidy? http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=apps/nano Yeah, an update for nano would be really nice. Is the 2.2.4-wchar.patch still needed? 2.2.5 builds out-of-the-box for me, with plain './configure' enabling UTF-8 and picking up ncursesw. Andy -- 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: {libqhull-devel, libqhull_5, qhull}-qhull-2010.1-1
Versions qhull-2010.1-1 of libqhull-devel, libqhull_5, qhull have been uploaded for cygwin CHANGES This is an upstream maintenance release For the full changes http://www.qhull.org/src/Changes.txt DESCRIPTION Qhull is a general dimension convex hull program and library It computes volumes, surface areas, and approximations to the convex hull. HOMEPAGE http://www.qhull.org/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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. -- 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: lapack 3.2.2-1
New versions 3.2.2-1 of lapack (source) liblapack0 liblapack-devel for cygwin are available in the Cygwin distribution: CHANGES These are new bugfix upstream versions Full list of changes at: http://www.netlib.org/lapack/lapack-3.2.html http://www.netlib.org/lapack/lapack-3.2.1.html http://www.netlib.org/lapack/lapack-3.2.2.html xblas is NOT yet implemented for cygwin. DESCRIPTION Comprehensive FORTRAN library for linear algebra operations. Includes matrix inversions, least squared solutions to sets of equations, eigenvector analysis, singular value decomposition, etc. HOMEPAGE http://www.netlib.org/lapack/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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. -- 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: SuiteSparse-3.5.0-1
New versions of SuiteSparse / libSuiteSparse-devel 3.5.0-1 for cygwin are available in the Cygwin distribution: CHANGES These are new upstream versions, mainly bugfix DESCRIPTION SuiteSparse is library for sparse matrix. It is used to compile Octave HOMEPAGE http://www.cise.ufl.edu/research/sparse/SuiteSparse/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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. -- 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: Build S-Lang Fail
On Sun, Aug 22, 2010 at 8:15 PM, Steven Woody wrote: $ ldd /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe ntdll.dll = /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c92) kernel32.dll = /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80) cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0x67f0) cygwin1.dll = /usr/bin/cygwin1.dll (0x6100) ADVAPI32.DLL = /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77da) RPCRT4.dll = /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e5) Secur32.dll = /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fc) cyggmp-3.dll = /usr/bin/cyggmp-3.dll (0x63f4) cygmpfr-1.dll = /usr/bin/cygmpfr-1.dll (0x6cd8) You could either run ldd on the DLLs (cyggcc_s-1.dll, cyggmp-3.dll and cygmpfr-1.dll) or use depends.exe (http://www.dependencywalker.com/) to try to identify the missing DLL. -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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] New package: ngspice-21-1
Hi, NGSPICE is now available for cygwin. The version ngspice-21-1 has been uploaded. DESCRIPTION Ngspice is a mixed-level/mixed-signal circuit simulator. Its code is based on Spice3f5. Ngspice is part of gEDA project, a full GPL'd suite of Electronic Design Automation tools. HOMEPAGE http://ngspice.sourceforge.net Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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. -- 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: Emacs and DBUS
On 8/24/2010 11:28 PM, Michael Albinus wrote: Ken Brown writes: After installing that library, Emacs did start. How ever, it blocks when loading dbus.el. Don't you normally have to start a D-BUS session before loading dbus.el? Maybe one of the Cygwin people who uses D-BUS can tell us how to do that. I've started the session bus via dbus-launch in advance, of course. I have no idea, how to start the system bus in cygwin, 'though. Run /usr/bin/messagebus-config and follow the instructions for installing messagebus as a service. You will need to be logged in as a user with administrator privileges for this. Emacs' D-Bus code shall be resistent in case of absence of a bus, but who knows ... how could I debug it via gdb? The executable /usr/bin/emacs-nox.exe is stripped; that's why you couldn't debug it. Here's a link to the unstripped version, with debug symbols: http://www.math.cornell.edu/~kbrown/emacs-nox.exe.bz2 Ken -- 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: gcc-4.5 notes
Hi Dave, Aside from Yaakov's notes I have nothing to fix. Just to add that it is working fine for me. I've rebuilt some of my perls with extensive testsuites and everything so far was fine. Yaakov's tests are obviously better than mine. May I ask when can we expect gcc-4.5.0 going stable? Because I want the pending perl-5.10.1-4 update which changes cc from gcc to gcc-4 and fixes some more minor stuff to be done with the new gcc-4.5.x. But if it's more than one week I'll revert to the old compiler. 2010/8/16 Yaakov (Cygwin/X): Dave, Several notes about gcc-4.5.0: 1) I'm using a new FIONREAD patch for Classpath which solves several issues. Matching patch for gcc-4.5 attached. 2) fix-libtool-scripts-for-latest-gcc-runtimes.sh doesn't actually do anything; 's|echo sed|sed|g' fixes that. 3) libgnat import libs are missing: $ gnatmake hello.adb -bargs -shared gcc -c hello.adb gnatbind -shared -x hello.ali gnatlink hello.ali -shared-libgcc /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686-pc-cygwin/bin/ld: cannot find -lgnat-4.5 collect2: ld returned 1 exit status gnatlink: error when calling /usr/bin/gcc.exe gnatmake: *** link failed. Looking at gcc/ada/gcc-interface/Makefile.in, it looks like there is supposed to be a adalib/libgnat-4.5.dll.a symlink, but it's not quite right. Patch for 4.5.1 attached. 4) After creating said symlink, the resulting binary outputs Hello, world! but does not exit, and requires kill -f to terminate. The same code linked statically (IOW w/o -bargs -shared) runs and exits correctly. 5) Several -4-suffixed programs have no unversioned alternatives; this includes: aot-compile, gccbug, jcf-dump, rebuild-gcj-db. (Of course, if we drop gcc3, or at least its alternatives, then gcc4 can be unversioned, making this point moot.) 6) Are the gcj tools working? If not, perhaps they should just be dropped until they get figured out. An alternative would be for me to ITP my Classpath-based stack. 7) jni.h and jni_md.h should probably be shipped with gcc4-java instead of gcc4-core. 8) It would be helpful if gcc4-core would provide a libffi.pc pkg-config file, since for us this is *the* libffi. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: Emacs and DBUS
On 8/25/2010 10:02 AM, Ken Brown wrote: On 8/24/2010 11:28 PM, Michael Albinus wrote: Ken Brown writes: After installing that library, Emacs did start. How ever, it blocks when loading dbus.el. Don't you normally have to start a D-BUS session before loading dbus.el? Maybe one of the Cygwin people who uses D-BUS can tell us how to do that. I've started the session bus via dbus-launch in advance, of course. I have no idea, how to start the system bus in cygwin, 'though. Run /usr/bin/messagebus-config and follow the instructions for installing messagebus as a service. You will need to be logged in as a user with administrator privileges for this. Emacs' D-Bus code shall be resistent in case of absence of a bus, but who knows ... how could I debug it via gdb? The executable /usr/bin/emacs-nox.exe is stripped; that's why you couldn't debug it. Here's a link to the unstripped version, with debug symbols: http://www.math.cornell.edu/~kbrown/emacs-nox.exe.bz2 Hi Michael, The blocking you observed when dbus.el is loaded doesn't occur with a build from the Emacs trunk (r101187). But I don't know how to test the dbus functionality after loading dbus.el. If we find it works there, maybe the problem is just a matter of backporting some patch to Emacs 23.2. Can you tell me how to test dbus in emacs? Or do you want me to send you the executable and let you test it? Ken -- 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: Emacs and DBUS
On 8/25/2010 10:37 AM, Ken Brown wrote: On 8/25/2010 10:02 AM, Ken Brown wrote: On 8/24/2010 11:28 PM, Michael Albinus wrote: Ken Brown writes: After installing that library, Emacs did start. How ever, it blocks when loading dbus.el. Don't you normally have to start a D-BUS session before loading dbus.el? Maybe one of the Cygwin people who uses D-BUS can tell us how to do that. I've started the session bus via dbus-launch in advance, of course. I have no idea, how to start the system bus in cygwin, 'though. Run /usr/bin/messagebus-config and follow the instructions for installing messagebus as a service. You will need to be logged in as a user with administrator privileges for this. Emacs' D-Bus code shall be resistent in case of absence of a bus, but who knows ... how could I debug it via gdb? The executable /usr/bin/emacs-nox.exe is stripped; that's why you couldn't debug it. Here's a link to the unstripped version, with debug symbols: http://www.math.cornell.edu/~kbrown/emacs-nox.exe.bz2 Hi Michael, The blocking you observed when dbus.el is loaded doesn't occur with a build from the Emacs trunk (r101187). Correction: It occurs if and only if the system messagebus service is running. Ken -- 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: Build S-Lang Fail
On 8/25/2010 8:58 AM, Csaba Raduly wrote: On Sun, Aug 22, 2010 at 8:15 PM, Steven Woody wrote: $ ldd /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe ntdll.dll = /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c92) kernel32.dll = /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80) cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0x67f0) cygwin1.dll = /usr/bin/cygwin1.dll (0x6100) ADVAPI32.DLL = /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77da) RPCRT4.dll = /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e5) Secur32.dll = /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fc) cyggmp-3.dll = /usr/bin/cyggmp-3.dll (0x63f4) cygmpfr-1.dll = /usr/bin/cygmpfr-1.dll (0x6cd8) You could either run ldd on the DLLs (cyggcc_s-1.dll, cyggmp-3.dll and cygmpfr-1.dll) or use depends.exe (http://www.dependencywalker.com/) to try to identify the missing DLL. 'cygcheck' is also an option as well. -- 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
associating device names with cygdrive directories
What is the best way to find or predict the association of a given /dev/sd? with the corresponding /cygdrive/?. Is there a good way to verify the assignment before writing to the device with dd? -- 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: associating device names with cygdrive directories
On 8/25/2010 2:49 PM, Charles D. Russell wrote: What is the best way to find or predict the association of a given /dev/sd? with the corresponding /cygdrive/?. Is there a good way to verify the assignment before writing to the device with dd? I think this link should help a little: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices The POSIX device names are generated from the Windows information/layout of these devices. So your best bet is to look to Windows to get the device number - drive letter association and then fill in the rest from there. There is no one-stop shopping utility that I know of that will do all that for you. -- 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
Re: associating device names with cygdrive directories
On 8/25/2010 2:49 PM, Charles D. Russell wrote: What is the best way to find or predict the association of a given /dev/sd? with the corresponding /cygdrive/?. Is there a good way to verify the assignment before writing to the device with dd? I think this link should help a little: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices The POSIX device names are generated from the Windows information/layout of these devices. So your best bet is to look to Windows to get the device number - drive letter association and then fill in the rest from there. I had read that reference, but don't see how it helps to find whether a given USB storage device is sda, sdb, or whatever. I found that a flash drive was /dev/sdc by unplugging all other USB devices and trial-and-error with dd if=/dev/sdc |od|less, but there must be a better way. I want to use multiple USB devices at the same time, and they don't all have stuff on them that I can recognize in binary. On Linux, the mount command reveals the association between filesystem names and /dev/ names, but Cygwin mount doesn't tell. The cited reference mentions NT internal device names, but I don't know what those are or how to find them. Is there some connection with the device numbers revealed by the Control Panel under Windows Computer Management/Storage/Disk Management? -- 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: associating device names with cygdrive directories
On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote: On Linux, the mount command reveals the association between filesystem names and /dev/ names, but Cygwin mount doesn't tell. Sorry that's not how the mount command works on Linux. It's not always easy to tell the device associated on linux either. Sometimes you need to look at dmesg output. Unfortunately cygwin has nothing similar. 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: associating device names with cygdrive directories
On 8/25/2010 3:03 PM, Christopher Faylor wrote: On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote: On Linux, the mount command reveals the association between filesystem names and /dev/ names, but Cygwin mount doesn't tell. Sorry that's not how the mount command works on Linux. It's not always easy to tell the device associated on linux either. Sometimes you need to look at dmesg output. Unfortunately cygwin has nothing similar. The wodim command from the cdrtools package includes logic (-scanbus option) which is able to identify SCSI devices under Cygwin. It doesn't map them to the /dev namespace, but it shows that something like you need may be possible. Wodim is also able to take a drive letter and directly use that when writing an ISO file to the drive. Maybe you could start there and craft a tool to do what you need. -Jeremy -- 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: associating device names with cygdrive directories
On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote:
On Linux, the mount command reveals the association between filesystem
names and /dev/ names, but Cygwin mount doesn't tell.
Is this what you want? (The multiple spaces are really tabs.)
$ for F in /dev/s* ; do echo $F$(cygpath -w $F) ; done
/dev/scd0 \\.\D:
/dev/scd1 \Device\CdRom1
/dev/scd2 \Device\CdRom2
/dev/sda\\.\PhysicalDrive0
/dev/sda1 \\.\Volume{39f65722-0106-11df-b1c0-806d6172696f}
/dev/sda2 \Device\Harddisk0\Partition2
/dev/sdb\Device\Harddisk1\Partition0
/dev/sdb1 \Device\Harddisk1\Partition1
/dev/sdb2 \Device\Harddisk1\Partition2
/dev/sdc\Device\Harddisk2\Partition0
/dev/sdc1 \Device\Harddisk2\Partition1
/dev/sdc2 \Device\Harddisk2\Partition2
/dev/shmC:\cygwin\dev\shm
/dev/sr0\\.\D:
/dev/sr1\Device\CdRom1
/dev/sr2\Device\CdRom2
/dev/st0\Device\Tape0
/dev/st1\Device\Tape1
/dev/st2\Device\Tape2
/dev/stderr \dev\tty
/dev/stdin \dev\tty
/dev/stdout /proc/2476/fd/pipe:[504]
- Barry
Disclaimer: Statements made herein are not made on behalf of NIAID.
--
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: associating device names with cygdrive directories
On 8/25/2010 4:11 PM, Jeremy Bopp wrote: On 8/25/2010 3:03 PM, Christopher Faylor wrote: On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote: On Linux, the mount command reveals the association between filesystem names and /dev/ names, but Cygwin mount doesn't tell. Sorry that's not how the mount command works on Linux. It's not always easy to tell the device associated on linux either. Sometimes you need to look at dmesg output. Unfortunately cygwin has nothing similar. The wodim command from the cdrtools package includes logic (-scanbus option) which is able to identify SCSI devices under Cygwin. It doesn't map them to the /dev namespace, but it shows that something like you need may be possible. Wodim is also able to take a drive letter and directly use that when writing an ISO file to the drive. Maybe you could start there and craft a tool to do what you need. That might be the easiest way to creating a tool, since you'd have existing logic to leverage. But to answer your original question, you can certainly use the information from Disk Management to figure out the mapping. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/devices.cc?rev=1.31content-type=text/x-cvsweb-markupcvsroot=src should help in that regard. But essentially, Disk 0 = /dev/sda, etc. -- 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
Re: associating device names with cygdrive directories
Maybe it won't always work, but with debian mount I get the following line of output, which tells me what I want to know (and more): /dev/sda1 on /live/image type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) I infer from the replies that in Cygwin there is no easier way to find my way around in /dev than the way I was doing it, though I realize strings is a better choice than od. With dd if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard drive. -- 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: associating device names with cygdrive directories
On 8/25/2010 3:32 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote: On Linux, the mount command reveals the association between filesystem names and /dev/ names, but Cygwin mount doesn't tell. Is this what you want? (The multiple spaces are really tabs.) $ for F in /dev/s* ; do echo $F$(cygpath -w $F) ; done /dev/scd0 \\.\D: /dev/scd1 \Device\CdRom1 /dev/scd2 \Device\CdRom2 snip That's a pretty clever solution. Too bad there is no way to use cygpath to go the other direction. Ideally, we could do something like: $ cygpath -t device D: /dev/scd0 Of course it's hard to justify adding such functionality without a good use case. -Jeremy -- 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: associating device names with cygdrive directories
On 8/25/2010 3:42 PM, Charles D. Russell wrote: Maybe it won't always work, but with debian mount I get the following line of output, which tells me what I want to know (and more): /dev/sda1 on /live/image type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) I infer from the replies that in Cygwin there is no easier way to find my way around in /dev than the way I was doing it, though I realize strings is a better choice than od. With dd if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard drive. How would you handle the case where you have more than a single mount which looks like that? e.g.) /dev/sda1 on /live/image1 type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) /dev/sdb1 on /live/image2 type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) I think part of what Chris is saying is that you typically don't know for sure how Linux will associate a particular hardware device with a particular node in the device filesystem. Looking at the mount table is only useful in extremely limited circumstances, such as when you only have a single device that always mounts to a well-known mount point. Since Windows handles the automounting for Cygwin, you have to depend on Windows to always assign the same drive letter to the device, thus creating your well-known mount point (/cygdrive/d, for example). However, I don't believe there is any way to force that under Windows, so if some other device loads first and takes the drive letter you usually get, your second device will automatically get a different drive letter. This is outside of Cygwin's control in any case. If you want to avoid the hacks you describe above, you'll need to talk to Windows in order to locate some sort of unique identifier for your device and use that to ultimately identify the POSIX device path, perhaps via the drive letter and Barry's trick. Under Linux you would essentially use sysfs to do a similar task. Anything less, especially since you're talking about using dd to write to the device, will likely lead to unhappiness. -Jeremy -- 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: associating device names with cygdrive directories
Greetings, Charles D. Russell! Maybe it won't always work, but with debian mount I get the following line of output, which tells me what I want to know (and more): /dev/sda1 on /live/image type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) I infer from the replies that in Cygwin there is no easier way to find my way around in /dev than the way I was doing it, though I realize strings is a better choice than od. With dd if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard drive. It's a very rough guess, and only work in limited amount of instances. You still have to check if the target device you got from mount table is actually a block device. And, please, use reply option when replying to list, instead of writing new message. -- WBR, Andrey Repin (anrdae...@freemail.ru) 26.08.2010, 6:31 Sorry for my terrible english... -- 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
linux-cygwin cross build environment
Last weekend I attempted to setup a linux-cygwin cross compiler (and
basic sysroot). However, it didn't work: while a simple C 'Hello World'
app could be compiled, copied over to a win32 system and executed, a C++
'Hello World' did not:
1) using the cygwin-provided cygstdc++-6.dll and cyggcc_s-1.dll, it
segfaulted.
2) copying over to the win32 system ALSO the cygstdc++-6.dll and
cyggcc_s-1.dll built as part of the cross toolchain, and running the C++
hello world app -- it didn't segfault. But it didn't print anything to
stdout (std::cout), either.
Now, I've build linux-hosted cross compilers before -- and I'm very
familiar with cygwin, too -- so I'm not exactly a novice here. But...I
wonder if I'm just doing something silly, and need another pair (or
hundred) of eyes to point out the obvious.
so, I've attached my build procedure (WARNING, for the archvies: the
compiler produced using this procedure is BROKEN. DO NOT USE).
I based my compiler on Dave's recent 4.5.0-1 release, and the current
cygwin binutils packages.
Anybody have a suggestion? What am I doing wrong?
--
Chuck
HOST_TRIPLE=i686-pc-linux-gnu
HOST_PREFIX=/opt/devel/cygwin
TARGET_TRIPLE=i686-pc-cygwin
TARGET_PREFIX=/usr
SYSROOT=${HOST_PREFIX}/${TARGET_TRIPLE}/sys-root
BUILDTOP=/mnt/junk
GCCVER=4.5.0
PKGREL=1
DOWNLOADS=/opt/devel/cygwin/src/downloads
MIRROR=http://mirrors.kernel.org/sourceware/cygwin/release
export PATH=${HOST_PREFIX}/bin:/opt/devel/cygwin/src/private/bin:${PATH}
do_get () {
pushd ${DOWNLOADS} /dev/null
wget ${MIRROR}/$1
popd /dev/null
}
mkdir -p ${DOWNLOADS}
do_get w32api/w32api-3.14-1.tar.bz2
do_get cygwin/cygwin-1.7.6-1.tar.bz2
do_get binutils/binutils-2.20.51-2-src.tar.bz2
do_get gcc4/gcc4-4.5.0-1-src.tar.bz2
mkdir -p ${SYSROOT}
(cd ${SYSROOT} tar xvjf ${DOWNLOADS)/w32api-3.14-1.tar.bz2)
(cd ${SYSROOT} tar xvjf ${DOWNLOADS}/cygwin-1.7.6-1.tar.bz2)
# not sure if sysroot support extends to the w32api stuff, so
# make sure the libs that appear in the specs file exist in the
# main lib dir, and not just in the w32api subdir. In any case,
# this is *absolutely* necessary during the build of the language
# runtime libraries...
(cd ${SYSROOT}${TARGET_PREFIX}/lib ln -fs w32api/libkernel.a .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib ln -fs w32api/libuser32.a .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib ln -fs w32api/libadvapi32.a .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib ln -fs w32api/libshell32.a .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib ln -fs w32api/libgdi32.a.)
(cd ${SYSROOT}${TARGET_PREFIX}/lib ln -fs w32api/libcomdlg32.a .)
# ensure linux package installed: libgmp-devel, libgmp10
# ensure linux package installed: mpfr-devel, libmpfr1
# ensure linux package installed: libmpc-devel, libmpc2
# ensure linux package installed: libcloog-devel, libcloog0
# ensure linux package installed: libppl-devel, libppl7
## binutils
cd $BUILDTOP
mkdir binutils
cd binutils
tar xvjf ${DOWNLOADS}/binutils-2.20.51-2-src.tar.bz2
mkdir _build
cd _build
${BUILDTOP}/binutils/binutils-2.20.51-2/configure \
--prefix=${HOST_PREFIX} \
--host=${HOST_TRIPLE} \
--build=${HOST_TRIPLE} \
--target=${TARGET_TRIPLE} \
--with-build-sysroot=${SYSROOT} \
--with-sysroot=${SYSROOT}
make
make install DESTDIR=${BUILDTOP}/binutils/_inst
cd ${BUILDTOP}/binutils/_inst
tar cvJf ../binutils-2.20.51-2-cygwin.tar.xz opt
cd /
tar xvJf ${BUILDTOP}/binutils/binutils-2.20.51-2-cygwin.tar.xz
## custom autoconf, automake
## gcc-4.5.0 requires ac-2.64, am-1.11.1
cd ${DOWNLOADS}
wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.64.tar.bz2
wget http://ftp.gnu.org/gnu/automake/automake-1.11.1.tar.bz2
cd ${BUILDTOP}
mkdir autoconf
cd autoconf
tar xvjf ${DOWNLOADS}/autoconf-2.64.tar.bz2
mkdir _build
cd _build
${BUILDTOP}/autoconf/autoconf-2.64/configure --prefix=${BUILDTOP}/private
make
make install
cd ${BUILDTOP}
mkdir automake
cd automake
tar xvjf ${DOWNLOADS}/automake-1.11.1.tar.bz2
mkdir _build
cd _build
${BUILDTOP}/automake/automake-1.11.1/configure --prefix=${BUILDTOP}/private
make
make install
mkdir -p ${BUILDTOP}/private/share/aclocal
echo '/usr/share/aclocal' ${BUILDTOP}/private/share/aclocal/dirlist
## gcc
cd $BUILDTOP
mkdir gcc45
cd gcc45
tar xvjf ${DOWNLOADS}/gcc4-4.5.0-1-src.tar.bz2
tar xvjf gcc-4.5.0.tar.bz2
cd gcc-4.5.0
patch -p2 ../classpath-0.98-FIONREAD.patch
patch -p2 ../classpath-0.98-build.patch
patch -p2 ../classpath-0.98-awt.patch
patch -p2 ../gcc45-ada.diff
patch -p0 ../gcc45-cygwin-lto.diff
patch -p2 ../gcc45-ehdebug.diff
patch -p2 ../gcc45-libffi.diff
patch -p2 ../gcc45-libstdc.diff
patch -p2 ../gcc45-misc-core.diff
patch -p2 ../gcc45-mnocygwin.diff
patch -p0 ../gcc45-sig-unwind.diff
patch -p2
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 8/21/2010 4:54 AM, Corinna Vinschen wrote: On Aug 20 21:07, Charles Wilson wrote: If you concur, I'll post a patch to that effect to cygwin-patches (we use our own header, not newlib's, for netinet/in.h). This is not the right solution. OK. First, we don't support _BSD_SOURCE and _GNU_SOURCE, yet, since, as you can see in the comment in /usr/include/features.h, the groundwork is entirely missing. The _POSIX_SOURCE is used in newlib in the first place and we can and do use it as well. _XOPEN_SOURCE is only barely available for a few months now, but it's not actually used anywhere. I see. On Linux, bindresvport and bindresvport6 are available by default, *unless* you define something like _POSIX_SOURCE. Right...as you pointed out below, you get the same warning on linux. Since newlib/Cygwin is missing the groundwork for a full-fledged features.h, your above suggestion would result in declaring bindresvport/bindresvport_sa *only if* the user explicitely defines _BSD_SOURCE or _GNU_SOURCE on the command line. That's not feasible. Yes, you are correct. :-( The question is, why does libtirpc declare the functions at all? Does it come with its own implementation? Yes, it does. And, that implementation is used by the upstream source for linux, in preference to the glibc-provided version. I followed that pattern in libtirpc, as well: the libtirpc version is used in preference to cygwin's. Not because I think there is a problem with cygwin's, but simply because I followed the linux pattern. Given that, I think something similar to the krb5 solution could be used here, as well. Unfortunately, the current cygtirpc-1.dll exports its version of bindresvport and bindresvport_sa. That is a *problem* because anything built against it will expect to use ITS version from now on. Unless I rebuild with renamed versions, and bump the API number. Or, don't bump the API number and break stuff. Since it is a new package, and so far only Erick's private libvirt seems to use it, I'm actually leaning that way. Eric, any thoughts? Whether or not, I think the problem are the libtirpc headers in the first place. OK. But note that this only occurs with -Wredundant-decls, which is not one of the default warnings. right, but this problem did lead to the discovery of a real issue in cygtirpc-1.dll... I wonder if there are more issues lurking here: The following are exported by both cygtirpc-1.dll and cygwin1.dll: bindresvport bindresvport_sa getpeereid (*) (*) implemented using error = getsockopt(s, SOL_SOCKET, SO_PEERCRED, uc, uclen); and then picking uc.uid and uc.gid (after error checking, etc). Note that there are a number of functions declared by cygwin's netdb.h header, but are provided by cygtirpc: voidendrpcent (void); struct rpcent *getrpcent (void); struct rpcent *getrpcbyname (const char *); struct rpcent *getrpcbynumber (int); voidsetrpcent (int); Interestingly, many of these apparently HAD been declared in tirpc/rpc/rpcent.h, but were commented out (using C++ comment markers, I might add). But, at least that means there is no conflict with these symbols. -- 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: Emacs and DBUS
Ken Brown kbr...@cornell.edu writes: Hi Michael, Hi Ken, The blocking you observed when dbus.el is loaded doesn't occur with a build from the Emacs trunk (r101187). But I don't know how to test the dbus functionality after loading dbus.el. There is a manual, open it with (info (dbus)) You could check your own D-Bus name: (dbus-get-unique-name :system) (dbus-get-unique-name :session) You could register for signals sent by the D-Bus: (defun my-dbus-signal-handler (rest args) (message Signal from bus %s received: %s (dbus-event-bus-name last-input-event) args)) (dbus-register-signal :system dbus-service-dbus dbus-path-dbus dbus-interface-dbus NameOwnerChanged 'my-dbus-signal-handler) (dbus-register-signal :session dbus-service-dbus dbus-path-dbus dbus-interface-dbus NameOwnerChanged 'my-dbus-signal-handler) Now you could open any other D-Bus application, and you shall be notified in Emacs. Let's use dbus-monitor, started in a shell: # dbus-monitor --session # dbus-monitor --system If we find it works there, maybe the problem is just a matter of backporting some patch to Emacs 23.2. In Emacs' trunk, there are changes how D-Bus buses are initialized for polling of pending messages. The intention was to access non-default buses as well, but it seems to help also for the system and session buses on cygwin. Backporting would include both dbusbind.c and dbus.el, because there are dependent changes. I havent't planned it yet for the Emacs 23 branch, but why not. Can you tell me how to test dbus in emacs? Or do you want me to send you the executable and let you test it? Unfortunately, the next 10 days or so I won't have access to a machine running Windows+Cygwin (I'll be on the road); accessing my email shall be possible. I'ld like to test it when I'm back. Thinking about, I prefer an unstripped version of emacs-x11 instead of emacs-nox for testing. Ken Best regards, Michael. -- 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: Emacs and DBUS
Ken Brown kbr...@cornell.edu writes: The blocking you observed when dbus.el is loaded doesn't occur with a build from the Emacs trunk (r101187). Correction: It occurs if and only if the system messagebus service is running. I'm confused: do you mean, the problem is happening when the system bus is running, or when it is *not* running? I suspect the latter case. Ken Best regards, Michael. -- 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
Possible tar version 1.23-1 --remove-files bug.
I have duplicated the following behavior on 2 different machines CYGWIN_NT-5.2 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 (Windows 2003 R2 Server) CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 (Windows XP Desktop) Both are running tar version 1.23-1 and the problem is 100% reproducible in my environment. *Some editing has been made to the output to protect the innocent. Any discrepancies in the output are unlikely related to the problem itself and more likely caused by my sausage shaped fingers. Scenario: Given a directory with sample contents: $ ls file1.asc file2.asc file3.asc file4.asc the following command: $ tar --remove-files -cvf test.tar *.asc file1.asc file2.asc file3.asc file4.asc Produces the expected result of a single test.tar, with the 4 asc files removed. $ ls test.tar And the tarball correctly contains all 4 files. $ tar -tvf test.tar -rw-r--r-- XX/None 22 2010-08-26 00:07 file1.asc -rw-r--r-- XX/None 22 2010-08-26 00:07 file2.asc -rw-r--r-- XX/None 22 2010-08-26 00:07 file3.asc -rw-r--r-- XX/None 22 2010-08-26 00:07 file4.asc *** PROBLEM STARTS HERE *** The following command, using the -r (append -vs- create) switch, correctly produces a test.tar file with all 4 files but fails to delete the files. $ tar --remove-files -rvf test.tar *.asc file1.asc file2.asc file3.asc file4.asc $ ls file1.asc file2.asc file3.asc file4.asc test.tar $ tar -tvf test.tar -rw-r--r-- XX/None 22 2010-08-26 00:11 file1.asc -rw-r--r-- XX/None 22 2010-08-26 00:11 file2.asc -rw-r--r-- XX/None 22 2010-08-26 00:11 file3.asc -rw-r--r-- XX/None 22 2010-08-26 00:11 file4.asc A return code of zero is produced in either instance, and the tarballs created are both fully usable. There is a second scenario where all asc files are deleted except the last one (so test.tar and file4 would be left in the directory at completion) but as of yet I cannot reproduce that scenario at will, so I'm uncertain as to the exact startup conditions that cause it. In my situation using -c is not a solution since this command is embedded within a large loop. Each file is being processed and appended to the archive one at a time. The processing script worked without issue prior to upgrading to the 1.23-1 version tar within the last week or so. *** Other possibly relevant pieces of information: *** I verified using a Linux box (2.6.18-164.9.1.el5.centos.plus) running tar (GNU tar) 1.15.1 to verify that my expectations of the command were correct. $ ls file1.asc file2.asc file3.asc file4.asc $ tar --remove-files -rvf test.tar *.asc file1.asc file2.asc file3.asc file4.asc $ ls test.tar $ tar -tvf test.tar -rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file1.asc -rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file2.asc -rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file3.asc -rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file4.asc Cygwin was installed from different mirrors at different times on each machine. It appears from the release notes that some changes were made in 1.23-1 related to the --remove-files argument ** The --remove-files option removes files only if they were succesfully stored in the archive. I was unable to find any related issues in the archive but was having trouble making the archive search match the '--remove-files' switch in the query. Apologies in advance if I duped. Thanks, Jeremy -- 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: associating device names with cygdrive directories
On Wed, Aug 25, 2010 at 04:32:49PM -0500, Jeremy Bopp wrote: On 8/25/2010 3:42 PM, Charles D. Russell wrote: Maybe it won't always work, but with debian mount I get the following line of output, which tells me what I want to know (and more): /dev/sda1 on /live/image type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) I infer from the replies that in Cygwin there is no easier way to find my way around in /dev than the way I was doing it, though I realize strings is a better choice than od. With dd if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard drive. How would you handle the case where you have more than a single mount which looks like that? e.g.) /dev/sda1 on /live/image1 type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) /dev/sdb1 on /live/image2 type vfat (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8) I think part of what Chris is saying is that you typically don't know for sure how Linux will associate a particular hardware device with a particular node in the device filesystem. No, actually what I was saying is that the mount command doesn't know which device is associated with a CD or disk. Something had to *generate* a command like: mount -t vfat /dev/sda1 /live/image That information usually comes from /etc/fstab and /etc/fstab would probably be generated by something which scanned the available devices to produce the file. Sure, when you type mount you will see mounted directories but cygdrive directories aren't really mounted in the strictest sense. The mount table is one place where Cygwin and Linux are quite different. 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
Updated: SuiteSparse-3.5.0-1
New versions of SuiteSparse / libSuiteSparse-devel 3.5.0-1 for cygwin are available in the Cygwin distribution: CHANGES These are new upstream versions, mainly bugfix DESCRIPTION SuiteSparse is library for sparse matrix. It is used to compile Octave HOMEPAGE http://www.cise.ufl.edu/research/sparse/SuiteSparse/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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.
Updated: lapack 3.2.2-1
New versions 3.2.2-1 of lapack (source) liblapack0 liblapack-devel for cygwin are available in the Cygwin distribution: CHANGES These are new bugfix upstream versions Full list of changes at: http://www.netlib.org/lapack/lapack-3.2.html http://www.netlib.org/lapack/lapack-3.2.1.html http://www.netlib.org/lapack/lapack-3.2.2.html xblas is NOT yet implemented for cygwin. DESCRIPTION Comprehensive FORTRAN library for linear algebra operations. Includes matrix inversions, least squared solutions to sets of equations, eigenvector analysis, singular value decomposition, etc. HOMEPAGE http://www.netlib.org/lapack/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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.
New package: ngspice-21-1
Hi, NGSPICE is now available for cygwin. The version ngspice-21-1 has been uploaded. DESCRIPTION Ngspice is a mixed-level/mixed-signal circuit simulator. Its code is based on Spice3f5. Ngspice is part of gEDA project, a full GPL'd suite of Electronic Design Automation tools. HOMEPAGE http://ngspice.sourceforge.net Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** 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.
