I am using dragonboard 410C + yocto, and I’m trying to build Mplayer2 .
mplayer2 refuses to compile due to it’s commercial license:
… was skipped: because it has a restricted license not whitelisted in
LICENSE_FLAGS_WHITELIST
I have already tried adding to local.conf:
LICENSE_FLAGS_WHITELIST = “commercial”
LICENSE_FLAGS_WHITELIST = “commercial_mplayer2”
LICENSE_FLAGS_WHITELIST = “mplayer2”
(did not work)
ant other idea?
thanks!
Here is the information needed for adding correctly components with different licenses to local.conf:
http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes
The problem is that you are overwriting the WHITELIST with new values each time, so it only takes the las value.
You can either delete the last two lines or add a "+" before "=" in the last two lines. This way:
LICENSE_FLAGS_WHITELIST = “commercial”
or
LICENSE_FLAGS_WHITELIST = “commercial”
LICENSE_FLAGS_WHITELIST += “commercial_mplayer2”
LICENSE_FLAGS_WHITELIST += “mplayer2”
Related
I have multiple variants for the same (custom) software. A few variants support different hardware platforms and other wariants support the same hardware platform but with different feature-set. For example I have:
mysoftware.bb (basic version)
mysoftware-qt.bb (basic + qt support)
mysoftware-lic.bb (basic + license support)
mysoftware-qt-lic.bb (basic + license + qt support)
My plan was to add PROVIDES = "mysoftware" to all of these recipes and PREFERRED_PROVIDER_mysoftware = "mysoftware-qt" to my machine conf file.
In my image recipe I wanted to add:
IMAGE_INSTALL += "mysoftware"
Many errors came up... like I had to set RPROVIDES_${PN} = "mysoftware" in every recipe and had to set SSTATE_DUPWHITELIST = "/" in those recipes. (and still not working...)
My question: is there a standard way to achieve this? or is this a bad practice? This seems to be a decent approach for me.
What I wanted to do in the end is:
IMAGE_INSTALL = "... mysoftware" and this will install the appropriate variant and I don't have to do like:
IMAGE_INSTALL_xhw = "... mysoftware-x"
IMAGE_INSTALL_yhw = "... mysoftware-y"
and for those very limited number of times when I have to change from mysoftware to mysoftware-qt I can install it with a package manager (apt in my case):
apt install mysoftware-x-qt
and as a result the conflicting mysoftware-x would be removed and mysoftware-x-qt would be installed easily.
Inside your recipe mysoftware-qt.bb add:
PROVIDES = "virtual/mysoftware"
RPROVIDES_${PN} = "virtual/mysoftware"
Inside your machine.conf add :
PREFERRED_PROVIDER_virtual/mysoftware = "mysoftware-qt
finally add IMAGE_INSTALL += "mysoftware" inside your image recipe
I have two similar boards. I want to write a recipe for each of them. But they will have different kernel patches.How to do it better? Or Should I add new machines to the build?
I added my-machine to mylayer/local.conf
MACHINEOVERRIDES = "imx8qmmek:my-machine"
I created mylayer/recipex-kernel/linux/linux-imx_%.bbappend with my-patch:
SRC_URI_imx8qmmek += " file://0001-add-modified-dts.patch "
SRC_URI_imx8qmmek += " file://0002-EP4668-wifi-bt-modified-dts.patch "
SRC_URI_imx8qmmek += " file://0003-EP4822-enable-USB3-hub.patch "
SRC_URI_my-machine += " file://0004-EP4827-comment-usdhc3.tcu.patch "
SRC_URI_imx8qmmek += " file://EP4133_added_BRCM-PCIE.cfg"
do_configure_append_imx8qmmek() {
bbnote "adding BRCM-PCIE configuration ${PN}"
cat ../*.cfg >> ${B}/.config
}
And I run command:
MACHINE="my-machine" bitbake -c clean linux-imx
But a terminal outputed the error:
WARNING: Layer meta-mylayer should set LAYERSERIES_COMPAT_mylayer in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer meta-mylayer should set LAYERSERIES_COMPAT_meta-mylayer in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: You have included the meta-gnome layer, but 'x11' has not been enabled in your DISTRO_FEATURES. Some bbappend files may not take effect. See the meta-gnome README for details on enabling meta-gnome support.
WARNING: Host distribution "ubuntu-18.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
MACHINE=my-machine is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file.
Similar != identical. If they are indeed slightly different, then two machines is the way to go. If they are sufficiently similar (to be determined by yourself :) ), different distros is also an option. All depends on how different the machines are and how different the final images should be (might need two machines or two distros or both).
If you have two similar machines but need two machine configuration files, put most of the common code into an .inc required by both machines. Don't forget to put a MACHINEOVERRIDES somewhere in that inc file with a name that will make sense for both machines (e.g., if you have rpi3-lcd and rpi3-iot, have an rpi3-common.inc with rpi3-common added to MACHINEOVERRIDES). This will make it possible to use VAR_rpi3-common in recipes that have patches or machine specific stuff in your recipes to apply to both without needing VAR_rpi3-lcd AND VAR_rpi3-iot.
Using Poky (v. 13.0 - Yocto 1.8), I am trying to build the core-image-minimal but excluding the opkg package.
In the generated rootfs, I still have a /usr/lib/opkg/ populated folder.
I tried to play with the following in my build/conf/local.conf
DISTRO_FEATURES_remove += " package-management"
IMAGE_FEATURES_remove += " package-management"
EXTRA_IMAGE_FEATURES_remove += " package-management opkg"
IMAGE_INSTALL_remove += " package-management opkg"
POKY_DEFAULT_EXTRA_RRECOMMENDS = ""
I saw that in meta-yocto/conf/distro/poky-tiny.conf there is the following, which I tried to add (still in my local.conf without success)
PACKAGECONFIG_pn-opkg-utils = ""
Well, if you ensure that IMAGE_FEATURES doesn't contain package-management, that should be enough. (Unless you manually install eg opkg).
Have you looked at /usr/lib/opkg? In my image, that directory only contains alternatives, which in turns holds information about alternative versions of installed applications. See eg update-alternatives.
Do you have any other files or directories under /usr/lib/opkg?
============== Update ==============
These files are not really needed, unless you want/need to run update-alternatives. This could also be run if you do package based updates. However, on a read-only rootfs, these shouldn't be needed.
Something like this could be used if you want /usr/lib/opkg to be removed:
remove_alternative_files () {
rm -rf ${IMAGE_ROOTFS}/usr/lib/opkg
}
ROOTFS_POSTPROCESS_COMMAND += "remove_alternative_files;"
This can be added either directly in your recipe, or if you have a custom image-class.
I'm trying to first uninstall a package, then install the latest version of that same package. Simple you would think, but when I include the following code in my DSC configuration:
### remove old product setup
Package removeOldProduct {
Ensure = 'Absent'
Name = 'My Product Name'
Path = ""
ProductId = ""
}
### now install the latest product setup
Package productSetup {
Ensure = 'Present'
Name = 'My Product Name'
Path = "$productShare\Repository\product.msi"
ProductId = ""
Arguments = "ACCEPT_EULA=1 /q"
DependsOn = '[Package]MsSql'
}
While creating the .mof file, I receive the following error:
Test-ConflictingResources : A conflict was detected between resources '[Package]productSetup and '[Package]removeOldProduct in node 'myNodeServer'. Resources have identical key properties but there are
differences in the following non-key properties: 'Path;Ensure;Arguments'.
I don't want to use a Script resource to process my uninstall. What am I doing wrong here?
Your configuration is supposed to be idempotent, generally, so this doesn't make a lot of sense. You would be uninstalling and reinstalling the package every time the configuration is applied (every 30 minutes or whatever it's set to).
An MSI installer should support upgrading automatically, which means you would just ensure the installation of the (newer) MSI.
I am new to bitbake recipe. I am trying to add HAProxy package into bitbake. I am trying to create a recipe but not sure how to proceed with it.
so far I have just made it till here:
SUMMARY = "HAProxy support for NEXT"
HOMEPAGE = "http://www.haproxy.org/"
SECTION = "tools"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=2d862e836f92129cdc0ecccc54eed5e0"
SRC_URI = "http://www.haproxy.org/download/1.6/src/haproxy-${PV}.tar.gz"
SRC_URI[md5sum] = "3362d1e268c78155c2474cb73e7f03f9"
SRC_URI[sha256sum] = "fd06b45054cde2c69cb3322dfdd8a4bcfc46eb9d0c4b36d20d3ea19d84e338a7"
Can anyone point me to right direction?
haproxy is a Makefile based project, so this link should help:
http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#new-recipe-makefile-based-package
You should define this variable in your recipe:
EXTRA_OEMAKE = "TARGET=XXX"
replacing XXX by the target your are interested (generic, linux22, linux24, and so on). That string TARGET=XXX will be passed as argument to the 'make' command, so bitbake will start compilation. Most probably that's all you need.