* packages versioning
@ 2011-12-09 2:57 Mr Dash Four
2011-12-09 3:17 ` Chris Larson
0 siblings, 1 reply; 11+ messages in thread
From: Mr Dash Four @ 2011-12-09 2:57 UTC (permalink / raw)
To: openembedded-devel
Is there a way I could force/select a particular version of a specific
package in a given target?
I am building my fso-console-image and I would like it to use udev-165
instead of udev-162, but I can't find a way to alter this. I could build
udev-165 separately - no problem, but don't know how to integrate this
into the main task of building the image itself.
Also, is there a way I can include additional packages as part of that
fso-console-image build? I'd like to have openvpn, a different version
of wpa_supplicant, openssl etc.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 2:57 packages versioning Mr Dash Four
@ 2011-12-09 3:17 ` Chris Larson
2011-12-09 12:59 ` Mr Dash Four
2011-12-10 18:29 ` Mr Dash Four
0 siblings, 2 replies; 11+ messages in thread
From: Chris Larson @ 2011-12-09 3:17 UTC (permalink / raw)
To: openembedded-devel
On Thu, Dec 8, 2011 at 7:57 PM, Mr Dash Four
<mr.dash.four@googlemail.com> wrote:
> Is there a way I could force/select a particular version of a specific
> package in a given target?
>
> I am building my fso-console-image and I would like it to use udev-165
> instead of udev-162, but I can't find a way to alter this. I could build
> udev-165 separately - no problem, but don't know how to integrate this into
> the main task of building the image itself.
PREFERRED_VERSION_udev = "165"
> Also, is there a way I can include additional packages as part of that
> fso-console-image build? I'd like to have openvpn, a different version of
> wpa_supplicant, openssl etc.
IMAGE_INSTALL_append = " openvpn"
-- Christopher Larson
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 3:17 ` Chris Larson
@ 2011-12-09 12:59 ` Mr Dash Four
2011-12-09 13:35 ` Koen Kooi
2011-12-10 18:29 ` Mr Dash Four
1 sibling, 1 reply; 11+ messages in thread
From: Mr Dash Four @ 2011-12-09 12:59 UTC (permalink / raw)
To: openembedded-devel
>> Is there a way I could force/select a particular version of a specific
>> package in a given target?
>>
>> I am building my fso-console-image and I would like it to use udev-165
>> instead of udev-162, but I can't find a way to alter this. I could build
>> udev-165 separately - no problem, but don't know how to integrate this into
>> the main task of building the image itself.
>>
>
> PREFERRED_VERSION_udev = "165"
>
>
>> Also, is there a way I can include additional packages as part of that
>> fso-console-image build? I'd like to have openvpn, a different version of
>> wpa_supplicant, openssl etc.
>>
>
> IMAGE_INSTALL_append = " openvpn"
>
Superb, thank you! One more query regarding this - how do I remove
packages I do not want included in the final image? Is there a way to do
that (fairly) easily?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 12:59 ` Mr Dash Four
@ 2011-12-09 13:35 ` Koen Kooi
2011-12-09 15:59 ` Mr Dash Four
0 siblings, 1 reply; 11+ messages in thread
From: Koen Kooi @ 2011-12-09 13:35 UTC (permalink / raw)
To: openembedded-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Op 09-12-11 13:59, Mr Dash Four schreef:
>
>>> Is there a way I could force/select a particular version of a
>>> specific package in a given target?
>>>
>>> I am building my fso-console-image and I would like it to use
>>> udev-165 instead of udev-162, but I can't find a way to alter this. I
>>> could build udev-165 separately - no problem, but don't know how to
>>> integrate this into the main task of building the image itself.
>>>
>>
>> PREFERRED_VERSION_udev = "165"
>>
>>
>>> Also, is there a way I can include additional packages as part of
>>> that fso-console-image build? I'd like to have openvpn, a different
>>> version of wpa_supplicant, openssl etc.
>>>
>>
>> IMAGE_INSTALL_append = " openvpn"
>>
> Superb, thank you! One more query regarding this - how do I remove
> packages I do not want included in the final image? Is there a way to do
> that (fairly) easily?
Yes, create your own image recipe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAk7iDqoACgkQMkyGM64RGpE03wCfcIs3EgRCInV/7UR4HHhslFZN
57kAoKbY+qE+wCxTLMQbEczLYiSr+a+u
=4Wsq
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 13:35 ` Koen Kooi
@ 2011-12-09 15:59 ` Mr Dash Four
2011-12-09 16:15 ` Mark Hatle
0 siblings, 1 reply; 11+ messages in thread
From: Mr Dash Four @ 2011-12-09 15:59 UTC (permalink / raw)
To: openembedded-devel
>> One more query regarding this - how do I remove
>> packages I do not want included in the final image? Is there a way to do
>> that (fairly) easily?
>>
>
> Yes, create your own image recipe.
>
I was hoping that there is an easier option ("(fairly) easily" being the
keywords here)!
I tried to trace where these packages are derived from, but could not
find anything. For example, I'd like to remove ash (and possibly the
whole BusyBox setup) and replace it with bash and their package
equivalents. By looking at the tasks/ as well as images/ directories I
couldn't find where these packages are derived from, hence the above
question.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 15:59 ` Mr Dash Four
@ 2011-12-09 16:15 ` Mark Hatle
2011-12-09 18:57 ` Mr Dash Four
0 siblings, 1 reply; 11+ messages in thread
From: Mark Hatle @ 2011-12-09 16:15 UTC (permalink / raw)
To: openembedded-devel
On 12/9/11 9:59 AM, Mr Dash Four wrote:
>
>>> One more query regarding this - how do I remove
>>> packages I do not want included in the final image? Is there a way to do
>>> that (fairly) easily?
>>>
>>
>> Yes, create your own image recipe.
>>
> I was hoping that there is an easier option ("(fairly) easily" being the
> keywords here)!
>
> I tried to trace where these packages are derived from, but could not
> find anything. For example, I'd like to remove ash (and possibly the
> whole BusyBox setup) and replace it with bash and their package
> equivalents. By looking at the tasks/ as well as images/ directories I
> couldn't find where these packages are derived from, hence the above
> question.
The creation of the filesystem image is driven by a number of components.
Basically it works like this:
You select an image to build. The image sets a few flags and a basic set of
requirements. The image inherits the core-image.bbclass.
The core-image.bbclass uses the flags, machine settings and extra settings to
determine a list of actual dependencies. Most of these dependencies are broken
into groups. Some of the groups are individual sets of recipes, while most are
actually tasks.
The tasks themselves are broken down into functional areas. These functional
areas are designed to give you control at a "functional" level, designed to
assist people who really aren't sure exactly what source packages to start from.
If you look for a list of the tasks you can see the breakdown and components.
In the recipes-extended, there is a set of core-tasks. These tasks allow you to
build up a system starting with busybox, and slowly add to it and replace
busybox with the discrete components from util-linux, coreutils, etc.
I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of the
current breakdowns. If you are interested send me an email off list.
--Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 16:15 ` Mark Hatle
@ 2011-12-09 18:57 ` Mr Dash Four
2011-12-09 19:06 ` Gary Thomas
2011-12-09 20:14 ` Mark Hatle
0 siblings, 2 replies; 11+ messages in thread
From: Mr Dash Four @ 2011-12-09 18:57 UTC (permalink / raw)
To: openembedded-devel
> The creation of the filesystem image is driven by a number of
> components. Basically it works like this:
Thanks a lot for that - a good insight into the workings of oe and
bitbake. I was hoping there would be an easier way to configure/change
this to what I want, but I see that it is much more complex than I
thought initially.
> I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of
> the current breakdowns. If you are interested send me an email off list.
I am interested (excel would be nice, thanks), but don't know your email
address (all I get when responding to 'all' is the mailing list email
address) - if you know mine, you could send me that and I'll have a look.
I take it there isn't an easy way to see the hierarchy of all
packages/dependencies involved in a particular image, is it (your
spreadsheet may be good, but I suppose it is static and reflects just a
current snapshot of a given packages/dependencies and that might change)?
If all else fails, I might use ipkg on the target system to uninstall
the packages I don't need and install new ones - not ideal by any means,
but this is what I'll do only as a last resort, if all else fails.
Thanks again for the thorough response!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 18:57 ` Mr Dash Four
@ 2011-12-09 19:06 ` Gary Thomas
2011-12-09 20:14 ` Mark Hatle
1 sibling, 0 replies; 11+ messages in thread
From: Gary Thomas @ 2011-12-09 19:06 UTC (permalink / raw)
To: openembedded-devel
On 2011-12-09 11:57, Mr Dash Four wrote:
>
>> The creation of the filesystem image is driven by a number of components. Basically it works like this:
> Thanks a lot for that - a good insight into the workings of oe and bitbake. I was hoping there would be an easier way to configure/change this to what I want, but I see that it is
> much more complex than I thought initially.
>
>> I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of the current breakdowns. If you are interested send me an email off list.
> I am interested (excel would be nice, thanks), but don't know your email address (all I get when responding to 'all' is the mailing list email address) - if you know mine, you
> could send me that and I'll have a look.
>
> I take it there isn't an easy way to see the hierarchy of all packages/dependencies involved in a particular image, is it (your spreadsheet may be good, but I suppose it is static
> and reflects just a current snapshot of a given packages/dependencies and that might change)?
>
> If all else fails, I might use ipkg on the target system to uninstall the packages I don't need and install new ones - not ideal by any means, but this is what I'll do only as a
> last resort, if all else fails. Thanks again for the thorough response!
You can also use 'bitbake -u hob' which will let you interactively
build and modify images.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 18:57 ` Mr Dash Four
2011-12-09 19:06 ` Gary Thomas
@ 2011-12-09 20:14 ` Mark Hatle
2011-12-09 20:46 ` Mr Dash Four
1 sibling, 1 reply; 11+ messages in thread
From: Mark Hatle @ 2011-12-09 20:14 UTC (permalink / raw)
To: openembedded-devel
On 12/9/11 12:57 PM, Mr Dash Four wrote:
>
>> The creation of the filesystem image is driven by a number of
>> components. Basically it works like this:
> Thanks a lot for that - a good insight into the workings of oe and
> bitbake. I was hoping there would be an easier way to configure/change
> this to what I want, but I see that it is much more complex than I
> thought initially.
Ya, I created the spreadsheet due to the complexity.. :( I like the flexibility
of the components that are used to construct the image packages, but there has
to be a more transparent way of doing this.
>> I have a spreadsheet (OpenOffice 17k, or Excel 81k) that lists all of
>> the current breakdowns. If you are interested send me an email off list.
> I am interested (excel would be nice, thanks), but don't know your email
> address (all I get when responding to 'all' is the mailing list email
> address) - if you know mine, you could send me that and I'll have a look.
(Sent as a private email)
> I take it there isn't an easy way to see the hierarchy of all
> packages/dependencies involved in a particular image, is it (your
> spreadsheet may be good, but I suppose it is static and reflects just a
> current snapshot of a given packages/dependencies and that might change)?
>
> If all else fails, I might use ipkg on the target system to uninstall
> the packages I don't need and install new ones - not ideal by any means,
> but this is what I'll do only as a last resort, if all else fails.
> Thanks again for the thorough response!
As Gary suggested in another email, "hob" is the best approach right now.
You can certainly remove binary packages after the fact, but it's much nicer to
not have to.
--Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 20:14 ` Mark Hatle
@ 2011-12-09 20:46 ` Mr Dash Four
0 siblings, 0 replies; 11+ messages in thread
From: Mr Dash Four @ 2011-12-09 20:46 UTC (permalink / raw)
To: openembedded-devel
> Ya, I created the spreadsheet due to the complexity.. :( I like the
> flexibility of the components that are used to construct the image
> packages, but there has to be a more transparent way of doing this.
I concur. I am starting to like oe and its flexibility, but it is a hell
of a steep curve at first to take on...particularly for people like me
that have little-to-no experience of oe.
> (Sent as a private email)
Got it, thanks a lot - will look at it tomorrow in more detail.
> As Gary suggested in another email, "hob" is the best approach right now.
I'll try that as well - it would be nice to see where all these
dependencies/packages come from, because for my (admittedly, rather
limited) case I won't need half the packages installed on that image,
but OTOH would need to add a few additions of my own to what is already
'included', so it is quite a change. I also plan to create one or two
new recipes for packages worth including (particularly for small systems
like the console image I am trying to build).
What is the policy of submitting patches on here - I followed the debate
about oe-classic/oe-core, but am still unclear if I want to submit
patches (I am working with oe-classic - so I am told) what should I base
against these?
> You can certainly remove binary packages after the fact, but it's much
> nicer to not have to.
Indeed and it is the reason for asking here first as I always believe
there must be more intelligent and elegant solution to this than hacking
the target system (which I'll have to do each time I
build/update/upgrade that image).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: packages versioning
2011-12-09 3:17 ` Chris Larson
2011-12-09 12:59 ` Mr Dash Four
@ 2011-12-10 18:29 ` Mr Dash Four
1 sibling, 0 replies; 11+ messages in thread
From: Mr Dash Four @ 2011-12-10 18:29 UTC (permalink / raw)
To: openembedded-devel
> PREFERRED_VERSION_udev = "165"
>
OK, hit a bit of a snag:
PREFERRED_VERSION_wpa-supplicant = "0.7.3"
but this still produces wpa-supplicant_0.6.9-r6.1.6_armv6-novfp.ipk and
wpa-supplicant-passphrase_0.6.9-r6.1.6_armv6-novfp.ipk. The recipe for
wpa-supplicant_0.7.3 is there, don't know why isn't used/included. Any
ideas on what I am doing wrong?
I also found two more errors when trying to include/compile
xtables-addons - there are two versions available in oe - 1.26 & 1.28. I
was planning to adapt the newest one (1.28) to compile the latest
xtables-addons, as well as be able to customise the various modules
which are included by "default" in this recipe, though I get the
following errors which prevent building this package and including it
into the image:
v1.28:
~~~~
ERROR: Task do_unpack in
/home/mr-4/oe/openembedded/recipes/xtables-addons/xtables-addons_1.28.bb
depends upon nonexistant task do_populate_staging in
virtual:native:/home/mr-4/oe/openembedded/recipes/xz/xz_5.0.0.bb
I first thought that there is a dependency missed for including "xz",
but even if I include this in my local.conf I still get the above error.
Any idea what is causing this?
v1.26:
~~~~~
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
arm-oe-linux-gnueabi-ld: use the --help option for usage information
That, I suppose, comes from the make linker flags. I am not sure this
should be included there (shoudn't that be just "-O1"?).
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-12-10 18:36 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-09 2:57 packages versioning Mr Dash Four
2011-12-09 3:17 ` Chris Larson
2011-12-09 12:59 ` Mr Dash Four
2011-12-09 13:35 ` Koen Kooi
2011-12-09 15:59 ` Mr Dash Four
2011-12-09 16:15 ` Mark Hatle
2011-12-09 18:57 ` Mr Dash Four
2011-12-09 19:06 ` Gary Thomas
2011-12-09 20:14 ` Mark Hatle
2011-12-09 20:46 ` Mr Dash Four
2011-12-10 18:29 ` Mr Dash Four
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.