GNU bug report logs - #22845
FYI: release soon

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22845 in the body.
You can then email your comments to 22845 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-grep <at> gnu.org
Subject: FYI: release soon
Date: Sun, 28 Feb 2016 21:31:57 -0800

[Message part 1 (text/plain, inline)]

I want to make a release soon.
The preceding release (gzip-1.6) was 2.5 years ago.

Here's a small admin change I've just pushed.
I suspect I'm the only one who noticed, because it
is triggered only via "make distcheck" when also
using automake built from automake.git's master branch.

[0001-maint-dist-check.mk-remove-.deps-dirs-before-compari.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-grep <at> gnu.org, Rusty Russell <rusty <at> rustcorp.com.au>
Subject: Re: FYI: release soon
Date: Sun, 28 Feb 2016 21:39:40 -0800

[Message part 1 (text/plain, inline)]

On Sun, Feb 28, 2016 at 9:31 PM, Jim Meyering <jim <at> meyering.net> wrote:
> I want to make a release soon.
> The preceding release (gzip-1.6) was 2.5 years ago.
>
> Here's a small admin change I've just pushed.
> I suspect I'm the only one who noticed, because it
> is triggered only via "make distcheck" when also
> using automake built from automake.git's master branch.

Finally, here is a long-overdue upstream-ready --rsyncable
patch for gzip. I've Cc'd Rusty Russel, who is listed as the author.
I'll push this in the next day or so, so any improvements people
can suggest in the mean time would be most welcome.
Most of the changes came from some distro patches
(not sure if it was debian or fedora, since I began this
long ago). I added the test, a few comments and the
commit log.

[0001-gzip-support-the-rsyncable-option.patch (text/x-patch, attachment)]

Message #11 received at 22845 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>, 22845 <at> debbugs.gnu.org,
 rusty <at> rustcorp.com.au
Subject: Re: bug#22845: FYI: release soon
Date: Sun, 28 Feb 2016 22:54:08 -0800

Jim Meyering wrote:
> I'll push this in the next day or so, so any improvements people
> can suggest in the mean time would be most welcome.

Thanks for doing all that.

In NEWS, there should be one "New features" section, not two.

I had difficulty following the new documentation. Perhaps it's because of the 
word "synchronize" and the recently-added --synchronous option. Also, the phrase 
"cannot tell the difference" is confusing -- it's trying to talk about the 
output of gunzip, not about gunzip itself. And "reduces compression" is 
ambiguous, since compression already reduces. How about something like the 
following instead?

@item --rsyncable
Cater better to the @command{rsync} program.  Although does not compress
quite as well, it lets the @code{rsync} program take advantage of
similarities in the uncompressed input when synchronizing two files
compressed with this flag.

Message #14 received at 22845 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22845 <at> debbugs.gnu.org, Rusty Russell <rusty <at> rustcorp.com.au>
Subject: Re: bug#22845: FYI: release soon
Date: Mon, 29 Feb 2016 08:45:46 -0800

On Sun, Feb 28, 2016 at 10:54 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Jim Meyering wrote:
>>
>> I'll push this in the next day or so, so any improvements people
>> can suggest in the mean time would be most welcome.
>
>
> Thanks for doing all that.
>
> In NEWS, there should be one "New features" section, not two.

Good catch.

> I had difficulty following the new documentation. Perhaps it's because of
> the word "synchronize" and the recently-added --synchronous option. Also,
> the phrase "cannot tell the difference" is confusing -- it's trying to talk
> about the output of gunzip, not about gunzip itself. And "reduces
> compression" is ambiguous, since compression already reduces. How about
> something like the following instead?
>
> @item --rsyncable
> Cater better to the @command{rsync} program.  Although does not compress
> quite as well, it lets the @code{rsync} program take advantage of
> similarities in the uncompressed input when synchronizing two files
> compressed with this flag.

Thank you. I prefer that, too. Tweaked slightly:

@item --rsyncable
Cater better to the @command{rsync} program by periodically resetting
the internal structure of the compressed data stream.  This lets the
@code{rsync} program take advantage of similarities in the uncompressed
input when synchronizing two files compressed with this flag.  The cost:
the compressed output is slightly larger.

Will post a revised patch to the proper list.

Message #21 received at 22845 <at> debbugs.gnu.org (full text, mbox):

From: Rusty Russell <rusty <at> rustcorp.com.au>
To: Jim Meyering <jim <at> meyering.net>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22845 <at> debbugs.gnu.org
Subject: Re: bug#22845: FYI: release soon
Date: Tue, 08 Mar 2016 10:34:56 +1030

Jim Meyering <jim <at> meyering.net> writes:
> On Sun, Feb 28, 2016 at 10:54 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>> Jim Meyering wrote:
>>>
>>> I'll push this in the next day or so, so any improvements people
>>> can suggest in the mean time would be most welcome.
>>
>>
>> Thanks for doing all that.

Wow, thanks!  That made me do some digging for my old blog posts:

  <h2>Friday October 27 2000</h2>

  <p>Sent <a href="gzip.rsync.patch">rsyncable gzip patch</a> to the
  Debian gzip maintainer: he hasn't applied it yet AFAICT.  Turned out
  to be relatively trivial (I originally assumed that the size of the
  window for calculating when to reset the Huffman tables would be much
  larger than the internal 32k window; this is false, and a value of
  ~16k is fine).  Next step is to propose its use for .debs, then the
  world will be mine. Bwaahahaha!

Cheers!
Rusty.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.