Re: [ITP] astrometry.net-0.38-1
On 10/7/2011 12:18 PM, Jussi Kantola wrote: However I had to modify backend-main.c so that the config file (which defines the location of index files) could be read from cygwin's preferred location, /usr/share/astrometry/etc/backend.cfg. That's a little odd, and I don't think that's exactly what was meant by the documentation http://cygwin.com/setup.html#package_contents. I don't think this is a showstopper for this release, but ordinarily configuration files belong in the top-level /etc directory. However, once installed there, a name like backend.cfg is poorly chosen, since it doesn't really indicate what package it belongs to, and thus might conflict with some other package. /usr/share/pkg/ is usually used for other, more extensive data files and support -- e.g. that's probably where your star catalog files (indexes?) ought to go. Furthermore, if backend.cfg is user-editable, then you would probably want to install it into /etc/defaults/etc/backend.cfg and include a postinstall/preremove scripts here: (a) /etc/postinstall/astrometry.net.sh (b) /etc/preremove/astrometry.net.sh whose job is to (a) copy the default version into /etc on install, IF no such file already exists, and (b) remove the /etc/backend.cfg file on uninstall, if and only if it is identical to the /etc/defaults/ one. See /etc/postinstall/tcp_wrappers.sh [or .done] /etc/preremove/tcp_wrappers.sh for and example. FYI, cygport will handle creating these scripts for you (almost) automatically, via a single command: make_etc_defaults /etc/backend.cfg All this complexity is so that user-modified configuration settings don't get clobbered by package updates, but non-modified files will get updated. However, what is probably a showstopper are various lines like this in the build: # Try building and installing python spherematch module make install-spherematch make[2]: Entering directory `/usr/src/packages/tmp/astrometry.net-0.38-1/libkd' python setup.py build --force --build-base build --build-platlib build/lib running build running build_py creating build creating build/lib copying spherematch.py - build/lib running build_ext building 'spherematch_c' extension creating build/temp.cygwin-1.7.9-i686-2.6 gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/lib/python2.6/site-packages/numpy/core/include/numpy -I../qfits-an/include -I../util -I. -I/usr/include/python2.6 -c pyspherematch.c -o build/temp.cygwin-1.7.9-i686-2.6/pyspherematch.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.9-i686-2.6/pyspherematch.o libkd.a ../util/libanfiles.a ../util/libanutils.a ../qfits-an/lib/libqfits.a -L/usr/lib/python2.6/config -lpython2.6 -o build/lib/spherematch_c.dll cp build/lib/spherematch_c.so spherematch_c.so cp: cannot stat `build/lib/spherematch_c.so': No such file or directory make[2]: *** [spherematch_c.so] Error 1 IOW, cygwin python's distutils is _doing the right thing_ -- creating the plugin with the name spherematch_c.dll -- but the Makefile in astrometry.net thinks the plugin will always be named spherematch_c.so and reports an error when it tries to install the latter file. Also, when I did 'make install ...' my lib/astrometry/bin directory was empty. I can't help but think this will cause problems for your users... Now, this bit is interesting: - mkdir -p $(INSTALL_DIR)/python/astrometry/libkd + mkdir -p $(INSTALL_DIR)/share/astrometry/python/astrometry/libkd Normally, python extensions go under the real python dir: /usr/lib/python2.6/site-packages/pkgname/... But...this whole build system doesn't really support that; it hardcodes the destination path and then adds that path to sys.path via the application .py files; when it really should use some mechanism to find the entry in $python's sys.path list which contains site-packages. So...accepting that, the python stuff should ALSO go under /lib rather than /share, because (a) the .pyc files are platform specific, and (b) the .dll's which ought to go there are also platform specific. so, not GTG. Also, you missed Corinna's statement: If the binaries are using it (the libbackend library), they should also be linked against [the DLL], rather than being linked statically. Your build still links against libbackend.a, rather than cygbackend.dll. I'm trying to massage your -src package to DTRT. Stay tuned. -- Chuck
Re: [ITP] win-ssh-agent 1.07
2011/11/4 Christopher Faylor On Thu, Nov 03, 2011 at 09:52:20AM -0400, Andrew Schulman wrote: I'd like to package and maintain win-ssh-agent for Cygwin. With the win-ssh-agent, we can use the ssh-agent (available inthe cygwin openssh) in the more smart way. Normally, we need to start all relevant programs, which mightneed to use the ssh, as child processes of the shell(e.g. bash) in which you eval'ed the ssh-agent. ?Because, theprograms must be able to refer to environment variables thatset by the ssh-agent. The win-ssh-agent enables all programs to refer to theenvironment variables of the ssh-agent, i.e. theSSH_AUTH_SOCK. ?Now, we no longer need to start programs aschild processes of the shell. +1 Sounds useful. I don't agree. ?I don't see why this couldn't be accomplished using standard UNIX tools The win-ssh-agent is for applications that uses the cygwin openssh internally and are executed from the Explorer (i.e. via the ShellExecute() API). The keychain in the distribution cannot propagate SSH_AUTH_SOCK to them. Example: Consider the ntemacs ( http://ftp.gnu.org/pub/gnu/emacs/windows/ ) . (1) I want to use it because the cygwin emacs does not have its own windows. The cygwin emacs works only in the terminal. (2) I want to run it from the start menu or the Windows 7's task bar (not from the cygwin bash shell). It is the window's style to run applications. (3) I want to use the tramp ( http://www.gnu.org/s/tramp/ ) in the ntemacs. With it, I can treat documents on the remote machine as if they are on the local machine by: C-x C-f /sshx:usernameathostname:~/remote-file But with the keychain, the ntemacs becomes silent because the ssh (executed by the tramp) cannot know the SSH_AUTH_SOCK and it asks me about the passphrase in the hidden console. With the win-ssh-agent, the ntemacs knows the SSH_AUTH_SOCK, so the tramp works as expected. and it seems like it might even be a potential security hole. ?I don't see the need to have this package in the distribution. cgf The win-ssh-agent set the SSH_AUTH_SOCK and some enviroments to the user's registory (HKEY_CURRENT_USER\Environment\*), not to the system registory. -- Nayuta Taga
Re: [ITP] astrometry.net-0.38-1
On Fri, Nov 4, 2011 at 8:29 AM, Charles Wilson wrote: I don't think this is a showstopper for this release, but ordinarily configuration files belong in the top-level /etc directory. However, once installed there, a name like backend.cfg is poorly chosen, since it doesn't really indicate what package it belongs to, and thus might conflict with some other package. Which is precisely the reason I've tried to keep everything under paths that have astrometry in them; as has already been pointed out (and as you point out below), a.n isn't really (at this point) designed for portability and/or 3rd party vendor distribution. I actually shuddered when I realized there would be a cygbackend.dll, as it sounds ALL wrong :-) /usr/share/pkg/ is usually used for other, more extensive data files and support -- e.g. that's probably where your star catalog files (indexes?) ought to go. Yes; indexes = star catalogs. Also, when I did 'make install ...' my lib/astrometry/bin directory was empty. That's odd, I was building and installing it all night last night and the folder was being updated duly. Looking at the source package, the Makefile seems fine (at least on that regard). so, not GTG. Also, you missed Corinna's statement: If the binaries are using it (the libbackend library), they should also be linked against [the DLL], rather than being linked statically. Oops, and roger. I'm trying to massage your -src package to DTRT. Stay tuned. Thank you very much and sorry for the trouble I'm causing! I'll have another session with the package myself, paying attention to what you've said. Also, I guess it's about time I get in contact with an active a.n developer to get clarification on some suspicions I've had ... but thanks again! -- jussi
Re: [ITP] win-ssh-agent 1.07
On Nov 4 15:37, Nayuta Taga wrote: 2011/11/4 Christopher Faylor On Thu, Nov 03, 2011 at 09:52:20AM -0400, Andrew Schulman wrote: I'd like to package and maintain win-ssh-agent for Cygwin. With the win-ssh-agent, we can use the ssh-agent (available inthe cygwin openssh) in the more smart way. Normally, we need to start all relevant programs, which mightneed to use the ssh, as child processes of the shell(e.g. bash) in which you eval'ed the ssh-agent. ?Because, theprograms must be able to refer to environment variables thatset by the ssh-agent. The win-ssh-agent enables all programs to refer to theenvironment variables of the ssh-agent, i.e. theSSH_AUTH_SOCK. ?Now, we no longer need to start programs aschild processes of the shell. +1 Sounds useful. I don't agree. ?I don't see why this couldn't be accomplished using standard UNIX tools The win-ssh-agent is for applications that uses the cygwin openssh internally and are executed from the Explorer (i.e. via the ShellExecute() API). The keychain in the distribution cannot propagate SSH_AUTH_SOCK to them. You can eaily propagate the SSH_* environment variables to other sessions via scripting, if you store the variables in a known path. You don't have to change the registry for that to work. Example: Consider the ntemacs ( http://ftp.gnu.org/pub/gnu/emacs/windows/ ) . (1) I want to use it because the cygwin emacs does not have its own windows. The cygwin emacs works only in the terminal. Try xemacs. It has a Windows GUI fallback mode if there's no X display. (2) I want to run it from the start menu or the Windows 7's task bar (not from the cygwin bash shell). It is the window's style to run applications. You can start it from the start menu via a bash script which pulls in the SSH_* environment before starting emacs. Don't get me wrong, I'm not opposed to include win-ssh-agent into the distro if it gets enough votes, but there are simple ways to solve this problem without a Windows GUI application. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
RE: [ITP] win-ssh-agent 1.07
Corinna Vinschen wrote on 2011-11-04:
On Nov 4 15:37, Nayuta Taga wrote:
2011/11/4 Christopher Faylor
On Thu, Nov 03, 2011 at 09:52:20AM -0400, Andrew Schulman wrote:
I'd like to package and maintain win-ssh-agent for Cygwin. With the
win-ssh-agent, we can use the ssh-agent (available inthe cygwin
openssh) in the more smart way. Normally, we need to start all
relevant programs, which mightneed to use the ssh, as child
processes of the shell(e.g. bash) in which you eval'ed the
ssh-agent. ?Because, theprograms must be able to refer to
environment variables thatset by the ssh-agent. The win-ssh-agent
enables all programs to refer to theenvironment variables of the
ssh-agent, i.e. theSSH_AUTH_SOCK. ?Now, we no longer need to start
programs aschild processes of the shell.
+1 Sounds useful.
I don't agree. ?I don't see why this couldn't be accomplished using
standard UNIX tools
The win-ssh-agent is for applications that uses the cygwin openssh
internally and are executed from the Explorer (i.e. via the
ShellExecute() API).
The keychain in the distribution cannot propagate SSH_AUTH_SOCK to
them.
You can eaily propagate the SSH_* environment variables to other
sessions via scripting, if you store the variables in a known path.
You don't have to change the registry for that to work.
keychain stores the ssh-agent environment variables in
$HOME/.keychain/${HOSTNAME}-sh by default. I start keychain from my
.bash_profile and then source $HOME/.keychain/${HOSTNAME}-sh in my .bashrc so
all my shells get the right values even if they aren't spawned from the shell
that started keychain.
Hope this helps.
--
Bryan Thrall
Principal Software Engineer
FlightSafety International
bryan.thr...@flightsafety.com
ssh through Cisco VPN problem
Does anyone have any idea why the openssh in cygwin (latest) would not connect through a Cisco vpn, but putty and virtualboxed Fedora's ssh would have no problem? Cygwin's ssh works fine at work, not using the vpn. I'll include -vvv's if no one knows right off the bat.
Re: [ITP] win-ssh-agent 1.07
On 11/04/2011 12:37 AM, Nayuta Taga wrote:
2011/11/4 Christopher Faylor
On Thu, Nov 03, 2011 at 09:52:20AM -0400, Andrew Schulman wrote:
I'd like to package and maintain win-ssh-agent for Cygwin.
-1, for reasons below...
With the win-ssh-agent, we can use the ssh-agent (available inthe
cygwin openssh) in the more smart way.
Normally, we need to start all relevant programs, which mightneed to
I'm not sure why your mail came through so garbled, but the large number
of missing spaces in your message distracts from your attempt to appear
professional in offering a package.
use the ssh, as child processes of the shell(e.g. bash) in which you
eval'ed the ssh-agent. ?Because, theprograms must be able to refer to
environment variables thatset by the ssh-agent.
The win-ssh-agent enables all programs to refer to theenvironment
variables of the ssh-agent, i.e. theSSH_AUTH_SOCK. ?Now, we no longer
need to start programs aschild processes of the shell.
Example:
Consider the ntemacs ( http://ftp.gnu.org/pub/gnu/emacs/windows/ ) .
Non-cygwin program. If someone is willing to download a non-cygwin
ntemacs, then they can also download a non-cygwin win-ssh-agent.
(3) I want to use the tramp ( http://www.gnu.org/s/tramp/ ) in the
ntemacs. With it, I can treat documents on the remote machine
as if they are on the local machine by:
C-x C-f /sshx:usernameathostname:~/remote-file
Have you tried using the emacs that ships with cygwin? It includes
tramp.elc already built in, without needing a separate download. But if
you are using the distro emacs, it seems like you are already okay using
the distro for firing up that emacs instance, at which point I don't see
a need for a gui frontend.
Unless you can give an example where an app in the cygwin distro would
be benefitted by adding a gui front-end to setting up the ssh-agent, and
why existing mechanisms of starting any cygwin app via a simple shell
script wrapper that attaches to $HOME/.keychain/${HOSTNAME}-sh if
already present, then I don't see why the cygwin distro needs
win-ssh-agent. I'm not saying that win-ssh-agent is bad (on the
contrary, it does seem to help your use case of ntemacs), just that
since your primary use case demonstration was as a stand-alone app for
helping other non-cygwin apps, and not something that fills a void for
interaction with existing cygwin apps.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
RE: ssh through Cisco VPN problem
Charles Stepp sent the following at Friday, November 04, 2011 10:15 AM Does anyone have any idea why the openssh in cygwin (latest) would not connect through a Cisco vpn, but putty and virtualboxed Fedora's ssh would have no problem? Cygwin's ssh works fine at work, not using the vpn. I'll include -vvv's if no one knows right off the bat. Wrong list. s/-apps// - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: [ITP] astrometry.net-0.38-1
On Fri, 2011-11-04 at 02:29 -0400, Charles Wilson wrote: On 10/7/2011 12:18 PM, Jussi Kantola wrote: However I had to modify backend-main.c so that the config file (which defines the location of index files) could be read from cygwin's preferred location, /usr/share/astrometry/etc/backend.cfg. That's a little odd, and I don't think that's exactly what was meant by the documentation http://cygwin.com/setup.html#package_contents. I don't think this is a showstopper for this release, but ordinarily configuration files belong in the top-level /etc directory. However, once installed there, a name like backend.cfg is poorly chosen, since it doesn't really indicate what package it belongs to, and thus might conflict with some other package. Then this should be /etc/astrometry/backend.cfg instead. IOW, cygwin python's distutils is _doing the right thing_ -- creating the plugin with the name spherematch_c.dll -- but the Makefile in astrometry.net thinks the plugin will always be named spherematch_c.so and reports an error when it tries to install the latter file. So patch the Makefile.in. Now, this bit is interesting: - mkdir -p $(INSTALL_DIR)/python/astrometry/libkd + mkdir -p $(INSTALL_DIR)/share/astrometry/python/astrometry/libkd Normally, python extensions go under the real python dir: /usr/lib/python2.6/site-packages/pkgname/... But...this whole build system doesn't really support that; it hardcodes the destination path and then adds that path to sys.path via the application .py files; when it really should use some mechanism to find the entry in $python's sys.path list which contains site-packages. So...accepting that, the python stuff should ALSO go under /lib rather than /share, because (a) the .pyc files are platform specific, and (b) the .dll's which ought to go there are also platform specific. I'm not so sure about (a), but my Linux VMs already use Python 2.7 so I couldn't check. That aside, I have no problem with application-specific pure-Python code in /usr/share/$PN, as they serve no purpose outside the given application, and many packages do this, in fact. Obviously DLL extensions can't go there though. so, not GTG. Also, you missed Corinna's statement: If the binaries are using it (the libbackend library), they should also be linked against [the DLL], rather than being linked statically. Your build still links against libbackend.a, rather than cygbackend.dll. I'm trying to massage your -src package to DTRT. Stay tuned. Good luck, it sounds like this software is quite unpolished. No wonder it's not in the distros yet. Yaakov
Re: [ITP] astrometry.net-0.38-1
On 11/4/2011 11:11 AM, Yaakov (Cygwin/X) wrote: software is quite unpolished. From reading the web page, it appears to be a research project by a couple of grad students -- with goals of supporting amateur and even professional astronomers by automating what is currently a labor-intensive task. So...like all research projects, it appears to suffer from get-it-done-itis focused on Linux and/or BSD, with little attention paid to portability. That's...problematic when going to any flavor of win32, including cygwin. I mean really: hand-editing makefiles? no configure scripts (some subdirs have them, but they are invoked as part of the top-level make, which doesn't). IMO the whole thing needs to be autotoolized, but I'm not going there. OTOH, I just spent a couple hours adding $(EXE) to about a thousand makefile rules, only to watch it blow up because of some built-in rule I can't turn off (where is it COMING from!!!??) that adds foo.exe.o to the dependencies and then looks for foo.exe.c to build it...Aaarrrggh -- Chuck
Re: [ITP] imlib2
On Nov 3 16:49, Yaakov (Cygwin/X) wrote: imlib2 is an image loading library from the Enlightenment project. ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Enlightenment/imlib2/ imlib2 is already in the major distros, and is required for an upcoming update to openbox. So no question that we need it. Yaakov, if you have to pull in packages because they are a requirement for newer versions of packages already in the distro, you really don't need to ITP them. Give us a quick note on this list and then just go auto-ahead. Don't wait for us slackers to cope with it. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] win-ssh-agent 1.07
2011/11/4 Corinna Vinschen: On Nov 4 15:37, Nayuta Taga wrote: (1)
I want to use it because the cygwin emacs does not have its own
windows. The cygwin emacs works only in the terminal. Try xemacs.
It has a Windows GUI fallback mode if there's no X display.
It's nice! I'll try it.
(2) I want to run it from the start menu or the Windows 7's task bar
(not from the cygwin bash shell). It is the window's style to run
applications. You can start it from the start menu via a bash script which
pulls in the SSH_* environment before starting emacs.
Yes, I can.
2011/11/4 Eric Blake: With the win-ssh-agent, we can use the
ssh-agent (available inthe cygwin openssh) in the more smart
way. Normally, we need to start all relevant programs, which
mightneed to I'm not sure why your mail came through so garbled, but
the large number of missing spaces in your message distracts from
your attempt to appear professional in offering a package.
I'm sorry for missing spaces. I don't know why this happened ...
(3) I want to use the tramp ( http://www.gnu.org/s/tramp/ ) in the
ntemacs. With it, I can treat documents on the remote machine as if
they are on the local machine by: C-x C-f
/sshx:usernameathostname:~/remote-file Have you tried using the emacs
that ships with cygwin? It includes tramp.elc already built in, without
needing a separate download.
The URL is just a information for someone who are not familiar withthe
tramp. I didn't download it from there.
Unless you can give an example where an app in the cygwin distro would be
benefitted by adding a gui front-end to setting up the ssh-agent, and why
existing mechanisms of starting any cygwin app via a simple shell script
wrapper that attaches to $HOME/.keychain/${HOSTNAME}-sh if already present,
then I don't see why the cygwin distro needs win-ssh-agent. I'm not saying
that win-ssh-agent is bad (on the contrary, it does seem to help your use
case of ntemacs), just that since your primary use case demonstration was as
a stand-alone app for helping other non-cygwin apps, and not something that
fills a void for interaction with existing cygwin apps.
Ok. I understand why win-ssh-agent should be distributed
separatelyfrom the cygwin's distro.
Thanks for your valuable feedback. I withdraw this ITP.--
Nayuta Taga
Re: [ITP] imlib2
On Fri, Nov 04, 2011 at 05:11:33PM +0100, Corinna Vinschen wrote: On Nov 3 16:49, Yaakov (Cygwin/X) wrote: imlib2 is an image loading library from the Enlightenment project. ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Enlightenment/imlib2/ imlib2 is already in the major distros, and is required for an upcoming update to openbox. So no question that we need it. Yaakov, if you have to pull in packages because they are a requirement for newer versions of packages already in the distro, you really don't need to ITP them. Give us a quick note on this list and then just go auto-ahead. Don't wait for us slackers to cope with it. +1 cgf
Re: [ITP] win-ssh-agent 1.07
Sorry for my broken mail. I send it again by other mailer.
2011/11/4 Corinna Vinschen:
On Nov 4 15:37, Nayuta Taga wrote:
(1) I want to use it because the cygwin emacs does not have its own
windows. The cygwin emacs works only in the terminal.
Try xemacs. It has a Windows GUI fallback mode if there's no X display.
It's nice! I'll try it.
(2) I want to run it from the start menu or the Windows 7's task bar
(not from the cygwin bash shell). It is the window's style to run
applications.
You can start it from the start menu via a bash script which pulls in
the SSH_* environment before starting emacs.
Yes, I can.
2011/11/4 Eric Blake:
With the win-ssh-agent, we can use the ssh-agent (available inthe
cygwin openssh) in the more smart way.
Normally, we need to start all relevant programs, which mightneed to
I'm not sure why your mail came through so garbled, but the large
number of
missing spaces in your message distracts from your attempt to appear
professional in offering a package.
I'm sorry for missing spaces. I don't know why this happened ...
(3) I want to use the tramp ( http://www.gnu.org/s/tramp/ ) in the
ntemacs. With it, I can treat documents on the remote machine
as if they are on the local machine by:
C-x C-f /sshx:usernameathostname:~/remote-file
Have you tried using the emacs that ships with cygwin? It includes
tramp.elc already built in, without needing a separate download.
The URL is just a information for someone who are not familiar with
the tramp. I didn't download it from there.
Unless you can give an example where an app in the cygwin distro would be
benefitted by adding a gui front-end to setting up the ssh-agent, and why
existing mechanisms of starting any cygwin app via a simple shell script
wrapper that attaches to $HOME/.keychain/${HOSTNAME}-sh if already
present,
then I don't see why the cygwin distro needs win-ssh-agent. I'm not
saying
that win-ssh-agent is bad (on the contrary, it does seem to help your use
case of ntemacs), just that since your primary use case demonstration
was as
a stand-alone app for helping other non-cygwin apps, and not
something that
fills a void for interaction with existing cygwin apps.
Ok. I understand why win-ssh-agent should be distributed separately
from the cygwin's distro.
Thanks for your valuable feedback. I withdraw this ITP.
--
Nayuta Taga
[ITA/P] a2ps, libpaper
The Cygwin a2ps package is currently out of date and depends on the ancient libintl2, and furthermore the maintainer hasn't been heard from in years[1]. I think it's fair to call this orphaned at this point. While I have no particular attachment to this package, as I do have a working copy in Ports, I might as well ITA it: ftp://ftp.cygwinports.org/pub/cygwinports/release-2/a2ps/ Since this a2ps package uses libpaper, which is not yet in the distro, I'll ITP that now: ftp://ftp.cygwinports.org/pub/cygwinports/release-2/libpaper/ libpaper, while maintained by Debian, is found in all major distros. Yaakov [1] http://cygwin.com/ml/cygwin/2010-07/msg00561.html
Re: [ITP] astrometry.net-0.38-1
On 11/4/2011 2:29 AM, Charles Wilson wrote: Your build still links against libbackend.a, rather than cygbackend.dll. I'm trying to massage your -src package to DTRT. Stay tuned. I've posted a revised version of your package here: http://cygwin.cwilson.fastmail.fm/astrometry.net-0.38-2-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/astrometry.net-0.38-2.tar.bz2 Inside the -src tarball is the *original* upstream sources (astrometry.net-0.38.tar.bz2), a few patches, and a .cygport script. to rebuild, unpack the -src and do: $ cygport astrometry.net-0.38-2.cygport all You should probably do that, to ensure that the build procedure works on your machine. Also, to test the resuts; I have no idea how to use this stuff. Finally: the backend.exe program is linked to cygbackend.dll, which are both in /usr/lib/astrometry/bin/. All the python stuff, including three extension DLLs, are in /usr/lib/astrometry/python/*/ I modified the build procedure for cygbackend.dll -- it now generates an import lib, and it also (re)exports all of the symbols from the other (sub)libraries. That means when linking backend.exe, you don't need to list those other dependencies, because cygbackend.dll will satisfy them all. (*) Provided you can rebuild this package on your machine, AND that it actually works, consider it GTG. (*) I did not do this, but because cygbackend now exports all the symbols from (e.g.) libanfiles.a, libutils.a, libkd.a, etc, you COULD modify the link commands for almost all of the /other/ .exe's in the blind/ directory, which currently link against (many) of those static libraries, to instead link solely against cygbackend.dll (actually, libbackend.dll.a). That would make the entire package MUCH smaller. But it's a lot of work. -- Chuck
Re: Title bar of X apps, no host name?
On Thu, Nov 3, 2011 at 8:27 PM, Timothy Madden wrote: Does anyone know how to change the window title to include the hostname please ? Put the following into your PS1 (on the remote machines) : \[\e]0;\h:\w\a\] Or you could google for xterm window title Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. 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 -- 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/
Re: Title bar of X apps, no host name?
On 04.11.2011 11:09, Csaba Raduly wrote: On Thu, Nov 3, 2011 at 8:27 PM, Timothy Madden wrote: Does anyone know how to change the window title to include the hostname please ? Put the following into your PS1 (on the remote machines) : \[\e]0;\h:\w\a\] Or you could google for xterm window title I would like to change the title of all my X windows, so as to include the hostname of the X client for the window (that is, the hostname running the application in the window). If you connect with *ssh -Y* to several machines, than you can run GUI applications on those machines, and the windows will open up on your X desktop. If you start gvim on each of these machines, you have 4 gvim windows on your desktop, with no easy way to tell to which machine each window belongs. Some Linux X servers have this by default (I have CentOS), and it allows me to run *knosole* or *gnome-terminal* or *gvim* or any other application on several machines at the same time, with the X windows for them all on my desktop, without confusing the host machine for each window. Thank you, Timothy Madden -- 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/
RE: Title bar of X apps, no host name?
You can put what you want in the title by setting PROMPT_COMMAND - e.g., set PROMPT_COMMAND=setWindowTitle $(uname -n) where setWindowTitle is a shell script like: echo -ne \e]2;$*\a by putting it in the PROMPT_COMMAND you handle the case where some command sets the window title while it is processing (I do this to provide feedback for long running scripts without filling up the screen). Once the command finishes the window title gets set back to your desired value. Btw, I use different foreground/background color combinations to distinguish between xterms on different machines - some of the color combinations are ugly but they are different :-) -- 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/
winsup/cygwin ChangeLog sigproc.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-11-04 16:52:43 Modified files: cygwin : ChangeLog sigproc.cc Log message: * sigproc.cc (child_info_spawn::reattach_children): Clean up handle when can't open parent process or suffer handle leak. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5544r2=1.5545 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.349r2=1.350
winsup/cygwin ChangeLog pinfo.h sigproc.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-11-04 17:07:21 Modified files: cygwin : ChangeLog pinfo.h sigproc.cc Log message: * pinfo.h (pinfo::reattach): Only set destroy to false when proc_subproc succeeds. Return true for success. * sigproc.cc (child_info_spawn::reattach_children): Try harder to clean up on error by detecting reattach failures too. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5545r2=1.5546 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/pinfo.h.diff?cvsroot=uberbaumr1=1.119r2=1.120 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.350r2=1.351
Re: Extend faq.using to discuss fork failures
On 03/11/2011 21:05, Christopher Faylor wrote: I would still prefer eschewing actively negative words like hostile and just neutrally stating that Windows does not use a fork/exec model and does not offer any easy way to implement fork. Hmm, yes, I'll fix that. I'd also like to see specific errors mentioned so that when people are searching for a solution to the problem they will be able to find it in the FAQ. Is there something wrong with the itemized list which follows that sentence?
Re: Extend faq.using to discuss fork failures
On 03/11/2011 17:17, Corinna Vinschen wrote: Thanks for doing that. I looks good to me, with just one exception. +listitemAddress space layout randomization (ASLR). Starting with +Vista, Windows implements ASLR, which means that thread stacks, +heap, memory-mapped files, and statically-linked dlls are placed +at different (random) locations in each process. This behaviour +interferes with a properliteralfork/literal, and if an +unmovable object (process heap or system dll) ends up at the wrong +location, Cygwin can do nothing to compensate (though it will +retry a few times automatically). In a 64-bit system, marking +executables as large address-ware and rebasing dlls to high +addresses has been reported to help, as ASLR affects only the +lower 2GB of address space./listitem Starting with In a 64-bit system it's getting a bit weird: - Starting with 4.5.3, gcc marks executables as large address aware automatically, so this is going to be a lesser problem over time. Is it worth to mention this at all? I suppose so, but the user should be pointed to peflags to tests for this property first for the given reason. - Starting with Cygwin 1.7.10, the high address area will be used for the application heap on 64 bit systems and large address aware executables. Mmaps are located there, too. This in turn leaves more room for DLLs in the normal 2 Gigs memory area. Therefore I would not like to suggest rebasing DLLs into the high address area at all. This should only be done by people who know what they are doing. Usually there should be enough space in the lower 2 Gigs, especially when heap and mmaps are out of the way, and given that the more recent rebaseall will not create an arbitrary 64K hole between DLLs anymore when rebasing. I think it would be simplest just to drop the sentence starting In a 64-bit system.
Re: Extend faq.using to discuss fork failures
On Fri, Nov 04, 2011 at 01:34:09PM +, Jon TURNEY wrote: On 03/11/2011 21:05, Christopher Faylor wrote: I would still prefer eschewing actively negative words like hostile and just neutrally stating that Windows does not use a fork/exec model and does not offer any easy way to implement fork. Hmm, yes, I'll fix that. Thanks. I'd also like to see specific errors mentioned so that when people are searching for a solution to the problem they will be able to find it in the FAQ. Is there something wrong with the itemized list which follows that sentence? No, sorry. I'm email challenged at the moment so I missed it. cgf
Re: Possible Bug (clarification) in Cygwin 1.7.5 -- findfirstfile (and findnextfile) yeild bad cfilename when file names have special characters. Works in cygwin 1.5, fails in 1.7
On Nov 3 17:56, Charles Wilson wrote: On 11/3/2011 4:48 PM, Leon Vanderploeg wrote: With cygwin 1.7.5, cFileName with a special characters such as ñ (n with tidle above it) fail be properly extracted from a WIN32_FIND_DATA structure with findFirstFile (or findNextFile). To set up a simple test scenario, I created a file in C:\Testing named Mañana.docx. I compiled the code at the end of this message on Cygwin 1.7.9 with GCC version 3.4.4 on Server 2008 32 bit system. On this system (and on a Windows 7 32 bit machine), it returns: a) Why are you using native Win32 APIs in a cygwin program? You should be using the POSIX interfaces instead -- see /usr/include/dirent.h. DIR *opendir (const char *); DIR *fdopendir (int); struct dirent *readdir (DIR *); int readdir_r (DIR *, struct dirent *, struct dirent **); void rewinddir (DIR *); int closedir (DIR *); ACK++ b) What you observe is an artifact of cygwin-1.7's new *support* for i18n. In cygwin-1.5, it just didn't care and passed all the bytes back exactly as found without transliteration. In 1.7, it (correctly) transcodes strings into the current locale -- and your current locale does not appear to support ñ -- or, at least, you haven't told cygwin to use the correct one. (I'm probably thoroughly botching this explanation, but the point is, Just a bit. What you have to keep in mind is that Windows stores all object names, including filenames, as UTF-16 strings, UNICODE in Windows terminology. When you use the ANSI Win32 API as in this example, then the UTF-16 names are converted to the currently defined ANSI charset on output, for instance codepage 1252 for Western Europe languages. Cygwin 1.5 either used the ANSI API, or it converted strings from UTF-16 to the current Windows ANSI charset or vice versa. Cygwin 1.7 doesn't use the ANSI API anymore, rather it uses UNICODE to talk to Windows only, and the multibyte charset is defined through the environment(*) as defined in POSIX. UTF-8 is the default now. you need to check your LC_* and LANG env vars, and maybe call setlocale(LC_ALL, ) in your application.) And even than the code won't work. If you don't define UNICODE, FindFirstFile/FindNextFile will use the ANSI versions of this API, FindFirstFileA/FindNextFileA. If you didn't set your LANG/LC_CTYPE/LC_ALL variables to use your current Windows ANSI charset *and* called setlocale, Cygwin will use UTF-8 by default. Therefore, the character ñ will have another multibyte encoding, 0xc3 0xb1, rather than, say, 0xf1 in Windows codepage 1252. To avoid this problem, you can use the UNICODE API FindFirstFileW/ FindNextFileW and convert the filename the current multibyte charset via wcstombs and friends. However, as Chuck has pointed out, the obviously right thing to do is to use the POSIX API opendir/readdir/closedir instead. Corinna (*) http://cygwin.com/cygwin-ug-net/setup-locale.html http://cygwin.com/cygwin-ug-net/using-utils.html#locale -- 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 execution of binary file
On 11/3/2011 4:56 PM, Eliot Moss wrote: Ok, so here's one thing about bash: to get it to run an *executable* (as opposed to a *script*), you need to say bash -c FLEXPART_GFORTRAN. You might try strace on that. In addition to the objdump suggestion. I have a moment to expand on this a little. The 80-byte read we saw was bash looking at the beginning of what it that was supposed to be a script (not a binary) and seeing if it really appeared to be a script. I did not look like a script, so bash gave up. (It checks whether the first line is all printable characters or white space.) Best -- Eliot Moss Hmm, wonder why bash would interpret it as a script. Anyway, I will get back to you later with output from strace and objdump. Cheers, kåre
Re: Problem with execution of binary file
On 11/4/2011 3:50 AM, Edvardsen Kåre wrote: On 11/3/2011 4:56 PM, Eliot Moss wrote: Ok, so here's one thing about bash: to get it to run an *executable* (as opposed to a *script*), you need to say bash -c FLEXPART_GFORTRAN. You might try strace on that. In addition to the objdump suggestion. I have a moment to expand on this a little. The 80-byte read we saw was bash looking at the beginning of what it that was supposed to be a script (not a binary) and seeing if it really appeared to be a script. I did not look like a script, so bash gave up. (It checks whether the first line is all printable characters or white space.) Best -- Eliot Moss Hmm, wonder why bash would interpret it as a script. Anyway, I will get back to you later with output from strace and objdump. Because you did not specify -c ... EM -- 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
Can't get sshd to work
Hi everybody, First post here, I am a Cygwin newbie. I try to implement ssh connectivity between my Windows 7 desktop and a FreeBSD/FreeNAS server. Openssh shell commands seem to work, but sshd is not running and thus network commands issued from the server abort because of connection refused. The sshd windows service is automatically started at windows startup, but it is not running. If I start the service by Windows command, it starts and stops immediately (Windows saying). If I start it at the command line with ssh I tried 2 ways $ /usr/sbin/sshd.exe /etc/sshd_config: No such file or directory $cygrunsrv --start sshd cygrunsrv: Error starting a service: OpenService: Win32 error 5: Accès refusé. I searched this forum but I am lost in the variety of parameters and reasons of not working, as well as different versions. In fact I downloaded the cygwin setup, and installed the default packages, and afterwards I installed the openssh package (5.9). What is to be done in order to debug this problem ? Is sshd simply lacking a sshd_config file ? Then how to build it ? :) Gabier -- View this message in context: http://old.nabble.com/Can%27t-get-sshd-to-work-tp32779981p32779981.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
proc_waiter: error on read of child wait pipe
Hello, I have all the packages up to date, and also the last Cygwin snapshot: jupiter% cat /proc/version | tr -d '\100' CYGWIN_NT-5.1 version 1.7.10s(0.254/5/3) (cgf) (gcc version 4.3.4 20090804 (release) 1 (GCC) ) 20111030 04:51:42 jupiter% I have compiled the last upstream tcsh (tcsh-6.17.06.tar.gz) with all default options. and installed the newly compiled tcsh into /bin/tcsh-6.17.06 for testing. I can now experience the following strange message: jupiter% /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `echo foo | wc -c`' 2 [proc_waiter] wc 2840 proc_waiter: error on read of child wait pipe 0x708, Win32 error 6 jupiter% wc seems to be able to be replaced by anything else, with the same message: jupiter% /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `echo foo | cat`' 330 [proc_waiter] cat 3912 proc_waiter: error on read of child wait pipe 0x708, Win32 error 6 jupiter% And the result seems ok: jupiter% /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `echo foo | tr o a`; echo $bar' 243 [proc_waiter] tr 2892 proc_waiter: error on read of child wait pipe 0x708, Win32 error 6 faa jupiter% On the other hand, the following variations don't produce the message: /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `/usr/bin/echo foo | wc -c`' /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'echo foo | wc -c' /usr/bin/env -i PATH=/usr/bin /bin/tcsh -fc 'set bar = `echo foo | wc -c`' When the number of pipes increases, the result is not so easily predictable (or reproducible): jupiter% /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `cat /proc/version | cat | wc -c`' jupiter% /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `cat /proc/version | cat | cat | wc -c`' 3 [main] wc 260 child_info_spawn::reattach_children: couldn't duplicate parent 0x6A0 handles for forked children after exec, Win32 error 6 177 [main] wc 260 _pinfo::dup_proc_pipe: DuplicateHandle failed, pid 2884, hProcess 0x708, wr_proc_pipe 0x700, Win32 error 5 270 [main] wc 260 child_info_spawn::reattach_children: couldn't duplicate parent 0x658 handles for forked children after exec, Win32 error 6 345 [main] wc 260 _pinfo::dup_proc_pipe: DuplicateHandle failed, pid 2720, hProcess 0x6F8, wr_proc_pipe 0x6F0, Win32 error 5 (there seems to be another effect) jupiter% /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `cat /proc/version | cat | cat | cat | wc -c`' 1 [proc_waiter] wc 2908 proc_waiter: error on read of child wait pipe 0x6F8, Win32 error 6 jupiter% /usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc 'set bar = `/usr/bin/echo foo | cat | wc -c`' 1 [proc_waiter] wc 3908 proc_waiter: error on read of child wait pipe 0x708, Win32 error 6 Compilation of tcsh under GCC-4.5.3 (Cygwin default) or GCC-4.6.2 has the same effect. Use of tcsh-6.17.04, tcsh-6.17.05 and tcsh-6.17.06 all have the same effect. But tcsh-6.17.00 (upstream) or tcsh-6.17.00.1-1 (patched by CV) do not exhibit the message. (i have currently no access to tcsh-6.17.01, tcsh-6.17.02 and tcsh-6.17.03) The message appeared with the 2011-10-26 snapshot (was not there with the 2011-10-23 snapshot). Of course, the decorations '/usr/bin/env -i PATH=/usr/bin /bin/tcsh-6.17.06 -fc' are not really needed. If your shell is tcsh-6.17.06, the result is: jupiter% echo `echo foo | wc -l` 5 [proc_waiter] wc 732 proc_waiter: error on read of child wait pipe 0x720, Win32 error 6 1 jupiter% Is somebody able to reproduce this? Regards, Denis Excoffier. -- 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 execution of binary file
On fr., 2011-11-04 at 05:50 -0500, Eliot Moss wrote: On 11/4/2011 3:50 AM, Edvardsen Kåre wrote: On 11/3/2011 4:56 PM, Eliot Moss wrote: Ok, so here's one thing about bash: to get it to run an *executable* (as opposed to a *script*), you need to say bash -c FLEXPART_GFORTRAN. You might try strace on that. In addition to the objdump suggestion. I have a moment to expand on this a little. The 80-byte read we saw was bash looking at the beginning of what it that was supposed to be a script (not a binary) and seeing if it really appeared to be a script. I did not look like a script, so bash gave up. (It checks whether the first line is all printable characters or white space.) Best -- Eliot Moss Hmm, wonder why bash would interpret it as a script. Anyway, I will get back to you later with output from strace and objdump. Because you did not specify -c ... EM I'm still learning :) Anyway, I've installed two versions of cygwin on the same machine - the first was installed around Oct. 3 and the second one from a few days ago. Compiling exactly the same software on both versions gives success on the older installation and failure on the newer one. Could it be that newer versions of some libs/compilers have bugs? Something different between those two versions is for sure causing the problem. Oviously, I'm using gfortran for building FLEXPART_GFORTRAN but I've also installed from source the latest version of jasper and grib_api libs (required by my FLEXPART software), and I'm not sure in detail what is involved in building those libs. Do you have any immediate idea of what could be the potential problem? Cheers, Kåre
Re: Can't get sshd to work
On 11/4/2011 8:17 AM, gabier wrote: Hi everybody, First post here, I am a Cygwin newbie. I try to implement ssh connectivity between my Windows 7 desktop and a FreeBSD/FreeNAS server. Openssh shell commands seem to work, but sshd is not running and thus network commands issued from the server abort because of connection refused. The sshd windows service is automatically started at windows startup, but it is not running. If I start the service by Windows command, it starts and stops immediately (Windows saying). If I start it at the command line with ssh I tried 2 ways $ /usr/sbin/sshd.exe /etc/sshd_config: No such file or directory $cygrunsrv --start sshd cygrunsrv: Error starting a service: OpenService: Win32 error 5: Accès refusé. I searched this forum but I am lost in the variety of parameters and reasons of not working, as well as different versions. In fact I downloaded the cygwin setup, and installed the default packages, and afterwards I installed the openssh package (5.9). What is to be done in order to debug this problem ? Is sshd simply lacking a sshd_config file ? Then how to build it ? Did you run /usr/bin/ssh-host-config ? 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: Can't get sshd to work
Ken Brown-6 wrote: On 11/4/2011 8:17 AM, gabier wrote: Hi everybody, First post here, I am a Cygwin newbie. I try to implement ssh connectivity between my Windows 7 desktop and a FreeBSD/FreeNAS server. Openssh shell commands seem to work, but sshd is not running and thus network commands issued from the server abort because of connection refused. The sshd windows service is automatically started at windows startup, but it is not running. If I start the service by Windows command, it starts and stops immediately (Windows saying). If I start it at the command line with ssh I tried 2 ways $ /usr/sbin/sshd.exe /etc/sshd_config: No such file or directory $cygrunsrv --start sshd cygrunsrv: Error starting a service: OpenService: Win32 error 5: Accès refusé. I searched this forum but I am lost in the variety of parameters and reasons of not working, as well as different versions. In fact I downloaded the cygwin setup, and installed the default packages, and afterwards I installed the openssh package (5.9). What is to be done in order to debug this problem ? Is sshd simply lacking a sshd_config file ? Then how to build it ? Did you run /usr/bin/ssh-host-config ? 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 No, I had not. I did not know I had to. Well, I ran it, but it asks me if I want privileged separation or not. I searched a little on internet to know what this is. It seems a good architecture, but I am feared that being rather new it introduces new problems. Does it work well now and is there a manual or how to in this context ? If I choose NO, is it dangerous but more simple ? :) Gabier -- View this message in context: http://old.nabble.com/Can%27t-get-sshd-to-work-tp32779981p32780552.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Can't get sshd to work
On 11/4/2011 08:58, gabier wrote: Ken Brown-6 wrote: On 11/4/2011 8:17 AM, gabier wrote: Hi everybody, First post here, I am a Cygwin newbie. I try to implement ssh connectivity between my Windows 7 desktop and a FreeBSD/FreeNAS server. Openssh shell commands seem to work, but sshd is not running and thus network commands issued from the server abort because of connection refused. The sshd windows service is automatically started at windows startup, but it is not running. If I start the service by Windows command, it starts and stops immediately (Windows saying). If I start it at the command line with ssh I tried 2 ways $ /usr/sbin/sshd.exe /etc/sshd_config: No such file or directory $cygrunsrv --start sshd cygrunsrv: Error starting a service: OpenService: Win32 error 5: Accès refusé. I searched this forum but I am lost in the variety of parameters and reasons of not working, as well as different versions. In fact I downloaded the cygwin setup, and installed the default packages, and afterwards I installed the openssh package (5.9). What is to be done in order to debug this problem ? Is sshd simply lacking a sshd_config file ? Then how to build it ? Did you run /usr/bin/ssh-host-config ? No, I had not. I did not know I had to. Well, I ran it, but it asks me if I want privileged separation or not. I searched a little on internet to know what this is. It seems a good architecture, but I am feared that being rather new it introduces new problems. Does it work well now and is there a manual or how to in this context ? If I choose NO, is it dangerous but more simple ? Privilege separation has been around for years now, so there's no risk with using it, really. Unless you know better, you should take all the defaults provided by ssh-host-config. You can always run it again later to change something. -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: ssh through Cisco VPN problem
Does anyone have any idea why the openssh in cygwin (latest) would not connect through a Cisco vpn, but putty and virtualboxed Fedora's ssh would have no problem? Cygwin's ssh works fine at work, not using the vpn. I'll include -vvv's if no one knows right off the bat. -- 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: Can't get sshd to work
Jeremy Bopp-3 wrote: On 11/4/2011 08:58, gabier wrote: Ken Brown-6 wrote: On 11/4/2011 8:17 AM, gabier wrote: Hi everybody, First post here, I am a Cygwin newbie. I try to implement ssh connectivity between my Windows 7 desktop and a FreeBSD/FreeNAS server. Openssh shell commands seem to work, but sshd is not running and thus network commands issued from the server abort because of connection refused. The sshd windows service is automatically started at windows startup, but it is not running. If I start the service by Windows command, it starts and stops immediately (Windows saying). If I start it at the command line with ssh I tried 2 ways $ /usr/sbin/sshd.exe /etc/sshd_config: No such file or directory $cygrunsrv --start sshd cygrunsrv: Error starting a service: OpenService: Win32 error 5: Accès refusé. I searched this forum but I am lost in the variety of parameters and reasons of not working, as well as different versions. In fact I downloaded the cygwin setup, and installed the default packages, and afterwards I installed the openssh package (5.9). What is to be done in order to debug this problem ? Is sshd simply lacking a sshd_config file ? Then how to build it ? Did you run /usr/bin/ssh-host-config ? No, I had not. I did not know I had to. Well, I ran it, but it asks me if I want privileged separation or not. I searched a little on internet to know what this is. It seems a good architecture, but I am feared that being rather new it introduces new problems. Does it work well now and is there a manual or how to in this context ? If I choose NO, is it dangerous but more simple ? Privilege separation has been around for years now, so there's no risk with using it, really. Unless you know better, you should take all the defaults provided by ssh-host-config. You can always run it again later to change something. -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 Thanks Ken and Jeremy I took the default, it went on without error, and at last I could start my sshd service on windows 7 without immediate abortion. As a first test I issued a scp command from the freebsd server as follows (first, login and second scp command asking to transfer testfile.txt from the windows computer at 192.168.1.103 to the freenas server. $ssh gabriel@freennas Password etc... Welcome... OK $scp gabriel@192.168.1.103:/cygdrive/E/gabriel/testfile.txt ~/gabriel/testfile.txt Now the connection is established but there is a password problem Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password,keyboard-interactive). The 2 users who communicate have the same name gabriel and the same password, but this password is denied. Is this a known problem and how can I debug it. -- View this message in context: http://old.nabble.com/Can%27t-get-sshd-to-work-tp32779981p32781364.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 execution of binary file
Anyway, I've installed two versions of cygwin on the same machine - the first was installed around Oct. 3 and the second one from a few days ago. Compiling exactly the same software on both versions gives success on the older installation and failure on the newer one. Could it be that [...] Do you have any immediate idea of what could be the potential problem? Only immediate suggestions :). Run 'objdump -fp' on the two executables. Perhaps there's a difference between outputs that stands out or is meaningful to somebody on the list when you report it. Another thing you might try is 'cygcheck -svr' on the two Cygwin versions and compare output. That may show meaningful differences between the two versions. That will have a lot of output to sift through but any differences listed may point to something. ..mark -- 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 execution of binary file
I would add that having more than one cygwin installation on the same system can be tricky, since you need to insure that each program gets the right dlls, etc. Regards -- Eliot Moss -- 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 execution of binary file
Eliot Moss writes: I would add that having more than one cygwin installation on the same system can be tricky, since you need to insure that each program gets the right dlls, etc. Sheesh, it's so tricky that I assumed the OP meant he had separate VMs for his two Cygwin installations. If they really are installed on one machine, as the OP said, one 'cygcheck -svr' is enough. I don't think the cygcheck has ever been posted in this thread but is the main requirement asked on http://cygwin.com/problems.html when reporting problems. ..mark -- 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: imlib2-1.4.5-1
The following packages have been added to the Cygwin distribution: *** imlib2-1.4.5-1 *** libImlib2_1-1.4.5-1 *** libImlib2-devel-1.4.5-1 imlib2 is an image-loading library from the Enlightenment project. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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: ssh public key authentication problem using curl
Greetings, carolus! What was exact command? curl -v -O sftp://dell03/cygdrive/f/transit_ext/this_is_external_drive.txt (without the newline. I can't get rid of it using the Thunderbird newsreader to write this reply.) And so, what the answer you've expected? You didn't supplied a username to the remote host at all. Quite predictable, you got a name mismatch... -- WBR, Andrey Repin (anrdae...@freemail.ru) 04.11.2011, 23:32 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
Re: ssh through Cisco VPN problem
On Fri, Nov 4, 2011 at 2:52 PM, Joseph Krahn joseph.kr...@gmail.com wrote: I had a weird problem with some versions of sshd not working from problems with negotiating a cipher, and it was fixed by disabling a few specific ciphers in my ssh config. I don't recall which ones were giving problems. Hope this helps. Joe Krahn It's a place to start looking. Thanks. -- 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: Why 'script' utility require SHELL (and work fine under Linux)?
On Fri, Nov 04, 2011 at 06:05:39AM +0100, Cyrille Lefevre wrote: the base-file maintainer has been BCC'ed to add the export SHELL to the /etc/profile. GNU/Linux login sets SHELL to bash, mksh, ... whilst ssh sets SHELL to /bin/bash, /bin/posh, /bin/mksh ... Given that there is no real login into cygwin (yet?), SHELL should be set to the expected login value. Assuming SHELL would be set and exported for login shells, i.e., further (nested) callings to interactive, non-login shells would inherit the original (login) SHELL value (as in GNU/Linux): $ echo $SHELL bash $ mksh $ echo $SHELL bash It could be fixed for bash, zsh, and mksh. Even for nested calls to login shells (which GNU/Linux doesn't honor) by setting SHELL for every ifdef in /etc/profile. Collateral damage: -posh works OK if set as login shell in /etc/passwd, but it is broken when called from command line as login shell (i.e. it ignores both /etc/profile and ~/.profile) -sh thinks she's bash: $ bash -l $ echo $SHELL bash $ mksh -l $ echo $SHELL mksh $ sh -l $ echo $SHELL bash $ posh -l $ echo $SHELL bash In short: it's not clear to me how to add this functionality consistently. -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
cygwin on virtual box vm
I have Windows XP Pro x32 in a VM with the latest version of cygwin installed. When I open a cygwin bash shell, and type '$ls' it just sits there forever. Any other command I type is freakishly slow. How do I get this to run faster under a vm environment. I am not sure why it is taking so long to do a simple ls or mkdir or any other command. Even if I $vi a file it takes a while seriously cutting into the productivity gains that cygwin on the host environment provides. -- 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: ssh public key authentication problem using curl
On 11/4/2011 2:33 PM, Andrey Repin wrote: You didn't supplied a username to the remote host at all. Quite predictable, you got a name mismatch... Thanks. That was the clue. The following all work, connecting to my cygwin home directory on the server: ssh dell03 sftp dell03 lftp sftp://dell03 but curl requires a more explicit syntax: curl sftp://cdr@dell03 I had tried curl -u cdr, but that asks for a password. Since I want to use curl in a script, I did not want to have to enter a password. I did not think of trying a different syntax until reading your suggestion. -- 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
1.7.10s(0.254/5/3) ssh pubkey disconnect
I don't have time to debug further right now, but this is just a heads up that I just updated using setup and installed the subject snapshot. Now, ssh with pubkey auth immediately disconnects from mintty and rxvt: $ uname -a CYGWIN_NT-5.1 PC1163-8460-XP 1.7.10s(0.254/5/3) 2004 17:08:22 i686 Cygwin $ ssh localhost Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Fri Nov 4 16:44:01 2011 from localhost Connection to localhost closed. and in the Windows Event log: Received disconnect from 127.0.0.1: 11: disconnected by user. Just curious if anyone has a WAG? If not, I'll look harder on Monday. Thanks. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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 very slow under virtual box (productivity hit)
I have Windows XP Pro x32 in a VM with the latest version of cygwin installed. When I open a cygwin bash shell, and type '$ls' it just sits there forever. Any other command I type is freakishly slow. How do I get this to run faster under a vm environment. I am not sure why it is taking so long to do a simple ls or mkdir or any other command. Even if I $vi a file it takes a while seriously cutting into the productivity gains that cygwin on the host environment provides. Is there a commercial version of cygwin or the likes that I can lay down cash for to go fast under a VM environment? I need to get this going or dump it all together for something else, work has slowed to a halt. -- 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 very slow under virtual box (productivity hit)
On 11/4/2011 4:28 PM, J.V. wrote: I have Windows XP Pro x32 in a VM with the latest version of cygwin installed. When I open a cygwin bash shell, and type '$ls' it just sits there forever. Any other command I type is freakishly slow. How do I get this to run faster under a vm environment. I am not sure why it is taking so long to do a simple ls or mkdir or any other command. Even if I $vi a file it takes a while seriously cutting into the productivity gains that cygwin on the host environment provides. I use Cygwin in a (VMware Player) VM with XP all the time and it's not like you describe at all. I think the main Cygwin developers also use VMs (at least from time to time), so there's nothing intrinsic to running in a VM that causes the performance you describe. I can't say for sure what your problem is, but I'd start by checking your PATH for any directories on a remote machine (including any host directories provided by your VM software). Or, perhaps simply try $ PATH /bin /bin/ls and see if your problem goes away. If none of that works, follow the directions here: http://cygwin.com/problems.html Is there a commercial version of cygwin or the likes that I can lay down cash for to go fast under a VM environment? No. -- David Rothenberger daver...@acm.org Every cloud engenders not a storm. -- William Shakespeare, Henry VI -- 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 very slow under virtual box (productivity hit)
On 11/4/2011 5:00 PM, David Rothenberger wrote: Or, perhaps simply try $ PATH /bin /bin/ls and see if your problem goes away. That should read: $ PATH=/bin /bin/ls and just to be clear, the $ is the prompt character. Don't type it. -- David Rothenberger daver...@acm.org For years a secret shame destroyed my peace-- I'd not read Eliot, Auden or MacNiece. But now I think a thought that brings me hope: Neither had Chaucer, Shakespeare, Milton, Pope. -- Justin Richardson. -- 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
New package: imlib2-1.4.5-1
The following packages have been added to the Cygwin distribution: *** imlib2-1.4.5-1 *** libImlib2_1-1.4.5-1 *** libImlib2-devel-1.4.5-1 imlib2 is an image-loading library from the Enlightenment project. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.
