On 2021-01-09 Vitaly Chikunov wrote:
> Few percent of the people report bugs or misfeatures, most just adapt
> or abandon usage. For example,
>
> 1. We added -T0 to our rpm building system for xz call, and when it's
> failed (tests) the change is just reverted. Yes, we didn't gain speed
> up, but
Hello!
This sounds great but unfortunately I still haven't been able to
properly read it yet. It may take a few more days. I apologize. :-(
As a minor update from my side, I committed lzma_outq changes that I
mostly did two weeks ago. I believe it should now be usable for
threaded decompression
This would seem to be a potential candidate for a multi-release
jar[1], if you can figure out a reasonable way to get a build system
to generate one.
The 4 uses I found of comparing byte[] could be refactored to call a
new utility class to do the comparison. The "regular" implementation
could be
On 2020-12-28 Sebastian Andrzej Siewior wrote:
> xz refuses to decompress a file which has more than one hard link. It
> can be reproduced by (as per Vincent):
> |$ echo foo > file1
> |$ xz file1
> |$ ln file1.xz file2.xz
> |$ xz -dk file1.xz
> |xz: file1.xz: Input file has more than one hard
On 2021-01-08 Lasse Collin wrote:
> It's tempting to ignore exit statuses >= 128 at the end of the script
> where it current checks for "$xz_status" -eq 0 but that doesn't work
> because in the middle of the script there is also this:
>
> case $xz_status in
> *[1-9]*)
Hi,
On Fri, Jan 08, 2021 at 06:40:18PM +0200, Lasse Collin wrote:
> On 2020-12-26 Sebastian Andrzej Siewior wrote:
> > On 2020-12-26 09:33:04 [+0300], Vitaly Chikunov wrote:
> > > This wasn't working, because `memlimit_compress` initialized with
> > > zero, thus memory limit is never lowered for
