Date   

Re: [ANNOUNCE] v4.19.50-cip3-rt1

Pavel Machek
 

Hi!

4.19.50-cip3-rt1 should be available at kernel.org. I did limited
testing, but it seems to have some bugs fixed relative to
4.19.13-cip1-rt1. (Boots on x86-32 and cyclictest on iwg20m does not
hit WARN_ON).

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt

And their content should be identical.
Shouldn't this be 4.19.50-cip3-rt2? It's the second -rt release for 4.19-cip.
Oh and BTW testing would be very welcome.

I tried testing it on my thinkpad X60, but it is not suitable
hardware; latency goes over 1msec quite easily. But I've seen 3msec
with iwg20m board, too. I guess I should try cyclictest on
4.19.13-cip1-rt1 so I have comparison, but that is easier said than done.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [ANNOUNCE] v4.19.50-cip3-rt1

Pavel Machek
 

Hi!

4.19.50-cip3-rt1 should be available at kernel.org. I did limited
testing, but it seems to have some bugs fixed relative to
4.19.13-cip1-rt1. (Boots on x86-32 and cyclictest on iwg20m does not
hit WARN_ON).

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt

And their content should be identical.
Shouldn't this be 4.19.50-cip3-rt2? It's the second -rt release for 4.19-cip.
Its first realtime release based on 4.19.50-cip3 :-). It is also based
on 4.19.50-rt22. So yes, the naming is a bit confusing.

If such version would previously be named -rt2, I'll obviously need to
fix it.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH v2 4.4.y-cip] Add gitlab-ci.yaml

Chris Paterson
 

Hello all,

It was decided in the weekly meeting today by the maintainers that we will add the .gitlab-ci.yml files (i.e. this patch) to the main kernel.org repository.

However, I've been busy this week and already have more changes to make.

So please drop this patch and I'll submit a V3 in the next few days.

I'll mark it accordingly in patchwork.

Kind regards, Chris

From: Chris Paterson <chris.paterson2@...>
Sent: 02 July 2019 11:52

This is configured to build and test for the following configurations:

1.
ARCH: arm
CONFIGS: shmobile_defconfig
BOARDS: r8a7743-iwg20d, r8a7745-iwg22d

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

v1->v2: Updated to use latest linux-cip-ci version: 9d56f41a

I still prefer to have these .gitlab-ci.yml files in the main cip repo,
rather then split them off into their own repo and trigger them with
hooks. Any opinions Kernel maintainers?

.gitlab-ci.yml | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..aec787a353bc
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,23 @@
+variables:
+ GIT_STRATEGY: clone
+ GIT_DEPTH: "10"
+ DOCKER_DRIVER: overlay2
+
+build_arm_shmobile_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm shmobile_defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+run_tests:
+ stage: test
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:test-latest
+ when: always
+ before_script: []
+ script:
+ - /opt/submit_tests.sh
--
2.17.1


Re: [PATCH v2 4.19.y-cip] Add gitlab-ci.yaml

Chris Paterson
 

Hello all,

It was decided in the weekly meeting today by the maintainers that we will add the .gitlab-ci.yml files (i.e. this patch) to the main kernel.org repository.

However, I've been busy this week and already have more changes to make.

So please drop this patch and I'll submit a V3 in the next few days.

I'll mark it accordingly in patchwork.

Kind regards, Chris

From: Chris Paterson <chris.paterson2@...>
Sent: 02 July 2019 11:51

This is configured to build and test for the following configurations:

1.
ARCH: arm
CONFIGS: shmobile_defconfig
BOARDS: r8a7743-iwg20d, r8a7745-iwg22d
2.
ARCH: arm64
CONFIGS: defconfig
BOARDS: r8a774c0-ek874

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

v1->v2: Updated to use latest linux-cip-ci version: 9d56f41a

I still prefer to have these .gitlab-ci.yml files in the main cip repo,
rather then split them off into their own repo and trigger them with
hooks. Any opinions Kernel maintainers?


.gitlab-ci.yml | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..71d92c975723
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,35 @@
+variables:
+ GIT_STRATEGY: clone
+ GIT_DEPTH: "10"
+ DOCKER_DRIVER: overlay2
+
+build_arm_shmobile_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm shmobile_defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+build_arm64_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm64 defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+run_tests:
+ stage: test
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:test-latest
+ when: always
+ before_script: []
+ script:
+ - /opt/submit_tests.sh
+
--
2.17.1


Re: CIP IRC weekly meeting today

Akihiro Suzuki
 

Hi SZ,

Today, Daniel-san takes a day off because of sickness.
And I won't join the meeting because I have an another plan.
Sorry about that.

So I'll describe the update of SW Updates WG here before the meeting.

* Software update
* We are preparing a software update demo for OSSJ.
* We had a meeting with Christian of Siemens and he shared a sample script
that could manage the state of software update.
* Suzuki implemented the state management into the u-boot script of the demo
and now BeagleBone Black can switch back to old root filesystem if the update fails.
We call it "rollback".
* Now we can give the demo of raw image update only.
If we can make it in time, we will give the demo of binary delta update using librsync.

Best regards,
Suzuki


-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of SZ Lin (林上
智)
Sent: Thursday, July 04, 2019 10:00 AM
To: cip-dev@...
Subject: [cip-dev] CIP IRC weekly meeting today

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC
meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=7&day=4&hour=9&min=0&sec=0&p1=241&p2=137&
p3=179&p4=136&p5=37&p6=248

US-West US-East   UK     DE     TW     JP
02:00    05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* Action item
1. Provide the script for CIP kernel config collection - bwh
#link https://lists.cip-project.org/pipermail/cip-dev/2019-June/002506.html
2. List real time kernel questions to ask Daniel Wagner - szlin
3. Try updating CIP RT kernel to 4.19.50 - Pavel
#link https://lists.cip-project.org/pipermail/cip-dev/2019-June/002548.html
4. Work out a solution for LAVA master backups - patersonc
* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics
can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,

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


CIP IRC weekly meeting today

SZ Lin (林上智) <SZ.Lin@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=7&day=4&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

US-West US-East   UK     DE     TW     JP
02:00    05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* Action item
1. Provide the script for CIP kernel config collection - bwh
#link https://lists.cip-project.org/pipermail/cip-dev/2019-June/002506.html
2. List real time kernel questions to ask Daniel Wagner - szlin
3. Try updating CIP RT kernel to 4.19.50 - Pavel
#link https://lists.cip-project.org/pipermail/cip-dev/2019-June/002548.html
4. Work out a solution for LAVA master backups - patersonc
* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,

SZ Lin, Moxa.


[PATCH v2 4.4.y-cip] Add gitlab-ci.yaml

Chris Paterson
 

This is configured to build and test for the following configurations:

1.
ARCH: arm
CONFIGS: shmobile_defconfig
BOARDS: r8a7743-iwg20d, r8a7745-iwg22d

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

v1->v2: Updated to use latest linux-cip-ci version: 9d56f41a

I still prefer to have these .gitlab-ci.yml files in the main cip repo,
rather then split them off into their own repo and trigger them with
hooks. Any opinions Kernel maintainers?

.gitlab-ci.yml | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..aec787a353bc
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,23 @@
+variables:
+ GIT_STRATEGY: clone
+ GIT_DEPTH: "10"
+ DOCKER_DRIVER: overlay2
+
+build_arm_shmobile_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm shmobile_defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+run_tests:
+ stage: test
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:test-latest
+ when: always
+ before_script: []
+ script:
+ - /opt/submit_tests.sh
--
2.17.1


[PATCH v2 4.19.y-cip] Add gitlab-ci.yaml

Chris Paterson
 

This is configured to build and test for the following configurations:

1.
ARCH: arm
CONFIGS: shmobile_defconfig
BOARDS: r8a7743-iwg20d, r8a7745-iwg22d
2.
ARCH: arm64
CONFIGS: defconfig
BOARDS: r8a774c0-ek874

Over time support will be added for all CIP supported architectures and
configurations.

At the moment only simple boot tests are run. Real tests will be added in
the future.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

v1->v2: Updated to use latest linux-cip-ci version: 9d56f41a

I still prefer to have these .gitlab-ci.yml files in the main cip repo,
rather then split them off into their own repo and trigger them with
hooks. Any opinions Kernel maintainers?


.gitlab-ci.yml | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..71d92c975723
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,35 @@
+variables:
+ GIT_STRATEGY: clone
+ GIT_DEPTH: "10"
+ DOCKER_DRIVER: overlay2
+
+build_arm_shmobile_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm shmobile_defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+build_arm64_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm64 defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+run_tests:
+ stage: test
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:test-latest
+ when: always
+ before_script: []
+ script:
+ - /opt/submit_tests.sh
+
--
2.17.1


Re: [cip-kernel-sec 5/6] report_affected: add support for reporting on tags

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2019-06-25 at 12:26 +0900, Daniel Sangorrin wrote:
Reporting on tags is useful for product engineers that
have shipped a kernel with a specific tag and need to know
which issues affect their product after some time.
I think this is a really important feature, but I'm not convinced about
this implementation.

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
 scripts/report_affected.py | 60 ++++++++++++++++++++++++++++++++------
 1 file changed, 51 insertions(+), 9 deletions(-)

diff --git a/scripts/report_affected.py b/scripts/report_affected.py
index 7557dc8..32e9345 100755
--- a/scripts/report_affected.py
+++ b/scripts/report_affected.py
@@ -9,7 +9,9 @@
 # Report issues affecting each stable branch.
 
 import argparse
+import copy
 import subprocess
+import re
 
 import kernel_sec.branch
 import kernel_sec.issue
@@ -23,10 +25,26 @@ def main(git_repo, remotes,
         branches = []
         for branch in live_branches:
             for name in branch_names:
+                # there could be multiple tags for the same branch
+                branch_copy = copy.deepcopy(branch)
This makes a lot of unnecessary copies!

+                if name[0] == 'v':
+                    # a stable tag, e.g. v4.4.92-cip11
+                    branch_copy['tag'] = name
+                    match = re.match(r'^v(\d+\.\d+).*', name)
+                    if not match:
+                        raise ValueError('failed to parse tag %r' % name)
+                    if 'cip' in name:
+                        name = 'linux-%s.y-cip' % match.group(1)
+                    else:
+                        name = 'linux-%s.y' % match.group(1)
How about adding regexps for tags to the branch configuration? Then
here we could match tags to branches with
re.matchall(branch['tag_regexp'], name).

+                if '/' in name:
'/' is valid in a branch or tag name, so how about using ':' which is
not?

+                    # a possibly custom tag, e.g. product-v1
+                    branch_copy['tag'] = name.split('/')[1]
+                    name = name.split('/')[0]
It would be more Pythonic to write this as a tuple assginment.

                 if name[0].isdigit():
                     name = 'linux-%s.y' % name
-                if branch['short_name'] == name:
-                    branches.append(branch)
+                if branch_copy['short_name'] == name:
+                    branches.append(branch_copy)
         if not branches:
             msg = "supplied branches didn't match any known branch"
             raise argparse.ArgumentError(None, msg)
@@ -40,6 +58,18 @@ def main(git_repo, remotes,
 
     c_b_map = kernel_sec.branch.CommitBranchMap(git_repo, remotes, branches)
 
+    # cache tag commits and set full_name to show the tag
+    tag_commits = {}
+    for branch in branches:
+        if 'tag' in branch:
+            start = 'v' + branch['base_ver']
+            end = branch['tag']
+            for commit in kernel_sec.branch._get_commits(git_repo, end, start):
The leading '_' means private, so it shouldn't be called from here. I
think it could be made public but it needs a better name, maybe
'iter_rev_list' matching the underlying command.

+                tag_commits.setdefault(end, []).append(commit)
[...]

Suppose I tried to query 'v4.4'; then I think we get start == end ==
'v4.4' and this loop doesn't execute at all. tag_commits['v4.4'] won't
be defined at all, and the reporting loop will crash.

So this could be simply:

tag_commits[end] = list(
kernel_sec.branch.iter_rev_list(git_repo, end, start))

But I think the collection type should also be changed from list to
set, so that tests for membership will be fast.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: [cip-kernel-sec 4/6] report_affected: check user supplied branch names

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2019-06-25 at 12:26 +0900, Daniel Sangorrin wrote:
This makes sure that we return when the user supplied
branch names are not within the configured branches.
This partly addresses my comment on patch 3, but it's still only
checking that at least one name matched a known branch.

I think the inner and outer loops should be swapped, so we can do:

        branches = []
        for name in branch_names:
            if name[0].isdigit():
                name = 'linux-%s.y' % name
        for branch in live_branches:
                if branch['short_name'] == name:
                    branches.append(branch)
break
else:
# not found; raise error

Ben.

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
 scripts/report_affected.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/report_affected.py b/scripts/report_affected.py
index bd22e29..7557dc8 100755
--- a/scripts/report_affected.py
+++ b/scripts/report_affected.py
@@ -27,6 +27,9 @@ def main(git_repo, remotes,
                     name = 'linux-%s.y' % name
                 if branch['short_name'] == name:
                     branches.append(branch)
+        if not branches:
+            msg = "supplied branches didn't match any known branch"
+            raise argparse.ArgumentError(None, msg)
     else:
         branches = live_branches
         if only_fixed_upstream:
--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: [cip-kernel-sec 3/6] report_affected: fix code when branches are specified

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2019-06-25 at 12:26 +0900, Daniel Sangorrin wrote:
The previous code could not handle branches with names
other than stable branch names. For example, passing
"linux-4.4.y-cip" as a branch would return an error.
[...]
--- a/scripts/report_affected.py
+++ b/scripts/report_affected.py
@@ -18,14 +18,17 @@ import kernel_sec.version
 
 def main(git_repo, remotes,
          only_fixed_upstream, include_ignored, *branch_names):
+    live_branches = kernel_sec.branch.get_live_branches()
     if branch_names:
-        # Support stable release strings as shorthand for stable branches
-        branches = [kernel_sec.branch.get_base_ver_stable_branch(name)
-                    if name[0].isdigit()
-                    else kernel_sec.branch.get_stable_branch(name)
-                    for name in branch_names]
+        branches = []
+        for branch in live_branches:
+            for name in branch_names:
+                if name[0].isdigit():
+                    name = 'linux-%s.y' % name
+                if branch['short_name'] == name:
+                    branches.append(branch)
[...]

This results in quietly skipping arguments that don't match any known
branch. The current behaviour (failing with a TypeError) is not good
but I think failing quietly is worse.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: [ANNOUNCE] v4.19.50-cip3-rt1

Jan Kiszka
 

On 28.06.19 14:59, Pavel Machek wrote:
Hi!
4.19.50-cip3-rt1 should be available at kernel.org. I did limited
testing, but it seems to have some bugs fixed relative to
4.19.13-cip1-rt1. (Boots on x86-32 and cyclictest on iwg20m does not
hit WARN_ON).
Trees are available at
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt
And their content should be identical.
Shouldn't this be 4.19.50-cip3-rt2? It's the second -rt release for 4.19-cip.

Jan

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


[ANNOUNCE] Release linux kernel 4.19.56-cip5

Nobuhiro Iwamatsu
 

Hi all,

CIP kernel team has released Linux kernel 4.19.56-cip5.
You can get this release via the git tree at:

repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch: linux-4.19.y-cip
commit: 5b7dee96a2b4fffe481be81edc72fd104ed047ab

This release has updated the base version from 4.19.52 to 4.19.56.

Best regards,
Nobuhiro


[ANNOUNCE] v4.19.50-cip3-rt1

Pavel Machek
 

Hi!

4.19.50-cip3-rt1 should be available at kernel.org. I did limited
testing, but it seems to have some bugs fixed relative to
4.19.13-cip1-rt1. (Boots on x86-32 and cyclictest on iwg20m does not
hit WARN_ON).

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt

And their content should be identical.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [RFC/RFT] -cip-rt kernels for review/testing

Daniel Wagner <wagi@...>
 

Hi Pavel,

On 6/24/19 8:28 AM, Jan Kiszka wrote:
On 23.06.19 22:37, Pavel Machek wrote:
v4.19.50-rt22-cip3-rebase was reasonably easy to do, as -cip1 was
empty. v4.4.179-rt181-cip34-rebase was more interesting.
Yep, the v4.4.179 brought some conflicts. Have you compared with my merge for v4.4-rt? Not sure if I understand your worklfow correctly. It looks like you used for the rebase branches the upstream -rt patchset and merged the cip branch. Is this correct?

What I did for the v4.4-cip-rt and v4.19-cip-rt is following

- initial setup (only once):

took the latest cip release and applied the current/matching -rt patcheset

- regulare update:

$ cd v4.4-rt
$ git tag -l 'v4\.4\.*' --sort=v:refname | tail
$ git merge v4.4.120 [fixup conflicts]

# do some testing (this is on Linutronix -rt test infrastrucure)
$ git push lxcvs -f --follow-tag HEAD:stable-maintenance-4.4.y-rt

$ srt commit
$ srt tag

$ cd v4.4-rt-rebase
$ git rebase -i v4.4.120 [fixup conflicts]
$ srt commit
$ srt tag

# check if the -rt-rebase branch is identical to v4.4-rt
$ git diff v4.4-rt

$ srt create v4.4.115-rt130 v4.4.120-rt135
$ srt sign v4.4.115-rt130 v4.4.120-rt135
$ srt upload v4.4.115-rt130 v4.4.120-rt135
$ srt push v4.4.115-rt130 v4.4.120-rt135

# XXX push missing tags
$ git push origin v4.4.115-rt131 v4.4.116-rt132 v4.4.118-rt133 v4.4.119-rt134

$ srt announce v4.4.115-rt130 v4.4.120-rt135 > ../announce-rt
$ cat ../announce-rt | msmtp -t --

The srt tool is available here: https://github.com/igaw/stable-rt-tools
It a few lines around git to make the steps consist. It is based on Steven Rostedt workflow. Tom Zanussi (also -rt stable maintainer) and I am using the tool to maintain the -rt trees.

Trees are at kernel.org:

https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-cip.git/log/?h=v4.4.179-rt181-cip34-rebase
https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-cip.git/log/?h=v4.19.50-rt22-cip3-rebase

Basically untested. Could I ask for reviews and testing?
- git fetch pavel --tags
From git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-cip
! [rejected] v4.4.176-cip31 -> v4.4.176-cip31 (would clobber existing tag)
! [rejected] v4.4.176-cip31-rebase -> v4.4.176-cip31-rebase (would clobber existing tag)


Was v4.4.176-cip31 rebased?

- tag pattern used to be "v4.4.[0-9]+-cip[0-9]+-rt[0-9]+", it's now
"v4.4.[0-9]+-rt[0-9]+-cip[0-9]+".

- in the v4.4-rt is still a problem with f01f17d3705b ("mm, vmstat: make quiet_vmstat lighter"). It is needed to boot on x86_64 but it breaks on NVIDIA's boards, e.g. Jetson. Unfortunately, I don't have a NVIDIA board in my lab to figure out what is missing. So I suspect there is a still a problem hidden in the current v4.4-rt tree.

I know that full preemption does not work on x86-32. I sent
"PREEMPT_RT_FULL on x86-32 machine" mail to the lists
I haven't run the v4.4 tree in 32bit so far. I can try if I get it booting in my lab.

I don't know how to release useful non-rebasing trees. Is someone
using those?
Just like the regular -cip kernel, the -rt version's primary stable feed is merge-based. Rebasing only comes out of the fact that a second patch series is involved, but I doubt many folks use that feed as source. I don't, my colleagues neither (AFAIK).
If it helps, I am going to give a talk at Plubmers on how to maintain the -rt trees:


"""
Maintaining out of tree patches over the long term

The PREEMPT_RT patchset is the longest existing large patchset living outside the Linux kernel. Over the years, the realtime developers had to maintain several stable kernel versions of the patchset. This talk will present the lessons learned from this experience, including workflow, tooling and release management that has proven over time to scale. The workflow deals with upstream changes and changes to the patchset itself. Now that the PREEMPT_RT patchset is about the be merged upstream, we want to share our toolset and methods with others who may be able to benefit from our experience.

This talk is for people who want to maintain an external patchset with stable releases.
"""

Please sync with Daniel Wagner on the workflow options and also on 4.4-rt maintenance.
Hope I could already answer a few question. In summary, have a look at stable-rt-tools which is the workflow implemented into a python script.

Thanks,
Daniel


Re: lava very slow; it was ok earlier today

Chris Paterson
 

Hello Pavel,

From: Pavel Machek <pavel@...>
Sent: 27 June 2019 22:40


Hi!

I'm trying to get something to work on iwg20m, but ... something is
very slow.
That's slow indeed. I can only assume that the Internet line the lab is on at the Renesas office was having some issues.

Sorry for the inconvenience. It seems to be okay this morning.

Kind regards, Chris


https://lava.ciplatform.org/scheduler/job/1552

downloading
https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-
core/iwg20m/core-image-minimal-iwg20m.tar.gz
saving as
/var/lib/lava/dispatcher/tmp/1552/tftp-deploy-38u2x17d/nfsrootfs/core-
image-minimal-iwg20m.tar
total size: 29096711 (27MB)
Using gunzip to decompress gz
progress   0% (0MB)
...
progress  70% (19MB)
http-download timed out after 598 seconds
end: 1.3.1 http-download (duration 00:09:58) [common]

I can increase the timeouts, and then it works better, but... it
should not take 10 minutes to download 19MB. Any idea what is wrong
there?

Best regards,
                                                                      Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: [PATCH 4.4.y-cip] Add gitlab-ci.yaml

Chris Paterson
 

From: Jan Kiszka <jan.kiszka@...>
Sent: 28 June 2019 06:48

On 28.06.19 02:20, daniel.sangorrin@... wrote:
It seems that a lot of people have the same problem.
https://gitlab.com/gitlab-org/gitlab-ce/issues/15041
Maybe a combination of a CI-only repo and a hook that triggers a build on
changes in the external (and unchanged) source repo can do the trick.
Yes this is one solution, however you wouldn't get the pretty green ticks that show a commit has been verified.

Chris


Jan


-----Original Message-----
From: cip-dev-bounces@... <cip-dev-bounces@...
project.org> On Behalf Of Chris Paterson
Sent: Thursday, June 27, 2019 10:13 PM
To: cip-dev@...
Subject: [cip-dev] [PATCH 4.4.y-cip] Add gitlab-ci.yaml

This is configured to build and test for the following configuration:

1. ARCH: arm
CONFIGS: shmobile_defconfig
BOARDS: r8a7743-iwg20d

Build/test Docker containers and scripts are created by the
https://gitlab.com/cip-playground/linux-cip-ci repository.

Over time support will be added for all CIP supported architectures and
configurations. At the moment only simple boot tests are run. Real tests
will be added in the future. These changes should all all be handled in
the linux-cip-ci repository.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

In theory this file is only required in our GitLab repository. However if
we add it there the automatic mirroring from the kernel.org repository
will be broken.

I also tried the GitLab option to create a new repository for CI/CD
'only'. However this also has the exact same problem.

This means that the best/easiest approach will be to just add the
.gitlab-ci.yml file directly to the kernel.org repository. Most people can
ignore it.

There may well be some chrun in this file as linux-cip-ci improves, but
this is a good starting point.

.gitlab-ci.yml | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..4e949ac75b7b
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,27 @@
+variables:
+ GIT_STRATEGY: none
+ DOCKER_DRIVER: overlay2
+
+before_script:
+ - cd /opt/linux
+ - git fetch origin
+ - git checkout $CI_COMMIT_SHA
+
+build_arm_shmobile_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm shmobile_defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+run_tests:
+ stage: test
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:test-latest
+ when: always
+ before_script: []
+ script:
+ - /opt/submit_tests.sh
--
2.17.1

_______________________________________________
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
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH 4.4.y-cip] Add gitlab-ci.yaml

Jan Kiszka
 

On 28.06.19 02:20, daniel.sangorrin@... wrote:
It seems that a lot of people have the same problem.
https://gitlab.com/gitlab-org/gitlab-ce/issues/15041
Maybe a combination of a CI-only repo and a hook that triggers a build on changes in the external (and unchanged) source repo can do the trick.

Jan


-----Original Message-----
From: cip-dev-bounces@... <cip-dev-bounces@...> On Behalf Of Chris Paterson
Sent: Thursday, June 27, 2019 10:13 PM
To: cip-dev@...
Subject: [cip-dev] [PATCH 4.4.y-cip] Add gitlab-ci.yaml

This is configured to build and test for the following configuration:

1. ARCH: arm
CONFIGS: shmobile_defconfig
BOARDS: r8a7743-iwg20d

Build/test Docker containers and scripts are created by the
https://gitlab.com/cip-playground/linux-cip-ci repository.

Over time support will be added for all CIP supported architectures and
configurations. At the moment only simple boot tests are run. Real tests
will be added in the future. These changes should all all be handled in
the linux-cip-ci repository.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

In theory this file is only required in our GitLab repository. However if
we add it there the automatic mirroring from the kernel.org repository
will be broken.

I also tried the GitLab option to create a new repository for CI/CD
'only'. However this also has the exact same problem.

This means that the best/easiest approach will be to just add the
.gitlab-ci.yml file directly to the kernel.org repository. Most people can
ignore it.

There may well be some chrun in this file as linux-cip-ci improves, but
this is a good starting point.

.gitlab-ci.yml | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..4e949ac75b7b
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,27 @@
+variables:
+ GIT_STRATEGY: none
+ DOCKER_DRIVER: overlay2
+
+before_script:
+ - cd /opt/linux
+ - git fetch origin
+ - git checkout $CI_COMMIT_SHA
+
+build_arm_shmobile_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm shmobile_defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+run_tests:
+ stage: test
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:test-latest
+ when: always
+ before_script: []
+ script:
+ - /opt/submit_tests.sh
--
2.17.1

_______________________________________________
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
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH 4.4.y-cip] Add gitlab-ci.yaml

daniel.sangorrin@...
 

It seems that a lot of people have the same problem.
https://gitlab.com/gitlab-org/gitlab-ce/issues/15041

-----Original Message-----
From: cip-dev-bounces@... <cip-dev-bounces@...> On Behalf Of Chris Paterson
Sent: Thursday, June 27, 2019 10:13 PM
To: cip-dev@...
Subject: [cip-dev] [PATCH 4.4.y-cip] Add gitlab-ci.yaml

This is configured to build and test for the following configuration:

1. ARCH: arm
CONFIGS: shmobile_defconfig
BOARDS: r8a7743-iwg20d

Build/test Docker containers and scripts are created by the
https://gitlab.com/cip-playground/linux-cip-ci repository.

Over time support will be added for all CIP supported architectures and
configurations. At the moment only simple boot tests are run. Real tests
will be added in the future. These changes should all all be handled in
the linux-cip-ci repository.

Signed-off-by: Chris Paterson <chris.paterson2@...>
---

In theory this file is only required in our GitLab repository. However if
we add it there the automatic mirroring from the kernel.org repository
will be broken.

I also tried the GitLab option to create a new repository for CI/CD
'only'. However this also has the exact same problem.

This means that the best/easiest approach will be to just add the
.gitlab-ci.yml file directly to the kernel.org repository. Most people can
ignore it.

There may well be some chrun in this file as linux-cip-ci improves, but
this is a good starting point.

.gitlab-ci.yml | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..4e949ac75b7b
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,27 @@
+variables:
+ GIT_STRATEGY: none
+ DOCKER_DRIVER: overlay2
+
+before_script:
+ - cd /opt/linux
+ - git fetch origin
+ - git checkout $CI_COMMIT_SHA
+
+build_arm_shmobile_defconfig:
+ stage: build
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:build-latest
+ script:
+ - /opt/build_kernel.sh arm shmobile_defconfig
+ artifacts:
+ name: "$CI_JOB_NAME"
+ when: on_success
+ paths:
+ - output
+
+run_tests:
+ stage: test
+ image: registry.gitlab.com/cip-playground/linux-cip-ci:test-latest
+ when: always
+ before_script: []
+ script:
+ - /opt/submit_tests.sh
--
2.17.1

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


lava very slow; it was ok earlier today

Pavel Machek
 

Hi!

I'm trying to get something to work on iwg20m, but ... something is
very slow.

https://lava.ciplatform.org/scheduler/job/1552

downloading
https://s3-us-west-2.amazonaws.com/download.cip-project.org/cip-core/iwg20m/core-image-minimal-iwg20m.tar.gz
saving as
/var/lib/lava/dispatcher/tmp/1552/tftp-deploy-38u2x17d/nfsrootfs/core-image-minimal-iwg20m.tar
total size: 29096711 (27MB)
Using gunzip to decompress gz
progress 0% (0MB)
...
progress 70% (19MB)
http-download timed out after 598 seconds
end: 1.3.1 http-download (duration 00:09:58) [common]

I can increase the timeouts, and then it works better, but... it
should not take 10 minutes to download 19MB. Any idea what is wrong
there?

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

7601 - 7620 of 10158