Ben Hutchings wrote:
"A buffer overrun has been fixed in zcat which happened sometimes when
the '-v, --show-nonprinting' option was used (or indirectly enabled)."
Thanks, Antonio. Will you request a CVE ID for this?
No, but I'm fine if somebody else requests it. The kind of vulnerability
On Tue, 31 Jul 2018 10:58:41 +0800 Ben Hutchings wrote:
*** Error in `zcat': free(): invalid next size (normal): 0x016e6980 ***
It seems I answered to the wrong bug[1], sorry. The bug fixed in
zutils-1.8-pre2 also fixes this one (#904819).
[1]
Stephen Kitt wrote:
Please accept my apologies, I didn’t mean to mischaracterise your work or
your emails, and I do appreciate all your efforts in this matter.
I'm sorry I didn't fix it sooner. But I'm happy that I have managed to
assemble a worst-case test file only 8192 bytes long and have
Stephen Kitt wrote:
I did provide a way to reproduce the problem, and Daniel reproduced it;
I will readily admit that it's neither convenient nor particularly useful
to identify the source of the problem, but dismissing this because
there's no way to reproduce it seems rather unfair to me.
See
Dear Ben,
I wrote:
"A double-free bug in zutils' zcat is not probable because zutils' zcat
is a C++ program that does not use neither malloc nor free."
You misquoted me as:
"this bug is impossible in C++!"
Please, don't misquote me.
On Tue, 31 Jul 2018 12:49:32 +0800 Ben Hutchings wrote:
On Sat, 28 Jul 2018 17:57:54 +0800 Ben Hutchings wrote:
The double-free bug in zutils zcat is presumably still unfixed, so I'm
cloning a separate bug for that.
A double-free bug in zutils' zcat is not probable because zutils' zcat
is a C++ program that does not use neither malloc nor free.
Note in the code below that by using a multi-format zcat, other data not
in one of the formats supported by the zcat used may be no longer
ignored but passed to cpio (possibly compressed), which may be the cause
of the problem.
Using the compressors directly to test the format (without *zcat
As advised in the xz man page:
When writing scripts that need to decompress files, it is recommended to
always use the name xz with appropriate arguments (xz -d or xz -dc)
instead of the names unxz and xzcat.
Patch follows:
diff -urdN initramfs-tools.orig/unmkinitramfs
Hi Lev,
Lev Lamberov wrote:
there's a somewhat old (from 2012) wishlist bug in the Debian BTS
[694057], asking for a proper support of crlf-terminated lines (or
arbitrary line-endings) in ed. Are there any plans to support the
requested mode?
I knew about the issue, but I have not yet done
Hello Jari et al,
Jari Aalto wrote:
Here is slightly more verbose description that would be nice
to get with --help option. I hope something like this would
be acceptable.
All the information added by your patch is already shown by the --help
output of the soon to be released ocrad
Hello Martin,
This bug was fixed upstream in version 1.7, so I think it can be closed.
Regards,
Antonio.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hello Martin,
Martin Zobel-Helas wrote:
could you have a look into the following Debian bug report?
[...]
Bug#682724: ed: info link to bash manual
Thanks for reporting this.
This bug was introduced before ed-0.3. I am fixing it like the links
between ddrescue[1] and lziprecover[2] so that
Version 1.6 of ed generates the man page with help2man. So I think this
bug has been fixed and can be closed.
Best regards,
Antonio.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Michael Prokop wrote:
fyi (find the bug at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656045 ):
Thanks for the hint.
This is an interesting addition to ddrescue, but I don't think it will
be easy to develop a pattern recognition algorithm for scratches.
Regards,
Antonio.
--
To
Hello,
Ocrad is able to produce other types of output, not only text. So the
current generic description of -o is more appropiate than the proposed
text only replacement.
OCR Results File is the name of a format originally used to interface
ocrad with kooka, and has its own chapter in the
Daniel Baumann wrote:
at this point, i think it's not really worth to the time to keep digging
into the issue any further (on my ultra30 at home it worked flawless for
all runs so far), so i'll probably just disable the check target on
sparc entirely.
I agree. Disabling the check target on
Daniel Baumann wrote:
smetana is back, so i tried it again.
Thanks.
funnily, 0.6 now works, eventhough it has never worked on smetana before.
It seems they have fixed something.
i've tested 0.7 about 20 times and it fails inconsistently at arround 6
iterations. with 5, it seems to work.
Tag: patch
I attach a patch adding support for lzip to lesspipe.
Best regards,
Antonio.
diff -urdN debian/lesspipe debian.new/lesspipe
--- debian/lesspipe 2009-04-18 13:41:40.0 +0200
+++ debian.new/lesspipe 2011-01-10 13:34:05.0 +0100
@@ -143,6 +143,18 @@
Daniel Baumann wrote:
how about making the number of threads configurable, so that we can use
a lower number on sparc?
Do you mean making the number of threads configurable in the test (make
check)? Sure, if the failure is caused by too many threads in the test
I'll happily reduce them.
I have just released lzlib-1.1, but I don't think lzlib causes this problem.
I have noticed that in the build log the message
Aborted
cmp: EOF on copy4
appears 6 times. The failing test tries a growing number of threads from
1 to 16. This may mean that the test fails with more than 10
Daniel Baumann wrote:
therefore, it looks to me like an issue involving specific hardware
features/combinations/configurations/$whatever of the sparc machines in
question, rather than a generic sparc failure, thus lowering severity to
important.
Antonio, do you have an idea about that?
No,
Daniel Baumann wrote:
do you have any preference to fix #608484[0]? atm, i think until,
hopefully, at some time gzip etc. drop their zcat et al, statically
compiling zutils (and moving them to /bin) is the best solution.
I agree with your solution. I am in talks with gzip maintainers[1] to
Hello Mario,
Mario 'BitKoenig' Holbe wrote:
please consider adding zmore and zless wrappers to zutils.
As I don't like to multiply scripts beyond necessity I have proposed the
gzip maintainers[1] to drop zless and zmore, given that there already
exist multi-format lesspipe scripts for less.
Package: ocrad
Version: 0.17-4
Severity: wishlist
Hello,
Ocrad version 0.19 is available since 27-Jan-2010. Please consider to
update the debian packages to the newest upstream version available.
http://ftpmirror.gnu.org/ocrad/ocrad-0.19.tar.gz
http://ftpmirror.gnu.org/ocrad/ocrad-0.19.tar.lz
Daniel Baumann wrote:
Currently only compression is performed in parallel.
Parallel decompression is planned to be implemented soon.
FYI, parallel decompression has already been implemented in version 0.5
(2010-02-10).
Best regards,
Antonio.
--
To UNSUBSCRIBE, email to
A patch for tar-1.22.91 has been already sent upstream[1], but perhaps
it can be applied in Debian if tar-1.23 is not released before next
Debian release.
[1] http://lists.gnu.org/archive/html/bug-tar/2010-02/msg00015.html
Regards,
Antonio.
--
To UNSUBSCRIBE, email to
Package: automake
Version: 1.11.1-1
Tags: patch
Hello,
The attached patch adds support for the lzip[1] compression format to
Automake.
[1] http://www.nongnu.org/lzip/lzip.html
Lzip is a lossless data compressor based on the LZMA algorithm, with
very safe integrity checking and a user
Package: dpkg
Version: 1.15.5.1
Severity: wishlist
Lzip is a lossless data compressor based on the LZMA algorithm, with
very safe integrity checking and a user interface similar to the one of
gzip or bzip2. Lzip decompresses almost as fast as gzip and compresses
better than bzip2, which makes
IMHO it would be better to replace dd_rescue with ddrescue.
There are many users confused by ddrescue not being included in the
ddrescue package:
(http://gumptravels.blogspot.com/2009/09/ddrescue-ddrescue-gddrescue-gnuddrescue.html)
I hadn't done a recovery in a while that needed special
Hello Michael, thanks for maintaining gddrescue.
Michael Prokop wrote:
Assuming ddrescue does several passes to try to rescue data,
a pass counter might be displayed to the user.
Ddrescue already shows the name of the pass being performed (each pass
does a different thing) and, when
BTW. The z command from GNU ed does more or less what you are requesting.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Thanks for reporting this.
The man page will be fixed in the next release.
The Press RETURN to continue... was removed in ed 0.3.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Ed opens files with the fopen function. Given that the combination
ed/NetBSD works, perhaps the problem is that the C library used by
Debian does not use open as a primitive for fopen.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Thank you for reporting this. It will be fixed in the next release of lzip.
Antonio.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Version 0.9-rc1 of GNU ed is ready for testing here
http://es.geocities.com/ant_diaz2001/ed-0.9-rc1.tar.gz
Please, test it and report any bugs you find.
Changes in this version:
* Return 0 exit status after receiving SIGHUP if the file is not
modified or is saved without error.
Regards,
Martin Michlmayr wrote:
Package: ocrad
Version: 0.14-1
Severity: important
Tags: patch
Your package fails to build with G++ 4.1. I'm filing this bug as
important for now, but when 4.1 will be the default compiler in
unstable (probably in a few weeks) I'll upgrade this to serious.
Thank you.
I think you have closed the request without understanding it.
I know there is a ddrescue package in debian. The request is about
creating a new package for GNU ddrescue, that is _not_ in debian, or
replacing the current ddrescue package with GNU ddrescue.
Regards,
Antonio Diaz, author of GNU
dd_rescue (currently in debian as 'ddrescue') at
http://freshmeat.net/projects/addrescue/
Regards.
Antonio Diaz Diaz.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
38 matches
Mail list logo
