Quantcast

moving forward with meta-gumstix

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

moving forward with meta-gumstix

Peter A. Bigot
I've used Open Embedded (OE-Classic and OE-Core) for more than a year, but
have only started playing with Gumstix hardware in the last week. I'm
trying to get a handle on the best approach moving forward for a build
environment for Gumstix now that the previous OE-Classic approach from
git://gitorious.org/gumstix-oe/mainline.git is outdated.

I see signs that the repo-based solution documented at
http://gumstix.org/software-development/open-embedded/209-yocto.html and
https://github.com/gumstix/Gumstix-YoctoProject-Repo is not ready for prime
time and/or is in a state of flux.  Evidence includes:

* that following the instructions for using repo to get the dev branch
   produces:

  fatal: manifest 'default.xml' not available
  fatal: remote adam-lee not defined in /tmp/.repo/manifests/default.xml

* that the upstream repository git://github.com/gumstix/meta-gumstix has
   some apparently bogus (or at least unreviewed) commits on its master
   branch:

  commit 7cefa67ee3607cfd2ef8e4d1f17da9c455c1aeb0
  Author: Ubuntu <[hidden email]>
  Date:   Tue Nov 20 17:26:04 2012 +0000

     Added a/ b/ prefixes to the file name

  commit 0a95f459e1cf686e50c55982f8bef0198ec74d11
  Author: Ubuntu <[hidden email]>
  Date:   Tue Nov 20 17:06:26 2012 +0000

     Aaaah please work!

  commit b7c3c47fefea583ebec5dc60a2ab9200f02803a3
  Author: Ubuntu <[hidden email]>
  Date:   Tue Nov 20 00:30:13 2012 +0000

     Oops, gave it a wrong file name =(

* that the current image release at
   http://cumulus.gumstix.org/images/angstrom/developer/yocto/ does not
   provide the equivalent to oe-commit-id.txt, so can't be reproduced.

There was also the discussion at
http://gumstix.8.n6.nabble.com/YoctoProject-Meta-Gumstix-BSP-has-been-posted-tp4965534p4965605.html
suggesting that there will be both a meta-gumstix (for things like image
recipes) and meta-gumstix-bsp (for things like u-boot and linux).

Alternatives I'm considering are:

* branching off Angstrom and adding meta-gumstix-community, which so
   far is the only experiment that's been completely successful;

* using Poky with or without the current meta-gumstix repo environment;

* using OE-core with meta-gumstix but overriding the BSP portions with
   content from meta-gumstix-community.

My questions:

* Can I trust that the material in the master branch of
   git://github.com/gumstix/meta-gumstix has been reviewed and will never be
   rebased?  If not, I won't use it.

* Any recommendations from those who've been doing Gumstix-specific projects
   for more than one week?

Thanks for any insight.

Peter

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: moving forward with meta-gumstix

Scott Ellis
I think it doesn't matter much what branch or repo you start with.
Once you run it through your own DEV/QA cycle you need to freeze
and maintain it yourself.

What the Gumstix developers do with their repo after that shouldn't
be relevant. They only provided a starting point that you have now
verified with your own QA. It's now your responsibility.

It's the upstream changes by Yocto/OE, linux omap, u-boot, systemd,
udev, gcc, Qt, etc..., that are more likely to break your product
anyway, not the high-level recipe commits by Gumstix.

Those are the projects you need to monitor.

When working a product, I don't think it's safe to update your repos
from anyone unless you are ready to take your project through a QA
phase again.

That means re-imaging new build workstations from your own internal
QA'd repo (usually cloud hosted) and ideally maintaining your own
fixed set of downloaded sources.

For our customers, we take the kernel and bootloader from Steve Sakoman's
repos, pinned to commits we've verified for the project. I think this
is similar to the Gumstix repos.

We use Poky direct from the Yocto project sticking with the [denzil]
branch for now.

Sometimes we use the meta-openembedded layer from openembedded.org.

After the initial clone, we only pull from these repos when we are
ready to QA again and, of course, prepared to revert. Git cherry-pick
works.

We generate a custom layer for the customer with patches and
customizations to each of the above layers as appropriate.

We haven't gone this far with any customer, but I guess the next step
would be to cut off the PROD build workstation from the network, at
least while it's running bitbake.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: moving forward with meta-gumstix

adam
In reply to this post by Peter A. Bigot
Hello Peter, this is Adam who made those commits. I was supposed to be committing to my own repository, not to the official Gumstix Github. My mistake! Will clean up this morning.

Adam

On Fri, Nov 30, 2012 at 12:43 AM, Peter A. Bigot <[hidden email]> wrote:
I've used Open Embedded (OE-Classic and OE-Core) for more than a year, but
have only started playing with Gumstix hardware in the last week. I'm
trying to get a handle on the best approach moving forward for a build
environment for Gumstix now that the previous OE-Classic approach from
git://gitorious.org/gumstix-oe/mainline.git is outdated.

I see signs that the repo-based solution documented at
http://gumstix.org/software-development/open-embedded/209-yocto.html and
https://github.com/gumstix/Gumstix-YoctoProject-Repo is not ready for prime
time and/or is in a state of flux.  Evidence includes:

* that following the instructions for using repo to get the dev branch
   produces:

  fatal: manifest 'default.xml' not available
  fatal: remote adam-lee not defined in /tmp/.repo/manifests/default.xml

* that the upstream repository git://github.com/gumstix/meta-gumstix has
   some apparently bogus (or at least unreviewed) commits on its master
   branch:

  commit 7cefa67ee3607cfd2ef8e4d1f17da9c455c1aeb0
  Author: Ubuntu <[hidden email]>
  Date:   Tue Nov 20 17:26:04 2012 +0000

     Added a/ b/ prefixes to the file name

  commit 0a95f459e1cf686e50c55982f8bef0198ec74d11
  Author: Ubuntu <[hidden email]>
  Date:   Tue Nov 20 17:06:26 2012 +0000

     Aaaah please work!

  commit b7c3c47fefea583ebec5dc60a2ab9200f02803a3
  Author: Ubuntu <[hidden email]>
  Date:   Tue Nov 20 00:30:13 2012 +0000

     Oops, gave it a wrong file name =(

* that the current image release at
   http://cumulus.gumstix.org/images/angstrom/developer/yocto/ does not
   provide the equivalent to oe-commit-id.txt, so can't be reproduced.

There was also the discussion at
http://gumstix.8.n6.nabble.com/YoctoProject-Meta-Gumstix-BSP-has-been-posted-tp4965534p4965605.html
suggesting that there will be both a meta-gumstix (for things like image
recipes) and meta-gumstix-bsp (for things like u-boot and linux).

Alternatives I'm considering are:

* branching off Angstrom and adding meta-gumstix-community, which so
   far is the only experiment that's been completely successful;

* using Poky with or without the current meta-gumstix repo environment;

* using OE-core with meta-gumstix but overriding the BSP portions with
   content from meta-gumstix-community.

My questions:

* Can I trust that the material in the master branch of
   git://github.com/gumstix/meta-gumstix has been reviewed and will never be
   rebased?  If not, I won't use it.

* Any recommendations from those who've been doing Gumstix-specific projects
   for more than one week?

Thanks for any insight.

Peter

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: moving forward with meta-gumstix

Steve Sakoman
In reply to this post by Scott Ellis
Scott gives very good advice below.

I do something very similar with my customers, though I now use the
danny branch of poky on new projects.

I try to minimize the number of layers in a project, ideally just poky
and a custom project layer.  Cutomers seem to always need a custom
kernel and boot loader, so I have never needed to use meta-gumstix, I
just include the custom bootloader and kernel recipes in the project
layer.

Sometimes a project uses a large number of recipes from
meta-openembedded. In that case I enable just the minimal set of
sub-layers from within meta-openembedded (i.e perhaps meta-systemd &
meta-networking).  Having a large number of unused recipes/layers just
slows down the build and increases the chances of some unintended side
effect.

If a project uses just a handful of recipes from meta-openembedded I
just copy the needed recipes into the project layer.

Locking things down at that point is good practice!  Only make changes
if the project actually needs a bug fix or feature from a new version.

Steve

On Fri, Nov 30, 2012 at 6:09 AM, jumpnowdev <[hidden email]> wrote:

> I think it doesn't matter much what branch or repo you start with.
> Once you run it through your own DEV/QA cycle you need to freeze
> and maintain it yourself.
>
> What the Gumstix developers do with their repo after that shouldn't
> be relevant. They only provided a starting point that you have now
> verified with your own QA. It's now your responsibility.
>
> It's the upstream changes by Yocto/OE, linux omap, u-boot, systemd,
> udev, gcc, Qt, etc..., that are more likely to break your product
> anyway, not the high-level recipe commits by Gumstix.
>
> Those are the projects you need to monitor.
>
> When working a product, I don't think it's safe to update your repos
> from anyone unless you are ready to take your project through a QA
> phase again.
>
> That means re-imaging new build workstations from your own internal
> QA'd repo (usually cloud hosted) and ideally maintaining your own
> fixed set of downloaded sources.
>
> For our customers, we take the kernel and bootloader from Steve Sakoman's
> repos, pinned to commits we've verified for the project. I think this
> is similar to the Gumstix repos.
>
> We use Poky direct from the Yocto project sticking with the [denzil]
> branch for now.
>
> Sometimes we use the meta-openembedded layer from openembedded.org.
>
> After the initial clone, we only pull from these repos when we are
> ready to QA again and, of course, prepared to revert. Git cherry-pick
> works.
>
> We generate a custom layer for the customer with patches and
> customizations to each of the above layers as appropriate.
>
> We haven't gone this far with any customer, but I guess the next step
> would be to cut off the PROD build workstation from the network, at
> least while it's running bitbake.
>
>
>
>
> --
> View this message in context: http://gumstix.8.n6.nabble.com/moving-forward-with-meta-gumstix-tp4966199p4966202.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> TUNE You got it built. Now make it sing. Tune shows you how.
> http://goparallel.sourceforge.net
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Loading...