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 y
Nick,
I think what you mean is when you try the zip and then try to decompress it
with gzip you get that. You can’t get that from zip.
As it happens, earlier today I sent Paul patches for gzip to handle Zip64.
Yes, Info-ZIP’s zip really likes to insert Zip64 fields when it doesn’t need to.
The
Speaking of zip able to create streamed archive, I may be doing something wrong
with zip syntax but when I do try this: ``$ cat fin | zip -FI - -
> fout''. I get `Zip64 entry -- not supported, use
unzip'. Which doesn't happen when `/dev/stdin' is used,
although this i
-*- outline -*-
** Bug fixes
gzip -d no longer rejects PKZIP signatures, local header, and data
- descriptors. These can appear in well-formed albeit unusual pigz output.
+ descriptors. These can appear in well-formed streamed zip files.
[bug present since the beginning]
A use of uninitial
me for a
> while.
>
> For the record I'm attaching the patches involved, and I'm closing the bug
> report.
>
> oset: if you would like your name and email address in the THANKS file,
> please let me know your name or nom de plume.
while.
For the record I'm attaching the patches involved, and I'm closing the
bug report.
oset: if you would like your name and email address in the THANKS file,
please let me know your name or nom de plume.From c651ce70ae78af23343b5140c9700aa8de42808a Mon Sep 17 00:00:00 2001
Paul,
I see the problem. I’ll fix it.
Mark
> On Jun 15, 2025, at 10:03 AM, Paul Eggert wrote:
>
> On 2025-06-15 09:46, Adler, Mark wrote:
>> It was not clear, but this is a gzip report, not a pigz report.
>
> Ah, thanks for letting me know. I reopened the gzip bug repor
On 2025-06-15 09:46, Adler, Mark wrote:
It was not clear, but this is a gzip report, not a pigz report.
Ah, thanks for letting me know. I reopened the gzip bug report.
Maybe someday somebody can get around to looking into the issue on the
gzip side.
Paul,
> On Jun 15, 2025, at 9:37 AM, Paul Eggert wrote:
>
> On 2025-06-15 08:25, Adler, Mark wrote:
>> The problem is with the “other un/zippers” which per the linked report on
>> sourceforge is actually just 7-Zip.
>
> Thanks for diagnosing; closing the gzip bu
y is doing the deeming. All I had to
go on was the link to the 7-Zip issue. So I asked if this was intended as a
report of a pigz bug.
Problem is, potentially, in gzip, which does not recognise fringe, rarely used,
format.
Now I see that you meant to say that it is deemed to be corrupted by gzip.
On 2025-06-15 08:25, Adler, Mark wrote:
The problem is with the “other un/zippers” which per the linked report on
sourceforge is actually just 7-Zip.
Thanks for diagnosing; closing the gzip bug report.
So this is an alleged pigz bug being reported? Then why is it being reported on
this gzip bug list? It should be reported instead at
https://github.com/madler/pigz/issues .
Though don’t bother, because this is not a bug in pigz. The problem is with the
“other un/zippers” which per the linked
Zip created by pigz[1] is deemed to be corrupted even though it is considered
valid by unzip et alli [2]. I do not claim pigz's zip is correct but
other un/zippers think so. Apparently it is mentioned in paragraph 4.3.9.3 of
ZIP File Format Specification [3][4]. 4.3.9.3 Although not original
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: f
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-
Paul Eggert wrote:
> 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.
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 \
010
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)
- build completes when the
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.
Thanks for reporting that glitch with busybox. I installed the attached
to work around it.From e77940b44f8804ca7b59606af2f9318d5bc954e2 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 27 Apr 2025 13:28:20 -0700
Subject: [PATCH] tests: port to Busybox od
Problem reported by Xinjian Ma (Bug
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 approach taken by addin
> 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
Ups, sent this to the wrong mailing list... Sorry!
Please ignore and close.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-
Hello everybody,
I am building grep 3.12 in a clean build environment for Arch Linux. That
fails when building with link time optimization is enabled:
CCLD grep
In function 'dfaoptimize',
inlined from 'dfaanalyze' at ../lib/dfa.c:2873:3:
../lib/dfa.c:2606:12: error: writing 1 byte into
on this
host'
+ sed 1q
+ Exit 99
+ set +e
+ exit 99
+ exit 99
+ remove_tmp_
+ __st=99
+ cleanup_
+ :
+ test '' = yes
+ cd
/opt/local/var/macports/build/nue.de.rsync.macports.org_macports_release_tarballs_ports_archivers_gzip/gzip/work/gzip-1.14/tests
+ chmod -R u+rwx
/opt/local/var/m
Dear gzip maintainers,
just found out this is related to link time optimization. If I disable LTO it
builds as-is (git master and 1.14), as soon as I enable LTO my patches is
required for a successful build. Thanks!
--
Best regards,
Chris
pgpYU47i1wJJ1.pgp
Description: OpenPGP digital signature
Please try gzip 1.14 instead, as it has fixes in at least some of the
areas that gave you trouble.
... as the compiler complains:
gzip.c: In function 'main':
gzip.c:465:24: error: 'env_argc' may be used uninitialized
[-Werror=maybe-uninitialized]
465 | optc = getopt_long (env_argc, env_argv, shortopts,
longopts,
|^
gzip.c:413:9: note: 'env_argc'
# endif
116 return 0;
117 # elif defined __QNX__ /* QNX */
118 fp->_Rback = fp->_Back + sizeof (fp->_Back);
119 fp->_Rsave = NULL;
120 if (fp->_Mode & 0x2000 /* _MWRITE */)
121 /* fp->_Buf <= fp->_Next <= fp->_Wend
On 2025-04-11 09:14, Paul Eggert wrote:
Why is this needed? What happens if you omit "#include ".
Sure no problem. Without this patch, on (our) s390x build (only):
[ 443s] gcc -DHAVE_CONFIG_H -I. -I./lib -I./lib -O2 -Wall
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong
-
On 2025-04-10 15:13, Nelson H. F. Beebe wrote:
I made this change against the original test file:
% diff dfly-openat-bug.c dfly-openat-bug-3.c
8c8
< int dirfd = open ("d/", O_SEARCH | O_DIRECTORY);
---
> int dirfd = open ("d/&quo
On 2025-04-10 22:27, Andreas Stieger via GNU gzip discussion and bug
reports. wrote:
Found building for s390x on openSUSE
---
dfltcc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dfltcc.c b/dfltcc.c
index 9f86581..7333757 100644
--- a/dfltcc.c
+++ b/dfltcc.c
@@ -18,6 +18,7 @@
#include
Found building for s390x on openSUSE
---
dfltcc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dfltcc.c b/dfltcc.c
index 9f86581..7333757 100644
--- a/dfltcc.c
+++ b/dfltcc.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#ifdef HAVE_SYS_SDT_H
# include
--
2.49.0
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 (p
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.2, 15.0; GhostBSD 24
Y>
says it has neither O_SEARCH nor O_PATH.
In that case please use O_RDONLY instead of O_SEARCH.
I made that change and ran the test:
% gcc dfly-openat-bug-2.c && ./a.out
d/f: File exists
% ls -Rl d
d:
total 0
The "File exists" re
GXCPU,0x7fdfcd80,0x0)= 0 (0x0)
sigaction(SIGXFSZ,0x7fdfcd80,0x0)= 0 (0x0)
sigprocmask(0x1,0x42a0e0,0x7fdfcdc0) = 0 (0x0)
openat(0x4,0x49f822,0xa01,0x180) ERR#17 'File exists'
Thanks for the info. This seems to be a
ack-valid
PASS: upper-suffix
[hangs at this point]
If I run the script in the tests directory, I get
% ./write-error
./write-error: cannot create d/e: Permission denied
[again at this point]
Thanks for the further checking on DragonFlyBSD. My guess about the
syscall bug was incorrect, unfortuna
ib 2025-01-31 553ab924d2b68d930fae5d3c6396502a57852d23
NEWS
* Noteworthy changes in release 1.14 (2025-04-09) [stable]
** Bug fixes
'gzip -d' no longer omits the last partial output buffer when the
input ends unexpectedly on an IBM Z platform.
[bug introduced in gzip-1.11]
n our test farm.
Since I'm guessing about the bug, it'd likely be more efficient to see
what system calls the failing gzip is executing, before writing a small
C program. Please run this:
mkdir d
echo >d/f
chmod a-w d
LC_ALL=C truss -o gzip.truss ./gzip d/f
and then l
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 succeeded if o
fear that it will result in very very cumbersome
error handling code.
OK, thanks for the analysis. Closing the bug report.
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
./gzip does:
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 am assuming "zdi
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_=/loca
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-error.XXX
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-version (exit status
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 binary built with an i686
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: 30
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: 0
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, 'more' is no
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
l of a useful
feature (when used responsibly). I guess those cons don't matter to you,
but maintainers tend to consider such things especially when it's a
widely-used package.
For example, here is a Debian bug from 2020 about the GZIP deprecation
warning appearing in dgit:
https://bugs-
Thanks for the bug report. This appears to be the same as the following
issue reported by Sarah-Julia Kriesch, and you can see a fix there:
https://bugs.gnu.org/66709
For now, I'll merge the two bug reports.
_param af;
./dfltcc.c: char alignas (8) aligned;
./dfltcc.c-};
--
./dfltcc.c- struct dfltcc_param_v0 param;
./dfltcc.c: char alignas (8) aligned;
./dfltcc.c-};
1. https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/2100598/comments/2
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 innocent but i
Hi,
On Mon, 2025-02-17 at 10:38 +, Eduard Stefes wrote:
>
> ...
> This makes hufts pass and does not affect any other test case. I will
> do more exhaustive tests just to be sure that nothing else is
> affected.
> ...
So, I did some tests. I setup afl++ with a static seed and went through
so
ons(-)
diff --git a/NEWS b/NEWS
index e348355..9341ef8 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,15 @@ GNU gzip NEWS-*- outline -*-
'gzip -S' now rejects suffixes containing '/'.
[bug present since the beginning]
+** Changes in behavior
+
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-17 02:38, Eduard Stefes wrote:
I came up with an ugly hack:
Thanks, it sounds much nicer than the hack I was thinking of, which was
to redo the entire run in software
JMFz
> 4qEFFyhpCJvbRLyu9&s=VxHLexQ8YkPuK0dODBtBIOdJSZNN3UOOaFzlPLnFd7s&e= >,
> superseding the
> incorrect patch I installed a couple of days ago. However, I'm
> worried
> about the patch to test/hufts that you also suggested, as it would
> mean
> gzip's dia
d and then removed
completely. Trouble-free uses of GREP_OPTIONS were fairly limited
(perhaps --color=auto might have been such), so removing it seemed
reasonable. Specifically, it was unacceptable that many scripts would
need to unset GREP_OPTIONS.
In gzip, bug#20104 [2] refers to troubles caus
[Resending because my earlier email had the wrong bug number.]
Due to work by Sam Russell and others it looks like gzip now has faster
CRC32 code on Savannah master, so closing this old bug report. See:
https://bugs.gnu.org/74927
https://bugs.gnu.org/74192--- Begin Message ---
Due to work by
issue
though.
Shouldn't be a license issue. It's just a lack of time issue.
Due to work by Sam Russell and others it looks like gzip now has faster
CRC32 code on Savannah master, so closing this old bug report. See:
https://bugs.gnu.org/74927
https://bugs.gnu.org/74192
On 2024-09-02 12:13, Collin Funk wrote:
Following Simon's patch in Gnulib, replacing the old FSF postal address
with a link [1].
Thanks, I see Jim installed something similar into gzip soon after you
sent this email, so I'm closing the bug report.
On 2024-08-23 you wrote:
root@INF-DESKTOP:/tmp# GZIP=-1 tar cfz saved.config.tar.gz saved.config
gzip: warning: GZIP environment variable is deprecated; use an alias or script
Yes, that's the intended and documented behavior. The GZIP environment
variable can make it hard to write portable sc
variable, which was marked as obsolescent in
+ gzip 1.7 (2016) due to its hazards, has been removed. You can use
+ an alias or script instead.
+
** Bug fixes
'gzip -d' no longer omits the last partial output buffer when the
diff --git a/doc/gzip.texi b/doc/gzip.texi
index cc05b60..1bfc
Thanks, I installed the attached somewhat-fancier patches which should
do the same thing; please see what you think. Boldly closing bug#74927.From 6b65e654a74998705da3aed81d1bbb57f50847eb Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 10 Feb 2025 22:31:36 -0800
Subject: [PATCH 1/2] gzip
Marking this bug report as done because Jim updated gzip to the latest
Gnulib on December 13, after this patch was submitted.
intain that behavior as
it is valuable information to give to the user.
I installed the patch to dfltcc.c that you suggested in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75924#5>, superseding the
incorrect patch I installed a couple of days ago. However, I'm worried
about the patch to te
On Wed, 2025-01-29 at 19:50 +, Eduard Stefes via GNU gzip
discussion and bug reports. wrote:
> Hi,
>
> On Wed, 2025-01-29 at 10:58 -0800, Paul Eggert wrote:
> > Thanks for the bug report. I installed the attached, a bit simpler
> > than
> > the patch you suggeste
Jim Meyering writes:
> However, the goal of that change was to move away from deprecated modules,
> so from realloc-gnu to realloc-posix. This is what I'll push shortly:
Ah, right. I forgot about the change from realloc-gnu to realloc-posix.
Thanks!
Collin
On Sun, Feb 2, 2025 at 7:54 PM Collin Funk wrote:
> Hi Jim,
>
> I noticed a small mistake in this commit:
>
> maint: reflect gnulib module renamings
>
> * bootstrap.conf: Some gnulib modules are now deprecated in favor of
> new names with a "-h" suffix. Induce this change with the fol
Hi Jim,
I noticed a small mistake in this commit:
maint: reflect gnulib module renamings
* bootstrap.conf: Some gnulib modules are now deprecated in favor of
new names with a "-h" suffix. Induce this change with the following:
re='inttypes|realloc-gnu|sys_stat'
perl
===
# TOTAL: 26
# PASS: 25
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
1.
https://launchpadlibrarian.net/773464868/buildlog_ubuntu-plucky-s390x.gzip_1.12-1.1ubuntu3~ppa1_BUILDING.txt.gz
On Wed, Jan 29, 2025 at 3:59 PM Paul Egg
Hi,
On Wed, 2025-01-29 at 10:58 -0800, Paul Eggert wrote:
> Thanks for the bug report. I installed the attached, a bit simpler
> than
> the patch you suggested; can you please give it a try?
changing the call fill_inbuff(1) to fill_inbuff(0) will not work.
dfltcc works on the ou
Thanks for the bug report. I installed the attached, a bit simpler than
the patch you suggested; can you please give it a try?
Also, is there a related bug near dfltcc.c line 375? That is, when
(inptr == insize && fill_inbuf (1) == EOF && param->cf), won't insize
th
Problem reported by Nick Rosbrook in:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083700
align the behavior of dfltcc_inflate to do the same as gzip_inflate
when it hits a premature EOF
---
dfltcc.c| 6 +-
tests/hufts | 6 --
2 files changed, 9 insertions(+), 3 deletions
Rosbrook in:
> > https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083700
> >
> > align the behavior of dfltcc_inflate to do the same as gzip_inflate
> > when it hits a premature EOF
>
> Looking at the style of other gzip commits:
> I would capitalize "Ali
/+archive/ubuntu/rsyslog-apparmor/+build/29355576
On Mon, 2024-12-02 at 10:35 +0100, Eduard Stefes wrote:
> Problem reported by Nick Rosbrook in:
> https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083700
>
> align the behavior of dfltcc_inflate to do the same as gzip_inflate
&g
On Tue, 2025-01-28 at 15:37 +0100, Eduard Stefes wrote:
LGTM, but I have several stylistic comments.
> Problem reported by Nick Rosbrook in:
> https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083700
>
> align the behavior of dfltcc_inflate to do the same as gzip_inflate
>
Problem reported by Nick Rosbrook in:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083700
align the behavior of dfltcc_inflate to do the same as gzip_inflate
when it hits a premature EOF
---
dfltcc.c| 7 ++-
tests/hufts | 6 --
2 files changed, 10 insertions(+), 3
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 the same in compression and decompression
On 2025-01-08 Paul Eggert wrote:
> On 2025-01-07 10:22, Lasse Collin wrote:
>
> > However, one thing that isn't an issue in musl is fchmod which is
> > currently documented in Gnulib's doc/posix-headers/fcntl.texi.
> > fchmod and a few others were fixed in 2013 by using
> > /proc/self/fd.[1]
>
1]
https://git.musl-libc.org/cgit/musl/commit/?id=9ca1f62b0c0d3e50480eb654ac941ff943ce0558
Would the following Gnulib patch work around the musl bug?
It does, thanks!
OK, I installed it.
Should it check for __linux__ too to be sure that the workaround won't
accidentally apply on some othe
s.opengroup.org/onlinepubs/9799919799/functions/open.html>.
I had looked at it a few times recently but somehow managed to convince
myself that "search only" means something else than it actually does.
Thanks for steering me back to the right path!
> > In musl, O_SEARCH maps to
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
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) != 0 && errno != EINVAL)
|| (fsync
1 - 100 of 1052 matches
Mail list logo
