Re: [ITA] Procmail 3.22
Hi Corinna, Corinna Vinschen wrote: Some users are running fetchmail/procmail/mutt without the detour over using an MTA, for instance: $ grep mda ~/.fetchmailrc mda /usr/bin/procmail -d %T Will this still work as expected, even if the user is member of the admin group? Keep in mind that Windows XP/2003 are not providing UAC at all, and even on UAC-providing systems, it might be switched off. I implemented the ipv6 patch. Here's the new release candidate: http://cygwin.boland.nl/x86/release/procmail/ I tested fetchmail, the way you indicate. It works fine, both for admin and non-admin users. Procmail always acts as the mailbox (calling) user. That's why Sendmail changes user two times, instead of one: root - smmsp - corinna By the way: this combination of fetchmail and procmail is nice. What program do you use to read the downloaded e-mail? By the way 2: to be shure: does your procmail put the e-mails in /var/spool/mail? And can you paste me the output of ls -l /var/spool/mail? Daniel
Re: [ITP] libsuexec 1.0
Hi Daniel, On Aug 17 21:22, D. Boland wrote: Hi group, Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. * The term 'capabilities' has been removed from the hints file, since that is not what the library is about or for. * Also the term 'multi-root' has been removed from the hints file. I think the new description in the hints file now accurately covers what the library does. * Not all functions in the library were declared. They are now. * I added a readme file. * I removed the dynamic library. This library will be static only. * I put the license under the 'Open Source Definition' license and added a reference to the complete license text. Uh, that's a bit of a problem. The text under http://opensource.org/docs/osd/ does *not* constitute a license by itself. It just describes what a license has to define to become an OSS license. For blessed OSS licenses, see http://opensource.org/licenses/. For a simple lib like this I'd suggest http://opensource.org/licenses/BSD-2-Clause or http://opensource.org/licenses/LGPL-3.0 http://cygwin.boland.nl/x86/release/libsuexec/ A LICENSE file parallel to usr/share/doc/README containing the license text would be nice. Other than that licensing issue, the package is GTG. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7mHTQaZvPn.pgp Description: PGP signature
Re: [ITA] Procmail 3.22
On Aug 18 12:42, D. Boland wrote: Hi Corinna, Corinna Vinschen wrote: Some users are running fetchmail/procmail/mutt without the detour over using an MTA, for instance: $ grep mda ~/.fetchmailrc mda /usr/bin/procmail -d %T Will this still work as expected, even if the user is member of the admin group? Keep in mind that Windows XP/2003 are not providing UAC at all, and even on UAC-providing systems, it might be switched off. I implemented the ipv6 patch. Here's the new release candidate: http://cygwin.boland.nl/x86/release/procmail/ Looks GTG, except... the version number is bad :} The 64 bit package already *is* 3.22-13, so your package should at least be 3.22-14 to override the older version automatically without deleting it. I tested fetchmail, the way you indicate. It works fine, both for admin and non-admin users. Procmail always acts as the mailbox (calling) user. That's why Sendmail changes user two times, instead of one: root - smmsp - corinna Just for the accuracy-huggers: root - smmsp - corinna can't work because smmsp doesn't have the right to switch the user context. This should be either root - smmsp | +- corinna with smmsp and corinna process ineracting via pipes or sockets, or root - smmsp via seteuid - back to root - corinna via setuid Anyway, thanks for confirming that it works. By the way: this combination of fetchmail and procmail is nice. What program do you use to read the downloaded e-mail? mutt, but I'm not using this method. I'm runninng my mail stuff on Linux using postfix as MTA. By the way 2: to be shure: does your procmail put the e-mails in /var/spool/mail? No, my procmail distributes the mail it gets from postfix into a few hundred MBOX files under ~/Mail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp28YBds1j7V.pgp Description: PGP signature
SSH key for upload access
Name: Daniel Boland Package: procmail BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by daniel@dimension from OpenSSH B3NzaC1yc2EDAQABAAABAQDQCiyKsZZIrVQ937mkmSTea59jV/tb4rfAri22AZ OhpmKHPclPSQ1NUbV6lD1GxXZWzg/7oDV9KvQYb6jUVJkhSqeQq2uUUO0l7qVFhJrtJT3y iOo0bBM95dWWZVtjjIajZ+6Mb7OLXuAAE/LgW8DF4xVNC1QuRIfecK4q1UI+KDiB0jFuB0 HUJVHnOd/eNQmPO9mMfaNfW3d2IkboqpgIBSz+KsjIJsVHxwQEYcpP6dcJRmmwX5cwT+ry QGVnR39L53W5vPdtNQcOoL+44nXeZkltTmmIwAhs8cdtegFV9v5SygnSfUxEGK83xgagAc 6ygFSh6eFgiQI8apM2kCSn END SSH2 PUBLIC KEY
Re: [ITP] libsuexec 1.0
Hi Corinna, Corinna Vinschen wrote: * I put the license under the 'Open Source Definition' license and added a reference to the complete license text. Uh, that's a bit of a problem. The text under http://opensource.org/docs/osd/ does *not* constitute a license by itself. It just describes what a license has to define to become an OSS license. For blessed OSS licenses, see http://opensource.org/licenses/. For a simple lib like this I'd suggest http://opensource.org/licenses/BSD-2-Clause or http://opensource.org/licenses/LGPL-3.0 http://cygwin.boland.nl/x86/release/libsuexec/ A LICENSE file parallel to usr/share/doc/README containing the license text would be nice. I changed the license to LGPL 2.1. It has the nice short text to paste in my sources :-). I also updated the procmail package. It has Cygwin version 14 now. Finally, I sent my public key, so now I will wait for activation. Thanks, Daniel
Re: [ITP] libsuexec 1.0
D. Boland writes: Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. I still think you should name it differently. Marco has already mixed it up with Apache suexec… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITP] libsuexec 1.0
Hi Achim, Achim Gratz wrote: D. Boland writes: Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. I still think you should name it differently. Marco has already mixed it up with Apache suexec⦠The idea kind of was to mix it up, so people will know what it does. I noticed that you and other people already declare the user switching technique half dead. It's a brilliant idea, you know. Because of its simplicity. It's even patented. By referring to the Apache executable I give the technique the glory and attention it deserves. So most people are thinking 'Capabilities' nowadays... Sigh. This will only steer admins away from finding out how user switching works and applying it. Instead they will just run entire server processes as admin-users. Sincerely, Daniel
Re: [ITA] Git et al
On 08/13/2014 01:12 PM, Adam Dinwoodie wrote: On Mon, Aug 04, 2014 at 10:41:06PM +0100, Adam Dinwoodie wrote: Just to update folk: I've bumped to v2.0.4, and everything's working a lot more nicely. I've managed CVS imports using both 32-bit and 64-bit, and I'm in the process of ironing out a few kinks in the test suites before I'm ready to release. This definitely feels like the home stretch for getting something ready to upload and distribute. I think everything's good to go! CVS imports are working fine, I've used the build myself briefly (and a previous almost-identical build for a while), and the test suites are almost all passing*. I'm not sure what the process is for adopting somebody else's package; the Submitting a new package instructions don't seem to apply since it's not a new package, but I don't yet have upload rights to just go ahead and do it. Adam, you are now listed as maintainer in cygwin-pkg-maint, so go ahead and submit your ssh key email. I trust that you'll fix the remaining package wrinkle before actually pushing a package, but even though I had a slight issue in rebuilding the package, I haven't had any problems using the pre-built binaries. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ITA] ed-1.10-1
On 2014-08-17 03:46, Marco Atzeri wrote:
On 17/08/2014 09:56, Yaakov Selkowitz wrote:
On Sun, 2014-08-17 at 09:44 +0200, Marco Atzeri wrote:
On 17/08/2014 08:47, Yaakov Selkowitz wrote:
Why no debuginfo?
no idea.
the build system is a bit basic, pre-autoconf age,
Then you need to help it along. This is a bit outdated but should help
you fix that:
http://sourceforge.net/p/cygwin-ports/ed/ci/master/tree/ed.cygport
done.
cygmake CFLAGS=${CFLAGS}
was enough
Great, thanks. ed is yours now.
Yaakov
src/winsup/cygwin ChangeLog dtable.cc fhandler ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-08-18 11:09:56 Modified files: winsup/cygwin : ChangeLog dtable.cc fhandler.h fhandler_serial.cc fhandler_socket.cc Log message: * dtable.cc (dtable::init_std_file_from_handle): Mention that console handles are kernel objects since Windows 8. * fhandler.h (enum conn_state): Add listener state. (class fhandler_socket): Drop listener status flag. (fhandler_socket::lseek): Return -1 and errno ESPIPE. (fhandler_serial::lseek): Ditto. * fhandler_socket.cc (fhandler_socket::listen): Set connect_state to listener. Add comment. (fhandler_socket::accept4): Explicitely check if the socket is listening and fail with EINVAL, if not. Explain why we have to do that. (fhandler_socket::recv_internal): Explicitely check if the socket is connected if it's a stream socket. Explain why we have to do that. (fhandler_socket::getpeereid): Drop now redundant test. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6493r2=1.6494 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srcr1=1.278r2=1.279 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srcr1=1.503r2=1.504 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_serial.cc.diff?cvsroot=srcr1=1.93r2=1.94 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srcr1=1.307r2=1.308
src/winsup/cygwin/release 1.7.33
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-08-18 11:37:28 Modified files: winsup/cygwin/release: 1.7.33 Log message: Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.33.diff?cvsroot=srcr1=1.1r2=1.2
src/winsup/cygwin ChangeLog miscfuncs.cc string.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-08-18 18:24:06 Modified files: winsup/cygwin : ChangeLog miscfuncs.cc string.h Log message: * miscfuncs.cc (strlwr): Rename from cygwin_strlwr. Drop __stdcall decoration. (strupr): Rename from cygwin_strupr. Drop __stdcall decoration. * string.h (strlwr): Remove override macro. Simply declare. (strupr): Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6494r2=1.6495 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/miscfuncs.cc.diff?cvsroot=srcr1=1.103r2=1.104 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/string.h.diff?cvsroot=srcr1=1.18r2=1.19
Re: cygwin now supports shared libraries?
Hi Gery, On Sat, Aug 16, 2014 at 1:12 PM, Gery . wrote: Hello, I though that Cygwin did not support shared libraries, I read it somewhere in the past, but now I am installing GEOS 3.4.2 (http://trac.osgeo.org/geos/) and I noticed this after the configure (it's just part of the long list of messages): checking whether the gcc linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe so, Cygwin now supports shared libraries or always did? sorry if this sounded like dumb, but as I said I understood that never did, moreover, the lack of /sbin/ldconfig should have supported my previous believes. The number of *.dll files in /bin should have convinced you otherwise :) 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 -- 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: Running a cygwin application on Windows
On Aug 16 08:57, Fernando Gont wrote: On 08/16/2014 06:49 AM, Corinna Vinschen wrote: On Aug 16 12:29, Achim Gratz wrote: Fernando Gont writes: My idea was to use cygwin, since I'm not much of a Windows programmer. Is there any way to produce and ship an exe with the relevant libraries? If I understand correctly what you're trying to do, you need to obtain a commercial license from RedHat for doing so. Otherwise, if you ship binaries linked against cygwin1.dll you need to also include all sources (for Cygwin and your own application) with each such shipment. You only need the buyout license if you want to provide binaries only. But this is a GPL'ed project, so I assume there's no desire to create binary-only packages. To be as honest and straightforward as possible :-): My goal is to provide as may options as possible. I will be producing a Cygwin package since that seems to be a fair way to contribute to this project. But I also want to address the user that just knows how to run commands from the windows command line and wants to quickly download install my toolkit to try it. -- hence my goal of also producing some sort of binary distribution (even if the binary package also includes the source). The binary package doesn't have to provide the sources, but your download site would have to provide the sources of the Cygwin DLL version you packed with your binary package. The problem is, a user with an existing Cygwin installation might run into trouble after installing your standalone package. A user installing Cygwin after installing your standalone package might run into trouble, too. Even though Cygwin tries its best to keep installations separate, this breaks if multiple Cygwin DLLs of different version numbers are in $PATH, or if the user tries to use Cygwin tools from different installation paths on the same command line. That's an unfortunate side-effect of Cygwin trying to emulate a bit of an OS :} So we'd like to ask you to install a Cygwin DLL only if there's no Cygwin installation present. Ideally you check if HKLM/Software/Cygwin/setup/rootdir or HKLM/Software/Cygwin/rhsetup/rootdir or, if it's a 32 bit installation on a 64 bit Windows HKLM/Software/Wow6432Node/Cygwin/setup/rootdir or HKLM/Software/Wow6432Node/Cygwin/rhsetup/rootdir exist and just install your tool into the Cygwin /bin path. Alternatively, if you find a Cygwin installation, you could just point the user to the cygwin distro to install from there. Both solutions don't fix the problems which might occur when installing Cygwin after installing your tool, but we might be lucky there ;) I'm in the process of reading the online information to produce the Cygwin package. Are there any pointers to get the other stuff done? other stuff? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNI4ipCxEZW.pgp Description: PGP signature
missing read-only files uuid and boot_id
Hi Cygwin team, to be more compatible to Linux environment, cygwin should provide 2 more virtual files: The read-only files uuid and boot_id contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9. The former is generated afresh for each read, the latter was generated once. they could be easy provided and filled using /dev/urandom Thanks, Alexander -- 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: missing read-only files uuid and boot_id
Greetings, Dr. Alexander Kleinsorge! to be more compatible to Linux environment, cygwin should provide 2 more virtual files: The read-only files uuid and boot_id contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9. The former is generated afresh for each read, the latter was generated once. What problem exactly you want to solve with this? Also, http://stackoverflow.com/questions/4313422/generate-guid-in-windows-with-batch-file they could be easy provided and filled using /dev/urandom That's not the right way to generate UUID. -- WBR, Andrey Repin (anrdae...@yandex.ru) 18.08.2014, 13:55 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: Bash uses lseek while reading from serial device
On Aug 17 15:19, Linda Walsh wrote: Being a bit of a busybody... I forwarded this to the bash list and chet responded there... so forwarding it back here... not sure what isatty is supposed to do with a serial line, let alone one on windows... On Linux isatty on a descriptor connected to serial line returns 0, on Cygwin it returned 1 so far. I fixed both problems here, isatty on a serial line returns 0 now, and lseek on serial (and, FWIW, sockets) don't simply return 0 anymore, but rather -1 with errno set to ESPIPE, as on Linux. These patches are available in the latest snapshot I just uploaded to https://cygwin.com/snapshots/ Ross, please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYLh2Q4JUsp.pgp Description: PGP signature
HEADSUP: OpenSSH 6.7 drops tcpwrapper support
Hi folks, Just a HEADSUP to all of you actively using the tcp_wrappers/libwrap functionality in sshd: Starting with the next OpenSSH version 6.7, which will be released soon, upstream removed support for tcp_wrappers/libwrap from the sources. While that's bad from a compatibility point of view, the upstream developers are adamant about this change for security reasons. So, if you configured /etc/hosts.allow and/or /etc/hosts.deny files in your Cygwin installation to block certain connections to your sshd service, you will have to find other means to do that ASAP: - Utilize the sshd_config Match rule. - Utilize your firewall. Hope that helps, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3D66qAzWLw.pgp Description: PGP signature
Re: (call-process ...) hangs in emacs
On 8/8/2014 9:26 AM, Ken Brown wrote: On 8/7/2014 5:42 PM, Eric Blake wrote: On 08/07/2014 12:53 PM, Ken Brown wrote: On 8/7/2014 11:30 AM, Eric Blake wrote: On 08/07/2014 05:51 AM, Ken Brown wrote: I think I found the problem with NORMAL mutexes. emacs calls pthread_atfork after initializing the mutexes, and the resulting 'prepare' handler locks the mutexes. (The parent and child handlers unlock them.) So when emacs calls fork, the mutexes are locked, and shortly thereafter the Cygwin DLL calls calloc, leading to a deadlock. Here's a gdb backtrace showing the sequence of calls: Arguably, that's an upstream bug in emacs. POSIX has declared pthread_atfork to be fundamentally useless; it is broken by design, because you cannot use it for anything that is not async-signal-safe without risking deadlock. And (except for sem_post()), NONE of the standardized locking functions are async-signal-safe. http://austingroupbugs.net/view.php?id=858 That said, it would still be nice to support this, since even though the theory says it is broken, there are still lots of (broken) programs/libraries still trying to use it. So what do you think emacs should do instead of using pthread_atfork? Or is it better to just remove it? I don't know how likely it is that this would cause a problem. The POSIX recommendation is that multithreaded apps limit themselves solely to async-signal-safe functions in the window between fork and exec (or to use pthread_spawn instead of fork/exec). I don't know what emacs is trying to do in that window, but at this point, it's certainly worth reporting it upstream. If you need a pointer to the full list of async-signal-safe functions: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04 and search for The following table defines a set of functions that shall be async-signal-safe. The most common deadlocks when violating async-signal-safety rules look like this in single-threaded programs: function calls malloc() malloc() grabs a non-recursive mutex async signal arrives signal handler called signal handler calls malloc() malloc() can't grab the mutex - deadlock and this counterpart in multithreaded programs: thread1 calls malloc() malloc() grabs a non-recursive mutex thread 2 gains control and calls fork() because of the fork, thread1 no longer exists to release the lock child process calls malloc() malloc() tries to grab mutex, but it is locked with no thread to release it Switching malloc() to a recursive lock may or may not solve the single-threaded deadlock (in that malloc can now obtain the mutex), but it is probably NOT what you want to happen (unless malloc is fully re-entrant, the inner instance will see incomplete data and either be totally clobbered itself, or else totally clobber the outer instance when it returns). So it's GOOD that malloc does NOT use a recursive mutex by default. In the multithreaded case, you are flat out hosed. Switching to a recursive lock does not change the picture - you are still deadlocked waiting on thread1 to release the lock, but thread1 doesn't exist. Thanks for the explanations, Eric. I've filed an emacs bug report: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18222 I've just made a new emacs test release that includes a workaround for this bug. I think I see a way to make emacs use Cygwin's malloc; if this works, it will provide a better fix for the bug. 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
[ANNOUNCEMENT] Updated: emacs-24.3.93-1 [TEST]
The following packages have been updated in the Cygwin distribution as test releases: *** emacs-24.3.93-1 *** emacs-X11-24.3.93-1 *** emacs-w32-24.3.93-1 *** emacs-el-24.3.93-1 Emacs is a powerful, customizable, self-documenting, modeless text editor. Emacs contains special code editing features, a scripting language (elisp), and the capability to read mail, news, and more without leaving the editor. This is another pretest of the upcoming emacs-24.4, replacing the current pretest (24.3.91-1). It includes a workaround for the bug reported in https://cygwin.com/ml/cygwin/2014-07/msg00387.html See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18222 for details. CYGWIN NOTES 1. The emacs, emacs-w32, and emacs-X11 packages each provide an emacs binary. These are emacs-nox.exe, emacs-w32.exe, and emacs-X11.exe, respectively, in order of increasing priority. The postinstall scripts use the `alternatives' system to create a symlink /usr/bin/emacs that resolves to the highest-priority binary that you have installed. Thus the command `emacs' will start emacs-X11.exe if you've installed the emacs-X11 package; otherwise, it will start emacs-w32.exe if you've installed emacs-w32; otherwise, it will start emacs-nox.exe. Similar remarks apply to emacsclient. If you have installed both emacs-w32 and emacs-X11 and prefer to give higher priority to emacs-w32, run the script /usr/bin/set-emacs-default-w32.sh You can later restore emacs-X11 as the default by running /usr/bin/set-emacs-default-X11.sh 2. Install emacs-X11 if you want to use the X11 GUI. You can then type `emacs' in an xterm window, and emacs will start in a new window. 3. Install emacs-w32 if you want to use the native Windows GUI instead of X11. 4. If you have sshd running and want to be able to run emacs-X11 from a remote machine, you need to enable X11 forwarding by adding the following line to /etc/sshd_config: X11Forwarding yes You might also need to have the cygserver service running. 5. The script /usr/bin/make-emacs-shortcut can be used to create a shortcut for starting emacs. See /usr/share/doc/emacs/README.Cygwin for details. Ken Brown Cygwin's emacs maintainer *** 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 the above 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: Cygwin installer hangs while downloading files
On Thu, Aug 7, 2014 at 8:32 AM, Michael DePaulo mikedep...@gmail.com wrote: HI, I'm having a weird issue with the Cygwin installer. It occurs whether I am using it to update my 2 installations of Cygwin (both 32-bit and 64-bit), or to perform a new install. The issue is that the installer hangs while downloading files. In other words, the progress bar makes 0% more progress at some point during a download. I've let the installer sit for over several hours without it making any progress. Sometimes it's setup.bz2. Usually it's one of the packages. On average, it happens on the 3rd file or so. Sometimes the 1st, sometimes the 6th, etc. It usually occurs in the middle of a file download, but sometimes at the beginning of the file download (when progress is 0%.) The UI is still responsive when this happens; so I can quit the installer. My Setup: 1. Windows 8.1 64-bit with the latest updates. 2. Joined to a domain. I Tried the following, but the issue still occurs: 1. Disabling my antivirus (NOD32 Antivirus 7) 2. Using both 32-bit and 64-bit Cygwin installer 3. Using the download path C:\Users\mike.DEPAULO\Downloads\cygtemp instead of the path on the U: network drive with spaces in it. 4. Selecting different mirrors. I also tried using another computer (Same OS, joined to the same domain, but different AV) and the issue did NOT occur. My workaround right now is just repeatedly run setup.exe -q and quitting the install whenever it does hang, until the entire download completes successfully. Once the entire download does complete, the packages install without any issue. -Mike The issue seems to be happening less frequently now. Today I downloaded about 60 packages and it only happened once. -- 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: Unable to get cygwin cron to work
-Original Message- From: cygwin-owne at cygwin.com on Behalf Of Denis Sent: Friday, August 15, 2014 21:39 I'm trying unsuccesfully to get cron to work under 64-bit cywin under Win7 Pro. First, I tried running as myself (running cygwin with system administrator privilege): $ cron-config Do you want to install the cron daemon as a service? (yes/no) yes Enter the value of CYGWIN for the daemon: [ ] Do you want the cron daemon to run as yourself? (yes/no) yes WARNING: User dkertz appears 2 times in /etc/passwd. This may confuse the system Edit /etc/passwd and assign unique user ids. snip From the above you can see the warning about my login appearing twice in /etc/passwd: $ grep dkertz /etc/passwd dkertz:unused:1003:513:dkertz,U-USNAVN0D011H46\dkertz, S-1-5-21-2470246883-414681431-158823764-1003:/home/dkertz:/bin/bash dkertz:unused:295587:10513:U-NA02\dkertz, S-1-5-21-2112754840-354624142-596004286- 285587:/home/dkertz:/bin/bash USNAVN0D011H46 is the PC machine name and NA02 is the domain set up by corporate IT. Does this suggest IT has messed up? I log into the PC using the na02\dkertz login. Thinking this login duplication might be the problem, I changed /etc/passwd to contain only the first login and then only the second login with the same results - logon failure when running cron-config. snip Now the cron runs but a scheduled cron job doesn't run and this is what the cronevents shows: 2014/08/15 19:41:01 [SYSTEM] /usr/sbin/cron: PID 4692: (dkertz) WRONG FILE OWNER (tabs/dkertz) There is no doubt that your problems are caused by the duplicate entry. There is no enough info to explain everything but note that according to http://cygwin.com/ml/cygwin/2014-02/msg00306.html when an entry can't be found in /etc/passwd it is now autogenerated. So I suggest that you try the following to sort things out better: - restore the original /etc/passwd with the 2 dkertz - manually edit /etc/passwd and rename one of them, for example one of them to NA02_dkertz - if you have renamed the dkertz you have login with, log out of Cygwin and start a new shell - make sure the crontab in /var/cron/tabs/ has the name of and is owned by the dkertz you want, and is readable by administrators - try starting cron again. If starting as yourself, make sure you are the one who owns the crontab. Sorry I can't help more, but I don' have a 64 bit system nor easy access to a domain account and I have not kept track with the way Cygwin maps user names. Pierre -- 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: Replicate packages from 32-bit machine on 64-bit machine
Eliot Moss moss at cs.umass.edu writes: On 8/17/2014 2:41 AM, paul wrote: When I wanted to replicate my cygwin installation from a 32-bit machine to another 32-bit machine, it was straightforward. I would simply reinstall all installed packages, but have the downloaded packages got to a folder which I then burn to CD. However, my next machine is a 64-bit machine. So I have to use the 64- bit setup. Is there an almost-as-painless way to replicate the 64-bit version of the packages that I have installed on my 32-bit machine? The 32-bit packages and set up run fine on a 64 bit processor. You just don't get as large a memory space for the programs when they are running. Yes, I was hoping to benefit from the 64-bit address space. But it took some trial and error to settle on the packages I wanted. Hoping I don't have to go through the same process again with the 64-bit packages. -- 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: Replicate packages from 32-bit machine on 64-bit machine
Andrey Repin anrdaemon at yandex.ru writes: When I wanted to replicate my cygwin installation from a 32-bit machine to another 32-bit machine, it was straightforward. I would simply reinstall all installed packages, but have the downloaded packages got to a folder which I then burn to CD. However, my next machine is a 64-bit machine. So I have to use the 64-bit setup. Is there an almost-as-painless way to replicate the 64-bit version of the packages that I have installed on my 32-bit machine? You contradicting yourself. 64-bit packages are entirely different files than 32-bit packages. Yes, I understand. I was referring to the 64-bit versions of my 32-bit packages. It took quite some period of discovery to determine my operational needs and the packages required. I'm hoping to avoid that re-experiencing that. Your only option is to download all of them. One way or another. OK. Also keep in mind that not all of packages are ported over to 64bit yet. Worse comes to worse, I'll simply install my 32-bit packages. As I said, the method of replicating the subset of packages that I already have is straightforward. If this may be an important factor in your decision to switch over to 64-bit installation, you'd have to do some investigation first. I.e. install 64-bit OS in virtual machine and try some things you normally do in your daily use. I'm migrating to a new machine. I'll just try the 64-bit for real on the new machine. If it doesn't work out, I always have a disc of my subset of 32-bit packages. 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: (call-process ...) hangs in emacs
On Mon, Aug 18, 2014 at 1:28 PM, Ken Brown kbr...@cornell.edu wrote: I've just made a new emacs test release that includes a workaround for this bug. I think I see a way to make emacs use Cygwin's malloc; if this works, it will provide a better fix for the bug. I'd like to give this a try. I've selected Exp mode in setup.exe but I don't see the latest version - do I need to do anything else or is it just a matter of waiting for the mirror to catch up (I am in the UK)? Pete -- 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: (call-process ...) hangs in emacs
On 08/18/2014 10:58 AM, Peter Hull wrote: On Mon, Aug 18, 2014 at 1:28 PM, Ken Brown kbr...@cornell.edu wrote: I've just made a new emacs test release that includes a workaround for this bug. I think I see a way to make emacs use Cygwin's malloc; if this works, it will provide a better fix for the bug. I'd like to give this a try. I've selected Exp mode in setup.exe but I don't see the latest version - do I need to do anything else or is it just a matter of waiting for the mirror to catch up (I am in the UK)? Probably the latter. If you don't want to wait, check out some other mirrors. -- Larry _ 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: Replicate packages from 32-bit machine on 64-bit machine
On 08/18/2014 10:30 AM, Paul wrote: Andrey Repin anrdaemon at yandex.ru writes: When I wanted to replicate my cygwin installation from a 32-bit machine to another 32-bit machine, it was straightforward. I would simply reinstall all installed packages, but have the downloaded packages got to a folder which I then burn to CD. However, my next machine is a 64-bit machine. So I have to use the 64-bit setup. Is there an almost-as-painless way to replicate the 64-bit version of the packages that I have installed on my 32-bit machine? You contradicting yourself. 64-bit packages are entirely different files than 32-bit packages. Yes, I understand. I was referring to the 64-bit versions of my 32-bit packages. It took quite some period of discovery to determine my operational needs and the packages required. I'm hoping to avoid that re-experiencing that. You shouldn't have allot of trouble matching the 64-bit version of any package with the 32-bit version. Assuming there is a 64-bit version of the package you want, package names are typically very similar between the two architectures. -- Larry _ 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
Problem with x86_64 2014-08-18 snapshot
ssh-add is not able to connect to the ssh-agent with the 2014-08-18 snapshot. This works fine with the 1.7.32-1 official release and with the 2014-08-07 snapshot. 508 ~ ssh-agent bash 499 ~ env | grep SSH SSH_AGENT_PID=7496 SSH_AUTH_SOCK=/tmp/ssh-CCN4vv8ePXKm/agent.7288 500 ~ ls -l /tmp/ssh-CCN4vv8ePXKm/agent.7288 srw--- 1 daver clearusers 0 Aug 18 10:15 /tmp/ssh-CCN4vv8ePXKm/agent.7288 501 ~ ps -ef | grep 7496 daver74967288 ?10:15:02 /usr/bin/ssh-agent 502 ~ ssh-add ~/.ssh/id_rsa Could not open a connection to your authentication agent. Please let me know if you need additional information to reproduce this. -- David Rothenberger daver...@acm.org Intelligence without character is a dangerous thing. -- G. Steinem -- 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
Windows Server 2012R2 64bit and 32bit Cygwin sshd
I'm not making progress on this, but I've come to the conclusion that it is highly unlikely that the existence of the second (64bit) Cygwin installation has anything to do with the problem, first reported here: http://thread.gmane.org/gmane.os.cygwin/147823 Meanwhile I've tried to make sure that the two installations don't interact by creating a separate privileged user for both of them, but that's not made a difference. So let me re-phrase the question, given: - Windows Server 2012R2 64bit running on hardware - Cygwin 32bit (latest snapshot from 2014-08-18 w/ AD integration) can anybody confirm they have gotten sshd successfully running? As far as I can debug this, the sshd I have installed goes through all the motions of checking and setting up the environment, but any process it then spawns to actually run my command or shell immediately exits. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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 now supports shared libraries?
On 8/16/2014 05:12, Gery . wrote: so, Cygwin now supports shared libraries or always did? Cygwin's binutils could link to DLLs (shared libraries) from the beginning, if only because Windows' own APIs are all DLL-based. I did a fair bit of Googling to try and find out when gcc -shared started working, but couldn't find a reference. I'd guess it was pretty early on, since I can't remember a time when Cygwin couldn't create DLLs. (I've been using Cygwin since B18, the first packaged release.) There have been occasional problems. For instance, I seem to recall a problem where C++ library DLLs failed when thrown exceptions crossed the DLL boundary, many years ago. While that problem existed, the standard recommendation was to build affected libraries statically, since they wouldn't work right otherwise. But, that's very much not the same thing as Cygwin cannot create DLLs. -- 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: missing read-only files uuid and boot_id
On 08/18/2014 03:46 AM, Dr. Alexander Kleinsorge wrote: Hi Cygwin team, to be more compatible to Linux environment, cygwin should provide 2 more virtual files: The read-only files uuid and boot_id contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9. The former is generated afresh for each read, the latter was generated once. they could be easy provided and filled using /dev/urandom It's only random if the BIOS does not have a known string. In the case of Windows, I highly suspect that we are likely to be able to find a known UUID that we should use instead of a random number. Especially since on Linux, the uuid file matches what dmidecode says was reported by BIOS, and there has been a lot of care taken into providing persistent uuid information to virtual machines precisely because Windows is so picky about hardware validation (the machine uuid reported by BIOS is one of the pieces of information Windows uses to tell if it has been installed on new hardware). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[ANNOUNCEMENT] New package: onc-rpc-devel-2.19_20140816-1
Version 2.19_20140816-1 of onc-rpc-devel has been uploaded. This package is necessary for building applications using Sun (now ONC) RPC protocol. It contains headers for some standard RPC services (like NFS) and rpcgen utility needed to generate such headers for custom services, thus obsoleting rpcgen package which was never included in x86-64 Cygwin. This package is currently available only for x84-64 in order not to break dependencies of existing 32-bit NFSv2 server. A work on other components of NFS stack is in (slow) progress. i386 version will be available when the whole NFS stack is updated and ported to TI-RPC. Changes in this version: - Added rpcsvc/yp.h include, needed by rpcbind - Fixed small bug in the makefile: if you run 'make' inside already built source tree, genrpc will refuse to overwrite already existing headers and produce error - Added missing 'OBSOLETES=rpcgen' to the .cygport file - EGlibc SVN snapshot updated to 16.08.2014 *** 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.com at 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. -- Kind regards, Pavel -- 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: Bash uses lseek while reading from serial device
Corinna Vinschen writes: On Linux isatty on a descriptor connected to serial line returns 0, on Cygwin it returned 1 so far. I fixed both problems here, isatty on a serial line returns 0 now, and lseek on serial (and, FWIW, sockets) don't simply return 0 anymore, but rather -1 with errno set to ESPIPE, as on Linux. I'm not sure if Chet Ramey's suggestion that if isatty() returns 1 then bash is allowed to assume reads are newline-delimited is correct. On Unix this would only be true if cannonical mode input processing was enabled (icanon), and Cygwin stty reports that this mode is disabled (-icanon) on serial devices. Or at least it used to, with the snapshot DLL it now complains /dev/ttyS0: Inappropriate ioctl for device. For what its worth my tests on Linux shows that isatty() returns 1 on a serial device, namely /dev/ttyS0. Which is what I would expect given that serial devices have traditionally been synonymous with ttys on Unix. Ross, please give it a try. The snapshot DLL solves the bug and the script runs without any data being lost. Thanks for looking into this. Ross Ridge -- 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: onc-rpc-devel-2.19_20140816-1
Version 2.19_20140816-1 of onc-rpc-devel has been uploaded. This package is necessary for building applications using Sun (now ONC) RPC protocol. It contains headers for some standard RPC services (like NFS) and rpcgen utility needed to generate such headers for custom services, thus obsoleting rpcgen package which was never included in x86-64 Cygwin. This package is currently available only for x84-64 in order not to break dependencies of existing 32-bit NFSv2 server. A work on other components of NFS stack is in (slow) progress. i386 version will be available when the whole NFS stack is updated and ported to TI-RPC. Changes in this version: - Added rpcsvc/yp.h include, needed by rpcbind - Fixed small bug in the makefile: if you run 'make' inside already built source tree, genrpc will refuse to overwrite already existing headers and produce error - Added missing 'OBSOLETES=rpcgen' to the .cygport file - EGlibc SVN snapshot updated to 16.08.2014 *** 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.com at 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. -- Kind regards, Pavel
