So I needed to downgrade the version of my gzip package in Ubuntu 10.04 because it wouldn't work with my openembedded build (I was getting errors unpacking the expat tarball). What I ended up doing was adding the "hardy" packages to my list of sources through the software sources gui (deb http://security.ubuntu.com/ubuntu hardy-security main). Then I followed the instructions here to find the older version of gzip and downgrade it. Now my build works. Basically what I did was:
1. System->Administration->Software Sources
2. Go to Other software and click Add
3. Add the line above (deb http://security.ubuntu.com/ubuntu hardy-security main)
4. Click close and allow it to rebuild the database.
5. run apt-cache showpkg gzip
6. You'll see the versions. You want the 1.3.12-3.2ubuntu0.1 version
7. run sudo apt-get install gzip=1.3.12-3.2ubuntu0.1
8. Select yes when asked if you want to downgrade.
Tuesday, July 20, 2010
Friday, July 9, 2010
A quick note on conf files
So I wanted to have my own configuration file in OE that I could use to specify things like which packages to make source ipks for or what my PREFERRED_PROVIDERs were for things like the virtual/kernel package.
This let me to the question of how can I easily add a new configuration file? I figured that some files must just be picked up automatically but was it really just as simple as adding another line to something like my local.conf? The simple answer is YES.
You can just add a line like:
include/.conf
The only thing to be aware of is that you can either "include" a configuration file, which means that it will be used if it exists but if it doesn't exist that's OK. Or you can "require" a configuration file, which as the name implies means it has to be present or you will get an error.
As for adding a configuration file "automatically" I'm not sure how to do that and I have it on good advice that you don't want to do that. I guess I can understand that because it is nice to know explicitly how something got added and forget all the automagical stuff.
This let me to the question of how can I easily add a new configuration file? I figured that some files must just be picked up automatically but was it really just as simple as adding another line to something like my local.conf? The simple answer is YES.
You can just add a line like:
include
The only thing to be aware of is that you can either "include" a configuration file, which means that it will be used if it exists but if it doesn't exist that's OK. Or you can "require" a configuration file, which as the name implies means it has to be present or you will get an error.
As for adding a configuration file "automatically" I'm not sure how to do that and I have it on good advice that you don't want to do that. I guess I can understand that because it is nice to know explicitly how something got added and forget all the automagical stuff.
Thursday, July 8, 2010
What does virtual/xyz point to?
Often I see things in recipes where they rely on things like "virtual/kernel". But how do I know what bitbake recipe virtual/kernel points to?
Usually you can find this information in the machine configuration file. This isn't always guaranteed, it could be stashed in some other configuration file like the distro configuration file (i.e. Angstrom defines the PREFERRED_PROVIDER_virtual/update-alternatives)
In the case of the dm3730-am3715-evm machine type its configuration file specifies:
PREFERRED_PROVIDER_virtual/kernel = "linux-omap-psp"
This tells me that if I were to "bitbake virtual/kernel" it would look for the latest linux-omap-psp recipe and build that with the exception of whether or not that recipe set DEFAULT_PREFERENCE to -1. If so then it would look for the next version of linux-omap-psp.
So in general the virtual/xyz values are set in the configuration files. You could of course always just "bitbake virtual/xyz" and see what it builds, but if you have a slow system like mine sometime you want to know without waiting on a build :)
Usually you can find this information in the machine configuration file. This isn't always guaranteed, it could be stashed in some other configuration file like the distro configuration file (i.e. Angstrom defines the PREFERRED_PROVIDER_virtual/update-alternatives)
In the case of the dm3730-am3715-evm machine type its configuration file specifies:
PREFERRED_PROVIDER_virtual/kernel = "linux-omap-psp"
This tells me that if I were to "bitbake virtual/kernel" it would look for the latest linux-omap-psp recipe and build that with the exception of whether or not that recipe set DEFAULT_PREFERENCE to -1. If so then it would look for the next version of linux-omap-psp.
So in general the virtual/xyz values are set in the configuration files. You could of course always just "bitbake virtual/xyz" and see what it builds, but if you have a slow system like mine sometime you want to know without waiting on a build :)
What is SOC_FAMILY?
So I was playing around with adding new tasks for the dm3730-am3715-evm machine type (I'll be submitting patches for these soon) and I was getting really annoyed because I kept picking up packages that I didn't want. For example I had the following section in one of my tasks:
MULTIMEDIA = ""
MULTIMEDIA_omap3 = " \
ti-dmai-apps \
ti-codec-engine-examples \
task-arago-gst \
gstreamer-ti \
"
RDEPENDS_${PN} = "\
${MULTIMEDIA} \
"
I was expecting that since I didn't have a MULTIMEDIA_dm3730-am3715-evm variable defined that I would pick up the default MULTIMEDIA line and there would be no RDEPENDS setting. Instead I kept getting the omap3 settings which was trying to build packages I didn't want.
So I dug into the conf/machine/dm3730-am3715-evm.conf file and noticed that it included the omap3.inc file which sets SOC_FAMILY to omap3. This gave me my insight into what was happening. The omap3 lines were getting picked up because the dm3730-am3715-evm section was empty. Basically the order was MACHINE -> SOC_FAMILY -> DEFAULT.
I'm sure this is somewhat simplified, but it gets the point across. Basically as I see it the SOC_FAMILY is a good way to specify variables for an entire family of devices without having to say XYZ_dev1, XYZ_dev2, etc and set them all the same.
MULTIMEDIA = ""
MULTIMEDIA_omap3 = " \
ti-dmai-apps \
ti-codec-engine-examples \
task-arago-gst \
gstreamer-ti \
"
RDEPENDS_${PN} = "\
${MULTIMEDIA} \
"
I was expecting that since I didn't have a MULTIMEDIA_dm3730-am3715-evm variable defined that I would pick up the default MULTIMEDIA line and there would be no RDEPENDS setting. Instead I kept getting the omap3 settings which was trying to build packages I didn't want.
So I dug into the conf/machine/dm3730-am3715-evm.conf file and noticed that it included the omap3.inc file which sets SOC_FAMILY to omap3. This gave me my insight into what was happening. The omap3 lines were getting picked up because the dm3730-am3715-evm section was empty. Basically the order was MACHINE -> SOC_FAMILY -> DEFAULT.
I'm sure this is somewhat simplified, but it gets the point across. Basically as I see it the SOC_FAMILY is a good way to specify variables for an entire family of devices without having to say XYZ_dev1, XYZ_dev2, etc and set them all the same.
Subscribe to:
Posts (Atom)