Re: submission rules page proposal number 3
On Jan 23 21:57, Lapo Luchini wrote: Corinna Vinschen wrote: webmaster#64;example#46;com Neat. I did that way. Looks good except for the boffo and libboffo7 setup.hint examples. Thanks for the proof-reading. While you're at it, could you add the Perl and Python categories? Sure. Heh, I'm just curious when we will get the first mail with the exact subject [ITP] foo 0.10 :-) FWIW, it will be 15 february 2006. Lapo PS: updates always at http://cyberx.lapo.it/~lapo/setup.html FYI, I was going to upload the new setup.html file, but I can't access your server right now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Updated: coreutils-5.93-2 [Attn base-files maintainer]
On Tue, 24 Jan 2006, Eric Blake wrote: [snip] An unrelated comment: Due to reinstating su.exe, coreutils now depends on crypt. To date, no package in Base has had a dependency on crypt, so the new coreutils does increase the size of the minimal cygwin install. Speak up now if anyone has heartburn with this. Gasp! How will I live with those extra 48k on my disk? We might want to move crypt into Base, though... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac
please upload clisp 2.38
please upload clisp 2.38, keeping 2.37 as previous. http://www.podval.org/~sds/clisp/clisp-2.38-1.tar.bz2 http://www.podval.org/~sds/clisp/setup.hint http://www.podval.org/~sds/clisp/clisp-2.38-1-src.tar.bz2 thanks. -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.memri.org http://www.dhimmi.com http://truepeace.org http://pmw.org.il http://ffii.org http://www.jihadwatch.org Flying is not dangerous; crashing is.
Re: please upload clisp 2.38
On Jan 24 12:27, Sam Steingold wrote: please upload clisp 2.38, keeping 2.37 as previous. http://www.podval.org/~sds/clisp/clisp-2.38-1.tar.bz2 http://www.podval.org/~sds/clisp/setup.hint http://www.podval.org/~sds/clisp/clisp-2.38-1-src.tar.bz2 Uploaded and 2.36-1 removed. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: submission rules page proposal number 3
Corinna Vinschen wrote: FYI, I was going to upload the new setup.html file, but I can't access your server right now. Yes, my home ADSL seem to have misbehaved for some hours yesterday (11:00-17:00 circa). It should now work (well, if you receive this message, it certainly does ^_^). Lapo
Attn: WindowMaker Maintainer
Hi, I tried to compile and update my windowmaker installation(0.90-2), with 0.92 it needed a patch to the configure.ac script so that it installs correctly. If u want i will send the patch. Could you please update WindowMaker to the latest, 0.92.0? If you want i will package it for u and send it to you for review? Thanks and Regards, Vijay -- 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/
my keyboard layout
(--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: E0200411 (0411) (EE) Keyboardlayout Microsoft IME Standard 2003 (E0200411) is unknown (--) 3 mouse buttons found -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin ChangeLog ntdll.h
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2006-01-25 05:57:20 Modified files: cygwin : ChangeLog ntdll.h Log message: * ntdll.h: (temporarily?) Add more functions for querying directory. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3352r2=1.3353 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ntdll.h.diff?cvsroot=uberbaumr1=1.33r2=1.34
Re: gdb problem - cygwin-1.5.19-4
Thanks, I totally forgot to look in the mailing list archive. Yann COLLETTE -- Disclaimer Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme. *** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system.
Re: apache 1.3.34 can not compile anymore
[EMAIL PROTECTED] wrote: The second one points out that this is apache problem, but I compiled apache 1.3.34 tens of times for cygwin in the past months (last compile 1-2 months ago) without any problem. Just because Cygwin changed does not mean it's not an Apache problem. Cygwin added an implementation of getline() where there was not one before. But Apache's build system makes false assumptions about this function not existing, so it blindly tries to use its own included version. This is the whole point of autoconf, to test for functionality on the platform and act accordingly. If Apache tries to use its own getline() when one exists in the system library then it is broken and needs to be fixed. Could anybody tell me how can I roll back to cygwin 1-5-18, so that I can work until this is resolved? Select the desired version of the cygwin package in setup.exe. However, by doing this you just exacerbate the problem so that it continues to exist. What needs to happen is for users of Apache to report this deficiency in its build system to the developers so that future versions of Apache can be fixed. Consider filing a PR at http://issues.apache.org/bugzilla/ or posting on their mailing list. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache 1.3.34 can not compile anymore
Tried to roll back to 1.5.18-1 from the setup.exe, but now I get 10s of error messages from packages who do not find getline in the cygwin dll. Horror... Could anybody help me to compile apache 1.3.34 under cygwin with this getline change? I need it compiled because of php and related stuff. Thank you, Iv -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache 1.3.34 can not compile anymore
Hi, thanks for the quick answer! Select the desired version of the cygwin package in setup.exe. Yes. Tried and now everything explodes crying for getline. However, by doing this you just exacerbate the problem so that it continues to exist. What needs to happen is for users of Apache to report this deficiency in its build system to the developers so that future versions of Apache can be fixed. Consider filing a PR at http://issues.apache.org/bugzilla/ or posting on their mailing list. Sounds reasonable. I'll try that. I just hope I will not lose my job until cygwin and apache show each other whose system what deficiencies has... Iv -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache 1.3.34 can not compile anymore
[EMAIL PROTECTED] wrote: Tried to roll back to 1.5.18-1 from the setup.exe, but now I get 10s of error messages from packages who do not find getline in the cygwin dll. You would have to also use a previous version of any programs that need getline(). I think this includes findutils and coreutils. Could anybody help me to compile apache 1.3.34 under cygwin with this getline change? I need it compiled because of php and related stuff. The patch in PR9894 is more or less what you want. It won't apply cleanly to 1.3.34 since it was generated against 1.3.24, but you get the idea. You could also do something like #define getline ap_getline at the top of each of those three files, but the define would have to come after stdio.h has been included. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache 1.3.34 can not compile anymore
Brian Dessent wrote: [EMAIL PROTECTED] wrote: Tried to roll back to 1.5.18-1 from the setup.exe, but now I get 10s of error messages from packages who do not find getline in the cygwin dll. You would have to also use a previous version of any programs that need getline(). I think this includes findutils and coreutils. Could anybody help me to compile apache 1.3.34 under cygwin with this getline change? I need it compiled because of php and related stuff. The patch in PR9894 is more or less what you want. It won't apply cleanly to 1.3.34 since it was generated against 1.3.24, but you get the idea. You could also do something like #define getline ap_getline at the top of each of those three files, but the define would have to come after stdio.h has been included. Brian Hi Brian, thanks for the help. I submitted a bug at apache - http://issues.apache.org/bugzilla/show_bug.cgi?id=38364 Now trying to compile apache 2.2.0 and depending on the result I'll try your suggestions as well, though I need something stable and I do not like to dive into patches. It's kind of shocking situation, but I guess it could not have been avoided. Thanks again, Iv -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
AutoNotify: Error
NAA is stripping all attachments that could contain a virus. If you receive this message and are trying to send a .zip attachment to someone at NAA, please reply to this message with the .zip file attached or send the message to [EMAIL PROTECTED] and we will forward the message to the intended recipient ([EMAIL PROTECTED]). The particulars of the message in question are as follows: Sender of the message: [EMAIL PROTECTED] The intended recipient of the message: [EMAIL PROTECTED] The subject line of the message: Error Message Received on 1/24/2006 at 3:47:38 AM -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re:
Corinna Vinschen corinna-cygwin at cygwin.com writes: Thanks. May I assume that the remote directory is on a NT4 based NTFS? Corinna I would not have thought so, but after asking our it-staff, I got it confirmed. We are running NT4 on the servers. I must say I am curious. How could you deduce that from the output? /jbm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
HELP: cygwin setup.exe woes...
I downloaded cygwin (setup.exe) and ran it. I clicked on the Default text beside Interpreters and it changed to Install meaning that I get the full Interpreters category to be downloaded. I downloaded without installing. Once completed I ran the setup.exe and installed cygwin from local folder. Once fully installed, I deleted the temporary downloaded files (which was around 100-200MB). Next day I decided that I needed cvs cvs-utils so I downloaded cygwin (setup.exe) file again. Ran it, but this time selected cvs cvs-utils from the Development category. I left it to download without installing. The download took seconds and the files downloaded was only 26MB. Hmm, I then installed my new downloaded files and it was successfully. Hmm, has cygwin remembered what I previously downloaded? How? I deleted all temporary downloaded files on my first download (no more setup.ini, or log files, etc.). Has it stored the setup.ini somewhere else? or even in registry? I delete my temporary downloaded files (1st and 2nd times). Now I want to download a complete cygwin (Interpreters, Development, etc.) however it won't do that. All I get is 10MB downloaded files. Somehow it has remembered my previous downloads... How can I get around this? Cygwin never used to do this? or did it?? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Serial port hangs unless I run Hyperterminal?
Thanks all for your replies - I looked into errno - will be useful for future issues. Thanks to Eric, found my problem was although Cygwin happy with using port labelled COM1 (and presumably picking up Windows settings thereof - hence their changing after Hyperterminal), it couldn't do the tcgetattr and tcsetattr for that port successfully. Using the correct POSIX labelled port of /dev/ttyS0 allowed get and set to work perfectly in C! Thanks all! Andy Burgess -- __ __ __ __ __ ___ _ |__||__)/ __/ \|\ ||_ | / | || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines ___/ [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ssh starting problems.
Did you use /usr/bin/ssh-host-config to set up sshd on the Win 2003 server? Currently I am running sshd on two such servers and set them up using the script. The script should detect that you are using Win 2003 and will ask if you want it to create a sshd_server user account and assign the privileges it needs under Local Security Policy to run properly. The sshd service should then be run under this account. ssh was setup using ssh-host-config and worked correctly. I then upgraded cygwin by removing it and reinstalling it. In this process the sshd_server account was not deleted and was not recreated either. This caused the problems that occured. I just removed the sshd_server user and then ran ssh-host-config again and all worked as it should. Thanks for your help! Although it's possible to set up/install sshd manually with cygrunsrv, IMHO the script is just simpler. Cheers, Herman -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re:
On Jan 24 09:04, Jonas M?ls? wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: Thanks. May I assume that the remote directory is on a NT4 based NTFS? I would not have thought so, but after asking our it-staff, I got it confirmed. We are running NT4 on the servers. I must say I am curious. How could you deduce that from the output? The values of the flags are a hint ;-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: curses.h (Attn: bash and setup maintainers)
In any case, looks like all the postinstall scripts ran for you, so you should be good to go. Hi Igor, So do you think that I broke CGDB somehow? When I compile and run it on Cygwin, it's display in the terminal is not correct. However, if I run a pre-compiled older version, it's display is fine. I'm going to build an older version today, and see if it still works. Thanks, Bob Rossi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: replaced while being copied - was ... RE: Solved partially by findutils 4.3 - RE: inode changed, ...
On Jan 23 17:12, Jan Schormann wrote: You wrote on Monday, January 23, 2006 4:24 PM: On Jan 23 13:34, Jan Schormann wrote: ... Thanks. You didn't reply to my other question, though. What filesystem exactly is on the remote side? I'm not familar with the above combination of values. This doesn't look like any native NTFS system, nor does it look like a Samba share, AFAICS. Corinna, to be honest, I haven't the faintest. This is a NetApp filer which is controlled by our IT staff. I will ask them, but I don't really expect any more concrete information than what you get when you google for cifs site:netapp.com (hints I gathered from within our intranet - cifs=common internet file system, looks like another M$ invention), of which I just can't make any sense apart from this: The OS is called Data ONTAP, and it is capable of exporting volumes as NFS and CIFS at the same time. CIFS volumes can then get NetBIOS aliases, which seems to be what I see from my client. The documentation mentions that the volumes on the filer are initially of type FlexVol, which seems to be an invention of NetApp. This is probably not enough to understand what's happening here, particularly if you haven't got a NetApp filer around for testing. In that case I'm inclined to give up for now and apologize for the noise, because I can live without cp'ing exes from the share. No, I think that's enough for now. As suggested by somebody on this list some weeks ago, I will change the condition on which I use the real inode number instead of faking the inode number using a hash value depending on the FILE_SUPPORTS_OBJECT_IDS flag, except for Samba file systems. This should lower the chance to get unreliable inode numbers. Otherwise, I'm always glad to get the file system flags returned by other remote file systems, to raise the chance to get reliable inode numbers. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: PostgreSQL 8.1.2 crashes diring import...
I see in your previous mail, that your cygserver SHM settings are already at the maximum. Hope that your have that much RAM/Virtual Memory. The previous error was an interrupted call error 2, which is not the case with your problem. Jason's Problem: 3 [main] postmaster 1144 transport_layer_pipes::connect: lost connection to cygserver, error = 2 ... FATAL: could not create shared memory segment: Interrupted system call DETAIL: Failed system call was shmget(key=5432001, size=8970240, 03600). Your problem: 9 [main] postmaster 656 transport_layer_pipes::connect: lost connection to cygserver, error = 121 Can you try running cygserver with -d. For testing best started from the console, not as service. Maybe within a sysbash to have the same permissions. BTW: My cygwin packages 8.06 and 8.1.2 to test against are at the setup User Url: http://xarch.tu-graz.ac.at/publ/cygwin/ I haven't tested yet such a big 3-4GIG import, a huge index might need more than with 8.0, but the heavy and parallel regressions do all pass so far. Adding to my own message. Just found this, which is from two years ago and reflects on the same problem - http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00014.html This e-mail says that cygserver simply exits upon high load upon PostgreSQL. This e-mail says that the problem is fixed - http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00179.html Could it be that the problem has come back? Could be but I doubt it. -- Reini Urban http://phpwiki.org/ http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: curses.h (Attn: bash and setup maintainers)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Igor Peshansky on 1/23/2006 9:34 AM: Most of the messages are diagnostics to track script progress. The only exceptions are the lines below: ./00bash.sh.done: line 12: ./01bash.bat: No such file or directory cp: cannot stat `./01bash.bat.t': No such file or directory rm: cannot remove `./01bash.bat.t': No such file or directory The first set is from 00bash.sh (it should probably have a test for the existence the .bat file). Also, in-place edits should work just fine (using 'sed -i -e /^echo/d; s,REM BASHPATH,$bashpath, 01bash.bat'). Duly noted; bash-3.1-2 will improve on this situation (whenever I get time to get that working; I'm still struggling with gracefully incorporating upstream patches without wiping them out by rerunning g-b-s prep). Actually, now that setup.exe has been updated to use /bin/bash and not /bin/sh, the technical reason for me needing two postinstall scripts in the first place has been overcome, so I may just simplify back to a single script that does it all, rather than staging it through a .bat. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin bash maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD1jCE84KuGfSFAYARAgvbAKDEPHTTQYO9+f3eu3/aM2MSS73rwgCfWnNr shMfcHDYKpSMS8n2Sf8eQFY= =oSza -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Prompt issue within cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Igor Peshansky on 1/23/2006 4:18 PM: I'm trying to get this prompt to work: PS1=\[\033]61;[EMAIL PROTECTED]@\H \W but the issue there is that the is duplicated (just like the space above, but much more noticable). Any ideas as to why making the title modification to use [EMAIL PROTECTED] instead of \w is causing these issues? Shoot - the bug is still not fixed upstream; I reproduced it with bash-3.1-1, readline-5.1-1, and rxvt-2.7.10-6. One of these days, I hope to be able to sit down and figure out where readline is going wrong (it is either a readline bug, or a bug in the terminfo database), but it is painful to debug. There is a prompt bug in bash that causes it to miscount the number of displayed characters. One workaround was to append '\[\]' to PS1. Also, a good habit to get into is to use single quotes in the shell when some value contains backslashes. Unfortunately, appending \[\] to PS1 no longer works with readline-5.1, since upstream fixed readline to recognize that an empty non-printing sequence has no effect on the location of the last non-printing character. However, I think I might be able to recussitate my readline-5.0 hack that forcefully treats a single-line prompt with non-printing characters as though it had a \[\] appended (and I hope I can make it work at a lower level then where empty \[\] is stripped from PS1). It may be a while, but I plan on providing readline-5.1-2 that works around this nasty prompt bug as soon as I can. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin readline maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD1jXV84KuGfSFAYARAkqDAKCGrQ9L51s8L2WJ0+TqgXifgbyIcgCgub9/ EgP3PKUv/8VzxRwWmDvAu84= =16wn -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: find problem: cygwin-1.5.19-4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to COLLETTE Yann on 1/24/2006 12:38 AM:
$ find . -name *.o -exec rm {} \; -print
find: /cygdrive/g/MAPAO/Meta-c++/Experiment/CVS changed during execution
of find (old inode number -411248424, new inode
number -397277624, filesystem type is user) [ref 1114]
find: /cygdrive/g/MAPAO/Meta-c++/Experiment/CVS changed during execution
of find (old inode number -403922104, new inode
number -386873840, filesystem type is user) [ref 1114]
Sounds like a repeat question. Could you please follow the directions here:
http://cygwin.com/ml/cygwin/2006-01/msg00818.html
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
volunteer cygwin findutils maintainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD1jaH84KuGfSFAYARAoGwAJ9sZEH8pJRtyOEqEuUHr01AGyIyigCdEnGP
i3k2+3Toxqh9BEm8GF3WnKo=
=Bbus
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: HELP: cygwin setup.exe woes...
On Tue, 24 Jan 2006, KevinGPO wrote: [snip] Now I want to download a complete cygwin (Interpreters, Development, etc.) however it won't do that. All I get is 10MB downloaded files. Somehow it has remembered my previous downloads... How can I get around this? Cygwin never used to do this? or did it?? Heh, if you think these are woes, you should see the complaints about the Uncaught Exception... :-) Setup is primarily an installer, not a download tool. As such, it won't even bother downloading packages that are already installed on the system. It knows what's installed by looking at /etc/setup/installed.db in your Cygwin tree. So, the simplest way to get it to temporarily forget what it has previously downloaded is to rename installed.db while downloading. Setup should re-create it, but if you only download (and not install) things, the new copy will be empty and can be replaced by the old. I wouldn't recommend actually installing anything with no installed.db, as it wouldn't be trivial to bring your system to a consistent state afterwards. One other thing that seemed weird is you first downloading and then installing packages. If all you want is to install things, setup can do it in one shot (still retaining the cached download directory). HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HELP: cygwin setup.exe woes...
On Tue, 24 Jan 2006, Igor Peshansky wrote: On Tue, 24 Jan 2006, KevinGPO wrote: [snip] Now I want to download a complete cygwin (Interpreters, Development, etc.) however it won't do that. All I get is 10MB downloaded files. Somehow it has remembered my previous downloads... How can I get around this? Cygwin never used to do this? or did it?? Heh, if you think these are woes, you should see the complaints about the Uncaught Exception... :-) Setup is primarily an installer, not a download tool. As such, it won't even bother downloading packages that are already installed on the system. It knows what's installed by looking at /etc/setup/installed.db in your Cygwin tree. So, the simplest way to get it to temporarily forget what it has previously downloaded is to rename installed.db while downloading. ^ s/while/before/ Setup should re-create it, but if you only download (and not install) things, the new copy will be empty and can be replaced by the old. I wouldn't recommend actually installing anything with no installed.db, as it wouldn't be trivial to bring your system to a consistent state afterwards. One other thing that seemed weird is you first downloading and then installing packages. If all you want is to install things, setup can do it in one shot (still retaining the cached download directory). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: curses.h (Attn: bash and setup maintainers)
On Tue, 24 Jan 2006, Eric Blake wrote: According to Igor Peshansky on 1/23/2006 9:34 AM: Most of the messages are diagnostics to track script progress. The only exceptions are the lines below: ./00bash.sh.done: line 12: ./01bash.bat: No such file or directory cp: cannot stat `./01bash.bat.t': No such file or directory rm: cannot remove `./01bash.bat.t': No such file or directory The first set is from 00bash.sh (it should probably have a test for the existence the .bat file). Also, in-place edits should work just fine (using 'sed -i -e /^echo/d; s,REM BASHPATH,$bashpath, 01bash.bat'). Duly noted; bash-3.1-2 will improve on this situation (whenever I get time to get that working; I'm still struggling with gracefully incorporating upstream patches without wiping them out by rerunning g-b-s prep). Does http://cygwin.com/ml/cygwin-apps/2006-01/msg00064.html make sense? Actually, now that setup.exe has been updated to use /bin/bash and not /bin/sh, the technical reason for me needing two postinstall scripts in the first place has been overcome, so I may just simplify back to a single script that does it all, rather than staging it through a .bat. You can't, unfortunately. Some people may have older versions of setup.exe on their systems, and blatantly disregard setup's warning that a newer version is available. Those systems will then fail to install sh properly. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: find problem: cygwin-1.5.19-4
Hello,
The result is the following:
$ ./test.exe /cygdrive/g/MAPAO/Meta-c++/
rootdir: g:\
Volume Name: CIFS.HOMEDIR
Serial Number : 0
Max Filenamelength : 255
Filesystemname : NTFS
Flags:
FILE_CASE_SENSITIVE_SEARCH : TRUE
FILE_CASE_PRESERVED_NAMES : TRUE
FILE_UNICODE_ON_DISK: TRUE
FILE_PERSISTENT_ACLS: TRUE
FILE_FILE_COMPRESSION : FALSE
FILE_VOLUME_QUOTAS : FALSE
FILE_SUPPORTS_SPARSE_FILES : FALSE
FILE_SUPPORTS_REPARSE_POINTS: FALSE
FILE_SUPPORTS_REMOTE_STORAGE: FALSE
FILE_VOLUME_IS_COMPRESSED : FALSE
FILE_SUPPORTS_OBJECT_IDS: FALSE
FILE_SUPPORTS_ENCRYPTION: FALSE
FILE_NAMED_STREAMS : TRUE
FILE_READ_ONLY_VOLUME : FALSE
Your sincerely,
Yann COLLETTE
Eric Blake a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to COLLETTE Yann on 1/24/2006 12:38 AM:
$ find . -name *.o -exec rm {} \; -print
find: /cygdrive/g/MAPAO/Meta-c++/Experiment/CVS changed during execution
of find (old inode number -411248424, new inode
number -397277624, filesystem type is user) [ref 1114]
find: /cygdrive/g/MAPAO/Meta-c++/Experiment/CVS changed during execution
of find (old inode number -403922104, new inode
number -386873840, filesystem type is user) [ref 1114]
Sounds like a repeat question. Could you please follow the directions here:
http://cygwin.com/ml/cygwin/2006-01/msg00818.html
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
volunteer cygwin findutils maintainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD1jaH84KuGfSFAYARAoGwAJ9sZEH8pJRtyOEqEuUHr01AGyIyigCdEnGP
i3k2+3Toxqh9BEm8GF3WnKo=
=Bbus
-END PGP SIGNATURE-
-- Disclaimer
Ce message ainsi que les eventuelles pieces jointes constituent une
correspondance privee et confidentielle a l'attention exclusive du destinataire
designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une
personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute
divulgation, distribution ou copie de cette transmission est strictement
interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en
informer l'expediteur par telephone ou de lui retourner le present message,
puis d'effacer immediatement ce message de votre systeme.
***
This e-mail and any attachments is a confidential correspondence intended only
for use of the individual or entity named above. If you are not the intended
recipient or the agent responsible for delivering the message to the intended
recipient, you are hereby notified that any disclosure, distribution or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify the sender by phone or by replying this
message, and then delete this message from your system.
Re: curses.h
On Tue, 24 Jan 2006, Bob Rossi wrote: In any case, looks like all the postinstall scripts ran for you, so you should be good to go. Hi Igor, So do you think that I broke CGDB somehow? When I compile and run it on Cygwin, it's display in the terminal is not correct. However, if I run a pre-compiled older version, it's display is fine. I'm going to build an older version today, and see if it still works. There are multiple possibilities. Many Cygwin packages have Cygwin-specific patches to compensate for either upstream non-portability or Cygwin's idiosyncracies. It's also possible that you just need to re-run configure for the newer version, as the old run may not have picked up the right libraries due to your installation mishap. Did a clean build fail for you too? Do you get the same problems when setting TERM to something widely used, e.g., ansi or xterm? Do you get the same problem in rxvt? Alternatively, something may have indeed changed in either CGDB or Cygwin that caused a bug to manifest. I think at this point we veered off the original topic of this thread... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ssh starting problems.
On Tue, 24 Jan 2006, JC Oosthuizen wrote: Did you use /usr/bin/ssh-host-config to set up sshd on the Win 2003 server? Currently I am running sshd on two such servers and set them up using the script. The script should detect that you are using Win 2003 and will ask if you want it to create a sshd_server user account and assign the privileges it needs under Local Security Policy to run properly. The sshd service should then be run under this account. ssh was setup using ssh-host-config and worked correctly. I then upgraded cygwin by removing it and reinstalling it. In this process the sshd_server account was not deleted and was not recreated either. This caused the problems that occured. I just removed the sshd_server user and then ran ssh-host-config again and all worked as it should. Ah, this is a clue. By removing Cygwin, you probably also removed /etc/passwd. AIUI, without sshd_server in /etc/passwd, user context switching won't work. Re-running ssh-host-config added sshd_server to /etc/passwd again. I'm not too well-versed in the details of ntsed -- Corinna should be able to confirm or deny the above. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: PostgreSQL 8.1.2 crashes diring import...
Reini Urban wrote: I see in your previous mail, that your cygserver SHM settings are already at the maximum. Hope that your have that much RAM/Virtual Memory. I did this just desperately looking for solution, but seems the problem is not there. Your problem: 9 [main] postmaster 656 transport_layer_pipes::connect: lost connection to cygserver, error = 121 Can you try running cygserver with -d. For testing best started from the console, not as service. Maybe within a sysbash to have the same permissions. Yes, I did that but did not include it in the e-mail, as I did not see anything meaningful there (no obvious error message). I'll do it again and send it to the list in the next 2-3 days (lost time the last 1-2 days with this). BTW: My cygwin packages 8.06 and 8.1.2 to test against are at the setup User Url: http://xarch.tu-graz.ac.at/publ/cygwin/ I went back to 8.0.4. I need something which I understand how it happens and why. Thanks, however. I haven't tested yet such a big 3-4GIG import, a huge index might need more than with 8.0, but the heavy and parallel regressions do all pass so far. OK I'll do the -d option and then we will see if we can do something. Thanks for your input, Iv -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Need information about data and bss segment address access in cygwin
[Note TOP posting is not the preferred way on this group. I can't be bothered
to reformat it all - so look back on the thread for the full context.]
Sudhahar wrote:
Thanks Cliff/Dave. I could not find the code where the dll data/bss
segments address are updated in cygwin. But in the fork code we are
doing a copy for all linked and loaded dlls data/bss segments by
giving the address as
for (dll *d = dlls.istart (DLL_LINK); d; d = dlls.inext ())
{
debug_printf (copying data/bss of a linked dll);
if (!fork_copy (pi, linked dll data/bss, d-p.data_start,
d-p.data_end,
d-p.bss_start, d-p.bss_end,
NULL))
goto cleanup;
}
and
for (dll *d = dlls.istart (DLL_LOAD); d; d = dlls.inext ())
{
debug_printf (copying data/bss for a loaded dll);
if (!fork_copy (pi, loaded dll data/bss, d-p.data_start,
d-p.data_end,
d-p.bss_start,
d-p.bss_end,
NULL))
goto cleanup;
}
And also please let me know if there exist any document which gives
some idea about this.
Brian Dessent wrote:
There is no code to update them. As the other replies have already
said, they act like labels and are established by the linker via the
linker script. When the program runs, they contain the address, that's
it. The values in the per_process struct are filled in by the startup
code in _cygwin_crt0_common.cc.
The 'ld' manual, section 3.5.3.
Sudahar wrote:
Brian,
From your comments I understand that dll data/bss segment
address is same as that of process data/bss segment
address(data_start, data_end, bss_start and bss_end) when the process
is loaded. Is that right
[I am not 100% confident I'm right her, but...] Each cygwin dll has its own
separate data and bss segments, and the linker generates _data_start__ etc
symbols for the dll when the dll is linked, just as it does for a normal
.exe. The dll initialisation code, which you will find in
winsup/cygwin/dcrt0.cc, copies the addresses of these symbols into
the dll structures (d-...) which is used during fork as you quoted above.
Hope that helps.
-- Cliff
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated [experimental]: coreutils-5.93-3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of coreutils, 5.93-3, is available for experimental use. NEWS: = I've uploaded a test version of coreutils, 5.93-3. This is a minor patch release from 5.93-2. I will make it the current version once a new base-files release is made. Improvements in this release: md5sum(1) and sha1sum(1) now generate checksum output in binary mode, and ignore \r in verify mode when reading (older) checksum files mistakenly created in text mode. This is so the \r is not treated as part of the filename. su(1) is now provided as a functional executable, rather than a no-op script. Be aware, however, that su does not quite work like it does on Linux. If you are on a Windows 9x machine, you have to use crypt to install your encrypted password to /etc/passwd. If you are on a Windows NT class machine, you have to have sufficient privileges to change user context, and su uses Windows notion of password protection (by default, SYSTEM has enough privileges, but Administrators do not; see http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid). You may be better off using Windows RunAs, or cygwin sshd, for switching user context in a predictable manner. dircolors(1) now works around a limitation of tcsh, in that tcsh prints a warning message when setting LS_COLORS to a value that includes codes recognized by ls(1) but not the tcsh built-in ls-F. This release provides /etc/DIR_COLORS, which used to be provided by base-files. This allows an easier tracking of the current behavior of dircolors. However, it does mean that if you upgrade to coreutils-5.93-3 before upgrading base-files beyond 3.6-1, you may lose /etc/defaults/etc/DIR_COLORS altogether, which would then impact auto-updating of /etc/DIR_COLORS. After upgrading, run cygcheck -c coreutils base-files, and if either package shows up as Incomplete, then use two runs of setup.exe to reinstall the new base-files first, then coreutils second. DESCRIPTION: GNU coreutils provides a collection of commonly used utilities essential to a standard POSIX environment. It comprises the former textutils, sh-utils, and fileutils packages. The following executables are included: [ basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold gkill groups head hostid hostname id install join link ln logname ls md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir seq sha1sum shred sleep sort split stat stty su sum sync tac tail tee test touch tr true tsort tty uname unexpand uniq unlink users vdir wc who whoami yes UPDATE: === 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. Save it and run setup, answer the questions, then look for 'coreutils' in the 'Base' category (it should already be selected). Since this is an experimental release, you will have to use the Exp radio button in setup.exe. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. - -- Eric Blake volunteer cygwin coreutils maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD1jsq84KuGfSFAYARAslBAKCDBp6aH3B/Ae9OHbm/w6CFnkiR6wCeIFS1 haWOIwMQkpjF3vhryCGFcLo= =jQOi -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /proc/pid/exe points to void
On Jan 20 13:50, Sam Steingold wrote: On Mar 10 16:00, Sam Steingold wrote: /proc/pid/exe points to foo, not to foo.exe, so it cannot be opened c. how do I find out which file is running if /proc/pid/exe cannot be opened? access(2) or stat(2) http://www.opengroup.org/onlinepubs/009695399/functions/access.html the above spec of access appears to indicate that if access() succeeds then open() must succeed too. this is not the case in cygwin: /proc/self/exe cannot be open()ed. I've just checked in a patch which tacks on the .exe suffix to /proc/$PID/exe, as well as a patch to realpath which returns the pathname with .exe suffix, even if the original name has no suffix given. We will give this a try. Please test the next snapshot. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-1.5.19-4 very slow in pipes and compiling
I have just installed cygwin-1.5.19-4. A pipe like gzip ?cd | tar ?xf
? is very slow. Gzip and tar alone are working reasonable. Ok this can
be avoided ;-)
But than I tried g++, and again it takes ages before a simple file is
compiled. All Virus Checking tools are off. What am I doing wrong?
I too have seen slowness, which I've previously reported on this
list, but have not narrowed down.
I have found that installing and using the tcsh shell helps allot,
althought this isn't a long-term solution. I'd be curious if you ran
under tcsh if you could reproduce what I've seen, better performance
than the bash shell. You'd need to install tcsh and also make sure it
is a login shell, so it doesn't inherit from the bash shell.
A previous posting indicated that the call to stat took an abnormally
long time to complete. Since then I noticed lines like 'if [ ! -d
${HOME} ]; then', which presumably call stat, in /etc/profile which
may contribute to the slow starting of the bash shell and sub-shells?!?!
Brett
Brett C. Serkez, Techie
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Errors compiling cdrtools under cygwin 1.5.19
Hi, I found out that cygwin 1.5.19 gives some problems when I try to compile cdrtools and cdrdao. I've just sent an e-mail to Jörg Shilling asking for support, here's what I wrote: I've got problems trying to compile 'cdrtools' with new Cygwin release 1.5.19 When I simply call 'make' (without any parameter) I've got a lot of errors like this: ../include/schily.h:189: error: conflicting types for 'getline' /usr/include/sys/stdio.h:31: error: previous declaration of 'getline' was here I've got this problem both with cdrtools 2.01.01a03 and 2.01.01a04, and also with the scsilib of cdrdao 1.2.1. I've never had any problem with previous versions of Cygwin, the only thing that changed since last time I compiled cdrtools is the upgrade of the cygwin package from 1.5.18 to 1.5.19. Looking at the cygwin website, I discovered that getline implementation has just been added to the new release of Cygwin, as you can see here: http://cygwin.com/ml/cygwin-announce/2006-01/msg00032.html I hope this problem can be easily solved... Anyway, thanks for your great work! Simone This is what he answered: Try to convince cygwin to remove their non-conforming interface definition. The getline() iterface I use goes back to 1982 and has been used in a commercial UNIX clone for a long time. Jörg I don't know if cygwin's interface can easily be changed, but considering that Jörg doesn't seem to be willing to modify his code, what do you think that could be done to solve this problem? I hope that a solution can be found, because cdrdao and cdrtools are really great software... Thanks Simone -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Jan 24 18:46, Simone Crestani wrote: Hi, I found out that cygwin 1.5.19 gives some problems when I try to compile cdrtools and cdrdao. [...] Try to convince cygwin to remove their non-conforming interface definition. The getline() iterface I use goes back to 1982 and has been used in a commercial UNIX clone for a long time. His fault. He shouldn't declare a function unconditionally, but use the system headers if there's a definition available. As for the correctness, the getline definition in Cygwin's /usr/include/sys/stdio.h file is *exactly* the definition used on Linux: ssize_t getline(char **, size_t *, FILE *); Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] GNU CLISP 2.38 (2006-01-24) released
ANSI Common Lisp is a high-level, general-purpose programming language. GNU CLISP is a Common Lisp implementation by Bruno Haible of Karlsruhe University and Michael Stoll of Munich University, both in Germany. It mostly supports the Lisp described in the ANSI Common Lisp standard. It runs on most GNU and Unix systems (GNU/Linux, FreeBSD, NetBSD, OpenBSD, Solaris, Tru64, HP-UX, BeOS, NeXTstep, IRIX, AIX and others) and on other systems (Windows NT/2000/XP, Windows 95/98/ME) and needs only 4 MB of RAM. It is Free Software and may be distributed under the terms of GNU GPL. The user interface comes in English, German, French, Spanish, Dutch, Russian and Danish, and can be changed at run time. GNU CLISP includes an interpreter, a compiler, a debugger, CLOS, MOP, a foreign language interface, sockets, i18n, fast bignums and more. An X11 interface is available through CLX, Garnet, CLUE/CLIO. GNU CLISP runs Maxima, ACL2 and many other Common Lisp packages. More information at http://clisp.cons.org/, http://www.clisp.org/, http://www.gnu.org/software/clisp/ and http://clisp.sourceforge.net/. Sources and selected binaries are available by anonymous ftp from ftp://ftp.gnu.org/pub/gnu/clisp/ and its mirrors. 2.38 (2006-01-24) = User visible changes * SAVEINITMEM can create standalone executables. Thanks to Frank Buß [EMAIL PROTECTED] for the idea. SAVEINITMEM also accepts :NORC argument do disable RC-file loading. See http://clisp.cons.org/impnotes/image.html for details. * POSIX:SYSLOG no longer recognizes %m and other formatting instructions. For your safety and security, please do all formatting in Lisp. * Fixed the OPEN :IF-EXISTS :APPEND bug introduced in 2.37. * Fixed a crash on woe32 in opening files with names longer than MAX_PATH. * Module berkeley-db now supports Berkeley DB 4.4. -- Sam Steingold (http://www.podval.org/~sds) running w2k http://truepeace.org http://www.camera.org http://www.palestinefacts.org http://www.mideasttruth.com http://www.memri.org http://ffii.org UNIX is as friendly to you as you are to it. Windows is hostile no matter what. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
This is what he answered: Joerg is known to be stubborn. You should try reading all his comments on the bug-tar list, where he claims that his implementation star is hands-down superior to GNU tar. Just take it with a grain of salt. Try to convince cygwin to remove their non-conforming interface definition. The getline() iterface I use goes back to 1982 and has been used in a commercial UNIX clone for a long time. I would remind Joerg that the Austin group is considering standardizing the GNU getline() interface; and if that is ever standardized, the older interface will be officially obsoleted. Meanwhile, getline() is a non-standard interface; and until either version (the 1982, or the GNU version) is standardized, cygwin is sticking with the Linux definition, and that programs that want to be portable to multiple platforms must be prepared to deal with whatever definition of getline exists. I don't know if cygwin's interface can easily be changed, but considering that Jörg doesn't seem to be willing to modify his code, what do you think that could be done to solve this problem? I hope that a solution can be found, because cdrdao and cdrtools are really great software... The only thing cygwin could do here is to make sure that the definition of getline is not visible if _POSIX_SOURCE is defined, since it is an extension to POSIX. From what I know about Joerg, he is pretty insistent that his programs stick to standards, so if he uses _POSIX_SOURCE to protect himself from inheriting getline from system headers, then it is cygwin's fault that we do not yet isolate non-standard interfaces properly. -- Eric Blake volunteer cygwin tar maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Tue, Jan 24, 2006 at 06:25:13PM +, Eric Blake wrote: somebody wrote: I don't know if cygwin's interface can easily be changed, but considering that J?rg doesn't seem to be willing to modify his code, what do you think that could be done to solve this problem? I hope that a solution can be found, because cdrdao and cdrtools are really great software... The only thing cygwin could do here is to make sure that the definition of getline is not visible if _POSIX_SOURCE is defined, since it is an extension to POSIX. From what I know about Joerg, he is pretty insistent that his programs stick to standards, so if he uses _POSIX_SOURCE to protect himself from inheriting getline from system headers, then it is cygwin's fault that we do not yet isolate non-standard interfaces properly. Linux seems to protect the getline and getdelim declarations with __USE_GNU which is turned on if _GNU_SOURCE is defined. This falls into the same category as my previous discussion about _POSIX_SOURCE. If a program builds without problem on linux, the goal is for it to build without problem on cygwin. It seems like the unconditional addition of getline to the headers moves us a step back from that goal. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
This falls into the same category as my previous discussion about _POSIX_SOURCE. If a program builds without problem on linux, the goal is for it to build without problem on cygwin. It seems like the unconditional addition of getline to the headers moves us a step back from that goal. Is this also valid for Apache 1.3.34? I think it compiles without problem on Linux, but does not compile on cygwin since getline() was implemented last month. I do not want to heat the discussion, but getline() in cygwin played very hard against me. I used cygwin happily for very long time to compile apache/php/postgresql and enjoy symlinks, and now I am cut-off from one day to the next. The apache folks do not seem to care. The bug I submitted is still without reply - http://issues.apache.org/bugzilla/show_bug.cgi?id=38364 Apache 2.x/php 5.x do not want to play on cygwin so far. So I am three days in the dark and testing like hell vmware and minigw to save my skin. Seems this getline() breaks quite a lot and I am not quite sure this is _very_ positive for cygwin. People just get left alone in the dark (no everybody can debug and patch) and the pride of cygwin is somehow self focused. I would expect such dramatic moves to be done with more care. Otherwise I could call cygwin nice, but not reliable. Iv. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache 1.3.34 can not compile anymore
On Tue, Jan 24, 2006 at 12:31:11AM -0800, Brian Dessent wrote: [EMAIL PROTECTED] wrote: Tried to roll back to 1.5.18-1 from the setup.exe, but now I get 10s of error messages from packages who do not find getline in the cygwin dll. You would have to also use a previous version of any programs that need getline(). I think this includes findutils and coreutils. Also readline and libreadline6 need 1.5.19 I think. (There's a pattern here...) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Tue, 24 Jan 2006, pobox wrote: This falls into the same category as my previous discussion about _POSIX_SOURCE. If a program builds without problem on linux, the goal is for it to build without problem on cygwin. It seems like the unconditional addition of getline to the headers moves us a step back from that goal. Is this also valid for Apache 1.3.34? I think it compiles without problem on Linux, but does not compile on cygwin since getline() was implemented last month. This is a simple name clash. Linux also defines getline (also with an incompatible prototype). htpasswd.c defines its own getline(), and it should have the same problem on any system with getline(). You have to check why it compiles (in particular, check the pre-processed form of htpasswd.c using gcc -E). I do not want to heat the discussion, but getline() in cygwin played very hard against me. I used cygwin happily for very long time to compile apache/php/postgresql and enjoy symlinks, and now I am cut-off from one day to the next. The apache folks do not seem to care. The bug I submitted is still without reply - http://issues.apache.org/bugzilla/show_bug.cgi?id=38364 That's because the Apache community has apparently been ignoring this issue since 2002: http://issues.apache.org/bugzilla/show_bug.cgi?id=9894 (which, BTW, contains a patch that you can apply to fix this issue). Apache 2.x/php 5.x do not want to play on cygwin so far. I seem to recall either Brian or Max reporting that they were able to compile PHP 5.x with the Cygwin Apache2 package. Search the cygwin-apps archives. So I am three days in the dark and testing like hell vmware and minigw to save my skin. Seems this getline() breaks quite a lot and I am not quite sure this is _very_ positive for cygwin. People just get left alone in the dark (no everybody can debug and patch) and the pride of cygwin is somehow self focused. I would expect such dramatic moves to be done with more care. Otherwise I could call cygwin nice, but not reliable. I like this slogan: Cygwin: nice, but not reliable. We should adopt this, and refer 90% of the mailing list complaints to it. :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
[EMAIL PROTECTED] wrote:
I do not want to heat the discussion, but getline() in cygwin played
very hard against me.
Like I said in the other thread, you can fix this in Apache (and
cdrtools for that matter -- see attached patch) with a couple of
#defines in the offending files. It's really simple.
If you can't deal with simple patches then why are you building from
source? In open source projects it's often the case that if you're
building things yourself there will sometimes have to actually get your
hands dirty and modify the source. To expect every open source package
to compile on every platform out-of-the-box every time is absurd.
That's why most people use binary packages, and most distributors of
binary packages have metric craploads of patches -- most just trivial
build fixes like this.
Briandiff -upr cdrtools-2.01/cdrecord/cue.c /usr/src/cdrtools-2.01/cdrecord/cue.c
--- cdrtools-2.01/cdrecord/cue.c2004-03-02 12:00:53.0 -0800
+++ /usr/src/cdrtools-2.01/cdrecord/cue.c 2005-12-17 16:22:53.796875000
-0800
@@ -44,6 +44,8 @@ staticchar sccsid[] =
#include auheader.h
#include libport.h
+#define getdelim schily_getdelim
+
typedef struct state {
char*filename;
void*xfp;
diff -upr cdrtools-2.01/include/schily.h /usr/src/cdrtools-2.01/include/schily.h
--- cdrtools-2.01/include/schily.h 2004-03-04 16:30:40.0 -0800
+++ /usr/src/cdrtools-2.01/include/schily.h 2005-12-17 16:19:09.015625000
-0800
@@ -39,6 +39,8 @@
#ifndef _SCHILY_H
#define_SCHILY_H
+#define getline schily_getline
+
#ifndef _STANDARD_H
#include standard.h
#endif
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: apache2-2.0.55-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache HTTPD version 2 has been updated to 2.0.55-1. This is a new upstream security and bugfix release. Additionally, in Cygwin-local news: - - mod_deflate is now included in the build. - - apxs2 -c (compile) mode has been fixed to provide the extra linker arguments required to successfully build a DSO on Cygwin. Please address requests for the inclusion of any additional modules contained within the Apache httpd distribution itself to cygwin (at) cygwin (dot) com. I did consider including mod_ssl, but found that it caused the server to crash when a configtest was run, and did not want to delay this release to debug. Apache 2.2: Probable timeframe for transitioning to the 2.2.x release series is 1 to 2 months. Max Bowsher. - -- 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. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . I would appreciate it if you would use this mailing list rather than emailing me directly. If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. This includes ideas and comments about the setup utility or Cygwin in general. *** 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: [EMAIL PROTECTED] 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 this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFD1sIqfFNSmcDyxYARArtkAKCH3cTyJJEe9qSJGn5dvwZUqcffBgCfTyfA KVH9RxUKdWwbkLHL67WSJak= =jrce -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
disk space allocation (du, ls et al?)
I noticed a minor problem on my machine. I have a partition that is using an 8K allocation unit. However, the commands like: du -s file -or- ls -s file don't show the file's actual allocation size on disk but seem to use a fixed 1k for size. I also duplicated the problem on a network share where the 'block size' on the network share shows up as 4K using a native WinGUI Util (TreeSize), but the cyg-based utils still show the 1k size. Is this something that should work under cygwin? Just not implemented yet? Thanks, Linda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: disk space allocation (du, ls et al?)
on Tue, 24 Jan 2006 18:00:57 -0800 Linda Walsh wrote: However, the commands like: du -s file -or- ls -s file don't show the file's actual allocation size on disk but seem to use a fixed 1k for size. the info pages state for these tools: If none of the above environment variables are set, the block size currently defaults to 1024 bytes in most contexts, but this number may change in the future. For `ls' file sizes, the block size defaults to 1 byte. This can be gotten from 'info coreutils' and then going to the node Block size. 'info info' will help you out on how to use the info tool. The man pages do not include detailed information on these tools. Each tool probably has its own way of adjusting the block size to use (at least du and ls are different). 'du -B 8k' and 'ls -s --block-size=8k' should give the result in block sizes of 8k. :-) Frodak -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Setup: Fatal Error: Uncaught Exception
On Mon, Jan 23, 2006 at 02:56:39PM -0500, Igor Peshansky wrote: Moving to cygwin-apps, as this is likely to get technical. On Mon, 23 Jan 2006, Brian Dessent wrote: Igor Peshansky wrote: I've looked at this a bit. Here's the weird part: the error says Uncaught Exception, but all the throws of that exception appear to be properly wrapped in try/catch blocks. So a simple change exception into an mbox kind of solution won't work here. More debugging is needed. The reason for the box is that the md5 checking was changed to run in a different thread than originally designed (now in the main thread instead of the download thread IIRC) and that thread does not have any particular catch handler for that exception, only the TOPLEVEL_CATCH which punts with the generic error. Do you mean packagemeta::ScanDownloadedFiles() calling packageversion::scan(), which calls check_for_cached()? Then yes, this isn't properly wrapped in a try/catch. I'd like to verify that this is the culprit (when someone sends me the corrupt tarball), but I think I see a proper fix for this. Will submit a patch shortly. Just to reemphasize, these are *not* corrupt tarballs. They are tarballs exactly as downloaded, extracted, and installed. It's just that later the versions on the cygwin mirror became different while keeping the same version/filename. I verified in a couple of the cases that the newer version actually had executables rebuilt, with slightly different file sizes and timestamps. I don't think I have any of them around any more, but if you were to pick a current tarball in your local package directory and un-bzip2 it and re-bzip2 it with a different compression level, you should see the problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Tue, Jan 24, 2006 at 10:43:30PM +0100, [EMAIL PROTECTED] wrote: I used cygwin happily for very long time to compile apache/php/postgresql and enjoy symlinks, and now I am cut-off from one day to the next. The apache folks do not seem to care. The bug I submitted is still without reply - http://issues.apache.org/bugzilla/show_bug.cgi?id=38364 Apache 2.x/php 5.x do not want to play on cygwin so far. So I am three days in the dark and testing like hell vmware and minigw to save my skin. I don't understand why you haven't just reverted cygwin to the previous version (yes, including packages that depend on 1.5.19 - a brief perusal of the cygwin-announce archives from the release of 1.5.19 onward would show you which packages may fall into this category). The cygwin distribution provides access to previous versions *because* it is known that things break from time to time, whether due to a problem in or out of cygwin's control. Additionally, if cygwin is that mission critical to you, you need to have a testing phase between downloading new versions and putting them into live production, just like for any other mission critical software. Seems this getline() breaks quite a lot and I am not quite sure this is _very_ positive for cygwin. People just get left alone in the dark (no everybody can debug and patch) and the pride of cygwin is somehow self focused. I don't understand the self focused part. Re: alone in the dark, If your concerns aren't addressed in the next few months, I think you can make that claim. I would expect such dramatic moves to be done with more care. The only care that really could be taken to prevent things like this is more users testing pre-release versions. Development snapshots of cygwin with getline() have been available for a long time now. Note that this isn't just addressed to you; if package maintainers heeded the release coming soon, please test a snapshot messages cgf sends out by testing that their packages build and run with the snapshot, there'd be less scope for problems. Otherwise I could call cygwin nice, but not reliable. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Setup: Fatal Error: Uncaught Exception
Yitzchak Scott-Thoennes wrote: Just to reemphasize, these are *not* corrupt tarballs. They are tarballs exactly as downloaded, extracted, and installed. It's just that later the versions on the cygwin mirror became different while keeping the same version/filename. I verified in a couple of the cases that the newer version actually had executables rebuilt, with slightly different file sizes and timestamps. I don't think I have any of them around any more, but if you were to pick a current tarball in your local package directory and un-bzip2 it and re-bzip2 it with a different compression level, you should see the problem. Well it's corrupt from the standpoint of setup.exe, which only knows that it has encountered a file with the specified name but incorrect size and/or MD5 based on the information in the setup.ini file. Short of AI there is no way for it to distinguish this case from the case of something that is actually corrupt. If people are uploading new packages (or otherwise modifying them once in flight) without bumping the version, then that needs to stop. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Tue, Jan 24, 2006 at 06:46:31PM -0800, Yitzchak Scott-Thoennes wrote: The only care that really could be taken to prevent things like this is more users testing pre-release versions. Development snapshots of cygwin with getline() have been available for a long time now. Note that this isn't just addressed to you; if package maintainers heeded the release coming soon, please test a snapshot messages cgf sends out by testing that their packages build and run with the snapshot, there'd be less scope for problems. Thank you, for making this point Yitzchak! Can I get two gold stars for over here? I should point out that I didn't rebuild my packages under 1.5.19 either so I'm just as guilty as any other package maintainer in this regard. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.19: Install problem: cannot find cygz.dll
I'm trying to install Cygwin (full install). I downloaded the installer from cygwin.com, and downloaded and installed. The installation runs smoothly until 99% of the way through, when I start getting the following error: xmlcatalog.exe - Unable to Locate Component This application has failed to start because cygz.dll was not found. Re-installing the application may fix this problem. I get this error repeatedly, coming from xmlcatalog.exe, gconftool-2.exe, and gtk-query-immodules-2.0.exe. After enough clicking of Okay, cygwin appears installed. I start up bash, and I find various programs non-functional. Some (I've seen ssh and emacs) generate the same cygz.dll error. Others (which, x) seem to not be installed. Reinstalling Cygwin does not help. Any thoughts? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Tue, Jan 24, 2006 at 10:28:50PM -0500, Christopher Faylor wrote: On Tue, Jan 24, 2006 at 06:46:31PM -0800, Yitzchak Scott-Thoennes wrote: The only care that really could be taken to prevent things like this is more users testing pre-release versions. Development snapshots of cygwin with getline() have been available for a long time now. Note that this isn't just addressed to you; if package maintainers heeded the release coming soon, please test a snapshot messages cgf sends out by testing that their packages build and run with the snapshot, there'd be less scope for problems. Thank you, for making this point Yitzchak! Can I get two gold stars for over here? translation: for over here == for Yitzchak cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Setup: Fatal Error: Uncaught Exception
On Tue, 24 Jan 2006, Yitzchak Scott-Thoennes wrote: On Mon, Jan 23, 2006 at 02:56:39PM -0500, Igor Peshansky wrote: Moving to cygwin-apps, as this is likely to get technical. On Mon, 23 Jan 2006, Brian Dessent wrote: Igor Peshansky wrote: I've looked at this a bit. Here's the weird part: the error says Uncaught Exception, but all the throws of that exception appear to be properly wrapped in try/catch blocks. So a simple change exception into an mbox kind of solution won't work here. More debugging is needed. The reason for the box is that the md5 checking was changed to run in a different thread than originally designed (now in the main thread instead of the download thread IIRC) and that thread does not have any particular catch handler for that exception, only the TOPLEVEL_CATCH which punts with the generic error. Do you mean packagemeta::ScanDownloadedFiles() calling packageversion::scan(), which calls check_for_cached()? Then yes, this isn't properly wrapped in a try/catch. I'd like to verify that this is the culprit (when someone sends me the corrupt tarball), but I think I see a proper fix for this. Will submit a patch shortly. Just to reemphasize, these are *not* corrupt tarballs. They are tarballs exactly as downloaded, extracted, and installed. It's just that later the versions on the cygwin mirror became different while keeping the same version/filename. I verified in a couple of the cases that the newer version actually had executables rebuilt, with slightly different file sizes and timestamps. I don't think I have any of them around any more, but if you were to pick a current tarball in your local package directory and un-bzip2 it and re-bzip2 it with a different compression level, you should see the problem. What Brian said. I've since managed to reproduce the problem with a zero-sized tarball (but you're right, anything with a mismatched size or md5 hash would have worked -- or, rather, not worked) and posted a patch. I would appreciate some comments on the discussion we had with Brian (on cygwin-apps). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Tue, 24 Jan 2006, Christopher Faylor wrote: On Tue, Jan 24, 2006 at 10:28:50PM -0500, Christopher Faylor wrote: On Tue, Jan 24, 2006 at 06:46:31PM -0800, Yitzchak Scott-Thoennes wrote: The only care that really could be taken to prevent things like this is more users testing pre-release versions. Development snapshots of cygwin with getline() have been available for a long time now. Note that this isn't just addressed to you; if package maintainers heeded the release coming soon, please test a snapshot messages cgf sends out by testing that their packages build and run with the snapshot, there'd be less scope for problems. Thank you, for making this point Yitzchak! Can I get two gold stars for over here? Done. translation: for over here == for Yitzchak Rats, now I had to remove a.k.a. quot;over herequot; from after Yitzchak's name before checking this in... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bug in: pthread_mutexattr_init ?
Any idea on what is the problem here? (gyginw CYGWIN Vers.: CYGWIN_NT-5.1 1.5.19(0.150/4/2) 2006-01-20 13:28 While buiding emacs (n.b. had to use a tacky dos trick for dirent since d_ino was deprecated, in order to break backward compatibilty) it crashes during executing temacs in a stack dump. The following information was gained from gdb ouptut In the appropriate directory: To debug: (after successfull config and filed main boostrap at temacs.exe) $ gdb temacs (gdb) r -batch -l loadup. (gdb) Return to continue Result: Program received signal SIGSEGV, Segmentation fault. 0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll (gdb) Quit (gdb) backtrace #0 0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll #1 0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll #2 0x0003 in ?? () #3 0x0022ee58 in ?? () #4 0x006a in ?? () #5 0x0022ee58 in ?? () #6 0x0022ee78 in ?? () #7 0x200a0210 in main (argc=539770848, argv=0x4) at emacs.c:1053 (gdb) Quit Any ideas of what is creating this? Regards, D.J. Henman -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Shell (bash, (pd)ksh, zsh, /not/ ash) + exec + here-doc + redirect == trouble!
Hi, Try the following script: === begin testexec.sh === #!/bin/ksh exec 50 /bin/ksh EOSH echo First exec: Done. exec 05 echo Second exec: Done. exit 0 EOSH end testexec.sh (Replace ksh with bash or zsh at will, above.) For me, this prints ``First exec: Done.'', then leaves me to type shell-commands, _which are executed_, until I press EOF (^D). In ash it prints '' First exec: Done. Second exec: Done. '', as I expected. Compare p.e. === begin testexec2.sh === #!/bin/bash echo 'echo First exec: Done. exec 05 echo Second exec: Done. exit 0' |exec 50 /bin/bash end testexec2.sh , which also performs as expected. Has anybody got a clue? Is this cygwin-specific? Are all these shells borrowing code from eachother? L8r, Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | // really is | and false bits entirely.| mail for ) | | //a 72 by 4 +---+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: disk space allocation (du, ls et al?)
Baksik, Frederick (NM75) wrote: the info pages state for these tools: If none of the above environment variables are set, the block size currently defaults to 1024 bytes in most contexts, but this number may change in the future. For `ls' file sizes, the block size defaults to 1 byte. Er, yeah...though I'm referring to the allocated size. But my problem is different than I thought it was. I cleared up the network problem (smb block size allocation roundup) but on my local disk, it had to do with looking in the wrong directory (my root directory): in my root directory I have file boot.bak that is 253 bytes: /c ls -lgG boot.bak -rw-r- 1 253 Jun 20 2004 boot.bak Allocated size (showing 1k instead of 16k) shows: /c ls -sS boot.bak 1 boot.bak I copy it to a subdirectory and it shows the correct size /c mkdir newsub; cp boot.bak newsub /c ls -s /c/boot.bak /c/newsub/boot.bak 1 /c/boot.bak 16 /c/newsub/boot.bak ^ bad size ^ correct size This would appear to be a bug of some sort... FYI, I just downloaded latest cyg versions last night (so am using new cygwin.dll). Weird. Linda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated [experimental]: coreutils-5.93-3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of coreutils, 5.93-3, is available for experimental use. NEWS: = I've uploaded a test version of coreutils, 5.93-3. This is a minor patch release from 5.93-2. I will make it the current version once a new base-files release is made. Improvements in this release: md5sum(1) and sha1sum(1) now generate checksum output in binary mode, and ignore \r in verify mode when reading (older) checksum files mistakenly created in text mode. This is so the \r is not treated as part of the filename. su(1) is now provided as a functional executable, rather than a no-op script. Be aware, however, that su does not quite work like it does on Linux. If you are on a Windows 9x machine, you have to use crypt to install your encrypted password to /etc/passwd. If you are on a Windows NT class machine, you have to have sufficient privileges to change user context, and su uses Windows notion of password protection (by default, SYSTEM has enough privileges, but Administrators do not; see http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid). You may be better off using Windows RunAs, or cygwin sshd, for switching user context in a predictable manner. dircolors(1) now works around a limitation of tcsh, in that tcsh prints a warning message when setting LS_COLORS to a value that includes codes recognized by ls(1) but not the tcsh built-in ls-F. This release provides /etc/DIR_COLORS, which used to be provided by base-files. This allows an easier tracking of the current behavior of dircolors. However, it does mean that if you upgrade to coreutils-5.93-3 before upgrading base-files beyond 3.6-1, you may lose /etc/defaults/etc/DIR_COLORS altogether, which would then impact auto-updating of /etc/DIR_COLORS. After upgrading, run cygcheck -c coreutils base-files, and if either package shows up as Incomplete, then use two runs of setup.exe to reinstall the new base-files first, then coreutils second. DESCRIPTION: GNU coreutils provides a collection of commonly used utilities essential to a standard POSIX environment. It comprises the former textutils, sh-utils, and fileutils packages. The following executables are included: [ basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold gkill groups head hostid hostname id install join link ln logname ls md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir seq sha1sum shred sleep sort split stat stty su sum sync tac tail tee test touch tr true tsort tty uname unexpand uniq unlink users vdir wc who whoami yes UPDATE: === 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. Save it and run setup, answer the questions, then look for 'coreutils' in the 'Base' category (it should already be selected). Since this is an experimental release, you will have to use the Exp radio button in setup.exe. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. - -- Eric Blake volunteer cygwin coreutils maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD1jsq84KuGfSFAYARAslBAKCDBp6aH3B/Ae9OHbm/w6CFnkiR6wCeIFS1 haWOIwMQkpjF3vhryCGFcLo= =jQOi -END PGP SIGNATURE-
GNU CLISP 2.38 (2006-01-24) released
ANSI Common Lisp is a high-level, general-purpose programming language. GNU CLISP is a Common Lisp implementation by Bruno Haible of Karlsruhe University and Michael Stoll of Munich University, both in Germany. It mostly supports the Lisp described in the ANSI Common Lisp standard. It runs on most GNU and Unix systems (GNU/Linux, FreeBSD, NetBSD, OpenBSD, Solaris, Tru64, HP-UX, BeOS, NeXTstep, IRIX, AIX and others) and on other systems (Windows NT/2000/XP, Windows 95/98/ME) and needs only 4 MB of RAM. It is Free Software and may be distributed under the terms of GNU GPL. The user interface comes in English, German, French, Spanish, Dutch, Russian and Danish, and can be changed at run time. GNU CLISP includes an interpreter, a compiler, a debugger, CLOS, MOP, a foreign language interface, sockets, i18n, fast bignums and more. An X11 interface is available through CLX, Garnet, CLUE/CLIO. GNU CLISP runs Maxima, ACL2 and many other Common Lisp packages. More information at http://clisp.cons.org/, http://www.clisp.org/, http://www.gnu.org/software/clisp/ and http://clisp.sourceforge.net/. Sources and selected binaries are available by anonymous ftp from ftp://ftp.gnu.org/pub/gnu/clisp/ and its mirrors. 2.38 (2006-01-24) = User visible changes * SAVEINITMEM can create standalone executables. Thanks to Frank Buß [EMAIL PROTECTED] for the idea. SAVEINITMEM also accepts :NORC argument do disable RC-file loading. See http://clisp.cons.org/impnotes/image.html for details. * POSIX:SYSLOG no longer recognizes %m and other formatting instructions. For your safety and security, please do all formatting in Lisp. * Fixed the OPEN :IF-EXISTS :APPEND bug introduced in 2.37. * Fixed a crash on woe32 in opening files with names longer than MAX_PATH. * Module berkeley-db now supports Berkeley DB 4.4. -- Sam Steingold (http://www.podval.org/~sds) running w2k http://truepeace.org http://www.camera.org http://www.palestinefacts.org http://www.mideasttruth.com http://www.memri.org http://ffii.org UNIX is as friendly to you as you are to it. Windows is hostile no matter what.
