meta-refkit-extra testing #135
Conversation
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| # GNU General Public License for more details. | ||
| # | ||
| # You should have received a copy of the GNU General Public License along |
There was a problem hiding this comment.
It might be more consistent to use MIT license, because the layer is overall MIT-licensed. I see that other scripts have been licensed under GPLv2 though.
| def setUpLocal(self): | ||
| """ | ||
| This code is executed before each test method. | ||
| It verifies that meta-refkit-extra is not active. |
There was a problem hiding this comment.
You could maybe just skip adding the layer if it is already present?
|
|
||
| def test_yocto_compat(self): | ||
| """ | ||
| Checks for 'Yocto Compatible 2.0' using the yocto-compat-layer.py tool. |
There was a problem hiding this comment.
You could open this up in the comment a bit. What is "Yocto Compatible 2.0" and where is it defined? What does it mean if the script succeeds?
| """ | ||
| self.enable_refkit_extra() | ||
| image = 'refkit-image-common' | ||
| packages = 'caffe-imagenet-model python3-pyrealsense opencv' |
There was a problem hiding this comment.
OpenCV is not coming from this layer. Caffe should bring it in as a dependency.
| Build an image with the extra packages mentioned in meta-refkit-extra/doc/computervision.rst. | ||
| """ | ||
| self.enable_refkit_extra() | ||
| image = 'refkit-image-common' |
There was a problem hiding this comment.
Why not use refkit-image-computervision as the baseline?
|
On Wed, 2017-05-03 at 00:41 -0700, Ismo Puustinen wrote:
It might be more consistent to use MIT license, because the layer is
overall MIT-licensed. I see that other scripts have been licensed
under GPLv2 though.
That's exactly the reason. By making it GPLv2, it becomes possible to
copy code from other test scripts which are under GPLv2.
|
|
On Wed, 2017-05-03 at 00:42 -0700, Ismo Puustinen wrote:
You could maybe just skip adding the layer if it is already present?
No, yocto-compat-layer.py depends on the layer not being present
already.
|
|
On Wed, 2017-05-03 at 00:45 -0700, Ismo Puustinen wrote:
You could open this up in the comment a bit. What is "Yocto Compatible
2.0" and where is it defined?
It's the next revision of the Yocto compliance program. What exactly it
means is under discussion and hasn't been written down. Therefore I had
to leave it open here, too.
What does it mean if the script succeeds?
That it hasn't found problems. How much that means in practice depends
on how the script evolves.
|
|
On Wed, 2017-05-03 at 00:46 -0700, Ismo Puustinen wrote:
OpenCV is not coming from this layer. Caffe should bring it in as a
dependency.
So I should remove it here?
I was following the computervision.rst, which explicitly calls out the
need to install opencv:
You need to have packages ``python3-pyrealsense`` and ``opencv``
installed
Should opencv be removed there, too?
|
|
@pohly : that example doesn't have Caffe, so OpenCV needs to be installed manually. It doesn't hurt to have it in your |
|
On Wed, 2017-05-03 at 00:50 -0700, Ismo Puustinen wrote:
Why not use refkit-image-computervision as the baseline?
Because computervision.rst didn't say that the demo only works when
using refkit-image-computervision as base, and I wanted this test to be
as fast as possible, i.e. use a smaller image.
|
|
@pohly : it should work with refkit-image-common too. I was sort of expecting computer vision components to be run on refkit-image-computervision, but that was maybe a false assumption. |
|
Ok .This PR looks good to me. |
|
@pohly this has conflicts after my secureboot selftests were added. can you resolve that? I'd like to see re-testing with this to see how much time is spent in post-selftests after this. |
|
On Tue, 2017-05-09 at 01:49 -0700, Mikko Ylinen wrote:
@pohly this has conflicts after my secureboot selftests were added.
can you resolve that? I'd like to see re-testing with this to see how
much time is spent in post-selftests after this.
|
|
On Thu, May 11, 2017 at 5:42 PM, Patrick Ohly wrote:
On Tue, 2017-05-09 at 01:49 -0700, Mikko Ylinen wrote:
> @pohly this has conflicts after my secureboot selftests were added.
> can you resolve that? I'd like to see re-testing with this to see how
> much time is spent in post-selftests after this.
The layer tests in PR #147 are now doing something related.
Do you want to merge this PR here before the 2.3 release, or can it wait
until we know what we want to do with PR #147?
It can/should wait post release. I was mostly curious getting the build
running
to see the post-build stats but now that I think of it again, it's not
important right now.
|
|
Can one of the admins verify this patch? |
The new "bbappends" hierarchy can be used to provide .bbappends for recipes in layers which may or may not be present. This relies on the BBFILES_DYNAMIC support in bitbake master. The complete hierarchy for all layers that are currently used by the refkit distro is set up in advance with empty directories where .bbappends need to go, to make it easier for developers to add .bbappends correctly. .bbappends outside of the "bbappends" hierarchy are ignored. While technically not required because OE-core is a hard dependency, also hosting the .bbappends that modified OE-core under the new "bbappends" hierarchy makes more sense (all modifications to other layers in one place). Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Several config changes were in refkit-config.inc merely because we couldn't use .bbappends for layers other than OE-core. Now we can make the changes in optional .bbappends. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
We had to use "inherit" to include optional changes. Now "require" is also supported without parameter, so we can use that instead of abusing the class inheritance mechanism. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Cooperation of ConnMan and systemd is getting enhanced in OE-core "systemd: enable resolved and networkd" by introducing additional symlinks. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Several components are known to have problems (for example, upm = eclipse-upm/upm#573 and nodejs) with gcc7. We have to continue using gcc 6.x until those problems have been sorted out. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
We cannot guarantee that all layers actually work with OE-core master and its Poky distro. For example, when OE-core switched to gcc7, nodejs and upm failed to build. Therefore we now limit testing in that build configuration to OE-core and meta-refkit-core, without any of the additional layers. As an additional benefit, the test now ensures that meta-refkit-core is actually usable for image building and booting when just using OE-core. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
gcc7 correctly errors out because the if check does not make sense (using enums in boolean context). An upm version update might also make sense; for now the goal is to get the code ready for OE-core master with gcc7 with minimal changes. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
The new OE-core master has its own distrooverrides.bbclass with a slightly different API (different variable for listing overrides, all overrides have a df- for "distro feature" prefix). * openembedded-core b51383e...1d9a88f (28): > ovmf: fix secureboot PACKAGECONFIG + OpenSSL update > package_ipk: Clean up Source entry in ipk packages > mtools-native: fix Upstream-Status > package_manager: flush installed_pkgs file before oe-pkgdata-util uses it > distrooverrides.bbclass: DISTRO_FEATURES as overrides > Revert "bitbake.conf: DISTRO_FEATURES as overrides" > python-3.5: Move bz2.py, lzma.py and _compression.py from python3-misc to python3-compression > attr: Fix build failure when image includes man-pages pkg > externalsrc: verify that EXTERNALSRC/EXTERNALSRC_BUILD are absolute paths > adwaita-icon-theme: add a patch to speed up the do_install() task > runqemu: change terminal settings for valid tty's > grub: switch from ftp to https > libid3tag: switch from ftp to http > libglu: switch from ftp to https > mesa: switch from ftp to https > mesa-demos: switch from ftp to https > dhcp: switch from ftp to http > libpcre: switch from ftp to https > image.bbclass: fix setting of vardeps flag > image.bbclass: improve setup of flags > image.bbclass: cleanup: add new variable "task" > staging.bbclass: fix typo > connman: correct the systemd boot in read only rootfs > systemd: enable resolved and networkd > selftest/sstatetests: Fix potential failure on uniprocessor machines > gcc_7.1.bb: disable thumb on armv5t > gcc: Add recipes for gcc-7 > ovmf: Update to latest Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
The helper function makes the intention of the code more explicit. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
The docstring is only special when it appears directly at the start of the method body. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
It is useful to run signature checks separately from the slower image build tests. "bitbake -r refkit_poky" still runs both, as before, but now refkit_poky.TestRefkitPokySignatures and refkit_poky.TestRefkitPokyBuilds can be used to run those subsets of the tests. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Our CI system does not enable the layer by default to avoid tainting "normal" builds. However, we need to ensure that the extra content at least continues to build. This can be done in a meta-refkit selftest which adds the extra layer as needed and removes it again. This is sub-optimal because it adds a long-running test with no output while the test runs; extending the CI setup so that it covers different build configurations would be better. But for now the selftest is better than nothing. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Only active layers were tested so far. We explicitly have look for inactive ones (like meta-refkit-extra) and also add a compat test for them. This currently fails, because meta-refkit-extra unconditionally changes glog: meta-refkit-extra/recipes-convnet/glog/glog_%.bbappend:DEPENDS += "gflags" TODO: do we want the layer to be Yocto Compatible 2.0? Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
pohly
force-pushed
the
meta-refkit-extra-testing
branch
from
c728c2f to
0cc5141
Compare
|
Rebased on top of PR #184. The yocto-compat-layer.py test is now in refkit_poky.py. However, since also software layers are checked for signature changes now, meta-refkit-extra does not pass anymore (due to glog_%.bbappend:DEPENDS += "gflags"). Is that perhaps a change that we want in meta-refkit-core under a df-refkit-config condition? It would also avoid some recompilation when switching between building without and with the layer. I've not finished the actual build test locally. Let's see whether it works in the CI... |
|
It's sort of ironic that one of the key reasons we put the extra packages to |
|
On Mon, 2017-06-19 at 01:03 -0700, Ismo Puustinen wrote:
It's sort of ironic that one of the key reasons we put the extra
packages to meta-refkit-extra layer (instead of just having a
recipes-extra or similar) was the ability to alter distro and build
configuration. :-)
That option still exists. The question just is whether it's done "the
old way" (= including the layer in bblayers.conf changes the build) or
"the Yocto Compatible 2.0 way" (= via distro features and/or .inc
files).
Should we instead define a new distro feature
(df-refkit-extra-config?) in the extras layer and then make the
configuration depend on that? The idea was AFAIK allow recompiling
stuff when the extras layer is added.
I don't think we had considered "Yocto Compatible 2.0" at the time when
we made that decision. To be honest, I don't remember much discussion
around that particular point at all. IMHO it was more about "when using
an extra layer, we can guarantee that the main layer does not
accidentally depend on extra".
I think it is at least worth reconsidering the question now.
That general question aside, regarding glog:
* is that something that also would make sense in meta-refkit-core?
* is it really reliable to change the content via DEPENDS? That glog
compiles differently looks like a bug in the recipe to me, it should
have an explicit PACKAGECONFIG for this where using gflags is disabled
even if it happens to be found.
|
|
Using Glog is coming from meta-openembedded. I don't really know why it's configured there the way it is configured. It probably isn't used by anything else than caffe? The real question is if we want to move configuration of packages used by |
|
This PR could also be rebased on master. |
|
On Tue, 2017-06-20 at 01:26 -0700, Ismo Puustinen wrote:
Using PACKAGECONFIG would of course be clearer. Many software
components change their build depending of what optional packages they
can auto-detect during configure. Before RSS this was a clear bug,
nowadays it's bit murkier because we can control the available
packages.
I think it is still a bug. The situation is less likely to trigger, but
unexpected, implicit compile changes can still just as before (for
example, when a dependency changes its own dependencies).
Glog is coming from meta-openembedded. I don't really know why it's
configured there the way it is configured. It probably isn't used by
anything else than caffe? The real question is if we want to move
configuration of packages used by meta-refkit-extra to
meta-refkit-core, which creates a soft dependency (the build
configuration is different because meta-refkit-extra might be
included).
I don't understand the "soft dependency" part. What I had in mind was to
have a glog_%.bbappend in meta-refkit-core which for "refkit-config"
changes the compilation in glob. Then we don't need to recompile glob
and everything that depends on it when adding meta-refkit-extra.
The reason for having that change is caffe in meta-refkit-extra, but
that's not different from building the core in a way that it is usable
by additional, external layers out-of-the-box. We can do that unless
there are reasons (performance, security, etc.) which make such a change
undesirable for other cases.
|
|
That's what I meant with "soft dependency". We are carrying a configuration change in |
We can use oe-selftest to cover some aspects of meta-refkit-extra.