The CRC32C-ADLER license is the same as the SPDX-standardized Zlib.
Use Zlib over CRC32C-ADLER and as it is the last reference, remove the
CRC32C-ADLER license.
Signed-off-by: Bastian Germann <bage@debian.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The libeigen recipe, which was the only user of this license file, now
uses the Minpack license from OE-Core instead.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Since libeigen is a header-only library, LGPL effectively has the same
properties as GPL when it comes to affecting the licensing of the code
that uses libeigen. To avoid the problem, backport a patch to remove all
LGPL-2.1 code from the library.
Switch to using "Minpack" rather than "MINPACK" as license since the
former is the official SPDX name.
Also correct the licenses for ${PN}, ${PN}-dbg and ${PN}-dev to reflect
that they do not contain any GPL code (the GPL code is only used for
benchmark tests and does not affect what is installed).
License-Update: Correct the license information
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Similarly to c++ protobuf, add products matching historical entries.
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Add all relevant products from following query.
Also remove generic "protobuf" to avoid matching golang:protobuf.
.../downloads/CVE_CHECK2$ sqlite3 nvdcve_2-2.db
sqlite> select vendor, product, count(*) from products where product like '%protobuf%' group by vendor, product;
golang|protobuf|1
google|google-protobuf|5
google|protobuf|2
google|protobuf-cpp|4
google|protobuf-java|15
google|protobuf-javalite|12
google|protobuf-kotlin|6
google|protobuf-kotlin-lite|4
google|protobuf-python|4
protobuf|protobuf|1
protobuf-c_project|protobuf-c|2
protobufjs_project|protobufjs|3
rust-protobuf_project|rust-protobuf|2
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
utf_range is MIT licensed.
Although the LICENSE file is not distributed in python protobuf,
this can be read in c++ protobuf recipe where all files are present.
License-Update: added missing license
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
We should not use additional vendored jsoncpp unless required due to
compatibility issues.
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This commit reverts
https://git.openembedded.org/meta-openembedded/commit/?id=5af1cd3ada4cc86864810a12c82771ba1afdce64
That commit prefers sdk development instead of release images.
The additional libraries are not needed for protobuf at runtime.
Also any component depending on protobuf will have whole abseil-cpp in
sysroots so linking all the libraries is possible and any additional
ones will be installed.
What may not work is if protobuf is installed in sdk image and
application using it wants to use an additional abseil-cpp library.
However that is easily fixable by adding also abseil-cpp to sdk.
Removing hard-dependency in release images is much harder.
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This is handled in protofuf cmake since 3.15:
55ed1d427c
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When linking to capnproto from another project, cmake fails to
find this package with the following error:
| CMake Error at ${RECIPE_SYSROOT}/usr/lib/cmake/CapnProto/CapnProtoTargets.cmake:176 (message):
| The imported target "CapnProto::capnp_tool" references the file
|
| "${RECIPE_SYSROOT}/usr/bin/capnp"
|
| but this file does not exist. Possible reasons include:
To solve this, this change includes the following:
1. Add a patch that removes the files installed (and exported) in
${bindir} from the target build. The CMake file originally verified
that these files exist when another recipe tried to use it, however
the ${RECIPE_SYSROOT} does not contain the binaries in ${bindir},
so it failed quick in the do_configure step. (This alone is enough
to link against the cross-compiled libraries of capnproto successfully,
but code-generation from capnproto definition fails)
2. Add a new bbclass for capnproto. To cross-compile an application
that uses capnproto, the application needs to be linked against the
cross-compiled version of the libraries, however the native version
of the binaries need to be used to generate C++ code from the
capnproto definitions. This class sets the correct CMake arguments, to
use the capnproto binaries from the native package, instead of looking
for the non-existent cross-compiled binaries. (These variables can
be found in ${libdir}/cmake/CapnProto/CapnProtoConfig.cmake file)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
In case "encryption-openssl" PACKAGECONFIG is enabled, do_package_qa fails:
ERROR: open62541-1.3.8-r0 do_package_qa: QA Issue: File /usr/lib/cmake/open62541/open62541Targets.cmake in package open62541-dev contains reference to TMPDIR [buildpaths]
Fix it by changing the value of RECIPE_SYSROOT to CMAKE_SYSROOT variable,
so the qa check passes, and other CMake projects should be still able to find the
CMake package provided by this recipe.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
1. Set the correct LICENSE value
2. Csocket is a submodule of the main znc project. Instead of
cloning it separately in a subfolder, just let the gitsm fetcher
to fetch the correct revisions, at the correct place.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
pipewire-0.2 (which is a pre-pandemic version of pipewire) has been
kept around[1] to satisfy the dependencies of mutter (< 3.36).
Mutter has been updated to a version that doesn't require
this old pipewire more than 3 years ago[2].
There is a much more newer version of pipewire recipe available
in the same folder, and it seems there aren't further recipes depending on
this old version.
[1]: 5200e029ea
[2]: 7cd570b486
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in meta-openembedded recipes to show this is definitely
the preferred formatting.
This fixes recipes with larger numbers of issues but there are just under 100
other references left to fix.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
