Patchwork [0/2] Upgrade chrpath and libevent

login
register
mail settings
Submitter Scott Garman
Date Dec. 23, 2011, 5:31 p.m.
Message ID <cover.1324661415.git.scott.a.garman@intel.com>
Download mbox
Permalink /patch/17585/
State New
Headers show

Pull-request

git://git.pokylinux.org/poky-contrib sgarman/recipe-upgrades-final

Comments

Scott Garman - Dec. 23, 2011, 5:31 p.m.
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
Scott Garman - Dec. 23, 2011, 5:42 p.m.
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 - Dec. 26, 2011, 9:12 p.m.
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
Saul Wold - Dec. 28, 2011, 6:37 p.m.
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
>
Scott Garman - Dec. 29, 2011, 3:05 p.m.
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
Paul Eggleton - Dec. 29, 2011, 3:28 p.m.
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
Scott Garman - Dec. 29, 2011, 8:42 p.m.
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
Paul Eggleton - Dec. 29, 2011, 10:06 p.m.
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
Saul Wold - Jan. 4, 2012, 12:02 a.m.
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!