cygport: KEEPDIRS not working, doenv and tcsh
Hi Yaakov,
I'm just converting the OpenSSL package to cygport packaging. I
stumbled over two problems using cygport 0.10.10-1:
- Neither keepdir nor KEEPDIRS seem to do their job.
The OpenSSL package installs two empty dirs which are supposed to
be kept in the tar archive. So I tried
src_install() {
[...]
keepdir usr/ssl/certs
keepdir usr/ssl/private
}
as well as on the top level:
KEEPDIRS=usr/ssl/certs usr/ssl/private
but to no avail:
cygport openssl-1.0.1b-1.cygport install
[...]
*** Info: Removing empty directory: /usr/ssl/certs
*** Info: Removing empty directory: /usr/ssl/private
Is there something else I have to do?
- Another problem I found is the way the `doenv' command works.
I like the idea, but it's not working well for tcsh scripts.
Assuming I want to extend the MANPATH variable, as for OpenSSL:
doenv MANPATH '${MANPATH}:/usr/ssl/man'
The result for tcsh looks like this:
setenv MANPATH ${MANPATH}:/usr/ssl/man
The problem is this. If the MANPATH variable is not set at the time,
tcsh will choke on it:
$ setenv MANPATH ${MANPATH}:/usr/ssl/man
MANPATH: Undefined variable.
A more generic solution, which takes potential self-referencing into
account should first set the variable to an empty string if it doesn't
exist:
if ( $?MANPATH ) setenv MANPATH
setenv MANPATH ${MANPATH}:/usr/ssl/man
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [patch/RFA] rebase: Add -n option.
Jason, Ping? Corinna On Apr 23 19:30, Corinna Vinschen wrote: Hi Jason, per the discussion starting at http://cygwin.com/ml/cygwin/2012-04/msg00443.html I would like to apply the following patch to rebase and friends. Thanks, Corinna ChangeLog: * configure.ac (AC_INIT): Bump version to 4.2.0. * configure: Regenerate. * peflagsall.in: Set DefaultDynBase to 0 to remove the dynamicbase flag by default, rather than to set it. Add .oct to DefaultSuffixes, just as in rebaseall.in. Fix help text accordingly. * rebase.c (long_options): Add --no-dynamicbase. (short_options): Add -n. (parse_args): Handle -n/--no-dynamicbase option. Set ReBaseDropDynamicbaseFlag flag. (usage): Add text for new -n/--no-dynamicbase option. * rebaseall.in: Call rebase with -n flag on Cygwin. * README: Document all aforementioned changes. imagehelper/ChangeLog: * imagehelper.h (ReBaseDropDynamicbaseFlag): Declare. * rebaseimage.cc: Include windows.h. Handle old w32api releases. (ReBaseDropDynamicbaseFlag): Define. (ReBaseImage64): Drop IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag in DllCharacteristics if successfully rebased and ReBaseDropDynamicbaseFlag is true. Index: README === RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/README,v retrieving revision 1.3 diff -u -p -r1.3 README --- README19 Mar 2012 17:57:48 - 1.3 +++ README23 Apr 2012 17:27:52 - @@ -142,8 +142,8 @@ dlls on your entire system: Both procedures may be combined into a single, 4-step procedure if desired. Note that by default, peflagsall will set the tsaware flag on all executables -(ash.exe and peflags.exe themselves excluded), and will set the dynamicbase -flag on all 'dll' and 'so' files (cygwin1.dll and cyglsa64.dll excluded). +(ash.exe and peflags.exe themselves excluded), and will remove the dynamicbase +flag on all 'dll', 'so' and 'oct' files (cygwin1.dll and cyglsa64.dll excluded). If you are used to using the -s option with rebaseall, to add additional suffixes to the rebase list (such as .oct), be warned that peflags behaves @@ -176,7 +176,7 @@ where: -p = skip test for running ash or dash only. This option is supposed to be used by Cygwin's setup tool. Only use it if you know what you're doing! --s = specify DLL suffix, use multiple if necessary (default: dll, so) +-s = specify DLL suffix, use multiple if necessary (default: dll, so, oct) -T = specify filelist (or stdin) to list additional files -4 = operate only on 32bit objects (ignore 64bit objects) (*) -8 = operate only on 64bit objects (ignore 32bit objects) (*) @@ -197,15 +197,15 @@ The following is the peflagsall command peflagsall [-p extra_args] [-d bool] [-t bool] [-s suffix] [-T FileList | -] [-vnh] -When invoked with no arguments, peflagsall modifies every cygwin exe|dll|so -on the system: .exe files have their tsaware flag set, while .dll and .so files -have their dynamicbase flag set. However, if any of [-d|-t|-s] are specified -then ONLY the actions so specified will occur. +When invoked with no arguments, peflagsall modifies every cygwin exe|dll|so|oct +on the system: .exe files have their tsaware flag set, while .dll, .so and .oct +files have their dynamicbase flag removed. However, if any of [-d|-t|-s] are +specified then ONLY the actions so specified will occur. -p extra_args pass extra_args to peflags.exe -d bool set the dynamicbase flag to 'bool' on all specified files -t bool set the tsaware flag to 'bool' on all specified files -s suffix search for all files with the specified suffix(es) - default: 'exe|dll|so' + default: 'exe|dll|so|oct' -T FileList in addition to files located via the normal search and suffix list, also operate on files listed in FileList May be '-' which indicates stdin @@ -244,6 +244,7 @@ The following is the rebase command line files top-down from there. Without this option the files are rebased from BaseAddress bottom-up. With the -s option, this option is implicitly set. + -n, --no-dynamicbaseRemove PE dynamicbase flag from rebased DLLs, if set. -o, --offset=OFFSET Specify an additional offset between adjacent DLLs when rebasing. Default is no offset. -t, --touch Use this option to make sure the file's modification Index: configure.ac
Re: cygport: KEEPDIRS not working, doenv and tcsh
On 4/28/2012 5:44 AM, Corinna Vinschen wrote:
Hi Yaakov,
I'm just converting the OpenSSL package to cygport packaging. I
stumbled over two problems using cygport 0.10.10-1:
- Neither keepdir nor KEEPDIRS seem to do their job.
The OpenSSL package installs two empty dirs which are supposed to
be kept in the tar archive. So I tried
src_install() {
[...]
keepdir usr/ssl/certs
keepdir usr/ssl/private
}
as well as on the top level:
KEEPDIRS=usr/ssl/certs usr/ssl/private
but to no avail:
I think you need the leading `/': keepdir /usr/ssl/certs.
Ken
Re: cygport: KEEPDIRS not working, doenv and tcsh
On Apr 28 09:00, Ken Brown wrote:
On 4/28/2012 5:44 AM, Corinna Vinschen wrote:
Hi Yaakov,
I'm just converting the OpenSSL package to cygport packaging. I
stumbled over two problems using cygport 0.10.10-1:
- Neither keepdir nor KEEPDIRS seem to do their job.
The OpenSSL package installs two empty dirs which are supposed to
be kept in the tar archive. So I tried
src_install() {
[...]
keepdir usr/ssl/certs
keepdir usr/ssl/private
}
as well as on the top level:
KEEPDIRS=usr/ssl/certs usr/ssl/private
but to no avail:
I think you need the leading `/': keepdir /usr/ssl/certs.
*blush* You're right, thanks. The manual states that the paths given
to keepdir or KEEPDIRS are relative to ${D}, just like the paths in
the foo_CONTENTS variables, so I never thought of prepending a slash.
Another problem I just encountered is this:
OpenSSL cannot be built outside its source tree. So my src_compile
looks like this:
src_compile() {
cd ${S} # ---
./config ${CONFIG_OPTIONS}
make depend
make
}
Now all the created binaries are in ${S} as well, of course. This
results in an enormous src patch file, which doesn't make sense at
all. Additionally I'm always building OpenSSL from the upstream
vanilla sources anyway. So what I tried was this:
DIFF_EXCLUDES='*'
Unfortunately this doesn't have the desired effect. The src patch
is still big and contains all the created binaries as well.
How do I tell cygport not to create a src patch file?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: cygport: KEEPDIRS not working, doenv and tcsh
On 28/04/2012 15:13, Corinna Vinschen wrote:
On Apr 28 09:00, Ken Brown wrote:
On 4/28/2012 5:44 AM, Corinna Vinschen wrote:
Another problem I just encountered is this:
OpenSSL cannot be built outside its source tree. So my src_compile
looks like this:
Use 'lndirs' instead
src_compile() {
cd ${S} # ---
./config ${CONFIG_OPTIONS}
make depend
make
}
Now all the created binaries are in ${S} as well, of course. This
results in an enormous src patch file, which doesn't make sense at
all. Additionally I'm always building OpenSSL from the upstream
vanilla sources anyway. So what I tried was this:
DIFF_EXCLUDES='*'
Unfortunately this doesn't have the desired effect. The src patch
is still big and contains all the created binaries as well.
How do I tell cygport not to create a src patch file?
Re: cygport: KEEPDIRS not working, doenv and tcsh
On 4/28/2012 4:33 PM, Jon TURNEY wrote:
On 28/04/2012 15:13, Corinna Vinschen wrote:
On Apr 28 09:00, Ken Brown wrote:
On 4/28/2012 5:44 AM, Corinna Vinschen wrote:
Another problem I just encountered is this:
OpenSSL cannot be built outside its source tree. So my src_compile
looks like this:
Use 'lndirs' instead
with some more details:
src_compile() {
cd ${S}
cygautoreconf
lndirs
cd ${B}
cygconf
cygmake
}
Marco
Re: cygport: KEEPDIRS not working, doenv and tcsh
On Apr 28 16:48, marco atzeri wrote:
On 4/28/2012 4:33 PM, Jon TURNEY wrote:
On 28/04/2012 15:13, Corinna Vinschen wrote:
On Apr 28 09:00, Ken Brown wrote:
On 4/28/2012 5:44 AM, Corinna Vinschen wrote:
Another problem I just encountered is this:
OpenSSL cannot be built outside its source tree. So my src_compile
looks like this:
Use 'lndirs' instead
with some more details:
src_compile() {
cd ${S}
cygautoreconf
lndirs
cd ${B}
cygconf
cygmake
}
Thanks guys!
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
[RFU] [TEST] GraphicsMagick-1.3.14-2
built for Perl-5.14.2-1 to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/GraphicsMagick/index.html rm ./index.html \ ./libGraphicsMagick-devel/index.html \ ./libGraphicsMagick3/index.html \ ./perl-Graphics-Magick/index.html rm ./libGraphicsMagick-devel/md5.sum \ ./libGraphicsMagick3/md5.sum \ ./md5.sum \ ./perl-Graphics-Magick/md5.sum File list: GraphicsMagick-1.3.14-2-src.tar.bz2 GraphicsMagick-1.3.14-2.tar.bz2 libGraphicsMagick-devel/libGraphicsMagick-devel-1.3.14-2.tar.bz2 libGraphicsMagick-devel/setup.hint libGraphicsMagick3/libGraphicsMagick3-1.3.14-2.tar.bz2 libGraphicsMagick3/setup.hint perl-Graphics-Magick/perl-Graphics-Magick-1.3.14-2.tar.bz2 perl-Graphics-Magick/setup.hint setup.hint
[RFU] [TEST] ImageMagick-6.7.6.3-2
built for Perl-5.14.2-1 to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/ImageMagick/index.html rm ./ImageMagick-doc/index.html \ ./index.html \ ./libMagick-devel/index.html \ ./libMagickCore5/index.html \ ./perl-Image-Magick/index.html \ ./ImageMagick-doc/md5.sum \ ./libMagick-devel/md5.sum \ ./libMagickCore5/md5.sum \ ./md5.sum \ ./perl-Image-Magick/md5.sum File list: ImageMagick-6.7.6.3-2-src.tar.bz2 ImageMagick-6.7.6.3-2.tar.bz2 ImageMagick-doc/ImageMagick-doc-6.7.6.3-2.tar.bz2 ImageMagick-doc/setup.hint libMagick-devel/libMagick-devel-6.7.6.3-2.tar.bz2 libMagick-devel/setup.hint libMagickCore5/libMagickCore5-6.7.6.3-2.tar.bz2 libMagickCore5/setup.hint perl-Image-Magick/perl-Image-Magick-6.7.6.3-2.tar.bz2 perl-Image-Magick/setup.hint setup.hint
winsup/cygwin ChangeLog environ.cc globals.cc ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2012-04-28 19:49:58 Modified files: cygwin : ChangeLog environ.cc globals.cc pipe.cc sigproc.cc Log message: * environ.cc (struct parse_thing): Add temporary (?) pipe_byte option. * globals.cc (pipe_byte): Declare. * pipe.cc (fhandler_pipe::create): Use current process id in pipe name rather than pid for simple name collision avoidance. Do this only once to avoid extra overhead when a busy pipe is found. Honor pipe_byte to create non-message pipes if set. * sigproc.cc (sigproc_init): Use a specific name for the signal pipe. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5816r2=1.5817 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/environ.cc.diff?cvsroot=uberbaumr1=1.199r2=1.200 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/globals.cc.diff?cvsroot=uberbaumr1=1.38r2=1.39 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/pipe.cc.diff?cvsroot=uberbaumr1=1.142r2=1.143 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.381r2=1.382
src/winsup/w32api ChangeLog lib/Makefile.in in ...
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2012-04-29 02:43:40 Modified files: winsup/w32api : ChangeLog winsup/w32api/lib: Makefile.in Added files: winsup/w32api/include: shobjidl.h winsup/w32api/lib: shobjidl-uuid.c Log message: 2012-04-28 LRN l_r_nightm...@users.sf.net * include/shobjidl.h: New file. * lib/shobjidl-uuid.c: New file. * lib/Makefile.in: Reference shobjidl-uuid.c. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1114r2=1.1115 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/shobjidl.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/shobjidl-uuid.c.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/Makefile.in.diff?cvsroot=srcr1=1.59r2=1.60
Re: how to deny delete
The problem i have is - no new user be created but i'm also administrator. I want to restrict some folders from being moved(or even touched). appreciate your hints help. regards pen pen wrote: How about locking the vnode or inode of directory? i did not find any such reference but i believe it must be doable. Larry Hall (Cygwin-X) wrote: On 4/24/2012 1:01 PM, Corinna Vinschen wrote: On Apr 24 12:57, Larry Hall (Cygwin) wrote: On 4/24/2012 4:24 AM, pen wrote: unfortunately, the options u pointed and what andrey pointed arent possible. In line with the locking file or directory any commands or API are available? Any tips on implementing it would be helpful. Windows will allow you to manage just the delete permission. If you need that level of control, check out 'icacls'. Something like the following may work for you: icaclsfilename /denyuser or SID:D Doesn't help in Cygwin if the user is admin. Think SE_BACKUP_PRIVILEGE. Ah yes. And the OP said dropping this privilege for the user was a non-starter for some reason. OK, I'm out of ideas. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/how-to-deny-delete-tp33732027p33763249.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)
On 4/27/12 10:27 PM, Christopher Faylor wrote: The above comment shows an and relationship here. Message type pipes more closely mimic Linux (UNIX) pipe behavior AND are definitely required for ptys. Yeah, but because message pipes break other programs. Cygwin has only been using message pipes since 23-Oct-11 (1.134), and it got along fine before that, ICANON aside. If Cygwin programs don't actually _need_ message pipes in the general case, Cygwin should use byte pipes instead. signature.asc Description: OpenPGP digital signature
Re: The date command is giving wrong results (SOLVED).
On Apr 28 00:30, Rodrigo Medina wrote: Corinna Vinschen wrote: ... you might consider to debug the tzset tool ... The cygwin tzset program is OK. The problem was caused by a non-standard TZ-regestry produced by an non-official patch that I applied few years ago when the venezuelan legal time zone was change from GMT-4:00 to GMT-4:30, that at that time was not supported by Microsoft. With the official Microsoft tz patch everything is OK. Sorry for the noise. No worries. Thanks for keeping us informed. 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
the tzset tool does not match the man description
Hi, It seems to me that the behavior of the tzset tool does not match the description given in the man pages. Apparently the tzset tool which is part of the cygwin pckage is different from the one described in the man pages. I think that this is a confusing situation. If I am right, I think that the cygwin maintainers should changing the name of the tzset tool to something else (tzget ?). greetings RM -- 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: the tzset tool does not match the man description
On 4/28/2012 5:29 PM, rodmed...@cantv.net wrote: Hi, It seems to me that the behavior of the tzset tool does not match the description given in the man pages. Apparently the tzset tool which is part of the cygwin pckage is different from the one described in the man pages. I think that this is a confusing situation. If I am right, I think that the cygwin maintainers should changing the name of the tzset tool to something else (tzget ?). greetings RM tzset tool has no man page. (no /usr/share/man/man1/tzset.1.gz ) what you see with man tzset is the man of the newlib tzset function /usr/share/man/man3/tzset.3.gz - TZSET(3) NEWLIB TZSET(3) NAME 9.11 `tzset'--set timezone characteristics from TZ environment variable SYNOPSIS #include time.h void tzset(void); void _tzset_r (struct _reent *); -- -- 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.14-2 setup.exe v2.772 broken?
On Apr 28 13:02, Ken wrote: marco atzeri wrote: BLODA is still a possibility, I have Symantec installed; or there is subtle bug handling the missing files on the website Marco Hi Marco, Nice to see that you can reproduce the problem! I neglected to mention that this seems to occur immediately after the initial setup.ini download (even to a fresh, non-cached, local folder), but it would seem that you have reproduced what I am experiencing. As I mentioned, the download operations work fine with the previous version of setup.exe (from 1.7.13); which is why I question whether or not something is slightly awry in the new version. There's no change between 2.769 and 2.772 which would explain any change in handling the .ini file. I installed 2.772 on my systems as soon as it was available and I don't see any such issue using my local mirror. Did you try another mirror? 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: the tzset tool does not match the man description
On Apr 28 17:55, marco atzeri wrote: On 4/28/2012 5:29 PM, rodmed...@cantv.net wrote: Hi, It seems to me that the behavior of the tzset tool does not match the description given in the man pages. Apparently the tzset tool which is part of the cygwin pckage is different from the one described in the man pages. I think that this is a confusing situation. If I am right, I think that the cygwin maintainers should changing the name of the tzset tool to something else (tzget ?). greetings RM tzset tool has no man page. (no /usr/share/man/man1/tzset.1.gz ) what you see with man tzset is the man of the newlib tzset function /usr/share/man/man3/tzset.3.gz And here's the description of the tzset command: http://cygwin.com/cygwin-ug-net/using-utils.html#tzset 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.14-2 setup.exe v2.772 broken?
Is there a reason why the Cygwin executables, and certainly the installer, are not digitally signed by Redhat? Also, with reference to: http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibility-on-windows-7.aspx http://msdn.microsoft.com/en-us/library/dd371711%28v=vs.85%29.aspx Should the Cygwin executables should be manifested so that they cannot run under any PCA compatibility shim and get the Windows 7 'behaviour'? -- 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.14-2 setup.exe v2.772 broken?
On Sat, Apr 28, 2012 at 08:06:21PM +0200, Corinna Vinschen wrote: On Apr 28 13:02, Ken wrote: marco atzeri wrote: BLODA is still a possibility, I have Symantec installed; or there is subtle bug handling the missing files on the website Marco Hi Marco, Nice to see that you can reproduce the problem! I neglected to mention that this seems to occur immediately after the initial setup.ini download (even to a fresh, non-cached, local folder), but it would seem that you have reproduced what I am experiencing. As I mentioned, the download operations work fine with the previous version of setup.exe (from 1.7.13); which is why I question whether or not something is slightly awry in the new version. There's no change between 2.769 and 2.772 which would explain any change in handling the .ini file. Yeah, ditto, but... I installed 2.772 on my systems as soon as it was available and I don't see any such issue using my local mirror. Did you try another mirror? I can duplicate this. I'll try to fix it today. 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.14-2 setup.exe v2.772 broken?
Christopher Faylor wrote: On Sat, Apr 28, 2012 at 08:06:21PM +0200, Corinna Vinschen wrote: On Apr 28 13:02, Ken wrote: marco atzeri wrote: BLODA is still a possibility, I have Symantec installed; or there is subtle bug handling the missing files on the website Marco Hi Marco, Nice to see that you can reproduce the problem! I neglected to mention that this seems to occur immediately after the initial setup.ini download (even to a fresh, non-cached, local folder), but it would seem that you have reproduced what I am experiencing. As I mentioned, the download operations work fine with the previous version of setup.exe (from 1.7.13); which is why I question whether or not something is slightly awry in the new version. There's no change between 2.769 and 2.772 which would explain any change in handling the .ini file. Yeah, ditto, but... I installed 2.772 on my systems as soon as it was available and I don't see any such issue using my local mirror. Did you try another mirror? Yes, as I mentioned in my initial post, I tried a few different mirrors with the same result. I can duplicate this. I'll try to fix it today. cgf Excellent! I look forward to the fix. :-) Thank you! Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: openssl-1.0.1b-1, openssl-devel-1.0.1b-1, libopenssl100-1.0.1b-1
I've updated the version of OpenSSL to 1.0.1b-1. This is an upstream new feature release. The Cygwin release is build from the vanilla sources, now packaged using cygport. Here's the official release message: OpenSSL version 1.0.1b released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1b of our open source toolkit for SSL/TLS. This new OpenSSL version is a new feature release. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. The most significant changes are: o Fix compilation error on non-x86 platforms. o Make FIPS capable OpenSSL ciphers work in non-FIPS mode. o Fix SSL_OP_NO_TLSv1_1 clash with SSL_OP_ALL in OpenSSL 1.0.0 We consider OpenSSL 1.0.1b to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 1.0.1b is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1b.tar.gz Size: 4456651 MD5 checksum: a1da58ce63baef3812004714fa302c47 SHA1 checksum: b6222cbbf835c27d9ad6db22262da6e4a2aca8b8 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1b.tar.gz openssl sha1 openssl-1.0.1b.tar.gz Yours, The OpenSSL Project Team. 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 the above URL. -- 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
gdb hanging in emacs
Hi all, I'm trying to use a home-built cross-gdb to do some remote debugging over tcp, but running gdb inside emacs doesn't work. M-x gud-gdb works fine, it's something wrong with the emacs integration. Unlike past times this has come up, the issue doesn't seem to be related to seg faults; the closest match I can find is from the emacs mailing list a while back [1], and involves a so-called phase error. Basically, a large fraction of commands cause gud to hang in [initializing...] state for minutes or longer, apparently because it doesn't see what it expects and gets confused. The workaround to use 'file $BINARY' instead of specifying it at the command line avoids one problem, but simple things like 'set remotebaud 115200' also hang (unless added to a .gdbinit), and actually attempting to attach to the remote process similarly hangs forever in the initializing state. There is no CPU or disk utilization, and the command can't be interrupted with C-c C-c (though that does make it report a phase error before going back to hung). In some cases the hang resolves itself after about two minutes -- usually for simple commands like `set remotebaud' -- but more often than not, it's permanent. The behavior is also somewhat erratic, in the sense that the specific set of commands that hangs changes slowly over time and/or between invocations. So, two questions: 1. Has anyone else seen this, and if so, do they have any advice or workarounds? 2. Cygwin's official gdb doesn't seem to have any of these problems, though I can't test most of the commands, since it can't attach to the remote process. Is there some set of cygwin-specific patches I could borrow that make all the difference, or is my observation just coincidence? Thanks! Ryan [1] http://lists.gnu.org/archive/html/help-gnu-emacs/2008-06/msg00713.html -- 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.14-2 setup.exe v2.772 broken?
On Sat, Apr 28, 2012 at 02:24:29PM -0400, Christopher Faylor wrote: I can duplicate this. I'll try to fix it today. I think I fixed the problem. I at least fixed *a* problem. The latest setup.exe, now on cygwin.com has the fix that solved the issue for me. 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
Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
It's bad etiquette to derail an email thread with unrelated questions. On Sat, Apr 28, 2012 at 07:22:29PM +0100, Nick Lowe wrote: Is there a reason why the Cygwin executables, and certainly the installer, are not digitally signed by Redhat? setup.exe is not produced by Red Hat and the Cygwin project at cygwin.com is not a Red Hat project. So, the logicstics of doing this aside, I doubt that Red Hat would be too keen on the 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: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
It's bad etiquette to derail an email thread with unrelated questions. I certainly didn't mean to derail it, the other points were ancillary to the implicit point that I intended to make which is that if the executable was digitally signed, any potential corruption would immediately be flagged by the operating system. -- 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.14-2 setup.exe v2.772 broken?
On 4/28/2012 10:45 PM, Christopher Faylor wrote: On Sat, Apr 28, 2012 at 02:24:29PM -0400, Christopher Faylor wrote: I can duplicate this. I'll try to fix it today. I think I fixed the problem. I at least fixed *a* problem. The latest setup.exe, now on cygwin.com has the fix that solved the issue for me. cgf no change in my case :-( installing from matzeri.altervista.org it crashes trying to download the missing setup.bz2. If I add a setup.bz2 it crashes with the missing setup.bz2.sig Marco -- 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 NFS server yields empty directory listing
For some years I have run an old Unix system (OpenStep) as an NFS client. The NFS server has been SFU running on Windows XP. This combination works fine. For Windows 7 I have looked at HameWin, FreeNFS, ... but they have limitations like very restricted user mapping. I've therefore tried Cygwin NFS server, which is more promising. I appear to have it set up correctly (permissions, firewall, user mapping, exports, etc.). It sort-of works but there's a bizarre problem. When I list a directory exported from the Windows server to the Unix client it works fine the first time. But when I list the directory a second (or later) time I get no entries listed. I turned on all logging for nfsd. It seems that it serves up directory entries only on the first access. On subsequent accesses, there is only minimal processing in NFS server and no attempt to read the directory: nfsd[8796] 04/28/112 18:25 fhandle.c 938 : fh_find: psi=14cfa... found '/tmp', fd=-1 nfsd[8796] 04/28/112 18:25 dispatch.c 174 : getattr [1 112/4/28 19:25:32 clam 0.100+100,0] nfsd[8796] 04/28/112 18:25 dispatch.c 174 : /tmp nfsd[8796] 04/28/112 18:25 fhandle.c 938 : fh_find: psi=14cfa... found '/tmp', fd=-1 nfsd[8796] 04/28/112 18:25 ugid_map.c 455 : ugid_get_entry(0x20075278, 0) result 0x20075680 nfsd[8796] 04/28/112 18:25 ugid_map.c 287 : luid(192.168.1.20, 0) = 500 nfsd[8796] 04/28/112 18:25 ugid_map.c 455 : ugid_get_entry(0x200782b8, 100) result 0x200789e0 nfsd[8796] 04/28/112 18:25 ugid_map.c 310 : lgid(192.168.1.20, 100) = 1008 nfsd[8796] 04/28/112 18:25 ugid_map.c 455 : ugid_get_entry(0x200782b8, 100) result 0x200789e0 nfsd[8796] 04/28/112 18:25 ugid_map.c 310 : lgid(192.168.1.20, 100) = 1008 nfsd[8796] 04/28/112 18:25 ugid_map.c 455 : ugid_get_entry(0x200782b8, 0) result 0x200786c0 nfsd[8796] 04/28/112 18:25 ugid_map.c 310 : lgid(192.168.1.20, 0) = 513 nfsd[8796] 04/28/112 18:25 ugid_map.c 237 : ruid(192.168.1.20, 544) = -2 nfsd[8796] 04/28/112 18:25 ugid_map.c 264 : rgid(192.168.1.20, 513) = -2 nfsd[8796] 04/28/112 18:25 dispatch.c 182 : result: 0 (no readdir at this point) Despite the empty directory listing, I can create and delete files or directories in the exported directory. I therefore think that the NFS setup is correct, but for some reason reading a directory gives no results after one access. Any inspirations? I am using Windows 7 Enterprise SP1, cygwin 1.7.14-2, nfs-server 2.3-5. -- 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
Choose different cygwin mirror without reselecting packages
I spent about 30-45 minutes choosing the packages I wanted from setup.exe, then proceeded to download. The particular server I chose has a delay between files of what seems like infinity, so I want to switch mirrors without having to re-select packages. I was hoping that my selection was saved somewhere, but no files within the package directory seems to contain my selection info. Is there a way to switch mirrors without having to reselect packages? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Putting package directory in c:\Cygwin
Putting the packages directly in c:\Cygwin is ill-advised because it shows up in the posix directory /. It pollutes the directory with millions of package folders. But what if I create a folder c:\Cygwin\LocalPkgs and stick them in there? From the 10,000 foot perspective, it certainly would be a lot more organized to have all cygwin stuff in one windows folder. -- 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: Choose different cygwin mirror without reselecting packages
Andy AndyMHancock at gmail.com writes: I spent about 30-45 minutes choosing the packages I wanted from setup.exe, then proceeded to download. The particular server I chose has a delay between files of what seems like infinity, so I want to switch mirrors without having to re-select packages. I was hoping that my selection was saved somewhere, but no files within the package directory seems to contain my selection info. Is there a way to switch mirrors without having to reselect packages? By the way, if the answer is no, thanks if you can also reply. I'd rather interrupt the current pathologically slow download and redo my package selection as soon as possible. Thanks. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
On Sat, Apr 28, 2012 at 09:57:01PM +0100, Nick Lowe wrote: It's bad etiquette to derail an email thread with unrelated questions. I certainly didn't mean to derail it, the other points were ancillary to the implicit point that I intended to make which is that if the executable was digitally signed, any potential corruption would immediately be flagged by the operating system. There is no evidence that setup.exe (which is signed) was corrupt. It has/had what we call in the software industry a bug. Digital signing is not going to solve that. -- 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: Choose different cygwin mirror without reselecting packages
On Sat, Apr 28, 2012 at 11:06:29PM +, Andy wrote: Andy AndyMHancock at gmail.com writes: I spent about 30-45 minutes choosing the packages I wanted from setup.exe, then proceeded to download. The particular server I chose has a delay between files of what seems like infinity, so I want to switch mirrors without having to re-select packages. I was hoping that my selection was saved somewhere, but no files within the package directory seems to contain my selection info. Is there a way to switch mirrors without having to reselect packages? By the way, if the answer is no, thanks if you can also reply. I'd rather interrupt the current pathologically slow download and redo my package selection as soon as possible. Thanks. No. 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: Putting package directory in c:\Cygwin
On Sat, Apr 28, 2012 at 11:02:54PM +, Andy wrote: Putting the packages directly in c:\Cygwin is ill-advised because it shows up in the posix directory /. It pollutes the directory with millions of package folders. But what if I create a folder c:\Cygwin\LocalPkgs and stick them in there? From the 10,000 foot perspective, it certainly would be a lot more organized to have all cygwin stuff in one windows folder. You can make a directory wherever you want. There is no such thing as a Windows folder compared to a Cygwin folder. They are all just regular old Windows directories. -- 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: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
I installed 2.772 on my systems as soon as it was available and I don't see any such issue using my local mirror. Did you try another mirror? Quite, but the idea of corruption was implicit in that question. A digital signature would rule that out. It was only a suggestion to ensure that that would never be a possibility. What's with the hostility? It's really bad etiquette... ;) Nick -- 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: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
I forgot to add, it also needs to be signed by a trusted root for it to be useful to most people. On Sun, Apr 29, 2012 at 1:51 AM, Nick Lowe nick.l...@gmail.com wrote: I installed 2.772 on my systems as soon as it was available and I don't see any such issue using my local mirror. Did you try another mirror? Quite, but the idea of corruption was implicit in that question. A digital signature would rule that out. It was only a suggestion to ensure that that would never be a possibility. What's with the hostility? It's really bad etiquette... ;) Nick -- 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: Choose different cygwin mirror without reselecting packages
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: On Sat, Apr 28, 2012 at 11:06:29PM +, Andy wrote: Is there a way to switch mirrors without having to reselect packages? No. Thanks, Chris. -- 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: Putting package directory in c:\Cygwin
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: On Sat, Apr 28, 2012 at 11:02:54PM +, Andy wrote: Putting the packages directly in c:\Cygwin is ill-advised because it shows up in the posix directory /. It pollutes the directory with millions of package folders. But what if I create a folder c:\Cygwin\LocalPkgs and stick them in there? From the 10,000 foot perspective, it certainly would be a lot more organized to have all cygwin stuff in one windows folder. You can make a directory wherever you want. There is no such thing as a Windows folder compared to a Cygwin folder. They are all just regular old Windows directories. I meant the path as seen from bash command line. Thanks for clarifying that the package folder can go anywhere. I should have reviewed the FAQ, which actually says that the cygwin root directory should not be put into c:\ . However, I decided not to put the package directory in c:\Cygwin anyway, just to make it that much easier to blow away c:\Cygwin when problems are encountered with Setup. I won't go into details because the problems I encountered got easily fixed exactly in this manner. Just as a note for others, though, I had to delete the shortcuts that launch a cygwin shell and have the setup program recreate them. Not doing so generates errors about the shortcut being bound to mintty, which couldn't be found. Hopefully, this detail will save some people a bit of time. -- 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
