ye is a command line tool to ease the manipulation of files under
the directory structure adopted by O.S. Systems to organize projects
that use the Yocto Project. ye provides means to quickly locate
files and directories into projects' directory tree, and act on them.
The infrastructure adopted by O.S. Systems assumes the following directory layout:
<project>
.repo
<build dir>
setup-environment
sources
<project> is the root directory of the project you’ll be working on.
In it you’ll initially find a setup-environment script, which is
supposed to be source’d to set up the environment and will create
<build dir>, and a sources directory, under which the source code
of all projects (git repositories) will be stored.
The directory layout in the <build dir> directory follows the
standard layout as determined by the Yocto Project.
Most ye commands accept a regular expression as argument. Thus, it’s
possible that it will obtain multiple results. In this case, if
ye's output is attached to a terminal (i.e., not a pipe or a file),
it will run interactively, prompting users for a specific result.
When running interactively, ye will paginate the output in case it
doesn’t fit the terminal window and will highlight matches in red on
the output.
Some commands expect the BUILDDIR environment variable to be set in
the environment (because they have to run bitbake behind the scenes
to find out things). This variable is automatically set by the
setup-environment script provided by O.S. Systems for Yocto
Project-based projects.
This section will show in detail how to use ye. The help message
displayed by ye when invoked with the --help option can be seen
below. The next subsections provide more detailed information about
each command.
$ ye -h
Usage: ye <command> [ <options> ]
f [-e] <regex>
find [-e] <regex>
Locate paths (in the "sources" directory) that match the given
expression <regex>. <regex> is case insensitive and implicitly
surrounded by '.*'. -e disables the implicit use of '.*' around
the given <regex>. Note that, unless <regex> contains /, matching
is attempted on filenames only (not on dirnames). If <regex>
contains /, matching is attempted on the full path.
v [-e] <regex>
view [-e] <regex>
Shortcut to find & view. If multiple files are found, a prompt for
files will be displayed (but not for actions).
e [-e] <regex>
edit [-e] <regex>
Shortcut to find & edit. If multiple files are found, a prompt for
files will be displayed (but not for actions).
sf [-e] <regex>
sysroot-find [-e] <regex>
Locate paths (in the "sysroots" directory) that match the given
expression <regex>. <regex> is case insensitive and implicitly
surrounded by '.*'. -e disables the implicit use of '.*' around
the given <regex>. Note that, unless <regex> contains /, matching
is attempted on filenames only (not on dirnames). If <regex>
contains /, matching is attempted on the full path.
wsf [-e] <regex>
work-shared-find [-e] <regex>
Similar to sysroot-find, but instead of searching in the sysroots
directories, search in the work-shared directory.
pf [-e] <regex>
pkg-find [-e] <regex>
Like 'find', but for packages.
pv [-e] <regex>
pkg-view [-e] <regex>
Shortcut to pkg-find & view. If multiple packages are found, a
prompt for packages will be displayed (but not for actions).
pi [-e] <regex>
pkg-info [-e] <regex>
Shortcut to pkg-find & info. If multiple packages are found, a
prompt for packages will be displayed (but not for actions).
ps [-e] <regex>
pkg-scripts [-e] <regex>
List scripts for package that matches <regex>. In case of multiple
matches, ye will prompt for a specific package. <regex> is case
insensitive and implicitly surrounded by '.*'. -e disables the
implicit use of '.*' around the given <regex>.
px [-e] [-c] <regex> [<file>]
pkg-extract [-e] [-c] <regex> [<file>]
Extract package that matches <regex>. In case of multiple matches,
ye will prompt for a specific package. <regex> is case insensitive
and implicitly surrounded by '.*'. -e disables the implicit use
of '.*' around the given <regex>.
If <file> is provided, ye will extract <file> only, otherwise the
whole package content will be extracted to a directory named after
the package filename (without extension). <file> must match the exact
file name in the package (usually starts with ./).
-c is specific to .deb and .ipk packages -- ye will extract files
from the control.tar.gz tarball in packages.
wd [-e] <regex>
workdir [-e] <regex>
Locate the Yocto Project's workdir for <regex>. <regex> is
implicitly surrounded by '.*', unless -e is provided.
l [-e] [-H] [-R] <recipe pattern> [<log pattern>]
log [-e] [-H] <recipe pattern> [<log pattern>]
Show the log files for <recipe>. -e is only applied to
<recipe pattern>. <log pattern> is always implicitly surrounded
by '.*', if provided. If -H ("human readable") is given on the
command line, ye will try to make the lines that contain calls
to gcc/g++ look more readable. If -R is provided, ye will apply
some text replacements to make the output more readable. Currently,
ye reverse expands some common variables whose expansion pollutes
log files with long paths. The following variables are reverse
expanded:
* $B
* $S
* $WORKDIR
* $TMPDIR
* $HOME
r [-e] <recipe pattern> [<run script pattern>]
run [-e] <recipe pattern> [<run script pattern>]
Show the log files for <recipe>. -e is only applied to
<recipe pattern>. <run script pattern> is always implicitly
surrounded by '.*', if provided.
g <args>
grep <args>
Run 'repo grep <args>'.
sg <args>
sysroot-grep <args>
Run 'grep -r <args> $BUILDDIR/tmp/sysroots/$MACHINE'.
glg [-n <num commits>] [-i] <regex>
git-log-grep [-n <num commits>] [-i] <regex>
Run "git log -n <num commits> --oneline | grep <regex>" on all the
repositories and prompt the user for the commit to show.
If -n is not provided, 1000 will be used. If -i is provided, search
will be case insensitive.
gbh [<args>] <regex>
grep-buildhistory [<args>] <regex>
Run "git grep [<args>] <regex>" in the buildhistory directory.
bh [-d] <revisions back>
buildhistory [-d] <revisions back>
Show changes in buildhistory <revisions back> (a positive integer).
If -d is given, show the raw git diff output.
d [-e] <regex>
doc [-e] <regex>
Search variable names in the reference manual that match the given
expression <regex> and show the documentation for the selected
match. <regex> is case insensitive and implicitly surrounded by
'.*'. -e disables the implicit use of '.*' around the given
<regex>.
x <recipe> <variable>
expand <recipe> <variable>
Expand BitBake's variable <variable> in the context of <recipe> and
show the final value and the recursive expansion of all variables
and expressions involved.
cd [<dir shortcut>]
Change to <dir shortcut>. The following <dir shortcut> options are
available:
top
Change to project's TOPDIR
wd [<recipe>]
Change to <recipe>'s WORKDIR or to BUILDDIR/tmp/deploy/work if
<recipe> is not provided
bd
Change to BUILDDIR
bh
Change to the buildhistory directory
sd
Change to the sysroot directory for MACHINE
src [<recipe>]
Change to <recipes>'s source dir or to TOPDIR/sources
if <recipe> is not provided
img
Change to BUILDDIR/tmp/deploy/MACHINE/image/
pkg
Change to BUILDDIR/tmp/deploy/PKG_TYPE/image/
manifest
Change to TOPDIR/.repo/manifests
When called without arguments, ye cd will change to BUILDDIR.
To use this feature, source'ing the ye-cd shell helper is required.
ye provides commands to locate files and operate on them. Some
commands are specific to some directories and some are specific to
some file types (e.g., packages). The following sections provide a
more in-depth explanation about them.
The find command (short: f) can be used to locate files under the
sources directory. It’s argument is a regular expression that will
be matched against pathnames. If the given regex contains /,
matching is attempted on filenames only (not on dirnames). If the
given regex contains /, matching is attempted on the full path.
After locating files that match the given pattern, ye will prompt
you to select one of the matches and, next, what to do with it. In
case the standard output is not a terminal (e.g., a file or a pipe),
interactive commands will just print the results to the standard
output (no prompt for action will be displayed).
Example:
$ ye f flex
[0] ~/yocto/sources/poky/meta/recipes-devtools/flex/flex.inc [0]
[1] ~/yocto/sources/poky/meta/recipes-devtools/flex/flex_2.5.35.bb [1]
Option (ENTER to cancel): 1
[v] View
[e] Edit
Option (ENTER to cancel): v
1 require flex.inc
2 PR = "r3"
3 LICENSE="BSD"
4 LIC_FILES_CHKSUM = "file://COPYING;md5=e4742cf92e89040b39486a6219b68067"
5 BBCLASSEXTEND = "native nativesdk"
6
7 SRC_URI += "file://avoid-FORTIFY-warnings.patch \
8 file://int-is-not-the-same-size-as-size_t.patch"
9
10 SRC_URI[md5sum] = "10714e50cea54dc7a227e3eddcd44d57"
11 SRC_URI[sha256sum] = "0becbd4b2b36b99c67f8c22ab98f7f80c9860aec70..."
|
Note
|
ye also allows you to use shortcuts for selecting options and
actions at the same prompt. In the example above, we typed 0 ENTER
to select flex.inc, then 0 ENTER to select the View action. The
shortcut would be 0v ENTER in the file selection prompt. For
Edit, the shortcut would be 0e ENTER.
|
For cases you know in advance what to do with files (i.e., view or
edit), ye provides commands to allow you to specify the action on
the command line, so it won’t prompt you for the action. Those
commands are view (short: v) and edit (short: e). They are
basically shortcuts to find → view and find → edit.
The view and edit commands can be quite handy when you have a part
of the full path to a file. Here’s an example use-case: you want to
understand how the qemuarm machine configuration is built. You
start by looking at the content of qemuarm.conf:
$ ye v qemuarm.conf
~/src/yocto/sources/poky/meta/conf/machine/qemuarm.conf
1 #@TYPE: Machine
2 #@NAME: arm_versatile_926ejs
3 #@DESCRIPTION: arm_versatile_926ejs
4
5 require conf/machine/include/qemu.inc
6 require conf/machine/include/tune-arm926ejs.inc
7 #require conf/machine/include/tune-arm1136jf-s.inc
8
9 KERNEL_IMAGETYPE = "zImage"
10
11 SERIAL_CONSOLE = "115200 ttyAMA0"
12
/home/mario/src/yocto/sources/poky/meta/conf/machine/qemuarm.conf
You see qemuarm.conf includes conf/machine/include/qemu.inc.
Since you may not know what layer ships
conf/machine/include/qemu.inc, to see its contents you first would
have to locate it, then you’d need to call a viewer passing as
argument the path to the file you found. With ye, you can just give
it the partial path referenced in qemuarm.conf:
$ ye v conf/machine/include/qemu.inc
~/src/yocto/sources/poky/meta/conf/machine/include/qemu.inc
1 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
2 PREFERRED_PROVIDER_virtual/egl ?= "mesa"
3 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
4 PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
5 PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"
6
7 XSERVER ?= "xserver-xorg \
...
ye will locate and display the file in a single step. If it finds
multiple results for conf/machine/include/qemu.inc it’ll prompt you
for the one you really want to see.
The sysroot-find (short: sf) command is pretty much equivalent to
the find command, except it locates files under the sysroots
directory (<build dir>/tmp/sysroots).
The work-shared-find (short: wsf) command is similar to the
sysroot-find command, but instead of searching in the sysroots
directories, it searches in the work-shared directory.
The pkg-find (short: pf) command is equivalent to the find
command, except it locates files under the deploy directory for
packages (<build dir>/tmp/deploy/<package type>). ye supports the
most common package formats generated by Yocto Project: .ipk, .deb
and .rpm.
The actions for packages are different from the find command. ye
supports the following actions on packages:
view-
show the package contents
info-
show the package metadata
scripts-
list package scripts (.e.g.,
postinstall,postrm) extract-
extract package contents to a directory named after the package filename
Just like the view and edit counterparts to the find command,
ye provides pkg-view (short: pv), pkg-info (short: pi),
pkg-scripts (short: ps) and pkg-extract (short: px) command
line shortcuts to the corresponding actions.
Examples:
$ ye pf busybox_ ~/yocto/build/tmp/deploy/ipk/cortexa9hf-vfp-neon/busybox_1.22.1-r32.5_cortexa9hf-vfp-neon.ipk [v] View [i] Info [s] Scripts [x] Extract Option (ENTER to cancel): v drwxrwxrwx root/root 0 2015-04-17 11:50 ./ drwxr-xr-x root/root 0 2015-04-17 11:50 ./etc/ -rw-r--r-- root/root 108 2015-04-17 11:50 ./etc/busybox.links.suid -rw-r--r-- root/root 2217 2015-04-17 11:50 ./etc/busybox.links.nosuid drwxr-xr-x root/root 0 2015-04-17 11:50 ./bin/ -rwxr-xr-x root/root 544012 2015-04-17 11:50 ./bin/busybox.nosuid -rwsr-xr-x root/root 52804 2015-04-17 11:50 ./bin/busybox.suid lrwxrwxrwx root/root 0 2015-04-17 11:50 ./bin/busybox -> busybox.nosuid lrwxrwxrwx root/root 0 2015-04-17 11:50 ./bin/sh -> busybox.nosuid /home/mario/yocto/build/tmp/deploy/ipk/cortexa9hf-vfp-neon/busybox_1.22.1-r32.5_cortexa9hf-vfp-neon.ipk
$ ye pi flex_ ~/yocto/build/tmp/deploy/ipk/cortexa9hf-vfp-neon/flex_2.5.39-r0.3_cortexa9hf-vfp-neon.ipk Package: flex Version: 2.5.39-r0.3 Description: Flex (The Fast Lexical Analyzer) Flex is a fast lexical analyser generator. Flex is a tool for generating programs that recognize lexical patterns in text. Section: devel Priority: optional Maintainer: O.S. Systems Software LTDA. <contato@ossystems.com.br> License: BSD Architecture: cortexa9hf-vfp-neon OE: flex Homepage: http://sourceforge.net/projects/flex/ Depends: m4, libc6 (>= 2.20) Source: http://downloads.sourceforge.net/flex/flex-2.5.39.tar.bz2 file://run-ptest file://do_not_create_pdf_doc.patch /home/mario/yocto/build/tmp/deploy/ipk/cortexa9hf-vfp-neon/flex_2.5.39-r0.3_cortexa9hf-vfp-neon.ipk
|
Tip
|
If you want to see the contents of the "main" package generated
by a recipe (i.e., not -dev, -dbg, -locale etc.), you can append
_ to the package name. So, instead of flex, you can use flex_
and ye won’t match flex-dev, for example.
|
The workdir command (short: wd) will print the work directory for
the given recipe regular expression pattern. Like the other commands
that deal with regular expressions, workdir implicitly surrounds the
given regular expression pattern by .*, unless the -e option is
provided.
Example:
$ ye wd busybox /home/mario/yocto/build/tmp/work/cortexa9hf-vfp-neon-oel-linux-gnueabi/busybox
Upon processing recipes, BitBake writes log files and scripts to the
directory where it processes recipes. Log files are prefixed by
log. and scripts are prefixed by run.:
run.<task>-
shows the code that was run to process
<task> log.<task>-
shows the output of the execution of
run.<task>
ye provides commands to display the contents of log files and
scripts: log (short: l) and run (short: r).
Both use as first argument a regex to be matched against recipe names.
The second argument (optional), is a regex to be matched against log
filenames or scripts. If the second argument is not provided, ye
will list all log files or scripts and prompt for the one you want to
see.
Both commands accept a -e option to indicate that the recipe regex
should not be automatically surrounded by .*.
Examples:
$ ye r base-files
=== Showing run scripts for base-files
[0] run.do_packagedata [0]
[1] run.do_package_write_ipk [1]
[2] run.do_fetch [2]
[3] run.do_install [3]
[4] run.do_unpack [4]
[5] run.do_populate_sysroot [5]
[6] run.do_patch [6]
[7] run.do_package [7]
[8] run.do_prepare_copyleft_sources [8]
[9] run.do_configure [9]
[10] run.do_populate_lic [10]
[11] run.do_compile [11]
[12] run.do_package_qa [12]
Option (ENTER to cancel): 11
1 #!/bin/sh
2
3 # Emit a useful diagnostic if something fails:
4 bb_exit_handler() {
5 ret=$?
...
$ ye l base-files
=== Showing logs for base-files
[0] log.do_package_qa [0]
[1] log.do_unpack [1]
[2] log.do_configure [2]
[3] log.do_prepare_copyleft_sources [3]
[4] log.do_fetch [4]
[5] log.do_package [5]
[6] log.do_populate_sysroot [6]
[7] log.do_patch [7]
[8] log.do_packagedata [8]
[9] log.do_compile [9]
[10] log.do_install [10]
[11] log.do_populate_lic [11]
[12] log.do_package_write_ipk [12]
Option (ENTER to cancel): 11
1 DEBUG: Executing python function sstate_task_prefunc
2 DEBUG: Python function sstate_task_prefunc finished
...
$ ye r base-files pack
=== Showing run scripts for base-files
[0] run.do_packagedata [0]
[1] run.do_package_write_ipk [1]
[2] run.do_unpack [2]
[3] run.do_package [3]
[4] run.do_package_qa [4]
Option (ENTER to cancel): 4
1 def do_package_qa(d):
2 import subprocess
3 import oe.packagedata
4
...
The log command also handles the -H option, which tries to make
compiler command lines more readable (and numbers them). See some
examples below:
Without -H:
$ ye l busybox compile === Showing logs for busybox [0] log.do_compile_ptest_base [0] [1] log.do_compile [1] Option (ENTER to cancel): 1 ... 1118 gcc -Wp,-MD,applets/.applet_tables.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o applets/applet_tables applets/applet_tables.c ...
With -H
$ ye l -H busybox compile === Showing logs for busybox [0] log.do_compile_ptest_base [0] [1] log.do_compile [1] Option (ENTER to cancel): 1 ... --------------[ command line 2 ]---------------------- gcc -Wp,-MD,applets/.applet_tables.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o applets/applet_tables applets/applet_tables.c ...
Long paths can considerably clutter logs, making them quite difficult
to read. Another useful argument to log is -R: it reverse expands
some variables in log text, transforming long paths into their
corresponding variable. Examples:
Without -R:
$ ye l -H make$ compile ... Making all in doc make[2]: Entering directory '/home/mario/src/yocto/build/tmp/work/ppce500v2-oel-linux-gnuspe/make/4.0-r0/build/doc' make[2]: Leaving directory '/home/mario/src/yocto/build/tmp/work/ppce500v2-oel-linux-gnuspe/make/4.0-r0/build/doc' make[2]: Entering directory '/home/mario/src/yocto/build/tmp/work/ppce500v2-oel-linux-gnuspe/make/4.0-r0/build' ---------------[ command line 1 ]--------------- powerpc-oel-linux-gnuspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double --sysroot=/home/mario/src/yocto/build/tmp/sysroots/olt8820plus -DLOCALEDIR=\"/usr/share/locale\" -DLIBDIR=\"/usr/lib\" -DINCLUDEDIR=\"/usr/include\" -DHAVE_CONFIG_H -I. -I/home/mario/src/yocto/build/tmp/work/ppce500v2-oel-linux-gnuspe/make/4.0-r0/make-4.0 -O2 -pipe -g -feliminate-unused-debug-types -c -o ar.o /home/mario/src/yocto/build/tmp/work/ppce500v2-oel-linux-gnuspe/make/4.0-r0/make-4.0/ar.c ...
With -R:
$ ye l -H -R make$ compile ... Making all in doc make[2]: Entering directory '$B/doc' make[2]: Leaving directory '$B/doc' make[2]: Entering directory '$B' ---------------[ command line 1 ]--------------- powerpc-iep-linux-gnuspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double --sysroot=$TMPDIR/sysroots/olt8820plus -DLOCALEDIR=\"/usr/share/locale\" -DLIBDIR=\"/usr/lib\" -DINCLUDEDIR=\"/usr/include\" -DHAVE_CONFIG_H -I. -I$S -O2 -pipe -g -feliminate-unused-debug-types -c -o ar.o $S/ar.c ...
ye provides commands to locate text in file contents and on summary
lines of commit messages. The next subsections show these commands in
detail.
The grep command is a thin wrapper around repo grep (repo is the
tool used by O.S. Systems to manage multiple git repositories — see
the Managing
platforms based on the Yocto Project document for more information).
Basically, repo grep <arguments> will run git grep <arguments> on
each repository (in the sources directory) which is part of the
project.
The grep command will run repo grep plus the arguments provided on
the command line (any valid argument for git grep) and will prompt
you to select one of the matches, then the action to apply on the
selected file. In case of a single match, you’ll be only prompted for
the action.
Example:
$ ye g -i libfoo
[0] sources/meta-openembedded/meta-oe/recipes-connectivity/samba/samba-3.6.24/waf-as-source.patch:+ """example: bld.symlink_as('${PREFIX}/lib/libfoo.so', 'libfoo.so.1.2.3') """ [0]
[1] sources/meta-openembedded/meta-oe/recipes-connectivity/samba/samba-3.6.24/waf-as-source.patch:+ libfoo.so is installed as libfoo.so.1.2.3 [1]
[2] sources/poky/meta/classes/package.bbclass: # /opt/abc/lib/libfoo.so.1 and contains /usr/bin/abc depending on system library libfoo.so.1 [2]
[3] sources/poky/meta/recipes-core/glibc/glibc/eglibc-install-pic-archives.patch: # $(inst_libdir)/libfoo.so -- for linking, symlink or ld script [3]
[4] sources/poky/meta/recipes-core/glibc/glibc/eglibc-install-pic-archives.patch: # $(inst_slibdir)/libfoo.so.NN -- for loading by SONAME, symlink [4]
Option (ENTER to cancel): 2v
1 #
2 # Packaging process
3 #
4 # Executive summary: This class iterates over the functions listed in PACKAGEFUNCS
...
The sysroot-grep (short: sg) command is similar to the grep
command, but instead of searching for matches in the sources
directory, it recursively searches for matches in the sysroot
directory (<build dir>/tmp/sysroots/<machine>, specifically).
Example:
$ ye sg -i '<libfoo\.a>'
Parsing recipes..done.
[0] /home/mario/src/reach/dizzy/build/tmp/sysroots/g2h-solo-3/usr/lib/perl/ptest/lib/ExtUtils/Liblist.pm:you are using GCC, it gets translated to C<libfoo.a>, but for other win32 [0]
[1] /home/mario/src/reach/dizzy/build/tmp/sysroots/g2h-solo-3/usr/lib/perl/ptest/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist.pm:you are using GCC, it gets translated to C<libfoo.a>, but for other win32 [1]
[2] /home/mario/src/reach/dizzy/build/tmp/sysroots/g2h-solo-3/usr/lib/perl/5.20.0/ExtUtils/Liblist.pm:you are using GCC, it gets translated to C<libfoo.a>, but for other win32 [2]
Option (ENTER to cancel): 1v
1 package ExtUtils::Liblist;
2
3 use strict;
4
...
The git-log-grep command (short: glg) basically runs
git log --oneline | grep <regex>"
for the given regular expressions on the summary lines of all git
repositories that are part of the project. By default, it limits the
repository history to 1000 commits. If you need to search in older
commit summary lines, you can use the -n <num commits> option.
Example:
$ ye glg 'build error'
[0] poky 7eb3e45 bitbake: toasterui: refactor log saving and save out-of-build errors [0]
[1] meta-fsl-arm e45b4f8 linux-imx (2.6.35.3): Fix build errors when using make 3.82 [1]
[2] meta-fsl-arm 7b30034 gst-fsl-plugin-2.0.3: fix build error due to missing uint declaration [2]
[3] meta-fsl-arm c38a612 xf86-video-imxfb: fix build error due to missing uint declaration [3]
[4] meta-openembedded 17ce4c6 libmtp: Fix 'Makefile.am: No such file or directory' build error. [4]
Option (ENTER to cancel): 4
commit 17ce4c6ac0d5b3651c7bd8758511679210a3286c
Author: Charles Oram <charles@oram.co.nz>
Date: Wed May 14 15:36:45 2014 +1200
libmtp: Fix 'Makefile.am: No such file or directory' build error.
* skip_udev_rules_generation() needs to reference Makefile.am in the recipe
source directory.
Signed-off-by: Charles Oram <charles@oram.co.nz>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
diff --git a/meta-oe/recipes-connectivity/libmtp/libmtp_1.1.5.bb b/meta-oe/recipes-connectivity/libmtp/libmtp_1.1.5.bb
index f4ea800..0c92ff9 100644
--- a/meta-oe/recipes-connectivity/libmtp/libmtp_1.1.5.bb
+++ b/meta-oe/recipes-connectivity/libmtp/libmtp_1.1.5.bb
@@ -29,8 +29,8 @@ do_unpack[vardeps] += "skip_udev_rules_generation"
do_unpack[postfuncs] += "skip_udev_rules_generation"
skip_udev_rules_generation () {
- sed -i -e '/^noinst_DATA=/,/util\/mtp-hotplug -H/d' Makefile.am
- cp ${WORKDIR}/69-libmtp.rules ${S}/
+ sed -i -e '/^noinst_DATA=/,/util\/mtp-hotplug -H/d' ${S}/Makefile.am
+ cp ${WORKDIR}/69-libmtp.rules ${S}/
}
inherit autotools pkgconfig lib_package
The grep-buildhistory commmand (short: gbh) is a wrapper around
git grep in the buildhistory directory.
Example:
$ ye gbh 'passwd /bin/busybox' [0] packages/armv7a-vfp-neon-iep-linux-gnueabi/busybox/busybox/latest.pkg_postinst: update-alternatives --install /usr/bin/passwd passwd /bin/busybox.suid 50 [0] [1] packages/armv7a-vfp-neon-iep-linux-gnueabi/busybox/busybox/latest.pkg_postrm: update-alternatives --remove passwd /bin/busybox.suid [1] [2] packages/ppce500v2-iep-linux-gnuspe/busybox/busybox/latest.pkg_postinst: update-alternatives --install /usr/bin/passwd passwd /bin/busybox.suid 50 [2] [3] packages/ppce500v2-iep-linux-gnuspe/busybox/busybox/latest.pkg_postrm: update-alternatives --remove passwd /bin/busybox.suid [3]
The buildhistory command (short: bh) can be used to display
changes in the
buildhistory.
The required argument (a positive integer) is the number of previous
revisions to display. If the optional -d argument is given,
buildhistory will show the raw diff output.
buildhistory is basically a wrapper around buildhistory-diff or
git diff in the buildhistory directory (when -d is provided).
Example:
$ ye bh 1 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-calibrate: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-conf: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-dbg: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-dev: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-doc: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-locale: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-staticdev: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib-tests: PKGR changed from r0.2 to r0.3 packages/cortexa9hf-vfp-neon-oel-linux-gnueabi/tslib/tslib: PKGR changed from r0.2 to r0.3
The doc command (short: d) is a man-like tool for Yocto
Project’s variables. It searches the
Yocto
Project Reference Manual for variables matching the given regular
expression pattern (matching is case-insensitive).
Example:
$ ye d STAGING_DIR [0] STAGING_DIR [0] [1] STAGING_DIR_TARGET [1] [2] STAGING_DIR_HOST [2] [3] STAGING_DIR_NATIVE [3] Option (ENTER to cancel): 3 === STAGING_DIR_NATIVE Specifies the path to the sysroot directory for the build host.
ye maintains a cache of the Yocto project Reference Manual for seven
days (under $YE_DIR/doc-data). If the cache is older than seven
days, it will fetch the reference manual data and update the cache.
The expand command (short: x) can be very handy to find out
variables' values and how they are assembled. It takes as argument a
recipe and the variable you want to expand. It’ll print the final
variable value and the intermediary expansions (in case the variable
value references other variables) in the context of the given recipe.
Example:
$ ye x core-image-minimal STAGING_DIR_TARGET
Parsing recipes..done.
=== Final value
STAGING_DIR_TARGET = /home/mario/src/yocto/build/tmp/sysroots/nitrogen6x-lite
=== Expansion
STAGING_DIR_TARGET ==> ${STAGING_DIR}/${MACHINE}
STAGING_DIR ==> ${TMPDIR}/sysroots
TMPDIR ==> /home/mario/src/yocto/build/tmp
MACHINE ==> nitrogen6x-lite
Except for the find and grep commands, all commands expect the
BUILDDIR environment variable to be set in the environment. This
variable is automatically set by the setup-environment script
provided by O.S. Systems for the Yocto Project-based projects.
The cd command can be used to move around the project directory.
ye provides some shortcut names for common directories in the layout
adopted by O.S. Systems. See the documentation for the cd command
for all available shortcuts.
Using the cd command is just like using the shell’s cd command,
but giving the available shortcuts as arguments. Examples:
$ pwd /home/mario/src/yocto $ ye cd $ pwd /home/mario/src/yocto/build $ ye cd src $ pwd /home/mario/src/yocto/sources $ ye cd src flex [0] ~/src/yocto/sources/poky/meta/recipes-bsp/grub/files/fix-issue-with-flex-2.5.37.patch [0] [1] ~/src/yocto/sources/poky/meta/recipes-devtools/flex/flex_2.5.39.bb [1] [2] ~/src/yocto/sources/poky/meta/recipes-devtools/flex/flex.inc [2] Option (ENTER to cancel): 0 /home/mario/src/yocto/sources/poky/meta/recipes-bsp/grub/files/fix-issue-with-flex-2.5.37.patch $ pwd /home/mario/src/yocto/sources/poky/meta/recipes-bsp/grub/files $ ye cd wd flex [0] /home/mario/src/yocto/build/tmp/work/x86_64-linux/flex-native [0] [1] /home/mario/src/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/flex [1] Option (ENTER to cancel): 1 /home/mario/src/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/flex $ pwd /home/mario/src/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/flex
|
Note
|
the cd command requires evaluating the ye-cd shell wrapper
that is shipped with ye. O.S. Systems' setup-environment script
will do that automatically if you have ye in your source tree.
|
ye allows you to customize the pager and the editor it uses for
displaying and editing files, respectively.
The configuration is via environment variables. ye uses YE_PAGER
and YE_EDITOR for pager and editor, respectively.
For the editor, ye first checks if YE_EDITOR is set in the
environment. If it is not set, it checks the EDITOR environment
variable. If it is not set, it resorts to emacs. If emacs cannot
be found, you’ll get an error.
For the pager, ye first checks if YE_PAGER is set in the
environment. If it is not set, it checks the PAGER environment
variable. If it is not set, it resorts to less -N %s. If less
cannot be found, you’ll get an error.
%s can be used as a placeholder for the file to act upon.
A Python installation and the directory structure in the layout created by O.S. System’s Yocto Project-based platforms.
ye has been more extensively tested with Python version 2.7.3, but
it should work with other recent Python 2.x versions and with Python
3.x.
For the doc command, the lxml module for Python is
required.
For the cd command, a Bourne-compatible shell is required.
Some ye commands use bitbake behind the scenes, and since
bitbake doesn’t support running multipl instances in parallel under
the same build directory, some ye features may not work while you
are using bitbake.