Upstream pbzip2 states:
> PBZIP2 is a parallel implementation of the bzip2 block-sorting file
> compressor that uses pthreads and > achieves near-linear speedup on SMP
> machines. The output of this version is fully compatible with
> bzip2 v1.0.2 or newer (ie: anything compressed with pbzip2 can
@pmatilai , Thank you for giving me the valuable comments. At that time, I
thought that we could handle the pbzip2 command with *.tar.pbz2 file extension
because the pbzip2 software uses the existing bzip2's library in order to be
compatible with bzip2. For example, using *.tar.pbz2 for
The licensing situation is solvable:
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
Short version: In Fedora, the legal team has come to the determination that the
usage is within the spirit of the licenses, if not its specific
Closed #118.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/118#event-915750694___
Rpm-maint mailing list
Like others have pointed out, this is not a feasible approach. Private
dependencies of other projects are just that: private, and we have no business
(or interest) guessing what they might be for any given project. As already
pointed out, the constructive path forward is to to get libmagic to
In the example shown
[here](https://github.com/rpm-software-management/rpm/blob/1ce844ab263bf49ee6d5145ed09e73f2c17924cc/doc/rpmsign.8#L67)
I should be able to specify a macro of `%_gpg_name Dusty Mabe
` and be able to use that. Unfortunately, i get this error
instead: