Bug#986396: lrzip: extreme low compression ratio in large files with latest program versions
This was fixed in 0.641. Urge everyone to update. Thanks On Mon, 5 Apr 2021 at 17:03, Jose Antonio Castro wrote: > > Package: lrzip > Version: 0.640-1 > Severity: normal > X-Debbugs-Cc: tonio.cas...@gmail.com > > Dear Maintainer, > > I use lrzip for compress large (~5Gb) database dumps. With old versións (like > 0.631) i get a file over 400Mb, but with the lasts versións I get a ~3Gb file. > > Thanks and excuse my English. > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing'), (2, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages lrzip depends on: > ii bash5.1-2+b1 > ii libbz2-1.0 1.0.8-4 > ii libc6 2.31-11 > ii libgcc-s1 10.2.1-6 > ii liblz4-11.9.3-1 > ii liblzo2-2 2.10-2 > ii libstdc++6 10.2.1-6 > ii zlib1g 1:1.2.11.dfsg-2 > > lrzip recommends no packages. > > lrzip suggests no packages. > > -- no debconf information
Bug#642271: lrzip: FTBFS on hurd-i386: missing mremap
On Wed, 21 Sep 2011 16:26:49 jari wrote: On 2011-09-21 09:13, jari wrote: | On 2011-09-21 09:50, Con Kolivas wrote: | | On Wed, 21 Sep 2011 09:37:35 you wrote: | | Package: lrzip | | Version: 0.607+20110917+git79c2e9a-2 | | Severity: important | | Tags: patch | | User: debian-h...@lists.debian.org | | Usertags: hurd | | | | Hi, | | | | currently[1], lrzip does not compile on GNU/Hurd. | | This is because it is not configured to use a fake mremap function, | | so it is being used as if it would exist in libc. | | The attached patch enables the use of fake_mremap as mremap also on | | GNU/Hurd. (Ideally a configure check would do this job?) | | | | [1] | | https://buildd.debian.org/status/fetch.php?pkg=lrziparch=hurd-i386v | | er=0. 607%2B20110917%2Bgit79c2e9a-2stamp=1316559794 | | | | Thanks, | | | | + defined(__APPLE__) || defined(__CYGWIN__) || \ | | + defined(__GNU__) | | | | Wouldn't this also define fake mremap on linux too, which actually does | | have mremap? | | As the problem is Hurd specific, we want stricter[*]: |__gnu_hurd__ Ah, I take it back. In the thread later[*]: ‘__GNU__’ is only defined on GNU/Hurd, whereas ‘__GLIBC__’ is defined on all GNU variants. so the original patch is correct. Jari [*] http://lists.debian.org/debian-bsd/2010/01/msg00151.html It turns out mremap is linux specific only so I've inverted the test entirely for !linux and pushed the fix to git. Thanks and Regards, Con -- -ck -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642271: lrzip: FTBFS on hurd-i386: missing mremap
On Wed, 21 Sep 2011 09:37:35 you wrote: Package: lrzip Version: 0.607+20110917+git79c2e9a-2 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, currently[1], lrzip does not compile on GNU/Hurd. This is because it is not configured to use a fake mremap function, so it is being used as if it would exist in libc. The attached patch enables the use of fake_mremap as mremap also on GNU/Hurd. (Ideally a configure check would do this job?) [1] https://buildd.debian.org/status/fetch.php?pkg=lrziparch=hurd-i386ver=0. 607%2B20110917%2Bgit79c2e9a-2stamp=1316559794 Thanks, + defined(__APPLE__) || defined(__CYGWIN__) || \ + defined(__GNU__) Wouldn't this also define fake mremap on linux too, which actually does have mremap? Regards, Con -- -ck -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623745: lrzip: Fails to compress big enough (tens or hundreds of GB) because of a thread leak
On Sat, 23 Apr 2011 03:09:06 you wrote:
Package: lrzip
Version: 0.552+20110217+gitcd8b086-1
Severity: normal
[NOTE: This still seems to be a problem with the most recent upstream
version of 0.603 - try with lrzip -lvv - hence Cc:ing to upstream
Con Kolivas.]
Hi,
While trying to compress a big (172 GiB) file (with lrzip -nvv), I ran
into this error:
Starting thread 7 to compress 19381057 bytes from stream 1
Starting thread 0 to compress 19381057 bytes from stream 1
pthread_createResource temporarily unavailable
Fatal error - exiting
It turns out lrzip does not pthread_join() the threads it creates,
which in turn eventually exhausts the threads. You can verify this by
modifying it to print some debug information:
Thanks for that Sami.
I guess this answers this comment in the manpages:
It is unspecified whether a thread that has exited but remains unjoined counts
against {PTHREAD_THREADS_MAX}.
Detaching the threads on the compression side should be enough to fix this
issue. I've committed a fix to my git repo and the patch is attached below.
Regards,
Con
--
-ck
diff --git a/stream.c b/stream.c
index 6f840e7..c11da00 100644
--- a/stream.c
+++ b/stream.c
@@ -135,13 +135,19 @@ static void cond_broadcast(pthread_cond_t *cond)
fatal(pthread_cond_broadcast failed);
}
-void create_pthread(pthread_t * thread, pthread_attr_t * attr,
+void create_pthread(pthread_t *thread, pthread_attr_t * attr,
void * (*start_routine)(void *), void *arg)
{
- if (pthread_create(thread, attr, start_routine, arg))
+ if (unlikely(pthread_create(thread, attr, start_routine, arg)))
fatal(pthread_create);
}
+void detach_pthread(pthread_t *thread)
+{
+ if (unlikely(pthread_detach(*thread)))
+ fatal(pthread_detach);
+}
+
void join_pthread(pthread_t th, void **thread_return)
{
if (pthread_join(th, thread_return))
@@ -1435,6 +1441,7 @@ static void clear_buffer(rzip_control *control, struct stream_info *sinfo, int s
s-i = i;
s-control = control;
create_pthread(threads[i], NULL, compthread, s);
+ detach_pthread(threads[i]);
if (newbuf) {
/* The stream buffer has been given to the thread, allocate a
Bug#607978: lrzip: FTBFS on kfrebsd-*: undefined reference to mremap
On Sun, 26 Dec 2010 02:04:55 you wrote: Source: lrzip Version: 0.551-1 Severity: serious Justification: FTBFS User: debian-...@lists.debian.org Usertags: kfreebsd Hi, your package no longer builds on kfreebsd-*: | g++ -o lrzip main.o rzip.o runzip.o stream.o util.o 7zCrc.o zpipe.o | Threads.o LzFind.o LzFindMt.o LzmaDec.o LzmaEnc.o LzmaLib.o -llzo2 -lbz2 | -lz -lm -lpthread rzip.o: In function `mmap_stdin': | /build/buildd-lrzip_0.551-1-kfreebsd-i386-2peUE8/lrzip-0.551/rzip.c:663: | undefined reference to `mremap' collect2: ld returned 1 exit status Full build logs: https://buildd.debian.org/status/package.php?p=lrzip KiBi. Check the git repo. Regards, Con -- -ck -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603972: Spaces bug
I cannot reproduce this bug with newer versions of lrzip. It's possible you were hitting a different bug which has since been fixed. The latest version as of this email is 0.543 Regards, Con -- -ck -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489457: experimental does not solve stable
Wait. I don't understand how suggesting installing a package from the experimental packages is meant to be a solution for the stable release. I have this same problem on 3 standard lenny installations on different machines, all of them up to date with updates.The text works fine left to right, but as soon as I change text orientation to vertical, all the characters are invisible, and it makes no difference what font I'm using. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489457: experimental does not solve stable
Wait. I don't understand how suggesting installing a package from the experimental packages is meant to be a solution for the stable release. I have this same problem on 3 standard lenny installations on different machines, all of them up to date with updates.The text works fine left to right, but as soon as I change text orientation to vertical, all the characters are invisible, and it makes no difference what font I'm using. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489457: experimental does not solve stable
On Tue, 28 Apr 2009 17:51:23 Rene Engelhard wrote: Hi, Con Kolivas wrote: Wait. I don't understand how suggesting installing a package from the experimental packages is meant to be a solution for the stable I didn't. The only thing I did was just to mark it as fixed in the 3.0 packages. If you look at the version graph (I fixed the version info right now) you see it'll still appear as not fixed for stable. release. I have this same problem on 3 standard lenny installations on a) This bugs is closed with 3.0.0-1, which is not in experimental anymore, but followers of it are even in *testing* b) bugs get closed when the fixed package appears. It doesn't say that this is fixed in stable but says that it's fixed in the version it was closed with. It will still appear open for stable. c) it's not a (release-)critical bug, so I fear I will never get the approval to fix it in stable - expecially since we don't have a patch but just know that it works in 3.0. Thanks for explaining that. That's a massive disappointment because it's an absolute showstopper for oo.o and Japanese word processing. Furthermore, it's purely a debian bug because the oo.o packages don't have this issue, only the debian ones. I guess I have no choice but to break package management and start installing random crap again. -ck -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#306362: X window system should not renice X
Package: x-window-system Version: 4.3.0.dfsg.1-12 The X window system in Debian Sarge by default renices X to a nice level of -10. While this is mildly helpful on a 2.4 or less kernel based system it is harmful to the behaviour of a 2.6 based system with the modified O(1) cpu scheduler design making it highly likely that ordinary audio applications will underperform (skip) during periods of heavy X usage. A nice level of 0 will perform well enough with a 2.4 kernel and allows using a 2.6 kernel on a desktop gui without problems. This is modified in a number of places when multiple display managers are installed (xdm, gdm, kdm), and I believe are all fixed with dpkg reconfigure but should not use nice -10 by default. Regards, Con Kolivas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
