From: Quentin Schulz <quentin.schulz@cherry.de>
To: Yoann Congal <yoann.congal@smile.fr>, docs@lists.yoctoproject.org
Subject: Re: [docs] [PATCH v2 1/4] migration/release-notes-5.1: document oeqa/selftest envvars change
Date: Wed, 2 Oct 2024 11:35:37 +0200 [thread overview]
Message-ID: <ba6aa464-764f-4cfa-b5d3-56df3af76dcf@cherry.de> (raw)
In-Reply-To: <3ca3c382-0c45-41e1-87a2-03fde24627b7@smile.fr>
Hi Yoann,
On 10/2/24 10:57 AM, Yoann Congal wrote:
>
>
> Le 01/10/2024 à 11:40, Quentin Schulz a écrit :
>> Hi Yoann,
>>
>> On 9/28/24 12:00 AM, Yoann Congal via lists.yoctoproject.org wrote:
>>> From: Yoann Congal <yoann.congal@smile.fr>
>>>
>>> This covers the Poky commit:
>>> 61186bc98a5 (oeqa/selftest: Only rewrite envvars paths that absolutely point to builddir, 2024-09-10)
>>>
>>> Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
>>> ---
>>> v1->v2: Reviews from Quentin Schulz:
>>> * environnement -> environment
>>> * oeqa/selftest now only rewrite*s*
>>> * Add exemples for the selftest change
>>> ---
>>> documentation/migration-guides/migration-5.1.rst | 15 +++++++++++++++
>>> .../migration-guides/release-notes-5.1.rst | 2 ++
>>> 2 files changed, 17 insertions(+)
>>>
>>> diff --git a/documentation/migration-guides/migration-5.1.rst b/documentation/migration-guides/migration-5.1.rst
>>> index b43fecc2d..4625ff0e1 100644
>>> --- a/documentation/migration-guides/migration-5.1.rst
>>> +++ b/documentation/migration-guides/migration-5.1.rst
>>> @@ -141,3 +141,18 @@ QEMU changes
>>> Miscellaneous changes
>>> ~~~~~~~~~~~~~~~~~~~~~
>>> +- oeqa/selftest now only rewrites environment variable paths that absolutely
>>> + point to builddir (i.e ``X=$BUILDDIR/conf/`` is still rewritten to point to
>>> + the selftest ``conf/`` directory but not ``Y=$BUILDDIR/../bitbake/`` which
>>> + still point to the ``bitbake/`` directory)
>>> +
>>> + For example (taken from autobuilder environment): ``BB_LOGCONFIG`` is an
>>
>> nit: could use :term:`BB_LOGCONFIG` here since we have it defined in the reference manual? We could probably even avoid explaining what it means here (not necessarily though).
>>
>>> + environment variable containing a path that configures bitbake logs. In
>>> + autobuilder, it is set as:
>>> + ``BB_LOGCONFIG="${BUILDDIR}/../bitbake/contrib/autobuilderlog.json"``.
>>> + Note the relative path starting from the build directory to outside of it.
>>> + This path is not changed by selftest anymore.
>>> +
>>> + Environment variables containing relative paths from tested build directory
>>> + to outside of the original build directory may need to be updated as they
>>> + won't be changed by selftest.
>>
>> selftest should be single-tick-quoted as defined as standard in the git repo, c.f. https://git.yoctoproject.org/yocto-docs/tree/documentation/standards.md
>>
>> This was done by Michael but he's not the maintainer anymore so I guess whoever replaces him may have a different opinion, in which case extending or replacing it would be most welcome, is that you Antonin?
>
>
>> On a side note,
> I've tried to make it clearer, I'll answer your questions inline maybe we'll find a better wording?
>
>> I still wouldn't really know which variables I need to look after
>
> That can be any environment variable containing the build directory path but relatively pointing to outside of the build dir (like $BUILD_DIR/../bitbake)
>
>> or what happens if I don't (is there an explicit error, are there side effects, if so, how do they show up?).
>
> It depends on how this variable is used.
>
> Ultimately, there was a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=15241 but the bug is more global than just BB_LOGCONFIG) and the workarounds that users may have been used are not needed anymore or broken.
>
Note: I don't want this discussion to prevent merging this patch in time
for Styhead release, we can always improve later.
Are those environment variables necessarily in the **shell** environment
or are we also talking about variables that could be defined in bitbake
conf files for example?
If they are shell environment variables, I believe (hope?) selftest/oeqa
can only access them if they are part of the BB_ENV_PASSTHROUGH and
BB_ENV_PASSTHROUGH_ADDITIONS variables? If that is the case, then we can
simply tell people to look for relative paths in all variables listed in
BB_ENV_PASSTHROUGH (via bitbake-getvar for example)?
Cheers,
Quentin
next prev parent reply other threads:[~2024-10-02 9:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-27 22:00 [PATCH v2 0/4] Document my team's commits for 5.1 Yoann Congal
2024-09-27 22:00 ` [PATCH v2 1/4] migration/release-notes-5.1: document oeqa/selftest envvars change Yoann Congal
2024-10-01 9:40 ` [docs] " Quentin Schulz
2024-10-01 10:09 ` Antonin Godard
2024-10-01 10:20 ` Quentin Schulz
2024-10-01 10:30 ` Antonin Godard
2024-10-02 8:57 ` Yoann Congal
2024-10-02 9:35 ` Quentin Schulz [this message]
2024-10-03 12:23 ` Improvement of the oeqa/selftest environment variable rewrite change Yoann Congal
2024-09-27 22:00 ` [PATCH v2 2/4] release-notes-5.1: document added python3-libarchive-c ptest Yoann Congal
2024-09-27 22:00 ` [PATCH v2 3/4] release-notes-5.1: document fixed _test_devtool_add_git_url test Yoann Congal
2024-09-27 22:00 ` [PATCH v2 4/4] release-notes-5.1: document spirv-tools reproducibility Yoann Congal
2024-10-01 9:41 ` [docs] " Quentin Schulz
2024-10-01 9:25 ` [docs] [PATCH v2 0/4] Document my team's commits for 5.1 Antonin Godard
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=ba6aa464-764f-4cfa-b5d3-56df3af76dcf@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=docs@lists.yoctoproject.org \
--cc=yoann.congal@smile.fr \
/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