[PATCH] setup: use libgcrypt for md5
IIUC libmd5-rfc preceded libgcrypt in setup by a few years. But now
that we're using libgcrypt for gpg/s-expr, I think it only makes sense
that we use it as well for MD5 hashing. (FWIW, this also shaves 2.5KB
off the stripped, uncompressed binary.) Patch attached.
Yaakov
2012-11-08 Yaakov Selkowitz yselkowitz@...
* Makefile.am (EXTRA_DIST): Remove libmd5-rfc files.
(setup_SOURCES): Ditto.
* download.cc: Remove unused include.
* csu_util/MD5Sum.cc: Port from libmd5-rfc to libgcrypt.
* csu_util/MD5Sum.h: Ditto.
* libmd5-rfc/*: Remove.
Index: Makefile.am
===
RCS file: /cvs/cygwin-apps/setup/Makefile.am,v
retrieving revision 2.87
diff -u -p -r2.87 Makefile.am
--- Makefile.am 1 Jun 2012 15:51:56 - 2.87
+++ Makefile.am 8 Nov 2012 06:56:17 -
@@ -49,8 +49,6 @@ EXTRA_DIST = \
choose-rtarrow.bmp \
choose-spin.bmp \
cygwin.ico \
- libmd5-rfc/README \
- libmd5-rfc/md5main.c \
setup.exe.manifest \
tree-minus.bmp \
tree-plus.bmp
@@ -274,9 +272,7 @@ setup_SOURCES = \
csu_util/rfc1738.cc \
csu_util/rfc1738.h \
csu_util/version_compare.cc \
- csu_util/version_compare.h \
- libmd5-rfc/md5.c \
- libmd5-rfc/md5.h
+ csu_util/version_compare.h
# autoload code does not optimize properly with gcc-4.x
autoload.o: CFLAGS += -O0
Index: download.cc
===
RCS file: /cvs/cygwin-apps/setup/download.cc,v
retrieving revision 2.55
diff -u -p -r2.55 download.cc
--- download.cc 29 Apr 2011 12:43:59 - 2.55
+++ download.cc 8 Nov 2012 06:56:17 -
@@ -51,7 +51,6 @@ static const char *cvsid =
#include Exception.h
#include getopt++/BoolOption.h
-#include csu_util/MD5Sum.h
using namespace std;
Index: csu_util/MD5Sum.cc
===
RCS file: /cvs/cygwin-apps/setup/csu_util/MD5Sum.cc,v
retrieving revision 1.2
diff -u -p -r1.2 MD5Sum.cc
--- csu_util/MD5Sum.cc 8 Apr 2008 23:50:54 - 1.2
+++ csu_util/MD5Sum.cc 8 Nov 2012 06:56:17 -
@@ -16,10 +16,6 @@
#include string.h
#include stdexcept
-namespace libmd5_rfc {
-#include ../libmd5-rfc/md5.h
-}
-
MD5Sum::MD5Sum(const MD5Sum source)
{
*this = source;
@@ -33,7 +29,7 @@ MD5Sum::operator= (const MD5Sum source)
internalData = 0;
if (source.internalData)
{
-internalData = new libmd5_rfc::md5_state_s;
+internalData = new gcry_md_hd_t;
*internalData = *(source.internalData);
}
return *this;
@@ -56,9 +52,9 @@ void
MD5Sum::begin()
{
if (internalData) delete internalData;
- internalData = new libmd5_rfc::md5_state_s;
+ internalData = new gcry_md_hd_t;
state = Accumulating;
- libmd5_rfc::md5_init(internalData);
+ gcry_md_open(internalData, GCRY_MD_MD5, 0);
}
void
@@ -67,7 +63,7 @@ MD5Sum::append(const unsigned char* data
if (!internalData)
throw new std::logic_error(MD5Sum::append() called on an object not
in the 'Accumulating' state);
- libmd5_rfc::md5_append(internalData, data, nbytes);
+ gcry_md_write(*internalData, data, nbytes);
}
void
@@ -76,7 +72,7 @@ MD5Sum::finish()
if (!internalData)
throw new std::logic_error(MD5Sum::finish() called on an object not
in the 'Accumulating' state);
- libmd5_rfc::md5_finish(internalData, digest);
+ memcpy(digest, gcry_md_read(*internalData, GCRY_MD_MD5), 16);
state = Set;
delete internalData; internalData = 0;
}
Index: csu_util/MD5Sum.h
===
RCS file: /cvs/cygwin-apps/setup/csu_util/MD5Sum.h,v
retrieving revision 1.1
diff -u -p -r1.1 MD5Sum.h
--- csu_util/MD5Sum.h 22 Nov 2004 18:15:34 - 1.1
+++ csu_util/MD5Sum.h 8 Nov 2012 06:56:17 -
@@ -16,7 +16,7 @@
#define SETUP_MD5SUM_H
/*
- * A C++ wrapper for the libmd5-rfc library, which additionally provides
+ * A C++ wrapper for the libgcrypt library, which additionally provides
* storage and comparison of MD5 checksums.
*
* An MD5Sum may be given a value in one of two ways:
@@ -27,10 +27,8 @@
*/
#include string
-
-namespace libmd5_rfc {
- struct md5_state_s;
-};
+#include win32.h
+#include gcrypt.h
class MD5Sum
{
@@ -54,7 +52,7 @@ class MD5Sum
private:
enum { Empty, Accumulating, Set } state;
unsigned char digest[16];
-libmd5_rfc::md5_state_s* internalData;
+gcry_md_hd_t* internalData;
};
#endif /* SETUP_MD5SUM_H */
Re: [PATCH] setup: use libgcrypt for md5
On Nov 8 02:03, Yaakov (Cygwin/X) wrote: IIUC libmd5-rfc preceded libgcrypt in setup by a few years. But now that we're using libgcrypt for gpg/s-expr, I think it only makes sense that we use it as well for MD5 hashing. (FWIW, this also shaves 2.5KB off the stripped, uncompressed binary.) Patch attached. Yaakov 2012-11-08 Yaakov Selkowitz yselkowitz@... * Makefile.am (EXTRA_DIST): Remove libmd5-rfc files. (setup_SOURCES): Ditto. * download.cc: Remove unused include. * csu_util/MD5Sum.cc: Port from libmd5-rfc to libgcrypt. * csu_util/MD5Sum.h: Ditto. * libmd5-rfc/*: Remove. Looks ok to me. Please apply. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] openmpi-1.6.3-2
On Nov 3 19:52, marco atzeri wrote: Hi, intention to package the OpenMPI: A High Performance Message Passing Library http://www.open-mpi.org/ already present in all major disti's. To download (remove the index.html's) : wget -r -np -nH --cut-dirs=1 \ http://matzeri.altervista.org/cygwin-1.7/openmpi/index.html find openmpi -name index.html -o -name md5.sum | xargs rm Filelist: libopenmpi/libopenmpi-1.6.3-2.tar.bz2 libopenmpi/setup.hint libopenmpi-devel/libopenmpi-devel-1.6.3-2.tar.bz2 libopenmpi-devel/setup.hint openmpi-1.6.3-2-src.tar.bz2 openmpi-1.6.3-2.tar.bz2 setup.hint ADVISE: 1) Cygserver is required to provide IPC shared memory otherwise the programs will fail as: $ mpirun -n 4 ./hello_c.exe Bad system call Ideally the openmpi package would allow to use POSIX IPC rather than XSI IPC. POSIX IPC doesn't require a server process. If there's a configure option to that effect, I'd use it. Otherwise, just add a README to tell the user about the dependency. 2) Binary are not stripped as otherwise they will be not functional. Reason to be determined. Stuff like that is seriously fishy. What happens? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
src/winsup/cygwin ChangeLog.64bit fhandler_soc ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-11-08 11:32:02 Modified files: winsup/cygwin : ChangeLog.64bit fhandler_socket.cc Log message: * fhandler_socket.cc (fhandler_socket::ioctl): Don't use __ms_u_long directly. Rather only use it on 64 bit. Add comment to explain the problem. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.28r2=1.1.2.29 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.291.2.5r2=1.291.2.6
src/winsup/cygwin ChangeLog.64bit cygheap.h fo ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-11-08 17:25:48 Modified files: winsup/cygwin : ChangeLog.64bit cygheap.h fork.cc heap.cc hookapi.cc kernel32.cc fhandler.h mtinfo.h fhandler_tape.cc Log message: * cygheap.h (struct user_heap_info): Change type of chunk to SIZE_T. Remove unused slop member. * fork.cc (fork): Rename esp to stackp. Add 64 bit asm expression to fetch stack pointer. (child_copy): Use platform independent types. * heap.cc (eval_start_address): Add comment. Disable 3GB code on 64 bit. (eval_initial_heap_size): Use platform independent types. Fix debug printf format strings. (sbrk): Add comment. Change argument type according to newlib definition. Use platform independent types. Drop unneeded else and move comment to the right spot. * hookapi.cc (PEHeaderFromHModule): Return PVOID. Add comment to explain why. Add bool parameter to return if target executable is 64 bit or not. (rvadelta_get): New inline function to fetch section address platform independent. (rvadelta32, rvadelta64): Platform dependent wrappers. (rvadelta): Change to macro calling the platform dependent rvadelta wrappers. (putmem): Define platform dependent THUNK_FUNC_TYPE and use throughout. (RedirectIAT): Add comment. (get_export): Add comment. (find_first_notloaded_dll): Allow to fetch information in a platform and target independent way. (hook_or_detect_cygwin): Ditto. Recognize the cyg64win1.dll file name as well. * kernel32.cc (CreateFileMappingW): Cast to avoid compiler warning. * fhandler.h (class fhandler_dev_tape): Replace mt_evt with an OVERLAPPED structure ov. * mtinfo.h (class mtinfo_part): Define members as int32_t rather than long. Change member function declarations accordingly. (class mtinfo_drive): Ditto. Store OVERLAPPED pointer rather than holding the full structure. Add comment to explain why. * fhandler_tape.cc: Accommodate above changes throughout. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.29r2=1.1.2.30 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygheap.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.161.2.3r2=1.161.2.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fork.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.237r2=1.237.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/heap.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.65r2=1.65.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/hookapi.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.29.2.1r2=1.29.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/kernel32.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.11r2=1.11.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.473.2.5r2=1.473.2.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mtinfo.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.12r2=1.12.10.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_tape.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.83.2.3r2=1.83.2.4
winsup/cygwin ChangeLog fhandler_termios.cc fh ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2012-11-08 17:27:00 Modified files: cygwin : ChangeLog fhandler_termios.cc fhandler_tty.cc sigproc.cc Log message: * fhandler_termios.cc (fhandler_termios::line_edit): Don't do special character handling when stopped by CTRL-S. * fhandler_tty.cc (bytes_available): Add arguments to debug_only_printf call. * sigproc.cc (proc_subproc): Simplify some if logic. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5987r2=1.5988 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_termios.cc.diff?cvsroot=uberbaumr1=1.102r2=1.103 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=uberbaumr1=1.273r2=1.274 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.388r2=1.389
src/winsup/cygwin ChangeLog sigproc.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-11-08 18:41:58 Modified files: winsup/cygwin : ChangeLog sigproc.cc Log message: * sigproc.cc (proc_subproc): Delete unused variable child. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5988r2=1.5989 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.cc.diff?cvsroot=srcr1=1.389r2=1.390
src/winsup/cygwin ChangeLog ChangeLog.64bit fh ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-11-08 18:51:28 Modified files: winsup/cygwin : ChangeLog ChangeLog.64bit fhandler_termios.cc fhandler_tty.cc sigproc.cc tty.h Log message: * tty.h (class tty): Store from_master and to_master HANDLEs in unions to make sure the storage is 64 bit compatible. Add comment to explain why. (from_master): Convert to read accessor method. (to_master): Ditto. (set_from_master): New method to store HANDLE value 64 bit clean. (set_to_master): Ditto. * fhandler_tty.cc: Fix debug printfs to work in 64 bit mode as well. Change usage of from_master and to_master throughout to accommodate aforementioned change. * fhandler_termios.cc (fhandler_termios::ioctl): Add cast to avoid compiler warning. Pull in changes from HEAD. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.25r2=1.5939.2.26 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.64bit.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.1.2.30r2=1.1.2.31 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_termios.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.101.2.2r2=1.101.2.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.268.2.4r2=1.268.2.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.388.2.2r2=1.388.2.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/tty.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.34.2.2r2=1.34.2.3
Info for the item does patch.exe work different than other unx patch tools? (i.e. hunk 1 out of 3 hunks failed)
Hello, using Cygwin patch.exe in a batch file I ran into the problem that patch failed for some reason (hunk 1 out of 3 hunks failed): Investigating this issue I found that inserting unix2dos my.patch before applying the patch was my friend! Being paranoid I tried dos2unix my.patch before applying the patch - and it was my friend too! Than I tried to run my batch script again without any unix2dos or dos2unix commands and I had my problem back. I have to say here, that my.patch is generated using diff inside my batch. So now I had a closer look to the diff generated my.patch file and I found out, that the file had somehow hybrid line endings: * the header with the file names was unix-like * the body with the diff info was dos-like The reason probably is, that my sources are with dos-like line endings. I assume, diff starts creating the my.patch with unix-like line-endings and than adds the diff info as it is. Than, when patch.exe gets the my.patch to execute it it sees unix-like line endings at the beginning of the my.patch, assumes all is that way and gets later trouble applying the patch info. I do not regard this as a bug, but I guess I am not the only one spending a few hours with that issue. I would like to propose an additional command line switch for the Cygwin diff.exe and/or patch.exe to tell about the line-endings. Thomas -- 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: Info for the item does patch.exe work different than other unx patch tools? (i.e. hunk 1 out of 3 hunks failed)
On Thu, Nov 8, 2012 at 5:30 AM, Thomas Höhenleitner wrote: So now I had a closer look to the diff generated my.patch file and I found out, that the file had somehow hybrid line endings: * the header with the file names was unix-like * the body with the diff info was dos-like The reason probably is, that my sources are with dos-like line endings. I assume, diff starts creating the my.patch with unix-like line-endings and than adds the diff info as it is. Possibly. Maybe your new file has the CRLF and the old file has only LF. Than, when patch.exe gets the my.patch to execute it it sees unix-like line endings at the beginning of the my.patch, assumes all is that way and gets later trouble applying the patch info. That depends. If the patch executable has the file modes in _O_TEXT then it will be capable of reading the mixed line endings fine. If the patch executable has the file modes in _O_BINARY then it will read the patch file in binary mode receiving the CR as part of the patched line. I do not regard this as a bug, but I guess I am not the only one spending a few hours with that issue. It is not a bug, that is correct. I would like to propose an additional command line switch for the Cygwin diff.exe and/or patch.exe to tell about the line-endings. If you use the --help argument to patch, you'll find one already that fits. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Info for the item does patch.exe work different than other unx patch tools? (i.e. hunk 1 out of 3 hunks failed)
On 08/11/2012 5:30 AM, Thomas Höhenleitner wrote: Hello, using Cygwin patch.exe in a batch file I ran into the problem that patch failed for some reason (hunk 1 out of 3 hunks failed): Investigating this issue I found that inserting unix2dos my.patch before applying the patch was my friend! Being paranoid I tried dos2unix my.patch before applying the patch - and it was my friend too! I've hit problems trying to apply a dos-like patch to a unix-like file, and vice-versa, but not what you describe. Also, problems with line endings tend to go all-or-nothing: either all hunks fail (all line endings differ), or all succeed in the absence of other conflicts. I almost wonder if the file you edited somehow got inconsistent line endings only for the changed lines; that would imply that the two successful hunks have only insertions and/or deletions, while the failed hunk has actual changes. Hard to say without seeing the files involved, tho. Also, did you try -b/-w with diff, and/or -l with patch? Ryan -- 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: aspell 0.60.6.1-1 does not install any dictionaries by default (RE: git gui 1.7.9-1: spell checking is unavailable error message)
Greetings, Matt Seitz! It looks like the Fedora team originally installed the aspell-en dictionary by default whenever aspell was installed. Then they dropped it as a dependency for the same reason given earlier in this thread: that it's not really required for aspell. Then they made installing the aspell-en dictionary a requirement again, to avoid issues like this. https://bugzilla.redhat.com/show_bug.cgi?id=494084 Does it make sense for Cygwin to follow Fedora's lead, and install aspell-en by default when aspell is installed? No, it makes sense to report this issue to Git maintaners. -- WBR, Andrey Repin (anrdae...@freemail.ru) 08.11.2012, 18:35 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Info for the item does patch.exe work different than other unx patch tools? (i.e. hunk 1 out of 3 hunks failed)
Thanks a lot, Earnie, for your answer. I do not know whitch patch command line switch do you mean. With -l I had already tried. In my answer to Ryan follows an example, I created. Bes regards, Thomas 2012/11/8 Earnie Boyd ear...@users.sourceforge.net: On Thu, Nov 8, 2012 at 5:30 AM, Thomas Höhenleitner wrote: So now I had a closer look to the diff generated my.patch file and I found out, that the file had somehow hybrid line endings: * the header with the file names was unix-like * the body with the diff info was dos-like The reason probably is, that my sources are with dos-like line endings. I assume, diff starts creating the my.patch with unix-like line-endings and than adds the diff info as it is. Possibly. Maybe your new file has the CRLF and the old file has only LF. Than, when patch.exe gets the my.patch to execute it it sees unix-like line endings at the beginning of the my.patch, assumes all is that way and gets later trouble applying the patch info. That depends. If the patch executable has the file modes in _O_TEXT then it will be capable of reading the mixed line endings fine. If the patch executable has the file modes in _O_BINARY then it will read the patch file in binary mode receiving the CR as part of the patched line. I do not regard this as a bug, but I guess I am not the only one spending a few hours with that issue. It is not a bug, that is correct. I would like to propose an additional command line switch for the Cygwin diff.exe and/or patch.exe to tell about the line-endings. If you use the --help argument to patch, you'll find one already that fits. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Info for the item does patch.exe work different than other unx patch tools? (i.e. hunk 1 out of 3 hunks failed)
May be because of the attatched file the mail before is not delivered.. Here is a temporary link to the attached file: https://www.dropbox.com/s/7etntr4jukp9t5l/ExamplePatch.zip 2012/11/8 Thomas Höhenleitner tho...@seerose.net: Hello Ryan, first I appologize for the wrong hunks-failed info. I did not remeber it correctly as I wrote the mail. *3 out of 3 hunks FAILED is what patch tells exactly in example. *I tried patch with the -l switch without success before. *Also --ignore-all-space I use with diff (what is -w and probably implies -b) *now I tried also the switch -a with diff: no difference I created a small example to play with and added it as zip file to this mail. Best regards, Thomas 2012/11/8 Ryan Johnson ryan.john...@cs.utoronto.ca: On 08/11/2012 5:30 AM, Thomas Höhenleitner wrote: Hello, using Cygwin patch.exe in a batch file I ran into the problem that patch failed for some reason (hunk 1 out of 3 hunks failed): Investigating this issue I found that inserting unix2dos my.patch before applying the patch was my friend! Being paranoid I tried dos2unix my.patch before applying the patch - and it was my friend too! I've hit problems trying to apply a dos-like patch to a unix-like file, and vice-versa, but not what you describe. Also, problems with line endings tend to go all-or-nothing: either all hunks fail (all line endings differ), or all succeed in the absence of other conflicts. I almost wonder if the file you edited somehow got inconsistent line endings only for the changed lines; that would imply that the two successful hunks have only insertions and/or deletions, while the failed hunk has actual changes. Hard to say without seeing the files involved, tho. Also, did you try -b/-w with diff, and/or -l with patch? Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Info for the item does patch.exe work different than other unx patch tools? (i.e. hunk 1 out of 3 hunks failed)
Thomas Höhenleitner wrote: snip 2012/11/8 Thomas Höhenleitner thomas@snip: snip 2012/11/8 Ryan Johnson ryan.johnson@snip: snip Per http://cygwin.com/lists.html, please don't include raw email addresses in your replies. This mailing list is archived online, and we'd rather not feed the spammers. See also http://cygwin.com/acronyms/#PCYMTNQREAIYR -- 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: Info for the item does patch.exe work different than other unx patch tools? (i.e. hunk 1 out of 3 hunks failed)
On Thu, Nov 8, 2012 at 10:15 AM, Thomas Höhenleitner wrote: Please do not top post. Thanks a lot, Earnie, for your answer. I do not know whitch patch command line switch do you mean. With -l I had already tried. I should have said diff instead of patch. --strip-trailing-cr -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: aspell 0.60.6.1-1 does not install any dictionaries by default (RE: git gui 1.7.9-1: spell checking is unavailable error message)
From: Andrey Repin From: Matt Seitz https://bugzilla.redhat.com/show_bug.cgi?id=494084 Does it make sense for Cygwin to follow Fedora's lead, and install aspell-en by default when aspell is installed? No, it makes sense to report this issue to Git maintaners. OK, I can do that. However, based on the Fedora bug reports, it sounds like this could be an issue for other aspell client applications. It appears that the normal behavior for aspell clients is to report an error if the default dictionary is specified and no dictionary is present. So it seems like the options are: 1. Change git-gui and other aspell based applications to suppress their error message when the default dictionary is specified and no dictionary is present. 2. Change setup.exe to install the default dictionary (i.e., the dictionary for the current locale) automatically when aspell is installed. 3. Change setup.exe to remind the user to install the default dictionary when aspell is installed. 4. Keep the current behavior, and let the end-user figure out what went wrong and how to fix it. Option 2 seems to be the solution that Fedora went with. -- 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: aspell 0.60.6.1-1 does not install any dictionaries by default (RE: git gui 1.7.9-1: spell checking is unavailable error message)
From: Matt Seitz I looked through setup.log. I see that something triggered aspell to be installed on Nov. 5: 2012/11/05 06:48:59 Adding required dependency aspell: Selecting version 0.60.6.1-1 for installation. 2012/11/05 06:48:59 Adding required dependency libaspell15: Selecting version 0.60.6.1-1 for installation. What's the best way for me to determine which packaged triggered adding the required dependency aspell? -- 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: aspell 0.60.6.1-1 does not install any dictionaries by default (RE: git gui 1.7.9-1: spell checking is unavailable error message)
From: Matt Seitz From: Matt Seitz I looked through setup.log. I see that something triggered aspell to be installed on Nov. 5: What's the best way for me to determine which packaged triggered adding the required dependency aspell? I'm suspecting the problem has something to do with the update of TeXmacs on Nov. 4. The setup.ini file does say that TeXmacs requires aspell. But on the other hand, it appears that the previous version of TeXmacs also requires aspell. So I'm still looking for a definitive answer as to what triggered the aspell installation. -- 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: aspell 0.60.6.1-1 does not install any dictionaries by default (RE: git gui 1.7.9-1: spell checking is unavailable error message)
Greetings, Matt Seitz! https://bugzilla.redhat.com/show_bug.cgi?id=494084 Does it make sense for Cygwin to follow Fedora's lead, and install aspell-en by default when aspell is installed? No, it makes sense to report this issue to Git maintaners. OK, I can do that. However, based on the Fedora bug reports, it sounds like this could be an issue for other aspell client applications. It appears that the normal behavior for aspell clients is to report an error if the default dictionary is specified and no dictionary is present. Application should not error out on mistakes in a third-party module configuration, that is not even required for application to run, and merely providing a cosmetic functionality. So it seems like the options are: 1. Change git-gui and other aspell based applications to suppress their error message when the default dictionary is specified and no dictionary is present. Specified where? If it's a configuration in Git-GUI, it must report it as inconsistency and suggest the way to amend it. If it's a configuration in aspell, and Git-GUI merely asking for default behavior, then again, Git-GUI should check, if the module can work at all, before trying to use it and throw errors at the user. 2. Change setup.exe to install the default dictionary (i.e., the dictionary for the current locale) automatically when aspell is installed. Unlikely to happen. Even if do, it would only be a suggestion. Unless you take the burden of implementing full APT functionality into cygwin setup.exe. 3. Change setup.exe to remind the user to install the default dictionary when aspell is installed. 4. Keep the current behavior, and let the end-user figure out what went wrong and how to fix it. Option 2 seems to be the solution that Fedora went with. -- WBR, Andrey Repin (anrdae...@freemail.ru) 08.11.2012, 22:59 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: aspell 0.60.6.1-1 does not install any dictionaries by default (RE: git gui 1.7.9-1: spell checking is unavailable error message)
From: Andrey Repin So it seems like the options are: 1. Change git-gui and other aspell based applications to suppress their error message when the default dictionary is specified and no dictionary is present. Specified where? Sorry, I wasn't clear. The git-gui program is just telling aspell to use the default aspell dictionary. It's then up to aspell to decide what the default dictionary is. The relevant git-gui code appears to be here: http://repo.or.cz/w/git-gui.git/blob/HEAD:/git-gui.sh#l3913 If it's a configuration in aspell, and Git-GUI merely asking for default behavior, then again, Git-GUI should check, if the module can work at all, before trying to use it and throw errors at the user. OK, I can suggest that to the Git maintainers. -- 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
(base-files 4.1-2) Typos in Default Home Directory Files
I send this to report a comment typo in the the skeleton files automatically added to home folders (package base-files was updated to version 4.1-2 to verify the typos were still in the newest release). 1901/4086 MB RAM 0.00 0.00 0.00 2/7 Thu Nov 08 11:00:55 11:00 PM [0 jobs] [ethan@firetail: +1] /etc/defaults/etc/skel $ grep -rn benifitial . ./.bashrc:21:# would be benifitial to all, please feel free to send ./.bash_profile:21:# would be benifitial to all, please feel free to send ./.inputrc:21:# would be benifitial to all, please feel free to send 1896/4086 MB RAM 0.00 0.00 0.00 1/8 Thu Nov 08 11:01:09 11:01 PM [0 jobs] [ethan@firetail: +1] /etc/defaults/etc/skel $ grep -rn benificial . ./.profile:21:# would be benificial to all, please feel free to send The correct spelling is be beneficial. Perfect normality is impossible. Be unique! --Ethan Warth (redyoshi49q) -- 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
