if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testexport fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
(From OE-Core rev: 0c1d098e6dd08fa3a5aafca656457ac6badcef89)
Signed-off-by: Konrad Weihmann
Signed-off-by: Richard
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testimage fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
(From OE-Core rev: c7a4e7e294992acc589c62adcaf6cd32659f2f9b)
Signed-off-by: Konrad Weihmann
Signed-off-by: Richard
devices in case
the lock can't be acquired up to 5 times.
If no tap device can be locked it fails in the existing
error handling
(From OE-Core rev: 23876576d054ebbab9b02c0012782aa56feda123)
Signed-off-by: Konrad Weihmann
Signed-off-by: Richard Purdie
---
scripts/runqemu
Hi,
could you please backport the following commits to scarthgap and kirkstone
runqemu: keep generating tap devices --
https://git.yoctoproject.org/poky/commit/?id=c9a40069623b95e8300fead4838de9edccb8
testimage: fallback for empty IMAGE_LINK_NAME --
https://git.yoctoproject.org/poky/commi
the error handling should be done on the return code by
the calling function, so creating an error within the function
does not make that much sense.
Signed-off-by: Konrad Weihmann
---
scripts/runqemu | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/scripts/runqemu b
devices in case
the lock can't be acquired up to 5 times.
If no tap device can be locked it fails in the existing
error handling
Signed-off-by: Konrad Weihmann
---
scripts/runqemu | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/scripts/runqemu b/sc
Signed-off-by: Konrad Weihmann
---
scripts/runqemu | 1 -
1 file changed, 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index cdbb625505..14eb939b3e 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1192,7 +1192,6 @@ to your build configuration.
raise
On 05.09.24 11:56, Richard Purdie wrote:
On Wed, 2024-09-04 at 12:21 +, Konrad Weihmann via lists.openembedded.org
wrote:
in case of running two or more runqemu instances in parallel
with no previously setup tap devices, the following happens:
instance A probes for tap devices, but
exclusive file (blocking) lock, so only a single instance can
perform the non-atomic changes.
Signed-off-by: Konrad Weihmann
---
scripts/runqemu | 10 ++
1 file changed, 10 insertions(+)
diff --git a/scripts/runqemu b/scripts/runqemu
index 2817acb19f..e5db06be37 100755
--- a/scripts/runqem
as package name contains uppercase chars
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/python/python3-cython_3.0.11.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-cython_3.0.11.bb
b/meta/recipes-devtools/python/python3-cython_3.0.11.bb
as this is correctly set by setuptools3-base already
Signed-off-by: Konrad Weihmann
---
meta/classes-recipe/python_flit_core.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/python_flit_core.bbclass
b/meta/classes-recipe/python_flit_core.bbclass
the unversioned python symlink and we should not be
catering to them.
Please reframe your arguments.
Alex
On Tue, 23 Jul 2024 at 18:44, Randy MacLeod via lists.openembedded.org
wrote:
On 2024-07-23 9:38 a.m., Konrad Weihmann via lists.openembedded.org wrote:
I also vote against it.
I'
I also vote against it.
While I see the convenience in dropping a lot of patches the better approach
would be to add something like python-is-python3, for the ones that require it.
(meta-webkit does provide it already
https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python
Anything preventing this patch from being picked?
There wasn't any feedback after the last reply.
An alternative would be to drop the python3 depends, as it is set by
setuptools-base class correctly already
On 16.07.24 12:54, Konrad Weihmann wrote:
It isn't that obvious, for the lo
=
"native" everything works well, it just affects recipes that use
inherit[_defer] native/nativesdk explicitly.
Nonetheless the target python3 dependency should be fixed regardless.
Konrad
On 16.07.24 12:12, Ross Burton wrote:
On 15 Jul 2024, at 13:18, Konrad Weihmann via lists.
when using python_flit_core on a native recipe
it was creating a dependency loop, as tasks for
python3 requires tasks for python3-native,
which is essential for building any native python recipes.
Signed-off-by: Konrad Weihmann
---
meta/classes-recipe/python_flit_core.bbclass | 5 -
1 file
On 04.07.24 17:15, Richard Purdie wrote:
On Wed, 2024-07-03 at 04:47 +, Konrad Weihmann via
lists.openembedded.org wrote:
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testexport fails, as the path assembly
is incorrect.
In that case fallback to
eviewed-By: Konrad Weihmann
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201452):
https://lists.openembedded.org/g/openembedded-core/message/201452
Mute This Topic: https://lists.openembedded.org/mt/106759209/21656
Group Owner: openembedd
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testexport fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
Signed-off-by: Konrad Weihmann
---
meta/classes-recipe/testexport.bbclass | 2 +-
1 file changed, 1 insertion(+), 1
if IMAGE_LINK_NAME is set empty to disable the symlinking
for image artifacts in deploy, testimage fails, as the path assembly
is incorrect.
In that case fallback to IMAGE_NAME
Signed-off-by: Konrad Weihmann
---
meta/classes-recipe/testimage.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2
by patching the interpreter lines after install
Signed-off-by: Konrad Weihmann
---
meta/recipes-devtools/python/python3-docutils_0.21.2.bb | 8
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-docutils_0.21.2.bb
b/meta/recipes-devtools/python/python3
Looking at the combination of the patches and the following
+ boot_files = d.getVar("IMAGE_BOOT_FILES")
+ if boot_files is None:
+ return
+
+ install_files = get_boot_files(deploy_image_dir, boot_files)
+ if install_files is None:
+ bb.warn("Could not find any boot files to install even though
IM
as this will clear WORKDIR and create race conditions
across various handling tasks
Signed-off-by: Konrad Weihmann
---
meta/classes-global/insane.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index
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
https://lists.openembedded.or
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&id=4641605c794db6648311b931fb3a36fe9e5dea56
breaks building python3-requests (as of version 2.28.2 in master).
> recipe-sysroot-native/usr/bin/python3-native/python3', '-m', 'pip',
'--disable-pip-version-c
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
anges 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: de
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 le
plied 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,
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 lin
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-re
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 to
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 pa
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 removes
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
- py
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 thi
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 wheel
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
r
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 --git
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 f
.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
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 it
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 setu
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 +
s, I guess!
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 whe
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 encoun
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 exception/
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', l
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
ile" 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'
t all core 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
Signed-off-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
o
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 1,
re as well).
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.bb
re as well).
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 deletion
re as well).
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_whe
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-" pre
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 underscor
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 wo
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 "cl
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 Herbrecht
a time
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 h
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 the
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.OperationalEr
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.
Sign
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 licenseInfoInFiles
>
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 re
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 --g
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 Mon
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 +0
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.
1 - 100 of 319 matches
Mail list logo
