Bug#902936: fixed in zutils 1.7-2
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 is "Heap-based Buffer Overflow"[1]. [1] http://cwe.mitre.org/data/definitions/122.html Best regards, Antonio.
Bug#904819: Bug#902936: fixed in zutils 1.7-2
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] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902936#124 Thank you very much Daniel for extracting a patch for 1.7 from 1.8-pre2 and applying it so fast. Best regards, Antonio.
Bug#902936: fixed in zutils 1.7-2
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 added it to the testsuite, so this bug should never happen again. Thanks again for your help. You can find the fixed version at http://download-mirror.savannah.gnu.org/releases/zutils/zutils-1.8-pre2.tar.lz The relevant entry in NEWS: "A buffer overrun has been fixed in zcat which happened sometimes when the '-v, --show-nonprinting' option was used (or indirectly enabled)." Best regards, Antonio.
Bug#902936: fixed in zutils 1.7-2
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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902936#5 for details. (I did also suggest that the real issue may lie somewhere else, since zutils 1.7 exhibits the bug if it's built on Debian stable, and doesn't if it's built on unstable.) Thanks for the report and for your support. I have finally managed to reproduce the problem. It seems to happen only when the -t option is used. It is not a double-free as Ben Hutchings suggested, but a buffer overrun. BTW, what I find unfair are all those accusations of dismissal. I do not have access to a Debian installation and have spent a lot of time trying to find a file that triggered this bug. I'll release a fixed version later today. Best regards, Antonio.
Bug#902936: fixed in zutils 1.7-2
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:
The non-technical problem I see is that your upstream is dismissive of
valid bug reports ("but it's compatible with cat", "this bug is
impossible in C++!"), and that you are agreeing with this nonsense.
I think "valid" does not mean what you think it means.
First, 'zcat -t' is not standardized. Therefore it is not valid to
expect it to be portable.
Second, a bug report is not valid until the bad code is pointed out or
until a way to reproduce the failure is provided. Until then the bug may
be anywhere else. The problem is that in spite of my efforts I have been
unable to reproduce the problem reported in zutils' zcat. As soon as
you, or anybody else, provide a way to reproduce the problem, or point
out the cause of the bug, I'll fix it in 24h. Until then there is not
much that I can do.
Stephen Kitt, please, could you send me the smallest file (not
necessarily an initramfs) that causes zcat to crash? Thanks.
Best regards,
Antonio.
Bug#904819: Bug#902936: fixed in zutils 1.7-2
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. But just in case, I have tested it for several hours with valgrind and I have been unable to find any bug. Moreover, I do not remember anybody reporting any double-free bug in zutils' zcat. The original reporter at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903931#5 states that zcat is not the problem: "Notice that even when it [unmkinitramfs] aborts, the "guilty" initrd file is perfectly fine and it can uncrompressed with gunzip or with zcat". I'm leaving #903931 assigned to initramfs-tools since I might as well work around the zcat incompatibility. You should because 'zcat -t' is not a valid way to test .gz file type. Zutils' zcat is not the only multi-format zcat out there, and a posix zcat would also fail. The problem is probably that unmkinitramfs is feeding random data to cpio by not using the standard command 'gzip -t' to test .gz file type. I have tested it and when feed random data, my somewhat old version of cpio not only accesses unaddressable memory, in one case it has even extracted a random file with random contents and random permissions. Therefore unmkinitramfs should be careful in testing the file format, as noted at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903931#81 ==4679== Syscall param read(buf) points to unaddressable byte(s) ==4679==at 0x5117B60: __read_nocancel (syscall-template.S:81) ==4679==by 0x418435: ??? (in /bin/cpio) ==4679==by 0x40CB33: ??? (in /bin/cpio) ==4679==by 0x4054CA: ??? (in /bin/cpio) ==4679==by 0x405945: process_copy_in (in /bin/cpio) ==4679==by 0x40AE4F: ??? (in /bin/cpio) ==4679==by 0x505BEDF: (below main) (libc-start.c:258) ==4679== Address 0x560ae10 is 0 bytes after a block of size 1,024 alloc'd ==4679==at 0x4C28B2D: malloc (vg_replace_malloc.c:299) ==4679==by 0x418D68: ??? (in /bin/cpio) ==4679==by 0x40AD1B: ??? (in /bin/cpio) ==4679==by 0x40AE44: ??? (in /bin/cpio) ==4679==by 0x505BEDF: (below main) (libc-start.c:258) ==4679== cpio: premature end of archive Best regards, Antonio.
Bug#903931: Maybe trailing garbage or data in an unsupported format is causing the problem?
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 wrappers) guarantees that the "other data" is indeed ignored. if zcat -t "$archive" >/dev/null 2>&1 ; then zcat "$archive" elif xzcat -t "$archive" >/dev/null 2>&1 ; then xzcat "$archive" elif lz4cat -t "$archive" >/dev/null 2>&1 ; then lz4cat "$archive" elif bzip2 -t "$archive" >/dev/null 2>&1 ; then bzip2 -c -d "$archive" elif lzop -t "$archive" >/dev/null 2>&1 ; then lzop -c -d "$archive" # Ignoring other data, which may be garbage at the end of the file fi | ( if [ -n "$dir" ]; then mkdir -p -- "$dir" cd -- "$dir" fi cpio "$@" )
Bug#903931: Neither zcat nor xzcat should be used in scripts
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 initramfs-tools/unmkinitramfs --- initramfs-tools.orig/unmkinitramfs 2018-07-18 06:50:17.0 +0200 +++ initramfs-tools/unmkinitramfs 2018-07-27 09:17:07.0 +0200 @@ -14,10 +14,10 @@ dir="$2" shift 2 - if zcat -t "$archive" >/dev/null 2>&1 ; then - zcat "$archive" - elif xzcat -t "$archive" >/dev/null 2>&1 ; then - xzcat "$archive" + if gzip -t "$archive" >/dev/null 2>&1 ; then + gzip -c -d "$archive" + elif xz -t "$archive" >/dev/null 2>&1 ; then + xz -c -d "$archive" elif lz4cat -t "$archive" >/dev/null 2>&1 ; then lz4cat "$archive" elif bzip2 -t "$archive" >/dev/null 2>&1 ; then Best regards, Antonio.
Bug#694057: [Bug-ed] support for crlf-terminated lines in ed
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 anything about it because it seems neither easy nor well defined, and implementing it properly is likely to cause some headaches, for example when stripping escaped newlines. IMHO using two characters to end a line is a bad idea. I'll make an attempt at a --crlf option as soon as I find the time. Best regards, Antonio.
Bug#602478: [Bug-ocrad] ocrad: manual - unclear options -o and -x
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 0.25-pre2, except the text for '-o' which is incorrect. Ocrad also makes transformations on images and produces image output in pnm format. It is therefore incorrect (and not very clear) to describe '-o' as save the extract from image to output file as you propose. I attach the complete output of --help of ocrad 0.25-pre2. I guess the Debian bug can be closed as soon as 0.25-pre2 is packaged. Best regards, Antonio. GNU Ocrad is an OCR (Optical Character Recognition) program based on a feature extraction method. It reads images in pbm (bitmap), pgm (greyscale) or ppm (color) formats and produces text in byte (8-bit) or UTF-8 formats. The pbm, pgm and ppm formats are collectively known as pnm. Ocrad includes a layout analyser able to separate the columns or blocks of text normally found on printed pages. For best results the characters should be at least 20 pixels high. If they are smaller, try the --scale option. Scanning the image at 300 dpi usually produces a character size good enough for ocrad. Merged, very bold or very light (broken) characters are normally not recognized correctly. Try to avoid them. Usage: ./ocrad [options] [files] Options: -h, --help display this help and exit -V, --versionoutput version information and exit -a, --append append text to output file -c, --charset=name try '--charset=help' for a list of names -e, --filter=name try '--filter=help' for a list of names -f, --force force overwrite of output file -F, --format=fmt output format (byte, utf8) -i, --invert invert image levels (white on black) -l, --layout perform layout analysis -o, --output=file place the output into file -q, --quiet suppress all messages -s, --scale=[-]n scale input image by [1/]n -t, --transform=name try '--transform=help' for a list of names -T, --threshold=n% threshold for binarization (0-100%) -u, --cut=l,t,w,h cut input image by given rectangle -v, --verbosebe verbose -x, --export=file export results in ORF format to file If no files are specified, ocrad reads the image from standard input. If the -o option is not specified, ocrad sends text to standard output. Exit status: 0 for a normal exit, 1 for environmental problems (file not found, invalid flags, I/O errors, etc), 2 to indicate a corrupt or invalid input file, 3 for an internal consistency error (eg, bug) which caused ocrad to panic. Report bugs to bug-oc...@gnu.org Ocrad home page: http://www.gnu.org/software/ocrad/ocrad.html General help using GNU software: http://www.gnu.org/gethelp
Bug#682724: ed: info link to bash manual
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
Bug#682724: [Bug-ed] Fwd: Bug#682724: ed: info link to bash manual
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 it also works in the html version[3], and will release a corrected version soon. [1]http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Examples [2]http://www.nongnu.org/lzip/manual/lziprecover_manual.html#Examples [3]http://www.gnu.org/software/ed/manual/ed_manual.html#Introduction-to-Line-Editing 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
Bug#480898: manpage incorrectly encodes \` and \'
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
Bug#656045: [fwd] Bug#656045: Wanted: geometry mapped scratch prediction for optical media
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 UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602478: [Bug-ocrad] Re: Bug#602478: ocrad: manual -- Unclear options -o and -x
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 manual, but to avoid confusions I have replaced the description of -x to export results in ORF format to file. I'll also extend the description of ocrad in the --help output, but not so much as proposed. For example, I think something like Always see with your own eyes the pnm file before blaming ocrad for the results is out of place in a description. Regards, Antonio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608642: plzip: FTBFS on sparc: test failures
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 sparc seems the most reasonable thing to do in this case. Thanks, Antonio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608642: plzip: FTBFS on sparc: test failures
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. with 6, it sometimes does, and with 7 it almost always fails. quite strange. The only real difference between the compression code of 0.6 and 0.7 is the order of initialization of mutex and condition in the function xinit. This should not break anything but I'll send you shortly a modified version to see if it fixes this problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608485: zless: please add support for lzip
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 @@ if [ -x `which lha` ]; then lha v $1 else echo No lha available; fi ;; + *.tar.lz|*.tlz) + if [ -x `which lzip` ]; then + lzip -dc $1 | tar tvvf - + elif [ -x `which lunzip` ]; then + lunzip -dc $1 | tar tvvf - + else echo No lzip or lunzip available; fi ;; + + *.lz) + if [ -x `which lzip` ]; then lzip -dc $1 + elif [ -x `which lunzip` ]; then lunzip -dc $1 + else echo No lzip or lunzip available; fi ;; + *.tar.lzma) if [ -x `which lzma` ]; then lzma -dc $1 | tar tfvv - diff -urdN debian/lesspipe.1 debian.new/lesspipe.1 --- debian/lesspipe.1 2007-10-22 13:03:49.0 +0200 +++ debian.new/lesspipe.1 2011-01-10 13:34:05.0 +0100 @@ -70,6 +70,8 @@ *.gif, *.jpeg, *.jpg, *.pcd, *.png, *.tga, *.tiff, *.tif *.iso, *.raw, *.bin *.lha, *.lzh + *.tar.lz, *.tlz + *.lz *.pdf *.rar, *.r[0-9][0-9] *.rpm
Bug#608642: plzip: FTBFS on sparc: test failures
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. But as 16 threads is a small number for what plzip can manage, I would like to be sure that the number of threads is indeed the problem. Could you, please, edit line 77 of plzip-0.7/testsuite/check.sh to remove all numbers larger than 10 and see if plzip passes the test then? Given that the failure message shown in the build log is Aborted, it could be produced by a lack of enough memory. (16 threads use more than 80MiB). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608642: plzip: FTBFS on sparc: test failures
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 threads. BTW. I have tried successfully plzip on x86_32 (single processor) with 100 threads. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608642: plzip: FTBFS on sparc: test failures
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, but I see in the build log that an invalid pointer seems to be passed to LZ_compress_close, so I am checking the related code in lzlib and plzip. If I can't find anything wrong in the code, I'll release a new stable version of lzlib soon (maybe tomorrow) to see if that helps. There have been a number of changes in lzlib since 1.0. 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
Bug#608484: zutils: diverts in /bin but installs itself to /usr/bin
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 replace gzip's scripts, but it will take some time because they want to approach such replacement conservatively. [1] http://lists.gnu.org/archive/html/bug-gzip/2010-12/msg5.html When this conflict with the gzip package is solved I'll approach Julian Seward about bzcat, etc. 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
Bug#608485: zutils: please consider adding zmore, zless
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. [1] http://lists.gnu.org/archive/html/bug-gzip/2010-12/msg00015.html The less package in Debian[2] also provides such a lesspipe script. [2] http://packages.debian.org/sid/less Regards, Antonio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585166: New upstream version available (0.19)
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 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
Bug#563929: RFP: plzip -- parallel version of lzip
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569493: tar: Please support lzip compression format
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570424: Patch adding support for lzip (dist-lzip)
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 interface similar to the one of
gzip or bzip2. Lzip decompresses almost as fast as gzip and compresses
better than bzip2, which makes it well suited for software distribution
and data archiving.
Given the simplicity of the changes needed (see attached patch), I see
no reason for not supporting lzip, which some developers[2] already dub
the currently best free compression program.
[2] ftp://ftp.gmplib.org/pub/snapshot/README
Best regards,
Antonio.
diff -urdN automake-1.11.1/automake.in automake-1.11.1.new/automake.in
--- automake-1.11.1/automake.in 2009-12-08 19:15:40.0 +0100
+++ automake-1.11.1.new/automake.in 2010-02-15 13:24:12.0 +0100
@@ -3895,7 +3895,7 @@
{
my $archive_defined = option 'no-dist-gzip' ? 0 : 1;
$archive_defined ||=
- grep { option dist-$_ } qw(shar zip tarZ bzip2 lzma xz);
+ grep { option dist-$_ } qw(shar zip tarZ bzip2 lzip lzma xz);
error (option 'no-dist-gzip',
no-dist-gzip specified but no dist-* specified,
. at least one archive format must be enabled)
@@ -7049,6 +7049,7 @@
'XZ' = !! option 'dist-xz',
'LZMA'= !! option 'dist-lzma',
+ 'LZIP'= !! option 'dist-lzip',
'BZIP2' = !! option 'dist-bzip2',
'COMPRESS'= !! option 'dist-tarZ',
'GZIP'= ! option 'no-dist-gzip',
diff -urdN automake-1.11.1/doc/automake.texi automake-1.11.1.new/doc/automake.texi
--- automake-1.11.1/doc/automake.texi 2009-12-08 19:15:40.0 +0100
+++ automake-1.11.1.new/doc/automake.texi 2010-02-15 13:24:12.0 +0100
@@ -8440,6 +8440,11 @@
Generate a gzip tar archive of the distribution.
@trindex dist-gzip
+...@item @code{dist-lzip}
+Generate an @samp{lzip} tar archive of the distribution. @command{lzip}
+archives are frequently smaller than @command{bzip2}-compressed archives.
+...@trindex dist-lzip
+
@item @code{dist-lzma}
Generate an @samp{lzma} tar archive of the distribution. @command{lzma}
archives are frequently smaller than @command{bzip2}-compressed archives.
@@ -8988,6 +8993,12 @@
Hook @code{dist-bzip2} to @code{dist}.
@trindex dist-bzip2
+...@item @option{dist-lzip}
+...@cindex Option, @option{dist-lzip}
+...@opindex dist-lzip
+Hook @code{dist-lzip} to @code{dist}.
+...@trindex dist-lzip
+
@item @option{dist-lzma}
@cindex Option, @option{dist-lzma}
@opindex dist-lzma
@@ -9260,7 +9271,8 @@
These three mutually exclusive options select the tar format to use
when generating tarballs with @samp{make dist}. (The tar file created
is then compressed according to the set of @option{no-dist-gzip},
-...@option{dist-bzip2}, @option{dist-lzma} and @option{dist-tarZ} options in use.)
+...@option{dist-bzip2}, @option{dist-lzip}, @option{dist-lzma} and
+...@option{dist-tarz} options in use.)
These options must be passed as arguments to @code{AM_INIT_AUTOMAKE}
(@pxref{Macros}) because they can require additional configure checks.
@@ -12920,4 +12932,4 @@
@c LocalWords: LTALLOCA MALLOC malloc memcmp strdup alloca libcompat xyz DFOO
@c LocalWords: unprefixed buildable preprocessed DBAZ DDATADIR WARNINGCFLAGS
@c LocalWords: LIBFOOCFLAGS LIBFOOLDFLAGS ftable testSubDir obj LIBTOOLFLAGS
-...@c LocalWords: barexec Pinard's automatize initialize lzma xz
+...@c LocalWords: barexec Pinard's automatize initialize lzip lzma xz
diff -urdN automake-1.11.1/lib/Automake/Options.pm automake-1.11.1.new/lib/Automake/Options.pm
--- automake-1.11.1/lib/Automake/Options.pm 2009-12-08 19:02:32.0 +0100
+++ automake-1.11.1.new/lib/Automake/Options.pm 2010-02-15 13:24:12.0 +0100
@@ -259,7 +259,7 @@
elsif ($_ eq 'no-installman' || $_ eq 'no-installinfo'
|| $_ eq 'dist-shar' || $_ eq 'dist-zip'
|| $_ eq 'dist-tarZ' || $_ eq 'dist-bzip2'
- || $_ eq 'dist-lzma' || $_ eq 'dist-xz'
+ || $_ eq 'dist-lzip' || $_ eq 'dist-lzma' || $_ eq 'dist-xz'
|| $_ eq 'no-dist-gzip' || $_ eq 'no-dist'
|| $_ eq 'dejagnu' || $_ eq 'no-texinfo.tex'
|| $_ eq 'readme-alpha' || $_ eq 'check-news'
diff -urdN automake-1.11.1/lib/am/distdir.am automake-1.11.1.new/lib/am/distdir.am
--- automake-1.11.1/lib/am/distdir.am 2009-12-08 19:15:40.0 +0100
+++ automake-1.11.1.new/lib/am/distdir.am 2010-02-15 13:24:12.0 +0100
@@ -344,6 +344,12 @@
tardir=$(distdir) $(am__tar) | bzip2 -9 -c $(distdir).tar.bz2
$(am__remove_distdir)
+?LZIP?DIST_ARCHIVES += $(distdir).tar.lz
+.PHONY: dist-lzip
+dist-lzip: distdir
+ tardir=$(distdir) $(am__tar) | lzip -9 -c $(distdir).tar.lz
+ $(am__remove_distdir)
+
?LZMA?DIST_ARCHIVES += $(distdir).tar.lzma
.PHONY: dist-lzma
dist-lzma: distdir
@@ -396,6 +402,7 @@
dist dist-all: distdir
?GZIP?
Bug#556960: dpkg: please support lzip compressed packages
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 it well suited for software distribution
and data archiving.
The lzip file format (.lz) is an improved successor of the lzma_alone
file format (.lzma), providing magic bytes and integrity checking.
Software tools that (de)compress both formats or can convert lzma_alone
files to lzip format are listed in the Links section of
http://www.nongnu.org/lzip/lzip.html.
Lzip is stable, distributed by many GNU/Linux distributions (including
Debian) and used to distribute software from ftp.gnu.org.
Best regards,
Antonio.
diff -urdN dpkg-1.15.5.1/debian/control dpkg-1.15.5.1.new/debian/control
--- dpkg-1.15.5.1/debian/control 2009-11-17 08:18:00.0 +0100
+++ dpkg-1.15.5.1.new/debian/control 2009-11-18 13:50:00.0 +0100
@@ -39,7 +39,7 @@
Section: utils
Priority: optional
Architecture: all
-Depends: dpkg (= 1.15.4), perl5, perl-modules, bzip2, lzma, xz-utils,
+Depends: dpkg (= 1.15.4), perl5, perl-modules, bzip2, lzip, lzma, xz-utils,
patch (= 2.2-1), make, binutils, libtimedate-perl, base-files (= 5.0.0)
Recommends: gcc | c-compiler, build-essential, fakeroot, gnupg, gpgv
Suggests: debian-keyring, debian-maintainers
diff -urdN dpkg-1.15.5.1/dpkg-deb/build.c dpkg-1.15.5.1.new/dpkg-deb/build.c
--- dpkg-1.15.5.1/dpkg-deb/build.c 2009-11-17 08:18:00.0 +0100
+++ dpkg-1.15.5.1.new/dpkg-deb/build.c 2009-11-18 13:50:00.0 +0100
@@ -542,6 +542,9 @@
case compress_type_bzip2:
datamember = DATAMEMBER_BZ2;
break;
+case compress_type_lzip:
+ datamember = DATAMEMBER_LZ;
+ break;
case compress_type_lzma:
datamember = DATAMEMBER_LZMA;
break;
diff -urdN dpkg-1.15.5.1/dpkg-deb/dpkg-deb.h dpkg-1.15.5.1.new/dpkg-deb/dpkg-deb.h
--- dpkg-1.15.5.1/dpkg-deb/dpkg-deb.h 2009-11-17 08:18:00.0 +0100
+++ dpkg-1.15.5.1.new/dpkg-deb/dpkg-deb.h 2009-11-18 13:59:11.0 +0100
@@ -59,6 +59,8 @@
#define DATAMEMBER_COMPAT_GZ data.tar.gz/
#define DATAMEMBER_BZ2 data.tar.bz2
#define DATAMEMBER_COMPAT_BZ2 data.tar.bz2/
+#define DATAMEMBER_LZ data.tar.lz
+#define DATAMEMBER_COMPAT_LZ data.tar.lz/
#define DATAMEMBER_LZMA data.tar.lzma
#define DATAMEMBER_COMPAT_LZMA data.tar.lzma/
#define DATAMEMBER_CAT data.tar
diff -urdN dpkg-1.15.5.1/dpkg-deb/extract.c dpkg-1.15.5.1.new/dpkg-deb/extract.c
--- dpkg-1.15.5.1/dpkg-deb/extract.c 2009-11-17 08:18:00.0 +0100
+++ dpkg-1.15.5.1.new/dpkg-deb/extract.c 2009-11-18 13:50:00.0 +0100
@@ -181,6 +181,10 @@
!memcmp(arh.ar_name,DATAMEMBER_COMPAT_BZ2,sizeof(arh.ar_name))) {
adminmember= 0;
compress_type = compress_type_bzip2;
+ } else if (!memcmp(arh.ar_name,DATAMEMBER_LZ,sizeof(arh.ar_name)) ||
+ !memcmp(arh.ar_name,DATAMEMBER_COMPAT_LZ,sizeof(arh.ar_name))) {
+ adminmember= 0;
+ compress_type = compress_type_lzip;
} else if (!memcmp(arh.ar_name, DATAMEMBER_LZMA, sizeof(arh.ar_name)) ||
!memcmp(arh.ar_name, DATAMEMBER_COMPAT_LZMA, sizeof(arh.ar_name))) {
adminmember = 0;
diff -urdN dpkg-1.15.5.1/dpkg-deb/main.c dpkg-1.15.5.1.new/dpkg-deb/main.c
--- dpkg-1.15.5.1/dpkg-deb/main.c 2009-11-17 08:18:00.0 +0100
+++ dpkg-1.15.5.1.new/dpkg-deb/main.c 2009-11-18 14:07:03.0 +0100
@@ -105,7 +105,8 @@
packages).\n
-z# Set the compression level when building.\n
-Ztype Set the compression type used when building.\n
- Allowed values: gzip, bzip2, lzma, none.\n
+ Allowed values: gzip, bzip2, lzip, lzma,\n
+ none.\n
\n));
printf(_(
@@ -197,6 +198,8 @@
compress_type = compress_type_gzip;
else if (!strcmp(value, bzip2))
compress_type = compress_type_bzip2;
+ else if (!strcmp(value, lzip))
+compress_type = compress_type_lzip;
else if (!strcmp(value, lzma))
compress_type = compress_type_lzma;
else if (!strcmp(value, none))
diff -urdN dpkg-1.15.5.1/lib/dpkg/compression.c dpkg-1.15.5.1.new/lib/dpkg/compression.c
--- dpkg-1.15.5.1/lib/dpkg/compression.c 2009-11-17 08:18:01.0 +0100
+++ dpkg-1.15.5.1.new/lib/dpkg/compression.c 2009-11-18 13:50:00.0 +0100
@@ -111,6 +111,8 @@
#else
fd_fd_filter(fd_in, fd_out, BZIP2, bzip2, -dc, v.buf);
#endif
+case compress_type_lzip:
+ fd_fd_filter(fd_in, fd_out, LZIP, lzip, -dc, v.buf);
case compress_type_lzma:
fd_fd_filter(fd_in, fd_out, LZMA, lzma, -dc, v.buf);
case compress_type_cat:
@@ -208,6 +210,10 @@
combuf[1]= *compression;
fd_fd_filter(fd_in, fd_out,
Bug#252198: ddrescue: please include dd_rhelp
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 attention, and ended up wasting a bunch of time fiddling the the ddrescue variants before I found the one I had used in the past. ... I promptly installed gddrescue using apt-get install gddrescue and then tried to view the man pages, of course using man gddrescue ... however, this is where some of the ddrescue confusion comes in, gddrescue simply uses ddrescue for its binary and for its man pages... (confusing), since dd_rescue actually uses a package name of ddrescue (apt-get install ddrescue), while using dd_rescue for its binary and man pages (once again, confusing). And here is a explanation of why dd_rhelp is so slow: (http://www.toad.com/gnu/sysadmin/index.html#ddrescue) One problem with dd_rhelp is that it's a shell script, so it's really slow and consumes massive resources. On one of my drives that had about 2900 bad sectors on it, dd_rhelp would waste upwards of 15 minutes deciding what blocks to tell dd_rescue to try reading next. During that time it makes about 100 new Unix processes every second. 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
Bug#407440: [Bug-ddrescue] Re: Bug#407440: gddrescue: missing pass indicator
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 retrying, the retry number. * Do you have an idea how to simulate a broken device? No, but Corvus Corax is working on it. See this message (Benchmarking ddrescue) http://lists.gnu.org/archive/html/bug-ddrescue/2009-07/msg00027.html 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
Bug#471866: The browse command from Plan9's ed
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
Bug#190907: man page s
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
Bug#357498: ed and LD_PRELOAD
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. Trouble? Contact listmas...@lists.debian.org
Bug#530135: lzip: bashism in /bin/sh script
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
Bug#456907: Version 0.9-rc1 of GNU ed released
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, Antonio Diaz, GNU ed maintainer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357717: FTBFS with G++ 4.1: definition not in namespace enclosing
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 have fixed it and will release the corrected version this week. Best regards, Antonio Diaz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316238: acknowledged by developer (Package exists in the archive)
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 ddrescue and GNU ocrad. PS. I am not a debian developer and I can't upload packages. Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #316238: ITP: ddrescue -- data recovery tool, which was filed against the wnpp package. It has been closed by one of the developers, namely Martin Michlmayr [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer, by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) Received: (at 316238-done) by bugs.debian.org; 6 Aug 2005 20:00:25 + From [EMAIL PROTECTED] Sat Aug 06 13:00:25 2005 Return-path: [EMAIL PROTECTED] Received: from merkel.debian.org [192.25.206.16] (mail) by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1E1UqH-0006Hw-00; Sat, 06 Aug 2005 13:00:25 -0700 Received: from tbm by merkel.debian.org with local (Exim 3.36 1 (Debian)) id 1E1UqG-00081g-00; Sat, 06 Aug 2005 14:00:24 -0600 Date: Sat, 6 Aug 2005 14:00:24 -0600 From: Martin Michlmayr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Package exists in the archive Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: Martin Michlmayr [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 It seems that this package already exists in the archive. If you have uploaded the package yourself but forgotten to close this WNPP bug, please read the instructions at http://www.debian.org/devel/wnpp for handling WNPP bugs properly. You should close WNPP bugs in your initial upload with a statement like Initial upload. (Closes: #316238). Thanks. Of course, it might also be that someone else uploading this package, in which case the statements above don't apply -- in any case, the package seems to be in the archive now. Information about the package already in the archive: Package: ddrescue Binary: ddrescue Version: 1.10-1 Priority: optional Section: utils Maintainer: Ayman Negm [EMAIL PROTECTED] Build-Depends: debhelper ( 4.0.0) Architecture: any Standards-Version: 3.6.1 Format: 1.0 Directory: pool/main/d/ddrescue Files: 9d13f36a198fe743a449beb3c7d9eb5e 554 ddrescue_1.10-1.dsc 58abc3a6d75deeedaedf2ca0eaa3d1ca 19594 ddrescue_1.10.orig.tar.gz be6c0e37b8b23c3ff1f97f9e2bd1b6e8 20 ddrescue_1.10-1.diff.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316238: RFP: GNU ddrescue - Data recovery tool
Package: wnpp Severity: wishlist GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying hard to rescue data in case of read errors. The basic operation of GNU ddrescue is fully automatic. That is, you don't have to wait for an error, stop the program, read the log, run it in reverse mode, etc. If you use the logfile feature of GNU ddrescue, the data is rescued very efficiently (only the needed blocks are read). Also you can interrupt the rescue at any time and resume it later at the same point. License : GNU General Public License V2 or later GNU ddrescue is hosted at http://www.gnu.org/software/ddrescue/ddrescue.html The latest version of GNU ddrescue can be found at http://ftp.gnu.org/gnu/ddrescue/ You can find some interesting information about how GNU ddrescue compares with Garloff's 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]
