Patchworkβ [oe,8/8] xz: add xz package

login
register
about
Submitter Bernhard Reutner-Fischer
Date 2010-02-13 12:51:46
Message ID <20100213125146.GJ10632@mx.loc>
Download mbox | patch
Permalink /patch/1587/
State Applied, archived
Headers show

Comments

Bernhard Reutner-Fischer - 2010-02-13 12:51:46
On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote:
>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote:
>> xz is the lzma successor
>> tested with automake-1.11.1, autoconf-2.65
>
>Thanks for the patch.  I think this could use a little cleanup before it
>is committed, though; please see below.

I flagged it as RFC in the summary, so yes, like the summary said, still
needs love..
>
>> index 0000000..bc5e9ff
>> --- /dev/null
>> +++ b/recipes/xz/xz-native.inc
>> @@ -0,0 +1,2 @@
>> +inherit native
>> +require xz_${PV}.bb
>
>You could consider using BBCLASSEXTEND to eliminate the need for this
>separate recipe.

Thanks for that, good thing. This will trim down alot on the number of
recipes in the tree!
>
>> diff --git a/recipes/xz/xz-native_4.999.9beta.bb b/recipes/xz/xz-native_4.999.9beta.bb
>> new file mode 100644
>> index 0000000..c4f0da9
>> --- /dev/null
>> +++ b/recipes/xz/xz-native_4.999.9beta.bb
>> @@ -0,0 +1,3 @@
>> +PV = "4.999.9beta"
>> +
>> +require xz-native.inc
>
>Is it necessary to set PV here?  I would have thought base.bbclass would
>infer that same value from the filename.

It was needed since above xz-native.inc had
require xz_${PV}.inc
in it, and if i didn't set PV before it, it defaulted to 1.0, breaking
horribly for obvious reasons. BBCLASSEXTEND nullifies this. Ditched.
>
>> diff --git a/recipes/xz/xz-native_git.bb b/recipes/xz/xz-native_git.bb
>> new file mode 100644
>> index 0000000..006b9d7
>> --- /dev/null
>> +++ b/recipes/xz/xz-native_git.bb
>> @@ -0,0 +1,7 @@
>> +# XZ_BASE should be the latest released version of xz.
>> +# It can be set in the distro file.
>> +#XZ_BASE ?= "4.999.9"
>> +#SRCREV = "HEAD"
>> +#PV = "${XZ_BASE}+gitr${SRCREV}"
>
>Please don't leave this sort of stuff commented out in the file.  If
>it's not needed, just delete those lines.

dropped.
>
>> +#FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/xz-${PV}"
>
>Likewise for that.

ditto (RFC..)
>
>> --- /dev/null
>> +++ b/recipes/xz/xz_4.999.9beta.bb
>> @@ -0,0 +1,8 @@
>> +PV = "4.999.9beta"
>
>See above regarding PV.
>
>> +
>> +require xz.inc
>> +PR = "${INC_PR}.0"
>> +SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz"
>
>Wouldn't that SRC_URI be better in the .inc file?  Presumably this is
>the correct URI for everything except the _git version.

It would indeed. Can i somehow say
file1: SRC="http:://one.ext/one.tar.xz"
       SRC[md5sum]=md5
       SRC[sha256sum]=sha256
       or, perhaps it's the basename if there was no ;name=
       SRC[one.tar.xz.md5sum]=md5
       SRC[one.tar.xz.sha256sum]=sha256
file2: SRC="git://two"
inc: FOO_SRC ?= SRC
     SRC_URI += FOO_SRC

?
>
>> +SRC_URI[xz.md5sum] = "cc4044fcc073b8bcf3164d1d0df82161"
>> +SRC_URI[xz.sha256sum] = "330312c4397608d8b7be362cc7edbfeafa6101614bc2164d816ea767656aa15c"
>> +EXTRA_OECONF = "--enable-shared"
>
>Likewise for that EXTRA_OECONF, I would have thought that would also
>belong in the .inc really.

the EXTRA_OECONF can. Done.
Revised patch is attached, but:
it works for the 4.999beta9 version (literally, since that's how
upstream calls the tarball; Is this a problem with the version-naming
like Koon indicates?) but not if you
PREFERRED_VERSION_xz = "git"
PREFERRED_VERSION_xz-native = "git"
and then bake xz-native:
NOTE: Task failed: Fetch failed: [snip]; git read-tree 1 failed with
signal 128, output:
fatal: Not a valid object name 1

since: $ ls -a ../sources/git/ctrl.tukaani.org.xz.git/
.  ..  1  .git

"1" ?!
Phil Blundell - 2010-02-13 13:19:29
On Sat, 2010-02-13 at 13:51 +0100, Bernhard Reutner-Fischer wrote:
> It would indeed. Can i somehow say
> file1: SRC="http:://one.ext/one.tar.xz"
>        SRC[md5sum]=md5
>        SRC[sha256sum]=sha256
>        or, perhaps it's the basename if there was no ;name=
>        SRC[one.tar.xz.md5sum]=md5
>        SRC[one.tar.xz.sha256sum]=sha256
> file2: SRC="git://two"
> inc: FOO_SRC ?= SRC
>      SRC_URI += FOO_SRC

I don't think this needs to be as complicated as you are making it.  You
should be able to simply move your original SRC_URI verbatim to the .inc
file, i.e.:

SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz"

and then, in the individual .bb files for each version, write:

SRC_URI[xz.md5sum] = ...

There's no requirement for the two things to be in the same file.  If
you need to add other things like patches to the SRC_URI for a specific
version, you can just write:

SRC_URI += "file://..."

in the .bb file in question.

> Revised patch is attached, but:
> it works for the 4.999beta9 version (literally, since that's how
> upstream calls the tarball; Is this a problem with the version-naming
> like Koon indicates?) 

It rather depends on what upstream are going to do next.  If "4.999" is
the number that they are using for pre-releases leading up to 5.0, and
everything in the 4.999 series is going to be a beta (i.e. they do
4.999.8beta, 4.999.9beta, 4.999.10beta, 5.0) then it is probably fine as
it stands.  But, if there is any risk that "4.999.9beta" might be
followed at some point by a version called just "4.999.9", or even
"4.999", then that would be a problem because the latter version will
sort lower than the former.

> since: $ ls -a ../sources/git/ctrl.tukaani.org.xz.git/
> .  ..  1  .git
> 
> "1" ?!

That is rather weird.  I can't see any obvious cause for that from a
quick inspection of the files you attached.

p.
Bernhard Reutner-Fischer - 2010-02-13 14:37:25
On Sat, Feb 13, 2010 at 01:19:29PM +0000, Phil Blundell wrote:
>On Sat, 2010-02-13 at 13:51 +0100, Bernhard Reutner-Fischer wrote:
>> It would indeed. Can i somehow say
>> file1: SRC="http:://one.ext/one.tar.xz"
>>        SRC[md5sum]=md5
>>        SRC[sha256sum]=sha256
>>        or, perhaps it's the basename if there was no ;name=
>>        SRC[one.tar.xz.md5sum]=md5
>>        SRC[one.tar.xz.sha256sum]=sha256
>> file2: SRC="git://two"
>> inc: FOO_SRC ?= SRC
>>      SRC_URI += FOO_SRC
>
>I don't think this needs to be as complicated as you are making it.  You
>should be able to simply move your original SRC_URI verbatim to the .inc
>file, i.e.:
>
>SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz"
>
>and then, in the individual .bb files for each version, write:
>
>SRC_URI[xz.md5sum] = ...
>
>There's no requirement for the two things to be in the same file.  If
>you need to add other things like patches to the SRC_URI for a specific
>version, you can just write:
>
>SRC_URI += "file://..."
>
>in the .bb file in question.

But that would clash with _git, wouldn't it, unless, and only if this
exact sequence would be used:
.inc:=S ?= ${WORKDIR}/xz-${PV}
.inc:=SRC_URI=http
0815.bb:PV=0814+0815foo
0815.bb:require .inc
0815.bb:SRC_URI+=patch1
git.bb:S=${WORKDIR}/git
git.bb:require .inc
git.bb:SRC_URI=git

which we can obey to in this case, but it somehow feels brittle altough
it should work out fine in practise, i think.
>
>> Revised patch is attached, but:
>> it works for the 4.999beta9 version (literally, since that's how
>> upstream calls the tarball; Is this a problem with the version-naming
>> like Koon indicates?) 
>
>It rather depends on what upstream are going to do next.  If "4.999" is
>the number that they are using for pre-releases leading up to 5.0, and
>everything in the 4.999 series is going to be a beta (i.e. they do
>4.999.8beta, 4.999.9beta, 4.999.10beta, 5.0) then it is probably fine as
>it stands.  But, if there is any risk that "4.999.9beta" might be
>followed at some point by a version called just "4.999.9", or even
>"4.999", then that would be a problem because the latter version will
>sort lower than the former.

ACK, exactly. I follow Koon on this.
>
>> since: $ ls -a ../sources/git/ctrl.tukaani.org.xz.git/
>> .  ..  1  .git
>> 
>> "1" ?!
>
>That is rather weird.  I can't see any obvious cause for that from a
>quick inspection of the files you attached.

Just try it out, that package shouldn't interfere with any existing
recipe.
To my untrained eyes it sounds like a glitch somewhere in infrastructure
and not in those recipes, but YMV alot from mine in this respect :)
Insights?

TIA && cheers,
Bernhard
Bernhard Reutner-Fischer - 2010-02-13 16:14:49
On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote:
>On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote:
>>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote:
>>> index 0000000..bc5e9ff
>>> --- /dev/null
>>> +++ b/recipes/xz/xz-native.inc
>>> @@ -0,0 +1,2 @@
>>> +inherit native
>>> +require xz_${PV}.bb
>>
>>You could consider using BBCLASSEXTEND to eliminate the need for this
>>separate recipe.
>
>Thanks for that, good thing. This will trim down alot on the number of
>recipes in the tree!

AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could
convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is
mentioned in there) will/would break AFAICT, is that correct?
Phil Blundell - 2010-02-13 18:46:59
On Sat, 2010-02-13 at 15:37 +0100, Bernhard Reutner-Fischer wrote:
> But that would clash with _git, wouldn't it, unless, and only if this
> exact sequence would be used:
> .inc:=S ?= ${WORKDIR}/xz-${PV}
> .inc:=SRC_URI=http
> 0815.bb:PV=0814+0815foo
> 0815.bb:require .inc
> 0815.bb:SRC_URI+=patch1
> git.bb:S=${WORKDIR}/git
> git.bb:require .inc
> git.bb:SRC_URI=git

It would be more traditional to set S with a hard assignment in the .inc
file, and simply override it (the same as SRC_URI) in the _git.bb file.
But, essentially, yes, what you are describing there is basically what
you'd have to do.  There is plenty of precedent in OE for the general
approach of using an .inc file to set generic defaults and then allowing
particular .bb files to override the parts they don't want.

I'll have a look at your git checkout issue later today.

p.
Tom Rini - 2010-02-25 00:49:35
On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote:
> On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote:
> >On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote:
> >>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote:
> >>> index 0000000..bc5e9ff
> >>> --- /dev/null
> >>> +++ b/recipes/xz/xz-native.inc
> >>> @@ -0,0 +1,2 @@
> >>> +inherit native
> >>> +require xz_${PV}.bb
> >>
> >>You could consider using BBCLASSEXTEND to eliminate the need for this
> >>separate recipe.
> >
> >Thanks for that, good thing. This will trim down alot on the number of
> >recipes in the tree!
> 
> AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could
> convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is
> mentioned in there) will/would break AFAICT, is that correct?

Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers
-native (and not -cross, -cross-sdk/-sdk nor -canadian*).
Bernhard Reutner-Fischer - 2010-02-25 07:41:12
Canadian seems to be deprecated in favour of nativesdk (which is handled by
BBCLASSEXTEND), so I will try use that instead.

On 25 Feb 2010 01:50, "Tom Rini" <tom_rini@mentor.com> wrote:

On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote:
> On Sat, Feb 13, 2010 at 01:51:4...
Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers
-native (and not -cross, -cross-sdk/-sdk nor -canadian*).

--
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation
Richard Purdie - 2010-02-25 10:39:48
On Wed, 2010-02-24 at 17:49 -0700, Tom Rini wrote:
> On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote:
> > On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote:
> > >On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote:
> > >>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote:
> > >>> index 0000000..bc5e9ff
> > >>> --- /dev/null
> > >>> +++ b/recipes/xz/xz-native.inc
> > >>> @@ -0,0 +1,2 @@
> > >>> +inherit native
> > >>> +require xz_${PV}.bb
> > >>
> > >>You could consider using BBCLASSEXTEND to eliminate the need for this
> > >>separate recipe.
> > >
> > >Thanks for that, good thing. This will trim down alot on the number of
> > >recipes in the tree!
> > 
> > AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could
> > convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is
> > mentioned in there) will/would break AFAICT, is that correct?
> 
> Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers
> -native (and not -cross, -cross-sdk/-sdk nor -canadian*).

BBCLASSEXTEND covers -native and -nativesdk

The -cross, -crosssdk, -canadian-cross and other combinations usually
have too many differences to be worth the effort although it would be
possible to make them work.

Cheers,

Richard
Richard Purdie - 2010-02-25 10:40:29
On Thu, 2010-02-25 at 08:41 +0100, Bernhard Reutner-Fischer wrote:
> Canadian seems to be deprecated in favour of nativesdk (which is handled by
> BBCLASSEXTEND), so I will try use that instead.

Yes, -nativesdk is intended to replace -sdk packages

Cheers,

Richard
Tom Rini - 2010-02-25 17:21:07
On Thu, 2010-02-25 at 10:39 +0000, Richard Purdie wrote:
> On Wed, 2010-02-24 at 17:49 -0700, Tom Rini wrote:
> > On Sat, 2010-02-13 at 17:14 +0100, Bernhard Reutner-Fischer wrote:
> > > On Sat, Feb 13, 2010 at 01:51:46PM +0100, Bernhard Reutner-Fischer wrote:
> > > >On Thu, Feb 11, 2010 at 12:53:01PM +0000, Phil Blundell wrote:
> > > >>On Wed, 2010-02-10 at 21:13 +0100, Bernhard Reutner-Fischer wrote:
> > > >>> index 0000000..bc5e9ff
> > > >>> --- /dev/null
> > > >>> +++ b/recipes/xz/xz-native.inc
> > > >>> @@ -0,0 +1,2 @@
> > > >>> +inherit native
> > > >>> +require xz_${PV}.bb
> > > >>
> > > >>You could consider using BBCLASSEXTEND to eliminate the need for this
> > > >>separate recipe.
> > > >
> > > >Thanks for that, good thing. This will trim down alot on the number of
> > > >recipes in the tree!
> > > 
> > > AFAICS BBCLASSEXTEND does not take canadian into account ATM, so i could
> > > convert mpfr without pain but gmp-canadian on darwin (at least 4.2.4 is
> > > mentioned in there) will/would break AFAICT, is that correct?
> > 
> > Since I didn't see a reply... at current, yes BBLCASSEXTEND only covers
> > -native (and not -cross, -cross-sdk/-sdk nor -canadian*).
> 
> BBCLASSEXTEND covers -native and -nativesdk

Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or
just not merged yet?

> The -cross, -crosssdk, -canadian-cross and other combinations usually
> have too many differences to be worth the effort although it would be
> possible to make them work.

I'm not so sure about that, but we'll see.  I should have some form of
canadian stuff working again shortly.
C Michael Sundius - 2010-02-25 18:18:15
can someone explain what BBCLASSEXTEND does... sorry for the rookie
question.
Richard Purdie - 2010-02-25 20:16:21
On Thu, 2010-02-25 at 10:21 -0700, Tom Rini wrote:
> > BBCLASSEXTEND covers -native and -nativesdk
> 
> Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or
> just not merged yet?

It should be implicit in the anonfuncs. If that class differs to Poky,
the Poky changes should be merged though.

> > The -cross, -crosssdk, -canadian-cross and other combinations usually
> > have too many differences to be worth the effort although it would be
> > possible to make them work.
> 
> I'm not so sure about that, but we'll see.  I should have some form of
> canadian stuff working again shortly.

You're unsure it would be possible to make them work of that its not
worth the effort?

Cheers,

Richard
Bernhard Reutner-Fischer - 2010-05-28 08:37:34
On Thu, Feb 25, 2010 at 08:16:21PM +0000, Richard Purdie wrote:
>On Thu, 2010-02-25 at 10:21 -0700, Tom Rini wrote:
>> > BBCLASSEXTEND covers -native and -nativesdk
>> 
>> Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or
>> just not merged yet?
>
>It should be implicit in the anonfuncs. If that class differs to Poky,
>the Poky changes should be merged though.
>
>> > The -cross, -crosssdk, -canadian-cross and other combinations usually
>> > have too many differences to be worth the effort although it would be
>> > possible to make them work.
>> 
>> I'm not so sure about that, but we'll see.  I should have some form of
>> canadian stuff working again shortly.
>
>You're unsure it would be possible to make them work of that its not
>worth the effort?

Tom?

Yesterday evening i was building a pristine master reference again and
saw that mpfr et al are (still) pretty outdated.
AFAIR i cannot mix BBCLASSEXTEND vs. old-fashioned recipes for one
package (didn't try if that's still true) so i'm, again, running into
the issue of what to do with older toolchains needing that canadian
stuff. I'm not too jazzed about the idea to touch the old toolchains
just because i want to have current gmp/mpc/mpfr/gcc (using CLASSEXTEND
nativesdk). So, how to proceed?

cheers,
Tom Rini - 2010-06-01 18:41:02
Bernhard Reutner-Fischer wrote:
> On Thu, Feb 25, 2010 at 08:16:21PM +0000, Richard Purdie wrote:
>> On Thu, 2010-02-25 at 10:21 -0700, Tom Rini wrote:
>>>> BBCLASSEXTEND covers -native and -nativesdk
>>> Is the -nativesdk part implicit in the anonfuncs in nativesdk.bbclass or
>>> just not merged yet?
>> It should be implicit in the anonfuncs. If that class differs to Poky,
>> the Poky changes should be merged though.
>>
>>>> The -cross, -crosssdk, -canadian-cross and other combinations usually
>>>> have too many differences to be worth the effort although it would be
>>>> possible to make them work.
>>> I'm not so sure about that, but we'll see.  I should have some form of
>>> canadian stuff working again shortly.
>> You're unsure it would be possible to make them work of that its not
>> worth the effort?
> 
> Tom?
> 
> Yesterday evening i was building a pristine master reference again and
> saw that mpfr et al are (still) pretty outdated.
> AFAIR i cannot mix BBCLASSEXTEND vs. old-fashioned recipes for one
> package (didn't try if that's still true) so i'm, again, running into
> the issue of what to do with older toolchains needing that canadian
> stuff. I'm not too jazzed about the idea to touch the old toolchains
> just because i want to have current gmp/mpc/mpfr/gcc (using CLASSEXTEND
> nativesdk). So, how to proceed?

So, where things stand right now (and have stood for a while) is that 
the existing canadian recipes simply don't work.  We've made them work 
internally, and then moved them up to using nativesdk/etc.  That's also 
been finished and the engineer in question is now working on making it 
work in OE.dev.  But for now, don't let the existing canadian stuff 
(which is broken) get in the way of fixing up other stuff.

Patch

diff --git a/recipes/xz/xz.inc b/recipes/xz/xz.inc
new file mode 100644
index 0000000..cc4f966
--- /dev/null
+++ b/recipes/xz/xz.inc
@@ -0,0 +1,9 @@ 
+DESCRIPTION = "XZ Utils is free general-purpose data compression software with high compression ratio.  XZ Utils are the successor to LZMA Utils."
+SECTION = "console/utils"
+LICENSE = "Public Domain"
+INC_PR = "r0"
+S ?= "${WORKDIR}/xz-${PV}"
+EXTRA_OECONF = "--enable-shared"
+BBCLASSEXTEND = "native"
+
+inherit autotools
diff --git a/recipes/xz/xz_4.999.9beta.bb b/recipes/xz/xz_4.999.9beta.bb
new file mode 100644
index 0000000..8733023
--- /dev/null
+++ b/recipes/xz/xz_4.999.9beta.bb
@@ -0,0 +1,5 @@ 
+require xz.inc
+PR = "${INC_PR}.0"
+SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz"
+SRC_URI[xz.md5sum] = "cc4044fcc073b8bcf3164d1d0df82161"
+SRC_URI[xz.sha256sum] = "330312c4397608d8b7be362cc7edbfeafa6101614bc2164d816ea767656aa15c"
diff --git a/recipes/xz/xz_git.bb b/recipes/xz/xz_git.bb
new file mode 100644
index 0000000..8950a08
--- /dev/null
+++ b/recipes/xz/xz_git.bb
@@ -0,0 +1,6 @@ 
+S = "${WORKDIR}/git"
+require xz.inc
+PV = "git"
+PR = "${INC_PR}.0"
+SRC_URI = "git://ctrl.tukaani.org/xz.git;branch=master;protocol=git"
+DEFAULT_PREFERENCE = "-1"