public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] pixz: Add 1.0.6
Date: Mon, 11 Jan 2016 16:17:25 -0800	[thread overview]
Message-ID: <07532094-8D88-49CD-8CF2-42C0F2B46CA4@gmail.com> (raw)
In-Reply-To: <1452555303.28375.1.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]


> On Jan 11, 2016, at 3:35 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Mon, 2016-01-11 at 15:21 -0800, Khem Raj wrote:
>>> On Jan 11, 2016, at 2:36 PM, Paul Eggleton <
>>> paul.eggleton@linux.intel.com> wrote:
>>> 
>>> On Mon, 11 Jan 2016 13:17:14 Khem Raj wrote:
>>>>> On Jan 11, 2016, at 1:07 PM, Paul Eggleton <
>>>>> paul.eggleton@linux.intel.com>
>>>>> wrote:>
>>>>> On Mon, 11 Jan 2016 09:36:36 Paul Eggleton wrote:
>>>>>> On Mon, 11 Jan 2016 09:26:39 Paul Eggleton wrote:
>>>>>>> On Fri, 08 Jan 2016 18:22:49 Richard Purdie wrote:
>>>>>>>> xz gives better compression results than bzip/gz but is
>>>>>>>> often slower.
>>>>>>>> Using parallel compression mitigates this somewhat and is
>>>>>>>> particularly
>>>>>>>> useful for the SDK.
>>>>>>>> 
>>>>>>>> Signed-off-by: Richard Purdie <
>>>>>>>> richard.purdie@linuxfoundation.org>
>>>>>>>> 
>>>>>>>> diff --git a/meta/recipes-support/pixz/pixz_1.0.6.bb
>>>>>>>> b/meta/recipes-support/pixz/pixz_1.0.6.bb new file mode
>>>>>>>> 100644
>>>>>>>> index 0000000..e6e4ac2
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/meta/recipes-support/pixz/pixz_1.0.6.bb
>>>>>>>> @@ -0,0 +1,14 @@
>>>>>>>> +SUMMARY = "Parallel, indexed xz compressor"
>>>>>>>> +
>>>>>>>> +DEPENDS = "xz libarchive"
>>>>>>>> +
>>>>>>>> +SRC_URI =
>>>>>>>> "https://github.com/vasi/pixz/releases/download/v${PV}/${
>>>>>>>> BPN}-${PV}.tar
>>>>>>>> .
>>>>>>>> xz
>>>>>>>> "
>>>>>>> 
>>>>>>> Can we rely on this never changing? I thought we'd
>>>>>>> experienced problems
>>>>>>> with github's release tarballs being generated on the fly
>>>>>>> in the past...
>>>>>> 
>>>>>> Another thing, this seems to fail to build without asciidoc:
>>>>>> 
>>>>>> ------------ snip ------------
>>>>>> checking for src/pixz.1... no
>>>>>> checking for a2x... no
>>>>>> configure: error: AsciiDoc not found, not able to generate
>>>>>> the man page.
>>>>>> ------------ snip ------------
>>>>>> 
>>>>>> This is also related to not supporting B != S, since
>>>>>> src/pixz.1 does
>>>>>> exist,
>>>>>> just in S and not B. If you inherit autotools-brokensep
>>>>>> instead of
>>>>>> autotools it works.
>>>>> 
>>>>> Possibly a bit obvious, but even inheriting autotools-brokensep
>>>>> isn't
>>>>> enough, because if it runs "make clean" on re-executing
>>>>> do_configure,
>>>>> src/pixz.1 gets deleted and you get the same issue.
>>>> 
>>>> Adding --without-manpage might get you past this issue.
>>> 
>>> I'm afraid that's not a valid option for this configure script.
>>> 
>>> I had more shenanigans trying to build the target version. In the
>>> end I needed
>>> to add "ac_cv_file_src_pixz_1=yes" to EXTRA_OECONF and inherit
>>> pkgconfig.
>>> 
>> 
>> I think you are missing
>> https://github.com/vasi/pixz/commit/936d8068ae19d95260d3058f41dd6cf71
>> 8101cd6
>> 
>> which is committed after 1.0.6 release. It should be back ported.
>> may be not use tarball but straight use
>> SRCREV=“936d8068ae19d95260d3058f41dd6cf718101cd6”
>> with git fetcher might be better.
> 
> As Randy mentions, should we use the -T option to xz instead though?

that might be ok too

xz /tmp/xx.tar  19.65s user 0.07s system 100% cpu 19.714 total
XZ_DEFAULTS="-T 0" xz /tmp/xx.tar  22.35s user 0.49s system 360% cpu 6.340 total
pixz /tmp/xx.tar /tmp/xx.tar.xz  26.56s user 0.45s system 456% cpu 5.917 total

a little slower than pixz and doesnt seem to use all cores with pixz I had 450% CPU on same load.

using pixz is simpler though. It can also be called integrated with tar. for XZ we need to set this env
variable to enable parallelism with pixz its not needed.

> 
> Cheers,
> 
> Richard


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

  reply	other threads:[~2016-01-12  0:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 18:22 [PATCH] pixz: Add 1.0.6 Richard Purdie
2016-01-09 17:14 ` Khem Raj
2016-01-11 18:37   ` Andre McCurdy
2016-01-10 20:26 ` Paul Eggleton
2016-01-10 20:36   ` Paul Eggleton
2016-01-11 21:07     ` Paul Eggleton
2016-01-11 21:17       ` Khem Raj
2016-01-11 22:36         ` Paul Eggleton
2016-01-11 23:07           ` Khem Raj
2016-01-11 23:21           ` Khem Raj
2016-01-11 23:35             ` Richard Purdie
2016-01-12  0:17               ` Khem Raj [this message]
2016-01-11 13:37   ` Burton, Ross
2016-01-11 18:52 ` Randy Witt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=07532094-8D88-49CD-8CF2-42C0F2B46CA4@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox