Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

[Martin Jansa]

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

On Wed, Jan 16, 2013 at 11:58:00AM +0000, git@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: 3c927c39502061bdf3ef9fba1f0f6e7080f6c3cd
> URL:    http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=3c927c39502061bdf3ef9fba1f0f6e7080f6c3cd
> 
> Author: Tom Zanussi <tom.zanussi@intel.com>
> Date:   Fri Jan 11 17:28:47 2013 -0600
> 
> lttng2-ust: rename to lttng-ust
> 
> recipes-kernel/lttng/lttng-ust was removed by a previous patch, which
> also removed the naming conflict that caused the lttng-2.0 version of
> lttng-ust to be named lttng2-ust.  lttng2-ust was the only lttng-2.0
> recipe to be named in this way and since that was entirely due to the
> conflict, we can go back to the consistent naming for it.
> 
> Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> Signed-off-by: Saul Wold <sgw@linux.intel.com>

lttng-ust had PE="1", bump PE to fix upgrade path:

ERROR: Package version for package lttng-ust-dbg went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-staticdev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-dev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-doc went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust-locale went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
ERROR: Package version for package lttng-ust went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)

> 
> ---
> 
>  .../packagegroup-core-tools-profile.bb             |    2 +-
>  meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb |    2 +-
>  .../{lttng2-ust_2.1.0.bb => lttng-ust_2.1.0.bb}    |    5 +++++
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> index 591f33f..8f40c4e 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> @@ -46,7 +46,7 @@ SYSTEMTAP_aarch64 = ""
>  # which means we can not use syscall() to call it. So we ignore
>  # it for x86_64/uclibc
>  
> -LTTNGUST = "lttng2-ust"
> +LTTNGUST = "lttng-ust"
>  LTTNGUST_libc-uclibc = ""
>  LTTNGUST_mips = ""
>  LTTNGUST_aarch64 = ""
> diff --git a/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb b/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb
> index 482b9a6..16e1ccc 100644
> --- a/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb
> +++ b/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb
> @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
>                      file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
>                      file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca"
>  
> -DEPENDS = "liburcu popt lttng2-ust"
> +DEPENDS = "liburcu popt lttng-ust"
>  
>  SRCREV = "917f768512b5d336d553b801f6c5308d90252a89"
>  PV = "v2.1.0"
> diff --git a/meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb b/meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb
> similarity index 87%
> rename from meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb
> rename to meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb
> index 439e006..1076bde 100644
> --- a/meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb
> +++ b/meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb
> @@ -12,6 +12,11 @@ inherit autotools
>  
>  DEPENDS = "liburcu util-linux"
>  
> +# For backwards compatibility after rename
> +RPROVIDES_${PN} = "lttng2-ust"
> +RREPLACES_${PN} = "lttng2-ust"
> +RCONFLICTS_${PN} = "lttng2-ust"
> +
>  SRCREV = "0c9ad44b7604040dfcd1e67b18afc3dc5d025b19"
>  PV = "2.1.0"
>  PR = "r0"
> 
> 
> _______________________________________________
> Openembedded-commits mailing list
> Openembedded-commits@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits

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

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

Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

[Tom Zanussi]

On Wed, 2013-01-16 at 15:09 +0100, Martin Jansa wrote:
> On Wed, Jan 16, 2013 at 11:58:00AM +0000, git@git.openembedded.org wrote:
> > Module: openembedded-core.git
> > Branch: master
> > Commit: 3c927c39502061bdf3ef9fba1f0f6e7080f6c3cd
> > URL:    http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=3c927c39502061bdf3ef9fba1f0f6e7080f6c3cd
> > 
> > Author: Tom Zanussi <tom.zanussi@intel.com>
> > Date:   Fri Jan 11 17:28:47 2013 -0600
> > 
> > lttng2-ust: rename to lttng-ust
> > 
> > recipes-kernel/lttng/lttng-ust was removed by a previous patch, which
> > also removed the naming conflict that caused the lttng-2.0 version of
> > lttng-ust to be named lttng2-ust.  lttng2-ust was the only lttng-2.0
> > recipe to be named in this way and since that was entirely due to the
> > conflict, we can go back to the consistent naming for it.
> > 
> > Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
> > Signed-off-by: Saul Wold <sgw@linux.intel.com>
> 
> lttng-ust had PE="1", bump PE to fix upgrade path:
> 
> ERROR: Package version for package lttng-ust-dbg went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
> ERROR: Package version for package lttng-ust-staticdev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
> ERROR: Package version for package lttng-ust-dev went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
> ERROR: Package version for package lttng-ust-doc went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
> ERROR: Package version for package lttng-ust-locale went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
> ERROR: Package version for package lttng-ust went backwards which would break package feeds from (1:0.16-r1 to 0:2.1.0-r0)
> 

Thanks for the report - I just sent a patch to fix this.

Tom

> > 
> > ---
> > 
> >  .../packagegroup-core-tools-profile.bb             |    2 +-
> >  meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb |    2 +-
> >  .../{lttng2-ust_2.1.0.bb => lttng-ust_2.1.0.bb}    |    5 +++++
> >  3 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> > index 591f33f..8f40c4e 100644
> > --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> > +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> > @@ -46,7 +46,7 @@ SYSTEMTAP_aarch64 = ""
> >  # which means we can not use syscall() to call it. So we ignore
> >  # it for x86_64/uclibc
> >  
> > -LTTNGUST = "lttng2-ust"
> > +LTTNGUST = "lttng-ust"
> >  LTTNGUST_libc-uclibc = ""
> >  LTTNGUST_mips = ""
> >  LTTNGUST_aarch64 = ""
> > diff --git a/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb b/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb
> > index 482b9a6..16e1ccc 100644
> > --- a/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb
> > +++ b/meta/recipes-kernel/lttng-2.0/lttng-tools_2.1.0.bb
> > @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
> >                      file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
> >                      file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca"
> >  
> > -DEPENDS = "liburcu popt lttng2-ust"
> > +DEPENDS = "liburcu popt lttng-ust"
> >  
> >  SRCREV = "917f768512b5d336d553b801f6c5308d90252a89"
> >  PV = "v2.1.0"
> > diff --git a/meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb b/meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb
> > similarity index 87%
> > rename from meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb
> > rename to meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb
> > index 439e006..1076bde 100644
> > --- a/meta/recipes-kernel/lttng-2.0/lttng2-ust_2.1.0.bb
> > +++ b/meta/recipes-kernel/lttng-2.0/lttng-ust_2.1.0.bb
> > @@ -12,6 +12,11 @@ inherit autotools
> >  
> >  DEPENDS = "liburcu util-linux"
> >  
> > +# For backwards compatibility after rename
> > +RPROVIDES_${PN} = "lttng2-ust"
> > +RREPLACES_${PN} = "lttng2-ust"
> > +RCONFLICTS_${PN} = "lttng2-ust"
> > +
> >  SRCREV = "0c9ad44b7604040dfcd1e67b18afc3dc5d025b19"
> >  PV = "2.1.0"
> >  PR = "r0"
> > 
> > 
> > _______________________________________________
> > Openembedded-commits mailing list
> > Openembedded-commits@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
> 

Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

[Chris Larson]

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

On Wed, Jan 16, 2013 at 8:38 AM, Tom Zanussi <tom.zanussi@intel.com> wrote:

> > lttng-ust had PE="1", bump PE to fix upgrade path:


Technically, that isn't going to "fix" the upgrade path. lttng 1.x requires
kernel patches and isn't compatible with lttng 2.x, as far as I'm aware. So
any machine with lttng 1.x that upgrades to this wouldn't be a real
'upgrade', it would switch interfaces, and potentially break compatibility
with the kernel running on that device. At mentor we have bsp layers for
1.x and for 2.x, and both work. I'm glad we aren't binary package feed
based, or we'd be in serious trouble with this.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 1009 bytes --]

Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

[Tom Zanussi]

On Wed, 2013-01-16 at 08:46 -0700, Chris Larson wrote:
> 
> On Wed, Jan 16, 2013 at 8:38 AM, Tom Zanussi <tom.zanussi@intel.com>
> wrote:
>         > lttng-ust had PE="1", bump PE to fix upgrade path:
> 
> Technically, that isn't going to "fix" the upgrade path. lttng 1.x
> requires kernel patches and isn't compatible with lttng 2.x, as far as
> I'm aware. So any machine with lttng 1.x that upgrades to this
> wouldn't be a real 'upgrade', it would switch interfaces, and
> potentially break compatibility with the kernel running on that
> device. At mentor we have bsp layers for 1.x and for 2.x, and both
> work. I'm glad we aren't binary package feed based, or we'd be in
> serious trouble with this.
> 

This is for the userspace tracing part, lttng-ust, which AFAIK doesn't
require any kernel patches.

The other lttng 2.x recipes weren't changed, just moved, so that
shouldn't break anything.

The lttng 1.x recipes were removed, however, since they do require
extensive kernel patches, and at least the recent Yocto kernels didn't
have those applied, mainly IIRC because the transition of the lttng
project in the meantime to version 2.0 made that difficult.  But now
that 2.0 is available there doesn't seem to be a good reason to keep 1.x
around especially considering the work involved in patching the kernel
and the fact that the functionality is mostly replaced by 2.0.

Tom

Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

[Chris Larson]

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

On Wed, Jan 16, 2013 at 9:40 AM, Tom Zanussi <tom.zanussi@intel.com> wrote:

> This is for the userspace tracing part, lttng-ust, which AFAIK doesn't
> require any kernel patches.
>

Yes, but the point was, as far as I know, the newer ust requires the newer
kernel components, and the older requires the older kernel components, so
technically the package upgrade on a device is likely to change the
behavior.

I didn't say the current version required patches, the point was about the
upgrade path for this recipe. I suspect we're one of the only companies
that was actually using the old recipes, and we don't particularly care
about the binary package upgrade paths at this time, but again, this is
*not* a particularly smooth binary package upgrade path. I expect we're
fine with that, but I wanted make sure it was an explicit conscious choice
of behavior, not something unexpected.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 1323 bytes --]

Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

[Martin Jansa]

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

On Wed, Jan 16, 2013 at 11:02:41AM -0700, Chris Larson wrote:
> On Wed, Jan 16, 2013 at 9:40 AM, Tom Zanussi <tom.zanussi@intel.com> wrote:
> 
> > This is for the userspace tracing part, lttng-ust, which AFAIK doesn't
> > require any kernel patches.
> >
> 
> Yes, but the point was, as far as I know, the newer ust requires the newer
> kernel components, and the older requires the older kernel components, so
> technically the package upgrade on a device is likely to change the
> behavior.
> 
> I didn't say the current version required patches, the point was about the
> upgrade path for this recipe. I suspect we're one of the only companies
> that was actually using the old recipes, and we don't particularly care
> about the binary package upgrade paths at this time, but again, this is
> *not* a particularly smooth binary package upgrade path. I expect we're
> fine with that, but I wanted make sure it was an explicit conscious choice
> of behavior, not something unexpected.

From what you said it looks like recipe shouldn't be renamed in first
place.

I'm not interested in lttng, first I was commenting only about recipe
being renamed without RPROVIDES/RREPLEACES/RCONFLICTS combo and then I
was surprised to see that ERROR about version downgrade from
buildhistory.

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

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

Re: [oe-commits] Tom Zanussi : lttng2-ust: rename to lttng-ust

[Tom Zanussi]

On Wed, 2013-01-16 at 19:47 +0100, Martin Jansa wrote:
> On Wed, Jan 16, 2013 at 11:02:41AM -0700, Chris Larson wrote:
> > On Wed, Jan 16, 2013 at 9:40 AM, Tom Zanussi <tom.zanussi@intel.com> wrote:
> > 
> > > This is for the userspace tracing part, lttng-ust, which AFAIK doesn't
> > > require any kernel patches.
> > >
> > 
> > Yes, but the point was, as far as I know, the newer ust requires the newer
> > kernel components, and the older requires the older kernel components, so
> > technically the package upgrade on a device is likely to change the
> > behavior.
> > 
> > I didn't say the current version required patches, the point was about the
> > upgrade path for this recipe. I suspect we're one of the only companies
> > that was actually using the old recipes, and we don't particularly care
> > about the binary package upgrade paths at this time, but again, this is
> > *not* a particularly smooth binary package upgrade path. I expect we're
> > fine with that, but I wanted make sure it was an explicit conscious choice
> > of behavior, not something unexpected.
> 
> From what you said it looks like recipe shouldn't be renamed in first
> place.
> 

You may be right and what's confusing things is that the new name of the
lttng project actually includes the version number as part of its name
despite it being a completely new project.

So I could submit a patch to rename lttng-ust back to lttng2-ust, but
that would be inconsistent with the other packages in 'lttng2' - it
would in that case make sense to rename them also to lttng2-prefixed
versions i.e. lttng2-modules, lttng2-tools.   It does get kind of
awkward when lttng2 releases a version 3  though- we'd have an
lttng2_ust_3.0 then.  Or will we just rename everything to lttng3_* at
that point, which if the lttng project doesn't do the same, means we'd
have provide some kind of mapping to say that our lttng3 is actually
lttng 2.0's 3.0 and so on...

Or we could just keep everything as lttng-*, rename the lttng2-ust now
and just keep it that way in future regardless of what lttngX decides to
name itself next time.

I'm happy to do either, depending on what people want..

Tom

> I'm not interested in lttng, first I was commenting only about recipe
> being renamed without RPROVIDES/RREPLEACES/RCONFLICTS combo and then I
> was surprised to see that ERROR about version downgrade from
> buildhistory.
> 
> Cheers,