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
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
> 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 exclude – new bug report?
--
Greetings
> 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/include -Wno-ca
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"
&& ./configure --prefix=/opt/l
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
-
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
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
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
Jim Meyering wrote:
> I'll soon push the attached:
> +if MORE
> +ZMORE_PROG = zless
Shouldn't that be
+if MORE
+ZMORE_PROG = zmore
?
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
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
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
Hi,
On Thu, 2025-02-06 at 10:20 -0800, Paul Eggert wrote:
> On 2025-02-05 07:46, Eduard Stefes wrote:
>
> > We think that the only
> > possibility for a problem here, is if faulty hardware updates
> > param->cf
> > incorrect.
>
> I'd rather not worry about hardware going bad, unless the hardware
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
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 outbuf, and fill_inb
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(-
Hi,
Thx for the review. I'll resend with the corrections.
On Tue, 2025-01-28 at 15:44 +0100, Ilya Leoshkevich wrote:
> 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
Hi,
After @AnderesHasenack tried to verify my patch, We found more problems
with the output buffer flushing in dfltcc_inflate in dfltcc.c.
I wrote a new patch and Andreas verified it with the ubuntu rsyslog
build.[1]
I will send the patch to the ML here.
[1]
https://launchpad.net/~ahasenack/
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 deletions
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
---
Notes:
Hi, the ubuntu folks found a problem with gzip on the ibm s390x
architecture.
Collin Funk writes:
> -# define casemap(c) tolow(c) /* Force file names to lower case */
This is for MSDOS/OS2/WIN32/ATARI only as far as I can tell -- do we
know that tolower() works as expected on these architectures? What
problem is caused by the current behaviour? I think it would be nice
Hi. The makecrc.c is not longer particulary relevant since gzip uses
the gnulib crc module. The code is nice to preserve, and could be moved
to gnulib eventually (possibly rewritten), but it will still be in gzip
git forever, so doesn't have to be in the release archive. What do you
think?
/Sim
Thanks, that was helpful. In the meantime I solved it with
-Wno-bad-function-cast even if I often read, that the warning should not be
ignored.
Paul Eggert schrieb am Mo., 12. Aug. 2024, 10:23:
> On 2024-08-11 17:55, Daniel Ruf via GNU gzip discussion and bug reports.
> wrote:
> >
During my research regarding faster gzip implementations I found
https://medium.com/@techhara/speeding-up-system-gzip-by-60-75edbc8ac0e8
Is the article correct and the implementation should be updated, or is the
benchmark flawed?
I'm trying to cross-compile on Ubuntu for Windows hosts using ./configure
--quiet --host=x86_64-w64-mingw32
But my build fails:
dup2.c: In function 'ms_windows_dup2':
dup2.c:80:11: error: cast from function call of type 'intptr_t' {aka 'long
long int'} to non-matching type 'void *' [-Werror=bad-f
Hi,
I just stumbled upon a "feature" that was probably not intended with the
-S parameter:
$ cat /tmp/importantfile
important content
$ gzip -f -k -S .d/../../tmp/importantfile /etc/ld.so.conf
$ cat /tmp/importantfile
$
I.e., it is possible to create/overwrite files at arbitrary
Hi,
I'm trying to compile gzip-1.9-13.el8_5.
Failed on make check
FAIL gzexe (exit status: 1)
Testsuite summary for gzip 1.9
# TOTAL: 23
# PASS:
Hi Paul:
Thanks for your quick reply. I apply
0001-zdiff-fix-arg-handling-bug.patch at the latest gzip code(commit
2b281564e142c68acbdc) and test the problem.
This patch can fix options with argument(e.g zdiff -C 5). This patch did
an interesting job to identify zidff options with argument([
As Bram Mertens mentioned in bug#35209:
"diff -y -W 200 /tmp/b1 /tmp/b2". But when passed to zdiff the space
between "-W" and 200 causes the COLUMNS argument to be interpreted as a
file:
zdiff -y -W 200 /tmp/b1 /tmp/b2
/bin/zdiff: 72: /bin/zdiff: cannot open 200: No such file
I reproduce this
As Bram Mertens mentioned in bug#35209:
"diff -y -W 200 /tmp/b1 /tmp/b2". But when passed to zdiff the space
between "-W" and 200 causes the COLUMNS argument to be interpreted as a
file:
zdiff -y -W 200 /tmp/b1 /tmp/b2
/bin/zdiff: 72: /bin/zdiff: cannot open 200: No such file
I reproduce this
Thank you for your help
-Original Message-
From: Paul Eggert
Sent: Friday, November 19, 2021 2:31 PM
To: Zhang, Cynthia X. (GSFC-705.0)[TELOPHASE CORP]
Cc: 51976-d...@debbugs.gnu.org
Subject: [EXTERNAL] Re: bug#51976: Inquiry: gzip for NASA Use
On 11/19/21 11:04, cynthia.x.zhang wrote:
Hello, my name is Cynthia and I am a Supply Chain Risk Management Analyst at
NASA. NASA is currently conducting a supply chain assessment of gzip. As stated
by Sections 208 and 514 of the Consolidated Appropriations Act, 2021, Public
Law 116-260, enacted December 27, 2020, a required step of our
Hi,
I've got a lvkm i wanna backup, put short, not enough space.
/dev/dva1..2..3..etc...
Can I have gzip show prompt and wait for user input after splitting the
fist segment of a multi-part archive?
Thanks!
--
-Jeremy
Hi Team,
Any Update?
Regards,
Sathish Narayanan
On Wed, Aug 21, 2019 at 6:10 PM Sathish Narayanan
wrote:
> Gzip Version -> gzip 1.6
>
> Regards,
> Sathish Narayanan
>
>
> On Wed, Aug 21, 2019 at 6:09 PM Sathish Narayanan
> wrote:
>
>> Hi Team,
>>
>> I used gzip files and sub directories as b
Gzip Version -> gzip 1.6
Regards,
Sathish Narayanan
On Wed, Aug 21, 2019 at 6:09 PM Sathish Narayanan
wrote:
> Hi Team,
>
> I used gzip files and sub directories as below command
>
> gzip -v -9 -r -c folder_name/ > /path/folder_name.gz
> Note: folder_name -> contains files and subdirectories.
Hi Team,
I used gzip files and sub directories as below command
gzip -v -9 -r -c folder_name/ > /path/folder_name.gz
Note: folder_name -> contains files and subdirectories.
How can i extract files and subdirectories from folder_name.gz. While
extracting i will get one executable file. Can you p
40 matches
Mail list logo
