Patchwork [meta-oe,0/3] Add mosh and dependencies

login
register
mail settings
Submitter Paul Eggleton
Date July 13, 2013, 2:47 p.m.
Message ID <cover.1373726565.git.paul.eggleton@linux.intel.com>
Download mbox
Permalink /patch/53637/
State Accepted, archived
Headers show

Pull-request

git://git.openembedded.org/meta-openembedded-contrib paule/mosh

Comments

Paul Eggleton - July 13, 2013, 2:47 p.m.
Add a recipe for mosh, and for dependencies migrate libio-pty-perl from
OE-Classic and bring in protobuf from meta-virtualization.

I considered putting this in meta-networking, however meta-virtualization
will still need protobuf and it already depends on meta-oe, and officially
meta-networking does not depend on meta-oe so splitting these would not
really work with the current layer dependencies.


The following changes since commit c383d6230942bb1558cee02764bced09031cb70f:

  llvm3.3: Add zlib dependency and explicitly enable it (2013-07-12 12:12:09 +0200)

are available in the git repository at:

  git://git.openembedded.org/meta-openembedded-contrib paule/mosh
  http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=paule/mosh

Paul Eggleton (3):
  protobuf: add recipe from meta-virtualization and tweak
  libio-pty-perl: add from OE-Classic and update
  mosh: add new recipe for version 1.2.4

 meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb    | 29 ++++++++++++++++++++++
 .../recipes-devtools/perl/libio-pty-perl_1.10.bb   | 14 +++++++++++
 .../recipes-devtools/protobuf/protobuf_2.4.1.bb    | 20 +++++++++++++++
 3 files changed, 63 insertions(+)
 create mode 100644 meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb
 create mode 100644 meta-oe/recipes-devtools/perl/libio-pty-perl_1.10.bb
 create mode 100644 meta-oe/recipes-devtools/protobuf/protobuf_2.4.1.bb
Joe MacDonald - July 15, 2013, 12:37 p.m.
[[oe] [meta-oe][PATCH 0/3] Add mosh and dependencies] On 13.07.13 (Sat 15:47) Paul Eggleton wrote:

> Add a recipe for mosh, and for dependencies migrate libio-pty-perl from
> OE-Classic and bring in protobuf from meta-virtualization.
> 
> I considered putting this in meta-networking, however meta-virtualization
> will still need protobuf and it already depends on meta-oe, and officially
> meta-networking does not depend on meta-oe so splitting these would not
> really work with the current layer dependencies.

That's not strictly true anymore, actually.  It was my intent and I
think there's value in it, but CRDA (already in meta-networking) depends
on python-m2crypto (in meta-oe).  I discovered it in my world build a
few weeks ago and hadn't yet managed to get round to seeing if there was
a clean way to separate the two.

I absolutely don't want the stated intent that meta-networking be
standalone be a barrier to adding packages to it that clearly belong to
it.

That's my way of saying I've no objection right now to including this in
meta-net.

-J.

> 
> 
> The following changes since commit c383d6230942bb1558cee02764bced09031cb70f:
> 
>   llvm3.3: Add zlib dependency and explicitly enable it (2013-07-12 12:12:09 +0200)
> 
> are available in the git repository at:
> 
>   git://git.openembedded.org/meta-openembedded-contrib paule/mosh
>   http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=paule/mosh
> 
> Paul Eggleton (3):
>   protobuf: add recipe from meta-virtualization and tweak
>   libio-pty-perl: add from OE-Classic and update
>   mosh: add new recipe for version 1.2.4
> 
>  meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb    | 29 ++++++++++++++++++++++
>  .../recipes-devtools/perl/libio-pty-perl_1.10.bb   | 14 +++++++++++
>  .../recipes-devtools/protobuf/protobuf_2.4.1.bb    | 20 +++++++++++++++
>  3 files changed, 63 insertions(+)
>  create mode 100644 meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb
>  create mode 100644 meta-oe/recipes-devtools/perl/libio-pty-perl_1.10.bb
>  create mode 100644 meta-oe/recipes-devtools/protobuf/protobuf_2.4.1.bb
>
Otavio Salvador - July 15, 2013, 3:02 p.m.
On Mon, Jul 15, 2013 at 9:37 AM, Joe MacDonald
<Joe.MacDonald@windriver.com> wrote:
> [[oe] [meta-oe][PATCH 0/3] Add mosh and dependencies] On 13.07.13 (Sat 15:47) Paul Eggleton wrote:
>
>> Add a recipe for mosh, and for dependencies migrate libio-pty-perl from
>> OE-Classic and bring in protobuf from meta-virtualization.
>>
>> I considered putting this in meta-networking, however meta-virtualization
>> will still need protobuf and it already depends on meta-oe, and officially
>> meta-networking does not depend on meta-oe so splitting these would not
>> really work with the current layer dependencies.
>
> That's not strictly true anymore, actually.  It was my intent and I
> think there's value in it, but CRDA (already in meta-networking) depends
> on python-m2crypto (in meta-oe).  I discovered it in my world build a
> few weeks ago and hadn't yet managed to get round to seeing if there was
> a clean way to separate the two.
>
> I absolutely don't want the stated intent that meta-networking be
> standalone be a barrier to adding packages to it that clearly belong to
> it.
>
> That's my way of saying I've no objection right now to including this in
> meta-net.

I agree; maybe we could add those inside meta-oe subdir? so people can
opt in enable them or not.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
Paul Eggleton - July 15, 2013, 3:36 p.m.
On Monday 15 July 2013 12:02:59 Otavio Salvador wrote:
> On Mon, Jul 15, 2013 at 9:37 AM, Joe MacDonald
> 
> <Joe.MacDonald@windriver.com> wrote:
> > [[oe] [meta-oe][PATCH 0/3] Add mosh and dependencies] On 13.07.13 (Sat 
15:47) Paul Eggleton wrote:
> >> Add a recipe for mosh, and for dependencies migrate libio-pty-perl from
> >> OE-Classic and bring in protobuf from meta-virtualization.
> >> 
> >> I considered putting this in meta-networking, however meta-virtualization
> >> will still need protobuf and it already depends on meta-oe, and
> >> officially meta-networking does not depend on meta-oe so splitting these
> >> would not really work with the current layer dependencies.
> > 
> > That's not strictly true anymore, actually.  It was my intent and I
> > think there's value in it, but CRDA (already in meta-networking) depends
> > on python-m2crypto (in meta-oe).  I discovered it in my world build a
> > few weeks ago and hadn't yet managed to get round to seeing if there was
> > a clean way to separate the two.
> > 
> > I absolutely don't want the stated intent that meta-networking be
> > standalone be a barrier to adding packages to it that clearly belong to
> > it.
> > 
> > That's my way of saying I've no objection right now to including this in
> > meta-net.
> 
> I agree; maybe we could add those inside meta-oe subdir? so people can
> opt in enable them or not.

Sorry Otavio, what are you suggesting exactly?

Cheers,
Paul
Otavio Salvador - July 15, 2013, 4:40 p.m.
On Mon, Jul 15, 2013 at 12:36 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Monday 15 July 2013 12:02:59 Otavio Salvador wrote:
>> On Mon, Jul 15, 2013 at 9:37 AM, Joe MacDonald
>>
>> <Joe.MacDonald@windriver.com> wrote:
>> > [[oe] [meta-oe][PATCH 0/3] Add mosh and dependencies] On 13.07.13 (Sat
> 15:47) Paul Eggleton wrote:
>> >> Add a recipe for mosh, and for dependencies migrate libio-pty-perl from
>> >> OE-Classic and bring in protobuf from meta-virtualization.
>> >>
>> >> I considered putting this in meta-networking, however meta-virtualization
>> >> will still need protobuf and it already depends on meta-oe, and
>> >> officially meta-networking does not depend on meta-oe so splitting these
>> >> would not really work with the current layer dependencies.
>> >
>> > That's not strictly true anymore, actually.  It was my intent and I
>> > think there's value in it, but CRDA (already in meta-networking) depends
>> > on python-m2crypto (in meta-oe).  I discovered it in my world build a
>> > few weeks ago and hadn't yet managed to get round to seeing if there was
>> > a clean way to separate the two.
>> >
>> > I absolutely don't want the stated intent that meta-networking be
>> > standalone be a barrier to adding packages to it that clearly belong to
>> > it.
>> >
>> > That's my way of saying I've no objection right now to including this in
>> > meta-net.
>>
>> I agree; maybe we could add those inside meta-oe subdir? so people can
>> opt in enable them or not.
>
> Sorry Otavio, what are you suggesting exactly?

To have a meta-networking/meta-oe with recipes which requires it.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
Joe MacDonald - July 15, 2013, 5:42 p.m.
[Re: [oe] [meta-oe][PATCH 0/3] Add mosh and dependencies] On 13.07.15 (Mon 13:40) Otavio Salvador wrote:

> On Mon, Jul 15, 2013 at 12:36 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Monday 15 July 2013 12:02:59 Otavio Salvador wrote:
> >> On Mon, Jul 15, 2013 at 9:37 AM, Joe MacDonald
> >>
> >> <Joe.MacDonald@windriver.com> wrote:
> >> > [[oe] [meta-oe][PATCH 0/3] Add mosh and dependencies] On 13.07.13 (Sat
> > 15:47) Paul Eggleton wrote:
> >> >> Add a recipe for mosh, and for dependencies migrate libio-pty-perl from
> >> >> OE-Classic and bring in protobuf from meta-virtualization.
> >> >>
> >> >> I considered putting this in meta-networking, however meta-virtualization
> >> >> will still need protobuf and it already depends on meta-oe, and
> >> >> officially meta-networking does not depend on meta-oe so splitting these
> >> >> would not really work with the current layer dependencies.
> >> >
> >> > That's not strictly true anymore, actually.  It was my intent and I
> >> > think there's value in it, but CRDA (already in meta-networking) depends
> >> > on python-m2crypto (in meta-oe).  I discovered it in my world build a
> >> > few weeks ago and hadn't yet managed to get round to seeing if there was
> >> > a clean way to separate the two.
> >> >
> >> > I absolutely don't want the stated intent that meta-networking be
> >> > standalone be a barrier to adding packages to it that clearly belong to
> >> > it.
> >> >
> >> > That's my way of saying I've no objection right now to including this in
> >> > meta-net.
> >>
> >> I agree; maybe we could add those inside meta-oe subdir? so people can
> >> opt in enable them or not.
> >
> > Sorry Otavio, what are you suggesting exactly?
> 
> To have a meta-networking/meta-oe with recipes which requires it.

Oh.  That's an interesting idea.  I guess the argument against that is
the support infrastructure has a reasonable home in meta-oe and nobody
wants meta-oe to depend on meta-networking.  I do think that having some
mechanism for keeping meta-net reasonably standalone but still not full
of stuff that's on there to satisfy dependencies is good, though.
Haven't really thought much about this yet, though.

-J.

> 
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://projetos.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel