Unable to add additional layers #83
Comments
|
Add in meta-sysrepo/conf/layer.conf secondly somewhere you seem to have inherit classes/openwrt-distro-defaults.bbclass this is not correct you only need |
|
I cleaned up the directory by removing the cache, downloads, sstate-cache and tmp directories I searched local.conf and bblayer.conf and did not file openwrt-distro-defaules.bbclass in any area and I'm still hitting the bitbake-layers show-layers error. [root@hostname Cl-Img]# bitbake-layers show-layers ERROR: Unable to start bitbake server [root@hostname Cl-Img]# my local.conf is: This file is your local configuration file and is where all local user settingsare placed. The comments in this file give some guide to the options a new userto the system might want to change but pretty much any configuration option canbe set in this file. More adventurous users can look at local.conf.extendedwhich contains other examples of configuration which can be placed in this filebut new users likely won't need any of them initially.Lines starting with the '#' character are commented out and in some cases thedefault values are provided as comments to show people example syntax. Enablingthe option is a question of removing the # character and making any change to thevariable as required.Machine SelectionYou need to select a specific machine to target the build with. There are a selectionof emulated machines available which can boot and run in the QEMU emulator:#MACHINE ?= "qemuarm" There are also the following hardware board target machines included fordemonstration purposes:#MACHINE ?= "beaglebone-yocto" This sets the default machine to be qemux86 if no other machine is selected:MACHINE ??= "qemux86" Where to place downloadsDuring a first build the system will download many different source code tarballsfrom various upstream projects. This can take a while, particularly if your networkconnection is slow. These are all stored in DL_DIR. When wiping and rebuilding youcan preserve this directory to speed up this part of subsequent builds. This directoryis safe to share between multiple builds on the same machine too.The default is a downloads directory under TOPDIR which is the build directory.#DL_DIR ?= "${TOPDIR}/downloads" Where to place shared-state filesBitBake has the capability to accelerate builds based on previously built output.This is done using "shared state" files which can be thought of as cache objectsand this option determines where those files are placed.You can wipe out TMPDIR leaving this directory intact and the build would regeneratefrom these files if no changes were made to the configuration. If changes were madeto the configuration, only shared state files where the state was still valid wouldbe used (done using checksums).The default is a sstate-cache directory under TOPDIR.#SSTATE_DIR ?= "${TOPDIR}/sstate-cache" Where to place the build outputThis option specifies where the bulk of the building work should be done andwhere BitBake should place its temporary files and output. Keep in mind thatthis includes the extraction and compilation of many applications and the toolchainwhich can use Gigabytes of hard disk space.The default is a tmp directory under TOPDIR.#TMPDIR = "${TOPDIR}/tmp" Default policy configThe distribution setting controls which policy settings are used as defaults.The default value is fine for general Yocto project use, at least initially.Ultimately when creating custom policy, people will likely end up subclassingthese defaults.DISTRO ?= "poky" As an example of a subclass there is a "bleeding" edge policy configurationwhere many versions are set to the absolute latest code from the upstreamsource control systems. This is just mentioned here as an example, its notuseful to most new users.DISTRO ?= "poky-bleeding"#DISTRO_FEATURES_append = " virtualization" Package Management configurationThis variable lists which packaging formats to enable. Multiple package backendscan be enabled at once and the first item listed in the variable will be usedto generate the root filesystems.Options are:- 'package_deb' for debian style deb files- 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)- 'package_rpm' for rpm style packagesE.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"We default to rpm:PACKAGE_CLASSES ?= "package_rpm " SDK target architectureThis variable specifies the architecture to build SDK items for and meansyou can build the SDK packages for architectures other than the machine you arerunning the build on (i.e. building i686 packages on an x86_64 host).Supported values are i686 and x86_64#SDKMACHINE ?= "i686" Extra image configuration defaultsThe EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generatedimages. Some of these options are added to certain image types automatically. Thevariable can contain the following options:"dbg-pkgs" - add -dbg packages for all installed packages(adds symbol information for debugging/profiling)"dev-pkgs" - add -dev packages for all installed packages(useful if you want to develop against libs in the image)"ptest-pkgs" - add -ptest packages for all ptest-enabled packages(useful if you want to run the package test suites)"tools-sdk" - add development tools (gcc, make, pkgconfig etc.)"tools-debug" - add debugging tools (gdb, strace)"eclipse-debug" - add Eclipse remote debugging support"tools-profile" - add profiling tools (oprofile, lttng, valgrind)"tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)"debug-tweaks" - make an image suitable for developmente.g. ssh root access has a blank passwordThere are other application targets that can be used here too, seemeta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.We default to enabling the debugging tweaks.LAYERSERIES_COMPAT_sysrepo = "sumo" Additional image featuresThe following is a list of additional classes to use when building images whichenable extra features. Some available options which can be included in this variableare:- 'buildstats' collect build statistics- 'image-mklibs' to reduce shared library files size for an image- 'image-prelink' in order to prelink the filesystem imageNOTE: if listing mklibs & prelink both, then make sure mklibs is before prelinkNOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extendedUSER_CLASSES ?= "buildstats image-mklibs image-prelink" Runtime testing of imagesThe build system can test booting virtual machine images under qemu (an emulator)after any root filesystems are created and run tests against those images. Toenable this uncomment this line. See classes/testimage(-auto).bbclass forfurther details.#TEST_IMAGE = "1" Interactive shell configurationUnder certain circumstances the system may need input from you and to do this itcan launch an interactive shell. It needs to do this since the build ismultithreaded and needs to be able to handle the case where more than one parallelprocess may require the user's attention. The default is iterate over the availableterminal types to find one that works.Examples of the occasions this may happen are when resolving patches which cannotbe applied, to use the devshell or the kernel menuconfigSupported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), noneNote: currently, Konsole support only works for KDE 3.x due to the waynewer Konsole versions behave#OE_TERMINAL = "auto" By default disable interactive patch resolution (tasks will just fail instead):PATCHRESOLVE = "noop" Disk Space Monitoring during the buildMonitor the disk space during the build. If there is less that 1GB of space or lessthan 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefullyshutdown the build. If there is less that 100MB or 1K inodes, perform a hard abortof the build. The reason for this is that running completely out of space can corruptfiles and damages the build in ways which may not be easily recoverable.It's necesary to monitor /tmp, if there is no space left the build will failwith very exotic errors.BB_DISKMON_DIRS ??= " Shared-state files from other locationsAs mentioned above, shared state files are prebuilt cache data objects which canused to accelerate build time. This variable can be used to configure the systemto search other mirror locations for these objects before it builds the data itself.This can be a filesystem directory, or a remote url such as http or ftp. Thesewould contain the sstate-cache results from previous builds (possibly from othermachines). This variable works like fetcher MIRRORS/PREMIRRORS and points to thecache locations to check for the shared objects.NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATHat the end as shown in the examples below. This will be substituted with thecorrect path within the directory structure.#SSTATE_MIRRORS ?= " Yocto Project SState MirrorThe Yocto Project has prebuilt artefacts available for its releases, you can enableuse of these by uncommenting the following line. This will mean the build usesthe network to check for artefacts at the start of builds, which does slow it downequally, it will also speed up the builds by not having to build things if they arepresent in the cache. It assumes you can download something faster than you can build itwhich will depend on your network.#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH" Qemu configurationBy default qemu will build with a builtin VNC server where graphical output can beseen. The two lines below enable the SDL backend too. By default libsdl-native willbe built, if you want to use your host's libSDL instead of the minimal libsdl builtby libsdl-native then uncomment the ASSUME_PROVIDED line below.PACKAGECONFIG_append_pn-qemu-native = " sdl" CONF_VERSION is increased each time build/conf/ changes incompatibly and is used totrack the version of this file when it was generated. This can safely be ignored ifthis doesn't mean anything to you.CONF_VERSION = "1"` and my bblayers.conf is: changes incompatiblyPOKY_BBLAYERS_CONF_VERSION = "2" BBPATH = "${TOPDIR}" BBLAYERS ?= " I added the LAYERSERIES_COMPAT in local and still am having the issue. Thanks |
|
Hi, it's hard to read your configs because they are formatted badly. Please edit and reformat as 'code blocks' so that they get displayed verbatim instead of as if they were Markdown soure. can you verify that BBLAYERS is actually set to what you have in bblayers.conf? |
|
I'm wondering about your BBLAYERS variable. @kraj can correct me if I'm wrong, but normally bitbake lists are space-separated not newline seperated, and the backslash (\) character is used at the end of the line so the variable is process properly. |
|
|
|
Look like you need the sumo compat thing in the 'appliance' layer as well and missed that one? |
I am attempting to compile with added layers and I encountering errors.
bitbake-layers show-layers
NOTE: Starting bitbake server...
ERROR: Unable to start bitbake server
ERROR: Server log for this session (/root/Yocto/poky/Cl-Img/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 9855 at 2018-07-03 13:26:59.125015 ---
WARNING: Layer appliance should set LAYERSERIES_COMPAT_appliance in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
ERROR: ParseError in configuration INHERITs: Could not inherit file classes/openwrt-distro-defaults.bbclass
WARNING: Layer appliance should set LAYERSERIES_COMPAT_appliance in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer appliance should set LAYERSERIES_COMPAT_appliance in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
ERROR: ParseError in configuration INHERITs: Could not inherit file classes/openwrt-distro-defaults.bbclass
ERROR: ParseError in configuration INHERITs: Could not inherit file classes/openwrt-distro-defaults.bbclass
ERROR: Unable to start bitbake server
ERROR: Server log for this session (/root/Yocto/poky/Cl-Img/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 9855 at 2018-07-03 13:26:59.125015 ---
WARNING: Layer appliance should set LAYERSERIES_COMPAT_appliance in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
ERROR: ParseError in configuration INHERITs: Could not inherit file classes/openwrt-distro-defaults.bbclass
WARNING: Layer appliance should set LAYERSERIES_COMPAT_appliance in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer appliance should set LAYERSERIES_COMPAT_appliance in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer sysrepo should set LAYERSERIES_COMPAT_sysrepo in its conf/layer.conf file to list the core layer names it is compatible with.
ERROR: ParseError in configuration INHERITs: Could not inherit file classes/openwrt-distro-defaults.bbclass
ERROR: ParseError in configuration INHERITs: Could not inherit file classes/openwrt-distro-defaults.bbclass
My local.conf
cat conf/local.conf
This file is your local configuration file and is where all local user settings
are placed. The comments in this file give some guide to the options a new user
to the system might want to change but pretty much any configuration option can
be set in this file. More adventurous users can look at local.conf.extended
which contains other examples of configuration which can be placed in this file
but new users likely won't need any of them initially.
Lines starting with the '#' character are commented out and in some cases the
default values are provided as comments to show people example syntax. Enabling
the option is a question of removing the # character and making any change to the
variable as required.
Machine Selection
You need to select a specific machine to target the build with. There are a selection
of emulated machines available which can boot and run in the QEMU emulator:
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
There are also the following hardware board target machines included for
demonstration purposes:
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ??= "qemux86"
Where to place downloads
During a first build the system will download many different source code tarballs
from various upstream projects. This can take a while, particularly if your network
connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
can preserve this directory to speed up this part of subsequent builds. This directory
is safe to share between multiple builds on the same machine too.
The default is a downloads directory under TOPDIR which is the build directory.
#DL_DIR ?= "${TOPDIR}/downloads"
IMAGE_FSTYPES += "wic.qcow2"
Where to place shared-state files
BitBake has the capability to accelerate builds based on previously built output.
This is done using "shared state" files which can be thought of as cache objects
and this option determines where those files are placed.
You can wipe out TMPDIR leaving this directory intact and the build would regenerate
from these files if no changes were made to the configuration. If changes were made
to the configuration, only shared state files where the state was still valid would
be used (done using checksums).
The default is a sstate-cache directory under TOPDIR.
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
Where to place the build output
This option specifies where the bulk of the building work should be done and
where BitBake should place its temporary files and output. Keep in mind that
this includes the extraction and compilation of many applications and the toolchain
which can use Gigabytes of hard disk space.
The default is a tmp directory under TOPDIR.
#TMPDIR = "${TOPDIR}/tmp"
TCLIBC = "musl"
Default policy config
The distribution setting controls which policy settings are used as defaults.
The default value is fine for general Yocto project use, at least initially.
Ultimately when creating custom policy, people will likely end up subclassing
these defaults.
DISTRO ?= "poky"
As an example of a subclass there is a "bleeding" edge policy configuration
where many versions are set to the absolute latest code from the upstream
source control systems. This is just mentioned here as an example, its not
useful to most new users.
DISTRO ?= "poky-bleeding"
#DISTRO_FEATURES_append = " virtualization"
Package Management configuration
This variable lists which packaging formats to enable. Multiple package backends
can be enabled at once and the first item listed in the variable will be used
to generate the root filesystems.
Options are:
- 'package_deb' for debian style deb files
- 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
- 'package_rpm' for rpm style packages
E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
We default to rpm:
PACKAGE_CLASSES ?= "package_rpm "
SDK target architecture
This variable specifies the architecture to build SDK items for and means
you can build the SDK packages for architectures other than the machine you are
running the build on (i.e. building i686 packages on an x86_64 host).
Supported values are i686 and x86_64
#SDKMACHINE ?= "i686"
Extra image configuration defaults
The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
images. Some of these options are added to certain image types automatically. The
variable can contain the following options:
"dbg-pkgs" - add -dbg packages for all installed packages
(adds symbol information for debugging/profiling)
"dev-pkgs" - add -dev packages for all installed packages
(useful if you want to develop against libs in the image)
"ptest-pkgs" - add -ptest packages for all ptest-enabled packages
(useful if you want to run the package test suites)
"tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
"tools-debug" - add debugging tools (gdb, strace)
"eclipse-debug" - add Eclipse remote debugging support
"tools-profile" - add profiling tools (oprofile, lttng, valgrind)
"tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
"debug-tweaks" - make an image suitable for development
e.g. ssh root access has a blank password
There are other application targets that can be used here too, see
meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
We default to enabling the debugging tweaks.
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
CORE_IMAGE_EXTRA_INSTALL += "openssh strongswan dhcp-server dhcp-client"
INHERIT += " openwrt-distro-defaults "
#INHERIT += " extrausers "
IMAGE_INSTALL_append = " sysrepo netopeer2-server netopeer2-cli netopeer2-keystored openssh openssl "
EXTRA_IMAGE_FEATURES_append = " package-management "
PACKAGE_EXCLUDE += " packagegroup-core-ssh-dropbear read-only-rootfs"
#MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
#KERNEL_MODULE_AUTOLOAD += "ip_gre"
#EXTRA_USERS_PARAMS = "usermod -P thincpe root;"
Additional image features
The following is a list of additional classes to use when building images which
enable extra features. Some available options which can be included in this variable
are:
- 'buildstats' collect build statistics
- 'image-mklibs' to reduce shared library files size for an image
- 'image-prelink' in order to prelink the filesystem image
NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
Runtime testing of images
The build system can test booting virtual machine images under qemu (an emulator)
after any root filesystems are created and run tests against those images. To
enable this uncomment this line. See classes/testimage(-auto).bbclass for
further details.
#TEST_IMAGE = "1"
Interactive shell configuration
Under certain circumstances the system may need input from you and to do this it
can launch an interactive shell. It needs to do this since the build is
multithreaded and needs to be able to handle the case where more than one parallel
process may require the user's attention. The default is iterate over the available
terminal types to find one that works.
Examples of the occasions this may happen are when resolving patches which cannot
be applied, to use the devshell or the kernel menuconfig
Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
Note: currently, Konsole support only works for KDE 3.x due to the way
newer Konsole versions behave
#OE_TERMINAL = "auto"
By default disable interactive patch resolution (tasks will just fail instead):
PATCHRESOLVE = "noop"
Disk Space Monitoring during the build
Monitor the disk space during the build. If there is less that 1GB of space or less
than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
of the build. The reason for this is that running completely out of space can corrupt
files and damages the build in ways which may not be easily recoverable.
It's necesary to monitor /tmp, if there is no space left the build will fail
with very exotic errors.
BB_DISKMON_DIRS ??= "
STOPTASKS,${TMPDIR},1G,100K
STOPTASKS,${DL_DIR},1G,100K
STOPTASKS,${SSTATE_DIR},1G,100K
STOPTASKS,/tmp,100M,100K
ABORT,${TMPDIR},100M,1K
ABORT,${DL_DIR},100M,1K
ABORT,${SSTATE_DIR},100M,1K
ABORT,/tmp,10M,1K"
Shared-state files from other locations
As mentioned above, shared state files are prebuilt cache data objects which can
used to accelerate build time. This variable can be used to configure the system
to search other mirror locations for these objects before it builds the data itself.
This can be a filesystem directory, or a remote url such as http or ftp. These
would contain the sstate-cache results from previous builds (possibly from other
machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
cache locations to check for the shared objects.
NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
at the end as shown in the examples below. This will be substituted with the
correct path within the directory structure.
#SSTATE_MIRRORS ?= "
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n
#file://.* file:///some/local/dir/sstate/PATH"
Yocto Project SState Mirror
The Yocto Project has prebuilt artefacts available for its releases, you can enable
use of these by uncommenting the following line. This will mean the build uses
the network to check for artefacts at the start of builds, which does slow it down
equally, it will also speed up the builds by not having to build things if they are
present in the cache. It assumes you can download something faster than you can build it
which will depend on your network.
#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"
Qemu configuration
By default qemu will build with a builtin VNC server where graphical output can be
seen. The two lines below enable the SDL backend too. By default libsdl-native will
be built, if you want to use your host's libSDL instead of the minimal libsdl built
by libsdl-native then uncomment the ASSUME_PROVIDED line below.
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
#ASSUME_PROVIDED += "libsdl-native"
CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
track the version of this file when it was generated. This can safely be ignored if
this doesn't mean anything to you.
CONF_VERSION = "1"
my bblayers.conf
cat conf/bblayers.conf
POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= "
/root/Yocto/poky/meta
/root/Yocto/poky/meta-poky
/root/Yocto/poky/meta-openwrt
/root/Yocto/poky/meta-openembedded/meta-initramfs
/root/Yocto/poky/meta-openembedded/meta-networking
/root/Yocto/poky/meta-openembedded/meta-oe
/root/Yocto/poky/meta-openembedded/meta-python
/root/Yocto/poky/meta-sysrepo
/root/Yocto/poky/meta-openembedded/meta-webserver
/root/Yocto/poky/meta-yocto-bsp
"
Any other info thats needed please let me know. Much appreciated.
The text was updated successfully, but these errors were encountered: