Skip to contentSkip to conversation

Upgrade chrpath and libevent

PATCH Applied Scott Garman 3 participants 11 messages Dec 23, 2011 – Jan 4, 2012

lore
Share & tools
lore

Scott Garman

author
#0 lore raw

cover Upgrade chrpath and libevent

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
Signature · 1 line
1.7.5.4
author
#1 lore raw

PATCH 1/2 chrpath: upgrade to 0.14

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 <[email protected]>
---
 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
meta/recipes-devtools/chrpath/chrpath_0.13.bb deleted +0 -23
deleted file mode 100644
index d65725e..0000000
@@ -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"
meta/recipes-devtools/chrpath/chrpath_0.14.bb new file +23 -0
new file mode 100644
index 0000000..679f1aa
@@ -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"
Signature · 1 line
1.7.5.4
author
#2 lore raw

PATCH 2/2 libevent: upgrade to 2.0.16

In reply to 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 <[email protected]>
---
 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
meta/recipes-support/libevent/libevent_1.4.14b.bb deleted +0 -19
deleted file mode 100644
index 36468dc..0000000
@@ -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"
meta/recipes-support/libevent/libevent_2.0.16.bb new file +22 -0
new file mode 100644
index 0000000..6da3d94
@@ -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"
Signature · 1 line
1.7.5.4
author
#3 lore raw
In reply to Scott Garman
Quoted 4 lines · Scott Garman

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

Signature · 3 lines
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
author
#4 lore raw
Quoted 6 lines · Scott Garman
Quoted 4 lines · Scott Garman

Hello,

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

Quoted 7 lines

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

Signature · 3 lines
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
#5 lore raw
Quoted 13 lines · Scott Garman
Quoted 12 lines · Scott Garman
Quoted 4 lines · Scott Garman

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.

Quoted 8 lines
Quoted 1 line

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!

Quoted 10 lines

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

author
#6 lore raw
Quoted 16 lines · Saul Wold
Quoted 15 lines · Scott Garman
Quoted 13 lines · Scott Garman
Quoted 4 lines · Scott Garman

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.

Quoted 7 lines
Quoted 6 lines

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

Signature · 3 lines
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
#7 lore raw
Quoted 6 lines · On Thursday 29 December 2011 10:05:52 Scott Garman wrote:
Quoted 1 line · Saul Wold

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

Signature · 2 lines
Paul Eggleton
Intel Open Source Technology Centre
author
#8 lore raw
Quoted 10 lines · Paul Eggleton
Quoted 6 lines · On Thursday 29 December 2011 10:05:52 Scott Garman wrote:
Quoted 1 line · Saul Wold

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

Signature · 3 lines
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
#9 lore raw
Quoted 9 lines · On Thursday 29 December 2011 15:42:29 Scott Garman wrote:
Quoted 8 lines · Paul Eggleton
Quoted 6 lines · On Thursday 29 December 2011 10:05:52 Scott Garman wrote:
Quoted 1 line · Saul Wold

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.

Quoted 7 lines
Quoted 2 lines

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

Signature · 2 lines
Paul Eggleton
Intel Open Source Technology Centre
Applied
#10 lore raw
In reply to Scott Garman
Quoted 24 lines · 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(-)
Quoted 5 lines

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!