Date   

Re: telnet connection and bbb testing

Robert Marshall <robert.marshall@...>
 

Don Brown <don.f.brown@...> writes:
(reformatted Don's response)

Robert Marshall <robert.marshall@...> wrote:

Don

Our bbb_debian_ramdisk_test2.yaml has a auto_login section defining a
login prompt username and password - was this approach tried and abandoned before
starting to use keeping a telnet session active on the beaglebone-black
tests?
Hi Robert,

Yes. I started with the test tutorial here: https://validation.linaro.org/static/docs/v2/standard-armmp-ramdisk-bbb.html
You will notice that there is no login or password.

When I had problems getting the test to properly log in to the BBB, I copied and modified the script into
'bbb_debian_ramdisk_test2.yaml' to include the username and password. It didn't work at the time, but that was some
time ago when I knew less about LAVA.

For everyone's benefit:
The requirement of needing to log into the Beaglebone-Black (BBB) as root prior to running a test is a small, but very
annoying and persistent problem that Christos and I ran into when we first started to test live on the BBB. If you watch
the log file of the health check as it is being executed, you'll see that the script makes the connection to the BBB, but then
it gets hung up. It needs to send a carriage return to the BBB prior to applying the username and password since that is
what we have to do when we are trying to telnet into the BBB manually.

I'm trying to solve this by writing an 'expect' script that will:
1.) Make the connection to the BBB
2.) Wait for something like "'^]'" to be displayed and then wait a second or two
3.) Send the '\r' to the BBB so it advances to the "login:" prompt
4.) Return control back to the Test Script where it *should* issue the username and password.

If this approach works, I *think* we can call the expect script in place of the 'telnet localhost 8020' - and we can update
the Device Dictionary so LAVA runs the new command too.

I hope that helps!
I'm now using this script - using expect - a wrapper around the telnet
connection_command and getting fairly consistent health check successes
without any manual intervention with the Beaglebone black

Robert


Re: cip-dev Digest, Vol 11, Issue 8

Don Brown <don.f.brown@...>
 

Hi Robert,

You will notice that there is no login or password.

When I had problems getting the test to properly log in to the BBB, I copied and modified the script into 'bbb_debian_ramdisk_test2.yaml' to include the username and password. It didn't work at the time, but that was some time ago when I knew less about LAVA.

For everyone's benefit:
The requirement of needing to log into the Beaglebone-Black (BBB) as root prior to running a test is a small, but very annoying and persistent problem that Christos and I ran into when we first started to test live on the BBB. If you watch the log file of the health check as it is being executed, you'll see that the script makes the connection to the BBB, but then it gets hung up. It needs to send a carriage return to the BBB prior to applying the username and password since that is what we have to do when we are trying to telnet into the BBB manually.

I'm trying to solve this by writing an 'expect' script that will: 
1.) Make the connection to the BBB
2.) Wait for something like "'^]'" to be displayed and then wait a second or two
3.) Send the '\r' to the BBB so it advances to the "login:" prompt
4.) Return control back to the Test Script where it *should* issue the username and password.

If this approach works, I *think* we can call the expect script in place of the 'telnet localhost 8020' - and we can update the Device Dictionary so LAVA runs the new command too.

I hope that helps!





Sincerely,

Don Brown. PMP
don.f.brown@...
Mobile: (317) 560-0513
Here's to Life, Linux and the Pursuit of Happiness

On Wed, Apr 19, 2017 at 8: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. telnet connection and bbb testing (Robert Marshall)
   2. CIP TSC meeting minutes (17 April 2017) (KOBAYASHI Yoshitake)
   3. Re: CIP TSC meeting minutes (17 April 2017)
      (Agustin Benito Bethencourt)
   4. CIP workshop on 30th May at the OSSJ venue
      (Agustin Benito Bethencourt)


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

Message: 1
Date: Tue, 18 Apr 2017 15:00:35 +0100
From: Robert Marshall <robert.marshall@....uk>
To: cip-dev@...
Subject: [cip-dev] telnet connection and bbb testing
Message-ID: <87inm1izng.fsf@ctlt579.codethink.co.uk>
Content-Type: text/plain

Don

Our bbb_debian_ramdisk_test2.yaml has a auto_login section defining a
login prompt username and password - was this approach tried and abandoned before
starting to use keeping a telnet session active on the beaglebone-black
tests?

Robert


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

Message: 2
Date: Tue, 18 Apr 2017 23:42:51 +0900
From: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
To: cip-dev@...
Subject: [cip-dev] CIP TSC meeting minutes (17 April 2017)
Message-ID: <268e138b-7f80-e674-6772-97806b659711@...>
Content-Type: text/plain; charset=utf-8

Hi all,

I have uploaded meeting minutes for yesterday's CIP TSC conference call.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

If you have any comments, please let us know.

Best regards,
Yoshi



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

Message: 3
Date: Tue, 18 Apr 2017 17:06:34 +0100
From: Agustin Benito Bethencourt <agustin.benito@....uk>
To: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Cc: cip-dev@...
Subject: Re: [cip-dev] CIP TSC meeting minutes (17 April 2017)
Message-ID: <58F6398A.2080601@codethink.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

On 18/04/17 15:42, KOBAYASHI Yoshitake wrote:
> Hi all,
>
> I have uploaded meeting minutes for yesterday's CIP TSC conference call.
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017
>
> If you have any comments, please let us know.

Thank you very much for formatting and publishing the minutes. I see
this as a small but relevant improvement towards transparency.

Best Regards

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


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

Message: 4
Date: Tue, 18 Apr 2017 17:13:37 +0100
From: Agustin Benito Bethencourt <agustin.benito@....uk>
To: "cip-dev@..." <cip-dev@...>
Subject: [cip-dev] CIP workshop on 30th May at the OSSJ venue
Message-ID: <58F63B31.8040102@codethink.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

Dear CIP friends,

as you can read in the meeting minutes of yesterday's TSC meeting[1],
the day before the Open Source Summit Japan starts, May 30th, we will
organise some specific sessions related with CIP in the same venue.

We are in the process of defining what we will do from 11:00 to 17:00.
Feel free to:
* Let us know if you are interested in attending.
* Provide input on the topics you would like to work on, discuss or
receive information.

Maybe creating a wiki page to coordinate the activities would be wise,
right?

Best Regards


[1]
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

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


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


CIP workshop on 30th May at the OSSJ venue

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

Dear CIP friends,

as you can read in the meeting minutes of yesterday's TSC meeting[1], the day before the Open Source Summit Japan starts, May 30th, we will organise some specific sessions related with CIP in the same venue.

We are in the process of defining what we will do from 11:00 to 17:00. Feel free to:
* Let us know if you are interested in attending.
* Provide input on the topics you would like to work on, discuss or receive information.

Maybe creating a wiki page to coordinate the activities would be wise, right?

Best Regards


[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

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


Re: CIP TSC meeting minutes (17 April 2017)

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

Hi,

On 18/04/17 15:42, KOBAYASHI Yoshitake wrote:
Hi all,

I have uploaded meeting minutes for yesterday's CIP TSC conference call.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

If you have any comments, please let us know.
Thank you very much for formatting and publishing the minutes. I see this as a small but relevant improvement towards transparency.

Best Regards

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


CIP TSC meeting minutes (17 April 2017)

Yoshitake Kobayashi
 

Hi all,

I have uploaded meeting minutes for yesterday's CIP TSC conference call.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr172017

If you have any comments, please let us know.

Best regards,
Yoshi


telnet connection and bbb testing

Robert Marshall <robert.marshall@...>
 

Don

Our bbb_debian_ramdisk_test2.yaml has a auto_login section defining a
login prompt username and password - was this approach tried and abandoned before
starting to use keeping a telnet session active on the beaglebone-black
tests?

Robert


Re: CIP TSC meeting minutes (3 April 2017)

tuyen.hoangvan@...
 

Dear Takuo Koguchi,

Thank you so much for your guide about building kernel for BBB.

I created a patch file to build minimal OS for BBB by using boot-loader
(u-boot) and

kernel (linux-base) based on meta-debian.

I would like to share you the patch at the attachment.

The patch is created for project-x, master branch.

Best regards,

Tuyen

Hi Yoshi,

Regarding to my project-x action item, recipes-kernel for BBB and CycloneV
is already posted.

If you copy recipes-kernel to your usual poky build (i.e. DISTRO = poky
without meta-debian,)
you will be able to bitbake virtual/kernel.

But it you want to use this recipe with meta-debian, there are some
issues.
1) you have to add meta-PROJECTX/conf/local.conf.sample and
bblayer.conf.sample manually.
This is my fault. I forgot to include these files. You can copy these
files from deby-qemux86-64/meta-PROJECTX/conf

If you do the above, you can bitbake virtual/kernel if the followings are
in conf/local.conf
MACHINE="beaglebone"
LINUX_DEFCONFIG="omap2plus_defconfig"

But this is still not what I meant for.
In the above mentioned build my "linux-cip" recipe is not used even if
PREFERRED_PROVIDER_virtual/kernel = "linux-cip"
is defined in local.conf because PREFERRED_PROVIDER _virtual/kernel is
overwritten
by meta-debian/conf\/distro/include/debian-preferred-provider.inc:2
to "linux-base"

I hope you can change
PREFERRED_PROVIDER_virtual/kernel = "linux-base"
for
PREFERRED_PROVIDER_virtual/kernel ?= "linux-base"

Unfortunately there are still some issue to build kernel with meta-debian.
I am working on it.


Best Regard,

Takuo Koguchi

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of KOBAYASHI
Yoshitake
Sent: Thursday, April 06, 2017 2:07 PM
To: cip-dev@...
Subject: [!][cip-dev] CIP TSC meeting minutes (3 April 2017)

Hi everyone,

I uploaded the meeting minutes for CIP Technical Steering Committee
meeting held 3
April, 2017 at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr03201
7

Past TSC meeting minutes can be find at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings.

Best regards,
Yoshi


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

--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com

--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com


Test mail from TSDV

Tuan Le Minh <tuan.leminh@...>
 

Test

 

Tuan | IS team


Re: Kernel feature support

minmin@plathome.co.jp
 

Dear Ben;

I apologize for the very late submission. Here is the config of our product.

Thanks in advance.

--
Masato Minda <minmin@...>
Plat'Home Co., Ltd.


Re: Kernel feature support

Jan Kiszka
 

On 2017-03-09 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Some more configs from our side. Some are just stripped-down defconfigs,
some are 4.1-based (to become 4.4 eventually), but I hope they are
useful. Any out-of-tree switch is to be ignored, of course.

I hope there will be more configs in the future. E.g., some projects on
4.4 are still running an expanded development feature set.

Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Re: u-boot policy for CIP

Mauerer, Wolfgang
 

Hi Chris,

On 12.04.2017 10:34, Chris Paterson wrote:
Hello all,

I'd like to reach some conclusion on the discussion/policy about
u-boot. We briefly spoke about it in the last TSC, and agreed to
continue the discussion here.

As highlighted by Ben and Wolfgang, a policy should be driven by the
use-case requirements from the member companies. Until more feedback
comes in from the member companies, would it be an idea for me to
draft an outline policy we can use to focus discussions? Sometimes it
is easier to have a starting point to amend, rather than waffle
aimlessly.
that's a good idea, thanks for pushing this forward. Discussions
are usually easier when there's some starting point. I'll try
to get some in-company requirements via our internal channels.

Thanks, Wolfgang

On a side note, I won't be able to attend the next TSC (Easter
holidays), but please continue the discussion without me.


Kind regards, Chris


From: Ben Hutchings [mailto:ben.hutchings@...] Sent: 24
March 2017 17:53

On Thu, 2017-03-16 at 12:07 +0000, Chris Paterson wrote:

I’m bringing a discussion I’ve started in other places here as it
will benefit from wider participation.
Thank you. I have limited knowledge of u-boot, but I did work on
it recently to add support for a new board.

[...]
Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware.
We should certainly pick one version for each reference board.

How we actively maintain that version (bug fixes/security
patches/features?) is another question. Given that most devices
in the field won’t have a way to update u-boot in the field
(security issues/practicalities), I think ‘SLTS’ support for
u-boot may not be required. Perhaps we just tag a version of
u-boot at the launch of a new CIP Kernel and stick with it?
If u-boot is configured to use network boot, or to require
authentication of its environment or boot images, or authentication
to interrupt boot (CONFIG_AUTOBOOT_KEYED=y), then it is sometimes
handling untrusted input and might need security updates.
Otherwise it probably does not.

It seems possible that some fixes might be needed to improve
reliability, e.g. if boot timing changes as hardware gets older.

How do we decide what u-boot version to support? Currently it
looks like the BBB platform are shipped with 2014.04
I have a new BBB that came with 2015.10 installed. So we cannot be
certain that a particular model of board will always be shipped
with the same version!

and the Renesas platform is shipped with 2013.01. That said, it
looks like there is upstream support for BBB [1], but how the
feature set compares to the version shipped with the platform I
don’t know. There is also support for some Renesas platforms [2],
but not for the exact board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support
for their boards upstream? When this is done do we pick the first
version that includes this support to work with? Or do we just
stick with the vendor provided forks?
I don't have an opinion on whether CIP should provide support for
u-boot, beyond the testing it will get through booting each kernel
to be tested. If we do, I would prefer not to include vendor forks
as this could greatly increase the maintenance effort.

Is there a particular feature set that CIP requires?
[...]

For testing purposes we will need at least an unauthenticated
command prompt (CONFIG_AUTOBOOT_KEYED=n), networking and TFTP
support. That probably isn't a complete list.

Ben.

-- Ben Hutchings Software Developer, Codethink Ltd.
_______________________________________________ cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: u-boot policy for CIP

Chris Paterson
 

Hello all,

I'd like to reach some conclusion on the discussion/policy about u-boot. We briefly spoke about it in the last TSC, and agreed to continue the discussion here.

As highlighted by Ben and Wolfgang, a policy should be driven by the use-case requirements from the member companies. Until more feedback comes in from the member companies, would it be an idea for me to draft an outline policy we can use to focus discussions? Sometimes it is easier to have a starting point to amend, rather than waffle aimlessly.

On a side note, I won't be able to attend the next TSC (Easter holidays), but please continue the discussion without me.


Kind regards, Chris

From: Ben Hutchings [mailto:ben.hutchings@...]
Sent: 24 March 2017 17:53

On Thu, 2017-03-16 at 12:07 +0000, Chris Paterson wrote:

I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.
Thank you. I have limited knowledge of u-boot, but I did work on it recently
to add support for a new board.

[...]
Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware.
We should certainly pick one version for each reference board.

How we actively maintain that version (bug fixes/security
patches/features?) is another question. Given that most devices in the
field won’t have a way to update u-boot in the field (security
issues/practicalities), I think ‘SLTS’ support for u-boot may not be
required. Perhaps we just tag a version of u-boot at the launch of a
new CIP Kernel and stick with it?
If u-boot is configured to use network boot, or to require authentication of
its environment or boot images, or authentication to interrupt boot
(CONFIG_AUTOBOOT_KEYED=y), then it is sometimes handling untrusted
input and might need security updates. Otherwise it probably does not.

It seems possible that some fixes might be needed to improve reliability, e.g.
if boot timing changes as hardware gets older.

How do we decide what u-boot version to support? Currently it looks
like the BBB platform are shipped with 2014.04
I have a new BBB that came with 2015.10 installed. So we cannot be certain
that a particular model of board will always be shipped with the same
version!

and the Renesas platform is shipped with 2013.01. That said, it looks
like there is upstream support for BBB [1], but how the feature set
compares to the version shipped with the platform I don’t know. There
is also support for some Renesas platforms [2], but not for the exact
board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support for
their boards upstream? When this is done do we pick the first version
that includes this support to work with? Or do we just stick with the
vendor provided forks?
I don't have an opinion on whether CIP should provide support for u-boot,
beyond the testing it will get through booting each kernel to be tested. If we
do, I would prefer not to include vendor forks as this could greatly increase
the maintenance effort.

Is there a particular feature set that CIP requires?
[...]

For testing purposes we will need at least an unauthenticated command
prompt (CONFIG_AUTOBOOT_KEYED=n), networking and TFTP support.
That probably isn't a complete list.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Update 2017wk14

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

Hi,

On 10/04/17 11:28, Agustin Benito Bethencourt wrote:
Dear CIP friends,

here is the report of those tasks related with Testing and kernel
maintenance that Don, Ben, Robert, Lachlan and myself has been working
on the past two weeks (12 and 13):

++ Board At Desk - Single Dev

The B.A.D.-S.D. team were facing the last few tasks before the release
when upstream updated kernelci. Some of the changes impacted us. I
decided to include the updates in this coming release despite having
past Beta milestone in order to match upstream, which will delay our
release, scheduled for mid April. In any case, we expect to be testing
the kernel on regular basis by the time we reach Open Source Summit
Japan. That has not changed.

This is always a challenging situation for any downstream project, when
you get an important update from upstream in the middle of the release
process, as we currently are.

The reason I took this decision is that we, as CIP project, will heavily
depend on upstream to provide support on LAVA and KernelCI to our
consumers, due to the complexity of the tooling. We will not be able to
become the default support channel. It is far from being our goal
either. I believe it is better for CIP to participate in the existing
support channel upstream has.

Being up to date with them is the only reasonable way to get that
support for our future users. Since there is no release from our side
yet, doing this right will help us in our credibility as project from
the very beginning.

After taken the decision, the following question is, what will we do if
this situation happens again in the future? And it will.

It would be very unfortunate if this happens again before our release,
based on our conversations with upstream. In any case, we will provide
an stable VM, now that have a "download service", as soon as the issues
related with the recent update are fixed (we are currently fixing what
we believe it is the last one, #65).

In general, the VM images will work as stable releases while the
"development VM" will be provided through Vagrant. This way those
interested in the development of the tooling itself will be able to get
the latest commits as they are merged, while those only interested in
using Board At Desk - Single Dev as consumers will always have an
"stable image" working, independently of what upstream or our team does.

We will inform through this mailing list as soon as the VM gets to the
state prior to the upstream update. We will re-focus then on the release.

I apologise for the inconveniences. I understand some of you are looking
forward to use the VM to test the CIP kernel. It was a tough decision to
make, with a high impact in the short term, but a higher risk for the
project in the mid term, in my modest opinion.

Issues closed:
* #49 USB passthrough config needs correcting
* #60 Kernel build failure
* #61 Error on running install_frontend.sh
* #57 Missing error checks in provisioning scripts
* #55 fix behaviour of vm with ifup failures
* #64 The KernelCI Backend fails on missing Ansible variable error_email
* #63 the kernelci webserver will no longer display builds that have
been performed. This is fact is the same issue that #65

Other issues
* #58 ser2net integration script may generate incorrect configuration
was reopened.
Link to all the issues: https://gitlab.com/cip-project/testing/boards


++ Kernel maintenance

Main tasks:
* Kernel security tracker: Ben H. wrote a template and implemented
importers
* Kernel feature support: Ben H. collected and began reviewing members'
configurations
* Ben Hutchings participated in the last TSC bi-weekly call. He answered
questions at members' phone meeting. Please check the minutes for
further details:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr032017

* Ben H. reviewed changes for Linux 4.4.60

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


Update 2017wk14

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

Dear CIP friends,

here is the report of those tasks related with Testing and kernel maintenance that Don, Ben, Robert, Lachlan and myself has been working on the past two weeks (12 and 13):

++ Board At Desk - Single Dev

The B.A.D.-S.D. team were facing the last few tasks before the release when upstream updated kernelci. Some of the changes impacted us. I decided to include the updates in this coming release despite having past Beta milestone in order to match upstream, which will delay our release, scheduled for mid April. In any case, we expect to be testing the kernel on regular basis by the time we reach Open Source Summit Japan. That has not changed.

This is always a challenging situation for any downstream project, when you get an important update from upstream in the middle of the release process, as we currently are.

The reason I took this decision is that we, as CIP project, will heavily depend on upstream to provide support on LAVA and KernelCI to our consumers, due to the complexity of the tooling. We will not be able to become the default support channel. It is far from being our goal either. I believe it is better for CIP to participate in the existing support channel upstream has.

Being up to date with them is the only reasonable way to get that support for our future users. Since there is no release from our side yet, doing this right will help us in our credibility as project from the very beginning.

After taken the decision, the following question is, what will we do if this situation happens again in the future? And it will.

It would be very unfortunate if this happens again before our release, based on our conversations with upstream. In any case, we will provide an stable VM, now that have a "download service", as soon as the issues related with the recent update are fixed (we are currently fixing what we believe it is the last one, #65).

In general, the VM images will work as stable releases while the "development VM" will be provided through Vagrant. This way those interested in the development of the tooling itself will be able to get the latest commits as they are merged, while those only interested in using Board At Desk - Single Dev as consumers will always have an "stable image" working, independently of what upstream or our team does.

We will inform through this mailing list as soon as the VM gets to the state prior to the upstream update. We will re-focus then on the release.

I apologise for the inconveniences. I understand some of you are looking forward to use the VM to test the CIP kernel. It was a tough decision to make, with a high impact in the short term, but a higher risk for the project in the mid term, in my modest opinion.

Issues closed:
* #49 USB passthrough config needs correcting
* #60 Kernel build failure
* #61 Error on running install_frontend.sh
* #57 Missing error checks in provisioning scripts
* #55 fix behaviour of vm with ifup failures
* #64 The KernelCI Backend fails on missing Ansible variable error_email
* #63 the kernelci webserver will no longer display builds that have been performed. This is fact is the same issue that #65

Other issues
* #58 ser2net integration script may generate incorrect configuration was reopened.

++ Kernel maintenance

Main tasks:
* Kernel security tracker: Ben H. wrote a template and implemented importers
* Kernel feature support: Ben H. collected and began reviewing members' configurations
* Ben Hutchings participated in the last TSC bi-weekly call. He answered questions at members' phone meeting. Please check the minutes for further details: https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr032017
* Ben H. reviewed changes for Linux 4.4.60

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


Re: CIP TSC meeting minutes (3 April 2017)

Takuo Koguchi
 

Hi Yoshi,

Regarding to my project-x action item, recipes-kernel for BBB and CycloneV is already posted.

If you copy recipes-kernel to your usual poky build (i.e. DISTRO = poky without meta-debian,)
you will be able to bitbake virtual/kernel.

But it you want to use this recipe with meta-debian, there are some issues.
1) you have to add meta-PROJECTX/conf/local.conf.sample and bblayer.conf.sample manually.
This is my fault. I forgot to include these files. You can copy these files from deby-qemux86-64/meta-PROJECTX/conf

If you do the above, you can bitbake virtual/kernel if the followings are in conf/local.conf
MACHINE="beaglebone"
LINUX_DEFCONFIG="omap2plus_defconfig"

But this is still not what I meant for.
In the above mentioned build my "linux-cip" recipe is not used even if
PREFERRED_PROVIDER_virtual/kernel = "linux-cip"
is defined in local.conf because PREFERRED_PROVIDER _virtual/kernel is overwritten
by meta-debian/conf\/distro/include/debian-preferred-provider.inc:2
to "linux-base"

I hope you can change
PREFERRED_PROVIDER_virtual/kernel = "linux-base"
for
PREFERRED_PROVIDER_virtual/kernel ?= "linux-base"

Unfortunately there are still some issue to build kernel with meta-debian. I am working on it.


Best Regard,

Takuo Koguchi

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of KOBAYASHI Yoshitake
Sent: Thursday, April 06, 2017 2:07 PM
To: cip-dev@...
Subject: [!][cip-dev] CIP TSC meeting minutes (3 April 2017)

Hi everyone,

I uploaded the meeting minutes for CIP Technical Steering Committee meeting held 3
April, 2017 at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr03201
7

Past TSC meeting minutes can be find at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings.

Best regards,
Yoshi


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


CIP TSC meeting minutes (3 April 2017)

Yoshitake Kobayashi
 

Hi everyone,

I uploaded the meeting minutes for CIP Technical Steering Committee meeting
held 3 April, 2017 at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr032017

Past TSC meeting minutes can be find at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings.

Best regards,
Yoshi


Recent bug after updating kernelci

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

Hi,

those of you who are trying to build BAD-SD VM with Vagrant might have noticed that the builds done with kernelci does not appear in the dashboard.

The ticket is here: https://gitlab.com/cip-project/testing/issues/63

Upstream has updated the backend of kernelci and we are looking into how this affects our set up.

In the near future we will provide the VM image so, when upstream updates key parts of the tooling breaking our VM, you will still be able to download and use the image while we adapt to the new changes.

Best Reagrds

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


Re: Twitter account

Mauerer, Wolfgang
 

Hi all,

On 31.03.2017 12:51, Agustin Benito Bethencourt wrote:
On 31/03/17 11:26, Wolfgang Mauerer wrote:
On 30.03.2017 15:33, Noriaki Fukuyasu wrote:

I think this is a great idea.
The challenge is how to manage the posts (who, what and how often etc).
Anyway, let me think over this.
marketing and creating public awareness of our endeavour is
of course good -- keeping up regular activity is going to be the
hard thing. But if we publish

* new software releases (board at desk, kernel)
* member presentations at conferences
The above will allow us to have one tweet per month which is not a bad
start. I prefer less tweets but relevant than a lot of noise.


we should at least have some base activity. I'm wondering, though,
what we intend to achieve with the account? (except that everybody
needs to have a Twitter account these days, as it seems :))
This is always a good question.

We can focus on:
1.- Increase the number of developers subscribed to our mailing list.
2.- increase the number of developers subscribed to our #IRC channel.
Currently we have around 20 people.
3.- Increase the number of downloads of our materials: VM images
(tools), slides from conferences.
4.- Increase the viewers of the videos of our conferences.

All the above objectives can be measurable together with the influence
that twitter has on them so we can determine goals for 2018 based on the
numbers we get in this first 2017.
... which suggests that we should also do after-conference tweets once
any materials (slides, videos) have been published.

Thanks, Wolfgang


Thanks, Wolfgang

regards

Nori


On Wed, Mar 29, 2017 at 10:53 PM, Agustin Benito Bethencourt
<agustin.benito@... <mailto:agustin.benito@...>>
wrote:

Hi,

maybe we can start the support of our promo efforts with a Twitter
account. I would also think about a hashtag

Best Regards

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




--
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
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Twitter account

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

Hi,

On 31/03/17 11:26, Wolfgang Mauerer wrote:
Hi all,

On 30.03.2017 15:33, Noriaki Fukuyasu wrote:
Hi Agustin

I think this is a great idea.
The challenge is how to manage the posts (who, what and how often etc).
Anyway, let me think over this.
marketing and creating public awareness of our endeavour is
of course good -- keeping up regular activity is going to be the
hard thing. But if we publish

* new software releases (board at desk, kernel)
* member presentations at conferences
The above will allow us to have one tweet per month which is not a bad start. I prefer less tweets but relevant than a lot of noise.


we should at least have some base activity. I'm wondering, though,
what we intend to achieve with the account? (except that everybody
needs to have a Twitter account these days, as it seems :))
This is always a good question.

We can focus on:
1.- Increase the number of developers subscribed to our mailing list.
2.- increase the number of developers subscribed to our #IRC channel. Currently we have around 20 people.
3.- Increase the number of downloads of our materials: VM images (tools), slides from conferences.
4.- Increase the viewers of the videos of our conferences.

All the above objectives can be measurable together with the influence that twitter has on them so we can determine goals for 2018 based on the numbers we get in this first 2017.


Thanks, Wolfgang

regards

Nori


On Wed, Mar 29, 2017 at 10:53 PM, Agustin Benito Bethencourt
<agustin.benito@... <mailto:agustin.benito@...>>
wrote:

Hi,

maybe we can start the support of our promo efforts with a Twitter
account. I would also think about a hashtag

Best Regards

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




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


Re: Twitter account

Mauerer, Wolfgang
 

Hi all,

On 30.03.2017 15:33, Noriaki Fukuyasu wrote:
Hi Agustin

I think this is a great idea.
The challenge is how to manage the posts (who, what and how often etc).
Anyway, let me think over this.
marketing and creating public awareness of our endeavour is
of course good -- keeping up regular activity is going to be the
hard thing. But if we publish

* new software releases (board at desk, kernel)
* member presentations at conferences

we should at least have some base activity. I'm wondering, though,
what we intend to achieve with the account? (except that everybody
needs to have a Twitter account these days, as it seems :))

Thanks, Wolfgang

regards

Nori


On Wed, Mar 29, 2017 at 10:53 PM, Agustin Benito Bethencourt
<agustin.benito@... <mailto:agustin.benito@...>>
wrote:

Hi,

maybe we can start the support of our promo efforts with a Twitter
account. I would also think about a hashtag

Best Regards

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




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

9481 - 9500 of 9694