From: Peter A. B. <pa...@pa...> - 2012-11-30 08:43:16
|
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 <ub...@ip...ernal> Date: Tue Nov 20 17:26:04 2012 +0000 Added a/ b/ prefixes to the file name commit 0a95f459e1cf686e50c55982f8bef0198ec74d11 Author: Ubuntu <ub...@ip...ernal> Date: Tue Nov 20 17:06:26 2012 +0000 Aaaah please work! commit b7c3c47fefea583ebec5dc60a2ab9200f02803a3 Author: Ubuntu <ub...@ip...ernal> 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 |
From: jumpnowdev <sc...@ju...> - 2012-11-30 14:09:14
|
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. |
From: Steve S. <sa...@gm...> - 2012-11-30 15:02:53
|
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 <sc...@ju...> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Adam L. <ad...@gu...> - 2012-11-30 14:35:54
|
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 <pa...@pa...> 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 <ub...@ip...ernal> > Date: Tue Nov 20 17:26:04 2012 +0000 > > Added a/ b/ prefixes to the file name > > commit 0a95f459e1cf686e50c55982f8bef0198ec74d11 > Author: Ubuntu <ub...@ip...ernal> > Date: Tue Nov 20 17:06:26 2012 +0000 > > Aaaah please work! > > commit b7c3c47fefea583ebec5dc60a2ab9200f02803a3 > Author: Ubuntu <ub...@ip...ernal> > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |