Re: [OE-core] Bringing an image from OE to OE-Core
2011/10/6 Saul Wold saul.w...@intel.com
On 10/05/2011 01:03 PM, Philip Balister wrote:
On 10/05/2011 03:35 PM, Khem Raj wrote:
On Wed, Oct 5, 2011 at 7:14 AM, Philip Balisterphi...@balister.org
wrote:
1) I do not want rpm in the image. This would confuse my customer base.
2) I am tired of dropbear, I want openssh only.
3) I need the full versions of tools, not the busybox ones.
4) I am not limited to gpv2 software.
Richard, it looks to me like we should add an item for the next Yocto
development cycle to review how images are built and try to make the
base
stuff in oe-core more usable by everyone. We need to define what
choices are
made by distros. For example opkg, rpm, no package management in image.
Images may want dropbear or openssh.
Short term, I think I'll copy the tasks/images into my bsp and get some
stuff together for testing. I'd like a better long term solution though.
There always will be customizations needed. But we can strive for
better basic blocks
Sure. The immediate things I noticed are rpm being installed and lack of
a way to chose between dropbear/openssh.
I think it is worth having a conversation to find out if when can make
it easier for users to create images, with a small number of knobs to
turn.
I agree, your 4 items above make sense and we could create a set of tasks
that can be use it as building blocks, I think that task-core-basic could be
a starting point for that.
We did work to enable the selection of either openssh/dropbear but at an
IMAGE_FEATURE level, not as a DISTRO_FEATURE or virtual.
Let's see what you come up with for your tasks and we can go from there.
Thanks
Sau!
The usability of tasks in general greatly depends on the use case you are
in.
To give an idea of our use case.
We make embedded systems to which the user only can interact in a specified
way. No online upgrading of packages let alone installing new ones (actually
some of the boards do not even have a network interface).
As we are limited on flash space our images are hand crafted, only to
contain those packages that we really need.
Wrt kernel: we hardly use modules, almost everything is configured into the
kernel (as we exactly know our hardware).
Then again if you have more space and or need to be more flexible tasks
definitely can have their merits. (especially when mapping machine features
to kernel modules etc).
For the specific case with dropbear.
OE classic task-base.bb contained
DISTRO_SSH_DAEMON ?= dropbear
and then used the variable in the image list
OE classic task-poky.bb hardcoded dropbear.
Personally I don't really see too much value in having the package in a var.
It is more work to type ${DISTRO_SSH_DAEMON} in the IMAGE-INSTALL than it is
to type dropbear or openssh.
Frans
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/04/2011 06:43 PM, Mark Hatle wrote: On 10/4/11 3:32 PM, Saul Wold wrote: On 10/04/2011 01:27 PM, Philip Balister wrote: On 10/04/2011 04:08 PM, Saul Wold wrote: On 10/04/2011 12:58 PM, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Philip, Have you looked at task-core-basic, it is supposed to be more of a desktop like set of tools, the idea being it's heavier weight than core, will move to supporting the non-graphical part of LSB. Another caveat for task-core-basic is that it's the largetest non-gplv3 task that is used by core-image-basic. Does this task approach what you are looking for? It looks like a start, but I notice it brings in rpm. I'm not sure if I want that. I would have thought that the package manager would be a distro decision. That's a bug that I would certainly take a patch for, unless rpm is required as part of LSB, that will need to be verified. The ability to install RPM packages is required by the LSB. The LSB does not require RPM however. (yes I know, odd requirement, but with things like alien it's doable on debian systems.) But yes, RPM is included to satisfy that requirement. This is beginning to look like a trickier problem than I would like. Between oe-core and meta-angstrom, there are a number of tasks/images to start from, but they each have something I don't like: 1) I do not want rpm in the image. This would confuse my customer base. 2) I am tired of dropbear, I want openssh only. 3) I need the full versions of tools, not the busybox ones. 4) I am not limited to gpv2 software. Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh. Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/5/11 9:14 AM, Philip Balister wrote: On 10/04/2011 06:43 PM, Mark Hatle wrote: On 10/4/11 3:32 PM, Saul Wold wrote: On 10/04/2011 01:27 PM, Philip Balister wrote: On 10/04/2011 04:08 PM, Saul Wold wrote: On 10/04/2011 12:58 PM, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Philip, Have you looked at task-core-basic, it is supposed to be more of a desktop like set of tools, the idea being it's heavier weight than core, will move to supporting the non-graphical part of LSB. Another caveat for task-core-basic is that it's the largetest non-gplv3 task that is used by core-image-basic. Does this task approach what you are looking for? It looks like a start, but I notice it brings in rpm. I'm not sure if I want that. I would have thought that the package manager would be a distro decision. That's a bug that I would certainly take a patch for, unless rpm is required as part of LSB, that will need to be verified. The ability to install RPM packages is required by the LSB. The LSB does not require RPM however. (yes I know, odd requirement, but with things like alien it's doable on debian systems.) But yes, RPM is included to satisfy that requirement. This is beginning to look like a trickier problem than I would like. Between oe-core and meta-angstrom, there are a number of tasks/images to start from, but they each have something I don't like: 1) I do not want rpm in the image. This would confuse my customer base. 2) I am tired of dropbear, I want openssh only. 3) I need the full versions of tools, not the busybox ones. 4) I am not limited to gpv2 software. Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh. Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. I'd suggest for now you try hob. It's capable of setting up image classes that can do exactly what you want.. selecting specific packages that must be on the target image and generating it. I think the key thing for oe-core is that we'll never have the right set of predefined images.. but we do need something so we can run the specific suite of tests to show that things are function, as well as give starting points. And I absolutely agree that we need to re-evaluate the configurations and come up with distribution flags (feature flags?) that can do things like enable/disable busybox, dropbear and other tooling. (GPLv2 packages are only built if you've excluded GPLv3 from your build.. otherwise the latest/greatest version is defaulted to on.) --Mark Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
Op 5 okt. 2011 om 09:14 heeft Philip Balister phi...@balister.org het volgende geschreven: On 10/04/2011 06:43 PM, Mark Hatle wrote: On 10/4/11 3:32 PM, Saul Wold wrote: On 10/04/2011 01:27 PM, Philip Balister wrote: On 10/04/2011 04:08 PM, Saul Wold wrote: On 10/04/2011 12:58 PM, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Philip, Have you looked at task-core-basic, it is supposed to be more of a desktop like set of tools, the idea being it's heavier weight than core, will move to supporting the non-graphical part of LSB. Another caveat for task-core-basic is that it's the largetest non-gplv3 task that is used by core-image-basic. Does this task approach what you are looking for? It looks like a start, but I notice it brings in rpm. I'm not sure if I want that. I would have thought that the package manager would be a distro decision. That's a bug that I would certainly take a patch for, unless rpm is required as part of LSB, that will need to be verified. The ability to install RPM packages is required by the LSB. The LSB does not require RPM however. (yes I know, odd requirement, but with things like alien it's doable on debian systems.) But yes, RPM is included to satisfy that requirement. This is beginning to look like a trickier problem than I would like. Between oe-core and meta-angstrom, there are a number of tasks/images to start from, but they each have something I don't like: 1) I do not want rpm in the image. This would confuse my customer base. 2) I am tired of dropbear, I want openssh only. fwiw 0.53 fixed most of my problems (e.g x11 forwarding), does it fix your issues as well? 3) I need the full versions of tools, not the busybox ones. 4) I am not limited to gpv2 software. Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh. Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
Hi Philip, Le 05/10/2011 16:14, Philip Balister a écrit : Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. that's what we also did here to get the wanted result without using standard variables which bring too much things in the image. Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
Hi Philip, Le 05/10/2011 16:14, Philip Balister a écrit : Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. that's what we also did here to get the wanted result without using standard variables which bring too much things in the image. Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister phi...@balister.org wrote: 1) I do not want rpm in the image. This would confuse my customer base. 2) I am tired of dropbear, I want openssh only. 3) I need the full versions of tools, not the busybox ones. 4) I am not limited to gpv2 software. Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh. Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. There always will be customizations needed. But we can strive for better basic blocks ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/05/2011 03:35 PM, Khem Raj wrote: On Wed, Oct 5, 2011 at 7:14 AM, Philip Balisterphi...@balister.org wrote: 1) I do not want rpm in the image. This would confuse my customer base. 2) I am tired of dropbear, I want openssh only. 3) I need the full versions of tools, not the busybox ones. 4) I am not limited to gpv2 software. Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh. Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. There always will be customizations needed. But we can strive for better basic blocks Sure. The immediate things I noticed are rpm being installed and lack of a way to chose between dropbear/openssh. I think it is worth having a conversation to find out if when can make it easier for users to create images, with a small number of knobs to turn. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On Wed, 2011-10-05 at 16:03 -0400, Philip Balister wrote: On 10/05/2011 03:35 PM, Khem Raj wrote: On Wed, Oct 5, 2011 at 7:14 AM, Philip Balisterphi...@balister.org wrote: 1) I do not want rpm in the image. This would confuse my customer base. 2) I am tired of dropbear, I want openssh only. 3) I need the full versions of tools, not the busybox ones. 4) I am not limited to gpv2 software. Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh. Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. There always will be customizations needed. But we can strive for better basic blocks Sure. The immediate things I noticed are rpm being installed and lack of a way to chose between dropbear/openssh. Core images automatically include the correct package manager when the image feature package-management is defined for the image. It would be nice to define a variable/feature to control SSH server. Regards, Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/05/2011 01:03 PM, Philip Balister wrote: On 10/05/2011 03:35 PM, Khem Raj wrote: On Wed, Oct 5, 2011 at 7:14 AM, Philip Balisterphi...@balister.org wrote: 1) I do not want rpm in the image. This would confuse my customer base. 2) I am tired of dropbear, I want openssh only. 3) I need the full versions of tools, not the busybox ones. 4) I am not limited to gpv2 software. Richard, it looks to me like we should add an item for the next Yocto development cycle to review how images are built and try to make the base stuff in oe-core more usable by everyone. We need to define what choices are made by distros. For example opkg, rpm, no package management in image. Images may want dropbear or openssh. Short term, I think I'll copy the tasks/images into my bsp and get some stuff together for testing. I'd like a better long term solution though. There always will be customizations needed. But we can strive for better basic blocks Sure. The immediate things I noticed are rpm being installed and lack of a way to chose between dropbear/openssh. I think it is worth having a conversation to find out if when can make it easier for users to create images, with a small number of knobs to turn. I agree, your 4 items above make sense and we could create a set of tasks that can be use it as building blocks, I think that task-core-basic could be a starting point for that. We did work to enable the selection of either openssh/dropbear but at an IMAGE_FEATURE level, not as a DISTRO_FEATURE or virtual. Let's see what you come up with for your tasks and we can go from there. Thanks Sau! Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Bringing an image from OE to OE-Core
I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Should I add task-proper-tools to meta-oe, or is there a better way to add a full features set of tools to an image? Basically, the image is more desktop like than embedded. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On Tue, Oct 4, 2011 at 12:58 PM, Philip Balister phi...@balister.org wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Should I add task-proper-tools to meta-oe, or is there a better way to add a full features set of tools to an image? Basically, the image is more desktop like than embedded. there are meta stuff like tools-debug, tools-sdk in oe-core. See if you can use them to construct your image. If it seems a common enough subset that can be used in multiple images then you could add the task to meta-oe like we have for task-cli-tools but a good judgment would be appropriate. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/04/2011 12:58 PM, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Philip, Have you looked at task-core-basic, it is supposed to be more of a desktop like set of tools, the idea being it's heavier weight than core, will move to supporting the non-graphical part of LSB. Another caveat for task-core-basic is that it's the largetest non-gplv3 task that is used by core-image-basic. Does this task approach what you are looking for? Sau! Should I add task-proper-tools to meta-oe, or is there a better way to add a full features set of tools to an image? Basically, the image is more desktop like than embedded. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/04/2011 04:08 PM, Saul Wold wrote: On 10/04/2011 12:58 PM, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Philip, Have you looked at task-core-basic, it is supposed to be more of a desktop like set of tools, the idea being it's heavier weight than core, will move to supporting the non-graphical part of LSB. Another caveat for task-core-basic is that it's the largetest non-gplv3 task that is used by core-image-basic. Does this task approach what you are looking for? It looks like a start, but I notice it brings in rpm. I'm not sure if I want that. I would have thought that the package manager would be a distro decision. Philip Sau! Should I add task-proper-tools to meta-oe, or is there a better way to add a full features set of tools to an image? Basically, the image is more desktop like than embedded. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On Tue, 2011-10-04 at 15:58 -0400, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Should I add task-proper-tools to meta-oe, or is there a better way to add a full features set of tools to an image? Basically, the image is more desktop like than embedded. The core-image-lsb is the OE-Core image with the full fat tools included. I'd suggest starting from that and see what is missing. I'd also note we have IMAGE_FEATURES which you can add tools-sdk to which may or may not include more of what you want (basically a development toolchain+tools). CHeers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/04/2011 01:27 PM, Philip Balister wrote: On 10/04/2011 04:08 PM, Saul Wold wrote: On 10/04/2011 12:58 PM, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Philip, Have you looked at task-core-basic, it is supposed to be more of a desktop like set of tools, the idea being it's heavier weight than core, will move to supporting the non-graphical part of LSB. Another caveat for task-core-basic is that it's the largetest non-gplv3 task that is used by core-image-basic. Does this task approach what you are looking for? It looks like a start, but I notice it brings in rpm. I'm not sure if I want that. I would have thought that the package manager would be a distro decision. That's a bug that I would certainly take a patch for, unless rpm is required as part of LSB, that will need to be verified. Sau! Philip Sau! Should I add task-proper-tools to meta-oe, or is there a better way to add a full features set of tools to an image? Basically, the image is more desktop like than embedded. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Bringing an image from OE to OE-Core
On 10/4/11 3:32 PM, Saul Wold wrote: On 10/04/2011 01:27 PM, Philip Balister wrote: On 10/04/2011 04:08 PM, Saul Wold wrote: On 10/04/2011 12:58 PM, Philip Balister wrote: I'm about to start bringing some images I use from OE to OE-core. The first issue I saw is there is no task-proper-tools in oe-core (where oe-core means the set of layers created by the Angstrom setup scripts). Philip, Have you looked at task-core-basic, it is supposed to be more of a desktop like set of tools, the idea being it's heavier weight than core, will move to supporting the non-graphical part of LSB. Another caveat for task-core-basic is that it's the largetest non-gplv3 task that is used by core-image-basic. Does this task approach what you are looking for? It looks like a start, but I notice it brings in rpm. I'm not sure if I want that. I would have thought that the package manager would be a distro decision. That's a bug that I would certainly take a patch for, unless rpm is required as part of LSB, that will need to be verified. The ability to install RPM packages is required by the LSB. The LSB does not require RPM however. (yes I know, odd requirement, but with things like alien it's doable on debian systems.) But yes, RPM is included to satisfy that requirement. --Mark Sau! Philip Sau! Should I add task-proper-tools to meta-oe, or is there a better way to add a full features set of tools to an image? Basically, the image is more desktop like than embedded. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
