The protobuf recipes are in meta-oe, and were only here to support
higher order virtualization tasks.
Dropping the recipes and we'll use the ones directly from meta-oe,
since the versions and compatibility should be fine.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
This will eventually be available in meta-openembedded so will be able
to be reverted. This will allow us to use openvswitch with python3 in
the interim.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
According to https://github.com/docker/libtrust, this repo is now deprecated
and the library was integrated in the docker-distribution repository.
Signed-off-by: Anselmo L. S. Melo <anselmo.melo@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
As far as I can tell openvswitch has been updated to work with python3
as well as with python(2). Switch to depend on python3 and use python3
for associated scripts. For the most part openvswitch will bind at
runtime to either py2 or py3 regardless of these changes, with these
changes we just do a better job of setting up the dependencies to
facilitate py3 bindings. The openvswitch autotests results are mostly
identical before and after this switch (failures move from python3 to
python(2) test cases as expected, with some exceptions see below).
When running the autotests/ptest with python(2) vs python3 we see a
slightly higher failure rate (334 failures vs. 284 failures). I do not
believe this higher fail rate reflects actual errors in the runtime,
rather the tests are not adapted to python3. At any rate like the rest
of openvswitch it is fairly straightforward to hack the logic for
autotests to be run using py2 as long as it is available in the image,
so these changes don't prevent falling back to py2 for autotests. This
should facilitate any debugging we need to do based on us switching to
favor py3.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
On a minimally provisioned rootfs the tests are currently getting
'stuck' after running for a few minutes because 'find' and 'which' are
not being found. Add these to the ptest package RDEPENDS to ensure
they are present in the rootfs.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
gcc 7 has a bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11672https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969
In order to avoid the build failure that this causes we reduce the
range by one. Better to have a slight reduction in the range than
having nobody to be able to build and use lxc.
Once gcc is fixed this can be reverted.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
1)Upgrade lxc from 2.0.0 to 2.0.8.
2)Delete two patches, since it is integrated upstream.
Delete Generate-lxc-restore-net-properly.patch,this script has already been rearchitected out of existence by cba98d127bf490b018a016b792ae05fd2d29c5ee
Delete Use-AC_HEADER_MAJOR-to-detect-major-minor-makedev.patch,this script has already been rearchitected out of existence by af6824fce9c9536fbcabef8d5547f6c486f55fdf from git://github.com/lxc/lxc.git
3)Modify two patches, since the data has been changed.
automake-ensure-VPATH-builds-correctly.patch
runtest.patch
Signed-off-by: Huang Qiyu <huangqy.fnst@cn.fujitsu.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Updating to the latest oci-image-tools for better support in unpack/creating
runtime bundles.
With this update, we get a single tool with subcommands, versus separate
commands previously.
We also add two proposed (but not merged) patches that can deal with existing
symlinks when unpacking layers. Without this, we fail to unpack many complex
containers due to duplicate files in layers.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Due to error in naming this service will not be autoenabled in
systems with systemd init manager
Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Commit 8709d4504c35817ef1d7181b47ba96c3ca0c949e [lvm2: separate
libdevmapper to avoid circular dependency] in meta-oe meant that our
build would fail with
checking for libdevmapper.h... no
configure: error: You must install device-mapper-devel/libdevmapper >= 1.0.0 to compile libvirt
Add the required DEPENDS for libdevmapper to get the build working as
it did prior to this meta-oe change.
NOTE: our previous dependency on lvm2 was not only to get libdevmapper
functionality, so lvm2 remains a valid DEPENDS, so is left in place.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Historically Yocto installs python modules in ${libdir} and not the
no-arch variant. The criu install was following every other distros
use of the non-arch variant, /usr/lib, which was being picked up by
the QA check. Modify the criu Makefile to enable us to overwrite this
location by using setup.py's install-lib directive.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
To provide hexdump which is used as part of the build process. Resolves
| criu/pie/../../scripts/gen-offsets.sh: line 37: hexdump: command not found
| criu/pie/Makefile:96: recipe for target 'criu/pie/parasite-blob.h' failed
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
I am not sure how the uprev to v2.5 was completed without seeing this
patch failure but regardless the file being patched was moved to the
'criu' directory as part of the v2.5 release. Update the path found in
the patch and update the context in the patch such that it applies.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The DIRFILES variable was a temporary workaround to resolve a do_rootfs
RPM package conflict between libvirt and polkit.
This happened because of the different permissions and ownership that the
packages placed on ${datadir}/usr/share/polkit-1/rules.d.
The behaviour is now conditional based on how PACKAGECONFIG is set. The
polkit rules will be removed from the package if polkit is not enabled.
If polkit is enabled the permissions and ownership are set to match those
set by the polkit recipe.
This uses the useradd enhancements for RSS. It requires that shadow-native
be included as a DEPENDS to provide the useradd command in the native
sysroot.
Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Continue work to use go infra in oe-core instead of the support for go
previously found in meta-virt. This is a 1:1 drop in replacement and
removes one more go piece from meta-virt in favor of the common
support found in oe-core.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Rather than explicit go-cross DEPENDS, we can inherit go.bbclass and
pick up them automatically.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
This recipe just installs a pair of shell scripts.
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
There have been a couple of fixes and new features upstream, let's bring
them in. The upstream URL has also changed slightly.
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
This version of OVS was released on Feb. 21. Bringing our recipe up to
date with the latest release ensure we have all the latest CVE fixes
as well as any new functionality that folks might be looking
for. Additionally we are better situated to support up to date
releases of DPDK (v16.11 in this case). No surprises with the uprev,
it passes all usecase tests (meta-overc) and ptest results are much
the same as the results we had in v2.6.1. While completing the uprev I
took the opportunity to do some cleanup of patches that were no longer
used or required.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Lua support is automatically enabled when configuring LXC if lua is
available in the sysroot. The packaging step will fail since the lua
related files are not in FILES.
This patch explicitly enables/disables lua support using PACKAGECONFIG,
and also adds lua-related files to FILES.
Signed-off-by: Jonatan Pålsson <jonatan.palsson@pelagicore.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The docker recipe has some outdated go hacks. While this doesn't remove
them all, it does use more of the oe-core go infrastructure .. and that
results in more consistent builds.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
glibc-utils is only provided by glibc therefore
add it with glibc overrides.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The switch to RPM4 and dnf results in this error during rootfs construction:
Error: Transaction check error:
file /usr/share/polkit-1/rules.d conflicts between attempted installs of libvirt-1.3.5-r0.13.core2_64 and polkit-0.113-r0.9.core2_64
We can temporarily work around it by instructing RPM to not package/process
the dirfiles.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Rather than expliciting depending on go-cross-${TARGET_ARCH}, we
can now simply inherit the oe-core go bbclass. This gets us the
correct go dependencies and other variables properly set.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
We can now use the oe-core go bbclass to get our DEPENDS correct
for building these go packages.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The patch fix the following QA warning:
--
WARNING: QA Issue: libvirt rdepends on libacl, but it isn't a build dependency? [build-deps]
Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
I was getting the following error when building the latest master:
../git/build-aux/calculate-schema-cksum: cksum: not found
../git/build-aux/calculate-schema-cksum: cksum: not found
Adding coreutils-native which supplies 'cksum' resolved this.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Follow the bouncing docker-registry package. Rather than use the docker hub
registry container, we can have finer grained control if we clone and build
the docker-distribution repository directly.
Since this is distinct from the main docker package/codebase, we break the
registry back out into its own package.
We also create a baseline configuration and .service file that can be the
basis for more complex implementations.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The docker v1 registry has long been depreciated and moved into the
docker distribution library.
The registry is run via the docker CLI and not through a standalone
server.
This change removes the old registry and adds a .service file + package
for docker registry in the main docker recipe. Anyone that wants to
run a local registry can install the docker-registry package and the
service will start.
Note: No full config.yml file is provided, since the default are sane.
If tweaks are required, we can use ENV vars or consider adding a
config overlay.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Most (all) distros package docker-proxy along with the docker CLI
and daemon .. largely due to the fact that it is required to run
the docker registry.
docker-proxy is part of the libnetwork repository, so we add it to
the docker recipe as a separate git repo and integrate it into the
build and packaging process.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Since there are two implementations of runc and containerd that may
not always be in sync, the docker variant, and the opencontainers
variable, we create a virtual/* namespace for these components.
Anything requiring runc or containerd should set a preferred provider
to get the desired/tested variant.
We set the default provider to the docker variants, since they are
the primary use case for these components.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Oru existing docker.service file is using an out of date command. We
can use the contrib .service file instead .. and hopefully it will
stay up to date.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
At the moment we only use runc in conjunction with docker. In order to
allow docker to function correctly we need to use the version
specified in docker's vendor.conf file. Uprev runc to this version.
NOTE that the docker folks have actually forked runc and I have used
this fork as the SRC_URI. I could have chosen instead to use the old
SRC_URI along with the fork point commit as the SRCREV, and then
applied the 2 commits the docker team have added beyond the fork. I
opted instead to use the fork such that 'docker info' would not
complain about a version mismatch. This also makes it easier to google
for issues since the commit ID matches.
NOTE when we eventually have more users of runc we will have to
determine a strategy to either have them all use the same version or
allow for multiple versions of runc on the system. This is also true
for containerd.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Docker defines required dependency versions in its vendor.conf
file. These can also be validated by running 'docker info' on the
running system. In order to avoid issues, such as the current one
where docker can't run containers, we need to ensure we match these
versions. Uprev containerd to the version defined in docker's
vendor.conf file.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Go only understands "386" as target arch, not "i586". Adjust this.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
