RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Denys Dmytriyenko]

Koen et al,

There will be 2 patches sent under this thread that try to resolve the 
dependency of recipes-misc/images on meta-angstrom layer w/o (re)moving those 
recipes. Those are just 2 possible alternatives of fixing it up for now. The 
third option would be to move the recipes-misc/images to another layer, once 
we agree on its name/location and other details. Nobody wants to just remove 
those recipes w/o giving them a proper home. Which also means, that one of the 
proposed 2 workarounds can still be used temporarily until such home is found. 
[Or, one of the two can be the final solution, if we decide not to move...]

Please at least consider these patches and don't blindly dismiss them, as this 
matter is quite a hot button.

-- 
Denys

[RFC: PATCH 1] ti-hw-bringup-image: fix 'no LICENSE' parsing error when meta-angstrom is not used

[Denys Dmytriyenko]

When meta-angstrom is not used in BBLAYERS, parsing of ti-hw-bringup-image and
all other cloud9-*image recipes in recipes-misc/ fails with "No LICENSE field
set" error message, as they use the base systemd-image recipe from meta-angstrom
that sets the license.

This workaround makes the recipes parse by duplicating the license info locally.
They still cannot be built though, as the base systemd-image is not available
w/o referencing meta-angstrom.

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
 recipes-misc/images/ti-hw-bringup-image.bb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/recipes-misc/images/ti-hw-bringup-image.bb b/recipes-misc/images/ti-hw-bringup-image.bb
index 9490098..0590445 100644
--- a/recipes-misc/images/ti-hw-bringup-image.bb
+++ b/recipes-misc/images/ti-hw-bringup-image.bb
@@ -2,6 +2,10 @@
 
 include recipes-images/angstrom/systemd-image.bb
 
+# Repeat the license info here, if systemd-image.bb from meta-angstrom is not available
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
+
 EXTRA_MACHINE_IMAGE_INSTALL ?= ""
 
 # Hokey-pokey workaround for MUSB bugs
-- 
1.7.8.6

[RFC: PATCH 2] systemd-image: overlay local copy to enable building ti-hw-bringup-image

[Denys Dmytriyenko]

Overlay systemd-image recipe locally in meta-ti to enable building at least
ti-hw-bringup-image w/o depending on meta-angstrom.

Couple caveats:
1. Local copy sacrifices timestamp-service that is only available in Angstrom
2. It uses generic packagegroup-boot instead of angstrom-packagegroup-boot,
   which results in sacrificing angstrom-version package

With the above minor tweaks it should be possible to build ti-hw-bringup-image
w/o depending on meta-angstrom layer, only requiring meta-oe/meta-systemd...
And for anyone w/o either meta-angstrom/meta-oe/meta-systemd, it will at least
parse and not break on ti-hw-bringup-image.

On the other hand, it is still possible to get the original behavior when
using the configuration with meta-angstrom, since its original copy of
systemd-image will override the copy in meta-ti, due to higher layer priority.

Unfortunately, cloud9* images depend on additional Angstrom-specific pieces...

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
 recipes-images/angstrom/systemd-image.bb |   28 ++++++++++++++++++++++++++++
 1 files changed, 28 insertions(+), 0 deletions(-)
 create mode 100644 recipes-images/angstrom/systemd-image.bb

diff --git a/recipes-images/angstrom/systemd-image.bb b/recipes-images/angstrom/systemd-image.bb
new file mode 100644
index 0000000..16da70e
--- /dev/null
+++ b/recipes-images/angstrom/systemd-image.bb
@@ -0,0 +1,28 @@
+#Angstrom-derived image to test systemd
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
+
+IMAGE_PREPROCESS_COMMAND = "rootfs_update_timestamp"
+
+DISTRO_UPDATE_ALTERNATIVES ??= ""
+ROOTFS_PKGMANAGE_PKGS ?= '${@base_conditional("ONLINE_PACKAGE_MANAGEMENT", "none", "", "${ROOTFS_PKGMANAGE} ${DISTRO_UPDATE_ALTERNATIVES}", d)}'
+
+CONMANPKGS ?= "connman connman-plugin-loopback connman-plugin-ethernet connman-plugin-wifi connman-systemd"
+CONMANPKGS_libc-uclibc = ""
+
+IMAGE_INSTALL += " \
+	packagegroup-boot \
+	packagegroup-basic \
+	${CONMANPKGS} \
+	${ROOTFS_PKGMANAGE_PKGS} \
+"
+
+IMAGE_DEV_MANAGER   = "udev"
+IMAGE_INIT_MANAGER  = "systemd"
+IMAGE_INITSCRIPTS   = " "
+IMAGE_LOGIN_MANAGER = "tinylogin shadow"
+
+export IMAGE_BASENAME = "systemd-image"
+
+inherit image
-- 
1.7.8.6

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Maupin, Chase]

> -----Original Message-----
> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
> bounces@yoctoproject.org] On Behalf Of Dmytriyenko, Denys
> Sent: Friday, September 14, 2012 1:43 AM
> To: meta-ti@yoctoproject.org
> Subject: [meta-ti] RFC: 2 possible workarounds for recipes-misc
> dependency on Angstrom
> 
> Koen et al,
> 
> There will be 2 patches sent under this thread that try to
> resolve the
> dependency of recipes-misc/images on meta-angstrom layer w/o
> (re)moving those
> recipes. Those are just 2 possible alternatives of fixing it up
> for now. The
> third option would be to move the recipes-misc/images to another
> layer, once
> we agree on its name/location and other details. Nobody wants to
> just remove
> those recipes w/o giving them a proper home. Which also means,
> that one of the
> proposed 2 workarounds can still be used temporarily until such
> home is found.
> [Or, one of the two can be the final solution, if we decide not
> to move...]
> 
> Please at least consider these patches and don't blindly dismiss
> them, as this
> matter is quite a hot button.

Denys, is it worth pulling these things in just to remove them when meta-beagle is created?  I think the better course is to do what you have done which is spell out the policy for meta-ti clearly and let these recipes get moved.  I think what is missing is a reasonable time frame being set for when these recipes will be removed from meta-ti.  Maybe I'm missing something here but it seems like if we are planning a cleanup of meta-ti that we shouldn't start it with first adding more things to cleanup.

So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.

> 
> --
> Denys
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Enrico]

On Fri, Sep 14, 2012 at 10:06 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
> So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.

Sorry to jump into the discussion but...am i the only one that thinks
that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?

Enrico

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Koen Kooi]

Op 17 sep. 2012 om 22:36 heeft Enrico <ebutera@users.berlios.de> het volgende geschreven:

> On Fri, Sep 14, 2012 at 10:06 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
>> So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.
> 
> Sorry to jump into the discussion but...am i the only one that thinks
> that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?

Beagle is not a TI board 



> 
> Enrico
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Denys Dmytriyenko]

On Mon, Sep 17, 2012 at 10:42:39PM +0200, Koen Kooi wrote:
> 
> 
> Op 17 sep. 2012 om 22:36 heeft Enrico <ebutera@users.berlios.de> het volgende geschreven:
> 
> > On Fri, Sep 14, 2012 at 10:06 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
> >> So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.
> > 
> > Sorry to jump into the discussion but...am i the only one that thinks
> > that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?
> 
> Beagle is not a TI board 

And whose board is it then? :)

-- 
Denys

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Enrico]

On Mon, Sep 17, 2012 at 10:42 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
>
> Op 17 sep. 2012 om 22:36 heeft Enrico <ebutera@users.berlios.de> het volgende geschreven:
>
>> On Fri, Sep 14, 2012 at 10:06 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
>>> So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.
>>
>> Sorry to jump into the discussion but...am i the only one that thinks
>> that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?
>
> Beagle is not a TI board

Oh come on you got my point ;)

Enrico

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Philip Balister]

On 09/17/2012 01:36 PM, Enrico wrote:
> On Fri, Sep 14, 2012 at 10:06 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
>> So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.
>
> Sorry to jump into the discussion but...am i the only one that thinks
> that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?

Whether or not Beagle is a TI board ....

It seems like the broader issue (and one I am falling over at the 
moment) is that we want some image recipes in BSP's. The images have 
different layer dependencies.

So we have a set of small images (such as board bring up and test 
images) that depend only on oe-core, and more complex images that depend 
on other layers. We can always mask the more complex images for the case 
where we want to only build against oe-core, but this is not the most 
convenient from a user point of view.

It seems like we need a way for an image to specify the layers it 
requires and if those layers are not present, the recipe will not build, 
but will not break parsing either.

Philip

>
> Enrico
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
>
>

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Denys Dmytriyenko]

On Mon, Sep 17, 2012 at 01:54:17PM -0700, Philip Balister wrote:
> On 09/17/2012 01:36 PM, Enrico wrote:
> >On Fri, Sep 14, 2012 at 10:06 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
> >>So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.
> >
> >Sorry to jump into the discussion but...am i the only one that thinks
> >that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?
> 
> Whether or not Beagle is a TI board ....
> 
> It seems like the broader issue (and one I am falling over at the
> moment) is that we want some image recipes in BSP's. The images have
> different layer dependencies.
> 
> So we have a set of small images (such as board bring up and test
> images) that depend only on oe-core, and more complex images that
> depend on other layers. We can always mask the more complex images
> for the case where we want to only build against oe-core, but this
> is not the most convenient from a user point of view.

That's the whole point of this prolonged discussion...


> It seems like we need a way for an image to specify the layers it
> requires and if those layers are not present, the recipe will not
> build, but will not break parsing either.

Ah, that flexibility would have been nice in general, although it might be too 
easy to use it the wrong way or abuse.

-- 
Denys

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Denys Dmytriyenko]

On Mon, Sep 17, 2012 at 10:36:20PM +0200, Enrico wrote:
> On Fri, Sep 14, 2012 at 10:06 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
> > So really I think the question is do we have an agreement on "meta-beagle" or whatever it should be called, a timeline for it to be created and the recipes moved?  Let's make meta-ti be the foundation BSP that we can all build on top of and nothing more or less.
> 
> Sorry to jump into the discussion but...am i the only one that thinks
> that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?

Not to argue that it's better, but how is it different from meta-cedartrail, 
meta-crownbay, meta-emenlow, meta-sugarbay and all the other Intel boards?

-- 
Denys

Re: RFC: 2 possible workarounds for recipes-misc dependency on Angstrom

[Enrico]

On Mon, Sep 17, 2012 at 11:55 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> On Mon, Sep 17, 2012 at 10:36:20PM +0200, Enrico wrote:
>> Sorry to jump into the discussion but...am i the only one that thinks
>> that having meta-beagle, meta-panda, meta-whateverTIboard is crazy?
>
> Not to argue that it's better, but how is it different from meta-cedartrail,
> meta-crownbay, meta-emenlow, meta-sugarbay and all the other Intel boards?

I admit i know nothing about them and why they are organized like that.

But, in my experience, it's really useful to see what happens in
boards similar to what i'm using/developing for. For example thanks to
Koen beagle patches i learned about smartreflex and crashing dm3730,
or a patch coming from linux-omap to enable 720mhz on 3530, or a patch
to fix mmc timeout issues. (i know, pretty old examples!).

In other words the more i know about an arch, the better it is. And
it's easier to follow meta-ti instead of meta-beagle-that-is-not-ti,
meta-panda, meta-whatever, expecially when i have no (direct) reason
to use those meta layers.

But i maintain nothing in meta-ti so it's easy for me to see it in this way.

Enrico