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
Quoted 7 lines · Philip Balister
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.
Quoted 8 lines
Philip
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 4 lines · Philip Balister
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!
Quoted 11 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 7 lines · Saul Wold
Quoted 4 lines · Philip Balister
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,
Quoted 8 lines
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
Quoted 17 lines
Sau!
Quoted 11 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 12 lines · Philip Balister
Quoted 11 lines · Saul Wold
Quoted 4 lines · Philip Balister
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.
Quoted 9 lines
Quoted 4 lines
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!
Quoted 26 lines
Philip
Quoted 17 lines
Sau!
Quoted 11 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 16 lines · Saul Wold
Quoted 15 lines · Philip Balister
Quoted 14 lines · Saul Wold
Quoted 4 lines · Philip Balister
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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
Quoted 34 lines
Sau!
Quoted 21 lines
Philip
Quoted 17 lines
Sau!
Quoted 11 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreQuoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 23 lines · Mark Hatle
Quoted 22 lines · Saul Wold
Quoted 21 lines · Philip Balister
Quoted 7 lines · Saul Wold
Quoted 4 lines · Philip Balister
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,
Quoted 8 lines
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.
Quoted 8 lines
Quoted 2 lines
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
Quoted 42 lines · Philip Balister
Quoted 23 lines · Mark Hatle
Quoted 22 lines · Saul Wold
Quoted 21 lines · Philip Balister
Quoted 7 lines · Saul Wold
Quoted 4 lines · Philip Balister
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,
Quoted 8 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 8 lines
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
Quoted 1 line
Philip
Op 5 okt. 2011 om 09:14 heeft Philip Balister <[email protected]> het volgende geschreven:
Quoted 31 lines · Mark Hatle
Quoted 30 lines · Saul Wold
Quoted 16 lines · Philip Balister
Quoted 15 lines · Saul Wold
Quoted 14 lines · Philip Balister
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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.)
Quoted 6 lines
Quoted 1 line
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?
Quoted 13 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 35 lines · Koen Kooi
Op 5 okt. 2011 om 09:14 heeft Philip Balister<[email protected]> het volgende geschreven:
Quoted 31 lines · Mark Hatle
Quoted 30 lines · Saul Wold
Quoted 16 lines · Philip Balister
Quoted 15 lines · Saul Wold
Quoted 14 lines · Philip Balister
Quoted 4 lines
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.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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.)
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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?
It is more that users know openssh and sometimes have issues with dropbear. And image size is not an issue.
Philip
Hi Philip,
Quoted 3 lines · Philip Balister
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
Hi Philip,
Quoted 3 lines · Philip Balister
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
Quoted 6 lines · Philip Balister
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.
Quoted 8 lines
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
Quoted 13 lines · Khem Raj
Quoted 12 lines · Philip Balister
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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 14 lines · Philip Balister
Quoted 13 lines · Khem Raj
Quoted 12 lines · Philip Balister
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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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
Signature · 3 lines
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology CentreQuoted 5 lines · Joshua Lock
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.
virtual providers could help here.
Quoted 20 lines · Philip Balister
Quoted 19 lines · Khem Raj
Quoted 16 lines · Philip Balister
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.
Quoted 9 lines
Quoted 2 lines
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!
Quoted 7 lines
Philip
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
2011/10/6 Saul Wold <[email protected]>
Quoted 43 lines · Philip Balister
Quoted 28 lines · Khem Raj
Quoted 18 lines
Quoted 14 lines · Philip Balister
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.Quoted 7 lines
Quoted 3 lines
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
Quoted 8 lines
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_FEATURElevel, not as aDISTRO_FEATUREor virtual.
Quoted 6 lines
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 containedDISTRO_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
Quoted 7 lines · Philip Balister
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