Changes between Initial Version and Version 1 of Yocto/packages


Ignore:
Timestamp:
10/22/2017 05:28:45 AM (5 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Yocto/packages

    v1 v1  
     1[[PageOutline]]
     2
     3= Yocto Packages =
     4
     5Please read the great Yocto Reference manual before proceeding:
     6 * [http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html Yocto 1.6 Developer Reference Manual]
     7
     8Often a developer will want to add a new package such as tcpdump or openvpn, or other standard packages.
     9
     10There are presumably many ways to do this, some of which are better than others.
     11
     12
     13== GUI Method ==
     14A GUI for bitbake is called Hob.  See more information [https://www.yoctoproject.org/documentation/hob-manual here]
     15
     16
     17== Package Feed types ==
     18Note that packages are split into feeds based on their type called 'feeds'
     19
     20On the target, the /etc/opkg/arch.conf file lists all types appropriate for your target and prioritizes them in case a package exists in multiple feeds.
     21
     22On the build host, packages are placed into directories for each feed.
     23
     24Some examples of standard feeds include:
     25 * all - packages that are applicable for '''all''' targets (ie scripts, text files, cross-platform data files)
     26 * armv7a - packages that are applicable for the armv7a instruction set only (ie compiled applications)
     27 * armv7a-vfp-neon - packages that are applicable for the armv7a instruction set using NEON hardware floating point
     28 * ventana - packages that are applicable to the ventana machine target (ie kernel and kernel modules)
     29
     30
     31== Package Building (using bitbake) ==
     32The following steps provide an example of building a package (in this case e2fsprogs):
     33 1. Find package you want. You can use '''bitbake-layers show-recipes''' to search for packages:
     34{{{
     35$ bitbake-layers show-recipes | grep e2f
     36Parsing recipes..done.
     37  meta                 1.8.2+git1+e398e374e2ff0e88bc1d63577a192f8ca04a1cb5
     38e2fsprogs:
     39  meta                 0.1+git1+a0be2fe4b5f12b8b07f4e3bd624b3729657f0ac5
     40}}}
     41 2. Compile and build package with bitbake command.  Example shown:
     42{{{
     43$ bitbake e2fsprogs
     44}}}
     45 3. Find outputted compiled .ipk file in one of the folders inside the ipk directory.  Example shown:
     46{{{
     47$ ls build/tmp/deploy/ipk
     48all  armv7a-vfp-neon  Packages  Packages.flock  Packages.gz  Packages.stamps  ventana
     49}}}
     50This case
     51{{{
     52$ ls build/tmp/deploy/ipk/armv7a-vfp-neon/e2fsprogs-mke2fs_1.42.1-r4_armv7a-vfp-neon.ipk
     53}}}
     54
     55
     56== Installing packages onto target (manually one at a time) ==
     57 1. Transfer desired .ipk file to Gateworks board that is running Yocto already.  Use a tool such as wget.
     58 2. Use the opkg install command to install on target. Example shown:
     59{{{
     60root@ventana:~# opkg install e2fsprogs-mke2fs_1.42.1-r4_armv7a-vfp-neon.ipk
     61}}}
     62  2a. This case there was a error because this package has dependencies that are not installed. Please install these first!
     63{{{
     64root@ventana:~# opkg install e2fsprogs-mke2fs_1.42.1-r4_armv7a-vfp-neon.ipk
     65Installing e2fsprogs-mke2fs (1.42.1-r4) to root...
     66Collected errors:
     67 * satisfy_dependencies_for: Cannot satisfy the following dependencies for e2fsprogs-mke2fs:
     68 *      libcom-err2 (>= 1.42.1) *       libe2p2 (>= 1.42.1) *   libext2fs2 (>= 1.42.1) *
     69 * opkg_install_cmd: Cannot install package e2fsprogs-mke2fs.
     70}}}
     71  2b. After installing the dependencies, try again
     72{{{
     73root@ventana:~# opkg install e2fsprogs-mke2fs_1.42.1-r4_armv7a-vfp-neon.ipk Installing e2fsprogs-mke2fs (1.42.1-r4) to root...
     74Configuring e2fsprogs-mke2fs.
     75root@ventana:~#
     76}}}
     77 3. Test package / command . Example shown
     78{{{
     79root@ventana:~# mk
     80mkdir         mkfs.ext2     mkfs.ext4dev  mkfs.ubifs    mktemp
     81mke2fs        mkfs.ext3     mkfs.jffs2    mknod         
     82mkfifo        mkfs.ext4     mkfs.minix    mkswap       
     83root@ventana:~# mkfs.ext4
     84Usage: mkfs.ext4 [-c|-l filename] [-b block-size] [-C cluster-size]
     85        [-i bytes-per-inode] [-I inode-size] [-J journal-options]
     86        [-G flex-group-size] [-N number-of-inodes]
     87        [-m reserved-blocks-percentage] [-o creator-os]
     88        [-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
     89        [-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
     90        [-t fs-type] [-T usage-type ] [-U UUID] [-jnqvFKSV] device [blocks-count]
     91}}}
     92
     93
     94== Installing using package feeds ==
     95Setting up a package feed is the easiest way to install packages, but it does require setting up a web server on your build host and adding in a feed conf file.
     96
     97Procedure:
     98 1. Install and configure a web server on your build host. For example, to install and configure 'lighttpd' on ubuntu:
     99{{{
     100# install the package
     101$ sudo apt-get install lighttpd
     102# add an alias for 'yocto' to your build hosts directory:
     103$ sudo sh -c 'echo "alias.url += ( \"/yocto\" => \"/usr/src/yocto/build/tmp/deploy/ipk\" )" >> /etc/lighttpd/lighttpd.conf'
     104}}}
     105 2. On your target, point to the various feeds on your hosts build directory. For example, if your build host is at 192.168.1.1 and you setup the aliase above as 'yocto' to point to your build/tmp/deploy/ipk directory:
     106{{{
     107root@ventana:~# cat << EOF > /etc/opkg/base-feeds.conf
     108# non-arch dependent files (scripts, config etc)
     109src/gz all http://192.168.1.1/yocto/all
     110# arch dependent files
     111src/gz armv7a-vfp-neon http://192.168.1.1/yocto/armv7a-vfp-neon
     112# machine dependent files (kernel, modules)
     113src/gz imx6qsabresd http://192.168.1.1/yocto/ventana
     114EOF
     115}}}
     116 3. update your feeds and install:
     117{{{
     118root@ventana:~# opkg update
     119root@ventana:~# opkg install e2fsprogs-mke2fs
     120}}}
     121 * you will need to update your feeds with 'opkg update' each time they change on your build host (ie you have built something new)
     122
     123
     124== Package Development Workflow ==
     125A common question is 'how do I develop or modify a package in the bitbake environment'. Here is a step-by-step procedure that may prove useful as a guide:
     126 1. Create a new package (if not modifying an existing one)
     127 2. activate a bitbake shell and build the package (performs all necessary steps per package recipe to fetch,patch,configure,compile,install,package and results in an ipk in build/tmp/deploy)
     128{{{
     129bitbake <package>
     130}}}
     131 3. edit source in packages WORKDIR
     132  * This will be in build/tmp/work in a subdirectory based on the feed for that package. For example packages that are independent of architecture, machine, etc (ie shell scripts, text files) will be in tmp/work/all-poky/linux and packages that are independent of machine but dependent on architecture (ie compiled apps or libs) will be in an arch specific subdir such as tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi and packages that depend on the 'ventana' machine such as the kernel or kernel modules, will be in the tmp/work/ventana-poky-linux-gnueabi subdir.
     133 4. force bitbake (-f flag) to re-execute the 'compile' task (-ccompile) as bitbake won't know that source files have been changed in the WORKDIR and 'bitbake <package>' will think its already done
     134{{{
     135bitbake -f -ccompile <package>
     136}}}
     137  * this forces all tasks dependent on the 'compile' tasks will now be flagged as dirty
     138  * if you are copying build objects to your target manually from the package WORKDIR you can do that now, and simply repeat steps 3 and 4 until you are done with your development
     139 5. bitbake the package to complete all remaining tasks to create an ipk
     140{{{
     141bitbake <package>
     142}}}
     143 6. if using opkg to get the updated package on your target, update the package indexes
     144{{{
     145bitbake package-index
     146}}}
     147  * if only using opkg for package updates you can now repeat steps 3, 4, 5, and 6 until you are done with your development
     148 7. if re-flashing the filesystem image rebuild that as well:
     149{{{
     150bitbake gateworks-image-test
     151}}}
     152  * Note that bitbake stores filesystem images in the DEPLOY directory by timestamp, and they will never be removed. You may want to 'rm -rf tmp/deploy/images/ventana/gateworks-image-test*' prior to rebuilding to keep disk space down
     153  * if using ubi filesystem for package updates you can now repeat steps 3, 4, 5, 6, and 7 until you are done with your development
     154
     155
     156If you are ultimately trying to produce a patch that will persist for the package you will want to use something like 'quilt' to track your patch in step 3. Then, when your development cycle is complete you can:
     157 1. take the resulting patch(es) produced by quilt and place them in an appropriate directory for that package (something thats in the filespath)
     158 2. add the patches to the SRC_URI of the package
     159 3. bump the package revision (PR) (or equivalent) so that bitbakes dependency system knows the package needs to be rebuilt in its entirety
     160 4. push your new recipe to your version control subsystem (or share it via mailist or public repository)
     161
     162Alternatively if you are trying to 'upstream' your patches (which you should do to avoid future maintenance on your part):
     163 1. take the resulting patch(es) produced by quilt and submit them to the projects mailist
     164 2. once your patches are upstreamed you can update the package recipe SRCREV to pull the updated version from source control (or create a new recipe if appropriate). If you create a new recipe (because the version of the package changes) or bump the SRCREV (because the recipe pulls 'un-released' source from a source control repository) you don't need to bump the package revision (PR) as bitbake tracks the package by version.
     165
     166
     167== Adding Packages to Image ==
     168One '''very simple''' way to do this that '''may or may not''' work depending on the complexity and dependencies is:
     169
     170 1. Build Yocto according to the instructions at [wiki:Yocto/Building]
     171 2. Add the following line to the conf/local.conf file
     172{{{
     173IMAGE_INSTALL_append = " package"
     174}}}
     175  1. Note package would be replaced by something such as tcpdump or openvpn, etc
     176{{{
     177IMAGE_INSTALL_append = " tcpflow tcpdump openvpn"
     178}}}
     179 3. Recompile by using the bitbake command as explained on the Building page here:
     180 4. Look for the .ipk file in the location tmp/deploy/ipk/armv7a-vfp-neon folder.
     181{{{
     182$ find ./tmp/deploy/ipk -name "*openvpn*.ipk"
     183./tmp/deploy/ipk/armv7a-vfp-neon/openvpn_2.1.3-r0_armv7a-vfp-neon.ipk
     184./tmp/deploy/ipk/armv7a-vfp-neon/openvpn-dev_2.1.3-r0_armv7a-vfp-neon.ipk
     185./tmp/deploy/ipk/armv7a-vfp-neon/openvpn-doc_2.1.3-r0_armv7a-vfp-neon.ipk
     186./tmp/deploy/ipk/armv7a-vfp-neon/openvpn-dbg_2.1.3-r0_armv7a-vfp-neon.ipk
     187}}}
     188 5. There are a few ipk files, however they are for dev, doc, and dbg (debug).  For main purposes, use the main one (eg openvpn_2.1.3-r0_armv7a-vfp-neon.ipk)
     189 6. Place this file onto the Ventana board through a method such as wget.  Then install using the opkg install command
     190{{{
     191root@ventana:/tmp# wget http://192.168.1.22/ipk/openvpn_2.1.3-r0_armv7a-vfp-neon.ipk
     192--2014-02-19 04:27:59--  http://192.168.1.22/ipk/openvpn_2.1.3-r0_armv7a-vfp-neon.ipk
     193Connecting to 192.168.1.22:80... connected.
     194HTTP request sent, awaiting response... 200 OK
     195Length: 208174 (203K)
     196Saving to: 'openvpn_2.1.3-r0_armv7a-vfp-neon.ipk'
     197
     198100%[======================================>] 208,174     --.-K/s   in 0.02s   
     199
     2002014-02-19 04:27:59 (12.9 MB/s) - 'openvpn_2.1.3-r0_armv7a-vfp-neon.ipk' saved [208174/208174]
     201
     202root@ventana:/tmp# opkg install openvpn_2.1.3-r0_armv7a-vfp-neon.ipk
     203Installing openvpn (2.1.3-r0) to root...
     204openvpn: unsatisfied recommendation for kernel-module-tun
     205Configuring openvpn.
     206root@ventana:/tmp#
     207}}}
     208
     209
     210== Modifying Packages through BB configuration File ==
     211Here is an example.
     212
     213Let's use the gst-plugins-bad package as an example.  This package has quite a few items inside of it.  This will all be controlled in it's bb file.
     214
     215Location: sources/poky/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb
     216
     217Open this file, and modify it.  In this example, we want to be sure that the mpegtsdemux is built and added, so inside the file, we add mpegtsdemux into the EXTRA_OECONF variable under the --with-plugins flag
     218{{{
     219EXTRA_OECONF += "--disable-examples --disable-experimental --disable-sdl --disable-cdaudio --disable-directfb \
     220                 --with-plugins=musicbrainz,wavpack,ivorbis,mpegvideoparse,mpegtsdemux --disable-vdpau --disable-apexsink \
     221                 --disable-orc"
     222
     223}}}
     224
     225After modifying the file, save it.
     226
     227Then, build the package individually like in the examples above on this page:
     228{{{
     229bitbake gst-plugins-bad
     230}}}
     231
     232The artifacts will be in the usual location:
     233{{{
     234./build/tmp/deploy/ipk/armv7a-vfp-neon/gst-plugins-bad-mpegtsdemux_0.10.23-r2_armv7a-vfp-neon.ipk
     235}}}
     236
     237
     238= Kernel Configuration =
     239
     240== Bitbake Menu Config ==
     241You can modify the kernel configuration using the 'menuconfig' task. For example:
     242{{{
     243bitbake -c menuconfig linux-imx
     244}}}
     245
     246This stores a modified config file in the kernel's work-dir (it will not be persistent if you clean or remove the workdir).
     247
     248See the [http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html#generating-configuration-files yocto documentation] for more info
     249
     250
     251= References =
     252Please consult the Yocto project website for more information regarding their OS.
     253 * [https://wiki.yoctoproject.org/wiki/FAQ#How_can_I_add_a_package_to_my_project.3F]
     254 * [https://wiki.yoctoproject.org]
     255 * [https://community.freescale.com/docs/DOC-94967]
     256 * [http://www.yoctoproject.org/docs/1.3/dev-manual/dev-manual.html] Yocto 1.3 Reference Manual]
     257 * [http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html Latest BitBake Manual]