Re: coreutils-5.3.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Attention: cygutils, gettext, and procps maintainers - see below for packaging conflicts. According to Corinna Vinschen on 1/31/2005 2:38 AM: This release is marked as test for several reasons: Please consider to put this package out of test in a couple of days. I forgot to mention one other reason - upstream designated 5.3.0 as unstable, as compared to 5.2.1 being stable. But it has worked pretty reliably for me, so you are right that I should bump it to current after a couple of weeks of no complaints on the cygwin list from early testers. [...] - pathchk regressed in behavior. In 5.2.1, `pathchk file/x' failed with a message that file is not a directory, but in 5.3.0 it silently succeeds. I don't know if this is worth patching locally or waiting for cygwin 1.5.13. That's a Cygwin problem and will be fixed in 1.5.13, thanks to Pierre. Then I won't bother writing a workaround patch for `pathchk' in the 1.5.12 timeframe unless someone asks for one. Any idea when 1.5.13 comes out? Will 1.5.13 support trailing spaces in filenames on a managed mount? - I bundled coreutils kill as gkill, rather than omitting it altogether Oh boy. Now we have *three* kills, kill from the Cygwin package, prockill from the procps package and gkill from the coreutils package. Isn't that overkill? Nice pun. And remember that bash (but not ash) has a builtin kill, different from all three executables. About the only feature I can see that GNU kill provides that the others don't is a nicer table listing with `gkill -t', which is why I included it. Packaging looks good. I've uploaded the package. Please send an announce posting to cygwin-announce. Don't forget to include the unsubscribe instructions in your announcement. Hmm, I found some packaging issues (maybe we should fold a variation of this check into the generic-build-script): $ tar tjvf coreutils-5.3.0-1.tar.bz2 | sed -e 's,.*usr/,/usr/,' -e 's, - .*,,' | grep -v '/$' | xargs cygcheck -fv | grep -v coreutils-5.2.1 /usr/bin/readlink.exe: found in package cygutils-1.2.5-1 /usr/lib/charset.alias: found in package gettext-0.14.1-1 /usr/lib/charset.alias: found in package libiconv-1.9.2-1 /usr/bin/uptime.exe: found in package procps-010801-2 I think /usr/lib/charset.alias should be owned by gettext. How about readlink and uptime, should they be switched to ownership by coreutils, or should I rename them to greadlink and guptime? It looks like I will have to make a -2 release soon to get rid of these packaging conflicts. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB/jg584KuGfSFAYARAoCeAKCG/D/q0Zgvh5KWWQWR/qs1FZWlYACfVQCL x6zVM6pUQemfiV6MiYcq8PI= =c8BV -END PGP SIGNATURE-
Re: coreutils-5.3.0-1
On Jan 31 06:52, Eric Blake wrote: Attention: cygutils, gettext, and procps maintainers - see below for packaging conflicts. According to Corinna Vinschen on 1/31/2005 2:38 AM: This release is marked as test for several reasons: Please consider to put this package out of test in a couple of days. I forgot to mention one other reason - upstream designated 5.3.0 as unstable, as compared to 5.2.1 being stable. But it has worked pretty reliably for me, so you are right that I should bump it to current after a couple of weeks of no complaints on the cygwin list from early testers. Hmm, if it's even unstable for the upstream maintainers... Then I won't bother writing a workaround patch for `pathchk' in the 1.5.12 timeframe unless someone asks for one. Any idea when 1.5.13 comes out? Later this year. Packaging looks good. I've uploaded the package. Please send an announce posting to cygwin-announce. Don't forget to include the unsubscribe instructions in your announcement. Hmm, I found some packaging issues (maybe we should fold a variation of this check into the generic-build-script): $ tar tjvf coreutils-5.3.0-1.tar.bz2 | sed -e 's,.*usr/,/usr/,' -e 's, - .*,,' | grep -v '/$' | xargs cygcheck -fv | grep -v coreutils-5.2.1 /usr/bin/readlink.exe: found in package cygutils-1.2.5-1 /usr/lib/charset.alias: found in package gettext-0.14.1-1 /usr/lib/charset.alias: found in package libiconv-1.9.2-1 /usr/bin/uptime.exe: found in package procps-010801-2 Urgh! Ok, that's not good. Please remove charset.alias from the coreutils binary package. There's no reason to provide it. As far as readlink(1) is concerned, I guess it makes sense to use the coreutils version and remove the cygutils version. What about uptime? I guess it should stay in procps, and not be packed with coreutils to keep problems at a minimum. It looks like I will have to make a -2 release soon to get rid of these packaging conflicts. I guess, yes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: coreutils-5.3.0-1
On Mon, 31 Jan 2005, Corinna Vinschen wrote: On Jan 29 11:05, Eric Blake wrote: I think I finally have something ready for submission on the coreutils front. Do I get the couple of gold stars promised in http://sources.redhat.com/ml/cygwin/2005-01/msg00727.html? Absolutely. Igor, do you have a couple of them handy? Yep, as long as Eric is content with regular gold stars -- I'm still working on the flashing ones... [snip] - I bundled coreutils kill as gkill, rather than omitting it altogether Oh boy. Now we have *three* kills, kill from the Cygwin package, prockill from the procps package and gkill from the coreutils package. Isn't that overkill? ln -s /bin/shutdown /bin/overkill ? ;-) Thanks again for taking overe maintainership. That's worth every gold star :-) Definitely. 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
