Date   

Re: running health checks from behind a web proxy

Daniel Sangorrin <daniel.sangorrin@...>
 

Thanks Robert, I will try today and see if it works.
# I'll close the gitlab issue in that case.

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Robert Marshall
Sent: Wednesday, July 05, 2017 11:19 PM
To: cip dev
Subject: [cip-dev] running health checks from behind a web proxy

There is a known issue with b@d when running a lava QEMU health check
from behind a web proxy.

When attempting to retrieve the kernel, it produces the error

Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org', port=443):
Max retries exceeded with url: /kvm/standard/stretch-2.img.gz
(Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]

see:
https://gitlab.com/cip-project/cip-testing/testing/issues/99

As b@d is intended to use locally built artefacts and the default QEMU health
check uses a remote kernel, a suggested work around for this test would be to copy
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
locally to /var/www/images/kernel-ci/qemu (a new directory)
and alter the health check to use the url
http://localhost:8010/qemu/stretch-2.img.gz

which should avoid the use of any web proxies.

You'll probably need a fairly clean copy of the VM with plenty of free
disk space to manage the extra copy of the kernel.

Thoughts? Hoping to discuss this further at tomorrow's open meeting.

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


Re: New repos for tests and logs

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

Hi,

On 29/06/17 11:40, Agustin Benito Bethencourt wrote:
Hi,

three new repositories has been created:

* https://gitlab.com/cip-project/cip-testing/imported-kernel-tests

For those third party tests we will use to test the CIP kernel

* https://gitlab.com/cip-project/cip-testing/CIP-kernel-test-logs

For the canonical logs we will compare results against.

* https://gitlab.com/cip-project/cip-kernel-tests

Test developed within the CIP project under CIP approved licenses.
A new repository has been created to mirror some kernelci frontend config files that we use so we can control which upstream changes should be applied when. It is called kernelci-frontend-config

Link: https://gitlab.com/cip-project/cip-testing/kernelci-frontend-config/tree/master

Best Regards

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


Re: CIP testing project: outcome of the OSSJ

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

Hi,

On 14/06/17 17:28, Agustin Benito Bethencourt wrote:
I plan to submit a talk about our progress in the testing front for
ELCE. Action 2:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting
I just submitted a technical talk in which Ben H. and myself will be talking about kernel maintenance & testing using the CIP work as example. Let's see if it gets approved.

If Chris, both Daniels or others have something to report about in the kernel maintenance/testing front related with CIP, maybe you can help us to deliver the talk.

Best regards

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


stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4 warnings (v4.4.76)

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

Hi,

please see below an example of a report sent to the kernel-build-reports@... of the latest LTS kernel version.

As you know, kernelci is mainly targeting kernel developers, not kernel maintainers. I suspect that Ben H. and Daniel W. will suggest changes in this report, specially when we add specific tests to our "CIP suite". I think this is a great reference though.


-------- Forwarded Message --------
Subject: stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4
warnings (v4.4.76)
Date: Wed, 05 Jul 2017 08:59:44 -0700 (PDT)
From: kernelci.org bot <bot@...>
To: kernel-build-reports@...



stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4 warnings
(v4.4.76) *stable/linux-4.4.y build: 199 builds: 0 failed, 199 passed, 4
warnings (v4.4.76)*
Full Build Summary:
https://kernelci.org/build/stable/branch/linux-4.4.y/kernel/v4.4.76/
Tree: stable
Branch: linux-4.4.y
Git Describe: v4.4.76
Git Commit: 4282d39575bf17daedc18f2fe01ca349830a6e99
Git URL:
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
<https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=4282d39575bf17daedc18f2fe01ca349830a6e99>
Built: 4 unique architectures

*Warnings Detected:*

x86: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
defconfig+CONFIG_KASAN=y
<https://kernelci.org/build/id/595d084059b514da801baba7/> 4 warnings
<https://storage.kernelci.org/stable/linux-4.4.y/v4.4.76/x86/defconfig+CONFIG_KASAN=y/build-warnings.log>



Warnings summary:
1 net/wireless/nl80211.c:5096:1: warning: the frame size of 2064 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:3859:1: warning: the frame size of 2168 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:1728:1: warning: the frame size of 5640 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344
bytes is larger than 2048 bytes [-Wframe-larger-than=]

*Detailed per-defconfig build reports:*

*acs5k_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*acs5k_tiny_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*allmodconfig+CONFIG_OF=n* (x86) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*allnoconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*allnoconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*allnoconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*allnoconfig* (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches

*am200epdkit_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ar7_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*assabet_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*at91_dt_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ath79_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*axm55xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*badge4_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*bcm2835_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bcm47xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bcm63xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bcm_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*bigsur_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bmips_be_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*bmips_stb_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*capcella_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cavium_octeon_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cerfcube_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ci20_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*clps711x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cm_x2xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cm_x300_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cns3420vb_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*cobalt_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*colibri_pxa270_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*colibri_pxa300_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*collie_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*corgi_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*davinci_all_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*db1xxx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*decstation_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*defconfig* (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches

*defconfig+CONFIG_CPU_BIG_ENDIAN=y* (arm64) — PASS, 0 errors, 0
warnings, 0 section mismatches

*defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y* (arm64) — PASS, 0 errors, 0
warnings, 0 section mismatches

*defconfig+CONFIG_KASAN=y* (x86) — PASS, 0 errors, 4 warnings, 0 section
mismatches

Warnings:
net/wireless/nl80211.c:3859:1: warning: the frame size of 2168 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:5096:1: warning: the frame size of 2064 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1728:1: warning: the frame size of 5640 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes
is larger than 2048 bytes [-Wframe-larger-than=]

*defconfig+CONFIG_LKDTM=y* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_LKDTM=y* (x86) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*defconfig+CONFIG_LKDTM=y* (arm64) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_OF_UNITTEST=y* (x86) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_OF_UNITTEST=y* (arm64) — PASS, 0 errors, 0 warnings, 0
section mismatches

*defconfig+CONFIG_RANDOMIZE_BASE=y* (arm64) — PASS, 0 errors, 0
warnings, 0 section mismatches

*defconfig+kvm_guest* (x86) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*dove_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*e55_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ebsa110_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*efm32_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*em_x270_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ep93xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*eseries_pxa_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*exynos_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ezx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*footbridge_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*fuloong2e_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*gpr_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*h3600_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*h5000_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*hackkit_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*hisi_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*i386_defconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*imote2_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*imx_v4_v5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*imx_v6_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*integrator_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*iop13xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*iop32x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*iop33x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip22_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip27_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip28_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ip32_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ixp4xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*jazz_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*jmr3927_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*jornada720_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*keystone_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*ks8695_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lart_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lasat_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lemote2f_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*loongson3_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*lpc18xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*lpc32xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*lpd270_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*ls1b_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*lubbock_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*magician_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mainstone_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*malta_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*malta_kvm_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*malta_kvm_guest_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*malta_qemu_32r6_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*maltaaprp_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltasmvp_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltasmvp_eva_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltaup_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*maltaup_xpa_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*markeins_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mini2440_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mips_paravirt_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mmp2_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*moxart_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*mpc30x_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*msp71xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mtx1_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*multi_v5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*multi_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*multi_v7_defconfig+CONFIG_ARM_LPAE=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_EFI=y* (arm) — PASS, 0 errors, 0 warnings, 0
section mismatches

*multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y* (arm) — PASS, 0
errors, 0 warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_LKDTM=y* (arm) — PASS, 0 errors, 0 warnings,
0 section mismatches

*multi_v7_defconfig+CONFIG_PROVE_LOCKING=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*multi_v7_defconfig+CONFIG_SMP=n* (arm) — PASS, 0 errors, 0 warnings, 0
section mismatches

*multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y*
(arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*mv78xx0_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mvebu_v5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mvebu_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*mvebu_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*mxs_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*neponset_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*netwinder_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*netx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*nhk8815_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*nlm_xlp_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*nlm_xlr_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*nuc910_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*nuc950_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*nuc960_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*omap1_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*omap2plus_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*orion5x_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*palmz72_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*pcm027_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pistachio_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*pleb_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pnx8335_stb225_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0
section mismatches

*prima2_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pxa168_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pxa255-idp_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*pxa3xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*pxa910_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*qcom_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*qi_lb60_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*raumfeld_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*rb532_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*rbtx49xx_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*realview-smp_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*realview_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*rm200_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*rpc_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*rt305x_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*s3c2410_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*s3c6400_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*s5pv210_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*sama5_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*sb1250_swarm_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*sead3_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*sead3micro_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*shannon_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*shmobile_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*simpad_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*socfpga_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spear13xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spear3xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spear6xx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*spitz_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*stm32_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*sunxi_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tb0219_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tb0226_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tb0287_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tct_hammer_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*tegra_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*tinyconfig* (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches

*trizeps4_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*u300_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*u8500_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*versatile_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*versatile_defconfig+CONFIG_OF_UNITTEST=y* (arm) — PASS, 0 errors, 0
warnings, 0 section mismatches

*vexpress_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*vf610m4_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*viper_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*vt8500_v6_v7_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*workpad_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*x86_64_defconfig* (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches

*xcep_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*xilfpga_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section
mismatches

*xway_defconfig* (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches

*zeus_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches

*zx_defconfig* (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


For more info write to <info@... <mailto:info@...>>


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


Re: LAVA health checks

Chris Paterson
 

Hello Agustin,

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: 05 July 2017 14:20

Hi,

one of the tasks that the CIP testing team has been performing since before
the B@D release is a daily LAVA health check using the CIP kernel and BBB[2].

What is a health check?

According to LAVA documentation[1]...

"A health check is a special type of test job, designed to validate that the a
test device and the infrastructure around it are suitable for running LAVA
tests. Health checks jobs are run periodically to check for equipment and/or
infrastructure failures that may have happened. [...]"

So we are using this daily health check as "validation test" for B@D in our
default (for now) set up, that is B@D running on Linux + CIP kernel
+ BBB.

So on top of the testing that Ben H. does as maintainer, the CIP testing
team is booting the kernel on the BBB using B@D on daily basis. On the
positive side, this health check can be reproduced by others. But still
we are providing limited value since results are not shared.

Action 2 is the next milestone, in which we want to use B@D to test the
kernel (first, then a simple system) in a fully decentralised
environment (some would call it architecture).

The initial step is for B@D to be able to send mails (reports)
automatically to the cip-test-results mailing list. With this feature,
we could collaborate in ensuring the B@D is ready to test the CIP kernel
on complementary environments like:
* Using Renesas boards
* Running B@D on Windows10

on daily basis.

But sharing the results in the CIP context is far from enough. We need
to ensure transparently that any of us is:
1. using the same tests...
2. to test the same CIP system...
3. on the same boards...
4. with the same tool set...
5. under the same environment...
6. producing the same reports...
7. based on the same logs.
Thank you for raising this point. You are of course correct.


During our Thursday meetings (remember they are open so please join us)
we are starting to think about how we can use the health check concept
to "validate" points 2 to 5. This is a very interesting challenge that
we believe we can solve to great extend assuming a "fully distributed
testing service architecture"..
I should be able to attend this week.

Kind regards, Chris


[1] https://validation.linaro.org/static/docs/v2/healthchecks.html
[2] BBB - BeagleBone Black

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


running health checks from behind a web proxy

Robert Marshall <robert.marshall@...>
 

There is a known issue with b@d when running a lava QEMU health check
from behind a web proxy.

When attempting to retrieve the kernel, it produces the error

Invalid job data:
["HTTPSConnectionPool(host='images.validation.linaro.org', port=443):
Max retries exceeded with url: /kvm/standard/stretch-2.img.gz
(Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection
object at 0x7f430c9b9c50>: Failed to establish a new connection: [Errno -5] No address associated with hostname',))"]

see:
https://gitlab.com/cip-project/cip-testing/testing/issues/99

As b@d is intended to use locally built artefacts and the default QEMU health
check uses a remote kernel, a suggested work around for this test would be to copy
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
locally to /var/www/images/kernel-ci/qemu (a new directory)
and alter the health check to use the url
http://localhost:8010/qemu/stretch-2.img.gz

which should avoid the use of any web proxies.

You'll probably need a fairly clean copy of the VM with plenty of free
disk space to manage the extra copy of the kernel.

Thoughts? Hoping to discuss this further at tomorrow's open meeting.

Robert


LAVA health checks

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

Hi,

one of the tasks that the CIP testing team has been performing since before the B@D release is a daily LAVA health check using the CIP kernel and BBB[2].

What is a health check?

According to LAVA documentation[1]...

"A health check is a special type of test job, designed to validate that the a test device and the infrastructure around it are suitable for running LAVA tests. Health checks jobs are run periodically to check for equipment and/or infrastructure failures that may have happened. [...]"

So we are using this daily health check as "validation test" for B@D in our default (for now) set up, that is B@D running on Linux + CIP kernel + BBB.

So on top of the testing that Ben H. does as maintainer, the CIP testing team is booting the kernel on the BBB using B@D on daily basis. On the positive side, this health check can be reproduced by others. But still we are providing limited value since results are not shared.

Action 2 is the next milestone, in which we want to use B@D to test the kernel (first, then a simple system) in a fully decentralised environment (some would call it architecture).

The initial step is for B@D to be able to send mails (reports) automatically to the cip-test-results mailing list. With this feature, we could collaborate in ensuring the B@D is ready to test the CIP kernel on complementary environments like:
* Using Renesas boards
* Running B@D on Windows10

on daily basis.

But sharing the results in the CIP context is far from enough. We need to ensure transparently that any of us is:
1. using the same tests...
2. to test the same CIP system...
3. on the same boards...
4. with the same tool set...
5. under the same environment...
6. producing the same reports...
7. based on the same logs.

During our Thursday meetings (remember they are open so please join us) we are starting to think about how we can use the health check concept to "validate" points 2 to 5. This is a very interesting challenge that we believe we can solve to great extend assuming a "fully distributed testing service architecture"..

[1] https://validation.linaro.org/static/docs/v2/healthchecks.html
[2] BBB - BeagleBone Black

Best Regards

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


Re: B@D on Windows 10

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

Hi,

On 05/07/17 02:44, Daniel Sangorrin wrote:
Can someone confirm the above results, please? Now that Robert is the
only person working on the testing front, double checking his results by
other companies/contributors becomes almost imperative.
Unfortunately I don't have a Windows 10 machine to test it.
But if the proxy problem is fixed has been fixed I can try instralling B@D again
on my Ubuntu machine.
It should be the next one on our bug list.

Best Regards


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


Re: B@D on Windows 10

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Agustin,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Agustin Benito Bethencourt
Sent: Tuesday, July 04, 2017 6:49 PM
To: cip dev
Subject: Re: [cip-dev] B@D on Windows 10

Hi,

On 04/07/17 11:32, Robert Marshall wrote:
Robert Marshall <robert.marshall@...> writes:

The B@D development team has been investigating if there are any issues
with the use of the B@D VM on Windows. The ticket
https://gitlab.com/cip-project/cip-testing/testing/issues/106
is being used to collect information and workarounds.

Briefly the current issues/state is as follows:

- We are using virtualbox rather than rsync for config.vm.synced_folder
- core.autocrlf=input is needed in the git settings for the scripts to
run under Debian (and an ssh client either via git or another route)
- We need to look at a substitute for ser2net running on the host in
order to open a connection from the VM to the BBB
- The VM installs and both the KernelCI webserver and Lava2 run
- Having built a kernel the build does not appear in the KernelCI web
interface, there's a long delay before it times out
- Health checks can be created but they don't appear to run, the admin
interface knows about the devices but they don't appear in
Scheduler->All Devices

This testing has been carried out directly from the pure Vagrant install
- once this is running the pre-loaded Vagrant box will also be tested.

Further work is continuing to get B@D fully operational on a Windows 10 host.
To report on the progress since Friday:

- KernelCI does not work with Microsoft Edge or Internet Explorer - we
recommend the use of firefox to display kernel build results - where
the KernelCI web interface does work.
- The hostname in the VM is different when run from windows a MR
has been created to deal with both versions of this
- The QEMU health check now runs on the W10 virtual machine
- The BBB health check will run when connecting to a BBB attached to a
debian machine from the Windows VM both with the linaro kernel and a
locally built one
Can someone confirm the above results, please? Now that Robert is the
only person working on the testing front, double checking his results by
other companies/contributors becomes almost imperative.
Unfortunately I don't have a Windows 10 machine to test it.
But if the proxy problem is fixed has been fixed I can try instralling B@D again
on my Ubuntu machine.

Thanks,
Daniel


Thank you Robert, good progress this week.

As usual, you can also meet us at #cip in freenode.

- We are still in progress of creating and testing a local initiramfs
and configuring the FTDI connection correctly


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


Re: [Lava-users] OE/Yocto testcase

Robert Berger <lava.users.mailinglist@...>
 

Hi,

On 2017-07-04 15:18, Agustin Benito Bethencourt wrote:
Dear CIP friends,
please check below. This is a use case we will meet in a few weeks/months. It is important to see others walking the same route.
My simple tests are running now thanks to the help of the nice people from the #linaro-lava chat.

1) Crazy me decided to use upstream u-boot 2017.05 instead of running some ancient version from 2014;)

1.1) which happens to have a different AUTOBOOT_PROMPT than the one Lava expects "Press SPACE to abort autoboot in %d seconds\n" instead of "Hit any key to stop autoboot" so (since) I would like to be able to stay as close as possible to upstream LAVA 2017.06 I patched u-boot[1]. Note that this could be fixed with LAVA as well - interrupt_prompt: {{ interrupt_prompt|default('Hit any key to stop autoboot') }}

1.2) also the SYS_PROMPT of upstream u-boot is different than the one expected by LAVA and again I made a u-boot patch[2]. Note that this could be fixed with LAVA as well - {% set bootloader_prompt = bootloader_prompt|default('U-Boot') %}

2) After some searching it turned out that LAVA set some funny variables in u-boot which made my kernel crash. (Crazy me decided to use a 4.9.x uImage without baked in address).

Adding this:
{% set base_high_limits = false %}
to my bbb03.jinja2 file fixed it.

... obviously ;)

Regards,

Robert

[1] https://github.com/RobertBerger/meta-mainline/blob/pyro-training-v4.9.x/u-boot-wic-bsp/recipes-bsp/u-boot/2017.05/beagle-bone-black/0002-default-AUTOBOOT_PROMPT-for-LAVA.patch
[2] https://github.com/RobertBerger/meta-mainline/blob/pyro-training-v4.9.x/u-boot-wic-bsp/recipes-bsp/u-boot/2017.05/beagle-bone-black/0003-SYS_PROMPT-LAVA-compatible.patch


[Lava-users] OE/Yocto testcase

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

Dear CIP friends,

please check below. This is a use case we will meet in a few weeks/months. It is important to see others walking the same route.


-------- Forwarded Message --------
Subject: [Lava-users] OE/Yocto testcase
Date: Mon, 3 Jul 2017 20:19:31 +0300
From: Robert Berger <lava.users.mailinglist@...>
To: Lava-users@...

Hi,

I succeeded in running the example Lava tests[1][2] on a Beagle Bone
Black in my lab.

Now I would like to test a core-image-minimal I built with Yocto and
cooked up something like this[3][4].

The result is unfortunately this[5].

I guess one of the problems I have is this:

lava-test: # ls -l /lava-38/
export SHELL=/bin/sh
/lava-38/bin/lava-test-runner /lava-38/0ls: cannot access '/lava-38/':
No such file or directory
lava-test: # export SHELL=/bin/sh
lava-test: # /lava-38/bin/lava-test-runner /lava-38/0
-sh: /lava-38/bin/lava-test-runner: No such file or directory

Regards,

Robert


[1]
https://validation.linaro.org/static/docs/v2/examples/test-jobs/standard-armmp-ramdisk-bbb.yaml
[2]
https://validation.linaro.org/static/docs/v2/examples/test-jobs/standard-armmp-nfs-bbb.yaml

[3]
https://github.com/RobertBerger/git.linaro.org-lava-team-refactoring/blob/master/bbb-core-image-minimal-1.yaml
[4]
https://github.com/RobertBerger/git.linaro.org-qa-test-definitions/blob/master/openembedded/smoke-tests-basic-core-image-minimal.yaml

[5] https://pastebin.com/14pjxhiN
_______________________________________________
Lava-users mailing list
Lava-users@...
https://lists.linaro.org/mailman/listinfo/lava-users

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


Re: B@D on Windows 10

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

Hi,

On 04/07/17 11:32, Robert Marshall wrote:
Robert Marshall <robert.marshall@...> writes:

The B@D development team has been investigating if there are any issues
with the use of the B@D VM on Windows. The ticket
https://gitlab.com/cip-project/cip-testing/testing/issues/106
is being used to collect information and workarounds.

Briefly the current issues/state is as follows:

- We are using virtualbox rather than rsync for config.vm.synced_folder
- core.autocrlf=input is needed in the git settings for the scripts to
run under Debian (and an ssh client either via git or another route)
- We need to look at a substitute for ser2net running on the host in
order to open a connection from the VM to the BBB
- The VM installs and both the KernelCI webserver and Lava2 run
- Having built a kernel the build does not appear in the KernelCI web
interface, there's a long delay before it times out
- Health checks can be created but they don't appear to run, the admin
interface knows about the devices but they don't appear in
Scheduler->All Devices

This testing has been carried out directly from the pure Vagrant install
- once this is running the pre-loaded Vagrant box will also be tested.

Further work is continuing to get B@D fully operational on a Windows 10 host.
To report on the progress since Friday:

- KernelCI does not work with Microsoft Edge or Internet Explorer - we
recommend the use of firefox to display kernel build results - where
the KernelCI web interface does work.
- The hostname in the VM is different when run from windows a MR
has been created to deal with both versions of this
- The QEMU health check now runs on the W10 virtual machine
- The BBB health check will run when connecting to a BBB attached to a
debian machine from the Windows VM both with the linaro kernel and a
locally built one
Can someone confirm the above results, please? Now that Robert is the only person working on the testing front, double checking his results by other companies/contributors becomes almost imperative.

Thank you Robert, good progress this week.

As usual, you can also meet us at #cip in freenode.

- We are still in progress of creating and testing a local initiramfs
and configuring the FTDI connection correctly


Robert
_______________________________________________
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: B@D on Windows 10

Robert Marshall <robert.marshall@...>
 

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

The B@D development team has been investigating if there are any issues
with the use of the B@D VM on Windows. The ticket
https://gitlab.com/cip-project/cip-testing/testing/issues/106
is being used to collect information and workarounds.

Briefly the current issues/state is as follows:

- We are using virtualbox rather than rsync for config.vm.synced_folder
- core.autocrlf=input is needed in the git settings for the scripts to
run under Debian (and an ssh client either via git or another route)
- We need to look at a substitute for ser2net running on the host in
order to open a connection from the VM to the BBB
- The VM installs and both the KernelCI webserver and Lava2 run
- Having built a kernel the build does not appear in the KernelCI web
interface, there's a long delay before it times out
- Health checks can be created but they don't appear to run, the admin
interface knows about the devices but they don't appear in
Scheduler->All Devices

This testing has been carried out directly from the pure Vagrant install
- once this is running the pre-loaded Vagrant box will also be tested.

Further work is continuing to get B@D fully operational on a Windows 10 host.
To report on the progress since Friday:

- KernelCI does not work with Microsoft Edge or Internet Explorer - we
recommend the use of firefox to display kernel build results - where
the KernelCI web interface does work.
- The hostname in the VM is different when run from windows a MR
has been created to deal with both versions of this
- The QEMU health check now runs on the W10 virtual machine
- The BBB health check will run when connecting to a BBB attached to a
debian machine from the Windows VM both with the linaro kernel and a
locally built one
- We are still in progress of creating and testing a local initiramfs
and configuring the FTDI connection correctly


Robert


Linux 4.4.75-cip6

Ben Hutchings <ben.hutchings@...>
 

I've released Linux version 4.4.75-cip6. This adds the fixes from
stable versions 4.4.70-4.4.75 inclusive, plus two regression fixes that
were missing from the 4.4 stable branch. I reviewed those fixes, but
have only done very basic manual testing of the result.

(I also tagged a version 4.4.75-cip5 which doesn't include the two extra
fixes.)

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


B@D on Windows 10

Robert Marshall <robert.marshall@...>
 

The B@D development team has been investigating if there are any issues
with the use of the B@D VM on Windows. The ticket
https://gitlab.com/cip-project/cip-testing/testing/issues/106
is being used to collect information and workarounds.

Briefly the current issues/state is as follows:

- We are using virtualbox rather than rsync for config.vm.synced_folder
- core.autocrlf=input is needed in the git settings for the scripts to
run under Debian (and an ssh client either via git or another route)
- We need to look at a substitute for ser2net running on the host in
order to open a connection from the VM to the BBB
- The VM installs and both the KernelCI webserver and Lava2 run
- Having built a kernel the build does not appear in the KernelCI web
interface, there's a long delay before it times out
- Health checks can be created but they don't appear to run, the admin
interface knows about the devices but they don't appear in
Scheduler->All Devices

This testing has been carried out directly from the pure Vagrant install
- once this is running the pre-loaded Vagrant box will also be tested.

Further work is continuing to get B@D fully operational on a Windows 10 host.

Robert


New repos for tests and logs

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

Hi,

three new repositories has been created:

* https://gitlab.com/cip-project/cip-testing/imported-kernel-tests

For those third party tests we will use to test the CIP kernel

* https://gitlab.com/cip-project/cip-testing/CIP-kernel-test-logs

For the canonical logs we will compare results against.

* https://gitlab.com/cip-project/cip-kernel-tests

Test developed within the CIP project under CIP approved licenses.

Best Regards

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


CIP testing: new wiki page with instructions to build initramfs and CIP kernel

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

Hi,

as a results of the work we have done to take control over building the CIP kernel and initramfs, we have introduced in our critical content path a fourth wiki page[1], so now we have five.[2]

This wiki page describes how to create an initramfs with BusyBox for the Beaglebone Black and how to build the CIP Kernel with Kernel CI.

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuildhowto
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting#action-1board-at-desk-single-developer-b-d

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


Re: Project-X (minimal root filesystem) for renesas board

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

Hi,

On 29/06/17 02:37, Daniel Sangorrin wrote:
Hi Koguchi-san,

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 6:08 PM
To: 'Daniel Sangorrin'; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: RE: Project-X (minimal root filesystem) for renesas board

Daniel-san,

I think this is not a good approach. We would need to have a new linux-cip folder for each
release.
Let make it clear. Will you please describe your recommendation?
Yes, please see below.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.
Good point. But CIP kernel repository is curerntly used for release assuming it is tested. And CycloneV is not supported by CIP at this
moment. So I put the patches in the yocto project way.
I didn't mean to put it on Ben's CIP repository rather on github. This way you can better maintain your "out-of-tree" cyclone V patches
and merge (do not rebase please) changes from Ben's CIP kernel regularly. In other words, do the same as Renesas is doing at [1].

[1] https://github.com/renesas-rz/renesas-cip
In order to have all the cip related code in one place, it would be good, if anybody is using github, that at least there is a mirror of that repo in gitlab. When we start automating builds/test, that would be helpful.


I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?
I am happy if you go ahead and fix it!
OK, thanks. I will also separate Beaglebone from Cyclone V.

Thanks,
Daniel

Best regards,
Takuo Koguchi



-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 5:52 PM
To: 小口琢夫 / KOGUCHI,TAKUO; cip-dev@...
Cc: 'Chris Paterson'
Subject: [!]RE: Project-X (minimal root filesystem) for renesas board

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you update linux-cip.
I think this is not a good approach. We would need to have a new linux-cip folder for each
release.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if it is necessary.
I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board
which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on
the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?
- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?

Thanks,
Daniel

[1]
https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


_______________________________________________
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: Project-X (minimal root filesystem) for renesas board

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Koguchi-san,

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 6:08 PM
To: 'Daniel Sangorrin'; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: RE: Project-X (minimal root filesystem) for renesas board

Daniel-san,

I think this is not a good approach. We would need to have a new linux-cip folder for each
release.
Let make it clear. Will you please describe your recommendation?
Yes, please see below.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.
Good point. But CIP kernel repository is curerntly used for release assuming it is tested. And CycloneV is not supported by CIP at this
moment. So I put the patches in the yocto project way.
I didn't mean to put it on Ben's CIP repository rather on github. This way you can better maintain your "out-of-tree" cyclone V patches
and merge (do not rebase please) changes from Ben's CIP kernel regularly. In other words, do the same as Renesas is doing at [1].

[1] https://github.com/renesas-rz/renesas-cip

I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?
I am happy if you go ahead and fix it!
OK, thanks. I will also separate Beaglebone from Cyclone V.

Thanks,
Daniel

Best regards,
Takuo Koguchi



-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 5:52 PM
To: 小口琢夫 / KOGUCHI,TAKUO; cip-dev@...
Cc: 'Chris Paterson'
Subject: [!]RE: Project-X (minimal root filesystem) for renesas board

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?

linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you update linux-cip.
I think this is not a good approach. We would need to have a new linux-cip folder for each
release.

Patches for the cyclone board should be on its own CIP kernel repository (where you can
merge cip releases and add tags). Then, we can choose which version we want by
specifying the repository and tag/commit_id.

- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine.
xserver-related definition was inculude in the original. I am not sure if it is necessary.
I don't think it is necessary since the CIP root filesystem only supports a few packages.
Do you mind if I rewrite this and other unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board
which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on
the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost
identical?
- I can see some xserver-related definitions on the board's
configuration file. Are those necessary?

Thanks,
Daniel

[1]
https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


Re: CIP Kernel release cadence

Chris Paterson
 

Hello Agustin,

Thank you for your feedback, apologies for the delayed response.

From: Agustin Benito Bethencourt [mailto:agustin.benito@...]
Sent: 20 June 2017 18:06

Hi Chris,

I think I mentioned before some of the below arguments when this topic
was risen months ago. It is a good time to publish them here.

On 20/06/17 17:18, Ben Hutchings wrote:
On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:
Hello Ben,

Do you have a plan for when future releases of the CIP Kernel will be
made?

It would be good to have a fixed release cadence or roadmap, so
people using the Kernel can plan their activities accordingly.
I expect to release about every month, and whenever there's an urgent
security update (which there will be soon, for the "stack clash" issue).
I would like to keep flexibility here, that is, do not tight ourselves to releases
yet for a variety of reasons. These are the main ones I can think of right now:

* We are in an LTS phase. Defining a cadence at this point might reinforce the
idea that our kernel maintenance process is somehow different than LTS
when, except for a few packages, it is not yet. That was intentional.

* I would like to be able to consistently test the kernel, even with a single
test, before claiming to make releases, that is, before making a public
commitment on any delivery process. The expectations can be higher that
we can commit to.

* We do not know at this point what the maintenance cycle is going to be
from the kernel community. I am not suggesting that we have to follow it,
but before defining our cadence, I would have a clear idea about what
upstream will do.

* A kernel release for SLTS has severe implications in other areas, like the
testing tools, testing results, tests, etc. We need also to freeze/store/release
them, together with the build instructions, metadata, artifacts, source
code.... In other words, we need to define what "a release" means for CIP
and how much effort requires.
This is a good point. I guess I was referring to rebasing the CIP Kernel itself to the latest LTS tag, and when this would be done. E.g. LTS tag + x weeks?


* With the above and the fact that we are starting to put effort in -RT, I
wonder if we will talk about releasing the CIP kernel or we will talk about
releasing the CIP platform (assuming that at the beginning the kernel is the
main bit).
I think that the CIP Kernel could/should be updated constantly, like LTS is now.

Periodically a complete 'CIP platform' release should be made. I think this should be done to a schedule so that users of the CIP project can plan their activities accordingly.


Defining a release today might play against us in a year or two.

Once this said, if Members require at this point a cadence, we will provide
one but I think that sticking to LTS cycle until Feb'18 and assuming that we will
catch up every 4-8 weeks is the way to go. Once the 4.4 maintainer is
published, let's talk to him/her and take decisions.

Is there a specific reason why you need a cadence now beyond what LTS
provides? I am trying to understand the details in order to think about a
solution for Renesas compatible with the above.
Is there an actual release cycle for LTS? As far as I can see, new releases are made randomly.

Kind regards, Chris


Best Regards

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

8361 - 8380 of 8699