Hi all,
I disagree with the proposed change, as this is unconditional, even
though the commit message claims otherwise.
It would be better to have it limited to qemuriscv as the commit message
proposes.
Fun fact: I can't find this message on the web interface of
yamllint requires pathspec module to be available
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/python/python3-yamllint_1.33.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
b/meta/recipes-devtools
to the same values that are used in bb.fetch.
Currently that would only add sha256sum to the created recipe,
which is the preferred choice over md5
Signed-off-by: Konrad Weihmann
---
scripts/lib/recipetool/create.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/lib/recipetool
FYI:
https://git.yoctoproject.org/poky/commit/meta/recipes-devtools/python?h=master-next=4641605c794db6648311b931fb3a36fe9e5dea56
breaks building python3-requests (as of version 2.28.2 in master).
> recipe-sysroot-native/usr/bin/python3-native/python3', '-m', 'pip',
, but it should have
been not deleted but just emptied
Signed-off-by: Konrad Weihmann
---
meta/lib/oeqa/__init__.py | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 meta/lib/oeqa/__init__.py
diff --git a/meta/lib/oeqa/__init__.py b/meta/lib/oeqa/__init__.py
new file mode 100644
since commit 482c493cf681121fb041f98066a42af14145ff9e:
valgrind: update to 3.20.0 (2022-11-03 07:46:47 +)
are available in the Git repository at:
https://github.com/witekio-kwe/poky spdx-fix
https://github.com/witekio-kwe/poky/tree/spdx-fix
Konrad Weihmann (1):
create-spdx: default
setup.py in latest release is broken after move to flit-core
was released by the project.
This broke the version detection in consuming libs like requests.
Remove the not needed egg.info removal as well
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/python/python3-idna_3.4.bb | 7
A general remark from my side about this patch is that this limitation
isn't mentioned in the documentation at all [1].
I would have been in favor of just dropping this piece of code, esp as
the check wasn't run for years now - but here we are with another
undocumented and breaking change (at
to python3-native/python3, not just to the
nativepython3 link to it. You can use 'create_wrapper' helper that was
written exactly for the purpose (see meta/ for examples).
Also, can the lookup in ~ be simply disabled at python3-native build time?
Alex
On Mon, 22 Aug 2022 at 21:57, Konrad Weihmann
by setting the ENABLE_USER_SITE flag globally.
This is the recommended way according to
https://peps.python.org/pep-0370/#implementation
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/python/python3_3.10.6.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools
-sysroot-native, leading to host/workspace contamination
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/python/python3/nativepython3 | 2 ++
meta/recipes-devtools/python/python3_3.10.6.bb | 9 -
2 files changed, 6 insertions(+), 5 deletions(-)
create mode 100644 meta/recipes
as nativepython3 is now a shell wrapper, prevent endless
recursion loops, by just calling python3 instead of nativepython3.
The interpreter setting will still have precedence over the plain
python binary called
Signed-off-by: Konrad Weihmann
---
meta/classes-recipe/python_pep517.bbclass | 2
different file mode bits (depending
on the current user's settings).
In a particular example
linux-fimware created /lib/firmware with 0600
while other-firmware-package created it with 0644
making the combination not installable by rpm backend
Signed-off-by: Konrad Weihmann
---
v2: - add ML link
different file mode bits (depending
on the current user's settings).
In a particular example
linux-fimware created /lib/firmware with 0600
while other-firmware-package created it with 0644
making the combination not installable by rpm backend
Signed-off-by: Konrad Weihmann
---
...01-Makefile-replace
by default git pulls in several code fragments not being licensed
under just GPL-2.0-only.
obstack and poll are licensed under GPL-2.0-or-later
reftable being BSD-3-Clause
sha1dc and inet_ntop being MIT
netmalloc being Bosst-1.0 aka BSL-1.0
regex being LGPL-2.1-or-later
Signed-off-by: Konrad
which has the same info as the in-file header used in before
Signed-off-by: Konrad Weihmann
---
v2:
- strip control codes at the end of the copying file
meta/recipes-core/ncurses/ncurses.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ncurses
in target and native variant a different set of vendored libraries
is pulled from the cmake sources.
Add those licenses and there texts
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/cmake/cmake-native_3.22.3.bb | 8
meta/recipes-devtools/cmake/cmake_3.22.3.bb| 7
which has the same info as the in-file header used in before
Signed-off-by: Konrad Weihmann
---
meta/recipes-core/ncurses/ncurses.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index
as described in src/pip/_vendor/README.rst pip ships plenty
of vendored copies of other python modules.
Correct the license of the resulting package and
reference all the vendor copy license files correctly
Signed-off-by: Konrad Weihmann
---
.../python/python3-pip_22.0.3.bb | 32
On 13.04.22 18:56, Jose Quaresma wrote:
Hi
Konrad Weihmann mailto:kweihm...@outlook.com>>
escreveu no dia quarta, 13/04/2022 à(s) 17:34:
by default git pulls in several code fragments not being licensed
under just GPL-2.0-only.
In fact obstack and poll are taken from glib,
netmalloc being Bosst-1.0 aka BSL-1.0
regex being LGPL-2.1-or-later
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/git/git_2.35.1.bb | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/git/git_2.35.1.bb
b/meta/recipes-devtools/git
depending on the actual PACKAGECONFIG some
internal vendor copies of libxml, libcroco and glib will
be used.
In the case of libxml this adds MIT to the license.
Reference the license statements based on the actual choosen
PACKAGECONFIG
Signed-off-by: Konrad Weihmann
---
meta/recipes-core
as COPYING clearly states that unicode data is baked into
the lib.
Add the license and reference the COPYING file for that
Signed-off-by: Konrad Weihmann
---
meta/recipes-extended/libidn/libidn2_2.3.2.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes
by default libsdl2 is build with code from src/video/yuv2rgb, which
is licensed under BSD-2-Clause.
Additional by default hidapi is build, which is licensed under
GPL3 | BSD-2-Clause | HIDAPI license, pick the least restrictive
and best matching BSD-2-Clause.
Signed-off-by: Konrad Weihmann
If libcap is compiled with pam in PACKAGECONFIG
one additional license text becomes effective,
add that as a conditional
Signed-off-by: Konrad Weihmann
---
v2:
- use spaces instead of tabs
- simplify by using bb.utils.contains
meta/recipes-support/libcap/libcap_2.63.bb | 6 +-
1 file
add the Kconfiglib license, as this was missing in before.
Add MIT identifier to LICENSE
Signed-off-by: Konrad Weihmann
---
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/kern-tools/kern
add COPYINGv3 license text to LIC_FILES_CHKSUM
Signed-off-by: Konrad Weihmann
---
meta/recipes-support/gmp/gmp_6.2.1.bb | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-support/gmp/gmp_6.2.1.bb
b/meta/recipes-support/gmp/gmp_6.2.1.bb
index 72fbf4eefe
to LIC_FILES_CHKSUM.
Format the list for better readability.
Remove useless line continuation from SRC_URI
Signed-off-by: Konrad Weihmann
---
meta/recipes-support/itstool/itstool_2.0.7.bb | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-support/itstool
If libcap is compiled with pam in PACKAGECONFIG
additional one additional license text becomes effective,
add that as a conditional
Signed-off-by: Konrad Weihmann
---
meta/recipes-support/libcap/libcap_2.63.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes
On 21.03.22 14:43, Ross Burton wrote:
On Thu, 3 Mar 2022 at 11:43, Konrad Weihmann wrote:
After scrolling through the log that I can get from a github pipeline
(sorry no runner log available) - I noticed
2022-03-03T05:39:23.2334189Z WARNING: cve-update-db-native-1.0-r0
do_fetch: Failed
On 10.03.22 19:25, Ross Burton wrote:
On Thu, 10 Mar 2022 at 17:36, Konrad Weihmann <mailto:kweihm...@outlook.com>> wrote:
Sorry to say that - but to me (even though it's more work) pip seems to
be the better option - the proposed tool is ~8 months old and not part
Sorry to say that - but to me (even though it's more work) pip seems to
be the better option - the proposed tool is ~8 months old and not part
of pypa community as it seems - so in comparison to pip this could not
be labeled "battle proven".
Especially as the second patch of the series
On 10.03.22 12:40, Ross Burton wrote:
Several recipes are duplicating the same bootstrap logic for installing
a wheel without using any tools. Add an implementation to
pip_install_wheel to centralise the code, and remove the duplicated code
from the following recipes:
- python3-flit-core
-
On 09.03.22 16:53, Ross Burton wrote:
On Wed, 9 Mar 2022 at 15:47, Konrad Weihmann wrote:
Can we, for the very unlikely case that do have more than one wheel in
this dir, bbfatal out here as well - otherwise I'm worried that this
will never get noticed
I'm undecided
On 09.03.22 16:02, Ross Burton wrote:
Now that the build systems that use pip_install_wheel are all building
their wheel into a directory that we knew was empty before, we can just
install *.whl and not need to know the precise names.
By design a pyproject.toml will always build a single
assignment shouldn't
be touched - but that could be just my mind
Ross
On Mon, 7 Mar 2022 at 20:06, Konrad Weihmann <mailto:kweihm...@outlook.com>> wrote:
On 07.03.22 20:42, Ross Burton wrote:
> If we expect users to extend this we should use =, as otherwise a
recipe
On 07.03.22 20:42, Ross Burton wrote:
If we expect users to extend this we should use =, as otherwise a recipe
that does += will replace the default value.
Signed-off-by: Ross Burton
---
meta/classes/pip_install_wheel.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 07.03.22 10:45, Richard Purdie wrote:
On Mon, 2022-03-07 at 08:36 +0100, Konrad Weihmann wrote:
On 04.03.22 00:46, Richard Purdie wrote:
On Thu, 2022-03-03 at 15:28 -0800, Tim Orling wrote:
On Thu, Mar 3, 2022 at 9:16 AM Richard Purdie
wrote:
On Thu, 2022-03-03 at 17:14 +, Ross
On 04.03.22 00:46, Richard Purdie wrote:
On Thu, 2022-03-03 at 15:28 -0800, Tim Orling wrote:
On Thu, Mar 3, 2022 at 9:16 AM Richard Purdie
wrote:
On Thu, 2022-03-03 at 17:14 +, Ross Burton wrote:
On Thu, 3 Mar 2022 at 16:34, Richard Purdie
wrote:
This removes a further 1600 files
.bb:do_populate_sysroot
resolve this by removing python3 from DEPENDS.
The correct dependencies are already injected by
setuptools-base class
Signed-off-by: Konrad Weihmann
---
meta/classes/setuptools_build_meta.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes
On 4 Mar 2022 21:14, Khem Raj wrote:On Fri, Mar 4, 2022 at 11:20 AM Konrad Weihmann wrote:
>
> If it's about meta-python why can't be placed there? I don't follow the argument that some edge case stuff outside of core requires the project to have additional (as of now not time l
If it's about meta-python why can't be placed there? I don't follow the argument that some edge case stuff outside of core requires the project to have additional (as of now not time limited) maintenance effort - if there would be a clear plan to remove that before kirkstone release I might agree,
On 04.03.22 14:13, Ross Burton wrote:
On Fri, 4 Mar 2022 at 12:44, Konrad Weihmann wrote:
For me that would be a candidate to be added to meta-python, or are
there any core recipes that currently break because of the new behavior?
This is restoring existing behaviour, so I believe
For me that would be a candidate to be added to meta-python, or are
there any core recipes that currently break because of the new behavior?
Furthermore the variables names are the same, so if people accidentally
(or due to complex injection trees/classes/distro settings/whatever have
new
On 03.03.22 18:11, Konrad Weihmann wrote:
On 03.03.22 17:34, Richard Purdie wrote:
This removes a further 1600 files from sstate handling and lets python
create the ones it wants at runtime which is likely much better overall
for performance.
Signed-off-by: Richard Purdie
---
meta
On 03.03.22 17:34, Richard Purdie wrote:
This removes a further 1600 files from sstate handling and lets python
create the ones it wants at runtime which is likely much better overall
for performance.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/python/python3_3.10.2.bb | 7
!
Can you share the full bitbake log from that run? I'd like to see what
jobs are running in parallel.
Ross
On Thu, 3 Mar 2022 at 11:10, Konrad Weihmann wrote:
Single from scratch build of core-image-minimal
On 03.03.22 12:07, Ross Burton wrote:
What's the scenario where this is happening
Single from scratch build of core-image-minimal
On 03.03.22 12:07, Ross Burton wrote:
What's the scenario where this is happening? Multiple build
directories using the same DL_DIR? Or was this a single build?
Ross
On Thu, 3 Mar 2022 at 08:10, Konrad Weihmann wrote:
Sadly I encountered
Sadly I encountered this here last night
NOTE: recipe cve-update-db-native-1.0-r0: task do_cve_check: Started
ERROR: cve-update-db-native-1.0-r0 do_cve_check: Error executing a
python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this
On 03.03.22 00:05, Richard Purdie wrote:
On Wed, 2022-03-02 at 21:55 +0100, Konrad Weihmann wrote:
An interesting behavior struck me once more after a long long time.
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 584
An interesting behavior struck me once more after a long long time.
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 584,
function: extend_recipe_sysroot
0580:if "/bin/" in l or "/sbin/" in l:
0581:
On 02.03.22 20:04, Khem Raj wrote:
On Wed, Mar 2, 2022 at 11:01 AM Konrad Weihmann wrote:
On 02.03.22 19:45, Khem Raj wrote:
v4 is definitely better than v3, I see one case it could address as well e.g.
python3-pymetno produces PyMetno-0.9.0-py3-none-any.whl, so if
guessing code could
renaming to a
fully lower case filename - any thoughts?
On Wed, Mar 2, 2022 at 1:21 AM Konrad Weihmann wrote:
v4 is out.
I tried to make it work with the dist-dir/bdist-dir option, but
apparently this isn't respected by setuptools in all of the tested recipes.
That's why I went wit
python recipes, all the python recipes in
my layers and a reasonable subset from meta-oe
On 02.03.22 09:06, Konrad Weihmann wrote:
My bad - one of the brackets in the name guessing slipped...
Will send a v4 soon
On 02.03.22 06:20, Khem Raj wrote:
this is causing 100+ packages to fail see
https
-by: Konrad Weihmann
---
v4: restructure name guessing to make wrongly placed brackets
being spottable more easily.
fix wrongly placed bracket to make name guessing work again
with pypi_package settings.
remove compile:prepend and use setuptools:do_compile cleandirs
option (see
My bad - one of the brackets in the name guessing slipped...
Will send a v4 soon
On 02.03.22 06:20, Khem Raj wrote:
this is causing 100+ packages to fail see
https://errors.yoctoproject.org/Errors/Build/142116/
I suggest to include meta-python for wider testing of such changes.
On Tue, Mar
).
recipes like python3-smbus run in a subfolder of the
workspace and were failing in before this adjustment
Signed-off-by: Konrad Weihmann
---
v3: remove in prepend to compile, not in install for obvious reasons
v2: fix python3 prefix string
meta/classes/pip_install_wheel.bbclass | 12
).
recipes like python3-smbus run in a subfolder of the
workspace and were failing in before this adjustment
Signed-off-by: Konrad Weihmann
---
v2: fix type in python3 prefix replacement
meta/classes/pip_install_wheel.bbclass | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
).
recipes like python3-smbus run in a subfolder of the
workspace and were failing in before this adjustment
Signed-off-by: Konrad Weihmann
---
meta/classes/pip_install_wheel.bbclass | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/classes/pip_install_wheel.bbclass
Some more observations when using the current state of the pip/wheels
patch series (from today's master)
- when using recipes that inherit setuptools (but not pypi) and do have
a "python3-..." prefix in the recipe name - the name guessing fails. IMO
it would be best to strip the "python3-"
On 25.02.22 05:03, Tim Orling wrote:
From: Tim Orling
Rather than only use PYPI_PACKAGE as a guess, fall back on PN for cases
where a recipe does not inherit pypi.
Wheels can only have alphanumeric characters in the 'distribution'
name [1]. Any other characters are replaced with an
On 25.02.22 14:16, Richard Purdie wrote:
On Thu, 2022-02-24 at 16:52 +0100, Konrad Weihmann wrote:
I got a kind of general question about this patch series and all the
followups: is this still considered to go into the next release?
It is still being considered, yes.
I'm a bit worried
I got a kind of general question about this patch series and all the
followups: is this still considered to go into the next release?
I'm a bit worried about the fallout of this pretty invasive change -
even though I see that at some point it needs to be done.
My understanding is that the
On 23.02.22 16:59, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier
Move the systemd shared library (libsystemd-shared.so) into its own
package to prevent a runtime dependency from udev package to systemd
package and thereby to a second init manager.
Signed-off-by: Stefan
me
Signed-off-by: Konrad Weihmann
---
This patch should be tested by users that run cve-check on a regular
on hosts with as much as possible cores, before merging.
In local testing I haven't found any issues on a world build,
but as mentioned in the previous patch the issue is kind of hard to
rep
On 22.02.22 18:50, Ross Burton wrote:
On Tue, 22 Feb 2022 at 17:01, Konrad Weihmann wrote:
This is somehow expected from my side tbh - as the lock file disables
any kind of parallelism - so just one instance of cve-check-task can run
at a time.
One thing that came to my mind is to move
On 22.02.22 16:50, Ralph Siemsen wrote:
Hi Konrad,
On Fri, Jan 7, 2022 at 4:59 AM Konrad Weihmann <mailto:kweihm...@outlook.com>> wrote:
On 07.01.22 10:48, Konrad Weihmann wrote:
> this should prevent running into the very rare error
> sqlite3.Operationa
This patch should be merged without this fix
https://git.yoctoproject.org/poky/commit/?id=89004bc2480808576582001460e37d98143bf9a3
On 21.02.22 15:14, Steve Sakoman wrote:
From: Alexander Kanavin
In particular libffi was missing from native, which
led to linking with host libffi instead.
previously used mipsarchr6:append created an empty set for
EXTRA_OECONF and then appended --disable-assembly
while it should be just added to the existing var value.
Without this patch gmp will be configured without
--enable-cxx=detect for mipsarchr6 targets
Signed-off-by: Konrad Weihmann
scope should be appended only the correct override
is append:class-target
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/ruby/ruby.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/ruby/ruby.inc
b/meta/recipes-devtools/ruby/ruby.inc
index
On 08.02.22 16:50, Saul Wold wrote:
>
>
> On 2/8/22 07:37, Konrad Weihmann wrote:
>> On 08.02.22 16:02, Saul Wold wrote:
>>> This patch will read the begining of source files and try to find
>>> the SPDX-License-Identifier to populate the licenseInfoInFil
On 08.02.22 16:02, Saul Wold wrote:
> This patch will read the begining of source files and try to find
> the SPDX-License-Identifier to populate the licenseInfoInFiles
> field for each source file. This does not populate licenseConcluded
> at this time, nor rolls it up to package level.
>
> We
My understanding is to add
--nonet
to XMLLINT_FLAGS = --noblanks --noout --xinclude --postvalid --noent
in docs/Makefile.in
and we should be good - haven't tried it yet but it should do the trick
On 13.01.22 18:39, Alexander Kanavin wrote:
Why wasn't this exposed by AB testing? And can there
That needs to go to the openembedded-de...@list.openembedded.org as
nodejs isn't part of core
On 11.01.22 17:23, Nisha Parrakat wrote:
Signed-off-by: Nisha Parrakat
---
meta-oe/recipes-devtools/nodejs/nodejs_16.11.1.bb | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
On 10.01.22 21:33, Peter Kjellerstedt wrote:
-Original Message-
From: Richard Purdie
Sent: den 10 januari 2022 16:44
To: Peter Kjellerstedt ; openembedded-
c...@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] rootfs-postcommands.bbclass: Change the
default.target location
On
On 08.01.22 16:13, Richard Purdie wrote:
On Sat, 2022-01-08 at 07:10 -0800, Matt Madison wrote:
On Sat, Jan 8, 2022 at 6:34 AM Richard Purdie
wrote:
On Fri, 2022-01-07 at 06:44 -0800, Matt Madison wrote:
On Fri, Jan 7, 2022 at 4:56 AM Richard Purdie
wrote:
On Fri, 2022-01-07 at 12:51
On 07.01.22 10:48, Konrad Weihmann wrote:
this should prevent running into the very rare error
sqlite3.OperationalError: attempt to write a readonly database
It's also possible that check_same_thread (that defaults to True ) in
the sqlite3.connect causes this (see
https://docs.python.org/3
at a time, by reusing
the already in place CVE_CHECK_DB_FILE_LOCK
YOCTO #14110
Signed-off-by: Konrad Weihmann
---
meta/classes/cve-check.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 70d1988a70..6c04ff9f09 100644
On 27.12.21 13:54, Stefan Herbrechtsmeier wrote:
Hi Konrad,
Am 25.12.21 um 21:43 schrieb Konrad Weihmann:
What I so far don't really get is why increase in parsing time is such
a big deal.
I admit when we're talking about npm it's some kind of a drastic
increase in recipes one would have
elsewhere.
So one could add consumers to core or push the code to where the "real
action" is (meta-virt for instance comes to my mind)
On 25.12.21 21:43, Konrad Weihmann wrote:
What I so far don't really get is why increase in parsing time is such a
big deal.
I admit when we're tal
On 25.12.21 20:32, Stefan Herbrechtsmeier wrote:
Isn't the circular dependencies problem mainly a problem of the native
packages? In many cases the dependency only exists at compile time of
the main project and not at compile time of the dependency itself. In
case of a native package all
What I so far don't really get is why increase in parsing time is such a
big deal.
I admit when we're talking about npm it's some kind of a drastic
increase in recipes one would have to maintain, just because some random
project decides to use a trillion dependencies instead of writing two or
I had a look at the failures and most of them are fairly easy to fix -
all but the go recipes like influxdb.
I'm not sure how to deal with that, so there aren't that many options here.
Either
- inject all the needed with a fixed revision, but that would prevent
devtool from catching updates
On 23.12.21 15:52, Andreas Müller wrote:
On Thu, Dec 23, 2021 at 2:19 PM Konrad Weihmann wrote:
On 23.12.21 14:11, Richard Purdie wrote:
On Thu, 2021-12-23 at 12:31 +0100, Konrad Weihmann wrote:
On 23.12.21 11:49, Peter Kjellerstedt wrote:
-Original Message-
From: openembedded
On 23.12.21 14:11, Richard Purdie wrote:
On Thu, 2021-12-23 at 12:31 +0100, Konrad Weihmann wrote:
On 23.12.21 11:49, Peter Kjellerstedt wrote:
-Original Message-
From: openembedded-core@lists.openembedded.org
On Behalf Of Richard Purdie
Sent: den 23 december 2021 00:21
On 23.12.21 11:49, Peter Kjellerstedt wrote:
-Original Message-
From: openembedded-core@lists.openembedded.org
On Behalf Of Richard Purdie
Sent: den 23 december 2021 00:21
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] base/patch: Disable network for
On 21.12.21 14:02, Ernst Sjöstrand wrote:
Dropbear shares a lot of code with other SSH implementations, so this is
a port of CVE-2018-20685 to dropbear.
Reference:
https://github.com/mkj/dropbear/commit/8f8a3dff705fad774a10864a2e3dbcfa9779ceff
Signed-off-by: Ernst Sjöstrand
This is
:47:04 +)
are available in the Git repository at:
git://github.com/priv-kweihmann/poky inapp-add-min
https://github.com/priv-kweihmann/poky/tree/inapp-add-min
Konrad Weihmann (32):
connman: fix patch Inappropriate
glib: fix patch Inappropriate
ldconfig: fix patch Inappropriate
On 16.12.21 15:54, Richard Purdie wrote:
On Thu, 2021-12-16 at 13:26 +0100, Konrad Weihmann wrote:
if a patch uses Upstream-Status: Inappropriate it should provide a machine
readable reasoning in square brackets.
According to latest wiki entry that would be
not author
native
licensing
On 16.12.21 15:41, Richard Purdie wrote:
On Wed, 2021-12-15 at 13:12 +0100, Konrad Weihmann wrote:
so one can get the layer name from a filepath
Signed-off-by: Konrad Weihmann
---
v2: order by path length to correctly map nested layer
meta/lib/oe/recipeutils.py | 11 ++-
1 file
-Status
Can be skipped with newly added patch-metadata key via INSANE_SKIP
Signed-off-by: Konrad Weihmann
---
v2: add possibility to skip with patch-metadata in INSANE_SKIP
meta/classes/insane.bbclass | 25 +
1 file changed, 25 insertions(+)
diff --git a/meta/classes
so one can get the layer name from a filepath
Signed-off-by: Konrad Weihmann
---
v2: order by path length to correctly map nested layer
meta/lib/oe/recipeutils.py | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe
into the task hash
On 15.12.21 11:03, Konrad Weihmann wrote:
instead of hard coding /meta/ into a skip condition introduce a
variable called QA_PATCH_CHECK_LAYER containing a space
separated list of layer names to perform the upstrem-status check
against.
as this will add BBFILE_PATTERN_* and therefore
so one can get the layer name from a filepath
Signed-off-by: Konrad Weihmann
---
meta/lib/oe/recipeutils.py | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index a0c6974f04..a0e8840c8f 100644
--- a/meta/lib/oe
to exclude do_qa_patch function from
task hashing.
As it is a postfunc it should run anyway, once do_patch needs to rerun
Signed-off-by: Konrad Weihmann
---
meta/classes/insane.bbclass | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta
On 15.12.21 08:16, Yongxin Liu wrote:
Slim Bootloader is an open-source boot firmware running on Intel x86
architecture.
Currently it supports qemu, apl(Apollo Lake), cfl(Coffee Lake),
cml(Comet Lake), tgl(Tiger Lake), and ehl(Elkhart Lake). You can set
"SLIMBOOT_TARGET" in .bb file or
pretty
automated, fancy stats, that will really provide some insights.
If we don't, we might end up in defining more and more new ids for
different things already covered by the current approach.
Alex
On Tue, 14 Dec 2021 at 19:48, Konrad Weihmann <mailto:kweihm...@outlook.com>&
On 14.12.21 19:38, Bruce Ashfield wrote:
On Tue, Dec 14, 2021 at 1:05 PM Konrad Weihmann wrote:
[snip]
meta/recipes-support/vte/vte/0001-Makefile.docs-correctly-substitute-gtkdoc-qemu-wrapp.patch:
6: Upstream-Status: Inappropriate [oe-core specific]
or are simply ignoring it at all
of worms, but either we drop the
reasoning from Inappropriate in the patch guideline completely or we
need to fix that in core (I guess in other layers it is even worse :) )
Any thoughts?
On 14.12.21 18:53, Konrad Weihmann wrote:
if a patch uses Upstream-Status: Inappropriate it should provide
-Status
Signed-off-by: Konrad Weihmann
---
meta/classes/insane.bbclass | 20
1 file changed, 20 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 240f3aad62..da26f4662c 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes
1 - 100 of 295 matches
Mail list logo
