|
kernelci setup fails
Daniel Wagner <wagi@...>
Hi,
running 'vagrant up' from a clean setup consistently fails with this: ==> default: TASK [setup] ******************************************************************* ==> default: ok: [kernel-ci-backend] ==> default: ==> default: TASK [common : Tweak kernel configuration for performance] ********************* ==> default: changed: [kernel-ci-backend] ==> default: ==> default: TASK [install-deps : Install OS dependencies] ********************************** ==> default: failed: [kernel-ci-backend] (item=[u'build-essential', u'git', u'lsb-release', u'python-apt', u'python-pip', u'python-pycurl', u'python-virtualenv', u'python2.7-dev', u'sysfsutils', u'python3', u'python3-yaml', u'python3-setproctitle', u'python3-zmq']) => {"failed": true, "item": ["build-essential", "git", "lsb-release", "python-apt", "python-pip", "python-pycurl", "python-virtualenv", "python2.7-dev", "sysfsutils", "python3", "python3-yaml", "python3-setproctitle", "python3-zmq"], "msg": "No package matching 'python3-setproctitle' is available"} A quick search for setproctitle tells me it is installed via kernelci-backend-config/roles/install-deps/tasks/main.yml: - python3-setproctitle But ubuntu doesn't seem to know this package: vagrant@vagrant-ubuntu-trusty-64:~$ apt-cache search setproctitle libbsd-dev - utility functions from BSD systems - development files python-setproctitle - A setproctitle implementation for Python python-setproctitle-dbg - A setproctitle implementation for Python I haven't spend time to figure out what this package is doing or how it used. So my quick question how to fix this? cheers, daniel
|
|
|
|
Re: kernelci setup fails
Agustin Benito Bethencourt <agustin.benito@...>
Hi Daniel
On 17/01/17 09:49, Daniel Wagner wrote: Hi,maybe this helps? https://gitlab.com/cip-project/testing/issues/12 If this is your case, Don is on it. He talked to one of the kernelci developers, Milo Casagrande about it. -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|
|
Re: kernelci setup fails
Daniel Wagner <daniel.wagner@...>
Hi Agustin,
On 01/17/2017 03:05 PM, Agustin Benito Bethencourt wrote: maybe this helps?Indeed the second bug report in the ticket is the problem I see too. http://packages.ubuntu.com/search?keywords=python3-setproctitle xenial (16.04LTS) (python): A setproctitle implementation for Python (Python 3) [universe] 1.1.8-1build2: amd64 arm64 armhf i386 powerpc ppc64el s390x yakkety (16.10) (python): A setproctitle implementation for Python (Python 3) 1.1.8-1ubuntu2: amd64 arm64 armhf i386 powerpc ppc64el s390x zesty (python): Setproctitle implementation for Python 3 1.1.10-1: amd64 arm64 armhf i386 powerpc ppc64el s390x So this package is just not part of the trusty version. Is there a specific reason to stick to trusty? Thanks, Daniel
|
|
|
|
Re: kernelci setup fails
Don Brown <don.f.brown@...>
Hi Daniel, I have the same problem and worked on it yesterday from several angles. My notes are logged in Issue #12 in the GitLab repo. The link is: Don Brown. PMP don.f.brown@... Mobile: (317) 560-0513 Here's to Life, Linux and the Pursuit of Happiness
On Tue, Jan 17, 2017 at 7:00 AM, <cip-dev-request@...> wrote: Send cip-dev mailing list submissions to
|
|
|
|
Re: kernelci setup fails
Daniel Wagner <daniel.wagner@...>
Hi Don,
On 01/17/2017 05:04 PM, Don Brown wrote: I have the same problem and worked on it yesterday from several angles.I'll create a gitlab account soon, so that I can collaborate via the ticket system. Thanks. Daniel
|
|
|
|
Re: kernelci setup fails
Daniel Wagner <daniel.wagner@...>
On 01/17/2017 03:43 PM, Daniel Wagner wrote:
http://packages.ubuntu.com/search?keywords=python3-setproctitleI gave it a try, no luck though: ==> default: TASK [install-deps : Install MongoDB] ****************************************** ==> default: failed: [kernel-ci-backend] (item=[u'mongodb-org', u'libsnappy1']) => {"failed": true, "item": ["mongodb-org", "libsnappy1"], "msg": "No package matching 'libsnappy1' is available"} So I am stuck at the same level as Don is. Anyway, I was wondering how to be able to have local copies of the kernelci code and use that one as source instead of the hard coded git urls. It seems rather hard to work on the setup if you can't change it :) What about having an option which mounts the local kernelci repos into the virtual machine? Obviously, the kernelci ansible script would also need to be modified to allow overwrites. Thanks, Daniel
|
|
|
|
Re: kernelci setup fails
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
On 17/01/17 17:32, Daniel Wagner wrote: Hi Don,until then... We have discussed what to do. There are several options: 1 Make Python 3.5.2 work on trusty. 2 Move on to Ubuntu 16.04 3 Move to an in-between version. 4 Try to move it into Debian so we can go for a single VM for the whole kernelci tolling. Don is describing in the gitlab ticket his early tries of each option to determine which way to go. Although #4 is the desired one, it seems the most difficult one as well, so we decided to focus on the initial three. We want to have the system working first and then we will figure out how we can simplify the deployment. Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|
|
Re: kernelci setup fails
Don Brown <don.f.brown@...>
Hi Everyone, I'm reporting on 2 issues today: 1. Re: kernelci setup fails 2. Re: Kernel-CI Frontend broken links to build.log et al. ----- #1 I have fixed the issue of the Kernel-CI Virtual Machine failing to boot on the 'python3-setproctitle' and various other libraries. You can read about it here: https://gitlab.com/cip-project/testing/issues/12 The TL;DR is that the kernelci_backend was broken between 12-Dec-2016 and the current version. I found that by using the 12-Dec-2016 commit, the backend booted up just fine. So, we are back to where we were at the end of December where we can create builds and view them on the Web Frontend, but the links to the build.log, kernel.config, kernel image and dtbs are still broken ----- #2 I have tracked down the general area where the links to the build.log, kernel.config, kernel image and dtbs are broken. I just need someone who knows the code to help fix it. You can read about it here: https://gitlab.com/cip-project/testing/issues/2 Sorry, there is no TL;DR for this one. Sincerely, Don Brown. PMP don.f.brown@... Mobile: (317) 560-0513 Here's to Life, Linux and the Pursuit of Happiness
On Tue, Jan 17, 2017 at 12:14 PM, <cip-dev-request@...> wrote: Send cip-dev mailing list submissions to
|
|
|
|
[PATCH] Use local copy of kernel-ci if present
Daniel Wagner <daniel.wagner@...>
In order to develop or debug the setup we should allow to a developer
to use local copy of the sources. This is done by cloning all the remote repos to the project main folder. This folder is shared with the VM. The intergration-scripts are testing if those repos are in the shared folder than git clone uses this as source. To simplify the developer setup a simple setup-dev-env.sh script is added. Note the current path should be the top folder of the project. Signed-off-by: Daniel Wagner <daniel.wagner@siemens.com> --- Hi, This helped me to quite a bit to get things tested in a more simpler way. What do you think? cheers, daniel integration-scripts/install_backend.sh | 8 +++++++- integration-scripts/install_build_script.sh | 9 ++++++++- integration-scripts/install_frontend.sh | 8 +++++++- scripts/setup-dev-env.sh | 11 +++++++++++ 4 files changed, 33 insertions(+), 3 deletions(-) create mode 100644 scripts/setup-dev-env.sh diff --git a/integration-scripts/install_backend.sh b/integration-scripts/install_backend.sh index 72a974033a3c..157e7184e349 100755 --- a/integration-scripts/install_backend.sh +++ b/integration-scripts/install_backend.sh @@ -4,7 +4,13 @@ # Install kernelci backend cd $HOME && mkdir git-repos && cd git-repos -git clone https://github.com/kernelci/kernelci-backend-config.git kernelci-backend + +GIT_SRC="https://github.com/kernelci/kernelci-backend-config.git" +if [ -d /vagrant/kernelci-backend-config ]; then + GIT_SRC=/vagrant/kernelci-backend-config +fi +git clone $GIT_SRC kernelci-backend + cp /vagrant/config/secrets-backend.yml kernelci-backend/secrets.yml # Fixme: Don't let ansible try to create the file in the first place. diff --git a/integration-scripts/install_build_script.sh b/integration-scripts/install_build_script.sh index 322619317af6..879aaed01792 100755 --- a/integration-scripts/install_build_script.sh +++ b/integration-scripts/install_build_script.sh @@ -3,7 +3,14 @@ # Copyright (C) 2016, Siemens AG, Wolfgang Mauerer <wolfgang.mauerer@siemens.com> # SPDX-License-Identifier: Apache-2.0 -cd $HOME && git clone https://github.com/kernelci/kernelci-build.git +cd $HOME + +GIT_SRC="https://github.com/kernelci/kernelci-build.git" +if [ -d /vagrant/kernelci-build ]; then + GIT_SRC=/vagrant/kernelci-build +fi +git clone $GIT_SRC + cd kernelci-build MASTER_KEY=`cat $HOME/backend-admin-token.txt` diff --git a/integration-scripts/install_frontend.sh b/integration-scripts/install_frontend.sh index 48ab91ab83ce..251ef89d28f3 100755 --- a/integration-scripts/install_frontend.sh +++ b/integration-scripts/install_frontend.sh @@ -4,7 +4,13 @@ # Install kernelci frontend cd $HOME/git-repos -git clone https://github.com/kernelci/kernelci-frontend-config.git kernelci-frontend + +GIT_SRC="https://github.com/kernelci/kernelci-frontend-config.git" +if [ -d /vagrant/kernelci-frontend-config ]; then + GIT_SRC=/vagrant/kernelci-frontend-config +fi +git clone $GIT_SRC kernelci-frontend + sed -i kernelci-frontend/roles/install-app/tasks/main.yml \ -e 's/kernelci\/kernelci-frontend.git/siemens\/kernelci-frontend.git/' diff --git a/scripts/setup-dev-env.sh b/scripts/setup-dev-env.sh new file mode 100644 index 000000000000..59c13b233065 --- /dev/null +++ b/scripts/setup-dev-env.sh @@ -0,0 +1,11 @@ +#!/bin/sh + +if [ ! -f "Vagrantfile" ]; then + echo "script is supposed to be run from the top folder where" + echo "the Vagrantfile is." + exit 1 +fi + +git clone https://github.com/kernelci/kernelci-backend-config.git +git clone https://github.com/kernelci/kernelci-build.git +git clone https://github.com/kernelci/kernelci-frontend-config.git -- 2.9.3
|
|
|
|
Re: [PATCH] Use local copy of kernel-ci if present
Wolfgang Mauerer <wm@...>
Am 19/01/2017 um 15:57 schrieb Daniel Wagner:
In order to develop or debug the setup we should allow to a developerI've had to read the last sentence for a couple of times before I could make sense of it. Perhaps something along the lines of 'The integration scripts test if the repos are present in the shared folder. They are used as source for "git clone" in this case.' the patch as such seems most helpful to me -- struggling with modifications that do not render any effect because sources are pulled from a differnet source have bitten me quite a few times when working with kernelci. Thanks, Wolfgang
|
|
|
|
Re: [PATCH] Use local copy of kernel-ci if present
Daniel Wagner <daniel.wagner@...>
On 01/19/2017 04:14 PM, Wolfgang Mauerer wrote:
Am 19/01/2017 um 15:57 schrieb Daniel Wagner:Good point. I lost myself in the depth of cloudy thoughts.This is done by cloning all the remote repos to the project mainI've had to read the last sentence for a couple of times before
|
|
|
|
CIP update 08 WK 03
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
this is the report from the activities that Codethink is driving on and or involved. This week is not that we worked more but that we completed more tasks. ++ Meetings * Members meeting on Monday January 16th ** ELC booth/sponsorship logistics as main topic ** Report about testing and kernel maintenance efforts. * Next Members meeting on Monday January 23rd ** Ben Hutchings attending to provide update about the kernel maintenance effort ++ Kernel maintenance * 4.4 CIP kernel updated to the latest LTS. * Backported patches being merged. * Kernel maintenance policies under review. The goal is to arrive to ELC with the policies finished and the backported patches merged. Some additional tasks might be done meanwhile. ++ Testing: Board @desk - Single Developer * KernelCI Virtual Machine Setup & Configuration Howto published[1] ** You can follow other tasks related with the beta release in the ticket #10 * Improvements in the Kernel CI & LAVA v2 configuration. ** LAVA v2 Web Server now sees the devices that are available in the application #4 ** LAVA v2 tests now complete #5 ** QEMU health check are executing and does not get a KVM kernel module related error any more. #8 #9 ** KernelCI VM now boots in Debian Jessie #12 * Beta release initially set for February 4th #10 ** The plan at this point is to release right before ELC. ++ Other topics * Robert Marshall has is no longer part of the team. Christos Karamitsos has substituted him. Chris is also based in Manchester. He will be focused in the issues we have in the kernelci front and back-en related with DDBB. ** Thanks Robert for your effort in pushing the development further. Welcome Christos. Please introduce yourself to the audience (when you recover from that flu). * Ben H. and Don Brown has now edit access to the public wiki. If you have a Linux Foundation ID, please review if you have them too. If not, please let us know through this list. #11 * Agustin (and Yoshi) will attend to FOSDEM. What about you? ++ Coming activities * Investigate DDBB related issues #2 and #3 * Consolidate the KernelCI & LAVA v2 servers into one VM #12 * Add documentation #10 * Preparation of the slides for the Open Source Leadership Summit (Agustin and Nori). #2 https://gitlab.com/cip-project/testing/issues/2 #3 https://gitlab.com/cip-project/testing/issues/3 #4 https://gitlab.com/cip-project/testing/issues/4 #5 https://gitlab.com/cip-project/testing/issues/5 #8 https://gitlab.com/cip-project/testing/issues/8 #9 https://gitlab.com/cip-project/testing/issues/9 #10 https://gitlab.com/cip-project/testing/issues/10 #11 https://gitlab.com/cip-project/testing/issues/11 #12 https://gitlab.com/cip-project/testing/issues/12 [1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/testinglavav2vmsetup Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|
|
Re: [PATCH] Use local copy of kernel-ci if present
Daniel Wagner <daniel.wagner@...>
Hi Don,
Over the weekend I had an idea to improve it even more: GIT_SRC="https://github.com/kernelci/kernelci-backend-config.git" if [ -d /vagrant/kernelci-backend-config ]; then GIT_SRC=/vagrant/kernelci-backend-config fi git clone $GIT_SRC kernelci-backend If there is a repo available on /vagrant we clone from it. I think it would be even better just to copy the working directory instead of cloning. That would allow to hack on the files without committing all the time. So this would change to: if [ -d /vagrant/kernelci-backend-config ]; then cp -r /vagrant/kernelci-backend-config kernelci-backend else git clone https://github.com/kernelci/kernelci-backend-config.git kernelci-backend fi What do you think about this? And another idea I had: we should create a mirror of kernelci sources clone from the mirror. I am pretty sure soon we have some patches which need to be around to get our setup running which aren't available in the upstream repository. For example I had to do this here: --- a/roles/install-deps/tasks/install-mongodb.yml +++ b/roles/install-deps/tasks/install-mongodb.yml @@ -2,7 +2,7 @@ - name: Add MongoDB apt key (Ubuntu) apt_key: id=7F0CEB10 - keyserver=hkp://keyserver.ubuntu.com + keyserver=hkp://keyserver.ubuntu.com:80 when: ansible_lsb.id == "Ubuntu" tags: - install @@ -11,7 +11,7 @@ - name: Add MongoDB apt key (Debian) apt_key: id=EA312927 - keyserver=hkp://keyserver.ubuntu.com + keyserver=hkp://keyserver.ubuntu.com:80 when: ansible_lsb.id == "Debian" tags: - install Thanks, Daniel
|
|
|
|
Re: Update on Patch and mirroring KernelCI code
Don Brown <don.f.brown@...>
Hi Daniel, I like the change to the patch and I'll incorporate it tonight. We are already mirroring the KernelCI Backend and Frontend and I had almost the exact same thought this weekend that we already need to modify the code to get ours working. I don't mind doing this in the short term. However, this can be a slippery slope since we could easily get to the point where we've essentially forked their code. I would prefer to work with the KernelCI upstream to incorporate our modifications into their code for the long-term. Don Brown. PMP don.f.brown@... Mobile: (317) 560-0513 Here's to Life, Linux and the Pursuit of Happiness
On Mon, Jan 23, 2017 at 7:00 AM, <cip-dev-request@...> wrote: Send cip-dev mailing list submissions to
|
|
|
|
Re: Update on Patch and mirroring KernelCI code
Daniel Wagner <daniel.wagner@...>
Hi Don,
On 01/23/2017 01:39 PM, Don Brown wrote: I like the change to the patch and I'll incorporate it tonight.Great. We are already mirroring the KernelCI Backend and Frontend and I hadI agree. There needs to be some strict rules for applying patches. I would prefer to work with the KernelCI upstream to incorporate ourOkay, understood. What about introducing a default configuration that clones for upstream but it could be overwritten as config option? Thanks, Daniel
|
|
|
|
Y2038. a risk that requires attention today and would benefit from CIP participation
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
during the past CIP Members meeting call, Monday 23rd January, Members agreed on bringing to the attention of CIP contributors and friends the Y2038 topic. What is Y2038 refers to? "Y2038 refers to an issue related to the way time is handled by computers. Time is often represented as the number of seconds since Jan 1, 1970. Whenever a 32-bit signed integer is used for this, the maximum value that can be represented is ± ~68 years, 19 days from the epoch, which corresponds to Jan 19, 2038. What happens after that is system dependent, but generally not good. A computer may act as if its time got reset to Dec 1901, or possibly to the epoch of Jan 1, 1970. It may give unexpected results or crash." Definition extracted from http://www.y2038.com[1]. Check more about the description of the problem in Wikipedia[2]. The Linux Kernel community is already acting on this topic since version 3.17[3] at least. One of the most interesting activities is to define tasks for newbies[4] related with this topic. You can read in this article[5] an update about what is being done, from 2015 and another reference[6] from 2016. CIP Members has expressed their interest for Y2038 on user space too. Arnd Bergmann, in CC, is one of the advocates of the Y2038 initiative. @Arnd, is there any further documentation we should read about this topic? What are the key activities at this point within the Linux Kernel related with the topic? Who can we talk to related with user space? Any light you can provide us would be helpful. [1] https://y2038.com/faq/ [2] https://en.wikipedia.org/wiki/Year_2038_problem [3] https://lwn.net/Articles/607741/ [4] https://kernelnewbies.org/y2038 [5] https://lwn.net/Articles/643234/ [6] https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-More-Y2038-Work Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|
|
Status Update on CIP - Continuous Integration of the CIP kernel using KernelCI and Testing the CIP kernel using LAVA Server v2
Don Brown <don.brown@...>
Civil Infrastructure Platform (CIP)
Continuous Integration of the CIP kernel using KernelCI and Testing the CIP kernel using LAVA Server v2 Hi Everyone, I am writing to give you an update on where we stand with the Civil Infrastructure Platform (CIP). As many of you know, we are using KernelCI for the Continuous Integration component and LAVA v2 for the kernel Testing platform. KernelCI performs the kernel builds against specific configurations and can verify boots and SOC's as well. Both come with complete results reporting to document what went wrong in the build, deployment or testing portion with a great level of granularity. Our Focus: We started working on this with the scenario of a "Single-Developer at their Desk with a Board" needing to build and test a kernel for a specific project. This has sharpened our focus on making it "just work," understanding that the developer does not have time to devote to the setup, configuration and maintenance of a KernelCI and LAVA server and cannot use a public service for whatever reason. However, in this day and age, we realize how desparately needed these tools are for embedded systems providers. Where We Stand: We currently have a KernelCI Virtual Machine running with a few sample test builds to verify that everything is working. We also have a LAVA v2 Server Virtual Machine running with a QEMU device and a Beaglebone-Black device pre-loaded. Both have a YAML health-check job loaded into their respective device types. This setup allows a developer to compile the kernel in multiple configurations to suit the specification of their particular project and to write tests for the appropriate actions in LAVA to thouroughly prove the kernel. The tests can help fulfill and properly document any customer specifications or regulatory requirements built into the specific project. We are approaching a beta release of the CIP Kernel along with the KernelCI & LAVA v2 Virtual Machine in Week 6 of 2017 before the Embedded Linux Conference. For the early adopters, we've provided links to the CIP-Kernel[1], the KernelCI[2] project, and the LAVA v2[3] Project. Tutorials have been created for both the KernelCI[4] and LAVA v2[5] Virtual Machines setup and configuration. On a technical note, we are working on merging the two Virtual Machines together to ease the burden on the "Single Developer at their Desk with a Board" scenario. Links: [1] The CIP Kernel: https://gitlab.com/cip-project/linux-cip [2] The KernelCI Virtual Machine files: https://gitlab.com/cip-project/kernelci-debian [3] The LAVA v2 Virtual Machine files: https://gitlab.com/cip-project/lava2-badsd [4] Tutorial: How to Set up and Configure a KernelCI Virtual Machine: https://wiki.linuxfoundation.org/civilinfrastructureplatform/testingkernelcivmsetup [5] Tutorial: How to Set up and Configure a LAVA v2 Virtual Machine: https://wiki.linuxfoundation.org/civilinfrastructureplatform/testinglavav2vmsetup Thank you! -- Don Brown Codethink, Ltd. Software Engineering Consultant Indianapolis, IN USA Email: don.brown@codethink.co.uk Mobile: +1 317-560-0513
|
|
|
|
Re: Y2038. a risk that requires attention today and would benefit from CIP participation
Arnd Bergmann <arnd@...>
On Tue, Jan 24, 2017 at 5:58 PM, Agustin Benito Bethencourt
<agustin.benito@codethink.co.uk> wrote: @Arnd, is there any further documentation we should read about this topic?Deepa Dinamani has done some important work on the kernel, but had a hard time getting some of the patches accepted at first. With her work, we now have some of the basics of converting over VFS, which I assume is one of the hardest parts. She is also looking into refactoring my system call series now, which is the other hard and absolutely essential part of the kernel work. Besides those there are a couple of areas that are tricky and spread out across the kerne (rtc, key management, probably one more), a couple that require small interface changes (input, v4l) and have to be done carefully, and lots of drivers that need to be individually fixed. Once those are done, 32-bit kernels and 64-bit kernels are equally good at dealing with y2038. I actually have an older prototype series that removes the definition of 'time_t' inside the kernel to ensure that there are no type confusions. Then there are issues that affect both 32-bit and 64-bit systems and that have to be fixed regardless. This mostly affects file systems (e.g. XFS), and many of them won't ever get fixed (e.g. ext3 is broken, but ext4 is a working replacement, same for NFSv2 vs NFSv3/4). The problem also exists in some network protocols and common file formats (e.g. CPIO). Again, these have to be dealt with individually. In user space, Albert Aribaud has an initial glibc patch set [1], which is most of what we require for typical 32-bit applications. glibc will allow building with either 32-bit or 64-bit time_t and support both at runtime (including on old kernels). In order to actually make it work beyond 2038, all user space has to be recompiled against the new glibc. Once that is done, we still have to deal with application specific bugs, where either timestamps are encoded as 32-bit integers on-disk, or the application uses its own types internally instead of time_t. Arnd [1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
|
|
|
|
Linux 4.4.48-cip2
Ben Hutchings <ben.hutchings@...>
I've just released Linux version 4.4.48-cip2. There are no new
CIP-specific changes; this just adds the fixes from stable versions 4.4.43-4.4.48 inclusive. I reviewed those fixes, but have only done very basic manual testing of the result. Ben. -- Ben Hutchings Software Developer, Codethink Ltd.
|
|
|
|
Update on CIP Testing Platform using KernelCI and LAVA
Don Brown <don.brown@...>
Hi Everyone,
I am writing to give you an update on where we stand with the Civil Infrastructure Platform (CIP). As many of you know, we are using KernelCI for the Continuous Integration component and LAVA v2 for the kernel Testing platform. KernelCI performs the kernel builds against specific configurations and can verify boots and SOC's as well. LAVA provides the testing framework & infrastructure. Both come with complete results reporting to document what went wrong in the build, deployment or testing portion with a great level of granularity. Where We Stand: We have successfully merged the KernelCI VM and the LAVA Server VM into a single Virtual Machine.[1] We have KernelCI creating builds of the CIP Kernel [2] and we have LAVA running health-check tests in qemu. We are very close to having the health-check running on the Beaglebone Black, but we've had some trouble getting it communicating properly. We expect to release the platform as a Beta version for the Embedded Linux Conference. The two original tutorials have been merged into one and can be found on the CIP Wiki.[3] Links: [1] CIP Testing Platform (Board-at-Desk-Single-Developer): https://gitlab.com/cip-project/board-at-desk-single-dev [2] The CIP Kernel: https://gitlab.com/cip-project/linux-cip [3] Tutorial: Board-at-Desk-Single-Developer KernelCI & LAVA VM Setup & Configuration: https://wiki.linuxfoundation.org/civilinfrastructureplatform/testinglavav2vmsetup -- Don Brown Codethink, Ltd. Software Engineering Consultant Indianapolis, IN USA Email: don.brown@codethink.co.uk Mobile: +1 317-560-0513
|
|
|