Re: [PATCH] setup: update non-experimental packages too when Exp is selected
On Thu, Aug 19, 2010 at 06:30:07AM +0100, Andy Koppe wrote:
At the moment, non-experimental packages don't get updated when 'Exp'
is selected. This was reported at
http://cygwin.com/ml/cygwin/2010-08/msg00460.html.
The fix turned out to be quite simple.
Andy
ChangeLog:
* package_meta.h (packagemeta::trustp): Update non-experimental
packages too when Exp is selected.
Index: package_meta.h
===
RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
retrieving revision 2.38
diff -u -r2.38 package_meta.h
--- package_meta.h 13 Dec 2009 19:23:43 - 2.38
+++ package_meta.h 19 Aug 2010 05:06:47 -
@@ -94,9 +94,9 @@
std::string action_caption () const;
packageversion trustp (trusts const t) const
{
-return t == TRUST_PREV ? (prev ? prev : (curr ? curr : installed))
- : t == TRUST_CURR ? (curr ? curr : installed)
-: exp ? exp : installed;
+return t == TRUST_PREV prev ? prev
+ : t == TRUST_TEST exp ? exp
+ : curr ? curr : installed;
}
Any chance you could add some parentheses here to make the nested ?'s
easier to understand?
Otherwise, I'll take your word for it that this works and say: Approved.
cgf
Re: New VIM version 7.3.002-1
On Aug 19 00:15, Yaakov S wrote: On Tue, 2010-08-17 at 11:54 +0200, Corinna Vinschen wrote: I have prepared a new release of vim, 7.3.002-1, so it's the new 7.3 release from yesterday with its first two patches. [snip] You can find the source and binary packages on sourceware under ~corinna/x/vim/ Please ping me when you finished the corresponding gvim release. Thanks for the heads-up. gvim is now on sourceware under ~yselkowitz/uploads/gvim/ . Thanks, I'll move both packages to release and ... Oh, I just see that you used the .003 patch as well. At the time I created the vim package that patch wasn't available. I'll create a new vim package with the .003 patch as well first. Hang on... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITA (sortof): sunrpc
Hi Chuck, On Aug 18 23:32, Charles Wilson wrote: sunrpc is orphaned. It provides libraries and headers for rpc routines, utilities including rpcgen, documentation, and the portmap daemon. just go ahead with libtirpc, rpcgen, and sunrpc. Please also update the cygwin-pkg-maint file, and make yourself the sunrpc maintainer. You can quarter it and burn the shreds then at your own discretion. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New VIM version 7.3.002-1
On Aug 19 10:43, Corinna Vinschen wrote: On Aug 19 00:15, Yaakov S wrote: On Tue, 2010-08-17 at 11:54 +0200, Corinna Vinschen wrote: I have prepared a new release of vim, 7.3.002-1, so it's the new 7.3 release from yesterday with its first two patches. [snip] You can find the source and binary packages on sourceware under ~corinna/x/vim/ Please ping me when you finished the corresponding gvim release. Thanks for the heads-up. gvim is now on sourceware under ~yselkowitz/uploads/gvim/ . Thanks, I'll move both packages to release and ... Oh, I just see that you used the .003 patch as well. At the time I created the vim package that patch wasn't available. I'll create a new vim package with the .003 patch as well first. Hang on... Ok, done. Both packages are in their respective release directory. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITA (sortof): sunrpc
Hi Chuck, On Aug 18 23:32, Charles Wilson wrote: sunrpc is orphaned. It provides libraries and headers for rpc routines, utilities including rpcgen, documentation, and the portmap daemon. just go ahead with libtirpc, rpcgen, and sunrpc. Please also update the cygwin-pkg-maint file, and make yourself the sunrpc maintainer. You can quarter it and burn the shreds then at your own discretion. Auto gold star awarded.
[ANNOUNCEMENT] Updated: gvim-7.3.003-1
The following package has been updated for the Cygwin distribution: *** gvim-7.3.003-1 gVim provides a GTK+ GUI for the Vim text editor. This is an update to the latest upstream version with the current patchset, and requires a simultaneous 7.3.x update to the vim package in order to operate. Yaakov Cygwin/X -- CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-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-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
libglade2.0_0 problem
Started installing cygwinX on Windows XP August 19 EST 1700h. Used ucalgary.ca mirror Chose default, plus ssh, ssl, vim Download OK, installing Ok, final stages stopped ~1900h Error libglade2.0_0 and libglade2.0.sh 'package does not exist' or words to that effect Hit Back, so lost the exact error message. Oops. What do I do ? Typo in the installation script ? Nick -- 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/
CygwinX Users Guide
Tried to print the PDF version of the guide, August 19 1700h. All screenshots are displaced off the right-hand side. Change magnification and they are still displaced. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog external.cc includ ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-19 10:14:31 Modified files: winsup/cygwin : ChangeLog external.cc winsup/cygwin/include/sys: cygwin.h Log message: * external.cc (sync_wincwd): New function. (cygwin_internal): Rename CW_SETCWD to CW_SYNC_WINCWD. Call sync_wincwd from here. * include/sys/cygwin.h (cygwin_getinfo_types): Rename CW_SETCWD to CW_SYNC_WINCWD. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4998r2=1.4999 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/external.cc.diff?cvsroot=srcr1=1.117r2=1.118 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/sys/cygwin.h.diff?cvsroot=srcr1=1.88r2=1.89
Re: run changes behavior with cygwin-17.6
On Wed, Aug 18, 2010 at 05:42:21PM -0700, Daniel Colascione wrote: The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. Right. I suggested that in cygwin-developers but neither Corinna nor I could really convince ourselves that it was a good idea. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Postinstall for mintty fails when installing just for me
On Aug 18 20:31, Buchbinder, Barry (NIH/NIAID) [E] wrote: Corinna Vinschen sent the following at Wednesday, August 18, 2010 4:43 AM That usually just means you don't have admin privs. For the archive: That is indeed the case. Here's the actual problem: cygdrive prefix / system binary,noacl,posix=0,auto The cygdrive prefix is set to the mount option noacl. So the output from getfacl or ls or stat for this directory shows just fake permissions based on the DOS R/O flag. You're not an admin, so you're not allowed to write to this directory, see the cacls output. However, since the cygdrive prefix is mounted with noacl, Cygwin tools just don't know it. With acl, I had been getting annoying error messages about copying permissions with cp -p on some network drives, so I switched everything to noacl. I'll try switching back to acl, testing for error messages, and going to noacl only on drives that seem to have problems. Oh, I didn't say you have to go back to acl. I was just pointing out the fact. The fact that noacl is perfectly valid is something we package maintainers have to keep in mind when creating postinstall scripts. Same for case-sensitivity. *make mental note* Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1
On Aug 18 22:00, Buchbinder, Barry (NIH/NIAID) [E] wrote: Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:16 AM What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api ^ In case you ever copy and paste the link, htdocs/ needs to be deleted for it to work. Ouch! Thank you for the hint. Actually that htdocs is a part of the URL to the Cygwin docs on my private web server. I hope I don't screw up again in the next announcement... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: More insufficient package dependencies
On Aug 18 21:57, Andy Koppe wrote: On 18 August 2010 21:50, Corinna Vinschen wrote: On Aug 18 21:32, William Blunn wrote: On 18/08/2010 19:26, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. A I see. It's /defined/ to be mediocre. Rather than attempting to solve the problem head-on, redefine the problem domain so that the problem is already solved. Inspired. Is there something in the water lately, which makes people on the list more aggressive than usual? It hasn't been redefined at all. It's the common way of reporting problems for a long time: http://cygwin.com/problems.html If you don't like it, I'm sorry. Are you going to volunteer to maintain a Cygwin packages bug-tracking system? Besides, thanks to the magic of mail filters, grabbing the attention of a package maintainer isn't the problem anyway. The issue is whether there's an active maintainer in the first place. Exactly! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On Aug 18 18:50, Rolf Campbell wrote: I have an 2nd NTFS disk mounted in a directory in my primary NTFS disk. When I use 'find' (with no arguments), it only displays a small fraction of the files in the current directory. Using cygwin 1.7.5, it displayed about 100,000 files. Using cygwin 1.7.6, it only displays the content of the first top-level directory and then just stops. I tried out all the snapshots and narrowed it down to 20100618. It worked correctly in 20100614 and does not work correctly in 20100618. If I mount the disk as a normal drive and access it using /cygdrive, it displays all 100, files with both 1.7.5 and 1.7.6. That narrows down the problem to a specific change, but unfortunately I can not reproduce the problem. I assume, when you say you mounted the 2nd drive, you didn't mean a Cygwin mount but rather a Windows junction point, so your drive doesn't show up as D:, but as C:\DriveD in Windows, correct? At least, that's what I tested. The drive has 1577 files and directories in multiple levels, and `find' always prints all of them, regardless whether the drive is mounted as drive or as juntion point. I also tried a Cygwin mount additionally, with the same result. Here are a couple of questions. They are all related to the mount using a junction point. - When you call `ls -l' in the top-level dir of the junction point, are directories recognized as directories? How many links do the directories supposedly have (should be 1)? - Is it possible that this has something to do with permissions? acl vs. noacl. Your cygcheck output doesn't point that out, but who knows. - Eventually, under Cygwin 1.7.6, can you please send us the output of `ls -l' of the top-level dir, and call `strace -o find.trace find' in the top-level dir and send the strace output? Please don't try this with the *working* scenario, the strace of a find finding 10 files would be a bit... swollen. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 19 02:03, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 05:42:21PM -0700, Daniel Colascione wrote: The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. Right. I suggested that in cygwin-developers but neither Corinna nor I could really convince ourselves that it was a good idea. IMHO it's what you would call a bottomless pit. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On Aug 19 10:31, Corinna Vinschen wrote: On Aug 18 18:50, Rolf Campbell wrote: I have an 2nd NTFS disk mounted in a directory in my primary NTFS disk. When I use 'find' (with no arguments), it only displays a small fraction of the files in the current directory. Using cygwin 1.7.5, it displayed about 100,000 files. Using cygwin 1.7.6, it only displays the content of the first top-level directory and then just stops. I tried out all the snapshots and narrowed it down to 20100618. It worked correctly in 20100614 and does not work correctly in 20100618. If I mount the disk as a normal drive and access it using /cygdrive, it displays all 100, files with both 1.7.5 and 1.7.6. That narrows down the problem to a specific change, but unfortunately I can not reproduce the problem. I assume, when you say you mounted the 2nd drive, you didn't mean a Cygwin mount but rather a Windows junction point, so your drive doesn't show up as D:, but as C:\DriveD in Windows, correct? At least, that's what I tested. The drive has 1577 files and directories in multiple levels, and `find' always prints all of them, regardless whether the drive is mounted as drive or as juntion point. I also tried a Cygwin mount additionally, with the same result. Here are a couple of questions. They are all related to the mount using a junction point. - When you call `ls -l' in the top-level dir of the junction point, are directories recognized as directories? How many links do the directories supposedly have (should be 1)? - Is it possible that this has something to do with permissions? acl vs. noacl. Your cygcheck output doesn't point that out, but who knows. - Eventually, under Cygwin 1.7.6, can you please send us the output of `ls -l' of the top-level dir, and call `strace -o find.trace find' in the top-level dir and send the strace output? Please don't try this with the *working* scenario, the strace of a find finding 10 files would be a bit... swollen. Hmm, is it perhaps possible that this is a side effect of running some aggressive virus scanner which needs tweaking? It's very strange that it should make a difference, whether the drive is mounted as drive or as junction point. There's no difference from Cygwin's POV, and the content of the drive obviously doesn't change by this. Therefore... well, it's grasping for straws, but still... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: run changes behavior with cygwin-17.6
On Aug 18 22:17, Corinna Vinschen wrote: On Aug 18 15:51, Charles Wilson wrote: On 8/18/2010 3:41 PM, Corinna Vinschen wrote: Chuck, btw., the function setup_win_environ() in run.c can easily be replaced with `cygwin_internal (CW_SYNC_WINENV);' Yes, I was just looking at that. I think setup_win_environ (or its guts before some early refactoring) pre-dated CW_SYNC_WINENV. Before removing it, I'll have to verify some things -- like whether that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard it would be to add if not -- since I want run to work over there too. CW_SYNC_WINENV is available since May 2006. That's Cygwin 1.5.20-1. With respect to the orginal discussion that spawned this thread, I'm going to hold off on any changes to run/run2/cygutils until a consensus is reached regarding: 1) what's going to happen inside cygwin wrt win32 cwd; I'm not sure yet. Maybe we should really go cgf's idea to stick to the Win32 CWD, as long as chdir isn't called the first time. 2) what new APIs are provided In PM we agreed on my suggestion. I just have to test and document it first... 3) and a project on how soon an official 1.7.7 will be released with those changes I think 1.7.7 will be released rather very soon. Maybe this weekend. I applied the patch which adds the CW_SYNC_WINCWD code and I updated the documentation accordingly. I uploaded the rewritten chapter about using the Win32 file API here: http://cygwin.de/cygwin-ug-177/using.html#pathnames-win32-api Please have a look. As for the documentation about CW_SYNC_WINENV, it's already in the official docs at http://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32 HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ImageMagick: Still more insufficient package dependencies?
I am trying to build the development version of Emacs with the imagemagick support. In the configure step one gets: $ ./configure --with-imagemagick [...] checking for Wand... yes checking IMAGEMAGICK_CFLAGS... -fopenmp -I/usr/include/ImageMagick checking IMAGEMAGICK_LIBS... -lMagickWand -lMagickCore checking for MagickExportImagePixels... no [...] Does Emacs use imagemagick? yes [...] But, $ make [...] image.o: In function `imagemagick_load_image': /tmp/emacs/src/image.c:7723: undefined reference to `_MagickExportImagePixels' collect2: ld returned 1 exit status make[2]: *** [temacs.exe] Error 1 make[2]: Leaving directory `/tmp/emacs/Work/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/tmp/emacs/Work' make: *** [bootstrap] Error 2 So, is this to be expected with current ImageMagick packages of Cygwin? or have we another 'more insufficient package dependencies' issue? In this case, which are the other packages to be installed? I have already installed ImageMagick-6.4.0.6-2, libImageMagick1-6.4.0.6-2 and libMagick-devel-6.4.0.6-2 and their dependencies. Thanks, Angelo. -- 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
Bug tracker (was: ImageMagick: More insufficient package dependencies)
On 18/08/2010 21:50, Corinna Vinschen wrote: On Aug 18 21:32, William Blunn wrote: On 18/08/2010 19:26, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote: My apologies to all the folks NOT involved in maintaining the ImageMagick package, but there doesn't appear to be any defined process for reporting bugs which might narrow down the attention-grab to a more relevant set of people. Actually, this is the defined way to report bugs in a cygwin package. A I see. It's /defined/ to be mediocre. Rather than attempting to solve the problem head-on, redefine the problem domain so that the problem is already solved. Inspired. Is there something in the water lately, which makes people on the list more aggressive than usual? It hasn't been redefined at all. Quite right. I think I wasn't intending to imply that the situation had been literally *re* defined to something other than what it was originally, but rather to speak in a metaphor, which I can see now wasn't clear. My mistake. It's the common way of reporting problems for a long time: http://cygwin.com/problems.html Key point here being for a long time. Cygwin's development and maintenance environment has, as far as I can see, stood still, or at least moved only very little over the years, whilst the rest of the world moved forward and got useful thinks like bug trackers. To me, compared to the rest of the world (and I'm thinking about things like Sourceforge and Google Code), the Cygwin development and maintenance environment looks quite dated. I realise that I am going to look like the bad guy by being critical. I have had people criticise me in the past. Whilst I may have been annoyed at the time, on some occasions, after reflection, I realised that the person was right and I made changes for the better. If you don't like it, I'm sorry. Are you going to volunteer to maintain a Cygwin packages bug-tracking system? That is an interesting point. The thought had crossed my mind that I could set up my own bug tracker, and that this might actually be useful to the project. To be sure, I had wondered if I could set up such a system and include a moderate amount of advertising on the site and that this might prove to be a moderately profitable activity. But, having a sniff round, it seems that Cygwin operates under the sourceware.org umbrella. And sourceware.org also seems to cover GCC. And GCC appears to have a Bugzilla. So I am wondering that server resource is not the issue. Would I be correct in thinking that? It might be helpful if I could be clear what the reasons for not having a bug tracker are. I could take a stab as: 1. It is not the feeling of the Cygwin maintainers that a bug tracker would provide a significantly better solution than the current mailing list solution 2. There is not any human resource around to do the top-level maintenance of such a system I would be interested to know if tallies with your thinking or whether I have gotten something wrong or missed something. Bill -- 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: ImageMagick: Still more insufficient package dependencies?
On 8/19/2010 7:33 AM, Angelo Graziosi wrote: I am trying to build the development version of Emacs with the imagemagick support. In the configure step one gets: $ ./configure --with-imagemagick [...] checking for Wand... yes checking IMAGEMAGICK_CFLAGS... -fopenmp -I/usr/include/ImageMagick checking IMAGEMAGICK_LIBS... -lMagickWand -lMagickCore checking for MagickExportImagePixels... no [...] Does Emacs use imagemagick? yes [...] But, $ make [...] image.o: In function `imagemagick_load_image': /tmp/emacs/src/image.c:7723: undefined reference to `_MagickExportImagePixels' This looks to me like an Emacs configuration problem, not a Cygwin problem. The code in image.c:7723 is guarded by #ifdef HAVE_MAGICKEXPORTIMAGEPIXELS, and configure reported no in the corresponding test. 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
Bash file completion (Tab) produces -sh: exclude: unbound variable
Greetings, after having recently upgraded Cygwin on my laptop running Windows Vista the Bash Shell started misbehaving by issuing -sh: exclude: unbound variable whenever I hit Tab for file name completion. After trying the obvious (that is, issuing set +u) and even having success with it, I checked the Cygwin mailing list archives but only found a single thread ending with Problem solved, use 'set -o nounset'. Now, in my opinion this only is a temporary workaround, but never a fix, so my question is: is there a real fix for the problem which allows to have set -u (or set -o unset) and tab completion at the same time? This is my third try to send mail to Cygwin@Cygwin.COM. The first two times I didn't even get a rejection message, just nothing, but my mail never showed up in the mailing list archives. Therefore I'll this time not attach the output from cygcheck -s -v -r but will rather only quote below the few lines from it having to do with bash. Sincerely Rainer PS: Please also respond via personal e-mail since I'm not regularly reading this list. Thankyou. HKEY_CURRENT_USER\Console\Cygwin Bash Shell (default) = 0x00f0 PopupColors = 0x00f9 ColorTable00 = 0x ColorTable01 = 0x0080 ColorTable02 = 0x8000 ColorTable03 = 0x00808000 ColorTable04 = 0x0080 ColorTable05 = 0x00800080 ColorTable06 = 0x8080 ColorTable07 = 0x00c0c0c0 ColorTable08 = 0x00808080 ColorTable09 = 0x00ff ColorTable10 = 0xff00 ColorTable11 = 0x0000 ColorTable12 = 0x00ff ColorTable13 = 0x00ff00ff ColorTable14 = 0x ColorTable15 = 0x00ff InsertMode = 0x0001 QuickEdit = 0x0001 FullScreen = 0x ScreenBufferSize = 0x03e70050 WindowSize = 0x00060050 FontSize = 0x000c0008 FontFamily = 0x0030 FontWeight = 0x0190 FaceName = 'Terminal' CursorSize = 0x0019 HistoryBufferSize = 0x03e7 NumberOfHistoryBuffers = 0x0004 HistoryNoDup = 0x WindowPosition = 0x029e HKEY_CURRENT_USER\Console\Cygwin Bash Shell (2) (default) = 0x00f0 PopupColors = 0x00f9 ColorTable00 = 0x ColorTable01 = 0x0080 ColorTable02 = 0x8000 ColorTable03 = 0x00808000 ColorTable04 = 0x0080 ColorTable05 = 0x00800080 ColorTable06 = 0x8080 ColorTable07 = 0x00c0c0c0 ColorTable08 = 0x00808080 ColorTable09 = 0x00ff ColorTable10 = 0xff00 ColorTable11 = 0x0000 ColorTable12 = 0x00ff ColorTable13 = 0x00ff00ff ColorTable14 = 0x ColorTable15 = 0x00ff InsertMode = 0x0001 QuickEdit = 0x0001 FullScreen = 0x ScreenBufferSize = 0x03e70050 WindowSize = 0x003c0050 FontSize = 0x000c0008 FontFamily = 0x0030 FontWeight = 0x0190 FaceName = 'Terminal' CursorSize = 0x0019 HistoryBufferSize = 0x03e7 NumberOfHistoryBuffers = 0x0004 HistoryNoDup = 0x ... Found: C:\cygwin\bin\bash.exe ... bash3.2.49-23 bash-completion 1.2-1 -- 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: run changes behavior with cygwin-17.6
On 8/19/2010 6:48 AM, Corinna Vinschen wrote: I applied the patch which adds the CW_SYNC_WINCWD code and I updated the documentation accordingly. I uploaded the rewritten chapter about using the Win32 file API here: http://cygwin.de/cygwin-ug-177/using.html#pathnames-win32-api Please have a look. The commentary about the errno values is duplicated. Other than that, it seems clear. I have one question, specifically as it relates to run/run2/cygstart: these apps use CreateProcess. In the documentation, you say: If you need a valid Win32 CWD only for a child application started via CreateProcess and friends, you don't have to set your own Win32 CWD. In that case, just utilize the lpCurrentDirectory parameter. See the description of the CreateProcess function in the MSDN manual pages. But earlier in this thread, you suggested that run/run2/cygstart should use the new CW_SYNC_WINENV. Which is it? As for the documentation about CW_SYNC_WINENV, it's already in the official docs at http://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32 Thanks. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug tracker
It might be helpful if I could be clear what the reasons for not having a bug tracker are. I could take a stab as: 1. It is not the feeling of the Cygwin maintainers that a bug tracker would provide a significantly better solution than the current mailing list solution 2. There is not any human resource around to do the top-level maintenance of such a system I think that a bug tracker would be a nice improvement to our development workflow. As a package maintainer, I'd love to be able to call up a page of all of the open bugs for all of the packages I maintain. I also think that the work to set up and maintain a bug tracker isn't very much at all. I've set up three Trac installations myself, for different projects. It's no big deal, and if Trac were the tool of choice for Cygwin, I would volunteer to set it up and maintain it. I don't have any experience managing other bug trackers though, e.g. Bugzilla, so I can't say about them and would be reluctant to volunteer to help with them. I don't know about server space, but surely that should be available somewhere. I'm guessing that it really comes down to what the project leaders want to support. Then again, if the community maintains a bug tracker, the project leaders don't have to be involved at all, except that it would be a much more valuable tool if they agreed to use it. Andrew. -- 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: run changes behavior with cygwin-17.6
On Aug 19 09:20, Charles Wilson wrote: On 8/19/2010 6:48 AM, Corinna Vinschen wrote: I applied the patch which adds the CW_SYNC_WINCWD code and I updated the documentation accordingly. I uploaded the rewritten chapter about using the Win32 file API here: http://cygwin.de/cygwin-ug-177/using.html#pathnames-win32-api Please have a look. The commentary about the errno values is duplicated. Other than that, it Oh, fixed. I missed to upload the latest version of the file. Sorry! (I experimented with DocBook's segmentedlists and tables) seems clear. I have one question, specifically as it relates to run/run2/cygstart: these apps use CreateProcess. In the documentation, you say: If you need a valid Win32 CWD only for a child application started via CreateProcess and friends, you don't have to set your own Win32 CWD. In that case, just utilize the lpCurrentDirectory parameter. See the description of the CreateProcess function in the MSDN manual pages. But earlier in this thread, you suggested that run/run2/cygstart should use the new CW_SYNC_WINENV. Which is it? It's something completely different. CW_SYNC_WINCWD is to sync the CWD. But it's your choice, whether ^^^ you use CW_SYNC_WINCWD or just utilize the lpCurrentDirectory param to CreateProcess. http://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32 Thanks. CW_SYNC_WINENV is for sync'ing the Win32 *environment* with the Cygwin ^^^ environment. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash file completion (Tab) produces -sh: exclude: unbound variable
On 8/18/2010 10:22 AM, Dr. Rainer Woitok wrote: Greetings, after having recently upgraded Cygwin on my laptop running Windows Vista the Bash Shell started misbehaving by issuing -sh: exclude: unbound variable whenever I hit Tab for file name completion. After trying the obvious (that is, issuing set +u) and even having success with it, I checked the Cygwin mailing list archives but only found a single thread ending with Problem solved, use 'set -o nounset'. My understanding is that, this has been forwarded upstream for fixing in next release. -- 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: Bug tracker
On 19/08/2010 14:57, Andrew Schulman wrote: I think that a bug tracker would be a nice improvement to our development workflow. As a package maintainer, I'd love to be able to call up a page of all of the open bugs for all of the packages I maintain. I also think that the work to set up and maintain a bug tracker isn't very much at all. I've set up three Trac installations myself, for different projects. It's no big deal, and if Trac were the tool of choice for Cygwin, I would volunteer to set it up and maintain it. I don't have any experience managing other bug trackers though, e.g. Bugzilla, so I can't say about them and would be reluctant to volunteer to help with them. I don't know about server space, but surely that should be available somewhere. I'm guessing that it really comes down to what the project leaders want to support. Then again, if the community maintains a bug tracker, the project leaders don't have to be involved at all, except that it would be a much more valuable tool if they agreed to use it. Sounds like a top idea. I suppose the top-level management workload is more about creating / maintaining the sub-projects for packages so as to associate them with the correct maintainers for each package. You might also want to make it clear at the new bug page that the tracker was only used for packages where the maintainer had elected to use the bug tracker, and that if there was no sub-project listed for a particular package then bugs for that package were not tracked in the tracker and the proper place to go would be the mailing list. Bill -- 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: Bug tracker
On Aug 19 09:57, Andrew Schulman wrote: It might be helpful if I could be clear what the reasons for not having a bug tracker are. I could take a stab as: 1. It is not the feeling of the Cygwin maintainers that a bug tracker would provide a significantly better solution than the current mailing list solution 2. There is not any human resource around to do the top-level maintenance of such a system I think that a bug tracker would be a nice improvement to our development workflow. As a package maintainer, I'd love to be able to call up a page of all of the open bugs for all of the packages I maintain. I also think that the work to set up and maintain a bug tracker isn't very much at all. I've set up three Trac installations myself, for different projects. It's no big deal, and if Trac were the tool of choice for Cygwin, I would volunteer to set it up and maintain it. I don't have any experience managing other bug trackers though, e.g. Bugzilla, so I can't say about them and would be reluctant to volunteer to help with them. I don't know about server space, but surely that should be available somewhere. I'm guessing that it really comes down to what the project leaders want to support. Then again, if the community maintains a bug tracker, the project leaders don't have to be involved at all, except that it would be a much more valuable tool if they agreed to use it. The question is if the maintainers really want that, and cgf and I are just 2 out of ~60 maintainers, maintaining over 1400 packages. From these ~60 maintainers we have quite a few who either don't reply to any mail about their package, or who only reply after some nudging. Somebody would have to set up the system and the maintainers must be willing to get automatic mails about issues entered into the bugtracker. How to set that up is YA question. One category per package? That doesn't sounds feasible, unless we have another, *active* maintainer just for keeping the bugtracker in shape. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug tracker
The question is if the maintainers really want that, and cgf and I are just 2 out of ~60 maintainers, maintaining over 1400 packages. From these ~60 maintainers we have quite a few who either don't reply to any mail about their package, or who only reply after some nudging. Agreed, but OTOH I'd guess that half of all of the bugs reported on this list are for just two packages: cygwin and setup.exe. If the maintainers of those two packages think a bug tracker would be useful, we should make one. If they don't, it's probably not worth bothering. Somebody would have to set up the system and the maintainers must be willing to get automatic mails about issues entered into the bugtracker. I can see a few models for notifying maintainers: (1) Individual maintainers must each agree to receive emails, or their packages won't be in the bug tracker. (2) The community decides that bug tracking is important enough that anyone who signs up to maintain a package must also agree to receive email from the bug tracker. Then all packages are listed in the bug tracker. (3) Bug notifications are sent to the cygwin list, or possibly to a separate cygwin-bugs list, instead of/in addition to the maintainers. How to set that up is YA question. One category per package? That doesn't sounds feasible, unless we have another, *active* maintainer just for keeping the bugtracker in shape. The list of packages could be automatically fetched and turned into categories, once a day. If the package maintainer names addresses could also be automatically fetched, then they could be automatically propagated into the bug tracker too and so much the better. The UI would need some care. We would NOT want a pull-down menu of 1400 categories to enter a new bug :( An autocomplete widget for the package names would probably work well. Andrew. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On Aug 19 09:50, Rolf Campbell wrote: NTFS Junction point: yes. I used the builtin windowns tool mountvol to mount the disk in an empty directory. It's technically mounted as C:\.timemachine\3. Output from ls -l [...] I do not set the CYGWIN environmental variable when running find. I noticed something of interest, if I run find, then it only descends into the ATI directory. After exhausting every file/dir under ATI, it terminates. But, if I run find -maxdepth 2, it shows all correct output (it correctly enters all top-level and 2nd level directories -- it does NOT stop after leaving ATI). Eric? Can you have a look here, please? This is weird. I checked the strace, and after ascending back from the ATI subdir into the toplevel dir successfully, find appears to exit just so, without any trace that it even *tries* to continue to scan further subdirs. And unfortunately there's no way to see why find thinks there's nothing to do anymore. Is there a way to debug find to find out why it exits? Also, ls -R works just fine (showing all 100,000 files). That's, at least, good news. Hmm, digging through Cygwin's readdir code, I have a vague idea. Eric, does find honor the struct dirent d_type flag? I'm wondering if d_type is erroneously set to DT_REG for some reason. If so, we could find this out by augmenting the debug output in the Cygwin DLL. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug tracker
On Aug 19 10:41, Andrew Schulman wrote: The question is if the maintainers really want that, and cgf and I are just 2 out of ~60 maintainers, maintaining over 1400 packages. From these ~60 maintainers we have quite a few who either don't reply to any mail about their package, or who only reply after some nudging. Agreed, but OTOH I'd guess that half of all of the bugs reported on this list are for just two packages: cygwin and setup.exe. If the maintainers of those two packages think a bug tracker would be useful, we should make one. If they don't, it's probably not worth bothering. I do not agree. On the contrary, I'm under the impression that more and more mails are reporting packaging problems or generic problems with using certain packages. Bash and CRLF in scripts, for instance. Agreed, at the time of a new Cygwin release breaking things (like this 1.7.6 release), we get more bug reports on Cygwin than usual, How to set that up is YA question. One category per package? That doesn't sounds feasible, unless we have another, *active* maintainer just for keeping the bugtracker in shape. The list of packages could be automatically fetched and turned into categories, once a day. If the package maintainer names addresses could also be automatically fetched, then they could be automatically propagated into the bug tracker too and so much the better. http://cygwin.com/acronyms/#SHTDI ? The UI would need some care. We would NOT want a pull-down menu of 1400 categories to enter a new bug :( An autocomplete widget for the package names would probably work well. Well, most packages are sub-packages. Like libncurses10 being a subpackage of ncurses. We don't need 1400 entries. Just a couple of hundreds... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick: Still more insufficient package dependencies?
Ken Brown wrote: This looks to me like an Emacs configuration problem, not a Cygwin problem. The code in image.c:7723 is guarded by #ifdef HAVE_MAGICKEXPORTIMAGEPIXELS, and configure reported no in the corresponding test. If I understand this rightly, ... checking for MagickExportImagePixels... no ... is right, i.e. the Cygwin binaries of ImageMagick do not support the function 'MagickExportImagePixels', but Emacs 'configure' sets 'HAVE_MAGICKEXPORTIMAGEPIXELS' to true in any case, so that the build enables the imagemagick support, ... Does Emacs use imagemagick? yes ... but it fails, obviously, at link time. This seems to be confirmed by $ grep -iR MagickExportImagePixe config.status D[HAVE_MAGICKEXPORTIMAGEPIXELS]= 1 $ grep -iR MagickExportImagePixe src/config.h /* Define to 1 if you have the `MagickExportImagePixels' function. */ #define HAVE_MAGICKEXPORTIMAGEPIXELS 1 Thanks for clarification. - Angelo -- 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: Bug tracker
http://cygwin.com/acronyms/#SHTDI ? Auto-updating the package categories daily doesn't seem hard to me, I would build that if we had a bug tracker working. But before we get to that point, I'd have a few other questions. (1) Most important: How many people care? Do users want a bug tracker? Would package maintainers use it? Would the cygwin and setup.exe maintainers use it? Andrew Schulman and Bill Blunn would find a bug tracker useful, but that's not enough reason to build one. There has to be significant community buy-in, or it's not worth doing. (2) What's the best bug tracker for Cygwin? I know Trac, and I would help to set it up. Maybe that's all we need to know, but I'd like to hear from people who have experience with other bug trackers and could suggest which is likely to work best for us. Trac's big selling point is its integration of wiki, bug tracker, and version control repository views. Only the bug tracker seems to be immediately of interest for Cygwin. We could disable the other components and just use the bug tracker, but it's not necessarily the strongest stand-alone bug tracker. (3) Would sourceware.org/cygwin.com be able to offer any server support, i.e. file space, PHP, and a database? Andrew. -- 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: Bug tracker
What is the status of http://cygwin.com/bugzilla? It appears to have been in use at least last year. Provisional effort? Occasionally used? Useful, not useful? -- 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: Bug tracker
On 8/19/2010 10:18 AM, Andrew Schulman wrote: (1) Most important: How many people care? Do users want a bug tracker? Would package maintainers use it? Would the cygwin and setup.exe maintainers use it? Andrew Schulman and Bill Blunn would find a bug tracker useful, but that's not enough reason to build one. There has to be significant community buy-in, or it's not worth doing. I'll chime in that I believe a bug tracker would be an excellent support option for Cygwin. For various reasons, many people new to Cygwin either don't know about or fail to successfully use the mail archives to find answers to their questions or solutions to their issues. Personally, I find that searching the mail archives leaves much to be desired when trying to follow the various threads that can sometimes be spawned by a single issue over Cygwin's history. For instance, how many threads have been created over the years because someone has trouble getting sshd correctly configured to work with pubkey authentication? And assuming the intrepid decide to play nice and search the mail archives first, how are new users supposed to know which reply in which thread has the authoritative answer for their version of Cygwin on their installation of Windows? For people who haven't been monitoring the list for years, it's hard to know who is an authority for any particular subject, and it's doubly hard to keep track of which version of Cygwin, openssh, what-have-you is relevant to any discussion older than 12 months. A defect tracker should hopefully address such issues at least somewhat better than mail archives. Duplicate issues can be merged, issue owners can be more readily assumed to be able to provide the authoritative answers and solutions, resolved issues can be unambiguously closed, and detailed information such as package and Cygwin versions and affected Windows platforms can be recorded for quick reference when applicable. For the various maintainers of the Cygwin project and its packages, this should also help them keep track of and prioritize issues and more transparently plan how and when the issues will be addressed. For especially difficult cases, perhaps a voting system could even be implemented to help everyone agree upon the prioritization of defects so that developers can better spend their time addressing the most urgent needs of the community at large (not that a volunteer developer really has to adhere to any community vote ;-). We also shouldn't overlook the case where one person replaces another as the maintainer of something. Having the current list of outstanding issues and some clear history of previous issues would make the new maintainer's job much easier. -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: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On 08/19/2010 08:43 AM, Corinna Vinschen wrote: Hmm, digging through Cygwin's readdir code, I have a vague idea. Eric, does find honor the struct dirent d_type flag? I'm wondering if d_type is erroneously set to DT_REG for some reason. If so, we could find this out by augmenting the debug output in the Cygwin DLL. find (but not oldfind) relies heavily on the d_type flag. If that flag is incorrect, it could explain why find gets lost. Could you repeat the experiment with 'oldfind' and see if that behaves better? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: run changes behavior with cygwin-17.6
On Thu, Aug 19, 2010 at 10:33:16AM +0200, Corinna Vinschen wrote: On Aug 19 02:03, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 05:42:21PM -0700, Daniel Colascione wrote: The other crazy idea would be to override the Win32 file and path functions and handle the notion of a current directory entirely within Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with Windows API functions was explicitly rejected a while ago. Right. I suggested that in cygwin-developers but neither Corinna nor I could really convince ourselves that it was a good idea. IMHO it's what you would call a bottomless pit. Yeah, we try to avoid things with the BP acronym these days. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On Aug 19 10:28, Eric Blake wrote:
On 08/19/2010 08:43 AM, Corinna Vinschen wrote:
Hmm, digging through Cygwin's readdir code, I have a vague idea.
Eric, does find honor the struct dirent d_type flag? I'm wondering
if d_type is erroneously set to DT_REG for some reason. If so, we
could find this out by augmenting the debug output in the Cygwin DLL.
find (but not oldfind) relies heavily on the d_type flag. If that flag
is incorrect, it could explain why find gets lost. Could you repeat the
experiment with 'oldfind' and see if that behaves better?
For further testing purposes I have uploaded a new cygwin1.dll which
a) adds debug output in readdir() which prints DOS attributes as well as
evaluated d_type value for each readdir entry to strace, and
b) which is heavily tweaked to try harder to get a useful d_type value
without compromising speed. The patch is attached, for the records.
Rolf, please try the following Cygwin DLL:
http://cygwin.de/cygwin-ug-177/new-cygwin1.dll.bz2
(md5sum compressed 17d66fdd070ce3c57ae735b814cfe527)
(md5sum uncompressed e30408e665195b351d62d755f3da82ed)
Bunzip the DLL, chmod +x it, and replace your current DLL with that
version. Then repeat the find. If it still fails, please send the
strace output again.
Thanks,
Corinna
Index: fhandler_disk_file.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_disk_file.cc,v
retrieving revision 1.332
diff -u -p -r1.332 fhandler_disk_file.cc
--- fhandler_disk_file.cc 18 Aug 2010 10:10:14 - 1.332
+++ fhandler_disk_file.cc 19 Aug 2010 16:59:35 -
@@ -148,10 +148,15 @@ path_conv::isgood_inode (__ino64_t ino)
return hasgood_inode () (ino UINT32_MAX || !isremote () || fs_is_nfs
());
}
-static inline bool
-is_volume_mountpoint (POBJECT_ATTRIBUTES attr)
+/* Check reparse point for type. IO_REPARSE_TAG_MOUNT_POINT types are
+ either volume mount points, which are treated as directories, or they
+ are directory mount points, which are treated as symlinks.
+ IO_REPARSE_TAG_SYMLINK types are always symlinks. We don't know
+ anything about other reparse points, so they are treated as unknown. */
+static inline int
+check_reparse_point (POBJECT_ATTRIBUTES attr)
{
- bool ret = false;
+ DWORD ret = DT_UNKNOWN;
IO_STATUS_BLOCK io;
HANDLE reph;
UNICODE_STRING subst;
@@ -165,15 +170,24 @@ is_volume_mountpoint (POBJECT_ATTRIBUTES
alloca (MAXIMUM_REPARSE_DATA_BUFFER_SIZE);
if (NT_SUCCESS (NtFsControlFile (reph, NULL, NULL, NULL,
io, FSCTL_GET_REPARSE_POINT, NULL, 0,
- (LPVOID) rp, MAXIMUM_REPARSE_DATA_BUFFER_SIZE))
- rp-ReparseTag == IO_REPARSE_TAG_MOUNT_POINT
- (RtlInitCountedUnicodeString (subst,
- (WCHAR *)((char *)rp-MountPointReparseBuffer.PathBuffer
- + rp-MountPointReparseBuffer.SubstituteNameOffset),
- rp-MountPointReparseBuffer.SubstituteNameLength),
- RtlEqualUnicodePathPrefix (subst, ro_u_volume, TRUE)))
- ret = true;
- NtClose (reph);
+ (LPVOID) rp, MAXIMUM_REPARSE_DATA_BUFFER_SIZE)))
+ {
+ if (rp-ReparseTag == IO_REPARSE_TAG_MOUNT_POINT)
+ {
+ RtlInitCountedUnicodeString (subst,
+ (WCHAR *)((char *)rp-MountPointReparseBuffer.PathBuffer
+ + rp-MountPointReparseBuffer.SubstituteNameOffset),
+ rp-MountPointReparseBuffer.SubstituteNameLength);
+ /* Only volume mountpoints are treated as directories. */
+ if (RtlEqualUnicodePathPrefix (subst, ro_u_volume, TRUE))
+ ret = DT_DIR;
+ else
+ ret = DT_LNK;
+ }
+ else if (rp-ReparseTag == IO_REPARSE_TAG_SYMLINK)
+ ret = DT_LNK;
+ NtClose (reph);
+ }
}
return ret;
}
@@ -1826,17 +1840,16 @@ fhandler_disk_file::readdir_helper (DIR
dir-__flags = ~dirent_set_d_ino;
}
- /* Set d_type if type can be determined from file attributes.
- FILE_ATTRIBUTE_SYSTEM ommitted to leave DT_UNKNOWN for old symlinks.
- For new symlinks, d_type will be reset to DT_UNKNOWN below. */
+ /* Set d_type if type can be determined from file attributes. For .lnk
+ symlinks, d_type will be reset below. Reparse points can be NTFS
+ symlinks, even if they have the FILE_ATTRIBUTE_DIRECTORY flag set. */
if (attr
- !(attr ( ~FILE_ATTRIBUTE_VALID_FLAGS
- | FILE_ATTRIBUTE_SYSTEM
- | FILE_ATTRIBUTE_REPARSE_POINT)))
+ !(attr (~FILE_ATTRIBUTE_VALID_FLAGS | FILE_ATTRIBUTE_REPARSE_POINT)))
{
if (attr FILE_ATTRIBUTE_DIRECTORY)
de-d_type = DT_DIR;
- else
+ /* FILE_ATTRIBUTE_SYSTEM might denote system-bit type symlinks. */
+ else if (!(attr FILE_ATTRIBUTE_SYSTEM))
de-d_type =
Re: Bug tracker
On Aug 19 11:23, Andrew Schulman wrote: What is the status of http://cygwin.com/bugzilla? It appears to have been in use at least last year. Provisional effort? Occasionally used? Useful, not useful? Not used for Cygwin, right now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug tracker
On Aug 19 11:18, Andrew Schulman wrote: http://cygwin.com/acronyms/#SHTDI ? Auto-updating the package categories daily doesn't seem hard to me, I would build that if we had a bug tracker working. But before we get to that point, I'd have a few other questions. (1) Most important: [...] Would the cygwin and setup.exe maintainers use it? That's the important point. (2) What's the best bug tracker for Cygwin? bugzilla is available on sourceware. I don't think anybody of the overseers crew would want to set up another system. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
libtirpc is an updated version of the Sun RPC library. As such, it replaces part of the (orphaned) sunrpc package -- just as on linux, it replaces the built-in RPC routines in glibc: http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php You should update sunrpc, if installed, to 4.0-4 or above. The headers are installed into /usr/lib/tirpc/rpc/* and not /usr/lib/rpc/ As a consequence, developers must add -I/usr/lib/tirpc when compiling RPC clients and servers on cygwin. Similarly, linking requires -ltirpc. However, this is the same procedure used on linux -- so any client that has already been taught how to accept tirpc on linux will be fine on cygwin. This version is compiled without the XDR routines, as cygwin-1.7.2+ provides those routines internally. It is compiled without AUTH_DES support (that is, cygwin libtirpc is not NIS-aware, because there is not yet any cygwin NIS server or client; since NIS requires a portmap or rpcbind implementation, we have a bit of a chicken/egg issue). Also, it is compiled without GSS_API support, because the official cygwin distribution does not yet contain any Kerboros implementation. Thus, this version of libtirpc supports only unencrypted communication. However, MOST uses of RPC are unencrypted, so this shouldn't be a big deal. Official PR blurb: -- This package contains SunLib's implementation of transport-independent RPC (TI-RPC) documentation. This library forms a piece of the base of Open Network Computing (ONC), and is derived directly from the Solaris 2.3 source. TI-RPC is an enhanced version of TS-RPC that requires the UNIX System V Transport Layer Interface (TLI) or an equivalent X/Open Transport Interface (XTI). TI-RPC is on-the-wire compatible with the TS-RPC, which is supported by almost 70 vendors on all major operating systems. TS-RPC source code (RPCSRC 4.0) remains available from several internet sites. -- Charles Wilson volunteer libtirpc maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: rpcgen-2.11.90_20100818-1
rpcgen is a tool that generates C code to implement an RPC protocol. The input to rpcgen is a language similar to C known as RPC Language (Remote Procedure Call Language). This package replaces a component of the (soon-to-be-obsolete) sunrpc package; you should update sunrpc to the 4.0-4 version if you have it installed. This implementation of rpcgen is derived from the eglibc SVN. Note that rpcgen requires /usr/bin/cpp -- but that program, the C PreProcessor, may be supplied by either the gcc-core or the gcc4-core package. Given this ambiguity, neither package is explicitly required, and neither will be automatically installed. It is up to the user to ensure that some version of gcc is installed, if rpcgen is to operate correctly. Also, note that due to a packaging error, 'rpcgen --version' will report 'rpcgen (cygwin-special) 2.12.90' -- even though this release claims to be version 2.11.90_20100818. This discrepancy will be corrected in a future release. -- Charles Wilson volunteer rpcgen maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: sunrpc-4.0-4
This update is simply a repackaging of the existing sunrpc package, without any testing. If the old version still works at this late date (4.0-3 was published in 2005, during the cygwin-1.3.x era), then this new version will too, because the .exe is *the same file*. OTOH, if this new version is broken, then the old one must also have been broken, so please, no complaints unless the following is true: 1) you were previously using sunrpc-4.0-3 and it worked 2) you upgraded to sunrpc-4.0-4 and made NO OTHER CHANGES and now it stopped working. Those are the only bug reports I will accept concerning this package, since it will soon be obsoleted by the forthcoming, modern rpcbind. The sole reason for this repackaging is to avoid conflicts with new facilities in cygwin itself (built-in XDR support), and with new packages that replace many of the separate facilities once provided by sunrpc. Eventually, sunrpc will be completely retired, once all of its facilities are replaced. The only remaining component before that can happen is the completion of a cygwin port of the 'rpcbind' package. Changes since 4.0-3 = o Repackaged, not recompiled + COMPLETELY UNTESTED o librpc and associated headers removed; use libtirpc instead o rpcgen removed; use new rpcgen package instead -- Charles Wilson volunteer sunrpc maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
MySQL?
Hello! Has MySQL ever been successfully ported to Cygwin? I recall as we were making the move towards 1.7 that it came up several times. - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. -- 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: Bug tracker
On Aug 19 11:23, Andrew Schulman wrote: What is the status of http://cygwin.com/bugzilla? It appears to have been in use at least last year. Provisional effort? Occasionally used? Useful, not useful? Not used for Cygwin, right now. CGF was using it at least a little bit last year: http://cygwin.com/bugzilla/show_bug.cgi?id=10928 . But it doesn't seem to be used much. That installation appears to be for everything in sourceware.org, with a few Cygwin categories. It's too hard to use for Cygwin in that form, IMO. I guess I need to talk to the sourceware admins about whether a separate instance could be provided for Cygwin. -- 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: Bug tracker
On Thu, Aug 19, 2010 at 11:18:48AM -0400, Andrew Schulman wrote: http://cygwin.com/acronyms/#SHTDI ? Auto-updating the package categories daily doesn't seem hard to me, I would build that if we had a bug tracker working. But before we get to that point, I'd have a few other questions. (1) Most important: How many people care? Do users want a bug tracker? Would package maintainers use it? Would the cygwin and setup.exe maintainers use it? Andrew Schulman and Bill Blunn would find a bug tracker useful, but that's not enough reason to build one. There has to be significant community buy-in, or it's not worth doing. (2) What's the best bug tracker for Cygwin? I know Trac, and I would help to set it up. Maybe that's all we need to know, but I'd like to hear from people who have experience with other bug trackers and could suggest which is likely to work best for us. Trac's big selling point is its integration of wiki, bug tracker, and version control repository views. Only the bug tracker seems to be immediately of interest for Cygwin. We could disable the other components and just use the bug tracker, but it's not necessarily the strongest stand-alone bug tracker. (3) Would sourceware.org/cygwin.com be able to offer any server support, i.e. file space, PHP, and a database? No, sourceware.org is not going to set up a completely new bug tracking system just for one project. I'm several messages into this thread and I have yet to see anyone say It's already there. There is already a cygwin category in sourceware's bugzilla database and we've already had the discussion about how it should be handled. We had the discussion and then nothing happened and apparently no one even remembers that it exists. My problem with making this available to the Cygwin community is that I think, by and large, it is comprised of a fairly naive and nontechnical group of people who will not provide adequate bug reports. So anyone maintaining bugzilla will be spending a fair amount of time closing bug reports or asking for obvious clarification. However, if someone wants to volunteer to maintain this and vows to do a good job policing the database then I'll give them administrative authority and change the wording on the web site. I assume we'd want to change some categories in bugzilla too. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug tracker
On Thu, Aug 19, 2010 at 11:02:35AM -0500, Jeremy Bopp wrote: On 8/19/2010 10:18 AM, Andrew Schulman wrote: (1) Most important: How many people care? Do users want a bug tracker? Would package maintainers use it? Would the cygwin and setup.exe maintainers use it? Andrew Schulman and Bill Blunn would find a bug tracker useful, but that's not enough reason to build one. There has to be significant community buy-in, or it's not worth doing. I'll chime in that I believe a bug tracker would be an excellent support option for Cygwin. For various reasons, many people new to Cygwin either don't know about or fail to successfully use the mail archives to find answers to their questions or solutions to their issues. Personally, I find that searching the mail archives leaves much to be desired when trying to follow the various threads that can sometimes be spawned by a single issue over Cygwin's history. For instance, how many threads have been created over the years because someone has trouble getting sshd correctly configured to work with pubkey authentication? And assuming the intrepid decide to play nice and search the mail archives first, how are new users supposed to know which reply in which thread has the authoritative answer for their version of Cygwin on their installation of Windows? For people who haven't been monitoring the list for years, it's hard to know who is an authority for any particular subject, and it's doubly hard to keep track of which version of Cygwin, openssh, what-have-you is relevant to any discussion older than 12 months. A defect tracker should hopefully address such issues at least somewhat better than mail archives. Duplicate issues can be merged, issue owners can be more readily assumed to be able to provide the authoritative answers and solutions, resolved issues can be unambiguously closed, and detailed information such as package and Cygwin versions and affected Windows platforms can be recorded for quick reference when applicable. This seems like a terrible example to me. You seem to be expecting a bug tracker will be used for technical support so that if someone is having problems setting up openssh they will be walked through the problem in the bug tracker. I'd actually expect that a user error would be closed as user error. And, subsequent reports of the problem would be closed as dups. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug tracker
On Thu, Aug 19, 2010 at 07:05:53PM +0200, Corinna Vinschen wrote: On Aug 19 11:23, Andrew Schulman wrote: What is the status of http://cygwin.com/bugzilla? It appears to have been in use at least last year. Provisional effort? Occasionally used? Useful, not useful? Not used for Cygwin, right now. I guess I should have read further. However, my previous points still stand. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug tracker
On Thu, Aug 19, 2010 at 01:26:03PM -0400, Andrew Schulman wrote: On Aug 19 11:23, Andrew Schulman wrote: What is the status of http://cygwin.com/bugzilla? It appears to have been in use at least last year. Provisional effort? Occasionally used? Useful, not useful? Not used for Cygwin, right now. CGF was using it at least a little bit last year: http://cygwin.com/bugzilla/show_bug.cgi?id=10928 . But it doesn't seem to be used much. That installation appears to be for everything in sourceware.org, with a few Cygwin categories. It's too hard to use for Cygwin in that form, IMO. I guess I need to talk to the sourceware admins about whether a separate instance could be provided for Cygwin. I'm one of the sourceware admins. We're not going to set up a separate bugzilla entry for Cygwin, or at least we won't be doing it until I'm convinced this is actually going to fly. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MySQL?
On Thu, 2010-08-19 at 13:22 -0400, Gregg Levine wrote: Has MySQL ever been successfully ported to Cygwin? I recall as we were making the move towards 1.7 that it came up several times. Cygwin Ports provides MySQL packages. The clients are fine, but I do not guarantee that the server is usable, although I think it should be if properly configured. YMMV. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: vim-7.3.003-1
I have updated the version of vim on cygwin.com to 7.3.003-1. This is an update to the new upstream version 7.3, including the first three patchsets. Cygwin Vim builds from the vanilla sources. The official release message: === Hello Vim users, Announcing: Vim (Vi IMproved) version 7.3 This is a minor release of Vim. It consists of Vim 7.2 plus all patches, updated runtime files and some more, see below. It has been two years since the 7.2 release, thus it's not that minor. But not major either. Something in between, don't know how to call that. The most notable additions since 7.2: - Persistent undo and undo for reload - Blowfish encryption, encryption of the swap file - Conceal text - Lua interface - Python 3 interface Once you have installed Vim 7.3 you can find all the details about the changes since Vim 7.2 with: :help version-7.3 Gratitude - If you like Vim, this is the way to say thanks: http://iccf-holland.org/clinic.html Where to get it --- The best way to obtain the latest Vim 7.3 is using Mercurial. Summary: hg clone https://vim.googlecode.com/hg/ vim cd vim/src hg update vim73 make More information here: http://www.vim.org/mercurial.php All downloadable files can be found below this directory: ftp://ftp.vim.org/pub/vim/ Direct link to the MS-Windows self-installing executable: ftp://ftp.vim.org/pub/vim/pc/gvim73.exe Information about which files to download for what system: http://www.vim.org/download.php A list of mirror sites can be found here: http://www.vim.org/mirrors.php UNIX: unix/vim-7.3.tar.bz2 sources + runtime files, bzip2 compressed MS-WINDOWS one-size-fits-all: pc/gvim73.exe installer for GUI and console executables, includes all runtime files, many features VARIOUS: doc/vim73html.zip help files converted to HTML MS-WINDOWS separate files: pc/vim73rt.zip runtime files pc/gvim73.zip GUI binary for Windows 95/98/NT/2000/XP pc/gvim73ole.zip GUI binary with OLE support pc/gvim73_s.zipGUI binary for Windows 3.1 (untested) pc/vim73d32.zipconsole version for MS-DOS/Windows 95/98 pc/vim73w32.zipconsole version for Windows NT/2000/XP pc/vim73src.zipsources for PC (with CR-LF) DIFFS TO PREVIOUS RELEASE: unix/vim-7.2-7.3.diff.gz sources + runtime files unstable/unix/vim-7.3f-7.3.diff.gz sources + runtime files Omitted in this version are: - Extra and lang archives, these are now included in the main source and runtime archives. - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete. Mailing lists - For user questions you can turn to the Vim mailing list. There are a lot of tips, scripts and solutions. You can ask your Vim questions, but only if you subscribe. See http://www.vim.org/maillist.php#vim If you want to help Vim development, discuss new features or get the latest patches, subscribe to the vim-dev mailing list. See http://www.vim.org/maillist.php#vim-dev Subject specific lists: Multi-byte issues: http://www.vim.org/maillist.php#vim-multibyte Macintosh issues: http://www.vim.org/maillist.php#vim-mac Before you ask a question you should search the archives, someone may already have given the answer. Reporting bugs -- Send them to vim-...@vim.org. Please describe the problem precisely. All the time spent on answering mail is subtracted from the time that is spent on improving Vim! Always give a reproducible example and try to find out which settings or other things influence the appearance of the bug. Try starting without your own vimrc file: vim -u NONE. Try different machines if possible. See :help bugs in Vim. Send me a patch if you can! Happy Vimming! === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports:
Re: Bug tracker
On 8/19/2010 12:34 PM, Christopher Faylor wrote: On Thu, Aug 19, 2010 at 11:02:35AM -0500, Jeremy Bopp wrote: A defect tracker should hopefully address such issues at least somewhat better than mail archives. Duplicate issues can be merged, issue owners can be more readily assumed to be able to provide the authoritative answers and solutions, resolved issues can be unambiguously closed, and detailed information such as package and Cygwin versions and affected Windows platforms can be recorded for quick reference when applicable. This seems like a terrible example to me. You seem to be expecting a bug tracker will be used for technical support so that if someone is having problems setting up openssh they will be walked through the problem in the bug tracker. I'd actually expect that a user error would be closed as user error. And, subsequent reports of the problem would be closed as dups. That's definitely one way that a maintainer could choose to operate on issues opened for his/her components; however, the first time such an issue is opened, the maintainer could also choose to elaborate upon the cause of the user error and/or offer an appropriate solution when the issue is closed as user error. The maintainer might also refer to the appropriate entry in the mailing list history similar to what is frequently done now when the same question is asked to the mailing list for the umpteenth time. Future duplicates could indeed be closed as dups without further comment. I admit that using a defect tracker as a general support forum is not exactly ideal, but it does give users some context with which to narrow their searches and measure the quality of the response or level of interest in solving the issue. Hopefully, the number of repeat problems goes down over time. If nothing else though, it should allow more technical people to clearly open real issues using the experience with defect trackers that more and more of them have. Of course the quality of the defect tracker is directly related to the effort the maintainers put in to keep it relatively pruned and organized. Maybe that is too much to expect for most maintainers at this time. On the other hand, maybe having the defect tracker option would lead to more community involvement. It wouldn't happen over night, but consistently directing people to the defect tracker would go a long way toward making the tracker valuable. As things currently stand, the mailing list option does not provide much to most people in the way of issue discovery, management, or tracking, even if it is great for discussions such as this. In any case, I just wanted to voice my support for using a defect tracker regardless of any arguments to do so. I'm already convinced that using one will be better. If you're not convinced, I don't think I have any evidence on hand to change your mind, and given the lack of popular support of this effort, perhaps you're right that a defect tracker still won't help Cygwin. -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: Bug tracker
On 08/19/2010 01:59 PM, Jeremy Bopp wrote: Of course the quality of the defect tracker is directly related to the effort the maintainers put in to keep it relatively pruned and organized. Maybe that is too much to expect for most maintainers at this time. Bingo. That's why I'm perfectly happy with mailing lists and no extra burden of a web-based tracker for the packages I maintain on my spare time. Why add overhead to a process that already works for me? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
rlwrap is ancient -- maintained?
The version of rlwrap in Cygwin is very old; the manpage dates it to 2005. Is the package still maintained? If not, does it need a new maintainer? :) -- 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: rlwrap is ancient -- maintained?
On 8/19/2010 5:02 PM, Daniel Colascione wrote: The version of rlwrap in Cygwin is very old; the manpage dates it to 2005. Is the package still maintained? If not, does it need a new maintainer? :) The listed maintainer is Mauricio Antune but my admittedly limited search for any recent activity on the list from him didn't turn up anything. Perhaps he's moved on. Or maybe he's still here lurking. It makes sense to check. Mauricio, you here? If so, are you willing to update rlwrap? Would you prefer Daniel take over? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On 2010-08-19 12:28, Eric Blake wrote: On 08/19/2010 08:43 AM, Corinna Vinschen wrote: Hmm, digging through Cygwin's readdir code, I have a vague idea. Eric, does find honor the struct dirent d_type flag? I'm wondering if d_type is erroneously set to DT_REG for some reason. If so, we could find this out by augmenting the debug output in the Cygwin DLL. find (but not oldfind) relies heavily on the d_type flag. If that flag is incorrect, it could explain why find gets lost. Could you repeat the experiment with 'oldfind' and see if that behaves better? oldfind displays all 100,000 files. -- 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
cron fails to start as a service in Win2k3R2 64bit
The only way I've been able to get cron running is manually by starting the crond via execution of cron.exe. Attached are my cygcheck.txt and crontab. I get the following error after I install and start the cron service... cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: Thanks very much for your time and consideration. Cygwin Configuration Diagnostics Current System Time: Thu Aug 19 11:44:38 2010 Windows 2003 Server R2 Ver 5.2 Build 3790 Service Pack 2 Running under WOW64 on AMD64 Running in Terminal Service session Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\ C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn\ Output from C:\cygwin\bin\id.exe UID: 500(Administrator) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'Administrator' PWD = '/home/Administrator' HOME = '/home/Administrator' HOMEPATH = '\Documents and Settings\Administrator' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\Administrator\Application Data' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'sm-i222' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'EM64T Family 6 Model 26 Stepping 5, GenuineIntel' WINDIR = 'C:\WINDOWS' OLDPWD = '/usr/bin' USERDOMAIN = 'SM-I222' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' USERNAME = 'Administrator' ClusterLog = 'C:\WINDOWS\Cluster\cluster.log' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\Administrator' CLIENTNAME = 'L-CM-BMILLER3' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\SM-I222' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'HP LaserJet 2200 Series PCL' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '1a05' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '8' SESSIONNAME = 'RDP-Tcp#1' COMPUTERNAME = 'SM-I222' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin a: fd N/AN/A c: hd NTFS285138Mb 5% CP CS UN PA FC d: hd NTFS 3812658Mb 47% CP CS UN PA FC Data e: fd N/AN/A g: cd N/AN/A C:\cygwin/ system binary,auto C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,auto Found: C:\cygwin\bin\awk Found: C:\cygwin\bin\awk - C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cp.exe Not Found: cpp (good!) Found: C:\cygwin\bin\crontab.exe Found: C:\cygwin\bin\crontab.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\find.exe Found: C:\WINDOWS\system32\find.exe Warning: C:\cygwin\bin\find.exe hides C:\WINDOWS\system32\find.exe Not Found: gcc Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\kill.exe Not Found: ld Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\ls.exe Not Found: make Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\mv.exe Not Found: patch Not Found: perl Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Found: C:\cygwin\bin\test.exe Found: C:\cygwin\bin\vi Found: C:\cygwin\bin\vi - C:\cygwin\bin\vim-nox.exe Found: C:\cygwin\bin\vim Found: C:\cygwin\bin\vim - C:\cygwin\etc\alternatives\vim - C:\cygwin\bin\vim-nox.exe 15k
Re: [ANNOUNCEMENT] Updated: vim-7.3.003-1
On 8/19/2010 11:54 AM, Corinna Vinschen wrote: I have updated the version of vim on cygwin.com to 7.3.003-1. This is an update to the new upstream version 7.3, including the first three patchsets. Cygwin Vim builds from the vanilla sources. After updating, /usr/bin/vi no longer exists. Is this intentional? If so, I'll figure out how to switch everything over to vim in my environment(s). -- David Rothenberger daver...@acm.org Immutability, Three Rules of: (1) If a tarpaulin can flap, it will. (2) If a small boy can get dirty, he will. (3) If a teenager can go out, he will. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
ChangeLog entry: 2010-08-19 Pedro Izecksohn pedro.izecks...@... * endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32) (htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64) (le16toh, le32toh, le64toh): Macros defined. I modified endian.h again: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 19 19:03:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,86 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE + + #include byteswap.h + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #endif /*__BYTE_ORDER == __LITTLE_ENDIAN*/ + + #if __BYTE_ORDER == __BIG_ENDIAN + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif /*__BYTE_ORDER == __BIG_ENDIAN*/ + + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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: [ANNOUNCEMENT] Updated: vim-7.3.003-1
On 8/19/2010 6:17 PM, David Rothenberger wrote: On 8/19/2010 11:54 AM, Corinna Vinschen wrote: I have updated the version of vim on cygwin.com to 7.3.003-1. This is an update to the new upstream version 7.3, including the first three patchsets. Cygwin Vim builds from the vanilla sources. After updating, /usr/bin/vi no longer exists. Is this intentional? If so, I'll figure out how to switch everything over to vim in my environment(s). Isn't all you are missing a link to the vim binary from /usr/bin/vi? Given that this has been supported in the past I am guessing it's an oversight. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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: cygwin 1.7.6: find skipping over some directories on NTFS mount points
Greetings, Corinna Vinschen! I checked the strace, and after ascending back from the ATI subdir into the toplevel dir successfully, find appears to exit just so, without any trace that it even *tries* to continue to scan further subdirs. And unfortunately there's no way to see why find thinks there's nothing to do anymore. If ATI is the junction (reparse point, or however you call it) to a top-level directory on another partition, this behavior could be explained by exiting through the window: process enter the partition from the doors (junction), dig it, then trying to exit from real path, which is, indeed, at the root of partition. So the process finds itself at the top-level and gracefully dies considering work done. A wild guess, however. -- WBR, Andrey Repin (anrdae...@freemail.ru) 20.08.2010, 2:33 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: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On 2010-08-19 18:37, Andrey Repin wrote: If ATI is the junction (reparse point, or however you call it) to a top-level directory on another partition, this behavior could be explained by exiting through the window: process enter the partition from the doors (junction), dig it, then trying to exit from real path, which is, indeed, at the root of partition. So the process finds itself at the top-level and gracefully dies considering work done. A wild guess, however. Unfortunitely, ATI is not the reparse point. The root of the mounted file system is the 3 directory where ATI sits. -- 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: last email
On 8/17/2010 6:07 AM, Global International wrote: Hi Dear, Please confirm if you received my last email and provide me your direct phone number for more discussions. Yours truly, Mr. David Brown Global International Discuss what? -- 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: last email
On Thu, Aug 19, 2010 at 8:31 PM, Jacob Jacobson n...@biyani.org wrote: On 8/17/2010 6:07 AM, Global International wrote: Hi Dear, Please confirm if you received my last email and provide me your direct phone number for more discussions. Yours truly, Mr. David Brown Global International Discuss what? -- Hello! It's an e-mail blast sent out to every single address they could find on the Internet. Problem being is that the people behind them are getting desperate because most of us are ignoring their desperate e-mail attempts for attention. Incidentally partner this is technically very off-topic for this list so we should drop it now from the list. If you're interested we can continue to discuss it off-list. - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. -- 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: last email
On 8/19/2010 8:31 PM, Jacob Jacobson wrote: On 8/17/2010 6:07 AM, Global International wrote: Hi Dear, Please confirm if you received my last email and provide me your direct phone number for more discussions. Yours truly, Mr. David Brown Global International Discuss what? Please do not feed the trolls. -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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
build cygwin apps on linux
I've looked through the archives and saw some messages about building a cross-compiler to build cygwin apps on linux, but most of those messages/articles are pretty old. Has anyone done this recently with more recent GCC and Cygwin versions? Thanks, slide -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: build cygwin apps on linux
I've build gcc 4.4.0 for arm in cygwin. 2010/8/20 Slide slide.o@gmail.com: I've looked through the archives and saw some messages about building a cross-compiler to build cygwin apps on linux, but most of those messages/articles are pretty old. Has anyone done this recently with more recent GCC and Cygwin versions? Thanks, slide -- 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 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: last email
On Thu, Aug 19, 2010 at 08:40:44PM -0400, Gregg Levine wrote: On Thu, Aug 19, 2010 at 8:31 PM, Jacob Jacobson n...@biyani.org wrote: On 8/17/2010 6:07 AM, Global International wrote: Hi Dear, Please confirm if you received my last email and provide me your direct phone number for more discussions. Yours truly, Mr. David Brown Global International Discuss what? -- Hello! It's an e-mail blast sent out to every single address they could find on the Internet. Problem being is that the people behind them are getting desperate because most of us are ignoring their desperate e-mail attempts for attention. Incidentally partner this is technically very off-topic for this list so we should drop it now from the list. If you're interested we can continue to discuss it off-list. It's called spam. It hardly needs an explanation and it is really word deleted to respond to it or discuss it in a public mailing list. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: build cygwin apps on linux
On Thu, Aug 19, 2010 at 06:18:11PM -0700, Slide wrote: I've looked through the archives and saw some messages about building a cross-compiler to build cygwin apps on linux, but most of those messages/articles are pretty old. Has anyone done this recently with more recent GCC and Cygwin versions? Yes. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
USB Drive Letter Manager (Small adverticement. Sorry if you find it abusive.)
Greetings, All! I've been pointed to this (without a doubt) exceptional piece of software. http://www.uwe-sieber.de/usbdlm_e.html I'm toying with it now, but what I find in it, what would be most attractive to the Cygwin community, is it's ability to mount removable drives as NTFS reparse points. However, it is not coming without a certain drawbacks, so read the shipped help file carefully before use. USBDLM is Freeware for private and educational (schools, colleges, universities) use only. -- WBR, Andrey Repin (anrdae...@freemail.ru) 20.08.2010, 5:27 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: USB Drive Letter Manager (Small adverticement. Sorry if you find it abusive.)
On Fri, Aug 20, 2010 at 05:37:31AM +0400, Andrey Repin wrote: I've been pointed to this (without a doubt) exceptional piece of software. http://www.uwe-sieber.de/usbdlm_e.html I'm toying with it now, but what I find in it, what would be most attractive to the Cygwin community, is it's ability to mount removable drives as NTFS reparse points. However, it is not coming without a certain drawbacks, so read the shipped help file carefully before use. USBDLM is Freeware for private and educational (schools, colleges, universities) use only. This doesn't really seem to have anything to do with Cygwin. I wouldn't want to start encouraging the advertisement of nifty windows utilities here. That's really not what this mailing list is for. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin 1.7.6: df shows wrong (different?) drive information
When I run df -h dir where dir is part of a native-NTFS-mounted-drive, then df prints details about the root drive (not the mounted drive). This acts differently if the drive is *also* mounted as a separate top-level drive. In that case, if you specify the mount point itself, it prints information about the root drive, but if you specify any subdir, then it prints the correct drive information. For example (not actual output): Drive 0, 100G: mounted as C:\ Drive 1, 200G: mounted as C:\1 Drive 2, 300G: mounted as C:\2 and D:\ df -h /cygdrive/c = 100G df -h /cygdrive/c/1 = 100G df -h /cygdrive/c/1/subdir = 100G df -h /cygdrive/c/2 = 100G df -h /cygdrive/c/2/subdir = 300G In cygwin 1.7.5, the output was 100G, 200G, 200G, 300G, and 300G respectively. I should point out that I'm still using that special snapshot Corinna made for me, not the stock 1.7.6. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: build cygwin apps on linux
On Thu, Aug 19, 2010 at 6:23 PM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Thu, Aug 19, 2010 at 06:18:11PM -0700, Slide wrote: I've looked through the archives and saw some messages about building a cross-compiler to build cygwin apps on linux, but most of those messages/articles are pretty old. Has anyone done this recently with more recent GCC and Cygwin versions? Yes. cgf -- Do you have a list of steps you took or what packages you needed? I'd like to build a cross compiler that I can use on my Linux box that has the same GCC version and same Cygwin packages as the current Cygwin releases. Thanks, slide -- 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: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
libtirpc is an updated version of the Sun RPC library. As such, it replaces part of the (orphaned) sunrpc package -- just as on linux, it replaces the built-in RPC routines in glibc: http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php You should update sunrpc, if installed, to 4.0-4 or above. The headers are installed into /usr/lib/tirpc/rpc/* and not /usr/lib/rpc/ As a consequence, developers must add -I/usr/lib/tirpc when compiling RPC clients and servers on cygwin. Similarly, linking requires -ltirpc. However, this is the same procedure used on linux -- so any client that has already been taught how to accept tirpc on linux will be fine on cygwin. This version is compiled without the XDR routines, as cygwin-1.7.2+ provides those routines internally. It is compiled without AUTH_DES support (that is, cygwin libtirpc is not NIS-aware, because there is not yet any cygwin NIS server or client; since NIS requires a portmap or rpcbind implementation, we have a bit of a chicken/egg issue). Also, it is compiled without GSS_API support, because the official cygwin distribution does not yet contain any Kerboros implementation. Thus, this version of libtirpc supports only unencrypted communication. However, MOST uses of RPC are unencrypted, so this shouldn't be a big deal. Official PR blurb: -- This package contains SunLib's implementation of transport-independent RPC (TI-RPC) documentation. This library forms a piece of the base of Open Network Computing (ONC), and is derived directly from the Solaris 2.3 source. TI-RPC is an enhanced version of TS-RPC that requires the UNIX System V Transport Layer Interface (TLI) or an equivalent X/Open Transport Interface (XTI). TI-RPC is on-the-wire compatible with the TS-RPC, which is supported by almost 70 vendors on all major operating systems. TS-RPC source code (RPCSRC 4.0) remains available from several internet sites. -- Charles Wilson volunteer libtirpc maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
NEW: rpcgen-2.11.90_20100818-1
rpcgen is a tool that generates C code to implement an RPC protocol. The input to rpcgen is a language similar to C known as RPC Language (Remote Procedure Call Language). This package replaces a component of the (soon-to-be-obsolete) sunrpc package; you should update sunrpc to the 4.0-4 version if you have it installed. This implementation of rpcgen is derived from the eglibc SVN. Note that rpcgen requires /usr/bin/cpp -- but that program, the C PreProcessor, may be supplied by either the gcc-core or the gcc4-core package. Given this ambiguity, neither package is explicitly required, and neither will be automatically installed. It is up to the user to ensure that some version of gcc is installed, if rpcgen is to operate correctly. Also, note that due to a packaging error, 'rpcgen --version' will report 'rpcgen (cygwin-special) 2.12.90' -- even though this release claims to be version 2.11.90_20100818. This discrepancy will be corrected in a future release. -- Charles Wilson volunteer rpcgen maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
