Re: Ready for test coreutils-5.2.0-1 [again]
Here's what's changed since my last packaging attempt: 1) The following files are deleted from the distribution: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz 2) Fileutils patches have been included. Package is available at the same location: http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1-src.tar.bz2 http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1.tar.bz2 I have a suggestion for how to deal with the old fileutils/textutils/etc. Provide empty versions of the packages this replaces, bumping each by 1 revision. This way, it should uninstall the old stuff before installing the new stuff. At least, it worked for Jan when the new teTeX packages were made. Also, IIRC, some of the packages were linked against libbinmode.a to prevent problems with CR/LF. I wonder if this ought to be libautomode? Also, our /bin/sh is pretty much braindead (no job control, amoungst other things) since it was decided that shaving 50k off of ash is worth not having a POSIX compliant version. Subsequently, the nohup script will not work with /bin/sh (ash), so it is necessary to force it to use bash instead. See the following scripts from mknetrel to see what needs to be done pre/post config build: http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/fileutils?rev=1.2content-type=text/x-cvsweb-markupcvsroot=cygwin-apps http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/sh-utils?rev=1.3content-type=text/x-cvsweb-markupcvsroot=cygwin-apps http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/textutils?rev=1.2content-type=text/x-cvsweb-markupcvsroot=cygwin-apps Note that it is easier to just to pass -L/usr/lib -lbinmode to LDFLAGS instead of bothering with printing gcc's search path. Finally, this is kinda picky, but why not use bzip2 instead of gzip for the manpages? Cheers, Nicholas
Re: Ready for test coreutils-5.2.0-1 [again]
Nicholas Wourms wrote: [...] I have a suggestion for how to deal with the old fileutils/textutils/etc. Provide empty versions of the packages this replaces, bumping each by 1 revision. This way, it should uninstall the old stuff before installing the new stuff. At least, it worked for Jan when the new teTeX packages were made. Also, IIRC, some of the packages were linked against libbinmode.a to prevent problems with CR/LF. I wonder if this ought to be libautomode? Do I create the empty packages or is it up to the previous maintainers of fileutils/textutils/sh-utils to do this? And is it simply a matter of running: for i in fileutils-4.2-3.tar textutils-2.0.21-2 sh-utils-2.0.15-5; do touch $i; bzip2 $i done About linking with libbinmode.a (or as cgf noted binmode.o), I built fileutils, textutils and sh-utils from the cygwin src packages and I didn't see that being done. Also, our /bin/sh is pretty much braindead (no job control, amoungst other things) since it was decided that shaving 50k off of ash is worth not having a POSIX compliant version. Subsequently, the nohup script will not work with /bin/sh (ash), so it is necessary to force it to use bash instead. See the following scripts from mknetrel to see what needs to be done pre/post config build: http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/fileutils?rev=1.2content-type=text/x-cvsweb-markupcvsroot=cygwin-apps http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/sh-utils?rev=1.3content-type=text/x-cvsweb-markupcvsroot=cygwin-apps http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/textutils?rev=1.2content-type=text/x-cvsweb-markupcvsroot=cygwin-apps The nohup in coreutils is a binary, not a script as in sh-utils. So I don't know whether the mknetrel scripts have any relevance for coreutils. Note that it is easier to just to pass -L/usr/lib -lbinmode to LDFLAGS instead of bothering with printing gcc's search path. Finally, this is kinda picky, but why not use bzip2 instead of gzip for the manpages? If in the future, man pages are to be bzipped instead of gzipped then maybe a patch should be made to generic-build-script. AFAIK no cygwin package currently bzips its man pages. Cheers, Nicholas Mark Blackburn
Re: Ready for test coreutils-5.2.0-1 [again]
Op Fri, 12 Mar 2004 16:45:22 -0500 schreef Mark Blackburn marklist at fangorn.ca in [EMAIL PROTECTED] [...] Hello, following patch does allow the 'check' target to be built. It: *) removes $(EXEEXT) where needed (this should probably go upstream...) *) allows checking to continue after errors To use it the test_rule in the build-script has to be set to 'check'. (there also is a target check-root...) Apply the patch with: patch coreutils-5.2.0-1.patchthe_patch hth, Buzz. the_patch --- coreutils-5.2.0-1.patch.orig2004-03-13 08:51:56.0 -0500 +++ coreutils-5.2.0-1.patch 2004-03-13 10:02:16.0 -0500 @@ -320,9 +320,73 @@ +the coreutils. +category: Base +requires: cygwin libiconv2 libintl2 +diff -urN -x .build -x .inst -x .sinst coreutils-5.2.0-orig/Makefile.am coreutils-5.2.0/Makefile.am +--- coreutils-5.2.0-orig/Makefile.am 2004-02-14 18:42:38.0 -0500 coreutils-5.2.0/Makefile.am2004-03-12 18:31:02.0 -0500 +@@ -21,7 +21,7 @@ + + # Some tests always need root privileges, others need them only sometimes. + check-root: +- cd tests $(MAKE) $@ ++ -cd tests $(MAKE) $@ + + dist-hook: + test -x $(srcdir)/config/install-sh +diff -urN -x .build -x .inst -x .sinst coreutils-5.2.0-orig/Makefile.in coreutils-5.2.0/Makefile.in +--- coreutils-5.2.0-orig/Makefile.in 2004-02-14 18:42:44.0 -0500 coreutils-5.2.0/Makefile.in2004-03-13 09:55:16.0 -0500 +@@ -384,7 +384,14 @@ + else \ + local_target=$$target; \ + fi; \ +-(cd $$subdir $(MAKE) $(AM_MAKEFLAGS) $$local_target) \ ++(cd $$subdir $(MAKE) $(AM_MAKEFLAGS) $$local_target ; \ ++s=$$? ; if \ ++ test x$$target = xcheck ; then true ; \ ++elif test $$s = 0 ; then \ ++ true ; \ ++else \ ++ false ; \ ++fi ) \ + || case $$amf in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \ + done; \ + if test $$dot_seen = no; then \ +@@ -733,7 +740,7 @@ + + # Some tests always need root privileges, others need them only sometimes. + check-root: +- cd tests $(MAKE) $@ ++ -cd tests $(MAKE) $@ + + dist-hook: + test -x $(srcdir)/config/install-sh +diff -urN -x .build -x .inst -x .sinst coreutils-5.2.0-orig/man/Makefile.am coreutils-5.2.0/man/Makefile.am +--- coreutils-5.2.0-orig/man/Makefile.am 2004-01-23 10:54:24.0 -0500 coreutils-5.2.0/man/Makefile.am2004-03-12 18:28:32.0 -0500 +@@ -157,7 +157,7 @@ + programs =\ + echo 'spy:;@echo $$(all_programs)' \ + | MAKEFLAGS= $(MAKE) -s -C ../src -f Makefile -f - spy\ +-| ../src/tr -s ' ' '\n' | $(ASSORT) -u | grep -v '\[' ++| ../src/tr -s ' ' '\n' | sed -e 's/$(EXEEXT)$$//' | $(ASSORT) -u | grep -v '\[' + + .PHONY: check-programs-vs-x + check-programs-vs-x: +diff -urN -x .build -x .inst -x .sinst coreutils-5.2.0-orig/man/Makefile.in coreutils-5.2.0/man/Makefile.in +--- coreutils-5.2.0-orig/man/Makefile.in 2004-02-08 15:12:50.0 -0500 coreutils-5.2.0/man/Makefile.in2004-03-13 09:55:14.0 -0500 +@@ -296,7 +296,7 @@ + programs = \ + echo 'spy:;@echo $$(all_programs)' \ + | MAKEFLAGS= $(MAKE) -s -C ../src -f Makefile -f - spy\ +-| ../src/tr -s ' ' '\n' | $(ASSORT) -u | grep -v '\[' ++| ../src/tr -s ' ' '\n' | sed -e 's/$(EXEEXT)$$//' | $(ASSORT) -u | grep -v '\[' + + all: all-am + diff -urN -x .build -x .inst -x .sinst coreutils-5.2.0-orig/src/Makefile.am coreutils-5.2.0/src/Makefile.am coreutils-5.2.0-orig/src/Makefile.am 2004-02-02 03:12:57.0 -0500 -+++ coreutils-5.2.0/src/Makefile.am2004-03-11 13:09:37.0 -0500 +--- coreutils-5.2.0-orig/src/Makefile.am 2004-02-02 03:12:58.0 -0500 coreutils-5.2.0/src/Makefile.am2004-03-13 09:46:44.0 -0500 @@ -30,7 +30,7 @@ # must precede $(LIBINTL) in order to ensure we use GNU getopt. # But libfetish.a must also follow $(LIBINTL), since libintl uses /the_patch -- ) | | ---/ ---/ Yes, this | This message consist 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
Re: Ready for test coreutils-5.2.0-1
Joshua Daniel Franklin wrote: There are also some patches I'm considering adding from fileutils-4.1-2 (proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1 with the src package for fileutils-4.1-2. I was hoping that the previous maintainer could comment on these patches so I could figure out if they are relevant for the coreutils package. If they the changes haven't been made in the coreutils source, why not continue using the Cygwin-specific patches? agree. Any cygwin-specific patches that were in the old packages that haven't been pushed back all the way to official coreutils, need to be kept in cygwin's coreutils. There are still conflicting binaries: kill.exe : cygwin-1.5.7-1 this is _probably_ cygwin specific. I'd either rename the coreutils one to 'corekill', or not distribute coreutil's kill at all. readlink.exe : cygutils-1.2.4-1 I'll go ahead and remove this program from cygutils -- but only *after* coreutils has made it thru its initial shake-down period. Thus, I won't delay cygutils-1.2.5 waiting for coreutils to finish ITP'ing -- but I'll release cygutils-1.2.6 very soon after coreutils goes 'gold'. uptime.exe : procps-010801-2 my linux box shows /usr/bin/uptime as part of procps, not coreutils. Another candidate for a rename? (coreps?) I think the way other packages have dealt with this problem is by renaming with a prefix (corekill like prockill) or just not installing them. I don't want to speak for Chuck, but the other option is, if he gets a new cygutils ready with Harold's mkshortcut patch he could also remove readlink from cygutils. -- Chuck
Re: Ready for test coreutils-5.2.0-1
On Fri, Mar 12, 2004 at 03:45:44AM -0500, Charles Wilson wrote: Joshua Daniel Franklin wrote: There are also some patches I'm considering adding from fileutils-4.1-2 (proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1 with the src package for fileutils-4.1-2. I was hoping that the previous maintainer could comment on these patches so I could figure out if they are relevant for the coreutils package. If they the changes haven't been made in the coreutils source, why not continue using the Cygwin-specific patches? agree. Any cygwin-specific patches that were in the old packages that haven't been pushed back all the way to official coreutils, need to be kept in cygwin's coreutils. Agree. There are still conflicting binaries: kill.exe : cygwin-1.5.7-1 this is _probably_ cygwin specific. I'd either rename the coreutils one to 'corekill', or not distribute coreutil's kill at all. Let's not distribute it. readlink.exe : cygutils-1.2.4-1 I'll go ahead and remove this program from cygutils -- but only *after* coreutils has made it thru its initial shake-down period. Thus, I won't delay cygutils-1.2.5 waiting for coreutils to finish ITP'ing -- but I'll release cygutils-1.2.6 very soon after coreutils goes 'gold'. Agree. uptime.exe : procps-010801-2 my linux box shows /usr/bin/uptime as part of procps, not coreutils. Another candidate for a rename? (coreps?) Do we need two of these? Let's not distribute it. cgf
Re: Ready for test coreutils-5.2.0-1
So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint Mark Blackburn Christopher Faylor wrote: On Fri, Mar 12, 2004 at 03:45:44AM -0500, Charles Wilson wrote: Joshua Daniel Franklin wrote: There are also some patches I'm considering adding from fileutils-4.1-2 (proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1 with the src package for fileutils-4.1-2. I was hoping that the previous maintainer could comment on these patches so I could figure out if they are relevant for the coreutils package. If they the changes haven't been made in the coreutils source, why not continue using the Cygwin-specific patches? agree. Any cygwin-specific patches that were in the old packages that haven't been pushed back all the way to official coreutils, need to be kept in cygwin's coreutils. Agree. There are still conflicting binaries: kill.exe : cygwin-1.5.7-1 this is _probably_ cygwin specific. I'd either rename the coreutils one to 'corekill', or not distribute coreutil's kill at all. Let's not distribute it. readlink.exe : cygutils-1.2.4-1 I'll go ahead and remove this program from cygutils -- but only *after* coreutils has made it thru its initial shake-down period. Thus, I won't delay cygutils-1.2.5 waiting for coreutils to finish ITP'ing -- but I'll release cygutils-1.2.6 very soon after coreutils goes 'gold'. Agree. uptime.exe : procps-010801-2 my linux box shows /usr/bin/uptime as part of procps, not coreutils. Another candidate for a rename? (coreps?) Do we need two of these? Let's not distribute it. cgf
Re: Ready for test coreutils-5.2.0-1
--- Mark Blackburn [EMAIL PROTECTED] wrote: So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? Leave it as-is and have it rely on Chuck's new cygutils without readlink. These packages, and the empty *utils ones, will have to all be uploaded at the same time to avoid installation issues. (There will probably be some anyway, users downloading and reinstalling old versions and wondering what happened. C'est la vie.) BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
Re: Ready for test coreutils-5.2.0-1
On Fri, 12 Mar 2004, Joshua Daniel Franklin wrote: --- Mark Blackburn marklistatfangorndotca wrote: So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? Leave it as-is and have it rely on Chuck's new cygutils without readlink. These packages, and the empty *utils ones, will have to all be uploaded at the same time to avoid installation issues. (There will probably be some anyway, users downloading and reinstalling old versions and wondering what happened. C'est la vie.) Not that simple, unfortunately. Anyone installing coreutils first and then installing the new version of cygutils (sans readlink) will have to reinstall coreutils to get readlink back... Maybe just putting a note in the announcement would suffice, but somehow I doubt it... BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and ^^ I believe the official name is sh-utils... textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. Umm, doesn't setup's .ini parser support a Replaces: tag? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Ready for test coreutils-5.2.0-1
On Fri, Mar 12, 2004 at 01:54:00PM -0500, Igor Pechtchanski wrote: textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. Umm, doesn't setup's .ini parser support a Replaces: tag? Possibly but I would be surprised if it actually did anything. If this is actually working, please let me know and I'll add it to upset ASAP. cgf
Ready for test coreutils-5.2.0-1 [again]
Here's what's changed since my last packaging attempt: 1) The following files are deleted from the distribution: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz 2) Fileutils patches have been included. Package is available at the same location: http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1-src.tar.bz2 http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1.tar.bz2 832cd01fe909edb311f2c0d4ad258eb3 *coreutils-5.2.0-1-src.tar.bz2 70e3e652d47b8cd4c58a3fb4d9cd7432 *coreutils-5.2.0-1.tar.bz2 Mark Blackburn
Re: Ready for test coreutils-5.2.0-1
Frédéric L. W. Meunier wrote: + /usr/lib/charset.alias I don't think this should be installed (neither by the current fileutils). Maybe Charles Wilson can comment. That's correct. /usr/lib/charset.alias SHOULD only be installed by the gettext package (since all the other projects which provide that file, get it by virtue of their local copy of the gettext sources). Unfortunately, fileutils, texinfo, and textutils all include it -- in addition to gettext. Sigh. -- Chuck
Re: Ready for test coreutils-5.2.0-1
On Thu, 11 Mar 2004, Mark Blackburn wrote: + /usr/lib/charset.alias I don't think this should be installed (neither by the current fileutils). Maybe Charles Wilson can comment. BTW, did you run make check ? Last time I tried it didn't run at all. -- http://www.pervalidus.net/contact.html
Re: Ready for test coreutils-5.2.0-1 [again]
Just now that 5.2.1 has been released ! On Fri, 12 Mar 2004, Mark Blackburn wrote: Here's what's changed since my last packaging attempt: 1) The following files are deleted from the distribution: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz 2) Fileutils patches have been included. -- http://www.pervalidus.net/contact.html
Re: Ready for test coreutils-5.2.0-1
Igor Pechtchanski wrote: On Fri, 12 Mar 2004, Joshua Daniel Franklin wrote: --- Mark Blackburn marklistatfangorndotca wrote: So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? Leave it as-is and have it rely on Chuck's new cygutils without readlink. These packages, and the empty *utils ones, will have to all be uploaded at the same time to avoid installation issues. (There will probably be some anyway, users downloading and reinstalling old versions and wondering what happened. C'est la vie.) Not that simple, unfortunately. Anyone installing coreutils first and then installing the new version of cygutils (sans readlink) will have to reinstall coreutils to get readlink back... Maybe just putting a note in the announcement would suffice, but somehow I doubt it... BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and ^^ I believe the official name is sh-utils... The project name is shellutils, the tarball is named sh-utils-MAJ.MIN.tar.gz see http://www.gnu.org/software/shellutils/shellutils.html Anyways I was just cutting and pasting from http://www.gnu.org/software/coreutils/ quote Introduction The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils http://www.gnu.org/software/fileutils/fileutils.html, shellutils http://www.gnu.org/software/shellutils/shellutils.html, and textutils http://www.gnu.org/software/textutils/textutils.html. Those three have been combined into a single set of utilities called the coreutils. /quote textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. Umm, doesn't setup's .ini parser support a Replaces: tag? Igor
Ready for test coreutils-5.2.0-1
I've created a new coreutils package that I hope addresses some of the
concerns recently voiced about it:
-cp.exe corrupting files when copying from binary to text mounts.
-printf.exe (and others) being statically linked with libintl.a and
libiconv.a created large binaries.
http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1-src.tar.bz2
http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1.tar.bz2
http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint
5a9ee1e8ef9455a14b9ed52c0f52e03e *coreutils-5.2.0-1-src.tar.bz2
779d8871f359223c2337a7ead83e2b9f *coreutils-5.2.0-1.tar.bz2
There are also some patches I'm considering adding from fileutils-4.1-2
(proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1
with the src package for fileutils-4.1-2. I was hoping that the previous
maintainer could comment on these patches so I could figure out if they
are relevant for the coreutils package.
Mark Blackburn
diff -Naur fileutils-4.1/lib/regex.c fileutils-4.1-2/lib/regex.c
--- fileutils-4.1/lib/regex.c 2001-04-02 04:26:14.0 -0400
+++ fileutils-4.1-2/lib/regex.c 2003-07-13 11:21:46.0 -0400
@@ -7841,7 +7841,7 @@
if (msg_size errbuf_size)
{
#if defined HAVE_MEMPCPY || defined _LIBC
- *((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
+ *((char *) mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
#else
memcpy (errbuf, msg, errbuf_size - 1);
errbuf[errbuf_size - 1] = 0;
diff -Naur fileutils-4.1/src/copy.c fileutils-4.1-2/src/copy.c
--- fileutils-4.1/src/copy.c2001-01-13 10:49:44.0 -0500
+++ fileutils-4.1-2/src/copy.c 2001-06-25 18:42:46.0 -0400
@@ -1147,6 +1147,7 @@
}
}
+ ok:
return delayed_fail;
un_backup:
diff -Naur fileutils-4.1/src/install.c fileutils-4.1-2/src/install.c
--- fileutils-4.1/src/install.c 2000-12-25 06:07:36.0 -0500
+++ fileutils-4.1-2/src/install.c 2001-06-15 15:07:52.0 -0400
@@ -390,6 +390,32 @@
install_file_in_file (const char *from, const char *to,
const struct cp_options *x)
{
+ int temp_fd;
+
+ /* CYGNUS LOCAL - dj/install */
+ /* dos/win hack - silently add .exe if it was silently added by gcc.
+ Note that cygwin's stat() checks foo and foo.exe for us (how nice)
+ but open() doesn't */
+ if ((temp_fd = open (from, O_RDONLY | O_BINARY)) 0)
+{
+ /* This isn't freed, but the program exits quickly */
+ char *new_from = (char *) xmalloc (strlen(from) + 5);
+ strcpy(new_from, from);
+ strcat(new_from, .exe);
+ if ((temp_fd = open (new_from, O_RDONLY | O_BINARY)) = 0)
+ {
+char *new_to = (char *) xmalloc (strlen(to) + 5);
+strcpy(new_to, to);
+strcat(new_to, .exe);
+from = new_from;
+to = new_to;
+close (temp_fd);
+ }
+}
+ else
+close (temp_fd);
+ /* END CYGNUS LOCAL - dj/install */
+
if (copy_file (from, to, x))
return 1;
if (strip_files)
diff -Naur fileutils-4.1/src/ln.c fileutils-4.1-2/src/ln.c
--- fileutils-4.1/src/ln.c 2001-02-03 12:57:02.0 -0500
+++ fileutils-4.1-2/src/ln.c2001-06-15 15:07:52.0 -0400
@@ -228,6 +228,13 @@
(!symbolic_link || stat (source, source_stats) == 0)
source_stats.st_dev == dest_stats.st_dev
source_stats.st_ino == dest_stats.st_ino
+/* CYGNUS LOCAL */
+#ifdef __CYGWIN__
+ (strlen (source) 5
+|| strncasecmp (source, dest, strlen (dest)) != 0
+|| strcasecmp (source + strlen (source) - 4, .exe) != 0)
+#endif
+/* END CYGNUS LOCAL */
/* The following detects whether removing DEST will also remove
SOURCE. If the file has only one link then both are surely
the same link. Otherwise check whether they point to the same
@@ -252,7 +259,13 @@
if (!yesno ())
return 0;
}
- else if (!remove_existing_files backup_type == none)
+ else if (!remove_existing_files backup_type == none
+#if defined (__CYGWIN__)
+(strlen (source) 5
+ || strncasecmp (source, dest, strlen (dest)) != 0
+ || strcasecmp (source + strlen (source) - 4, .exe) != 0)
+#endif
+ )
{
error (0, 0, _(%s: File exists), quote (dest));
return 1;
diff -Naur fileutils-4.1/src/system.h fileutils-4.1-2/src/system.h
--- fileutils-4.1/src/system.h 2000-04-19 17:41:14.0 -0400
+++ fileutils-4.1-2/src/system.h2001-06-15 15:07:52.0 -0400
@@ -272,7 +272,11 @@
#endif
#ifndef ST_NBLOCKSIZE
-# define ST_NBLOCKSIZE 512
+# ifdef S_BLKSIZE
+# define ST_NBLOCKSIZE S_BLKSIZE
+# else
+# define ST_NBLOCKSIZE 512
+# endif
#endif
#include sys2.h
diff -urN -x .build -x .inst -x .sinst
coreutils-5.2.0-orig/CYGWIN-PATCHES/coreutils.README
coreutils-5.2.0/CYGWIN-PATCHES/coreutils.README
---
Re: Ready for test coreutils-5.2.0-1
Mark,
Thanks for packaging this and being willing to maintain it.
Comments below.
On Thu, Mar 11, 2004 at 04:45:47PM -0500, Mark Blackburn wrote:
I've created a new coreutils package that I hope addresses some of the
concerns recently voiced about it:
-cp.exe corrupting files when copying from binary to text mounts.
-printf.exe (and others) being statically linked with libintl.a and
libiconv.a created large binaries.
http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1-src.tar.bz2
http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1.tar.bz2
http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint
5a9ee1e8ef9455a14b9ed52c0f52e03e *coreutils-5.2.0-1-src.tar.bz2
779d8871f359223c2337a7ead83e2b9f *coreutils-5.2.0-1.tar.bz2
There are also some patches I'm considering adding from fileutils-4.1-2
(proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1
with the src package for fileutils-4.1-2. I was hoping that the previous
maintainer could comment on these patches so I could figure out if they
are relevant for the coreutils package.
If they the changes haven't been made in the coreutils source, why
not continue using the Cygwin-specific patches?
There are still conflicting binaries:
kill.exe : cygwin-1.5.7-1
readlink.exe : cygutils-1.2.4-1
uptime.exe : procps-010801-2
I think the way other packages have dealt with this problem is by
renaming with a prefix (corekill like prockill) or just
not installing them. I don't want to speak for Chuck, but the
other option is, if he gets a new cygutils ready with Harold's
mkshortcut patch he could also remove readlink from cygutils.
As for obsoleting {file,sh-,text}utils, what we did with
newlib-man-cygwin-doc was create an empty newlib-man-$NEWVERISON
and put that in cygwin-doc's requires. That could work here.
Speaking of setups.hint, coreutils' ldesc starts with A command line
file transfer program. It suppore Utilities ???
Other than that, the packages looks good. My basic see-if-it-runs
tests worked (for i in *exe; do ./$i --help foo; done), and the
source package builds the binary package.
By the way, downloading the packages was really slow for me. I took
the liberty of putting them here for any other potential reviewers:
http://ns1.iocc.com/~joshua/cygwin/coreutils-5.2.0-1-src.tar.bz2
http://ns1.iocc.com/~joshua/cygwin/coreutils-5.2.0-1.tar.bz2
http://ns1.iocc.com/~joshua/cygwin/setup.hint
snip
#!/bin/sh
wget http://ns1.iocc.com/~joshua/cygwin/coreutils-5.2.0-1-src.tar.bz2
wget http://ns1.iocc.com/~joshua/cygwin/coreutils-5.2.0-1.tar.bz2
wget http://ns1.iocc.com/~joshua/cygwin/setup.hint
snip
