Date   

Update 2017week10: kernel maintenance / kernel testing

Agustin Benito Bethencourt <agustin.benito@...>
 

Dear CIP friends,

as you know we released the beta version of Board at desk - Single dev on Feb 22nd a little before the CIP at ELC. It was announced through this mailing list.

That day we also communicated the first draft of the kernel maintenance policies Ben H. published on our wiki[1]. The policies are an extension from the current Linux kernel ones, having our use case in mind.

Check Yoshi's slides[2] from ELC

Christos Karamitsos has been of a great help in order to solve some technical issues during the past few weeks, working full time to help Don Brown to solve them. Thanks Christos. Robert Marshall is back in the team to focus the coming weeks in preparing the 1.0 release, substituting Christos. Welcome back again Robert.

Ben H. will be helping us in shaping the VM for his needs as kernel maintainer the coming days. He is coming to our HQ in Manchester, UK for this purpose.

Based on the feedback received after the beta release, we have added some features requests in our ticket system[3]. I will be processing them this week.

After FOSDEM, OS Leadership Summit and ELC, including the beta release, we will go back this Friday to our bi-weekly report about the technical activities related with kernel maintenance and testing.

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences
[3] https://gitlab.com/cip-project/testing/issues

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


CIP kernel in Gitlab.com

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

the past few weeks, maybe related with the problems gitlab.com has experienced, the automatic update of our kernel in gitlab.com has given us problems to the extend that we took two actions:
* Disable the automatic updates
* Use directly the kernel.org repo in Board at desk - single dev

Since the week before I was at ELC and last week on vacation, the CIP kernel is not up to date compared to the kernel.org one. I am currently updating it.

I am monitoring gitlab.com service. I hope I can restore the automatic updates soon. Meanwhile, I will update it manually at least on weekly basis.

Best Regards


--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Rectification: Open Source Leadership Summit slides

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

during the CIP talk that Nori and I did at the Open Source Leadership Summit on week 07, I made the following mistake:

Daniel Sangorrin, from Toshiba, has been working the last few weeks on Fuego. I assigned to him the integration of LAVA and Fuego. The truth is that this particular feature has been developed by Jan-Simon Möller, from the Linux Foundation, within AGL.

I also stated that the effort is ongoing when, in fact, Jan-Simon already completed it.

This mistake is specially inexplicable given that I am part of the AGL CIAT group and I am closely following the progress of Fuego.

Apologies to both of you for my wrong attribution. I will change the slides accordingly.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Board at desk - Single dev. beta release: KernelCI + LAVAv2 on your machine to test kernels

Agustin Benito Bethencourt <agustin.benito@...>
 

Dear CIP friends,

The Civil Infrastructure Platform project[1], a Linux Foundation Initiative, is happy to announce the publication of a customised and easy to deploy instance of the KernelCI + LAVAv2 projects as a vagrant VM image/recipe, containing the tools and configurations used and developed by the kernelci project, the biggest collaborative testing effort.

This VM is configured so any developer can deploy it in her machine and test a specific kernel on a board physically connected to it.

Please visit the Download page[2] if you are interested in using kernelci on your own machine. To learn more about the current release please visit the feature page[3].

Goal of this effort

kernelci.org[4] is designed as a "open collaborative service", mostly used by the Linux Kernel community. At CIP, we believe this effort we now publish under beta state will help:

a.- To create a first step towards "trusted testing" within CIP for every member and the CIP kernel maintainer.

b.- To extend and simplify the current use case satisfied by kernelci.org, focusing on those embedded developers that have direct access to boards, by reducing the deployment, configuration and maintenance costs.

c.- To severely increase the number of developers and organizations willing to participate in kernelci.org by providing a simple mechanism to evaluate the technologies involved and to test Linux kernels.

The final release date will depend on the feedback received. Check the roadmap[5] for further details. CIP is a community project so we welcome contributions[6] to this effort.

Download kernelci Board @desk - Single dev[2]

[1] https://www.cip-project.org/
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdesksingledevfeaturepage
[4] https://kernelci.org/
[5] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting#testing-at-cipactions
[6] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#participate-in-cip

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: (Feb 21, 4pm) LTSI Workshop @ ELC Portland

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 20/02/17 13:16, Noriaki Fukuyasu wrote:
Hi

Please let me forward below.
I will attend to the LTSI workshop.


Regards

Nori


---------- Forwarded message ---------
From: Noriaki Fukuyasu <fukuyasu@...
<mailto:fukuyasu@...>>
Date: 2017年1月25日(水) 5:29
Subject: (Feb 21, 4pm) LTSI Workshop @ ELC Portland
To: ltsi-dev@...
<mailto:ltsi-dev@...>
<ltsi-dev@...
<mailto:ltsi-dev@...>>


Hi LTSI developers!


We are going to have another LTSI Workshop next month at ELC Portland.

If you are attending ELC, please come join!

(If you are interested in joining the workshop, please send me a note. )


Date: Feb 21st, 2017

Time: 4pm to 6pm

Venue: Director's Suite on the 3rd floor.


Agenda:

* Brief Status Update & LTSI Development Schedule
* Exchange thoughts “Upstream First” (*1). There will be 2-3 guest
speakers to talk about their experiences and thoughts on "Upstream
First" to kick the discussions.


NOTE (*1): This year, LTSI would like to spend sometime on gathering
the information of how companies are taking advantage of upstream
development. Particularly, we are interested in the following questions:

* What is the business value
* What are the challenges
* What makes it successful (from the real company experiences) etc

We are planning to write up a white paper on this subject later this
year based on the information we gather from the workshop.


See you there!!


regards


Noriaki Fukuyasu



--
Noriaki Fukuyasu

The Linux Foundation
Mail: fukuyasu@... <mailto:fukuyasu@...>
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:
http://www.linuxfoundation.jp
http://events.linuxfoundation.jp
http://jp.linux.com

--
Noriaki Fukuyasu

The Linux Foundation
Mail: fukuyasu@... <mailto:fukuyasu@...>
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:
http://www.linuxfoundation.jp
http://events.linuxfoundation.jp
http://jp.linux.com



_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


(Feb 21, 4pm) LTSI Workshop @ ELC Portland

Noriaki Fukuyasu <fukuyasu@...>
 

Hi

Please let me forward below.

Regards 

Nori


---------- Forwarded message ---------
From: Noriaki Fukuyasu <fukuyasu@...>
Date: 2017年1月25日(水) 5:29
Subject: (Feb 21, 4pm) LTSI Workshop @ ELC Portland
To: ltsi-dev@... <ltsi-dev@...>


Hi LTSI developers!


We are going to have another LTSI Workshop next month at ELC Portland.

If you are attending ELC, please come join!

(If you are interested in joining the workshop, please send me a note. )


Date: Feb 21st, 2017

Time: 4pm to 6pm

Venue: Director's Suite on the 3rd floor.


Agenda:

  • Brief Status Update & LTSI Development Schedule
  • Exchange thoughts “Upstream First” (*1). There will be 2-3 guest speakers to talk about their experiences and thoughts on "Upstream First" to kick the discussions.


NOTE (*1):  This year, LTSI would like to spend sometime on gathering the information of how companies are taking advantage of upstream development. Particularly, we are interested in the following questions:

  • What is the business value
  • What are the challenges
  • What makes it successful (from the real company experiences) etc

We are planning to write up a white paper on this subject later this year based on the information we gather from the workshop.


See you there!!


regards


Noriaki Fukuyasu



--
Noriaki Fukuyasu

The Linux Foundation
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:

--
Noriaki Fukuyasu

The Linux Foundation
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:


CIP kernel maintenance policies

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi Ben,

can you provide us a status of the CIP kernel maintenance policies. I see you have been working on them

Link: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

The idea is present them during Yoshi talk on Wed Feb 22nd, right?

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


Re: CIP talk at OS Leadership Summit

Noriaki Fukuyasu <fukuyasu@...>
 

Thanks, Agustin!!

regards

Nori

On Fri, Feb 17, 2017 at 7:47 AM, Agustin Benito Bethencourt <agustin.benito@...> wrote:
Hi,

please find the slides and info about the talk provided by Nori and myself at OS Leadership Summit in our wiki:

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences

Thanks Nori for sharing the talk with me.

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev



--
Noriaki Fukuyasu

The Linux Foundation
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:


CIP talk at OS Leadership Summit

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

please find the slides and info about the talk provided by Nori and myself at OS Leadership Summit in our wiki:

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences

Thanks Nori for sharing the talk with me.

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...


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@...
Mobile: +1 317-560-0513


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.


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@...> wrote:
@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.
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


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@...
Mobile: +1 317-560-0513


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@...


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 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 agree. There needs to be some strict rules for applying patches.

I would prefer to work with the KernelCI upstream to incorporate our
modifications into their code for the long-term.
Okay, understood. What about introducing a default configuration that
clones for upstream but it could be overwritten as config option?

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.


Sincerely,

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
        cip-dev@...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.cip-project.org/mailman/listinfo/cip-dev
or, via email, send a message with subject or body 'help' to
        cip-dev-request@...project.org

You can reach the person managing the list at
        cip-dev-owner@...project.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cip-dev digest..."


Today's Topics:

   1. Re: [PATCH] Use local copy of kernel-ci if present (Daniel Wagner)


----------------------------------------------------------------------

Message: 1
Date: Mon, 23 Jan 2017 10:50:28 +0100
From: Daniel Wagner <daniel.wagner@...>
To: cip-dev@..., Don Brown <don.f.brown@...>
Subject: Re: [cip-dev] [PATCH] Use local copy of kernel-ci if present
Message-ID: <4566da15-839f-e88f-f812-095d7ee770ba@...>
Content-Type: text/plain; charset=windows-1252

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


------------------------------

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


End of cip-dev Digest, Vol 8, Issue 11
**************************************


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


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@...


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:
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.
I'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.'
Good point. I lost myself in the depth of cloudy thoughts.


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 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.
I'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.'

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@...>
---
Hi,

This helped me to quite a bit to get things tested in a more simpler
way. What do you think?
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

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@...>
# 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

10001 - 10020 of 10169