From: "Maxim Yu. Osipov" <mosipov@ilbers.de>
To: Claudius Heine <claudius.heine.ext@siemens.com>,
isar-users@googlegroups.com
Cc: Claudius Heine <ch@denx.de>
Subject: Re: [PATCH v3 0/8] Cleanup rootfs creation
Date: Thu, 25 Apr 2019 12:33:34 +0300 [thread overview]
Message-ID: <7ff79c17-aa00-f18f-a6ad-4d0f16492eac@ilbers.de> (raw)
In-Reply-To: <6f41982e-7b01-d02c-7785-297061eb8cd4@siemens.com>
On 4/25/19 11:11 AM, Claudius Heine wrote:
> On 25/04/2019 10.39, Maxim Yu. Osipov wrote:
>> On 4/25/19 10:27 AM, Claudius Heine wrote:
>>> On 25/04/2019 10.07, Maxim Yu. Osipov wrote:
>>>> Hi Claudius,
>>>>
>>>> On 4/25/19 10:01 AM, Claudius Heine wrote:
>>>>> Hi Maxim,
>>>>>
>>>>> On 25/04/2019 09.55, Maxim Yu. Osipov wrote:
>>>>>> Hi Claudius,
>>>>>>
>>>>>> On 4/25/19 8:40 AM, Claudius Heine wrote:
>>>>>>> Hi Maxim,
>>>>>>>
>>>>>>> On 25/04/2019 08.03, Maxim Yu. Osipov wrote:
>>>>>>>>
>>>>>>>> Tried this series with fast ci build ("scripts/ci_build.sh -q -f"-
>>>>>>>> similar problems as before.
>>>>>>>> http://isar-build.org:8080/job/isar_mosipov_develop/98/console
>>>>>>>>
>>>>>>>> I observe the same errors on my host.
>>>>>>>
>>>>>>> So what do we do then when the CI is not reproducible?
>>>>>>>
>>>>>>> I am at a loss at how to investigate an error that does not
>>>>>>> happen when I build on isar-build or on my local host and only
>>>>>>> when you build it on isar-build or at your host.
>>>>>>
>>>>>> Do you mean that this problem is not reproduced when you run
>>>>>> "fast" CI build (ci_build.sh -q -f) on your PC?
>>>>>
>>>>> I don't do ci_builds locally, because that is the job of the CI. I
>>>>> just build one target that might be affected of the specific change.
>>>>
>>>> That's the reason why you can't reproduce the problem.
>>>
>>> Well I did build the multiconfig+target where the issue occured IIRC.
>
> I looked into the "fast" build now, and it cross-compiles
> "multiconfig:rpi-stretch:isar-image-base". Now I tried that and the
> build fails even on the current 'next' so the issue seems to be there.
No. "Fast" CI build (which in particular tests cross-compilation) in
'next' is OK - I've built it today morning when I tested your patch
"ubi-img/ubifs-img: change fatal error to skip recipe" and my patch
which includes SDK cretion test into "fast" build.
You may look at the log:
http://isar-build.org:8080/job/isar_mosipov_develop/97/console
>>>
>>>>
>>>>>>
>>>>>>> Any suggestions?
>>>>>>
>>>>>> Yes, sure. We will create an additional project for you on
>>>>>> isar-build.org to launch "fast" CI build.
>>>>>
>>>>> So you suggest that I should now test every patch I send two times,
>>>>> once for each different CI configuration manually?
>>>>
>>>> There is another option. I may reconfigure your current project to
>>>> fast build. Should I do that?
>>>
>>> I don't care. I would like to have my CI configured in a way that
>>> allows my patches to tested for upstream inclusion. If that is in a
>>> "fast", "slow" or "totally unnoteworthy" velocity does not matter for
>>> that. CI is an acceptability test and I want the strictest one. If I
>>> was mistaken that "fast" is less strict than "slow", then switch to
>>> "fast". If I now need to pass "fast" and "slow" for my patch to be
>>> acceptable, then I would suggest introducing a "abysmal slow" CI run
>>> that combines "slow" and "fast".
>>
>> I've just sent the CI tests procedure in separate email.
>
> That is not a CI test procedure. That is a test procedure for local
> testing, if someone wants to use the ci scripts to do so. I don't since
> my environment is different from what you have on your CI server.
>
>> The problem that if we include all the features into single CI run it
>> will takes hours to test single patch.
>
> Right. "abysmal slow". But in your 'CONTRIBUTERS' you state that
> everyone should do that anyway. Manually.
It's highly suggested but its' not a must.
Current iteration of patch series just proves that it's worth to run
these scripts if you want to avoid multiple patches versions iterations.
>
>>
>> Anyway I pointed you to the problem and the way how to reproduce it.
>> You wrote that you don't want to call CI locally. It's up to you - I
>> don't care too - if the problem is not fixed the patchset will not be
>> applied.
>
> Well I don't have the same environment as you on your CI server, so
> running scripts build for your CI server is not something I can do. That
> is not choice that is just how things are.
>
>> I didn't understood from your emotional passage what configuration you
>> prefer.
>
> Well CI testing should be done reproducible and transparent. If my
> branch on jenkins has a different configuration than some other branch
> there and now the invisible configuration of those branches changes like
> the weather, then this is not reproducible nor transparent.
>
> Having to explain the basics of what CI is, is pretty nerve wreaking and
> exhausting.
Thank you for explaining what CI is - I'm sorry to make you nervous and
exhausted.
>> I suggested two options
>>
>> 1) Add additional project for you for "fast" build. Yes. In such cases
>> you have to launch the tests in both projects but you will be sure that
>> integration will go more smoothly.
>
> Well the most acceptable way would be 3 branches. One for "fast", one
> for "slow" and one for "acceptance" (which combines slow and fast).
>
>>
>> 2) Reconfigure your existing project from "standard" to the "fast" one.
>>
>> It is up to you to decide how you want to test your patch set.
>
> No its not. It is up to you to test the patchset and decide if that
> should be merged or not. So contributors have to jump through those
> hoops in order for it to be merged reasonable fast.
And I decided to don't merge your patch set because tests were failed.
That's the only story.
Maxim.
> Claudius
>
>>
>> Greetings,
>> Maxim.
>>
>>
>>> Claudius
>>>
>>>>
>>>> Maxim.
>>>>
>>>>> Claudius
>>>>>
>>>>>>
>>>>>> Maxim.
>>>>>>
>>>>>>> Claudius
>>>>>>>
>>>>>>>>
>>>>>>>> Maxim.
>>>>>>>>
>>>>>>>> On 4/24/19 11:27 AM, claudius.heine.ext@siemens.com wrote:
>>>>>>>>> From: Claudius Heine <ch@denx.de>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I could not reproduce the raspberrypi issue Maxim found in his
>>>>>>>>> CI build:
>>>>>>>>> http://isar-build.org:8080/job/isar_mosipov_develop/91/consoleText
>>>>>>>>>
>>>>>>>>> This is my build log:
>>>>>>>>> http://isar-build.org:8080/job/isar_claudius_ilbers-ci/54/consoleText
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Only the module loading fails, which Maxim stated he will look
>>>>>>>>> into.
>>>>>>>>>
>>>>>>>>> This patchset uses still the 'old' style for
>>>>>>>>> refactoring/cleanup patchsets,
>>>>>>>>> until I automated the official patch submission process as
>>>>>>>>> documented by the
>>>>>>>>> CONTRIBUTERS policy.
>>>>>>>>>
>>>>>>>>> You can find the whole patchset in under this url:
>>>>>>>>>
>>>>>>>>> https://github.com/cmhe/isar/tree/ch/cleanup
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>> Claudius
>>>>>>>>>
>>>>>>>>> changes from v2:
>>>>>>>>> - replaced 'ROOTFS_ARCH' with 'HOST_ARCH' in sdkchroot.bb to
>>>>>>>>> avoid
>>>>>>>>> populate_sdk issue
>>>>>>>>>
>>>>>>>>> changes from v1:
>>>>>>>>> - fixed typo in commit message
>>>>>>>>>
>>>>>>>>> Claudius Heine (8):
>>>>>>>>> isar-boostrap-helper: move 'HOST_ARCH' and 'HOST_DISTRO' to
>>>>>>>>> base.bbclass
>>>>>>>>> move 'HOST_DISTRO_APT_SOURCES' from bootstrap-helper to
>>>>>>>>> isar-bootstrap
>>>>>>>>> buildchroot.bbclass: only cross build if HOST_ARCH !=
>>>>>>>>> DISTRO_ARCH
>>>>>>>>> isar-bootstrap/buildchroot/sdkchroot: refactor PF and WORKDIR
>>>>>>>>> bitbake.conf: remove unneeded and differently used variables
>>>>>>>>> image.bbclass: make IMAGE_ROOTFS overwritable
>>>>>>>>> bitbake.conf: set default QEMU_ARCH variables
>>>>>>>>> buildchroot/configscript: make creation of builder uid/gid
>>>>>>>>> idempotent
>>>>>>>>>
>>>>>>>>> meta/classes/base.bbclass | 9
>>>>>>>>> +++++++++
>>>>>>>>> meta/classes/buildchroot.bbclass | 2 +-
>>>>>>>>> meta/classes/image-sdk-extension.bbclass | 2 +-
>>>>>>>>> meta/classes/image.bbclass | 2 +-
>>>>>>>>> meta/classes/isar-bootstrap-helper.bbclass | 14
>>>>>>>>> --------------
>>>>>>>>> meta/conf/bitbake.conf | 13
>>>>>>>>> ++++++++-----
>>>>>>>>> .../isar-bootstrap/isar-bootstrap-host.bb | 11
>>>>>>>>> +++--------
>>>>>>>>> .../isar-bootstrap/isar-bootstrap-target.bb | 6 +-----
>>>>>>>>> .../recipes-core/isar-bootstrap/isar-bootstrap.inc | 1 +
>>>>>>>>> .../buildchroot/buildchroot-host.bb | 1 +
>>>>>>>>> meta/recipes-devtools/buildchroot/buildchroot.inc | 3 +--
>>>>>>>>> .../buildchroot/files/configscript.sh | 4 ++--
>>>>>>>>> meta/recipes-devtools/sdkchroot/sdkchroot.bb | 3 +--
>>>>>>>>> 13 files changed, 30 insertions(+), 41 deletions(-)
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov
next prev parent reply other threads:[~2019-04-25 9:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 9:27 claudius.heine.ext
2019-04-24 9:27 ` [PATCH v3 1/8] isar-boostrap-helper: move 'HOST_ARCH' and 'HOST_DISTRO' to base.bbclass claudius.heine.ext
2019-04-25 11:25 ` Claudius Heine
2019-04-24 9:27 ` [PATCH v3 2/8] move 'HOST_DISTRO_APT_SOURCES' from bootstrap-helper to isar-bootstrap claudius.heine.ext
2019-04-24 9:27 ` [PATCH v3 3/8] buildchroot.bbclass: only cross build if HOST_ARCH != DISTRO_ARCH claudius.heine.ext
2019-04-24 9:27 ` [PATCH v3 4/8] isar-bootstrap/buildchroot/sdkchroot: refactor PF and WORKDIR claudius.heine.ext
2019-04-24 9:27 ` [PATCH v3 5/8] bitbake.conf: remove unneeded and differently used variables claudius.heine.ext
2019-04-24 9:27 ` [PATCH v3 6/8] image.bbclass: make IMAGE_ROOTFS overwritable claudius.heine.ext
2019-04-24 9:27 ` [PATCH v3 7/8] bitbake.conf: set default QEMU_ARCH variables claudius.heine.ext
2019-04-24 9:27 ` [PATCH v3 8/8] buildchroot/configscript: make creation of builder uid/gid idempotent claudius.heine.ext
2019-04-25 6:03 ` [PATCH v3 0/8] Cleanup rootfs creation Maxim Yu. Osipov
2019-04-25 6:40 ` Claudius Heine
2019-04-25 7:55 ` Maxim Yu. Osipov
2019-04-25 8:01 ` Claudius Heine
2019-04-25 8:07 ` Maxim Yu. Osipov
2019-04-25 8:27 ` Claudius Heine
2019-04-25 8:39 ` Maxim Yu. Osipov
2019-04-25 9:11 ` Claudius Heine
2019-04-25 9:33 ` Maxim Yu. Osipov [this message]
2019-04-25 9:51 ` Baurzhan Ismagulov
2019-04-25 10:32 ` Baurzhan Ismagulov
2019-04-25 11:18 ` Claudius Heine
2019-04-25 11:22 ` Claudius Heine
2019-04-25 8:52 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ff79c17-aa00-f18f-a6ad-4d0f16492eac@ilbers.de \
--to=mosipov@ilbers.de \
--cc=ch@denx.de \
--cc=claudius.heine.ext@siemens.com \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox