On 2025-07-24 01:13, MATHEW THOMAS via GNU gzip discussion and bug
reports. wrote:
We are currently running gzip 1.9.7 on z/OS 3.1.
We plan to migrate to the z17 hardware and would like to know if there are any
required actions to take for this product, such as upgrading or applying any
fixes
Hello,
We are currently running gzip 1.9.7 on z/OS 3.1.
We plan to migrate to the z17 hardware and would like to know if there are any
required actions to take for this product, such as upgrading or applying any
fixes to tolerate the z17s.
Your assistance is greatly appreciated.
Thank
Thanks for reporting that. I installed the attached slightly-different
patch (different because it includes errno.h in same order as other files).From c76affb4551630ff661ac1c1ee99353a17eb16e1 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 30 May 2025 12:31:04 -0700
Subject: [PATCH] gzip
Thanks, I installed the attached additional patch.From b1de0e782a291c46e26777005893eeca142e0490 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 30 May 2025 12:23:42 -0700
Subject: [PATCH] gzip: fix another uninitialized read
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content
() is even invoked for that path.
This can be demonstrated with:
printf "\x50\x4B\x03" > trigger.dat
# Assuming gzip compiled with DYN_ALLOC and your patch c5e7899
valgrind --track-origins=yes ./gzip -tv trigger.dat
Best regards,
Mohamed Maatallah
On Fri, May 30, 2025 at 7:10 AM
Thanks for the bug report and proposed fix. I installed the attached,
which should fix the gzip bug in a different way.
I think the bug is innocuous in practice, but it's good to fix it anyway
as these things tend to mushroom.From c5e789971dfbc999cde5d1ce526a4422310617b8 Mon Sep 17 00:
Hi gzip maintainers,
An out-of-bounds / uninitialised read occurs in unzip.c:check_zipfile()
when the PKZIP local header is shorter than 30 bytes (CWE-457, CWE-125).
Reproduction (on 1.14, Linux x86-64, gcc 13.3):
printf '%s' \
504B0304 1400 000
Hello,
while rebasing the gzip in fedora I've encountered the build failure from
the $SUBJ.
A bit more info:
- happens only when configured with the --enable-dfltcc
- introduced by the [1] (the "errno" variable doesn't seem to be used
outside of the scope of the patch)
- buil
On 2025-04-15 03:14, Peter Dyballa wrote:
Yes, compiles fine, except for some warnings:
The warnings are false alarms; you can ignore them. Glad to hear that
gzip compiles now. Closing the bug report.
+ perl -e '
use POSIX qw(dup2);
$SIG{PIPE} = "DEFAULT"
On 2025-04-16 02:54, Peter Dyballa wrote:
Testing misses two files to exclude – new bug report?
I suppose so, yes - for Tar.
nsure that compressing these simple strings always produces the same bytes.
-# If using "od" is not portable enough, consider using this:
-# perl -ne 'printf "%02x ", ord($_) for split //'
for i in '' a b c yyy zzz; do
- echo $i: $(printf %s "$i&q
Hello everyone
We met a issue when run gzip-1.14 tests in yocto project
| od: invalid option -- 'A'
| BusyBox v1.37.0 () multi-call binary.
It's caused by line 46 in tests/reference.
yocto use od from busybox which only has limited option of od.
For such cases, the usual ap
> Am 15.Apr..2025 um 09:39 schrieb Paul Eggert :
>
> Please try gzip 1.14 instead, as it has fixes in at least some of the areas
> that gave you trouble.
Same problem with gnutar 1.35 (and same solution, + missing "-lintl"). Testing
misses two files to ex
> Am 15.Apr..2025 um 09:39 schrieb Paul Eggert :
>
> Please try gzip 1.14 instead, as it has fixes in at least some of the areas
> that gave you trouble.
Yes, compiles fine, except for some warnings:
/opt/local/bin/gcc-apple-4.2 -std=gnu99 -DHAVE_CONFIG_H -I.
-I/opt/local/in
Please try gzip 1.14 instead, as it has fixes in at least some of the
areas that gave you trouble.
Hello!
I am building the software out of a MacPorts installation on an Apple PowerBook
G4 with Mac OS X 10.4.11, Tiger:
Executing: cd
"/opt/local/var/macports/build/nue.de.rsync.macports.org_macports_release_tarballs_ports_archivers_gzip/gzip/work/gzip-1.13"
&& ./confi
less it has something to do with a change to line 11 above.
I'm still unclear about why gzip would need (or want) to be able to
write into a no-write-access directory in the failing test.
Explanation?
The test is making sure that gzip outputs a reasonable diagnosic when
asked to write into
I have now got successful builds and validations of gzip-1.13.56-e549
on 56 systems in our test farm at Utah.
I have test failures on 17 systems, but in only 3 specific tests:
pipe-output:FreeBSD 13.5, 14.2, 15.0; GhostBSD 24.01; NetBSD 10.0;
OpenBSD 7.3, 7.4, 7.5, 7.6, 7.7
On Mon, Apr 7, 2025 at 4:39 PM Nelson H. F. Beebe wrote:
> I have now got successful builds and validations of gzip-1.13.56-e549
> on 56 systems in our test farm at Utah.
>
> I have test failures on 17 systems, but in only 3 specific tests:
>
> pipe-output:FreeBSD 13.5, 14
port certainly seems like a red herring; one would
have expected "Directory not writable" or "File cannot be created."
Indeed, if you get the same result with O_RDONLY instead of O_SEARCH
it's a clear bug, one that gzip cannot work around reliably as far as I
can see.
On 2025-04-09 05:47, Nelson H. F. Beebe wrote:
I ran these tests in the gzip-1.13.56-e549 build directory
on DragonFlyBSD 6.4.0:
mkdir d
echo >d/f
chmod a-w d
env LC_ALL=C truss -o gzip.truss ./gzip d/f
That last command produces this output;
gzip
On 2025-04-08 11:43, Nelson H. F. Beebe wrote:
Here is the requested test on DragonFlyBSD for gzip-1.13.56-e549:
% cat foo.sh
#! /bin/sh
mkdir d
echo >d/f
chmod a-w d
./gzip d/f
% ./foo.sh
gzip: d/f.gz already exists; do you wish to overwrite (y or n)? y
gzip: d/f.gz: No such file or direct
This is to announce gzip-1.14, a stable release.
Most notable: "gzip -d" is up to 40% faster on x86_64 CPUs with pclmul
support. Why? Because about half of its time was spent computing a CRC
checksum, and that code is far more efficient now. Even on 10-year-old
CPUs lacking pclmul sup
On 4/8/25 14:16, Nelson H. F. Beebe wrote:
Thanks for this analysis of the gzip-1.13.56-e549 test failures on
DragonFlyBSD 6.4.0:
If you can concoct a small C program that is likely to be runnable
across a range of systems, then I'll be happy to configurize it, and
then do tests builds o
On 2025-04-08 11:25, Nelson H. F. Beebe wrote:
Here is the output on NetBSD 10.0 for the test script for zdiff
behavior:
Thanks. I'm quoting it below. Apparently the equivalent of the following
crashed:
echo b >b
gzip b
gzip_status=$(gzip -cdfq -- b.gz)
whereas the same thing succ
On 2025-04-08 06:07, Nelson H. F. Beebe wrote:
+ mkdir d
+ echo
+ chmod a-w d
+ test -w d
+ id -u
+ test 887 '=' 0
+ returns_ 1 gzip d/f
+ fail=1
To help debug this problem on DragonFlyBSD 6.4.0, please run the
following commands in the gzip source directory and tell us what the
.
On 2025-04-08 06:12, Nelson H. F. Beebe wrote:
+ returns_ 1 zdiff a.gz b.gz >out 2>err
+ fail=1
To help debug that, could you please run the following commands in the
gzip source directory and tell us the output?
echo a>a
echo b>b
./gzip a b
/bin/bash -x ./zdiff a.gz b.gz
I
Yesterday, I reported that the zdiff test for gzip-1.13.56-e549
failed on NetBSD 10.0. Here is the tests/zdiff.log file:
+ initial_cwd_=/local/build/cc/gzip-1.13.56-e549/tests
+ testdir_prefix_
+ printf gt
+ pfx_=gt
+ mktempd_ /local/build/cc/gzip-1.13.56-e549/tests gt-zdiff.
+ destdir_
Yesterday, I reported this failure for gzip-1.13.56-e549 on
DragonFlyBSD 6.4.0: write-error.
Here is the tests/write-error.log file:
+ initial_cwd_=/local/build/cc/gzip-1.13.56-e549/tests
+ testdir_prefix_
+ printf gt
+ pfx_=gt
+ mktempd_ /local/build/cc/gzip-1.13.56-e549/tests gt-write
Jim Meyering wrote:
> I haven't seen any report of those yet, so details would be helpful.
Regarding the 'pipe-output' failures, you find the details already
reported in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70861 .
Bruno
Debian 13 trixie buildd:
https://buildd.debian.org/status/package.php?p=gzip&suite=experimental
looks good except on hurd where 'more' is not available at all:
/build/reproducible-path/gzip-1.13.56~e549/tests/../zmore: line 53: more:
command not found
FAIL: zmore
FAIL help
On Apr 6, 2025, at 10:43 PM, Nicolas Boos via GNU gzip discussion and bug
reports. wrote:
> Will a binary built with an i686 toolchain and a CPU supporting pclmul will
> work from a system without this instruction?
Yes. There is an instruction to check for that instruction. It also chec
Le Sat, 05 Apr 2025 14:07:01 -0700
Jim Meyering écrivait :
> ** Performance improvements
>
> gzip now decompresses significantly faster by computing CRCs via a
> slice by 8 algorithm, and faster yet on x86-64 platforms that
> support pclmul instructions.
Will a binar
On Sun, Apr 6, 2025 at 1:14 PM Bruno Haible wrote:
> Jim Meyering wrote:
> > I'll soon push the attached:
>
> > +if MORE
> > +ZMORE_PROG = zless
>
> Shouldn't that be
>
> +if MORE
> +ZMORE_PROG = zmore
Yes, indeed. Thanks. Adjusted.
Jim Meyering wrote:
> I'll soon push the attached:
> +if MORE
> +ZMORE_PROG = zless
Shouldn't that be
+if MORE
+ZMORE_PROG = zmore
?
On Sun, Apr 6, 2025 at 1:27 AM Bruno Haible via GNU gzip discussion
and bug reports. wrote:
> Testing on GNU Hurd x86_64 from 2025:
> There is 1 test failure:
> FAIL: help-version
>
> Details:
>
> /home/bruno/gzip-1.13.56-e549/build/tests/../zmore: line 53: more: command
All tests pass (except possibly year-2038) on:
* Linux
- Ubuntu 24.04 (64-bit, 32-bit)
- CentOS 6, 7, 8-Stream, AlmaLinux 9
- Slackware 15 (32-bit)
- s390x: openSUSE 15.5
- hppa: Debian 12
- m68k: Debian 12
* Haiku
* Android (Termux)
Bruno
On
- OpenBSD 7.6,
- Solaris 11 OpenIndiana,
- AIX 7.1 32-bit
there is 1 test failure:
FAIL: pipe-output
Find attached the respective log files.
=
gzip 1.13.56-e549: tests/test-suite.log
=
# TOTAL
On Cygwin 3.4.6 I see one ERROR in the tests:
ERROR: zgrep-abuse
Find attached the tests/test-suite.log.
=
gzip 1.13.56-e549: tests/test-suite.log
=
# TOTAL: 30
# PASS: 28
# SKIP: 1
# XFAIL: 0
# FAIL
Testing on GNU Hurd x86_64 from 2025:
There is 1 test failure:
FAIL: help-version
Details:
/home/bruno/gzip-1.13.56-e549/build/tests/../zmore: line 53: more: command not
found
+ echo FAIL: zmore
FAIL: zmore
+ fail=1
Find attached the complete tests/test-suite.log.
On this machine, 'mor
I want to release gzip-1.14 by Tuesday or Wednesday, so here's a
snapshot of the latest. It's been more than 1.5 years since gzip-1.13,
but with a surprising performance improvement as well as some bug fixes.
Any tests (success/failure) you can tell us about would be most welcome.
T
On 2025-02-23 Antonio Diaz Diaz wrote:
> Have you considered that removing GZIP, as Paul did originally, would
> maximize reliability, minimize maintenance work,
I considered both pros and cons, including those pros you mentioned.
The cons are backward compatibility concerns and remova
Lasse Collin wrote:
Hypothetically, someone somewhere might rely on GZIP=-n when
compressing regular files.
Have you considered that removing GZIP, as Paul did originally, would
maximize reliability, minimize maintenance work, prevent long discussions
about what options GZIP should or should
On 2025-02-19 Paul Eggert wrote:
> So I installed the attached patch instead into Savannah master gzip.
> It means gzip will pay attention to -1..-9, --rsyncable, and
> --synchronous
This sounds reasonable. It unambiguously prevents glitches in scripts.
For example, GZIP=-v may seem inn
On 2025-02-12 05:58, Lasse Collin wrote:
the removal makes gzip one
of the few compression tools that don't support setting even the
compression level via an environment variable.
Thanks for the review. On further thought I agree that, for backward
compatibility reasons at least, the
Hi,
This is on top of the previous patch I presume? It doesn't have the
__builtin_unreachable() line the previous patch added, but I might
have missed an update.
On Mon, Feb 17, 2025 at 7:44 AM Eduard Stefes wrote:
>
> due to hardware limitations we cannot rely on the OESC error code
> before th
due to hardware limitations we cannot rely on the OESC error code
before the hardware parsed the initial huffman tree. For this case
we have to add a branch to the EOF handling. we return an errorcode 2
(invalid data) if we where still in the initial phase (bytes_out == 0).
Otherwise we continue wi
On 2025-02-10 Paul Eggert wrote:
> The GZIP environment variable is too hazardous.
I looked at old mailing list threads to understand why the GZIP
environment variable was deprecated in the first place. The discussion
about deprecating the GZIP environment variable was a decade ago, s
On 2023-11-09 10:32, Paul Eggert wrote:
On 2023-11-09 09:40, Young Mo Kang wrote:
Since both GNU Gzip and zlib are written by the same authors, I was
wondering if GNU Gzip can share zlib's CRC32 calculation and obtain
this performance gain--I am not sure if there would be a license
The GZIP environment variable is too hazardous.
* gzip.c (env, ENV_OPTION):
* tailor.h (OPTIONS_VAR):
* util.c (SEPARATOR, add_envopt):
Remove. All uses removed.
* gzip.c (main): Ignore GZIP.
* tests/gzip-env: Test that GZIP is ignored.
---
NEWS | 6
doc/gzip.texi | 11
Thanks, I installed that test. Marking this gzip bug as done.
On 2025-01-08 Lasse Collin wrote:
> On 2025-01-08 Paul Eggert wrote:
> > On 2025-01-07 10:22, Lasse Collin wrote:
> > > It could be useful to add a test for gzip --synchronous.
> >
> > Feel free
>
> Attached. It's based on z-suffix.
Syncing is
2013 by using
> > /proc/self/fd.[1]
>
> Is that a full fix, though? /proc might not be mounted.
No, it requires /proc, but it works most of the time...
> > It could be useful to add a test for gzip --synchronous.
>
> Feel free
Attached. It's based on z-suffix.
r kernel or libc that has O_PATH?
Anything else with O_SEARCH == O_PATH is likely to have similar
problems. If not, we can cross that bridge when we come to it.
It could be useful to add a test for gzip --synchronous.
Feel free
on't
accidentally apply on some other kernel or libc that has O_PATH? Or
perhaps it's safe to assume that nothing else has O_SEARCH == O_PATH.
For example, FreeBSD has O_PATH but, as expected, it doesn't equal
O_SEARCH.
It could be useful to add a test for gzip --synchronous. "make check"
passed without the Gnulib patch too.
--
Lasse Collin
On 2025-01-06 05:29, Lasse Collin wrote:
In musl, O_SEARCH maps to Linux-specific O_PATH
That is a bug in musl. musl should not define O_SEARCH to O_PATH on
Linux, because O_PATH is not a valid implementation of O_SEARCH. Or if
musl wants to do some sort of approximate-but-invalid implementa
On Linux/musl:
$ echo foo > foo
$ gzip --synchronous foo
gzip: foo.gz: Bad file descriptor
From gzip.c:
dfd = open (dfname, O_SEARCH | O_DIRECTORY);
...
if ((synchronous
&& ((0 <= dfd && fdatasync (dfd) !
Hi Jim,
Jim Meyering writes:
> Thanks for the patch and the message.
> I have just pushed your patch.
>
> I was somewhat surprised to find that I have no trace of your original,
> though I did find a very similarly-titled message about tar.
Thanks! Interesting, perhaps I sent it at some unlucky
On Tue, Sep 10, 2024 at 3:45 AM Collin Funk wrote:
> Hi Jim,
>
> Thanks for the recent gzip patches.
>
> Could you check and apply one I've sent previously [1]?
>
> It fixes some library names used by Gnulib. They should only be needed
> on ancient systems I t
; that. Async safety is about something else (admittedly brain-hurting
> :-).
Thanks, I found the original thread prompting the addition of
volatile_strcpy and think I understand now [1].
Apologies for the extra noise. :)
Collin
[1] https://lists.gnu.org/archive/html/bug-gzip/2018-08/msg00013.html
On 2024-08-13 09:20, Jim Meyering wrote:
While somewhat related, I don't see how an async-safe strcpy would let
us remove that function.
Agreed. You can't even use strcpy on 'char volatile *'; C prohibits
that. Async safety is about something else (admittedly brain-hurting :-).
On Sun, Aug 4, 2024 at 5:10 PM Collin Funk wrote:
> Also, now that POSIX-1.2024 requires strcpy to be async-signal-safe can
> 'volatile_strcpy' be removed? Or is there something more to
> that. Signals hurt my brain a bit, sorry...
While somewhat related, I don't see how an async-safe strcpy woul
Thanks! Applied
Since gzip uses 'printf-posix' can't offsets be printed using that
instead of fprint_off? Patch attached + 1 more removing #ifndef CHAR_BIT
cruft.
Also, now that POSIX-1.2024 requires strcpy to be async-signal-safe can
'volatile_strcpy' be removed? Or is there something m
Hello,
I am attempting to compile gzip but receive a failure about a header
file recently added to C23:
# make gzip
CC bits.o
CC deflate.o
CC gzip.o
In file included from gzip.c:77:
./lib/stat-time.h:30:10: fatal error: 'stdckdint.h' file
On 2024-04-16 11:10, Mark Diaz wrote:
Sorry if this is a known issue or has already been corrected
Your bug report is about gzip 1.3.12 (2007-04-13). Unfortunately gzip's
support for VMS was removed in gzip 1.9 (2018-01-07) and (as you're
noticing) it wasn't really working e
Sorry if this is a known issue or has already been corrected
No need for a response.
VMS/VAX 7.2 GZIP 1.3.12e
Compresses FILE.DAT;1 and FILE.DAT;2 is deleted.
$ DIRECTORY FILE.DAT*
FILE.DAT;2
FILE.DAT;1
$ GZIP FILE.DAT;1
$ DIRECTORY FILE.DAT*
FILE.DAT;1
FILE.DAT-GZ;1
There are VMS
current Sarwate
algorithm, or tiny bit faster ( paste.ee paste.ee/p/QeBKL ).Benefits are
not that unambiguous. Though I didn't make that slicing-by-8 ( paste.ee
paste.ee/d/mkqTU/0 ) work with gzip properly, I would consider it in a context
of application itself. If braids ar
> The initial value returned by crc32(0L, Z_NULL, 0) is 0, not -1. And there
is no post inversion That was it, thanks.
> The paper on braided CRCs is in the zlib distribution: doc/crc-doc.1.0.pdf
Thanks for a tip, I read that and now it's bit clearer to me.Maybe it
is slightly faster, but I wouldn't bet dollars against nuts it's exact
in my case as 7zip-crc also uses slice-by-8 algorithm and is actually fa
> Mr. Wrotycz, Mr Adler, let's spare the formalities. That's a
nickname. > > On Mar 13, 2024, at 6:14 PM, wrotycz < wrotycz@#$%...
I know it's a mail list but I would appreciate to not broadcast my email
to every (spam)bot on the web. Archive is publicly available and easily
searchable by
Re: bug#67022: Gzip decompression can be 60% faster using zlib's CRC32I
tried to make that CRC-slice-by-8 happen but, as I miss something, maybe you
will get that right. My guess the problem lies in all those negations of crc
(`(return) crc = crc ^ 0x;'). I prepared
On Mar 14, 2024, at 3:46 PM, wrotycz wrote:
>
>
> Despite that the question is how do I use zlib crc32()? It doesn't give me
> correct result.
>
> My 'rig' is this:
>
> ~~~
> crc = -1
> while (buffer, length = read_data()):
> {
> crc = crcfunc(crc, buffer, length)
> }
> crc = ~crc
> And, again, due to level of complexity in the code, I didn't check it. I have
> this quirk that I want to understand stuff I use, here I couldn't so I didn't
> follow.
>
> I will check that braids thing when I find something about it.
The paper on braided CRCs is in the zlib distribution: do
Mr. Wrotycz,
I’m not sure what you mean by “bloated”, but anyway, the current code in zlib
for CRC-32 does not use slice-by-8. It uses braids, which is faster. If there
were going to be a replacement for the software CRC in gzip, it should start
there.
It could also finish there, simply by
I tried to implement this slice-by-8 CRC but couldn't do it the way I
wanted - without bloated zlib tables and stuff. Maybe because I don't get
what updcrc(), getcrc(), setcrc() are and what they actually do. The whole
program is magical, there is no way to find do_de/compress(), nor anything li
Hi!
Sorry...
Can you explain why gzip --rsyncable doesn't get rsync speedup?..
I have Proxmox hosts. And I have backups of my VMs like *.gz made with gzip
--rsyncable. And I expect some speedup when i rsync my backups to another
host. But I haven't any speedup...If i try to copy who
On 2023-11-09 09:40, Young Mo Kang wrote:
Since both GNU Gzip and zlib are written by the same authors, I was
wondering if GNU Gzip can share zlib's CRC32 calculation and obtain this
performance gain--I am not sure if there would be a license issue though.
Shouldn't be a license i
ng CRC32 computation. On an AMD 7735HS system, I get
GNU Gzip unmodified
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:05.11
GNU Gzip with CRC32 from zlib
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.16
And I saw even better performance improvement when tested on an Apple
Silicon M1 syste
d stdalign. gzip needs this module because
gzip.c and (as you noticed) dlftcc.c use alignas. We didn't notice the
bug until now because gzip.c falls back on working code if alignas is
absent, and we don't test on s390x.
I fixed the bug by installing the attached, which should appe
Hi,
we are using gzip 1.13 for builds on openSUSE Tumbleweed.
It is failing for the hardware architecture s390x with the following error
message:
[ 246s] gcc -DHAVE_CONFIG_H -I. -I./lib -I./lib-O2 -Wall
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables
Hello,
I'm trying to run gzip on a set of inputs and I want to time the compression
and decompression so I can calculate the throughputs. I want the comparison to
other compressors that I'm timing to be fair, so I need to time only the
compressor and decompressor functions and not
This is to announce gzip-1.13, a stable release.
Thanks to Paul and Bruno for contributing.
There have been 50 commits by 3 people in the 71 weeks since 1.12.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
The following people contributed changes to this release
On 2023-06-17 08:25, Jim Meyering wrote:
Thanks. However, I noticed that this change makes it so our
semi-automated copyright year updates would fail to change this usage:
that script doesn't account for the use of "\en" in place of "-". It's
an already too-complex script, and I am loath to comp
On Sat, Jun 17, 2023 at 2:49 AM Paul Eggert wrote:
> Thanks, I installed the attached, which isn't the same as what you sent
> but I hope it addresses the same editorial issues.
Thanks. However, I noticed that this change makes it so our
semi-automated copyright year updates would fail to change
page
From suggestions by Bjarni Ingli Gislason (bug#64118).
---
gzip.1 | 276 -
1 file changed, 155 insertions(+), 121 deletions(-)
diff --git a/gzip.1 b/gzip.1
index 22ab88d..657ad0d 100644
--- a/gzip.1
+++ b/gzip.1
@@ -35,8 +35,8 @@
Output from "mandoc -T lint gzip.1:"
mandoc: gzip.1:347:173: STYLE: input text line longer than 80 bytes: When you
synchronize...
mandoc: gzip.1:348:277: STYLE: input text line longer than 80 bytes: Normally,
after a ch...
mandoc: gzip.1:349:176: STYLE: input text line longer tha
On Thu, Apr 6, 2023 at 9:53 PM Petr Pisar wrote:
>
> V Thu, Apr 06, 2023 at 09:25:50AM +, Mary-Anne Freckleton via GNU gzip
> discussion and bug reports. napsal(a):
> > I am trying to gzip some files; however, I keep getting the error message
>
> The message is:
>
&
V Thu, Apr 06, 2023 at 09:25:50AM +, Mary-Anne Freckleton via GNU gzip
discussion and bug reports. napsal(a):
> I am trying to gzip some files; however, I keep getting the error message
The message is:
$ gzip FILE_NAME
gzip: FILE_NAME.gz: Operation not permitted
The cause it that you do
On Thu, Jan 5, 2023 at 8:42 PM Sam James wrote:
> > On 28 Dec 2022, at 17:28, Jim Meyering wrote:
> >
> > I think we're about ready for a new gzip release, so here's the latest.
> > Please take it for a spin and let us know of success and failure.
> >
> On 28 Dec 2022, at 17:28, Jim Meyering wrote:
>
> I think we're about ready for a new gzip release, so here's the latest.
> Please take it for a spin and let us know of success and failure.
> Thanks to Paul Eggert for all the recent improvements.
Tested OK on amd6
resolved
I think we're about ready for a new gzip release, so here's the latest.
Please take it for a spin and let us know of success and failure.
Thanks to Paul Eggert for all the recent improvements.
gzip snapshot:
https://meyering.net/gzip/gzip-ss.tar.xz 788 KB
https://meyering.net
* bootstrap.conf (gnulib_modules): Use strerror, not perror.
This removes dependencies on Gnulib’s ‘threadlib’ and ‘lock’ modules,
and simplifies the mainline code. Apparently the old code was written
before strerror was universally supported; nowadays we can use Gnulib
strerror instead. All uses
In 2017 I wrote:
> Regarding OpenBSD, I've just reported this to the OpenBSD people:
> https://marc.info/?l=openbsd-bugs&r=1&b=201711&w=2
They discussed the issue, but AFAICS with no consequences:
https://marc.info/?t=15105079751&r=1&w=2
Bruno
On 8/10/18 14:02, Paul Eggert wrote:
What platform and gzip version are you using, and how was gzip built
and installed? Can you reproduce the problem? Better yet, can you show
us how to reproduce the problem?
No further comment in four years, so I'm closing this old bug report.
No further comment on this old bug report, so I'm taking the liberty of
closing it.
On 11/12/17 00:25, Paul Eggert wrote:
I installed the attached patch to tests/timestamp
As this appears to have fixed the bug, I'm closing this old bug report.
* gzip.c (BUFFER_ALIGNED): Do not depend on __alignas_is_defined
as that has been removed from C23.
---
NEWS | 2 +-
gzip.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 918fcf2..f2ea30e 100644
--- a/NEWS
+++ b/NEWS
@@ -9,7 +9,7 @@ GNU gzip NEWS
index 0c4a6aa..23b65f9 100644
--- a/bits.c
+++ b/bits.c
@@ -76,7 +76,7 @@
* Local data used by the "bit string" routines.
*/
-local file_t zfile; /* output gzip file */
+static file_t zfile; /* output gzip file */
#ifndef IBM_Z_DFLTCC
static
diff --git a/deflate.c b/deflate.c
ind
1 - 100 of 854 matches
Mail list logo
