Matthew Woehlke <[EMAIL PROTECTED]> writes:
> (Also, apologies for dropping bugs-gzip, I'm used to gmane handling
> cross-posting, but obviously it doesn't if the list isn't on
> gmane. Paul: I take it you have not heard back from them yet?)
No. Perhaps you can bug them separately?
Paul Eggert wrote:
Matthew Woehlke writes:
Honestly, I'm a little confused/amused with this whole
situation... :-)
I'm used to using gzip as a stream compressor that /occasionally/
opens a file, unlinks it, and puts back a different file.
The problem is that "gzip -r DIR" recursively traverses
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Honestly, I'm a little confused/amused with this whole
> situation... :-)
> I'm used to using gzip as a stream compressor that /occasionally/
> opens a file, unlinks it, and puts back a different file.
The problem is that "gzip -r DIR" recursively tra
Karl Berry wrote:
>gnulib-tool
>
> That's for Bruno, I expect.
I abstain. The keyword has served its purpose once, by allowing us to easily
diagnose that
a user's gnulib checkout was 6 months old. But OTOH I believe, with Jim, that
git's nonlinear
branch topology makes this unusable in the f
Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
gzip 1.3.6 does not build on Tandem NSK/OSS because it uses fchdir,
which does not exist on NSK/OSS. This was added in gzip 1.3.5. Is
there a replacement for this function (e.g. in gnulib)? Can its use be
removed/conditionalized?
I
