[PATCH 0/2] Upgrade chrpath and libevent

[PATCH 0/2] Upgrade chrpath and libevent

[Scott Garman]

Hello,

This pull request upgrades the chrpath and libevent recipes. It has
been build-tested on all 5 of our qemu architectures.

Scott

The following changes since commit c38693f78c968ab5f4bb557c20d1c8c55393ed6b:

  opkg: Fix installation order in feeds with mutiple providers of packages (2011-12-22 22:38:09 +0000)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib sgarman/recipe-upgrades-final
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=sgarman/recipe-upgrades-final

Scott Garman (2):
  chrpath: upgrade to 0.14
  libevent: upgrade to 2.0.16

 meta/recipes-devtools/chrpath/chrpath_0.13.bb     |   23 ---------------------
 meta/recipes-devtools/chrpath/chrpath_0.14.bb     |   23 +++++++++++++++++++++
 meta/recipes-support/libevent/libevent_1.4.14b.bb |   19 -----------------
 meta/recipes-support/libevent/libevent_2.0.16.bb  |   22 ++++++++++++++++++++
 4 files changed, 45 insertions(+), 42 deletions(-)
 delete mode 100644 meta/recipes-devtools/chrpath/chrpath_0.13.bb
 create mode 100644 meta/recipes-devtools/chrpath/chrpath_0.14.bb
 delete mode 100644 meta/recipes-support/libevent/libevent_1.4.14b.bb
 create mode 100644 meta/recipes-support/libevent/libevent_2.0.16.bb

-- 
1.7.5.4

[PATCH 1/2] chrpath: upgrade to 0.14

[Scott Garman]

SRC_URI changed because Debian has not started packaging v0.14 yet.
So now we're using the true upstream for sources.

Confirmed license file is still GPLv2, checksum changed due to
updated FSF postal address in COPYING.

Added HOMEPAGE and BUGTRACKER fields.

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
---
 meta/recipes-devtools/chrpath/chrpath_0.13.bb |   23 -----------------------
 meta/recipes-devtools/chrpath/chrpath_0.14.bb |   23 +++++++++++++++++++++++
 2 files changed, 23 insertions(+), 23 deletions(-)
 delete mode 100644 meta/recipes-devtools/chrpath/chrpath_0.13.bb
 create mode 100644 meta/recipes-devtools/chrpath/chrpath_0.14.bb

diff --git a/meta/recipes-devtools/chrpath/chrpath_0.13.bb b/meta/recipes-devtools/chrpath/chrpath_0.13.bb
deleted file mode 100644
index d65725e..0000000
--- a/meta/recipes-devtools/chrpath/chrpath_0.13.bb
+++ /dev/null
@@ -1,23 +0,0 @@
-SUMMARY = "Tool to edit rpath in ELF binaries"
-DESCRIPTION = "chrpath allows you to change the rpath (where the application \
-looks for libraries) in an application. It does not (yet) allow you to add an \
-rpath if there isn't one already."
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
-PR = "r3"
-
-SRC_URI = "${DEBIAN_MIRROR}/main/c/chrpath/chrpath_${PV}.orig.tar.gz \
-        file://standarddoc.patch"
-
-SRC_URI[md5sum] = "b73072a8fbba277558c50364b65bb407"
-SRC_URI[sha256sum] = "c1aa5342eac0daad81b8da05aa282ae1ccd6f68bc75ca94064304f541eed071b"
-
-inherit autotools
-
-S = "${WORKDIR}/chrpath-${PV}"
-
-# We don't have a staged chrpath-native for ensuring our binary is relocatable
-# so must use the one we've just built
-CHRPATH_BIN_virtclass-native = "${S}/chrpath"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/chrpath/chrpath_0.14.bb b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
new file mode 100644
index 0000000..679f1aa
--- /dev/null
+++ b/meta/recipes-devtools/chrpath/chrpath_0.14.bb
@@ -0,0 +1,23 @@
+SUMMARY = "Tool to edit rpath in ELF binaries"
+DESCRIPTION = "chrpath allows you to change the rpath (where the \
+application looks for libraries) in an application. It does not \
+(yet) allow you to add an rpath if there isn't one already."
+HOMEPAGE = "http://alioth.debian.org/projects/chrpath/"
+BUGTRACKER = "http://alioth.debian.org/tracker/?atid=412807&group_id=31052"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
+PR = "r0"
+
+SRC_URI = "http://alioth.debian.org/frs/download.php/3648/chrpath-${PV}.tar.gz \
+           file://standarddoc.patch"
+
+SRC_URI[md5sum] = "ea6b212b23393bf58b0ef9bcf6491b86"
+SRC_URI[sha256sum] = "a1bc9abc42d2b97efc3a0ced7c5dbed37d5debff600386193750315fa5823eaa"
+
+inherit autotools
+
+# We don't have a staged chrpath-native for ensuring our binary is
+# relocatable, so use the one we've just built
+CHRPATH_BIN_virtclass-native = "${S}/chrpath"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
1.7.5.4

[PATCH 2/2] libevent: upgrade to 2.0.16

[Scott Garman]

Updated HOMEPAGE and SRC_URI to reflect project's new home.

From the whatsnew-2.0.txt document:

COMPATIBILITY:

  Nearly all existing code that worked with Libevent 1.4 should still
  work correctly with Libevent 2.0.

So this upgrade is expected to be safe.

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
---
 meta/recipes-support/libevent/libevent_1.4.14b.bb |   19 ------------------
 meta/recipes-support/libevent/libevent_2.0.16.bb  |   22 +++++++++++++++++++++
 2 files changed, 22 insertions(+), 19 deletions(-)
 delete mode 100644 meta/recipes-support/libevent/libevent_1.4.14b.bb
 create mode 100644 meta/recipes-support/libevent/libevent_2.0.16.bb

diff --git a/meta/recipes-support/libevent/libevent_1.4.14b.bb b/meta/recipes-support/libevent/libevent_1.4.14b.bb
deleted file mode 100644
index 36468dc..0000000
--- a/meta/recipes-support/libevent/libevent_1.4.14b.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-SUMMARY = "An asynchronous event notification library"
-DESCRIPTION = "An asynchronous event notification library"
-HOMEPAGE = "http://www.monkey.org/~provos/libevent/"
-SECTION = "libs"
-
-LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://event.c;endline=26;md5=bc20aa63bf60c36c2d8edb77746f6b7c"
-
-PR = "r0"
-
-SRC_URI = "http://www.monkey.org/~provos/${BPN}-${PV}-stable.tar.gz"
-
-SRC_URI[md5sum] = "a00e037e4d3f9e4fe9893e8a2d27918c"
-SRC_URI[sha256sum] = "afa61b476a222ba43fc7cca2d24849ab0bbd940124400cb699915d3c60e46301"
-S = "${WORKDIR}/${BPN}-${PV}-stable"
-
-inherit autotools
-
-LEAD_SONAME = "libevent-1.4.so"
diff --git a/meta/recipes-support/libevent/libevent_2.0.16.bb b/meta/recipes-support/libevent/libevent_2.0.16.bb
new file mode 100644
index 0000000..6da3d94
--- /dev/null
+++ b/meta/recipes-support/libevent/libevent_2.0.16.bb
@@ -0,0 +1,22 @@
+SUMMARY = "An asynchronous event notification library"
+DESCRIPTION = "An asynchronous event notification library"
+HOMEPAGE = "http://libevent.org/"
+BUGTRACKER = "http://sourceforge.net/tracker/?group_id=50884&atid=461322"
+SECTION = "libs"
+
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=50aad300de703db62baae12146832b45"
+
+PR = "r0"
+
+SRC_URI = "http://github.com/downloads/libevent/libevent/${BPN}-${PV}-stable.tar.gz"
+
+SRC_URI[md5sum] = "899efcffccdb3d5111419df76e7dc8df"
+SRC_URI[sha256sum] = "a578c7bcaf3bab1cc7924bd4d219f2ea621ab8c51dfc4f886e234b6ef4d38295"
+
+S = "${WORKDIR}/${BPN}-${PV}-stable"
+
+inherit autotools
+
+# Needed for Debian packaging
+LEAD_SONAME = "libevent-2.0.so"
-- 
1.7.5.4

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Scott Garman]

On 12/23/2011 09:31 AM, Scott Garman wrote:
> Hello,
>
> This pull request upgrades the chrpath and libevent recipes. It has
> been build-tested on all 5 of our qemu architectures.

Please hold off on accepting this pull request. I forgot to include the 
distro tracking field updates, and when I just went to do so, I noticed 
that libevent had a NO_UPDATE_REASON field suggesting that libevent2 was 
not compatible. Which means I have to do a lot more testing on this 
before I can feel comfortable submitting it.

I will likely not get to this until I return on January 2.

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Scott Garman]

On 12/23/2011 12:42 PM, Scott Garman wrote:
> On 12/23/2011 09:31 AM, Scott Garman wrote:
>> Hello,
>>
>> This pull request upgrades the chrpath and libevent recipes. It has
>> been build-tested on all 5 of our qemu architectures.
>
> Please hold off on accepting this pull request. I forgot to include the
> distro tracking field updates, and when I just went to do so, I noticed
> that libevent had a NO_UPDATE_REASON field suggesting that libevent2 was
> not compatible. Which means I have to do a lot more testing on this
> before I can feel comfortable submitting it.
>
> I will likely not get to this until I return on January 2.

Just a note:

I did a grep for DEPENDS references to libevent in our tree and 
nfs-utils is the only recipe that lists it. I have tested building 
nfs-utils with the new libevent and there were no build errors.

Can anyone tell me if there are other applications known to use libevent 
that we include which I could do some runtime testing? If there are 
none, then I think in fact it should be safe to take this pull request.

If nothing else, the chrpath recipe upgrade commit is safe.

Thanks,

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Saul Wold]

On 12/26/2011 01:12 PM, Scott Garman wrote:
> On 12/23/2011 12:42 PM, Scott Garman wrote:
>> On 12/23/2011 09:31 AM, Scott Garman wrote:
>>> Hello,
>>>
>>> This pull request upgrades the chrpath and libevent recipes. It has
>>> been build-tested on all 5 of our qemu architectures.
>>
>> Please hold off on accepting this pull request. I forgot to include the
>> distro tracking field updates, and when I just went to do so, I noticed
>> that libevent had a NO_UPDATE_REASON field suggesting that libevent2 was
>> not compatible. Which means I have to do a lot more testing on this
>> before I can feel comfortable submitting it.
>>
>> I will likely not get to this until I return on January 2.
>
> Just a note:
>
> I did a grep for DEPENDS references to libevent in our tree and
> nfs-utils is the only recipe that lists it. I have tested building
> nfs-utils with the new libevent and there were no build errors.
>
This will probably require a PR bump for nfs-utils then.

Sau!

> Can anyone tell me if there are other applications known to use libevent
> that we include which I could do some runtime testing? If there are
> none, then I think in fact it should be safe to take this pull request.
>
> If nothing else, the chrpath recipe upgrade commit is safe.
>
> Thanks,
>
> Scott
>

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Scott Garman]

On 12/28/2011 01:37 PM, Saul Wold wrote:
> On 12/26/2011 01:12 PM, Scott Garman wrote:
>> On 12/23/2011 12:42 PM, Scott Garman wrote:
>>> On 12/23/2011 09:31 AM, Scott Garman wrote:
>>>> Hello,
>>>>
>>>> This pull request upgrades the chrpath and libevent recipes. It has
>>>> been build-tested on all 5 of our qemu architectures.
>>>
>>> Please hold off on accepting this pull request. I forgot to include the
>>> distro tracking field updates, and when I just went to do so, I noticed
>>> that libevent had a NO_UPDATE_REASON field suggesting that libevent2 was
>>> not compatible. Which means I have to do a lot more testing on this
>>> before I can feel comfortable submitting it.
>>>
>>> I will likely not get to this until I return on January 2.
>>
>> Just a note:
>>
>> I did a grep for DEPENDS references to libevent in our tree and
>> nfs-utils is the only recipe that lists it. I have tested building
>> nfs-utils with the new libevent and there were no build errors.
>>
> This will probably require a PR bump for nfs-utils then.

Are you sure? I thought this was handled automatically as long as the 
recipe in question includes the build dependency in DEPENDS, as 
nfs-utils does for libevent.

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Paul Eggleton]

On Thursday 29 December 2011 10:05:52 Scott Garman wrote:
> On 12/28/2011 01:37 PM, Saul Wold wrote:
> > This will probably require a PR bump for nfs-utils then.
> 
> Are you sure? I thought this was handled automatically as long as the
> recipe in question includes the build dependency in DEPENDS, as
> nfs-utils does for libevent.

Yes, if you want nfs-utils to be rebuilt you'll need to bump its PR. When we 
eventually move over to the PR server that won't be necessary.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Scott Garman]

On 12/29/2011 10:28 AM, Paul Eggleton wrote:
> On Thursday 29 December 2011 10:05:52 Scott Garman wrote:
>> On 12/28/2011 01:37 PM, Saul Wold wrote:
>>> This will probably require a PR bump for nfs-utils then.
>>
>> Are you sure? I thought this was handled automatically as long as the
>> recipe in question includes the build dependency in DEPENDS, as
>> nfs-utils does for libevent.
>
> Yes, if you want nfs-utils to be rebuilt you'll need to bump its PR. When we
> eventually move over to the PR server that won't be necessary.

Wow, this is really surprising to me. In all of the recipe upgrades I've 
ever previously done, I've *never* bumped the PR for all other recipes 
that list it in DEPENDS. Is this a new procedure we'll have to adopt for 
the core metadata team?

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Paul Eggleton]

On Thursday 29 December 2011 15:42:29 Scott Garman wrote:
> On 12/29/2011 10:28 AM, Paul Eggleton wrote:
> > On Thursday 29 December 2011 10:05:52 Scott Garman wrote:
> >> On 12/28/2011 01:37 PM, Saul Wold wrote:
> >>> This will probably require a PR bump for nfs-utils then.
> >> 
> >> Are you sure? I thought this was handled automatically as long as the
> >> recipe in question includes the build dependency in DEPENDS, as
> >> nfs-utils does for libevent.
> > 
> > Yes, if you want nfs-utils to be rebuilt you'll need to bump its PR.
> > When we eventually move over to the PR server that won't be necessary.
> 
> Wow, this is really surprising to me. In all of the recipe upgrades I've
> ever previously done, I've *never* bumped the PR for all other recipes
> that list it in DEPENDS. Is this a new procedure we'll have to adopt for
> the core metadata team?

It's a judgement call. If there is an ABI being provided which has changed 
incompatibly then you definitely should bump PRs of those recipes that depend 
on it. Thinking about it, it probably wouldn't be too hard to detect when the 
ABI has been broken if we wanted to put some safeguards in place.

I don't think we've been vigilant about this in the past but because people 
try not to change ABIs we get away with it most of the time. Not sure if it 
warrants any change in procedure but extra care at least can't hurt.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 0/2] Upgrade chrpath and libevent

[Saul Wold]

On 12/23/2011 09:31 AM, Scott Garman wrote:
> Hello,
>
> This pull request upgrades the chrpath and libevent recipes. It has
> been build-tested on all 5 of our qemu architectures.
>
> Scott
>
> The following changes since commit c38693f78c968ab5f4bb557c20d1c8c55393ed6b:
>
>    opkg: Fix installation order in feeds with mutiple providers of packages (2011-12-22 22:38:09 +0000)
>
> are available in the git repository at:
>    git://git.pokylinux.org/poky-contrib sgarman/recipe-upgrades-final
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=sgarman/recipe-upgrades-final
>
> Scott Garman (2):
>    chrpath: upgrade to 0.14
>    libevent: upgrade to 2.0.16
>
>   meta/recipes-devtools/chrpath/chrpath_0.13.bb     |   23 ---------------------
>   meta/recipes-devtools/chrpath/chrpath_0.14.bb     |   23 +++++++++++++++++++++
>   meta/recipes-support/libevent/libevent_1.4.14b.bb |   19 -----------------
>   meta/recipes-support/libevent/libevent_2.0.16.bb  |   22 ++++++++++++++++++++
>   4 files changed, 45 insertions(+), 42 deletions(-)
>   delete mode 100644 meta/recipes-devtools/chrpath/chrpath_0.13.bb
>   create mode 100644 meta/recipes-devtools/chrpath/chrpath_0.14.bb
>   delete mode 100644 meta/recipes-support/libevent/libevent_1.4.14b.bb
>   create mode 100644 meta/recipes-support/libevent/libevent_2.0.16.bb
>
Merged to OE-Core

Thanks
	Sau!