$ rpm2cpio kdelibs3-3.5.5-39.i586.rpm | zstd -c --single-thread | wc -c
16307922
$ rpm2cpio kdelibs3-3.5.5-39.i586.rpm | zstd -c -T1 | wc -c
16308523
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hmm, I don't think ZSTDMT_compress_advanced_internal is used in out use case,
so disregard the comment about the influence of the thread number. (I'm not
100% sure, though, the zstd source code is somewhat cryptic to me.)
--
You are receiving this because you are subscribed to this thread.
Possibly related: https://github.com/rpm-software-management/rpm/issues/1304
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Had a quick chat on IRC with @ffesti and he said it's actually just three
outcomes that rpmbuild may return; success (0), error (1) or missing build deps
(11), in which case adding all three into the man page would be worthwhile.
I'll skim through the code to double-check and go ahead with
Also note that threading mode with one thread (T1) is *not* unthreaded mode.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
But was it identical? Zstd upstream said that it is different.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> it compresses a bit worse
I was testing it on xonotic-data and it was 873M in single-threaded compression
and the same size in multi-threaded mode.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'm also not so sure about the "the multi-threaded output produces the same
compressed data no matter how many threads you use" statement, because the
block size seems to depend on the number of workers (see
ZSTDMT_compress_advanced_internal).
--
You are receiving this because you are
Note that the zstd people *did* say that threaded compression has a different
output than unthreaded operation: it compresses a bit worse. So the pull
request will break delta rpms.
Can you please change the code so that it uses unthreaded mode if there is no
'T' in the compression flags? I.e.
Actually looking closely at the `rpmbuild(8)` man page, it seems we don't
specify any exit codes there at the moment. So I'm wondering if it really is
worth documenting them for this particular use case (`-br --nodeps`) only.
There could be a separate section called `EXIT CODES` or similar
10 matches
Mail list logo
