Hi All,
QA for yocto-4.3.rc2 is completed. This is the full report for this release:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
=== Summary
No high milestone defects.
No new issue found.
Thanks,
Jing Hui
>
From: Lee Chee Yang
Signed-off-by: Lee Chee Yang
---
meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
b/meta/recipes-kernel/kexec/kexec-tools_2.0.20.bb
index 871b36440f..206c6ccae7 100644
---
On Wed, Oct 25, 2023 at 6:37 PM William A. Kennington III via
lists.openembedded.org wrote:
>
> The hooks are pulled from the impure environment and are often broken in
> our environments. There is no reason to add extra metadata or verify the
> commit message as its arbitrary to turn the tarball
The hooks are pulled from the impure environment and are often broken in
our environments. There is no reason to add extra metadata or verify the
commit message as its arbitrary to turn the tarball into a git repo.
Signed-off-by: William A. Kennington III
---
On Tue, 2023-10-24 at 19:17 -0400, Bruce Ashfield wrote:
> On Tue, Oct 24, 2023 at 6:07 PM Khem Raj wrote:
> >
> > os.environ does not pass this down to runstrip() function and in
> > strip_execs() its using STRIP bitbake variable to find the strip utility
> > to use. Since there might be a
Since we are skipping the merge test, two of the selftests now report
SKIP instead of XPASS/XFAIL as expected. Adjust the two files to have
the right endings for XSKIP, and add the category so that it can be used
for more extensive testing in the future.
Signed-off-by: Trevor Gamblin
---
Le mer. 25 oct. 2023 à 17:01, Luca Ceresoli
a écrit :
>
> Hello Julien,
>
> On Tue, 24 Oct 2023 16:17:54 +0200
> "Julien Stephan" wrote:
>
> > Signed-off-by: Julien Stephan
> > ---
> > meta/lib/oeqa/selftest/cases/devtool.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
Signed-off-by: Julien Stephan
---
meta/lib/oeqa/selftest/cases/devtool.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/devtool.py
b/meta/lib/oeqa/selftest/cases/devtool.py
index c36b1efa78b..b5c488be8e8 100644
---
if user run devtool selftests with a local workspacelayer
the tests fail with various error such as:
- devtool.DevtoolAddTests.test_devtool_add just hangs
- devtool.DevtoolModifyTests.* fail with the following error:
ERROR: Found duplicated BBFILE_COLLECTIONS 'workspacelayer', check
Add 3 tests to check the creation of PEP-517 project using the 3
backends supported by bitbake:
- setuptools.build_meta
- poetry.core.masonry.api
- flit_core.buildapi
Theses tests requires the tomllib python module, so skip theses tests
if module is not present. tomllib module is part of
Le mer. 25 oct. 2023 à 16:11, Richard Purdie
a écrit :
>
> On Tue, 2023-10-24 at 16:40 +0200, Julien Stephan wrote:
> > Hello all,
> >
> > This series adds basic support for PEP-517 in recipetool/devtool, plus somes
> > others fixes.
> >
> > Recipetool/devtool selftest passed locally
> >
> >
Add basic support for PEP517 [1] for the 3 following backends that are
supported by bitbake:
- setuptools.build_meta
- poetry.core.masonry.api
- flit_core.buildapi
If a pyproject.toml file is found, use it to create the recipe,
otherwise fallback to the old setup.py method.
Some projects
Hello all,
This series adds basic support for PEP-517 in recipetool/devtool, plus somes
others fixes.
Recipetool/devtool selftest passed locally
Missing features:
- extra or optionnal dependencies are not handled
- version number for dependencies are not handled (issue already present
for the
License field of setup is not always standardized, so we usually use the
classifier to determine the correct license format to use in the recipe.
A warning note is added above the LICENSE field of the create recipe
in case a license is provided in setup. But when the plugin is called,
"LICENSE ="
In order to prepare the support for pyproject.toml (PEP517 [1]) enabled
projects, refactor the code and move setup.py specific code into a
specific class in order to allow sharing the PythonRecipeHandler class
No functionnal changes expected
[1]: https://peps.python.org/pep-0517/#source-tree
By convention, all python recipes start with "python3-" so update
create_buildsys_python to do this
This rule doesn't apply for packages already starting with "python"
Update recipetool's selftest accordingly
Signed-off-by: Julien Stephan
---
meta/lib/oeqa/selftest/cases/recipetool.py |
Hello Julien,
On Tue, 24 Oct 2023 16:17:54 +0200
"Julien Stephan" wrote:
> Signed-off-by: Julien Stephan
> ---
> meta/lib/oeqa/selftest/cases/devtool.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/lib/oeqa/selftest/cases/devtool.py
>
Check that the maximum line length of the testresult file is less than
220 characters, to help guard against malicious changes being sent in
email responses. If any line exceeds this length, replace the normal
testresults used in the response with a line stating that tests failed,
but the results
On Tue, 2023-10-24 at 16:40 +0200, Julien Stephan wrote:
> Hello all,
>
> This series adds basic support for PEP-517 in recipetool/devtool, plus somes
> others fixes.
>
> Recipetool/devtool selftest passed locally
>
> Missing features:
> - extra or optionnal dependencies are not handled
> -
Hello Marko,
I think that we will need to go back to the drawing board and have a
look what we want to report from the CVE check.
I'm not totally happy with the solution proposed here, because it is
adding high-level states. However, it is a step
forward to be able to map our status to VEX. In the
Hello Marta,
Major reason why we introduced CVE_STATUS was exactly to avoid patch like this.
There were ideas to introduce 5 or 10 or 15 different statuses and we decided
to keep 3 and introduce “sub-statuses”.
These sub-statuses are listed in cve reports, too.
Currently we have three main
Hello Andrej,
This patch is splitting the Patched state, not the ignore one. This is not
incorrect CPE or anything else.
Currently Patched means one of two situations: either this issue has never
affected the code base (example: we have version 1.0, issue was introduced
in 2.0 and fixed in 2.1),
- Add the recipe to the RM_WORK_EXCLUDE
With rm_work active, external module signing throws an error:
scripts/sign-file: error while loading shared libraries: libcrypto.so.3: can
not open shared object file: No such file or directory
Preserve libraries that sign-file script needs during runtime.
Hi Marta,
That's fine, as I said we designed the "ignore" with status
"cpe-incorrect" or "ignored" exactly for those purposes. Extending the
option with "not affected" doesn't make any sense.
You have to set the status to "why is not affected" = "ignored". Which
completely covers the
On Wed, 25 Oct 2023 at 10:47, qi...@fujitsu.com wrote:
> If you can do the cairo update to 1.18.0 first, I would really appreciate
> that.
>
> I'm trying to do the cairo update.
> Which images and tests should be check?
There is no definite and specific answer to this, but a few things you
Hi Andrej,
This is more complex. "Not affected" is also an issue that isn't present in the
code - like when we have a version that has never had the vulnerability.
Those are also currently 'Patched' in cve-check.
This work is in sync with what VEX is doing, is it the use-case
Matsanaga-Shinji?
Hi，Alex
>
> If you can do the cairo update to 1.18.0 first, I would really appreciate
> that.
I'm trying to do the cairo update.
Which images and tests should be check?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189671):
Hi all,
Do we really need a new "not_affected" state? I guess the ignore state
is exactly designed for those purposes.
Regards,
Andrej
On 25.10.2023 07:13, Matsunaga-Shinji wrote:
CVEs that are currently considered "Patched" are classified into the following
3 statuses:
1. "Patched" -
28 matches
Mail list logo
