[RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

[RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

[Tom Rini]

Hey all,

In digging at some other bluez problems, I found that at least
4.91 no longer needs the sbc-thumb patch.  But without moving it to the
N versions of bluez4 we have or starting a new inc file for later bluez4
versions, there wasn't a clean way to exclude the patch.  Until now.
Borrowing the minrev/maxrev logic I added minver/maxver patch params
and tested them lightly (the patch is applied on 4.89 and not on
4.91).  I'm cc'ing Koen here because patch #3 adds 4.91 and make it
default for Angstrom, but all I've done myself is build testing.
It should be safe, based on upstream changelog tho.

-- 
Tom Rini
Mentor Graphics Corporation

[PATCH 1/3] patch.bbclass: Add minver/maxver params

[Tom Rini]

Similar to minrev/maxrev and mindate/maxdate allow us to list patches
in an inc file and only apply them in certain versions.

Signed-off-by: Tom Rini <tom_rini@mentor.com>
---
 classes/patch.bbclass |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/classes/patch.bbclass b/classes/patch.bbclass
index edfb5e9..3045719 100644
--- a/classes/patch.bbclass
+++ b/classes/patch.bbclass
@@ -102,6 +102,18 @@ python patch_do_patch() {
 				bb.note("Patch '%s' applies to earlier revisions" % pname)
 				continue
 
+		if "minver" in parm:
+			srcver = bb.data.getVar('PV', d, 1)
+			if srcver and srcver < parm["minver"]:
+				bb.note("Patch '%s' applies to later versions" % pname)
+				continue
+
+		if "maxver" in parm:
+			srcver = bb.data.getVar('PV', d, 1)
+			if srcver and srcver > parm["maxver"]:
+				bb.note("Patch '%s' applies to earlier versions" % pname)
+				continue
+
 		if "patchdir" in parm:
 			patchdir = parm["patchdir"]
 			if not os.path.isabs(patchdir):
-- 
1.7.0.4

[PATCH 2/3] bluez4.inc: List 4.90 as the maxver for applying a patch

[Tom Rini]

After 4.89 we don't need to apply sbc-thumb.patch anymore as upstream
has made a similar change.

Signed-off-by: Tom Rini <tom_rini@mentor.com>
---
 recipes/bluez/bluez4.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/recipes/bluez/bluez4.inc b/recipes/bluez/bluez4.inc
index d5b30be..12989d0 100644
--- a/recipes/bluez/bluez4.inc
+++ b/recipes/bluez/bluez4.inc
@@ -14,7 +14,7 @@ RPROVIDES_bluez4-dev = "bluez-libs-dev"
 SRC_URI = "\
   http://www.kernel.org/pub/linux/bluetooth/bluez-${PV}.tar.gz \
   file://fix-dfutool-usb-declaration-mismatch.patch \
-  file://sbc-thumb.patch \
+  file://sbc-thumb.patch;maxver=4.90 \
   file://bluetooth.conf \
 "
 S = "${WORKDIR}/bluez-${PV}"
-- 
1.7.0.4

[PATCH 3/3] bluez4: Add 4.91 and make it default for Angstrom

[Tom Rini]

Signed-off-by: Tom Rini <tom_rini@mentor.com>
---
 recipes/bluez/bluez4_4.91.bb |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)
 create mode 100644 recipes/bluez/bluez4_4.91.bb

diff --git a/recipes/bluez/bluez4_4.91.bb b/recipes/bluez/bluez4_4.91.bb
new file mode 100644
index 0000000..16f06d5
--- /dev/null
+++ b/recipes/bluez/bluez4_4.91.bb
@@ -0,0 +1,18 @@
+require bluez4.inc
+
+SRC_URI[md5sum] = "3059b7ef5168c84cd0c6a67034ce79f9"
+SRC_URI[sha256sum] = "11e9279e2669db996afd464b96d2c68f41f157f6eb9b8842a0bbcad8a4eac18d"
+
+DEFAULT_PREFERENCE = "-1"
+DEFAULT_PREFERENCE_angstrom = "1"
+
+DEPENDS += "libsndfile1"
+
+PR = "${INC_PR}.0"
+
+# Not all distros have a recent enough udev
+BTUDEV = " --disable-udevrules"
+BTUDEV_angstrom = " --enable-udevrules"
+BTUDEV_shr = " --enable-udevrules"
+
+EXTRA_OECONF += "${BTUDEV}"
-- 
1.7.0.4

Re: [PATCH 3/3] bluez4: Add 4.91 and make it default for Angstrom

[Koen Kooi]

Op 25 apr 2011, om 20:31 heeft Tom Rini het volgende geschreven:

> Signed-off-by: Tom Rini <tom_rini@mentor.com>

I ran into Marcel at ELC, which reminded me to make a recipe, but hadn't pushed it yet. Let's use your version. So:

Acked-by: Koen Kooi <koen@openembedded.org>

> ---
> recipes/bluez/bluez4_4.91.bb |   18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
> create mode 100644 recipes/bluez/bluez4_4.91.bb
> 
> diff --git a/recipes/bluez/bluez4_4.91.bb b/recipes/bluez/bluez4_4.91.bb
> new file mode 100644
> index 0000000..16f06d5
> --- /dev/null
> +++ b/recipes/bluez/bluez4_4.91.bb
> @@ -0,0 +1,18 @@
> +require bluez4.inc
> +
> +SRC_URI[md5sum] = "3059b7ef5168c84cd0c6a67034ce79f9"
> +SRC_URI[sha256sum] = "11e9279e2669db996afd464b96d2c68f41f157f6eb9b8842a0bbcad8a4eac18d"
> +
> +DEFAULT_PREFERENCE = "-1"
> +DEFAULT_PREFERENCE_angstrom = "1"
> +
> +DEPENDS += "libsndfile1"
> +
> +PR = "${INC_PR}.0"
> +
> +# Not all distros have a recent enough udev
> +BTUDEV = " --disable-udevrules"
> +BTUDEV_angstrom = " --enable-udevrules"
> +BTUDEV_shr = " --enable-udevrules"
> +
> +EXTRA_OECONF += "${BTUDEV}"
> -- 
> 1.7.0.4
> 

Re: [PATCH 3/3] bluez4: Add 4.91 and make it default for Angstrom

[Martin Jansa]

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

On Mon, Apr 25, 2011 at 11:31:13AM -0700, Tom Rini wrote:
> Signed-off-by: Tom Rini <tom_rini@mentor.com>
> ---
>  recipes/bluez/bluez4_4.91.bb |   18 ++++++++++++++++++
>  1 files changed, 18 insertions(+), 0 deletions(-)
>  create mode 100644 recipes/bluez/bluez4_4.91.bb
> 
> diff --git a/recipes/bluez/bluez4_4.91.bb b/recipes/bluez/bluez4_4.91.bb
> new file mode 100644
> index 0000000..16f06d5
> --- /dev/null
> +++ b/recipes/bluez/bluez4_4.91.bb
> @@ -0,0 +1,18 @@
> +require bluez4.inc
> +
> +SRC_URI[md5sum] = "3059b7ef5168c84cd0c6a67034ce79f9"
> +SRC_URI[sha256sum] = "11e9279e2669db996afd464b96d2c68f41f157f6eb9b8842a0bbcad8a4eac18d"
> +
> +DEFAULT_PREFERENCE = "-1"
> +DEFAULT_PREFERENCE_angstrom = "1"

please make it default for shr too, we're using bluez4_4.91 now from 
meta-oe and it works ok, so we can keep it in sync, thanks

> +
> +DEPENDS += "libsndfile1"
> +
> +PR = "${INC_PR}.0"
> +
> +# Not all distros have a recent enough udev
> +BTUDEV = " --disable-udevrules"
> +BTUDEV_angstrom = " --enable-udevrules"
> +BTUDEV_shr = " --enable-udevrules"
> +
> +EXTRA_OECONF += "${BTUDEV}"
> -- 
> 1.7.0.4
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 3/3] bluez4: Add 4.91 and make it default for Angstrom

[Paul Menzel]

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

Dear Tom,


On Mo, 2011-04-25 at 11:31 -0700, Tom Rini wrote:

what build configuration did you use for build testing? Could you add
that to the commit message please.

> Signed-off-by: Tom Rini <tom_rini@mentor.com>
> ---
>  recipes/bluez/bluez4_4.91.bb |   18 ++++++++++++++++++
>  1 files changed, 18 insertions(+), 0 deletions(-)
>  create mode 100644 recipes/bluez/bluez4_4.91.bb
> 
> diff --git a/recipes/bluez/bluez4_4.91.bb b/recipes/bluez/bluez4_4.91.bb
> new file mode 100644
> index 0000000..16f06d5
> --- /dev/null
> +++ b/recipes/bluez/bluez4_4.91.bb
> @@ -0,0 +1,18 @@
> +require bluez4.inc
> +
> +SRC_URI[md5sum] = "3059b7ef5168c84cd0c6a67034ce79f9"
> +SRC_URI[sha256sum] = "11e9279e2669db996afd464b96d2c68f41f157f6eb9b8842a0bbcad8a4eac18d"
> +
> +DEFAULT_PREFERENCE = "-1"
> +DEFAULT_PREFERENCE_angstrom = "1"
> +
> +DEPENDS += "libsndfile1"
> +
> +PR = "${INC_PR}.0"
> +
> +# Not all distros have a recent enough udev
> +BTUDEV = " --disable-udevrules"
> +BTUDEV_angstrom = " --enable-udevrules"
> +BTUDEV_shr = " --enable-udevrules"
> +
> +EXTRA_OECONF += "${BTUDEV}"

Please create the patch next time adding `-M -C -C` to `git
format-patch`. Additionally adding the recipe and making it default for
Ȧngström could have been two commits in my opinion.

Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>

I will build test with `minimal-uclibc` and report back.


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 3/3] bluez4: Add 4.91 and make it default for Angstrom

[Tom Rini]

On 04/25/2011 11:54 AM, Paul Menzel wrote:
> Dear Tom,
> 
> 
> On Mo, 2011-04-25 at 11:31 -0700, Tom Rini wrote:
> 
> what build configuration did you use for build testing? Could you add
> that to the commit message please.

Done.

>> Signed-off-by: Tom Rini <tom_rini@mentor.com>
>> ---
>>  recipes/bluez/bluez4_4.91.bb |   18 ++++++++++++++++++
>>  1 files changed, 18 insertions(+), 0 deletions(-)
>>  create mode 100644 recipes/bluez/bluez4_4.91.bb
>>
>> diff --git a/recipes/bluez/bluez4_4.91.bb b/recipes/bluez/bluez4_4.91.bb
>> new file mode 100644
>> index 0000000..16f06d5
>> --- /dev/null
>> +++ b/recipes/bluez/bluez4_4.91.bb
>> @@ -0,0 +1,18 @@
>> +require bluez4.inc
>> +
>> +SRC_URI[md5sum] = "3059b7ef5168c84cd0c6a67034ce79f9"
>> +SRC_URI[sha256sum] = "11e9279e2669db996afd464b96d2c68f41f157f6eb9b8842a0bbcad8a4eac18d"
>> +
>> +DEFAULT_PREFERENCE = "-1"
>> +DEFAULT_PREFERENCE_angstrom = "1"
>> +
>> +DEPENDS += "libsndfile1"
>> +
>> +PR = "${INC_PR}.0"
>> +
>> +# Not all distros have a recent enough udev
>> +BTUDEV = " --disable-udevrules"
>> +BTUDEV_angstrom = " --enable-udevrules"
>> +BTUDEV_shr = " --enable-udevrules"
>> +
>> +EXTRA_OECONF += "${BTUDEV}"
> 
> Please create the patch next time adding `-M -C -C` to `git
> format-patch`.

Is there a way to shove that into ~/.gitconfig?  Otherwise I'm sure to
forget.

> Additionally adding the recipe and making it default for
> Ȧngström could have been two commits in my opinion.

That's a little excessive I think, just because it's largely a given
that Angstrom (and SHR) will be opting to use this and it doesn't add
anything to the bisect'ability of the tree.

> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>

Just for this one patch I assume.

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH 3/3] bluez4: Add 4.91 and make it default for Angstrom

[Eric Bénard]

Hi

On 25/04/2011 21:05, Tom Rini wrote:
>> Please create the patch next time adding `-M -C -C` to `git
>> format-patch`.
>
> Is there a way to shove that into ~/.gitconfig?  Otherwise I'm sure to
> forget.
>
http://www.kernel.org/pub/software/scm/git/docs/git-config.html :
diff.renames

     Tells git to detect renames. If set to any boolean value, it will enable 
basic rename detection. If set to "copies" or "copy", it will detect copies, 
as well.

Eric

Re: [RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

[Frans Meulenbroeks]

2011/4/25 Tom Rini <tom_rini@mentor.com>

> Hey all,
>
> In digging at some other bluez problems, I found that at least
> 4.91 no longer needs the sbc-thumb patch.  But without moving it to the
> N versions of bluez4 we have or starting a new inc file for later bluez4
> versions, there wasn't a clean way to exclude the patch.  Until now.
> Borrowing the minrev/maxrev logic I added minver/maxver patch params
> and tested them lightly (the patch is applied on 4.89 and not on
> 4.91).  I'm cc'ing Koen here because patch #3 adds 4.91 and make it
> default for Angstrom, but all I've done myself is build testing.
> It should be safe, based on upstream changelog tho.
>
> First question should probably be: do we need 9 versions of bluez4? This is
not too much in line with the version policy the TSC once stipulated and
seems also different from the road oe-core and meta-oe are taking.

Also personally I'm not too keen on minrev/maxrev. It only makes things
again a little bit more complicated.
My preference would be to remove the patch from the .inc file and move to
the individual bb files

My 2 cents.

Frans

PS: two more cents: it seems somewhat odd that some distro's have a DP = 1
for more than one version of a recipe. While technically not wrong this
looks a little bit odd.
Also we seem to have two mechanisms to select a version for a distro. One is
the DP_distro mechanism the other one is the PREFERRED_VERSION_recipe in the
conf file
It seems to me one should be sufficient

Re: [RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

[Tom Rini]

On 04/25/2011 01:14 PM, Frans Meulenbroeks wrote:
> 2011/4/25 Tom Rini <tom_rini@mentor.com>
> 
>> Hey all,
>>
>> In digging at some other bluez problems, I found that at least
>> 4.91 no longer needs the sbc-thumb patch.  But without moving it to the
>> N versions of bluez4 we have or starting a new inc file for later bluez4
>> versions, there wasn't a clean way to exclude the patch.  Until now.
>> Borrowing the minrev/maxrev logic I added minver/maxver patch params
>> and tested them lightly (the patch is applied on 4.89 and not on
>> 4.91).  I'm cc'ing Koen here because patch #3 adds 4.91 and make it
>> default for Angstrom, but all I've done myself is build testing.
>> It should be safe, based on upstream changelog tho.
>>
>> First question should probably be: do we need 9 versions of bluez4? This is
> not too much in line with the version policy the TSC once stipulated and
> seems also different from the road oe-core and meta-oe are taking.

For bluez4 we could probably drop out 4.31, 4.41 (4.43 seems to
introduce some startup changes that might require folks to opt-in) and
then all of the post ones until 4.91, since shr and angstrom would both
depend on that.  I'd be happy to do that as a follow-up.

> Also personally I'm not too keen on minrev/maxrev. It only makes things
> again a little bit more complicated.
> My preference would be to remove the patch from the .inc file and move to
> the individual bb files

Well, maybe the better answer is a re-worked series to drop out a number
of older versions, and then it won't be bad to have the patch in a the
bb files..  Need to think about this.

> My 2 cents.
> 
> Frans
> 
> PS: two more cents: it seems somewhat odd that some distro's have a DP = 1
> for more than one version of a recipe. While technically not wrong this
> looks a little bit odd.
> Also we seem to have two mechanisms to select a version for a distro. One is
> the DP_distro mechanism the other one is the PREFERRED_VERSION_recipe in the
> conf file
> It seems to me one should be sufficient

Well, this is in part something the oe-core/meta-oe/etc policy will help
with since it does have a planned phasing out / removal of the old
version, so we would have less in the way of "add the latest .z release
and .z-1 through .z-5 just stick around).

-- 
Tom Rini
Mentor Graphics Corporation

Re: [RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

[Frans Meulenbroeks]

2011/4/25 Tom Rini <tom_rini@mentor.com>

> On 04/25/2011 01:14 PM, Frans Meulenbroeks wrote:
> > 2011/4/25 Tom Rini <tom_rini@mentor.com>
> >
> >> Hey all,
> >>
> >> In digging at some other bluez problems, I found that at least
> >> 4.91 no longer needs the sbc-thumb patch.  But without moving it to the
> >> N versions of bluez4 we have or starting a new inc file for later bluez4
> >> versions, there wasn't a clean way to exclude the patch.  Until now.
> >> Borrowing the minrev/maxrev logic I added minver/maxver patch params
> >> and tested them lightly (the patch is applied on 4.89 and not on
> >> 4.91).  I'm cc'ing Koen here because patch #3 adds 4.91 and make it
> >> default for Angstrom, but all I've done myself is build testing.
> >> It should be safe, based on upstream changelog tho.
> >>
> >> First question should probably be: do we need 9 versions of bluez4? This
> is
> > not too much in line with the version policy the TSC once stipulated and
> > seems also different from the road oe-core and meta-oe are taking.
>
> For bluez4 we could probably drop out 4.31, 4.41 (4.43 seems to
> introduce some startup changes that might require folks to opt-in) and
> then all of the post ones until 4.91, since shr and angstrom would both
> depend on that.  I'd be happy to do that as a follow-up.
>
> > Also personally I'm not too keen on minrev/maxrev. It only makes things
> > again a little bit more complicated.
> > My preference would be to remove the patch from the .inc file and move to
> > the individual bb files
>
> Well, maybe the better answer is a re-worked series to drop out a number
> of older versions, and then it won't be bad to have the patch in a the
> bb files..  Need to think about this.
>

I appreciate it if you would.
To me the analysis of what is needed seems sound.

>
> > My 2 cents.
> >
> > Frans
> >
> > PS: two more cents: it seems somewhat odd that some distro's have a DP =
> 1
> > for more than one version of a recipe. While technically not wrong this
> > looks a little bit odd.
> > Also we seem to have two mechanisms to select a version for a distro. One
> is
> > the DP_distro mechanism the other one is the PREFERRED_VERSION_recipe in
> the
> > conf file
> > It seems to me one should be sufficient
>
> Well, this is in part something the oe-core/meta-oe/etc policy will help
> with since it does have a planned phasing out / removal of the old
> version, so we would have less in the way of "add the latest .z release
> and .z-1 through .z-5 just stick around).
>

Actually the last remark was mostly triggered by the observation that
distro's have two ways to pin a recipe (and actually use both of them).
Having only one mechanism might reduce the chance of causing confusion
and/or mistakes

Frans