I am using yocto build a linux image that integrates some layers of wlan and a specific wifi chip, but seems like patching of one of the files is failing (details below)
Steps that I did:
Created a working directory
initialized a repo for kernel 4.14.98 via:
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.3.3.xml
sync the repo via repo sync
created a tmp folder outside of the current working dir, and download the specific code for wifi via
repo init -u git://codeaurora.org/quic/le/le/manifest.git -b release -m CHSS.LNX_FSLS.1.0-01200-QCAAUTOHOSTHZ.xml –repo-url=git://codeaurora.org/tools/repo.git –repo-branch=caf-stable
repo the sync
copy the meta-qti-connectivity and wlan-opensource folders into the source folder of the working directory
Download the files for a specific wifi chip and copy over meta-qticonnectivity-prop and wlanproprietary into the source folder of the working directory
So now we have added additional 4 directories into the source folder of the working directory
Set up the build environment
Run bitbake core-image-minimal
and I see the following error:
ERROR: wpa-supplicant-git-r0 do_patch: Command Error: 'quilt --quiltrc <working_directory>/linux_image/build/tmp/work/imx8qxpmek-poky-linux/wpa-supplicant/git-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch
patching file src/drivers/nl80211_copy.h
...
15 out of 20 hunks FAILED -- rejects in file src/drivers/nl80211_copy.h
Patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch does not apply (enforce with -f)
ERROR: wpa-supplicant-git-r0 do_patch: Function failed: patch_do_patch
I'm new to yocto, and from the looks of it, it seems the patch 0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch didn't apply, but does that mean the issue is with the patch file or the way it's referenced.
This patch file resides in the meta-fsl-bsp-release layer under wpa-supplicant sub directory, which I DID NOT add manually. This sub-directory has a .bbappend file that refers to these patch files via SRC_URI variable, but it doesn't contain any .bb file.
One of the meta layers that I added has wpa-supplicant sub-directory as well but it only has .bb file and no .bbappend.
I'm confused as to how are these two subdirectories different or could they conflict in anyway? Also, shouldn't the subdirectory have both the .bbappend & a corresponding .bb file?
The SRC_URI variable is used to locate the applicable patch files and do_patch isn't needed in the respective .bb file of wpa-supplicant, right?
the respective bb file wpa-supplicant has the following:
SRC_URI = "file://wlan-opensource/wpa_supplicant_8/"
SRC_URI += "file://hostapdconf \
file://supplicantconf \
shouldn't patch files be defined with .patch at the end?
Also, I see in the yocto documentation that the path defined in file:// is relative to the FILESPATH variable, which in the bb file is defined to be "${BSPDIR}/sources:" - not certain of BSPDIR itself but I think it's referring to <top_dir>/sources, but does that mean hostapdconf is supposed to be at <top_dir>/sources? I don't see it there but in other sub directory
To me it looks like you have added a .bbappend for the wpa-supplicant recipe in a version that does not match the recipe. Likely the .bbappend is from one of the meta layers you copied into your source tree manually (meta-qti-connectivity or wlan-opensource).
I'm new to yocto, and from the looks of it, it seems the patch
0009-Sync-with-mac80211-next.git-include-uapi-linux-nl802.patch didn't
apply, but does that mean the issue is with the patch file or the way
it's referenced?
Likely the patch is targetet at a different version of the source file.
The SRC_URI variable is used to locate the applicable patch files and
do_patch isn't needed in the respective .bb file of wpa-supplicant,
right?
Right, if you don't see it explicitly ly in the .bb. The default do_patch task will be used.
the respective bb file wpa-supplicant has the following:
SRC_URI = "file://wlan-opensource/wpa_supplicant_8/" SRC_URI +=
"file://hostapdconf
file://supplicantconf \ shouldn't patch files be defined
with .patch at the end?
The .patch file is probably referenced by name in a .bbappend if you dont see it in the .bb file.
Related
I'm trying to build a Yocto receipe that depends on libnotify. When it attempts to build libnotify I get a fetcher error: "ERROR: libnotify-0.7.8-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'https://download.gnome.org/sources//libnotify/0.7/libnotify-0.7.8.tar.xz;name=archive')" I noticed that the URL has an extra / in it. I tried looking in /meta/recipes-gnome/libnotify/libnotify_0.7.8.bb but I don't see a SRC_URI defined so I don't understand where it is getting this URI from. Does someone know how to correct this?
An SRC_URI pointing to this URL: https://download.gnome.org/sources//libnotify/0.7/libnotify-0.7.8.tar.xz must exist.
In /meta/recipes-gnome/libnotify/libnotify_0.7.8.bb there is an SRC_URI[archive.md5sum] =babb... Here "archive" is the name of the SRC_URI which is defined elsewhere more likely in classes/clutter.bbclass or classes/gnomebase.bbclass
Make sure you have not a proxy then try to build again.
As a workaround. You can download this archive with wget command.
wget https://download.gnome.org/sources//libnotify/0.7/libnotify-0.7.8.tar.xz;name=archive
Put it inside your download directory.
Then create inside the download directory a file named as the archive but with .done extension at the end.
touch libnotify-0.7.8.tar.xz.done
Thus, bitbake will notice that the archive is already present and there is no need to fetch it again.
I need to access the target path to kernel modules in a recipe, is there a variable with such information?
I mean, where can i get "/lib/modules/4.1.23-fslc+g3617c73" since this path may change because of configuration?
The destination directory is as follows.
Look into bbclass file kernel.bbclass in poky/meta/classes/ function kernel_do_install
It is passed as a make option
oe_runmake DEPMOD=echo MODLIB=${D}${nonarch_base_libdir}/module/${KERNEL_VERSION} INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
I hope below info will help you,
the kernel modules path is `
tmp-glibc/work/beaglebone-linux-gnueabi/linux-ti/3.12.30-phy10-r0.0/image/lib/modules/3.12.30-AM335x-PD15.3.0`
if you add your code in your linux kernel and compile as modules(.ko) by default it will add in above mentioned path.
If you want to copy your module(.ko) manually to the lib/modules path copy your.ko file to sources/meta-youlayer/recipes-kernel/linux and create linux-ti_%.bbappend file ad below line
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI +="file://your.ko"
do_install_append(){
install -m 0777 ${S}/your.ko ${D}/lib/modules/version
}
I did not try this yet. hope it will work.
Introduction
I have a do_install task in a BitBake recipe which I've written for a driver where I execute a custom install script. The task fails because the installation script cannot find kernel source header files within <the image rootfs>/usr/src/kernel. This script runs fine on the generated OS.
What's Happening
Here's the relevant part of my recipe:
SRC_URI += "file://${TOPDIR}/example"
DEPENDS += " virtual/kernel linux-libc-headers "
do_install () {
( cd ${TOPDIR}/example/Install ; ./install )
}
Here's a relevant portion of the install script:
if [ ! -d "/usr/src/kernel/include" ]; then
echo ERROR: Linux kernel source include directory not found.
exit 1
fi
cd /usr/src/kernel
make scripts
...
./install_drv pci ${DRV_ARGS}
I checked changing to if [ ! -d "/usr/src/kernel" ], which also failed. install passes different options to install_drv, which I have a relevant portion of below:
cd ${DRV_PATH}/pci
make NO_SYSFS=${ARG_NO_SYSFS} NO_INSTALL=${ARG_NO_INSTALL} ${ARGS_HWINT}
if [ ${ARG_NO_INSTALL} == 0 ]; then
if [ `/sbin/lsmod | grep -ci "uceipci"` -eq 1 ]; then
./unload_pci
fi
./load_pci DEBUG=${ARG_DEBUG}
fi
The make target build: within ${DRV_PATH}/pci is essentially this:
make -C /usr/src/kernel SUBDIRS=${PWD} modules
My Research
I found these comments within linux-libc-headers.inc relevant:
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
#
# Why? These headers are used to build the libc. If you customise the
# headers you are customising the libc and the libc becomes machine
# specific. Most people do not add custom libc extensions to the kernel
# and have a machine specific libc.
#
# But you have some kernel headers you need for some driver? That is fine
# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
# This will make the package using them machine specific but this is much
# better than having a machine specific C library. This does mean your
# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
# makes total sense.
#
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
I'm a bit unclear if I can 'get' the headers from the STAGING_KERNEL_DIR properly since I'm not using make.
Within kernel.bbclass provided in the meta/classes directory, there is this variable assigment:
# Define where the kernel headers are installed on the target as well as where
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"
This path is then packaged later within that .bbclass file here:
PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules"
...
FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} /lib/modules/${KERNEL_VERSION}/build"
Update (1/21):
A suggestion on the yocto IRC channel was to use the following line:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
which is corroborated by the Yocto Project Reference Manual, which states that in version 1.8, there was the following change:
The kernel build process was changed to place the source in a common shared work area and to place build artifacts separately in the source code tree. In theory, migration paths have been provided for most common usages in kernel recipes but this might not work in all cases. In particular, users need to ensure that ${S} (source files) and ${B} (build artifacts) are used correctly in functions such as do_configure and do_install. For kernel recipes that do not inherit from kernel-yocto or include linux-yocto.inc, you might wish to refer to the linux.inc file in the meta-oe layer for the kinds of changes you need to make. For reference, here is the commit where the linux.inc file in meta-oewas updated.
Recipes that rely on the kernel source code and do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
But I'm having difficulties applying this to my recipe. From what I understand, I should be able to change the above line to:
do_install[depends] += "virtual/kernel:do_shared_workdir"
Which would mean that the do_install task now must be run after do_shared_workdir task of the virtual/kernel recipe, which means that I should be able to work with the shared workdir (see Question 3 below), but I still have the same missing kernel header issue.
My Questions
I'm using a custom linux kernel (v3.14) from git.kernel.org. which inherits the kernel class. Here are some of my questions:
Shouldn't the package kernel-dev be a part of any recipe which inherits the kernel class? (this section of the variables glossary)
If I add the virtual/kernel to the DEPENDS variable, wouldn't that mean that the kernel-dev would be brought in?
If kernel-dev is part of the dependencies of my recipe, wouldn't I be able to point to the /usr/src/kernel directory from my recipe? According to this reply on the Yocto mailing list, I think I should.
How can I properly reference the kernel source header files, preferably without changing the installation script?
Consider your Environment
Remember that there are different environments within the the build time environment, consisting of:
sysroots
in the case of kernels, a shared work directory
target packages
kernel-dev is a target package, which you'd install into the rootfs of the target system for certain things like kernel symbol maps which are needed by profiling tools like perf/oprofile. It is not present at build time although some of its contents are available in the sysroots or shared workdir.
Point to the Correct Directories
Your do_install runs at build time so this is within the build directory structures of the build system, not the target one. In particular, /usr/src/ won't be correct, it would need to be some path within your build directory. The virtual/kernel do_shared_workdir task populates ${STAGING_DIR_KERNEL} so you would want to change to that directory in your script.
Adding a Task Dependency
The:
do_install[depends] += "virtual/kernel:do_shared_workdir
dependency like looks correct for your use case, assuming nothing in do_configure or do_compile accesses the data there.
Reconsider the module BitBake class
The other answers are correct in the recommendation to look at module.bbclass, since this illustrates how common kernel modules can be built. If you want to use custom functions or make commands, this is fine, you can just override them. If you really don't want to use that class, I would suggest taking inspiration from it though.
Task Dependencies
Adding virtual/kernel to DEPENDS means virtual/kernel:do_populate_sysroot must run before our do_configure task. Since you need a dependency for do_shared_workdir here, a DEPENDS on virtual/kernel is not enough.
Answer to Question 3
The kernel-dev package would be built, however it would then need to be installed into your target image and used at runtime on a real target. You need this at build time so kernel-dev is not appropriate.
Other Suggestions
You'd likely want the kernel-devsrc package for what you're doing, not the kernel-dev package.
I don't think anyone can properly answer that last question here. You are using a non-standard install method: we can't know how to interact with it...
That said, take a look at what meta/classes/module.bbclass does. It sets several related variables for make: KERNEL_SRC=${STAGING_KERNEL_DIR}, KERNEL_PATH=${STAGING_KERNEL_DIR}, O=${STAGING_KERNEL_BUILDDIR}. Maybe your installer supports some of these environment variables and you could set them in your recipe?
I'm getting this error on my mac osx build.
Primer3/eprimer3 issue:
Error: thermodynamic approach chosen, but path to thermodynamic parameters not specified
From:
http://www.mcardle.wisc.edu/mprime/help/primer3/primer3_manual.htm#globalTags
PRIMER_THERMODYNAMIC_PARAMETERS_PATH (string; default ./primer3_config)
This tag specifies the path to the directory that contains all the parameter files used by the thermodynamic approach. In Linux, there are two default locations that are tested if this tag is not defined: ./primer3_config/ and /opt/primer3_config/. For Windows, there is only one default location: .\primer3_config\.
I put the primer3_config in my PATH in bin and still cannot solve this issue. I even did:
export PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/Users/jared/Downloads/primer3-2.3.2/src
and
export PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/Users/jared/Downloads/primer3-2.3.2/src/primer3_config
to no avail.
According to the primer3 manual:
1.5. IMPORTANT: because PRIMER_THERMODYNAMIC_ALIGNMENT=1
PRIMER_THERMODYNAMIC_PARAMETERS_PATH must point to the right location.
This tag specifies the path to the directory that contains all the
parameter files used by the thermodynamic approach. In Linux, there
are two default locations that are tested if this tag is not
defined: ./primer3_config/ and /opt/primer3_config/. For Windows,
there is only one default location: .\primer3_config. If the the
parameter files are not in one these locations, be sure to set
PRIMER_THERMODYNAMIC_PARAMETERS_PATH.
So if you download and compile primer3 form source using the Make command, to get primer3 to run globally you need to copy the executueable, primer3_core, to your path and place the configuration directory, primer3_config in that same directory or at /opt/primer3_config
cd src
sudo cp primer3_core /usr/local/bin # or /usr/bin
sudo cp -r primer3_config /opt/
I has the same issue. I had installed Primer 3 using homebrew-science which was pretty painless. https://github.com/Homebrew/homebrew-science
I did try copying the primer3_config directory into the homebrew primer3 directory, ie:
/usr/local/Cellar/primer3/2.3.4/bin/primer3_config but this also did not work.
In the end I added the PRIMER_THERMODYNAMIC_PARAMETERS_PATH configuration to the primer 3 input file, and this worked. Note that the directory name must have a trailing slash. It is the last entry in the file below which is copied from the example file in the primer3 sources.
SEQUENCE_ID=example
SEQUENCE_TEMPLATE=GTAGTCAGTAGACNATGACNACTGACGATGCAGACNACACACACACACACAGCACACAGGTATTAGTGGGCCATTCGATCCCGACCCAAATCGATAGCTACGATGACG
SEQUENCE_TARGET=37,21
PRIMER_TASK=pick_detection_primers
PRIMER_PICK_LEFT_PRIMER=1
PRIMER_PICK_INTERNAL_OLIGO=1
PRIMER_PICK_RIGHT_PRIMER=1
PRIMER_OPT_SIZE=18
PRIMER_MIN_SIZE=15
PRIMER_MAX_SIZE=21
PRIMER_MAX_NS_ACCEPTED=1
PRIMER_PRODUCT_SIZE_RANGE=75-100
P3_FILE_FLAG=1
SEQUENCE_INTERNAL_EXCLUDED_REGION=37,21
PRIMER_EXPLAIN_FLAG=1
PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/usr/local/Cellar/primer3/2.3.4/bin/primer3_config/
=
Then run it like this:
$ primer3_core < example2
I've setup a custom configuration file for Pylint (name, conveniently, config). There has to be a way that I don't have to include --rcfile=config on every run. How can I set the config file permanently?
When you do not specify the --rcfile option, Pylint searches for a configuration file in the following order and uses the first one it finds:
pylintrc in the current working directory
If the current working directory is in a Python module, Pylint
searches up the hierarchy of Python modules until it finds a
pylintrc file. This allows you to specify coding standards on a
module-by-module basis. Of course, a directory is judged to be a
Python module if it contains an __init__.py file.
The file named by environment variable PYLINTRC
.pylintrc in your home directory, unless you have no home directory
or your home directory is /root
.pylintrc in the current working directory
/etc/pylintrc
Thus depending on the method you choose, Pylint can use a different configuration file based on the location of the code, the user or the machine.
Note that the configuration file only applies to Python files that are in modules. Thus, Pylint still uses its default rules when analyzing Python files in a directory with no __init__.py file.
For example, I have a bin/ directory containing command line applications. Ordinarily, this directory needs no __init__.py file because it is never imported. I had to add a bin/__init__.py file to get Pylint to analyze these Python files using my pylintrc file.
set the path to that file in the PYLINTRC environment variable, or rename the file $HOME/.pylintrc or /etc/pylintrc (the latter is probably only supported on *nix)
It can be done using .pre-commit-config.yaml. This snippet below need to be added to .pre-commit-config.yaml:
repos:
- repo: local
hooks:
- id: pylint
name: pylint
entry: pylint
language: system
types: [python]
args: [
"-rn", # Only display messages
"-sn", # Don't display the score
"--rcfile=.pylintrc", # Link to your config file
"--load-plugins=pylint.extensions.docparams", # Load an extension
]