Obsoletion procedures?
Three of my library packages are going to be becoming obsolete in the medium-term future. libapr0 and libaprutil0 and their development packages apr and apr-util are already used only by [prev] software. libneon24 is used solely by [curr] cadaver, and [prev] subversion. I'm soliciting opinions on how long library packages should remain after they no longer are required by any other software in the distro. Max. signature.asc Description: OpenPGP digital signature
cadaver: rebuild request
cadaver is now the sole package whose [curr] version depends on libneon24. Please could it be rebuilt against neon 0.25.x, which will entail bumping the dependency to libneon25. Thanks! Max. signature.asc Description: OpenPGP digital signature
Re: Obsoletion procedures?
On Sun, Jun 11, 2006 at 03:52:26PM +0100, Max Bowsher wrote: Three of my library packages are going to be becoming obsolete in the medium-term future. libapr0 and libaprutil0 and their development packages apr and apr-util are already used only by [prev] software. libneon24 is used solely by [curr] cadaver, and [prev] subversion. I'm soliciting opinions on how long library packages should remain after they no longer are required by any other software in the distro. I don't think any opinions are required. We have a procedure for this. The package move into the _obsolete category/_obsolete directory, and the latest package becomes an empty .tar.bz2 file. I don't see any reason to remove packages from the _obsolete category once they are put there. cgf
RE: cadaver: rebuild request
Max Bowsher wrote on Sunday, June 11, 2006 4:55 PM: cadaver is now the sole package whose [curr] version depends on libneon24. Please could it be rebuilt against neon 0.25.x, which will entail bumping the dependency to libneon25. Thanks! Hehe, maintainer will have to wait for 1.5.20 to build an official release: === snip = $ make gcc -DHAVE_CONFIG_H -I. -I./lib -DLOCALEDIR=\/usr/local/bin/share/locale\ -I./src -g -O2 -I/usr/include/neon -o src/cmdline.o -c src/cmdline.c src/cmdline.c: In function `davglob_readdir': src/cmdline.c:220: error: structure has no member named `d_ino' make: *** [src/cmdline.o] Error 1 === snip = - Jörg
Re: STARTXWIN.BAT Hanging Under Win2KPro
Lionel B [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] had the same thing (also Win2K Pro). On failure to start, XWin.log revealed the following (which was not present on a successful restart): (EE) Couldn't load XKB keymap, falling back to pre-XKB keymap Identical error... Googling turned up the following: http://www.cygwin.com/ml/cygwin-xfree/2005-08/msg00072.html Reading to the bottom, the fix suggested is to copy the directory /etc/X11/xkb to /usr/X11R6/lib/X11/xkb. This does appear to solve the problem in my case. ...unfortunately, it did not on mine. Thanks for the tip tho. I note that on my setup /usr/X11R6/lib/X11/xkb would normally be just a soft link to /etc/X11/xkb ... Ditto mine. --- Douglas J. Renze [EMAIL PROTECTED] -- 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: STARTXWIN.BAT Hanging Under Win2KPro
Charli Li [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have W2K Professional, and it works just fine. You may want to edit the startxwin.bat file to fit your needs. (Rightclick startxwin.bat edit) For your convenience, I wrote up this seperate little batch script (run under cmd or standalone): [snip] Thanks for the tip, unfortunately, didn't do the trick for me. I'm still trying to figger this'n out... --- Douglas J. Renze [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/w32api ChangeLog include/imagehlp.h ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-06-12 00:55:06 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: imagehlp.h rpcdce.h rpcnsi.h rpcnsip.h windef.h winsup/w32api/include/ddk: batclass.h cfgmgr32.h ddkmapi.h hidclass.h hidpi.h kbdmou.h mcd.h miniport.h minitape.h ndis.h ndistapi.h ndiswan.h newdev.h ntapi.h ntdd8042.h ntddpcm.h ntifs.h ntpoapi.h parallel.h pfhook.h scsiwmi.h smbus.h srb.h storport.h tdikrnl.h upssvc.h usbcamdi.h usbscan.h video.h videoagp.h win2k.h winddi.h winddk.h winnt4.h ws2san.h Log message: [mingw-Bugs-1424461] *include/imagehlp.h: Comment out IN, OUT and OPTIONAL, throughout. *include/rpcdce.h: Don't define IN, OUT or OPTIONAL if _NO_W32_PSEUDO_MODIFIERS. *include/rpcnsi.h: Comment out IN, OUT and OPTIONAL, throughout. *include/rpcnsip.h: Likewise. *include/windef.h: Don't define IN, OUT or OPTIONAL if _NO_W32_PSEUDO_MODIFIERS. *include/ddk/batclass.h: Comment out IN, OUT and OPTIONAL, throughout. *include/ddk/cfgmgr32.h: Likewise. *include/ddk/ddkmapi.h: Likewise. *include/ddk/hidclass.h: Likewise. *include/ddk/hidpi.h: Likewise. *include/ddk/kbdmou.h: Likewise. *include/ddk/mcd.h: Likewise. *include/ddk/miniport.h: Likewise. *include/ddk/minitape.h: Likewise. *include/ddk/ndis.h: Likewise. *include/ddk/ndistapi.h: Likewise. *include/ddk/ndiswan.h: Likewise. *include/ddk/ntapi.h: Likewise. *include/ddk/ntdd8042.h: Likewise. *include/ddk/ntddpcm.h: Likewise. *include/ddk/ntifs.h: Likewise. *include/ddk/ntpoapi.h: Likewise. *include/ddk/parallel.h: Likewise. *include/ddk/pfhook.h: Likewise. *include/ddk/scsiwmi.h: Likewise. *include/ddk/smbus.h: Likewise. *include/ddk/srb.h: Likewise. *include/ddk/storport.h: Likewise. *include/ddk/tdikrnl.h: Likewise. *include/ddk/upssvc.h: Likewise. *include/ddk/usbcamdi.h: Likewise. *include/ddk/usbscan.h: Likewise. *include/ddk/video.h: Likewise. *include/ddk/videoagp.h: Likewise. *include/ddk/win2k.h: Likewise. *include/ddk/winddi.h: Likewise. *include/ddk/winddk.h: Don't define IN, OUT or OPTIONAL if _NO_W32_PSEUDO_MODIFIERS. Comment out IN, OUT and OPTIONAL, throughout. *include/ddk/winnt4.h: Comment out IN, OUT and OPTIONAL, throughout. *include/ddk/ws2san.h: Likewise. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.852r2=1.853 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/imagehlp.h.diff?cvsroot=srcr1=1.2r2=1.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/rpcdce.h.diff?cvsroot=srcr1=1.8r2=1.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/rpcnsi.h.diff?cvsroot=srcr1=1.2r2=1.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/rpcnsip.h.diff?cvsroot=srcr1=1.3r2=1.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/windef.h.diff?cvsroot=srcr1=1.17r2=1.18 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/batclass.h.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/cfgmgr32.h.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/ddkmapi.h.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/hidclass.h.diff?cvsroot=srcr1=1.4r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/hidpi.h.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/kbdmou.h.diff?cvsroot=srcr1=1.1r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/mcd.h.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/miniport.h.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/minitape.h.diff?cvsroot=srcr1=1.4r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/ndis.h.diff?cvsroot=srcr1=1.9r2=1.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/ndistapi.h.diff?cvsroot=srcr1=1.4r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ddk/ndiswan.h.diff?cvsroot=srcr1=1.5r2=1.6
mount never fails ... sorta
Give mount(1) nonexistent hosts or directories and it will complain, but it still populates the mount table as if it succeeded. It also always returns zero, for success or failure. Richard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
rxvt usage issues under windows xp
Hello, I've switched time ago from the standard cygwin.bat (cmd.exe) window, to rxvt. It's miles away from the m$ command line, but I still have some issue. First of all, here is my launch command taken from the web with some tweaks: C:\cygwin\bin\rxvt.exe -bg black -fg white -si +sk -sw -sr -sl 65535 -fn Courier New-23-bold -ls -e /usr/bin/bash --login -rcfile ~/.profile And in my .bashrc I have: ... export CYGWIN=codepage:oem tty binmode title export TERM=rxvt-cygwin-native ... Now the issues: #1 A-I want to scroll back manually, without resetting position, event if there is something scrolling on the screen. So I have setup -si -sw. B-But I want to go on the prompt line on key press. So I have setup +sk. A is working fine, B not. Why ? #2 I used Windows Courier-New font, because it correctly show up character (for example, midnight commander) in other applications, like Putty. In rxvt, it doesen't work well. I've tried Lucida Console too, but the result was the same. Why ? Thanks for suggestions, -- Diesis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's (was Re: unix 'at' command implementation)
Larry Hall (Cygwin) wrote: Linda Walsh wrote: Eric Blake wrote: I have cygwin install but I can not find the implementation of Unix 'at' command. Because no one has ported an open source version of it to cygwin yet. Some packages might be more easily ported if RPM's became a common way to package cygwin packages. Much of the porting effort is in converting to the cygwin installer. Someone asked about logrotation a while back and I was surprised no one had ported a logrotate package. I pulled the source RPM from my SuSE distro, and was able to produce a binary RPM in about 10 minutes, then I realized RPM's weren't a desirable format for cygwin packages. I'm sure there's some good reason for converting all packages to yet another installer, but I'm not sure I know what they are. One side effect, though -- it can put a damper on porting programs over when most (or all) of the work is in converting to the a different installer. Support for RPM and DEB packages were always intended for setup.exe. It's just no one has added this support yet. Anyone who's interested is certainly welcome to provide patches to reach this goal. I'm sure they will be thoughtfully considered. I've entertained fantasies of making integrating dpkg into setup.exe, and making Cygwin packages be in .deb format. It's a pretty huge undertaking though, and somehow I can't see myself getting around to it any time soon. Max. signature.asc Description: OpenPGP digital signature
Re: RPM's (was Re: unix 'at' command implementation)
Max Bowsher wrote I've entertained fantasies of making integrating dpkg into setup.exe, and making Cygwin packages be in .deb format I'll certainly love .deb packages, surely apt support. Cygwin is command-line, so it would be nice to ssh remotely in a machine, run apt-get update apt-get upgrade to mantain the Cygwin system -- Diesis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount never fails ... sorta
Richard Foulk wrote: Give mount(1) nonexistent hosts or directories and it will complain, but it still populates the mount table as if it succeeded. It also always returns zero, for success or failure. Cygwin's mount is a different bird than on Unix. It really is just a mapping table of POSIX names to DOS or UNC-style paths. It is not required that the POSIX path exist for things to work. But since most people coming from a UNIX background expect that it does and it certainly helps things like shell path completion if the paths do already exist, you get a warning to let you know about this difference. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's (was Re: unix 'at' command implementation)
On Sat, 10 Jun 2006, Linda Walsh wrote: Eric Blake wrote: I have cygwin install but I can not find the implementation of Unix 'at' command. Because no one has ported an open source version of it to cygwin yet. Some packages might be more easily ported if RPM's became a common way to package cygwin packages. Much of the porting effort is in converting to the cygwin installer. Someone asked about logrotation a while back and I was surprised no one had ported a logrotate package. I pulled the source RPM from my SuSE distro, and was able to produce a binary RPM in about 10 minutes, then I realized RPM's weren't a desirable format for cygwin packages. Do you mean that you used Cygwin's rpm package to produce that RPM? I'm sure there's some good reason for converting all packages to yet another installer, but I'm not sure I know what they are. One side effect, though -- it can put a damper on porting programs over when most (or all) of the work is in converting to the a different installer. Technically, nothing prevents you from shipping a Cygwin package (which is just a .tar.bz2) that contains only the Cygwin binary RPM and the postinstall script that invokes rpm to unpack that binary RPM (as long as that package also requires: the rpm package). You'll also need to build a manifest of all extracted files and have a preremove script that cleans those up. See the gcc-mingw-core package for an example of a similar approach. What you will lose with the above is the ability to list and search package contents via cygcheck and the online package search. Incidentally, one of the things we should teach setup and cygcheck to do is look at the manifest files produced by postinstall scripts and include those in the file lists of the package. I'm sure it would be easier to do than add full dpkg or rpm support to setup.exe, and would be a good way to familiarize yourself with the code of setup/cygcheck. As usual, PTC. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rxvt usage issues under windows xp
On Sun, 11 Jun 2006, gabriele.mailing wrote: Hello, I've switched time ago from the standard cygwin.bat (cmd.exe) window, to rxvt. It's miles away from the m$ command line, but I still have some issue. First of all, here is my launch command taken from the web with some tweaks: C:\cygwin\bin\rxvt.exe -bg black -fg white -si +sk -sw -sr -sl 65535 -fn Courier New-23-bold -ls -e /usr/bin/bash --login -rcfile ~/.profile And in my .bashrc I have: ... export CYGWIN=codepage:oem tty binmode title First, codepage:oem, tty, and title only make sense for the Cygwin console. You don't need them for rxvt at all. Second, tty should be set before the first Cygwin process is ever invoked -- setting it in .bashrc is way too late. If you want the setting to be available to all processes, set CYGWIN in the global system environment instead. export TERM=rxvt-cygwin-native And this is another problem -- this will bite you when you try using ssh. Rxvt already sets the TERM to xterm by default, and will set it to whatever you want with the -tn command-line option. I suggest adding -tn rxvt-cygwin-native to your rxvt command line instead of the above .bashrc line. ... Now the issues: #1 A-I want to scroll back manually, without resetting position, event if there is something scrolling on the screen. So I have setup -si -sw. B-But I want to go on the prompt line on key press. So I have setup +sk. A is working fine, B not. Why ? Because you've misread the manpage. +sk turns OFF scroll-on-keypress. You want -sk instead. This is not Cygwin-specific. #2 I used Windows Courier-New font, because it correctly show up character (for example, midnight commander) in other applications, like Putty. In rxvt, it doesen't work well. I've tried Lucida Console too, but the result was the same. Why ? It's a Windows codepage issue. rxvt uses the system-default codepage. You'll probably need a customized font with the right characters in the right places... HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: swig-1.3.29-1
SWIG, the Simplified Wrapper and Interface Generator, is a tool for easing the interfacing of C/C++ libraries to scripting languages. Its package in the Cygwin net distribution has been updated to version 1.3.29-2. This is a Cygwin-local bugfix release, to fix the omission of the file /usr/share/swig/1.3.29/swigwarn.swg from 1.3.29-1. Max Bowsher. signature.asc Description: OpenPGP digital signature
Re: RPM's (was Re: unix 'at' command implementation)
On Sun, Jun 11, 2006 at 06:38:49PM +0200, [EMAIL PROTECTED] wrote: Max Bowsher wrote I've entertained fantasies of making integrating dpkg into setup.exe, and making Cygwin packages be in .deb format I'll certainly love .deb packages, surely apt support. Cygwin is command-line, so it would be nice to ssh remotely in a machine, run apt-get update apt-get upgrade to mantain the Cygwin system That's precisely why people think about integrating something like rpm or deb into the packaging system. However, the funny thing about free software is that no matter how much people want this type of thing it still requires someone to do the actual work. I would hate to see this thread become a wish-fest when there is obviously no one interested in doing this work. That would be a waste of good electrons. I will point out that there is no mystery to the format of cygwin packages. They are just .tar.bz2 files and they are *MUCH* simpler than rpm or deb files (and I am intimately acquainted with all three formats, thanks). It is not that hard to extract .tar.bz2 files and install them except for the chicken/egg problem of installing packages that are used to install packages. That is a basic problem with rpm and deb too. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's (was Re: unix 'at' command implementation)
On Sun, Jun 11, 2006 at 02:04:11PM -0400, Igor Peshansky wrote: Technically, nothing prevents you from shipping a Cygwin package (which is just a .tar.bz2) that contains only the Cygwin binary RPM and the postinstall script that invokes rpm to unpack that binary RPM (as long as that package also requires: the rpm package). You'll also need to build a manifest of all extracted files and have a preremove script that cleans those up. See the gcc-mingw-core package for an example of a similar approach. Nothing would stop anyone from using rpm to build a package and then using rpm2tar to convert the rpm to a .tar.bz2 file either. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount never fails ... sorta
On Sun, Jun 11, 2006 at 02:34:53AM -1000, Richard Foulk wrote: Give mount(1) nonexistent hosts or directories and it will complain, but it still populates the mount table as if it succeeded. It also always returns zero, for success or failure. Correct. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gpg-agent: only one trouble before succesfull building
Renè, thank you for your suggestions. I built pth-2.0.6. It worked fine, but I had to add -I/usr/local/include . if you try by hand the correct command it will work: gcc -g -O2 -Wall -o gpg-connect-agent.exe gpg-connect-agent.o no-libgcrypt.o ../jnlib/libjnlib.a ../common/libcommon.a ../gl/libgnu.a -lassuan -lpth -lgpg-error -lintl -lz The only difference is -lpth which is the output of /usr/bin/pth-config --libs (or in your case /usr/local/bin/...). So after the error, I made: cd tools gcc -I/usr/local/include -g -O2 -Wall -o gpg-connect-agent.exe gpg-connect-agent.o no-libgcrypt.o ../jnlib/libjnlib.a ../common/libcommon.a ../gl/libgnu.a -L/usr/local/lib -lassuan -lgpg-error -lintl -lz -lpth cd .. make And the gpg-agent built good. So the problem was really an error on the generated Makefile, you should report it to gnupg. I'll do. After building, I tried gpg-agent: $ cd /usr/src/gnupg-1.9.20/agent $ eval $(./gpg-agent --daemon) Checked to be sure it is active: $ ps -a | grep gpg-agent 3012 13012 3012? 1005 16:52:40 /usr/src/gnupg-1.9.20/agent/gpg-agent Checked that the environment is good: $ set | grep GPG_AGENT GPG_AGENT_INFO=/tmp/gpg-ptlT3p/S.gpg-agent:3012: Checked that the socket is present: $ ls /tmp/gpg-ptlT3p/ total 1 drwx--+ 2 mnt.vvngrl Nessuno 0 Jun 11 16:52 . drwxrwxrwt+ 6 mnt.vvngrl Users0 Jun 11 16:52 .. srwxr-xr-x 1 mnt.vvngrl Nessuno 53 Jun 11 16:52 S.gpg-agent So, to be sure to use official cygwin gpg: $ gpg --version gpg (GnuPG) 1.4.2.1 Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Ok, let's do litte test: $ echo test | gpg -ase -r 0xEFF5860B | gpg gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information You need a passphrase to unlock the secret key for user: Gabriele Vivinetto [EMAIL PROTECTED] 1024-bit DSA key, ID E8FC81D7, created 2005-08-31 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: problem with the agent - disabling agent use Enter passphrase: Oh no... *gpg: problem with the agent - disabling agent use* May be official cygwin gpg lacks agent support ? How do I see if the gpg executable is compiled with agent support ? Ah, yes, I've tried the test, but another run of the test requested me the password again. P.S. tried to build pinentry too, installed and run eval $(gpg-agent --daemon --pinentry-program /usr/local/bin/pinentry) but same failure... -- Diesis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin Dimmension
Can anyone tell me how to increase the dimensions of the cygwin window? I would like it to come up as a full screen window. Thanks, -Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's require to much knowledge of setup to port easily
Igor Peshansky wrote: Do you mean that you used Cygwin's rpm package to produce that RPM? yes. I'm sure there's some good reason for converting all packages to yet another installer, but I'm not sure I know what they are. One side effect, though -- it can put a damper on porting programs over when most (or all) of the work is in converting to the a different installer. Technically, nothing prevents you from shipping a Cygwin package (which is just a .tar.bz2) that contains only the Cygwin binary RPM and the postinstall script that invokes rpm to unpack that binary RPM (as long as that package also requires: the rpm package). You'll also need to build a manifest of all extracted files and have a preremove script that cleans those up. See the gcc-mingw-core package for an example of a similar approach. --- I wasn't thinking so much for my own devious purposes, but if someone wanted logrotate, I could have spoke up on the list and announced it...but if it isn't in some common cygwin-ish location, rpm packages will be pretty random. What you will lose with the above is the ability to list and search package contents via cygcheck and the online package search. --- I also miss the ability to do an rpm -qi packagename, or rpm -qf file, or to find a version rpm -q package. One problem of producing useful RPM's is that non of the base files (if/then...cp, gzip) are installed in the RPM database, so it's impossible to setup real prereqs. Incidentally, one of the things we should teach setup and cygcheck to do is look at the manifest files produced by postinstall scripts and include those in the file lists of the package. I'm sure it would be easier to do than add full dpkg or rpm support to setup.exe, and would be a good way to familiarize yourself with the code of setup/cygcheck. As usual, PTC. --- Thanks...but here again, we've come full circle. I have an existing cygwin RPM, but to make it available to the masses, (as much as any other setup-based program), I have to not only learn the setup format, but the structure of the source code itself. I'd say that's a barrier to people providing ports. Unfortunately, I have a less than ideal Win development setup. It can do small things, but with a Mobile-P-III on a 5-6 YO laptop, we aren't talking hyper speed or resources. I've, moreo than once tried to setup a development env for cygwin setup and the cygwin dll, with an emphasis on a cross-compile from linux, since I also have access to a slightly faster linux machine, but it's as old as the laptop, it's only faster because it was a workstation model when it was new. Every time I've tried to setup an environment, I run into items I don't have in my environment that the instructions somehow assumed were there. I fix one thing, and another pops to the top of the list to block progress. I lose interest. Due to various reasons, my development cycle(s) are slower than they used to be, and are also limited in time (correctable, _maybe_, with spinal surgery...something I'm not wanting to rush into). It puts a kink in some of my more favorite activities. Regardless of my specific circumstance, it still seems there is a lot of work to be done before RPM's could be distributed as part of cygwin. I still don't get all the reasons behind forcing everyone into a new format. Is it just a power trip or what? The issue of active files not being over-writeable, could be handled transparently by the cygwin layer, from what I can tell. At least on NT based systems (haven't tried it under Win9x type systems), a delete of an active file, instead of failing could rename the active file to a suitably cryptic nanem .deletedfile###, and the delete commands could be entered into OS's pending fileops for when the user next reboots. What other reasons would we have for not using RPM? -l -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Dimmension
Can anyone tell me how to increase the dimensions of the cygwin window? I would like it to come up as a full screen window. This is more of a Windows question. Right click on the top of the window and look in the properties. Brett -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's (was Re: unix 'at' command implementation)
Christopher Faylor wrote That's precisely why people think about integrating something like rpm or deb into the packaging system. May be someone has found the right way: cyg-apt. It is in an early stage, does not handle 'in-use' file substitution, but for simple update-upgrade, it works. I'm not saying that tar.bz2 is not a good packaging format, but only point out that now there is no CLI alternative to setup.exe. Administering a Cygwin environment from the command line is better in IMHO. I would hate to see this thread become a wish-fest when there is obviously no one interested in doing this work. My skills are too low to start and finish such a project. I'm not a coder, I'm a SysAdmin... -- Diesis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rxvt usage issues under windows xp
Igor, thank you for your reply. Igor Peshansky wrote export CYGWIN=codepage:oem tty binmode title set CYGWIN in the global system environment instead. Ok, I've set it in the main windows environment. Now from CDM.EXE prompt, CYGWIN is already set. export TERM=rxvt-cygwin-native And this is another problem -- this will bite you when you try using ssh. ...I suggest adding -tn rxvt-cygwin-native to your rxvt command line instead of the above .bashrc line. Ok, done this. Never had problems, because I haven't do any ssh to my machine since I've switched to rxvt. Because you've misread the manpage. +sk turns OFF scroll-on-keypress. You want -sk instead. This is not Cygwin-specific. That's my fault !!! Now it's working perfectly :D It's a Windows codepage issue. rxvt uses the system-default codepage. You'll probably need a customized font with the right characters in the right places... Oh yeah, I've red /usr/share/doc/Cygwin/rxvt-20050409.README and found mention about the font Lucida ConsoleP. I've downloaded from http://home.online.no/~aageli/luconP.ttf, installed in Windows, and run a shortcut with: C:\cygwin\bin\rxvt.exe -bg black -fg white -si -sk -sw -sr -sl 65535 -tn rxvt-cygwin-native -fn Lucida ConsoleP-22 -ls -e /usr/bin/bash --login -rcfile ~/.profile Now mc is correctly displayed, but pstree -p is not drawen correctly (nor it was before) !!! -- Diesis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's require to much knowledge of setup to port easily
On Sun, Jun 11, 2006 at 12:49:30PM -0700, Linda Walsh wrote: Igor Peshansky wrote: Do you mean that you used Cygwin's rpm package to produce that RPM? yes. I'm sure there's some good reason for converting all packages to yet another installer, but I'm not sure I know what they are. One side effect, though -- it can put a damper on porting programs over when most (or all) of the work is in converting to the a different installer. Technically, nothing prevents you from shipping a Cygwin package (which is just a .tar.bz2) that contains only the Cygwin binary RPM and the postinstall script that invokes rpm to unpack that binary RPM (as long as that package also requires: the rpm package). You'll also need to build a manifest of all extracted files and have a preremove script that cleans those up. See the gcc-mingw-core package for an example of a similar approach. --- I wasn't thinking so much for my own devious purposes, but if someone wanted logrotate, I could have spoke up on the list and announced it...but if it isn't in some common cygwin-ish location, rpm packages will be pretty random. What you will lose with the above is the ability to list and search package contents via cygcheck and the online package search. I also miss the ability to do an rpm -qi packagename, or rpm -qf file, or to find a version rpm -q package. One problem of producing useful RPM's is that non of the base files (if/then...cp, gzip) are installed in the RPM database, so it's impossible to setup real prereqs. There is no one-to-one equivalent to rpm -qi but rpm -qf is equivalent to cygcheck -f and cygcheck -c packagename will give you the package name and version. Incidentally, one of the things we should teach setup and cygcheck to do is look at the manifest files produced by postinstall scripts and include those in the file lists of the package. I'm sure it would be easier to do than add full dpkg or rpm support to setup.exe, and would be a good way to familiarize yourself with the code of setup/cygcheck. As usual, PTC. Thanks...but here again, we've come full circle. I have an existing cygwin RPM, but to make it available to the masses, (as much as any other setup-based program), I have to not only learn the setup format, but the structure of the source code itself. I'd say that's a barrier to people providing ports. It's not clear that you really understand that 1) cygwin packages are just tar files and 2) there is already a way to do some of the things that you have mentioned. I wouldn't mind moving to a more accepted packaging format but I don't think that doing so would make people more inclined to contribute packages. A setup.hint file is much simpler than an rpm spec file so, unless you actually already understand rpm spec files, moving to rpm could actually add an additional burden to package submission. I still don't get all the reasons behind forcing everyone into a new format. Is it just a power trip or what? Actually, the new (i.e., five+ year old) format was imposed on us by the Trilateral Commission. It was one of several initiaitves intended to draw focus from the Y2K election fixing and the Hollywood-staged moon landing. I probably shouldn't divulge this, but this was a joint directive signed by both Elvis Presley and Henry Kissinger. So, as you can see, we really had no choice in the matter. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's (was Re: unix 'at' command implementation)
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
setup.exe
Cygwin-X is a liberating tool. Is there a way to use setup.exe remotely, via X, so it fits into the larger scheme of things? Or is there some other tool that does the same thing via X or command line? Thanks Richard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount never fails ... sorta
Richard Foulk wrote: Give mount(1) nonexistent hosts or directories and it will complain, but it still populates the mount table as if it succeeded. It also always returns zero, for success or failure. Cygwin's mount is a different bird than on Unix. It really is just a mapping table of POSIX names to DOS or UNC-style paths. It is not required that the POSIX path exist for things to work. But since most people coming from a UNIX background expect that it does and it certainly helps things like shell path completion if the paths do already exist, you get a warning to let you know about this difference. I guess I should have said mount's behavior is wrong and broken. It knows when there's an error it just does the wrong things. 1. mount reports the error to stderr, but not via the return code. 2. mount knows about the error but signals success anyway -- by listing a (non-existent) mount within the mount table. Sure Cygwin's mount is different than Unix's. That's what Cygwin is all about, hiding those differences. Cygwin's mount fails at that. Registering a mount that doesn't exist is quite broken. Richard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount never fails ... sorta
Richard Foulk wrote: Richard Foulk wrote: Give mount(1) nonexistent hosts or directories and it will complain, but it still populates the mount table as if it succeeded. It also always returns zero, for success or failure. Cygwin's mount is a different bird than on Unix. It really is just a mapping table of POSIX names to DOS or UNC-style paths. It is not required that the POSIX path exist for things to work. But since most people coming from a UNIX background expect that it does and it certainly helps things like shell path completion if the paths do already exist, you get a warning to let you know about this difference. I guess I should have said mount's behavior is wrong and broken. It knows when there's an error it just does the wrong things. 1. mount reports the error to stderr, but not via the return code. Well, if you feel strongly about this, then PTC. If there's going to be much worthwhile debate on this issue, giving the specifics of your proposal via a patch makes it easy for people to provide specific feedback. 2. mount knows about the error but signals success anyway -- by listing a (non-existent) mount within the mount table. You say error now. Before you called it as it's reported, a warning. Seems you're escalating things here without much cause. 'mount' lists the entry in the mount table because it is not *required* that the target or the source exist at the time the entry is created for the mount point to be valid. The target *never* has to exist in the file system for the mount point to work. The source only needs to exist when the target path is being used. And at that point you get a very valid error if the target is still not accessible - No such file or directory. Sure Cygwin's mount is different than Unix's. That's what Cygwin is all about, hiding those differences. Cygwin's mount fails at that. Cygwin's 'mount' has *no* functional overlap with Unix's, for better or worse. If you expect Cygwin's 'mount' to do what the Unix 'mount' does, then you're going to be very disappointed. The semantics are completely different. If you want to argue that Cygwin's 'mount' and 'umount' commands should be called something else because of this difference, that's reasonable (though not very likely to happen given it's historical usage in the Cygwin environment and the lack of file system drivers in Cygwin to support real mounting). But that's not a basis on which to claim that Cygwin's 'mount' is broken. Registering a mount that doesn't exist is quite broken. Have you tried it? It works just as I've described. Something that works can't really be termed broken. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rxvt usage issues under windows xp
[EMAIL PROTECTED] wrote: Now mc is correctly displayed, but pstree -p is not drawen correctly (nor it was before) !!! pstree will not work (except in -A mode) on rxvt, unless pstree is completely rewritten. See (2) in http://www.cygwin.com/ml/cygwin/2006-03/msg00556.html -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin1.dll 1.5.19: race condition deadlock with fifos
Barry Kelly wrote: This code, without a delay, causes a deadlock and both active spawned bash processes (the forked one reading from the fifo and the backgrounded one) need to be killed explicitly: ---8--- ~/test-fifo$ rm fifo ~/test-fifo$ mkfifo fifo ~/test-fifo$ ((echo foo fifo)); echo Read: $(fifo) ---8--- This works fine for me, no hang -- but I use a recent CVS build. Have you tried the latest shapshot? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.19-4: BUG: Using tellg() skips characters on files with DOS line endings
Hi, I've got the following bug that only reproduces itself under Cygwin environment. Using basic_istream::tellg() on files with DOS line endings results in skipping characters from the input. Attached program tellg-bug.cpp tries to reproduce the behavior using a test file test.txt. Commenting out call to tellg() results in correct reading of characters while presence of call to tellg() results in skipping a number of characters that is equal to the number of lines (line endings) in the file. NOTE: File test.txt must have DOS line endings for the bug to be reproducible so please make sure these line endings were not changed while sent over the internet. Converting file to UNIX format with dos2unix utility effectively removes the bug. I think this bug may be related to the following discussions on the Internet: http://sourceforge.net/mailarchive/message.php?msg_id=6614018 http://www.cygwin.com/ml/cygwin/2001-03/msg00399.html Kind regards, Yuriy -- ___ Play 100s of games for FREE! http://games.mail.com/ tellg-bug.cpp Description: Binary data cygcheck.out Description: Binary data 123 The number of chars skipped depends on the number of lines in this file -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin1.dll 1.5.19: race condition deadlock with fifos
On Sun, 11 Jun 2006 18:23:22 -0700, you wrote: Barry Kelly wrote: This code, without a delay, causes a deadlock and both active spawned bash processes (the forked one reading from the fifo and the backgrounded one) need to be killed explicitly: ---8--- ~/test-fifo$ rm fifo ~/test-fifo$ mkfifo fifo ~/test-fifo$ ((echo foo fifo)); echo Read: $(fifo) ---8--- This works fine for me, no hang -- but I use a recent CVS build. Have you tried the latest shapshot? I have just tried: DLL version: 1.5.20 ... Build date: Sun Jun 4 16:35:33 EDT 2006 Snapshot date: 20060604-16:33:54 And I find it has fixed the problem. Thanks! Is there any indication as to how long before 1.5.20 will be fully released? I don't want to risk running under a CVS snapshot except for this test. -- Barry -- http://barrkel.blogspot.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin1.dll 1.5.19: race condition deadlock with fifos
Barry Kelly wrote: On Sun, 11 Jun 2006 18:23:22 -0700, you wrote: Barry Kelly wrote: This code, without a delay, causes a deadlock and both active spawned bash processes (the forked one reading from the fifo and the backgrounded one) need to be killed explicitly: ---8--- ~/test-fifo$ rm fifo ~/test-fifo$ mkfifo fifo ~/test-fifo$ ((echo foo fifo)); echo Read: $(fifo) ---8--- This works fine for me, no hang -- but I use a recent CVS build. Have you tried the latest shapshot? I have just tried: DLL version: 1.5.20 ... Build date: Sun Jun 4 16:35:33 EDT 2006 Snapshot date: 20060604-16:33:54 And I find it has fixed the problem. Thanks! Is there any indication as to how long before 1.5.20 will be fully released? I don't want to risk running under a CVS snapshot except for this test. If you check the email archives, you will see a number of calls for testing of the snapshots in preparation for 1.5.20. From that you can surmise that any recent snapshot is likely to be pretty close to the eventual released version. Keep an eye out here for more details. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
static library in linux and Cygwin
Hello,everyone: I compile the static library in cygwin just like in linux,but when I link my program with the Library, it did not find the function included in the library. Are there any difference between linux and cygwin when using and compiling the static library. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
