Re: [yocto] Moving angstrom under the yocto banner
Dave, Coud summarize the discussion about this during bspfest, collab and the AB meeting please? regards, Koen Op 30 mrt. 2012, om 21:00 heeft Osier-mixon, Jeffrey het volgende geschreven: As I understand it - Poky is sort of a reference distro for the Yocto system. I think Angstrom would be an excellent addition as an alternative, and I'd be happy to do anything needed on the community side to help. On Fri, Mar 30, 2012 at 11:44 AM, Koen Kooi k...@dominion.thruhere.net wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. What is the process to make that happen? I suspect OSVs will need to know as well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes it impossible to provide any added value if you want to keep calling it 'yocto' to your customers. regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
[Note, Koen is trying to get davest to respond quickly by trying a top post. Good work, Koen!] From: Koen Kooi [mailto:k...@dominion.thruhere.net] Sent: Tuesday, April 10, 2012 7:04 AM Dave, Coud summarize the discussion about this during bspfest, collab and the AB meeting please? Evidently I created a firestorm of controversy with my previous stupid questions on this topic. At the risk of doing so again, will soldier on. Official minutes coming from Shane/Jefro in coming days. I think we're all in agreement with the intent of the Yocto Project - to minimize or eliminate the redundant effort required currently in embedded Linux. This is why we have people slaving away to QA our release bits and fix bugs, for example. With that intent clear, we're still trying to work out which parts of the projects are intended to be upstreams and which are there just as examples. There is some additional clarity we need in order to make this really clear, and I think RP took the action to work on this. (Some of the lack of clarity is that there are still a lot of things called poky and go by fancy video game character names, which might need to change). In the AB meeting, we spent time talking about the use of the Yocto Project (tm) logo and brand. We agreed to create a straw man spreadsheet of requirements for this and will discuss over the next month. The analogy here is to the CGL requirements form, only I'm hoping it's closer to maybe a dozen lines to fill in rather than 200. :-) Dave regards, Koen Op 30 mrt. 2012, om 21:00 heeft Osier-mixon, Jeffrey het volgende geschreven: As I understand it - Poky is sort of a reference distro for the Yocto system. I think Angstrom would be an excellent addition as an alternative, and I'd be happy to do anything needed on the community side to help. On Fri, Mar 30, 2012 at 11:44 AM, Koen Kooi k...@dominion.thruhere.net wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. What is the process to make that happen? I suspect OSVs will need to know as well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes it impossible to provide any added value if you want to keep calling it 'yocto' to your customers. regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2012 10:13 AM, Tom Rini wrote: On Fri, Mar 30, 2012 at 07:27:16PM -0700, Darren Hart wrote: Hi Tom, [snip] You've mentioned preferring to do this with set versions of bitbake and oe-core. Do oe-core and bitbake maintain stable branches? I didn't think they did. This makes it difficult to stabilize a release, and poky serves this purpose well in my opinion. I'm going to stop going down this path though as the policies surrounding this aren't clear to me and would be better coming from others (RP or Chris for example). Again, the intention of poky the repository is not intended to have its own changes. oe-core will have a branch to go along with this release, just like meta-oe, meta-ti, meta-fsl-arm, meta-fsl-ppc, meta-intel and so forth. Richard has even been (from how the branch layout looks) been keeping master stable and doing master-next for things that will go in post release. I think at this point Richard (sorry!) really, really needs to find the time to make poky the distro be a separate layer and Yocto adopt some form of tooling, perhaps Angstrom's setup scripts with a little bit of abstraction, to replace the conglomerate repository and stop some of the That's been stated by RP himself and think we're all agreed on it. confusion about repository directionality (and maybe move I need to resurrect idea X into a branch in upstream). This could even be done as part of Angstrom moving under the umbrella and one of the mutual benefits :) Without this, people working with The Yocto Project are back to using different versions of bitbake and oe-core depending on which distribution or BSP they are building, and we ultimately end up where we started with unsolvable dependency chains and people passing around fixup patches for this or that issue. Then perhaps non-SCM blobs should be part of a Yocto Project release. That has been suggested and it has some merit as a deployment mechanism. I do fear that people will find it convenient to get started, but the confusion is just being pushed back a level to when they try to start developing. Which perhaps is an improvement, but I think we can do better. The point is that poky the repository is NOT an upstream for anything other than poky the distro specific things.` I've wondered about this myself. One disadvantage of this approach in my opinion, and an advantage of the poky repository, is that in poky we have a sort of buffer between oe-core development and bitbake development, where the two can be made to coexist in a known good state. That said, as a developer I would love not having to develop against poky and then split my patches out across the various upstreams (bitbake, oe-core, and meta-yocto) and hope they don't have to be rebased. However, I fear developing on master of each oe-core and bitbake would prove much more fragile than working on poky's master. For stable releases, this issue can be addresses with a similar branching and tagging scheme in oe-core and bitbake (and other Yocto Project projects such as meta-yocto, meta-intel, angstrom, meta-ti, etc.) or as I will label them from now on: forks. Angstrom has been independent from poky and the Yocto Project in the past and I can understand not wanting to lose some of that individuality. However, too much individuality breeds chaos and fragmentation. I will draw a line in the sand here and say: Forcing people to ignore upstream (oe-core/bitbake) and force a fork down their throats breeds chaos and fragmentation. Don't be so dramatic Koen :-) Everybody involved knows the bitbake and oe-core in the poky repository are not forks, at least not in the sense you portray here. They are snapshots with the same maintainer (or subset of maintainers). They are no more forks than the stable Linux kernels maintained by Greg KH are forks of Linus' kernel. I won't presume to make a statement of policy regarding submitting patches against poky that aren't also destined for oe-core or bitbake as well, but I personally wouldn't deign to submit such a patch for fear of the wrath of Purdie (and a flame or two from a certain dutchman ;-). Yes, you the day to day developer understand the relationship between bitbake, oe-core and poky the distro within poky the repository. To the casual or new developer it's not clear because it's not done with git submodules or repo or other standard multi-git-repos-in-a-single-dir tools. It's just manual merge. I agree that it's confusing to the casual or new developer. In particular my concern is about what it means to build with the Yocto Project X.Y release. When such a person goes to download a BSP, say from the Yocto Project Downloads page or somewhere else, that BSP should provide some statement about what it works with. The convenient works with statement is works with the Yocto Project X.Y release. So what does that mean? Poky
Re: [yocto] Moving angstrom under the yocto banner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 09:25 AM, Martin Jansa wrote: On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Clear reproducible testing results. Whether or not a pair of git clones and some tinkering can result in the same thing as a poky repository or not isn't relevant in my opinion. I believe that we need a consistent mode of validating support for a Yocto Project X.Y release. Now if that is accomplished by building with the poky repository of the same vintage or by running some script that pulls the right bits together independently I honestly don't care, but I do think it should be consistent. so teach setup script something like: poky.sh checkout X.Y (which checkouts whatever parts are needed for X.Y) poky.sh update X.Y (dtto) Which creates the same structure like poky repository has, but by checkouting upstream repositories or using submodules or whatever. That's what oebb.sh and SHR makefile does for master/shr HEADs, but can be extended do it for particular version too. This is certainly doable, but it doesn't address the stabilization buffer poky provides that I mentioned. - -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPeyYbAAoJEKbMaAwKp364OUMH/j8LTjnxSHNS7bc2oDQXmx3r E/HzG2t2Q+u0N7Zg/H/1OHNjmZesDr94GlnqHzVMOQRXdpmnx/BZjLuTCL//R43Y wP3jH/gCrAqdk2EJmqNkNQN3A5iQT8Ybj9dYfd0tr6M+GnN/9MpaL8VyW1Fz3Rxo gHgxNu+mvB8mKT4Ix45a91yV107LQ2enPZ7OHHURLGRdjxF1SCi0owuP/hQzEAYl qdgrc3KeBcrAs9ubC9OyAg68G7N8kvgSNSQRegVcELRa34k5Lr/6uP7pehT0IY4m meA1E3tGafo1iIpdxSHhM6HwzUwKcWf/RzupGcXXUWuHsVgeaElvUW5u0h7Kkkg= =mdcZ -END PGP SIGNATURE- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 09:25 AM, Martin Jansa wrote: On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Clear reproducible testing results. Whether or not a pair of git clones and some tinkering can result in the same thing as a poky repository or not isn't relevant in my opinion. I believe that we need a consistent mode of validating support for a Yocto Project X.Y release. Now if that is accomplished by building with the poky repository of the same vintage or by running some script that pulls the right bits together independently I honestly don't care, but I do think it should be consistent. so teach setup script something like: poky.sh checkout X.Y (which checkouts whatever parts are needed for X.Y) poky.sh update X.Y (dtto) Which creates the same structure like poky repository has, but by checkouting upstream repositories or using submodules or whatever. That's what oebb.sh and SHR makefile does for master/shr HEADs, but can be extended do it for particular version too. This is certainly doable, but it doesn't address the stabilization buffer poky provides that I mentioned. While I want to reply to your whole email, I want to ask now, is there really a stabilization buffer being provided? I could see that being the case if we were talking about depending on something independent of this effort (gcc, eglibc, make) but we're talking about oe-core and bitbake. The folks in charge of poky the repo are in charge of oe-core and bitbake. There might be an unintentional lag between when Richard can push changes to poky the repo, but I don't think it's great (and hey, freeing up Richard's time for other stuff is probably a good thing :)). -- Tom signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 09:25 AM, Martin Jansa wrote: On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Clear reproducible testing results. Whether or not a pair of git clones and some tinkering can result in the same thing as a poky repository or not isn't relevant in my opinion. I believe that we need a consistent mode of validating support for a Yocto Project X.Y release. Now if that is accomplished by building with the poky repository of the same vintage or by running some script that pulls the right bits together independently I honestly don't care, but I do think it should be consistent. so teach setup script something like: poky.sh checkout X.Y (which checkouts whatever parts are needed for X.Y) poky.sh update X.Y (dtto) Which creates the same structure like poky repository has, but by checkouting upstream repositories or using submodules or whatever. That's what oebb.sh and SHR makefile does for master/shr HEADs, but can be extended do it for particular version too. This is certainly doable, but it doesn't address the stabilization buffer poky provides that I mentioned. And is it? OE @ ~ $ diff -rq openembedded-core/ projects/poky/ | grep -v '\.git' Files openembedded-core/README and projects/poky/README differ Only in projects/poky/: README.hardware Only in projects/poky/: bitbake Only in openembedded-core/: dev Only in projects/poky/: documentation Only in openembedded-core/meta/conf: bblayers.conf.sample Only in openembedded-core/meta/conf: local.conf.sample Only in openembedded-core/meta/conf: local.conf.sample.extended Only in openembedded-core/meta/conf: site.conf.sample Only in projects/poky/: meta-yocto Only in projects/poky/scripts: lib Files openembedded-core/scripts/oe-setup-builddir and projects/poky/scripts/oe-setup-builddir differ Only in projects/poky/scripts: yocto-bsp Only in projects/poky/scripts: yocto-kernel OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep -v '\.git' Only in projects/bitbake/: MANIFEST.in Only in projects/bitbake/: TODO Only in projects/poky/bitbake/bin: bitbake-runtask Only in projects/bitbake/: classes Only in projects/bitbake/: conf Only in projects/bitbake/lib/bb: fetch Only in projects/poky/bitbake/lib/bb: shell.py Only in projects/bitbake/: setup.py Those changes doesn't look like stabilization buffer.. which is fine we don't need bigger diff between oe-core repo and poky copy, smaller would be nice. And dangerous changes are stopped to oe-core AFAIK, see e.g. my 13 pending patches... Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 09:44 AM, Martin Jansa wrote: On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 09:25 AM, Martin Jansa wrote: On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Clear reproducible testing results. Whether or not a pair of git clones and some tinkering can result in the same thing as a poky repository or not isn't relevant in my opinion. I believe that we need a consistent mode of validating support for a Yocto Project X.Y release. Now if that is accomplished by building with the poky repository of the same vintage or by running some script that pulls the right bits together independently I honestly don't care, but I do think it should be consistent. so teach setup script something like: poky.sh checkout X.Y (which checkouts whatever parts are needed for X.Y) poky.sh update X.Y (dtto) Which creates the same structure like poky repository has, but by checkouting upstream repositories or using submodules or whatever. That's what oebb.sh and SHR makefile does for master/shr HEADs, but can be extended do it for particular version too. This is certainly doable, but it doesn't address the stabilization buffer poky provides that I mentioned. And is it? OE @ ~ $ diff -rq openembedded-core/ projects/poky/ | grep -v '\.git' Files openembedded-core/README and projects/poky/README differ Only in projects/poky/: README.hardware Only in projects/poky/: bitbake Only in openembedded-core/: dev Only in projects/poky/: documentation Only in openembedded-core/meta/conf: bblayers.conf.sample Only in openembedded-core/meta/conf: local.conf.sample Only in openembedded-core/meta/conf: local.conf.sample.extended Only in openembedded-core/meta/conf: site.conf.sample Only in projects/poky/: meta-yocto Only in projects/poky/scripts: lib Files openembedded-core/scripts/oe-setup-builddir and projects/poky/scripts/oe-setup-builddir differ Only in projects/poky/scripts: yocto-bsp Only in projects/poky/scripts: yocto-kernel OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep -v '\.git' Only in projects/bitbake/: MANIFEST.in Only in projects/bitbake/: TODO Only in projects/poky/bitbake/bin: bitbake-runtask Only in projects/bitbake/: classes Only in projects/bitbake/: conf Only in projects/bitbake/lib/bb: fetch Only in projects/poky/bitbake/lib/bb: shell.py Only in projects/bitbake/: setup.py Those changes doesn't look like stabilization buffer.. which is fine we don't need bigger diff between oe-core repo and poky copy, smaller would be nice. And dangerous changes are stopped to oe-core AFAIK, see e.g. my 13 pending patches... Cheers, I expect the buffer to be empty at times. Hopefully *MOST* of the time. - -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPey6cAAoJEKbMaAwKp364o9YIAK8aUDP2jj4Nf1YeefhvZyrm kI5EID7AF1ROjItOX2oQJjLj7aZDsiXCTzx7HFOv1L2VHm1j/6cEtyHkXHwKNFlN ZMWqH2q3+ImUeb6PR2E1PH41KMZoleQtvtQZQQz1cnmn2rjxAI0bJV+3gMcxmugg XO0L7uj0/O1LS/F+s4eCFe7k4VnglzuHyeL4ZIqrBOqGdfawl8vs+iMRaeMhUatX guu42fTZJDulKTaymsYf8pkz6vWfNsz4Nivt101ofcAcWLABxDqVwCk3nnX7j6m7 yO5AldHi19IgcSUNncqdWkIrecQpoSSGB5s4S52i4xHKpM1VwhmtiSfiP+8r7Wk= =qtXk -END PGP SIGNATURE- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Tue, Apr 03, 2012 at 10:08:44AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 09:44 AM, Martin Jansa wrote: On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 09:25 AM, Martin Jansa wrote: On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote: -BEGIN PGP SIGNED MESSAGE- Clear reproducible testing results. Whether or not a pair of git clones and some tinkering can result in the same thing as a poky repository or not isn't relevant in my opinion. I believe that we need a consistent mode of validating support for a Yocto Project X.Y release. Now if that is accomplished by building with the poky repository of the same vintage or by running some script that pulls the right bits together independently I honestly don't care, but I do think it should be consistent. so teach setup script something like: poky.sh checkout X.Y (which checkouts whatever parts are needed for X.Y) poky.sh update X.Y (dtto) Which creates the same structure like poky repository has, but by checkouting upstream repositories or using submodules or whatever. That's what oebb.sh and SHR makefile does for master/shr HEADs, but can be extended do it for particular version too. This is certainly doable, but it doesn't address the stabilization buffer poky provides that I mentioned. And is it? OE @ ~ $ diff -rq openembedded-core/ projects/poky/ | grep -v '\.git' Files openembedded-core/README and projects/poky/README differ Only in projects/poky/: README.hardware Only in projects/poky/: bitbake Only in openembedded-core/: dev Only in projects/poky/: documentation Only in openembedded-core/meta/conf: bblayers.conf.sample Only in openembedded-core/meta/conf: local.conf.sample Only in openembedded-core/meta/conf: local.conf.sample.extended Only in openembedded-core/meta/conf: site.conf.sample Only in projects/poky/: meta-yocto Only in projects/poky/scripts: lib Files openembedded-core/scripts/oe-setup-builddir and projects/poky/scripts/oe-setup-builddir differ Only in projects/poky/scripts: yocto-bsp Only in projects/poky/scripts: yocto-kernel OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep -v '\.git' Only in projects/bitbake/: MANIFEST.in Only in projects/bitbake/: TODO Only in projects/poky/bitbake/bin: bitbake-runtask Only in projects/bitbake/: classes Only in projects/bitbake/: conf Only in projects/bitbake/lib/bb: fetch Only in projects/poky/bitbake/lib/bb: shell.py Only in projects/bitbake/: setup.py Those changes doesn't look like stabilization buffer.. which is fine we don't need bigger diff between oe-core repo and poky copy, smaller would be nice. And dangerous changes are stopped to oe-core AFAIK, see e.g. my 13 pending patches... I expect the buffer to be empty at times. Hopefully *MOST* of the time. I really think what you're calling a stabilization buffer is what others of us see when we branch the repo(s) we're working on until we're happy with the changes. -- Tom signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Tue, Apr 3, 2012 at 1:26 PM, Chris Larson clar...@kergoth.com wrote: I really don't see what the issue is here. If you want a stable branch, we can look into creating such a thing upstream, though I'm personally of the opinion that master should remain release-quality, and make better use of feature branches, potentially a next/integration branch for forthcoming features, than trying to cherry pick onto a stable branch. There's nothing poky's structure provides that can't also be provided via branching policy in the individual repositories. I like what Chris said. I vote for this. It is standard SCM practice. All development goes on in a branch. Integration on another branch. When good enough, it is merged to master and tagged as a milestone release. Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On 04/03/2012 10:34 AM, Brian Hutchinson wrote: On Tue, Apr 3, 2012 at 1:26 PM, Chris Larson clar...@kergoth.com wrote: I really don't see what the issue is here. If you want a stable branch, we can look into creating such a thing upstream, though I'm personally of the opinion that master should remain release-quality, and make better use of feature branches, potentially a next/integration branch for forthcoming features, than trying to cherry pick onto a stable branch. There's nothing poky's structure provides that can't also be provided via branching policy in the individual repositories. I like what Chris said. I vote for this. It is standard SCM practice. All development goes on in a branch. Integration on another branch. When good enough, it is merged to master and tagged as a milestone release. I'd really like to see this as well. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Sun, 2012-04-01 at 21:08 -0700, Matthew McClintock wrote: I think we should consider a standard way of integrating layers and other bits. One method is (and I'm not recommending it) using 'git submodules' - another is 'androids repo command'. If all the distros (poky, angstrom, MEL, etc) could at least consider standardizing on something like this it starts to becoming more obvious what exactly is going on and what version of what is being pulled in and from where... I don't think there is common ground in this area to work with. There is a certain class of users who really need a single repo with all the pieces in to get started with. Poky and some of the solutions provided by various people on this list look like that. There is also the scripts approach taken by Angstrom and others and also the different commercial offerings from the OSVs which are different again. None of the implementations I've seen are wrong, they just help people in different ways (and have some downsides too). Maybe in time we'll see some standardisation in this area (we already have a small number of approaches rather than everyone being different) but at the moment, people are generally happy with their own solutions. I don't see much value in trying to force a standard way of doing things. Its orders of magnitude more important we share bitbake, OE-Core and make the layer model a success. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, Mar 30, 2012 at 07:27:16PM -0700, Darren Hart wrote: [snip] You've mentioned preferring to do this with set versions of bitbake and oe-core. Do oe-core and bitbake maintain stable branches? I didn't think they did. This makes it difficult to stabilize a release, and poky serves this purpose well in my opinion. I'm going to stop going down this path though as the policies surrounding this aren't clear to me and would be better coming from others (RP or Chris for example). Again, the intention of poky the repository is not intended to have its own changes. oe-core will have a branch to go along with this release, just like meta-oe, meta-ti, meta-fsl-arm, meta-fsl-ppc, meta-intel and so forth. Richard has even been (from how the branch layout looks) been keeping master stable and doing master-next for things that will go in post release. I think at this point Richard (sorry!) really, really needs to find the time to make poky the distro be a separate layer and Yocto adopt some form of tooling, perhaps Angstrom's setup scripts with a little bit of abstraction, to replace the conglomerate repository and stop some of the confusion about repository directionality (and maybe move I need to resurrect idea X into a branch in upstream). This could even be done as part of Angstrom moving under the umbrella and one of the mutual benefits :) Without this, people working with The Yocto Project are back to using different versions of bitbake and oe-core depending on which distribution or BSP they are building, and we ultimately end up where we started with unsolvable dependency chains and people passing around fixup patches for this or that issue. Then perhaps non-SCM blobs should be part of a Yocto Project release. The point is that poky the repository is NOT an upstream for anything other than poky the distro specific things.` or as I will label them from now on: forks. Angstrom has been independent from poky and the Yocto Project in the past and I can understand not wanting to lose some of that individuality. However, too much individuality breeds chaos and fragmentation. I will draw a line in the sand here and say: Forcing people to ignore upstream (oe-core/bitbake) and force a fork down their throats breeds chaos and fragmentation. Don't be so dramatic Koen :-) Everybody involved knows the bitbake and oe-core in the poky repository are not forks, at least not in the sense you portray here. They are snapshots with the same maintainer (or subset of maintainers). They are no more forks than the stable Linux kernels maintained by Greg KH are forks of Linus' kernel. I won't presume to make a statement of policy regarding submitting patches against poky that aren't also destined for oe-core or bitbake as well, but I personally wouldn't deign to submit such a patch for fear of the wrath of Purdie (and a flame or two from a certain dutchman ;-). Yes, you the day to day developer understand the relationship between bitbake, oe-core and poky the distro within poky the repository. To the casual or new developer it's not clear because it's not done with git submodules or repo or other standard multi-git-repos-in-a-single-dir tools. It's just manual merge. I will again refer to the agreement between the OE community and yocto for doing the 'merge'. If you people (all speaking personally of course) really think poky is the only way to go, then please close down and remove the oe-core and bitbake repos. I see poky as collecting and integrating these projects into a known-to-work-well-together snapshot. I suppose this is similar to what the Angstrom setup scripts do, except the fetching is done for you in poky instead of after the fact in Angstrom. I think this is a more accurate description than calling them forks. So lets be clear. poky the repository is a collection of exiting branches or tags from other projects, done as a lets make this easy on new / casual users. So why should Angstrom be forced to include poky the repository in it's work-flow when the exact same results, excluding poky the distro, can be achieved by working upstream? -- Tom signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Sat, Mar 31, 2012 at 12:06 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2012-03-30 at 20:00 -0700, Chris Larson wrote: Not to be terribly pendatic or difficult here, but technically, the comparison you make here doesn't ring true. bitbake in poky *still* has changes that never went into the upstream repository. I was surprised to hear that but its easy enough to test: diff -ur bitbake/ ../bitbake/ Only in bitbake//bin: bitbake-runtask Only in ../bitbake/: classes Only in ../bitbake/: conf Only in ../bitbake/: .git Only in ../bitbake/: .gitignore diff -ur bitbake//lib/bb/cooker.py ../bitbake//lib/bb/cooker.py --- bitbake//lib/bb/cooker.py 2012-03-22 14:40:40.488135297 + +++ ../bitbake//lib/bb/cooker.py 2012-03-22 14:32:17.336127747 + @@ -178,7 +178,7 @@ self.configuration.data = bb.data.init() if not self.server_registration_cb: - bb.data.setVar(BB_WORKERCONTEXT, 1, self.configuration.data) + self.configuration.data.setVar(BB_WORKERCONTEXT, 1) filtered_keys = bb.utils.approved_variables() bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys) Only in bitbake//lib/bb: shell.py Only in ../bitbake/: MANIFEST.in Only in ../bitbake/: setup.py Only in ../bitbake/: TODO (where one tree is on bitbake master and the other is poky master). Of these, the classes/conf/.git/setup.py/MANIFEST/TODO are deliberately removed. Those are upstream too. shell.py is still around as a reminder that at some point I think we should resurrect it in a new form. I also evidently never added bitbake-runtask upstream which I thought I had. So, yes, there is a one line change that we've screwed up merging and its not even functionally different. I think we should consider a standard way of integrating layers and other bits. One method is (and I'm not recommending it) using 'git submodules' - another is 'androids repo command'. If all the distros (poky, angstrom, MEL, etc) could at least consider standardizing on something like this it starts to becoming more obvious what exactly is going on and what version of what is being pulled in and from where... -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, 2012-03-30 at 20:00 -0700, Chris Larson wrote: Not to be terribly pendatic or difficult here, but technically, the comparison you make here doesn't ring true. bitbake in poky *still* has changes that never went into the upstream repository. I was surprised to hear that but its easy enough to test: diff -ur bitbake/ ../bitbake/ Only in bitbake//bin: bitbake-runtask Only in ../bitbake/: classes Only in ../bitbake/: conf Only in ../bitbake/: .git Only in ../bitbake/: .gitignore diff -ur bitbake//lib/bb/cooker.py ../bitbake//lib/bb/cooker.py --- bitbake//lib/bb/cooker.py 2012-03-22 14:40:40.488135297 + +++ ../bitbake//lib/bb/cooker.py2012-03-22 14:32:17.336127747 + @@ -178,7 +178,7 @@ self.configuration.data = bb.data.init() if not self.server_registration_cb: -bb.data.setVar(BB_WORKERCONTEXT, 1, self.configuration.data) +self.configuration.data.setVar(BB_WORKERCONTEXT, 1) filtered_keys = bb.utils.approved_variables() bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys) Only in bitbake//lib/bb: shell.py Only in ../bitbake/: MANIFEST.in Only in ../bitbake/: setup.py Only in ../bitbake/: TODO (where one tree is on bitbake master and the other is poky master). Of these, the classes/conf/.git/setup.py/MANIFEST/TODO are deliberately removed. Those are upstream too. shell.py is still around as a reminder that at some point I think we should resurrect it in a new form. I also evidently never added bitbake-runtask upstream which I thought I had. So, yes, there is a one line change that we've screwed up merging and its not even functionally different. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
Reading the discussion, I was wondering whether something under the yocto umbrella should be self-contained layerwise. E.g. would it be ok to depend on an external meta-whatsoever? If so, this does have some quality implications, especially if the external repo has higher prio and contains alternatives to recipes that also exist in oe-core. I can also imagine that any project brought under the yocto umbrella would have to commit themselves to the yocto/oe-core guidelines. My two cents. Frans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Friday 30 March 2012 11:44:23 Koen Kooi wrote: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. I think a lot of points have been well addressed in this thread already, but I wanted to add (and reiterate) a few things. None of this constitutes Yocto Project policy, just my own opinions. I think it's perfectly reasonable if you base something upon the openembedded- core and bitbake repositories to state that it is based upon the Yocto Project (aside from any other conditions which Richard has already talked about; I'm sure LF has some trademark policies as well). If you're supplying your own distro policy as many will in their projects, you would not need to have meta- yocto and it is reasonable if you are building a distribution such as Angstrom to want to exclude it, since you will never be using anything in it. Whatever you do though, I think you need to be able to demonstrate to your customers that you are in fact basing your release on top of a Yocto Project release. This could be accomplished through the use of tags - if you state that you use BitBake x.y and a specific OE-Core tag, and this matches up with the Yocto Project release you state you have based upon, then that should be sufficient. A few other thoughts: 1) Angstrom has a very distinct distro policy from the default provided by OE- Core (or indeed the Poky distro policy); it also currently uses different versions of eglibc and the toolchain. This does make it for certain purposes a slightly different platform from Poky or something else based on OE-Core. This is not necessarily a problem, and is no doubt backed by sound reasoning, but is worth noting and communicating to users. 2) With Angstrom being primarily a binary distribution, I have the impression that you expect that that its distro policy will not be deviated from. There's definitely a good reason for this and value in having such a distribution; but users need to be able to understand the distinction. The Yocto Project itself in providing a way to produce custom Linux distributions does not have such restrictions - we expect that users will make whatever customisations make sense for their project, although of course we make some recommendations as to how they might be implemented. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, Mar 30, 2012 at 2:11 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2012-03-30 at 15:18 -0500, Mark Hatle wrote: On 3/30/12 2:33 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven: On 3/30/12 1:44 PM, Koen Kooi wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. In the interests of clarity, as Tracey will tell you there is no Yocto (which is an SI prefix), only the Yocto Project :). I know some of us have bad habits but since we're trying to ensure we're all consistent, this is worth highlighting. For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org. But there is no yocto.. It's the Yocto Project, Poky, or specific git repositories. There is no reason we can't have an angstrom repository. It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky. Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under yocto is targeted at eliminating 'poky' from the stack while still being able to say 'yocto'. Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a distribution definition (in meta-yocto). I assume angstrom has it's own distribution definition. So my question is why NOT on top of Poky (the repository, not distribution definition)? FWIW I don't think it has to be on top of Poky. Basically the question is whether you'd include the meta-yocto layer or not. I know that doesn't have its own repository yet (but that's purely a time thing). I have no strong feelings either way about the inclusion of that layer. Its purposefully not got that much in it (one distro definition and some hardware/BSP addons). Also, Angstrom has a different repository format in the way the user fetches and interacts with layers. I don't think Yocto mandates any requirement in that area, or that it needs to. I think the repository format used for poky in yocto project could also be confusing things. Since it does not clone openembedded-core or bitbake from upstream locations but maintains a copy of its own. even though they are ditto copies of upstream it still has logical separation that can be source of confusion. So if there was a meta-poky that defined the distro policies and another integration layer that sources openembedded-core and bitbake meta-poky and other layers would make it much clearer. As such OE-Core is distroless as we all know and can be built standalone and poky uses most of defaults so meta-poky could be a thin layer on top right now I think poky combines distro policy layer and integration layer into one which could also be source of confusion. I think creating distinct layers for these two will clear up the air quite a bit. Whether you want to include angstrom as an alternative distro layer is Yocto project and angstrom community to decide I think this would make the distinctions very clear. -Khem ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Sat, Mar 31, 2012 at 9:30 AM, Khem Raj raj.k...@gmail.com wrote: I think the repository format used for poky in yocto project could also be confusing things. Since it does not clone openembedded-core or bitbake from upstream locations but maintains a copy of its own. even though they are ditto copies of upstream it still has logical separation that can be source of confusion. So if there was a meta-poky that defined the distro policies and another integration layer that sources openembedded-core and bitbake meta-poky and other layers would make it much clearer. As such OE-Core is distroless as we all know and can be built standalone and poky uses most of defaults so meta-poky could be a thin layer on top right now I think poky combines distro policy layer and integration layer into one which could also be source of confusion. I think creating distinct layers for these two will clear up the air quite a bit. I agree, and would love to see that happen. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
As I understand it - Poky is sort of a reference distro for the Yocto system. I think Angstrom would be an excellent addition as an alternative, and I'd be happy to do anything needed on the community side to help. On Fri, Mar 30, 2012 at 11:44 AM, Koen Kooi k...@dominion.thruhere.netwrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. What is the process to make that happen? I suspect OSVs will need to know as well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes it impossible to provide any added value if you want to keep calling it 'yocto' to your customers. regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On 3/30/12 2:33 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven: On 3/30/12 1:44 PM, Koen Kooi wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org. But there is no yocto.. It's the Yocto Project, Poky, or specific git repositories. There is no reason we can't have an angstrom repository. It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky. Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under yocto is targeted at eliminating 'poky' from the stack while still being able to say 'yocto'. Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a distribution definition (in meta-yocto). I assume angstrom has it's own distribution definition. So my question is why NOT on top of Poky (the repository, not distribution definition)? We both know that saying it is 'yocto' is wrong and misleading, but that's what users are asking for and yocto advocates seem to push. Just watch the ELC videos for yocto related presentations, 'yocto' and 'poky' are used interchangeably in most of them. A 'reference' should be just that, a reference, not a mandated part. It's hard to call something Yocto Project based unless it used something from the Yocto Project. meta-yocto being on of those components. There is enough confusion about yocto vs poky vs.. It's slowly being reconciled and defined.. but it's a slow process for all of us. --Mark regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
Op 30 mrt. 2012, om 13:18 heeft Mark Hatle het volgende geschreven: On 3/30/12 2:33 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven: On 3/30/12 1:44 PM, Koen Kooi wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org. But there is no yocto.. It's the Yocto Project, Poky, or specific git repositories. There is no reason we can't have an angstrom repository. It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky. Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under yocto is targeted at eliminating 'poky' from the stack while still being able to say 'yocto'. Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a distribution definition (in meta-yocto). I assume angstrom has it's own distribution definition. So my question is why NOT on top of Poky (the repository, not distribution definition)? 1) It's downstream, I want to use upstream (oe-core, bitbake) 2) meta-yocto is *absolutely* unwanted, the meta-ti layer angstrom uses has much, much better support for the beagleboard. 3) It's downstream 4) The combo repo makes it harder to contribute things back upstream 5) It's downstream I know I can change bblayers.conf to remove any unwanted layers, but what's the point of using that combo repo if I do that? It means that angstrom developers have to spend more time explaining that yes, it's a single git repo, but no, you can't send patches against it. We both know that saying it is 'yocto' is wrong and misleading, but that's what users are asking for and yocto advocates seem to push. Just watch the ELC videos for yocto related presentations, 'yocto' and 'poky' are used interchangeably in most of them. A 'reference' should be just that, a reference, not a mandated part. It's hard to call something Yocto Project based unless it used something from the Yocto Project. meta-yocto being on of those components. So you are saying that meta-yocto is an absolute requirement for anything that wants to use 'yocto' in its messaging? There is enough confusion about yocto vs poky vs.. It's slowly being reconciled and defined.. but it's a slow process for all of us. Hence this proposal. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, Mar 30, 2012 at 03:18:06PM -0500, Mark Hatle wrote:
On 3/30/12 2:33 PM, Koen Kooi wrote:
Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
On 3/30/12 1:44 PM, Koen Kooi wrote:
Hi,
RP said I should raise this on the yocto lists, so here it is:
The Angstrom core team would like to move angstrom under the yocto banner
so
we can formally claim to be 'yocto'.
For it to be on the yocto project web site, it just need to have the layers
hosted on the git.yoctoproject.org. But there is no yocto.. It's the
Yocto Project, Poky, or specific git repositories. There is no reason we
can't have an angstrom repository. It could be in a similar format to the
Poky repository (everything combined for a single download), or it could be
a layer [or layers] that sit on top of Poky.
Why on top of poky? I do not want poky, nor do my customers, oe-core is what
we need and want. This proposal to move angstrom under yocto is targeted at
eliminating 'poky' from the stack while still being able to say 'yocto'.
Poky is a repository made up of bitbake + oe-core + meta-yocto, as
well as a distribution definition (in meta-yocto). I assume
angstrom has it's own distribution definition.
So my question is why NOT on top of Poky (the repository, not
distribution definition)?
What does being on top of poky buy the end user? ${some_tool} will be
grabbing the repositories so it's not easier to grab bitbake + oe-core
as one. It adds a barrier to end user to developer conversion since
we'll have a lot of OK, thanks for your contribution but next time
please base against oe-core directly not poky. Not to speak for Denys
or Chase but for Arago, why would we want to have the poky sample distro
around on top of our distro?
We both know that saying it is 'yocto' is wrong and misleading, but that's
what users are asking for and yocto advocates seem to push. Just watch the
ELC
videos for yocto related presentations, 'yocto' and 'poky' are used
interchangeably in most of them.
A 'reference' should be just that, a reference, not a mandated part.
It's hard to call something Yocto Project based unless it used
something from the Yocto Project. meta-yocto being on of those
components.
So bitbake and oe-core don't count because they're external projects?
There is enough confusion about yocto vs poky vs.. It's slowly
being reconciled and defined.. but it's a slow process for all of
us.
Right. But we should probably reiterate that one of the goals was to be
able to say that components X/Y/Z make up a release. And while a merged
repo makes sense in terms of a reference platform (and since git
submodules, repo, etc, etc, each have their own problems) it wasn't the
intent to say you must use this merged repo.
--
Tom
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
Op 30 mrt. 2012, om 13:45 heeft Tom Rini het volgende geschreven:
On Fri, Mar 30, 2012 at 03:18:06PM -0500, Mark Hatle wrote:
On 3/30/12 2:33 PM, Koen Kooi wrote:
Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
On 3/30/12 1:44 PM, Koen Kooi wrote:
Hi,
RP said I should raise this on the yocto lists, so here it is:
The Angstrom core team would like to move angstrom under the yocto banner
so
we can formally claim to be 'yocto'.
For it to be on the yocto project web site, it just need to have the
layers hosted on the git.yoctoproject.org. But there is no yocto.. It's
the Yocto Project, Poky, or specific git repositories. There is no reason
we can't have an angstrom repository. It could be in a similar format to
the Poky repository (everything combined for a single download), or it
could be a layer [or layers] that sit on top of Poky.
Why on top of poky? I do not want poky, nor do my customers, oe-core is what
we need and want. This proposal to move angstrom under yocto is targeted at
eliminating 'poky' from the stack while still being able to say 'yocto'.
Poky is a repository made up of bitbake + oe-core + meta-yocto, as
well as a distribution definition (in meta-yocto). I assume
angstrom has it's own distribution definition.
So my question is why NOT on top of Poky (the repository, not
distribution definition)?
What does being on top of poky buy the end user? ${some_tool} will be
grabbing the repositories so it's not easier to grab bitbake + oe-core
as one. It adds a barrier to end user to developer conversion since
we'll have a lot of OK, thanks for your contribution but next time
please base against oe-core directly not poky. Not to speak for Denys
or Chase but for Arago, why would we want to have the poky sample distro
around on top of our distro?
We both know that saying it is 'yocto' is wrong and misleading, but that's
what users are asking for and yocto advocates seem to push. Just watch the
ELC
videos for yocto related presentations, 'yocto' and 'poky' are used
interchangeably in most of them.
A 'reference' should be just that, a reference, not a mandated part.
It's hard to call something Yocto Project based unless it used
something from the Yocto Project. meta-yocto being on of those
components.
So bitbake and oe-core don't count because they're external projects?
If oe-core doesn't count, that will go directly against the agreement the OE
developers made with the yocto ones when deciding to drop OE classic and start
oe-core.
If that's really the position of the yocto project I think the OE project will
need to seriously reconsider the merge and its participation in the yocto
project.
regards,
Koen
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
It's hard to call something Yocto Project based unless it used something from the Yocto Project. meta-yocto being on of those components. So bitbake and oe-core don't count because they're external projects? If oe-core doesn't count, that will go directly against the agreement the OE developers made with the yocto ones when deciding to drop OE classic and start oe-core. If that's really the position of the yocto project I think the OE project will need to seriously reconsider the merge and its participation in the yocto project. Mark said above: It's hard to call something YP based unless it uses something from the Yocto Project. meta-yocto is one example, but so is oe-core. oe-core is shared code between Yocto and OE. Thus, it is reasonable to say that any distribution that uses oe-core is representative of the Yocto Project, to some degree. So of course oe-core counts, as does bitbake, another shared component. regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
I have some hope of bringing a little bit of order to the chaos that seems to be ensuing here. I am speaking here from my own understanding, which may or may not be correct. On Fri, Mar 30, 2012 at 1:18 PM, Mark Hatle mark.ha...@windriver.comwrote: On 3/30/12 2:33 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven: On 3/30/12 1:44 PM, Koen Kooi wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org. But there is no yocto.. It's the Yocto Project, Poky, or specific git repositories. There is no reason we can't have an angstrom repository. It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky. Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under yocto is targeted at eliminating 'poky' from the stack while still being able to say 'yocto'. Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a distribution definition (in meta-yocto). I assume angstrom has it's own distribution definition. So my question is why NOT on top of Poky (the repository, not distribution definition)? I think I understand what Koen is after - an alternative reference distribution for the Yocto Project. I think this issue provides us with the opportunity to really nail down what is, and what isn't, the Yocto Project. (Since this discussion is happening on the yocto mailing list.) I see it as: - a build took (BitBake), whose maintenance is shared with OE - a set of metadata: some maintained under the Yocto Project banner (e.g. meta-yocto linux-yocto) some shared with others (oe-core) some outside but hosted on yp.org - several build-related tools utilities (e.g. swabber, ADT, etc) - embedded related libraries (e.g. EGLIBC) What these all have in common is that they are related to embedded Linux development, they are maintained under the Yocto Project banner, and they are all tested together in the course of our release process. I think most of the confusion among Yocto, Poky, and OE comes from legacy descriptions. At one time, Poky was itself a build system, and the various layers were not separate projects. It was similar to OE classic. Now functionality all lives in separate layers, most of them interchangeable between Yocto and OE. Definition-wise, we need to remember that the Yocto Project is a *project*, not a distribution, and not a consortium. It isn't a sticker one could put on a box to say yocto inside. As the project website says, it provides templates, tools and methods to help you create custom Linux-based systems. It is not a distribution itself, but it does have a reference system called Poky that is working, tested representation of all of these things together. Thus, there is no yocto distribution. I think it would be correct to say that any release that uses the linux-yocto and/or meta-yocto layer would be representative of the Yocto Project. If a distro uses BitBake, oe-core, and a BSP maintained or obtained from a Yocto Project repository, that's a grey area. If a distro uses nothing maintained on yoctoproject.org, I would suggest that it is not representative of the Yocto Project, although it may be compatible with it. BitBake and oe-core are shared components between Yocto and OE, so by this circuitous definition, Angstrom could be considered representative of the Yocto Project to some extent, as it uses Yocto Project components as its upstream. Poky does as well, but Poky uses only Yocto-maintained components (I think?) and represents all of the various components of the build system working together, and it is tested as such. Does that mean that Poky is more representative of the Yocto Project than Angstrom? Possibly so. But it does not mean Angstrom is unrepresentative. Angstrom uses some Yocto-maintained components and some that are not maintained by the Yocto Project, just as Ubuntu uses some Debian components and some that are not maintained or supported by Debian. We both know that saying it is 'yocto' is wrong and misleading, but that's what users are asking for and yocto advocates seem to push. Just watch the ELC videos for yocto related presentations, 'yocto' and 'poky' are used interchangeably in most of them. A 'reference' should be just that, a reference, not a mandated part. It's hard to call something Yocto Project based unless it used something from the Yocto Project. meta-yocto being on of those components. There is enough confusion about yocto vs poky vs.. It's slowly being reconciled and defined.. but it's a slow process for all of us.
Re: [yocto] Moving angstrom under the yocto banner
On Fri, 2012-03-30 at 15:18 -0500, Mark Hatle wrote: On 3/30/12 2:33 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven: On 3/30/12 1:44 PM, Koen Kooi wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. In the interests of clarity, as Tracey will tell you there is no Yocto (which is an SI prefix), only the Yocto Project :). I know some of us have bad habits but since we're trying to ensure we're all consistent, this is worth highlighting. For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org. But there is no yocto.. It's the Yocto Project, Poky, or specific git repositories. There is no reason we can't have an angstrom repository. It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky. Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under yocto is targeted at eliminating 'poky' from the stack while still being able to say 'yocto'. Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a distribution definition (in meta-yocto). I assume angstrom has it's own distribution definition. So my question is why NOT on top of Poky (the repository, not distribution definition)? FWIW I don't think it has to be on top of Poky. Basically the question is whether you'd include the meta-yocto layer or not. I know that doesn't have its own repository yet (but that's purely a time thing). I have no strong feelings either way about the inclusion of that layer. Its purposefully not got that much in it (one distro definition and some hardware/BSP addons). Also, Angstrom has a different repository format in the way the user fetches and interacts with layers. I don't think Yocto mandates any requirement in that area, or that it needs to. We both know that saying it is 'yocto' is wrong and misleading, but that's what users are asking for and yocto advocates seem to push. Try saying this in earshot of Tracey ;-). We are trying to do a better job of saying Yocto Project, please help us! Just watch the ELC videos for yocto related presentations, 'yocto' and 'poky' are used interchangeably in most of them. A 'reference' should be just that, a reference, not a mandated part. It's hard to call something Yocto Project based unless it used something from the Yocto Project. meta-yocto being on of those components. The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan Note that it I don't list must use meta-yocto there since I don't think that is true. I would want to be clear about where I'd see Angstrom positioned within the Yocto Project which would be as a reference binary distribution. This is in contrast with Poky which would remain as the getting started and reference testing configuration (obviously building from source/sstate in contrast to Angstrom). I do have some questions related to some of the above points but I'm going to hold off those for now and see where this discussion goes. I'd also mention that I'd like to see what advice the advisory board has on this topic too. There is enough confusion about yocto vs poky vs.. It's slowly being reconciled and defined.. but it's a slow process for all of us. Right, I think we are getting to grips with this slowly and there was a good discussion about this on the meta-ti list recently. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
My apologies for loosing the reply indent, I blame apple mail
Op 30 mrt. 2012, om 14:01 heeft Osier-mixon, Jeffrey het volgende geschreven:
Angstrom does use oe-core, but I don't think it uses linux-yocto (right?) and
definitely not meta-yocto.
linux-yocto is a kernel, which is used by machines in meta-intel, which
angstrom supports (only fri2 atm), so the choice to use or not use linux-yocto
is up to th e BSP, not to angstrom. OE was founded on the principle that
machines, images and distros are orthogonal. Angstrom does cheat a bit with
images, but it is *not* changing any machine definitions.
This is what angstrom is currently using:
[koen@Angstrom-F16-vm-rpm setup-scripts]$ cat sources/layers.txt
# Name,repo-uri,branch,rev
bitbake,git://github.com/openembedded/bitbake.git,master,HEAD
meta-angstrom,git://github.com/Angstrom-distribution/meta-angstrom,master,HEAD
meta-openembedded,git://github.com/openembedded/meta-oe.git,master,HEAD
meta-ti,git://git.yoctoproject.org/meta-ti,master,HEAD
meta-ettus,git://github.com/balister/meta-ettus.git,master,HEAD
meta-efikamx,git://github.com/kraj/meta-efikamx.git,master,HEAD
meta-nslu2,git://github.com/kraj/meta-nslu2.git,master,HEAD
meta-smartphone,http://git.shr-project.org/repo/meta-smartphone.git,master,HEAD
meta-intel,git://git.yoctoproject.org/meta-intel,master,HEAD
meta-xilinx,git://git.yoctoproject.org/meta-xilinx,master,HEAD
meta-openpandora,git://github.com/openpandora/meta-openpandora.git,master,HEAD
meta-handheld,git://git.openembedded.org/meta-handheld,master,HEAD
meta-opie,git://github.com/bluelightning/meta-opie.git,master,HEAD
meta-java,git://github.com/woglinde/meta-java.git,master,HEAD
meta-mozilla,git://github.com/OSSystems/meta-mozilla.git,master,HEAD
meta-mono,git://github.com/KokoFitClub/meta-mono.git,master,HEAD
openembedded-core,git://github.com/openembedded/oe-core.git,master,HEAD
It will add more bsp layers soon (fsl-ppc, fsl-arm, etc) before the release.
And the layer config:
[koen@Angstrom-F16-vm-rpm setup-scripts]$ cat conf/bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = 4
TOPDIR := ${@os.path.dirname(os.path.dirname(d.getVar('FILE', True)))}
BBPATH = ${TOPDIR}
BBFILES =
# These layers hold recipe metadata not found in OE-core, but lack any machine
or distro content
BASELAYERS ?= \
${TOPDIR}/sources/meta-openembedded/meta-oe \
${TOPDIR}/sources/meta-openembedded/toolchain-layer \
${TOPDIR}/sources/meta-openembedded/meta-efl \
${TOPDIR}/sources/meta-openembedded/meta-gpe \
${TOPDIR}/sources/meta-openembedded/meta-gnome \
${TOPDIR}/sources/meta-openembedded/meta-xfce \
${TOPDIR}/sources/meta-openembedded/meta-initramfs \
${TOPDIR}/sources/meta-opie \
${TOPDIR}/sources/meta-java \
${TOPDIR}/sources/meta-mozilla \
# These layers hold machine specific content, aka Board Support Packages
BSPLAYERS ?= \
${TOPDIR}/sources/meta-ti \
${TOPDIR}/sources/meta-efikamx \
${TOPDIR}/sources/meta-nslu2 \
${TOPDIR}/sources/meta-smartphone/meta-htc \
${TOPDIR}/sources/meta-smartphone/meta-nokia \
${TOPDIR}/sources/meta-smartphone/meta-openmoko \
${TOPDIR}/sources/meta-smartphone/meta-palm \
${TOPDIR}/sources/meta-handheld \
${TOPDIR}/sources/meta-intel \
${TOPDIR}/sources/meta-intel/meta-sugarbay \
${TOPDIR}/sources/meta-intel/meta-crownbay \
${TOPDIR}/sources/meta-intel/meta-emenlow \
${TOPDIR}/sources/meta-intel/meta-fishriver \
${TOPDIR}/sources/meta-intel/meta-jasperforest \
${TOPDIR}/sources/meta-intel/meta-n450 \
# Add your overlay location to EXTRALAYERS
# Make sure to have a conf/layers.conf in there
EXTRALAYERS ?=
BBLAYERS = \
${TOPDIR}/sources/meta-angstrom \
${BASELAYERS} \
${BSPLAYERS} \
${EXTRALAYERS} \
${TOPDIR}/sources/openembedded-core/meta \
regards,
Koen
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
I just thought I'd chime in on this discussion as someone who is outside of both groups. It's been difficult to explain to our teams internally the whole Yocto Project vs. Angstrom-core terminology, and since everyone here is familiar with Linux and distros, we decided to put it in those terms. Note that not coming from these groups, there's a good chance we've been explaining it all wrong, in which case, feel free to correct and clarify and I'd be happy to change our internal explanations. We see bitbake/oe-core as Debian based Linux, Poky and Angstrom as distros (like Ubuntu and Debian), and the Yocto Project as something like Canonical. The Yocto Project regularly contributes to bitbake and oe-core, but also maintains layers and products on top of that, like meta-yocto and the Eclipse ADT plugin, all of which constitutes the Poky distro. The Yocto Project then has regular releases of stable snapshots, much like you have Ubuntu 10.04, 10.10, etc. That said, I personally feel (this is not necessarily representative of my co-workers or company) that Angstrom, as a distro, should be allowed to use the Yocto Project name and have the Yocto Project post information about Angstrom on their Projects page, if Angstrom can stick to a regular release schedule that meets the same quality requirements that Poky does. I think that would ensure that the Yocto Project trademark maintains a quality image while helping users whose projects align better with the Angstrom distro than with Poky know that there are other oe-core distros out there. Daniel Lazzari Jr. Firmware Engineer, LeapFrog dlazz...@leapfrog.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Richard Purdie Sent: Friday, March 30, 2012 2:11 PM The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan I would add: e) there should be interoperability with the other parts of the YP. Part of the benefit we're trying to create is that if someone invests in YP for their device, they should get benefit from the whole thing. If a board manufacturer creates a BSP for YP v1.2, there should be no doubt whatsoever that it will work with that system. Can anyone assure me that such a BSP would work under Angstrom? Or I develop a layer for an app on Angstrom. Do I know for sure that it will for sure work on MEL, which has YP as its upstream? See where I'm going with this? Finally, Dr. Kooi has stated that he doesn't see YP as an upstream. In fact, many of the OSVs (like Wind River, Mentor Graphics and now ENEA - yeah!) absolutely want to use YP as their upstream. So I'm hoping we could change the definition of YP/Poky/Angstrom so Angstrom could us Poky as its upstream ... no? Too hard? Anyway, if we can't get to this level of interoperability, then adding Angstrom to the Yocto project may add too much confusion. Dave ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, Mar 30, 2012 at 4:06 PM, Stewart, David C david.c.stew...@intel.com wrote: From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Richard Purdie Sent: Friday, March 30, 2012 2:11 PM The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan I would add: e) there should be interoperability with the other parts of the YP. Part of the benefit we're trying to create is that if someone invests in YP for their device, they should get benefit from the whole thing. If a board manufacturer creates a BSP for YP v1.2, there should be no doubt whatsoever that it will work with that system. Can anyone assure me that such a BSP would work under Angstrom? Given that an OE priority has *always* been that distro, machine, and image are largely independent, orthogonal components, and generally speaking one can combine any combination of the three and have at least a good shot at functionality, I'd say that if such a BSP did not work under Angstrom, that'd be a bug that we'd all agree would need to be fixed. As far as I know, this priority and attribute of the system still exists. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, Mar 30, 2012 at 04:09:37PM -0700, Chris Larson wrote: On Fri, Mar 30, 2012 at 4:06 PM, Stewart, David C david.c.stew...@intel.com wrote: From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Richard Purdie Sent: Friday, March 30, 2012 2:11 PM The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx ?? development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with ?? mutual benefit) d) Have some kind of sustainable resource plan I would add: e) there should be interoperability with the other parts of the YP. Part of the benefit we're trying to create is that if someone invests in YP for their device, they should get benefit from the whole thing. ??If a board manufacturer creates a BSP for YP v1.2, there should be no doubt whatsoever that it will work with that system. ??Can anyone assure me that such a BSP would work under Angstrom? Given that an OE priority has *always* been that distro, machine, and image are largely independent, orthogonal components, and generally speaking one can combine any combination of the three and have at least a good shot at functionality, I'd say that if such a BSP did not work under Angstrom, that'd be a bug that we'd all agree would need to be fixed. As far as I know, this priority and attribute of the system still exists. This is also my understanding and expectation. -- Tom ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, Mar 30, 2012 at 11:06:04PM +, Stewart, David C wrote: Finally, Dr. Kooi has stated that he doesn't see YP as an upstream. In fact, many of the OSVs (like Wind River, Mentor Graphics and now ENEA - yeah!) absolutely want to use YP as their upstream. So I'm hoping we could change the definition of YP/Poky/Angstrom so Angstrom could us Poky as its upstream ... no? Too hard? Putting on my me, myself and I hat and apologizing for putting words in a few peoples mouths, I think this speaks to the heart of the problem Koen is trying to express. On a technical level, the goal has been something (and I'm simplifying a bit here) to say that poky (the distro) is an implementation of policy for oe-core. oe-core, bitbake and N number of other layers (meta-intel, meta-fsl-ppc, meta-ti, meta-java, meta-oe, meta-so-on-and-so-forth) will say that this is their metadata for release X. Some of these layers (bitbake, oe-core, poky the distro) are maintained by 'Yocto Project' folks like Richard. Others are maintained by community folks (Koen, Eric B.) or other companies (Denys). Now, you say YP is an upstream. But Yocto Project is an upstream for bitbake, and for openembedded-core and for poky (the distro) and a lot of other stuff. However, meta-yocto (what got us going in this direction) is only an upstream for poky (the distro), and Richard has said it's a TODO list item to move poky (the distro) into a separate repository and thus make meta-yocto ONLY a conglomeration of other repositories. It's GOOD that companies want to work with upstream, and at some high level Yocto Project is where that is, in so far as bitbake, openembedded-core, etc, get a lot of time and energy and resources of Yocto Project people. But these also get community resources too. Koen for example DOES see Yocto Project as an upstream in that he contributes to openembedded-core, etc, etc. Angstrom also sees Yocto Project as an upstream for the same reasons. But on a technical level, none of us would say it that way. And this is where the confusion emanates from I believe. You're saying that Angstrom (the distro) should see poky (the distro) as it's upstream. If I was a runner, I could make an analogy you would say but that's silly! and I would say exactly! and we'd all be on the same page. So can we pretend I did? Anyway, if we can't get to this level of interoperability, then adding Angstrom to the Yocto project may add too much confusion. If someone makes a layer and it works with meta-yocto + meta-SomeHWVendor and fails with meta-angstrom + openembedded-core + bitbake + meta-SomeHWVendor (and you can replace meta-angstrom with meta-arago or any other layer that provides distro policy) it's a bug, not a feature, and not what anyone expects to happen today. -- Tom signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On 03/30/2012 02:11 PM, Richard Purdie wrote: On Fri, 2012-03-30 at 15:18 -0500, Mark Hatle wrote: On 3/30/12 2:33 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven: On 3/30/12 1:44 PM, Koen Kooi wrote: Hi, RP said I should raise this on the yocto lists, so here it is: The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'. In the interests of clarity, as Tracey will tell you there is no Yocto (which is an SI prefix), only the Yocto Project :). I know some of us have bad habits but since we're trying to ensure we're all consistent, this is worth highlighting. For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org. But there is no yocto.. It's the Yocto Project, Poky, or specific git repositories. There is no reason we can't have an angstrom repository. It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky. Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under yocto is targeted at eliminating 'poky' from the stack while still being able to say 'yocto'. Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a distribution definition (in meta-yocto). I assume angstrom has it's own distribution definition. So my question is why NOT on top of Poky (the repository, not distribution definition)? FWIW I don't think it has to be on top of Poky. Basically the question is whether you'd include the meta-yocto layer or not. I know that doesn't have its own repository yet (but that's purely a time thing). I have no strong feelings either way about the inclusion of that layer. Its purposefully not got that much in it (one distro definition and some hardware/BSP addons). Also, Angstrom has a different repository format in the way the user fetches and interacts with layers. I don't think Yocto mandates any requirement in that area, or that it needs to. We both know that saying it is 'yocto' is wrong and misleading, but that's what users are asking for and yocto advocates seem to push. Try saying this in earshot of Tracey ;-). We are trying to do a better job of saying Yocto Project, please help us! Just watch the ELC videos for yocto related presentations, 'yocto' and 'poky' are used interchangeably in most of them. A 'reference' should be just that, a reference, not a mandated part. It's hard to call something Yocto Project based unless it used something from the Yocto Project. meta-yocto being on of those components. The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan I'll take a couple careful steps into this arena to offer just one more possible criteria. One of the touted goals/advantages/benefits of using the Yocto Project is to work with a vetted set of sources that are known to all work together, having had some level of QA performed. This is something the poky repository accomplishes by bringing specifc versions of bitbake and oe-core together (along with some other tooling). At some point, this gets rolled up into a release of the Yocto Project: 0.9, 1.1, and soon 1.2. It's common for someone to refer to these release points as the base for their BSP. It therefor seems reasonable to me for a distribution definition (which is how I think of Angstrom - but feel free to correct me Koen) to make a statement like This release of Angstrom builds with the Yocto Project X.Y release. I believe this is the sort of language that most outside developers would immediately understand and associate with being part of the Yocto Project. -- Darren Note that it I don't list must use meta-yocto there since I don't think that is true. I would want to be clear about where I'd see Angstrom positioned within the Yocto Project which would be as a reference binary distribution. This is in contrast with Poky which would remain as the getting started and reference testing configuration (obviously building from source/sstate in contrast to Angstrom). I do have some questions related to some of the above points but I'm going to hold off those for now and see where this discussion goes. I'd also mention that I'd like to see what advice the advisory board has on this topic too. There is enough confusion about yocto vs poky vs.. It's slowly being reconciled and defined.. but it's a slow process for all of us. Right, I think we are getting to grips with this slowly and
Re: [yocto] Moving angstrom under the yocto banner
Op 30 mrt. 2012, om 16:49 heeft Tom Rini het volgende geschreven: On Fri, Mar 30, 2012 at 11:06:04PM +, Stewart, David C wrote: Finally, Dr. Kooi has stated that he doesn't see YP as an upstream. In fact, many of the OSVs (like Wind River, Mentor Graphics and now ENEA - yeah!) absolutely want to use YP as their upstream. So I'm hoping we could change the definition of YP/Poky/Angstrom so Angstrom could us Poky as its upstream ... no? Too hard? Putting on my me, myself and I hat and apologizing for putting words in a few peoples mouths, I think this speaks to the heart of the problem Koen is trying to express. Exactly! I said that *poky* is not an upstream, nothing about YP. On a technical level, the goal has been something (and I'm simplifying a bit here) to say that poky (the distro) is an implementation of policy for oe-core. oe-core, bitbake and N number of other layers (meta-intel, meta-fsl-ppc, meta-ti, meta-java, meta-oe, meta-so-on-and-so-forth) will say that this is their metadata for release X. Some of these layers (bitbake, oe-core, poky the distro) are maintained by 'Yocto Project' folks like Richard. Others are maintained by community folks (Koen, Eric B.) or other companies (Denys). Now, you say YP is an upstream. But Yocto Project is an upstream for bitbake, and for openembedded-core and for poky (the distro) and a lot of other stuff. However, meta-yocto (what got us going in this direction) is only an upstream for poky (the distro), and Richard has said it's a TODO list item to move poky (the distro) into a separate repository and thus make meta-yocto ONLY a conglomeration of other repositories. It's GOOD that companies want to work with upstream, and at some high level Yocto Project is where that is, in so far as bitbake, openembedded-core, etc, get a lot of time and energy and resources of Yocto Project people. But these also get community resources too. Koen for example DOES see Yocto Project as an upstream in that he contributes to openembedded-core, etc, etc. Angstrom also sees Yocto Project as an upstream for the same reasons. But on a technical level, none of us would say it that way. Exactly. I said that *poky* is not an upstream. And this is where the confusion emanates from I believe. You're saying that Angstrom (the distro) should see poky (the distro) as it's upstream. If I was a runner, I could make an analogy you would say but that's silly! and I would say exactly! and we'd all be on the same page. So can we pretend I did? Anyway, if we can't get to this level of interoperability, then adding Angstrom to the Yocto project may add too much confusion. If someone makes a layer and it works with meta-yocto + meta-SomeHWVendor and fails with meta-angstrom + openembedded-core + bitbake + meta-SomeHWVendor (and you can replace meta-angstrom with meta-arago or any other layer that provides distro policy) it's a bug, not a feature, and not what anyone expects to happen today. Like meta-ti won't build with binutils newer than 2.20.x. We all agree that's a bug in meta-ti, not a bug in oe-core or poky (the distro). ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven: [snip] On 03/30/2012 02:11 PM, Richard Purdie wrote: The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan I'll take a couple careful steps into this arena to offer just one more possible criteria. One of the touted goals/advantages/benefits of using the Yocto Project is to work with a vetted set of sources that are known to all work together, having had some level of QA performed. This is something the poky repository accomplishes by bringing specifc versions of bitbake and oe-core together (along with some other tooling). At some point, this gets rolled up into a release of the Yocto Project: 0.9, 1.1, and soon 1.2. It's common for someone to refer to these release points as the base for their BSP. It therefor seems reasonable to me for a distribution definition (which is how I think of Angstrom - but feel free to correct me Koen) to make a statement like This release of Angstrom builds with the Yocto Project X.Y release. Yes, but see below I believe this is the sort of language that most outside developers would immediately understand and associate with being part of the Yocto Project. What does a 'yocto project release' actually mean? Right now it looks more like a 'poky (the distro) release'. Since angstrom builds on oe-core and bitbake directly the statement (in the current situation) would be more like: This release of angstrom builds on oe-core 2012.1, bitbake 1.something.x, which matches the YP 1.x release. If we move more things under the YP banner and convince subprojects to adopt the same schedule, we could make statements like: The Yocto Project 1.x release consist of the following modules: * bitbake 1.x * oe-core 2012.x * poky $DOTT_character * eglibc 2.17 * pseudo 1.2 * angstrom 2012.04 * meta-xilinx 6.5 ... etc I think that would make it fit better with the umbrella project idea. consists might be a bad choice of words, I blame the unlimited coffee refills at the diner across the street :) regards, Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On 03/30/2012 05:08 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven: [snip] On 03/30/2012 02:11 PM, Richard Purdie wrote: The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan I'll take a couple careful steps into this arena to offer just one more possible criteria. One of the touted goals/advantages/benefits of using the Yocto Project is to work with a vetted set of sources that are known to all work together, having had some level of QA performed. This is something the poky repository accomplishes by bringing specifc versions of bitbake and oe-core together (along with some other tooling). At some point, this gets rolled up into a release of the Yocto Project: 0.9, 1.1, and soon 1.2. It's common for someone to refer to these release points as the base for their BSP. It therefor seems reasonable to me for a distribution definition (which is how I think of Angstrom - but feel free to correct me Koen) to make a statement like This release of Angstrom builds with the Yocto Project X.Y release. Yes, but see below I believe this is the sort of language that most outside developers would immediately understand and associate with being part of the Yocto Project. What does a 'yocto project release' actually mean? Right now it looks more like a 'poky (the distro) release'. Since angstrom builds on oe-core and bitbake directly the statement (in the current situation) would be more like: /me hands koen a real MUA that wraps at 80 characters... and wraps his mail for him... (everyone else gets a pass, but you? ;-) I see the poky distro definition as only a part of the poky repository, the naming is unfortunate, but I think we can all see past that for the purposes of this discussion. This is part of meta-yocto which will at some point be it's own repository. So I don't agree with the assertion that it looks more like a poky the distro release. This release of angstrom builds on oe-core 2012.1, bitbake 1.something.x, which matches the YP 1.x release. OK. Donning my Yeah but I have a XYZ and things to get done hat, I think people will respond more positively to: Download the 1.2 Yocto Project release, add meta-angstrom to your bblayers.conf, and build $IMAGE_TARGET than they will to Download bitbake X.Y, Angstrom X.Y, OE Core X.Y, etc. instructions on setting up the layers, the local.conf, etc etc. I believe there are some other details the poky repository helps out with (someone more familiar with working with the individual components would have to enumerate these, I honestly don't know what they all are). And yes, there are the BSP layers to add to each of these scenarios, but that effects each equally. All that environment setup is something that can make or break the initial experience. I believe lots of users appreciate not having to pull all the pieces together themselves. (especially those that don't even know what they're not having to do!) If we move more things under the YP banner and convince subprojects to adopt the same schedule, we could make statements like: The Yocto Project 1.x release consist of the following modules: * bitbake 1.x * oe-core 2012.x * poky $DOTT_character * eglibc 2.17 * pseudo 1.2 * angstrom 2012.04 * meta-xilinx 6.5 ... etc With the exception of eglibc (I wouldn't want to have to list every package from oe-core and the layers!) this doesn't seem out of line to me. I think that would make it fit better with the umbrella project idea. consists might be a bad choice of words, I blame the unlimited coffee refills at the diner across the street :) And I blame any perceived snarkiness on the migraine and the 4 different medications the doc's got me on to try and patch me up to fly on Monday ;-) -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
Op 30 mrt. 2012, om 17:28 heeft Darren Hart het volgende geschreven: On 03/30/2012 05:08 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven: [snip] On 03/30/2012 02:11 PM, Richard Purdie wrote: The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan I'll take a couple careful steps into this arena to offer just one more possible criteria. One of the touted goals/advantages/benefits of using the Yocto Project is to work with a vetted set of sources that are known to all work together, having had some level of QA performed. This is something the poky repository accomplishes by bringing specifc versions of bitbake and oe-core together (along with some other tooling). At some point, this gets rolled up into a release of the Yocto Project: 0.9, 1.1, and soon 1.2. It's common for someone to refer to these release points as the base for their BSP. It therefor seems reasonable to me for a distribution definition (which is how I think of Angstrom - but feel free to correct me Koen) to make a statement like This release of Angstrom builds with the Yocto Project X.Y release. Yes, but see below I believe this is the sort of language that most outside developers would immediately understand and associate with being part of the Yocto Project. What does a 'yocto project release' actually mean? Right now it looks more like a 'poky (the distro) release'. Since angstrom builds on oe-core and bitbake directly the statement (in the current situation) would be more like: /me hands koen a real MUA that wraps at 80 characters... and wraps his mail for him... (everyone else gets a pass, but you? ;-) I see the poky distro definition as only a part of the poky repository, the naming is unfortunate, but I think we can all see past that for the purposes of this discussion. This is part of meta-yocto which will at some point be it's own repository. So I don't agree with the assertion that it looks more like a poky the distro release. But it is the only component of the YP that gets released as part of the YP release, no? This release of angstrom builds on oe-core 2012.1, bitbake 1.something.x, which matches the YP 1.x release. OK. Donning my Yeah but I have a XYZ and things to get done hat, I think people will respond more positively to: Download the 1.2 Yocto Project release, add meta-angstrom to your bblayers.conf, and build $IMAGE_TARGET than they will to Download bitbake X.Y, Angstrom X.Y, OE Core X.Y, etc. instructions on setting up the layers, the local.conf, etc etc. I believe there are some other details the poky repository helps out with (someone more familiar with working with the individual components would have to enumerate these, I honestly don't know what they all are). And yes, there are the BSP layers to add to each of these scenarios, but that effects each equally. All that environment setup is something that can make or break the initial experience. I believe lots of users appreciate not having to pull all the pieces together themselves. (especially those that don't even know what they're not having to do!) And that's why angstrom (currently!) only supports setup using the angstrom setup-scripts. That contains all the logic that is needed to get the right versions. It also contains pretty much all known layers, so there's a high likelihood that users will never need to open bblayers.conf (either manually or using a script). If we move more things under the YP banner and convince subprojects to adopt the same schedule, we could make statements like: The Yocto Project 1.x release consist of the following modules: * bitbake 1.x * oe-core 2012.x * poky $DOTT_character * eglibc 2.17 * pseudo 1.2 * angstrom 2012.04 * meta-xilinx 6.5 ... etc With the exception of eglibc (I wouldn't want to have to list every package from oe-core and the layers!) this doesn't seem out of line to me. I was listing YP projects, not recipes/packages. I guess my point about a YP release needing to contain more than one yocto subproject got lost :( I think that would make it fit better with the umbrella project idea. consists might be a bad choice of words, I blame the unlimited coffee refills at the diner across the street :) And I blame any perceived snarkiness on the migraine and the 4 different medications the doc's got me on to try and patch me up to fly on Monday ;-) I hope you get well soon! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On 03/30/2012 05:53 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 17:28 heeft Darren Hart het volgende geschreven: On 03/30/2012 05:08 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven: [snip] On 03/30/2012 02:11 PM, Richard Purdie wrote: The criteria I see for being part of the Yocto Project are: a) Sharing the project's objectives (e.g. making embedded Liunx development easier) b) Willing to be part of the Yocto Project's governance structure c) Bringing something new/beneficial to the Yocto Project (often with mutual benefit) d) Have some kind of sustainable resource plan I'll take a couple careful steps into this arena to offer just one more possible criteria. One of the touted goals/advantages/benefits of using the Yocto Project is to work with a vetted set of sources that are known to all work together, having had some level of QA performed. This is something the poky repository accomplishes by bringing specifc versions of bitbake and oe-core together (along with some other tooling). At some point, this gets rolled up into a release of the Yocto Project: 0.9, 1.1, and soon 1.2. It's common for someone to refer to these release points as the base for their BSP. It therefor seems reasonable to me for a distribution definition (which is how I think of Angstrom - but feel free to correct me Koen) to make a statement like This release of Angstrom builds with the Yocto Project X.Y release. Yes, but see below I believe this is the sort of language that most outside developers would immediately understand and associate with being part of the Yocto Project. What does a 'yocto project release' actually mean? Right now it looks more like a 'poky (the distro) release'. Since angstrom builds on oe-core and bitbake directly the statement (in the current situation) would be more like: /me hands koen a real MUA that wraps at 80 characters... and wraps his mail for him... (everyone else gets a pass, but you? ;-) I see the poky distro definition as only a part of the poky repository, the naming is unfortunate, but I think we can all see past that for the purposes of this discussion. This is part of meta-yocto which will at some point be it's own repository. So I don't agree with the assertion that it looks more like a poky the distro release. But it is the only component of the YP that gets released as part of the YP release, no? This release of angstrom builds on oe-core 2012.1, bitbake 1.something.x, which matches the YP 1.x release. OK. Donning my Yeah but I have a XYZ and things to get done hat, I think people will respond more positively to: Download the 1.2 Yocto Project release, add meta-angstrom to your bblayers.conf, and build $IMAGE_TARGET than they will to Download bitbake X.Y, Angstrom X.Y, OE Core X.Y, etc. instructions on setting up the layers, the local.conf, etc etc. I believe there are some other details the poky repository helps out with (someone more familiar with working with the individual components would have to enumerate these, I honestly don't know what they all are). And yes, there are the BSP layers to add to each of these scenarios, but that effects each equally. All that environment setup is something that can make or break the initial experience. I believe lots of users appreciate not having to pull all the pieces together themselves. (especially those that don't even know what they're not having to do!) And that's why angstrom (currently!) only supports setup using the angstrom setup-scripts. That contains all the logic that is needed to get the right versions. It also contains pretty much all known layers, so there's a high likelihood that users will never need to open bblayers.conf (either manually or using a script). CTRL+R I wonder if there is something Angstrom could contribute to the Yocto Project in terms of setup scripts... If we move more things under the YP banner and convince subprojects to adopt the same schedule, we could make statements like: The Yocto Project 1.x release consist of the following modules: * bitbake 1.x * oe-core 2012.x * poky $DOTT_character * eglibc 2.17 * pseudo 1.2 * angstrom 2012.04 * meta-xilinx 6.5 ... etc With the exception of eglibc (I wouldn't want to have to list every package from oe-core and the layers!) this doesn't seem out of line to me. I was listing YP projects, not recipes/packages. I guess my point about a YP release needing to contain more than one yocto subproject got lost :( Ah yes, and I missed that eglibc is indeed listed on the official list of projects. http://www.yoctoproject.org/projects I don't think it's accurate to say that poky (the distro) is the only Yocto Project project that is released in the official releases. The list currently includes: Poky (bitbake, oe-core, meta-yocto) Perhaps the description could be
Re: [yocto] Moving angstrom under the yocto banner
Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven: So that brings us back to what does it mean for Angstrom to be a Yocto Project project I guess? In my very humble opinion (really), it still makes sense to build Angstrom with the components in the poky repository as part of a Yocto Project release. I understand that there is resistance to this idea. Yes, it would force angstrom developers to ignore upstream and work on downstream projects or as I will label them from now on: forks. Angstrom has been independent from poky and the Yocto Project in the past and I can understand not wanting to lose some of that individuality. However, too much individuality breeds chaos and fragmentation. I will draw a line in the sand here and say: Forcing people to ignore upstream (oe-core/bitbake) and force a fork down their throats breeds chaos and fragmentation. I will again refer to the agreement between the OE community and yocto for doing the 'merge'. If you people (all speaking personally of course) really think poky is the only way to go, then please close down and remove the oe-core and bitbake repos. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On Fri, Mar 30, 2012 at 7:27 PM, Darren Hart dvh...@linux.intel.com wrote: On 03/30/2012 06:37 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven: So that brings us back to what does it mean for Angstrom to be a Yocto Project project I guess? In my very humble opinion (really), it still makes sense to build Angstrom with the components in the poky repository as part of a Yocto Project release. I understand that there is resistance to this idea. Yes, it would force angstrom developers to ignore upstream and work on downstream projects That's an understandable concern. If I were a casual observer, I would expect every project identifying itself with the Yocto Project to interoperate with eachother at each release point. I would imagine that Angstrom developers would continue their feature development with the upstreams of bitbake and oe-core. As a Yocto Project release occurs (or shortly after, as is the case with many BSPs) I would then expect (again as a casual observer) that some effort went into ensuring some version of Angstrom works with the release of the poky repository. You've mentioned preferring to do this with set versions of bitbake and oe-core. Do oe-core and bitbake maintain stable branches? I didn't think they did. This makes it difficult to stabilize a release, and poky serves this purpose well in my opinion. I'm going to stop going down this path though as the policies surrounding this aren't clear to me and would be better coming from others (RP or Chris for example). Without this, people working with The Yocto Project are back to using different versions of bitbake and oe-core depending on which distribution or BSP they are building, and we ultimately end up where we started with unsolvable dependency chains and people passing around fixup patches for this or that issue. or as I will label them from now on: forks. Angstrom has been independent from poky and the Yocto Project in the past and I can understand not wanting to lose some of that individuality. However, too much individuality breeds chaos and fragmentation. I will draw a line in the sand here and say: Forcing people to ignore upstream (oe-core/bitbake) and force a fork down their throats breeds chaos and fragmentation. Don't be so dramatic Koen :-) Everybody involved knows the bitbake and oe-core in the poky repository are not forks, at least not in the sense you portray here. They are snapshots with the same maintainer (or subset of maintainers). They are no more forks than the stable Linux kernels maintained by Greg KH are forks of Linus' kernel. I won't presume to Not to be terribly pendatic or difficult here, but technically, the comparison you make here doesn't ring true. bitbake in poky *still* has changes that never went into the upstream repository. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Moving angstrom under the yocto banner
On 03/30/2012 08:00 PM, Chris Larson wrote: On Fri, Mar 30, 2012 at 7:27 PM, Darren Hart dvh...@linux.intel.com wrote: On 03/30/2012 06:37 PM, Koen Kooi wrote: Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven: So that brings us back to what does it mean for Angstrom to be a Yocto Project project I guess? In my very humble opinion (really), it still makes sense to build Angstrom with the components in the poky repository as part of a Yocto Project release. I understand that there is resistance to this idea. Yes, it would force angstrom developers to ignore upstream and work on downstream projects That's an understandable concern. If I were a casual observer, I would expect every project identifying itself with the Yocto Project to interoperate with eachother at each release point. I would imagine that Angstrom developers would continue their feature development with the upstreams of bitbake and oe-core. As a Yocto Project release occurs (or shortly after, as is the case with many BSPs) I would then expect (again as a casual observer) that some effort went into ensuring some version of Angstrom works with the release of the poky repository. You've mentioned preferring to do this with set versions of bitbake and oe-core. Do oe-core and bitbake maintain stable branches? I didn't think they did. This makes it difficult to stabilize a release, and poky serves this purpose well in my opinion. I'm going to stop going down this path though as the policies surrounding this aren't clear to me and would be better coming from others (RP or Chris for example). Without this, people working with The Yocto Project are back to using different versions of bitbake and oe-core depending on which distribution or BSP they are building, and we ultimately end up where we started with unsolvable dependency chains and people passing around fixup patches for this or that issue. or as I will label them from now on: forks. Angstrom has been independent from poky and the Yocto Project in the past and I can understand not wanting to lose some of that individuality. However, too much individuality breeds chaos and fragmentation. I will draw a line in the sand here and say: Forcing people to ignore upstream (oe-core/bitbake) and force a fork down their throats breeds chaos and fragmentation. Don't be so dramatic Koen :-) Everybody involved knows the bitbake and oe-core in the poky repository are not forks, at least not in the sense you portray here. They are snapshots with the same maintainer (or subset of maintainers). They are no more forks than the stable Linux kernels maintained by Greg KH are forks of Linus' kernel. I won't presume to Not to be terribly pendatic or difficult here, but technically, the comparison you make here doesn't ring true. bitbake in poky *still* has changes that never went into the upstream repository. I wasn't aware. Not knowing what they are, I'll have to leave a comment on those to others. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
