From: Changqing Li
Fix following ptest failure:
/usr/lib64/cpio/ptest/run-ptest: line 7: cd: /usr/lib/cpio/ptest/tests/: No
such file or directory
Signed-off-by: Changqing Li
---
meta/recipes-extended/cpio/cpio-2.13/run-ptest | 2 +-
meta/recipes-extended/cpio/cpio_2.13.bb| 1 +
2 fil
libxcb needs to find the python package in the path specified by pythondir
recorded in xcb-proto.pc. If the libdir line is deleted, libxcb will report an
error when compiling:
| Failed to load the xcbgen Python package!
| Make sure that xcb/proto installed it on your Python path.
| If not, you wi
also seeing below errors which are related too
ERROR: Nothing PROVIDES 'gtk4-native' (but
/mnt/b/yoe/master/sources/meta-openembedded/meta-gnome/recipes-gnome/gnome-bluetooth/gnome-bluetooth_42.5.bb,
/mnt/b/yoe/master/
sources/meta-openembedded/meta-gnome/recipes-gnome/gnome-text-editor/gnome-text
I am seeing waylandpp failing to build and YP layer compatibility tests failing.
https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/2557/steps/11/logs/stdio
On Sun, Mar 12, 2023 at 7:51 AM Alexander Kanavin
wrote:
>
> This makes native opengl (and thus accelerated graphics in qemu
On Mon, Mar 13, 2023 at 12:56 AM Alexander Kanavin
wrote:
>
> On Mon, 13 Mar 2023 at 01:12, Khem Raj wrote:
>
> > This is working as intended, unlike glibc, musl provides stddef.h and
> > it wants musl based platforms to use that,
> > OE clang won't do that when the selected libc is glibc.
>
> Bu
All,
Below is the list as of top 38 bug owners as of the end of WW10 of who have
open medium or higher bugs and enhancements against YP 4.2. There are 33
possible work days left until the final release candidates for YP 4.2 needs
to be released.
Who
Count
michael.opdenac...@bootlin.com
All,
The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newc
* passing -std=c2x to avoid build failure with gcc-13 on host
works as well, but the resulting zic then segfaults when
used in tzdata, use a fix from upstream instead
* reported upstream in https://mm.icann.org/pipermail/tz/2023-March/032690.html
* fixes:
http://errors.yoctoproject.org/Erro
meta/classes-recipe/npm.bbclass:85: DeprecationWarning: invalid escape sequence
'\.'
'--transform', 's,^\./,package/,',
Signed-off-by: Martin Jansa
---
meta/classes-recipe/npm.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/npm.bbclass b/meta/cl
* there are few more autodetected compression libs
--disable-zlib disable zlib compression support [default=auto]
--disable-bzlib disable bz2lib compression support [default=auto]
--disable-xzlib disable liblzma/xz compression support
--disable-zstdlib disable
On Mon, Mar 13, 2023 at 6:38 PM Alexander Kanavin
wrote:
> On Mon, 13 Mar 2023 at 18:28, Martin Jansa wrote:
> >
> > On Mon, Mar 13, 2023 at 6:26 PM Alexander Kanavin <
> alex.kana...@gmail.com> wrote:
> >>
> >> Tests in distrodata that contact upstream servers had to be disabled
> >> because it
hwclock command fails on read-only-rootfs:
AssertionError: 1 != 0 : Failed to reset RTC time, output: hwclock: cannot open
/etc/adjtime: Read-only file system
Signed-off-by: Mikko Rapeli
---
meta/lib/oeqa/runtime/cases/rtc.py | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff
On Mon, 13 Mar 2023 at 18:28, Martin Jansa wrote:
>
> On Mon, Mar 13, 2023 at 6:26 PM Alexander Kanavin
> wrote:
>>
>> Tests in distrodata that contact upstream servers had to be disabled
>> because it's not possible to tell what is a real failure, and what is
>> a transient upstream issue (with
On Mon, Mar 13, 2023 at 6:26 PM Alexander Kanavin
wrote:
> Tests in distrodata that contact upstream servers had to be disabled
> because it's not possible to tell what is a real failure, and what is
> a transient upstream issue (with expired certificates or other network
> issues). To ensure ups
Tests in distrodata that contact upstream servers had to be disabled
because it's not possible to tell what is a real failure, and what is
a transient upstream issue (with expired certificates or other network
issues). To ensure upstream version checks don't regress, I run them
manually every now a
Clause II.3 of the Vim license states that any distribution of Vim that
has been extended or modified must _at least_ indicate in the :version
output that this is the case.
Handily, Vim has a --with-modified-by argument to add a line in that
text, so use MAINTAINER. This is the distribution maint
The default Poky-specific MAINTAINER assignment makes it look like the
maintainer is a person called Poky.
Instead, use "Poky Maintainers" as the name.
Signed-off-by: Ross Burton
---
meta-poky/conf/distro/poky.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-poky/co
I understand, I'll pursue all my tests with the current poky master. Thanks
On Mon, 13 Mar 2023 at 11:42, Alexander Kanavin wrote:
>
> You need to use kirkstone or newer to see the bitbake-driven network
> disabling in action. Can you try on current poky master? You don't
> need to port the whole
* with 1 preconfigured tap device you cannot run testimage on multiple images
at the same time
in my case have /tmp/qemu-tap-locks/tap0.skip (tap0 is used by openvpn on
builder)
and /etc/runqemu-nosudo as my build user doesn't have sudo powers
but then when 2 do_testimage tasks are execu
On Tue, Feb 14, 2023 at 4:22 PM Kai Kang wrote:
>
> On 2/14/23 22:30, Martin Jansa wrote:
>
> Thanks Kai,
>
> this should fix what I've reported in:
> https://lists.openembedded.org/g/openembedded-core/message/176508
>
> once this is merged, can you please add both oe-core changes (3 qemu patches)
Hi Ross,
> The other option would be for the test to determine if the recipes are
available, so adding meta-filesystems would enable the tests.
I'm not sure if I understand your proposal correctly.
If the idea is to add meta-filesystems as a kind of before class/test
setup and remove it afterward
This incorporates fixes for CVE-2023-1127, CVE-2023-1170, CVE-2023-1175.
Also remove runtime/doc/uganda.txt from the license checksum: the Vim
license is also in the top-level LICENSE file so this is redundant.
Signed-off-by: Ross Burton
---
meta/recipes-support/vim/vim.inc | 7 +++
1 file
* I was hit by oe-selftest -r
eSDK.oeSDKExtSelfTest.test_install_libraries_headers
running all tests except only this selected one:
poky $ oe-selftest -v -r eSDK.oeSDKExtSelfTest.test_install_libraries_headers
-K -B /OE/build/poky/build-eSDK
2023-03-13 14:00:52,955 - oe-selftest - DEBUG -
* skipped modules were triggering an ERROR before:
poky $ oe-selftest -v -r eSDK.oeSDKExtSelfTest.test_install_libraries_headers
imagefeatures.ImageFeatures.test_image_gen_debugfs -K -B
/OE/build/poky/build-eSDK
2023-03-13 15:07:53,430 - oe-selftest - ERROR - Not found
eSDK.oeSDKExtSelfTest
On 12 Mar 2023, at 12:03, Steve Sakoman via lists.yoctoproject.org
wrote:
> Full list: Found 7 unpatched CVEs
> CVE-2005-1796 (CVSS3: N/A): ncurses:ncurses-native
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-1796 *
Not a ncurses bug, I’ve asked NIST to update the CPE.
> CVE-202
Add a convenience argument to the log subcommand to list all of the
ptest logs in a testresults file.
Signed-off-by: Ross Burton
---
scripts/lib/resulttool/log.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/lib/resulttool/log.py b/scripts/lib/resulttool/log.py
index eb3927ec
ptestresult_get_log() looked for a key called 'ptestresuls.sections',
which should be 'ptestresult.sections'
Signed-off-by: Ross Burton
---
scripts/lib/resulttool/resultutils.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/lib/resulttool/resultutils.py
b/scripts/l
* these cases were correctly respecting IMAGE_LINK_NAME in most tests
* the only exception was relatively wide glob for manifest:
"test-empty-image-*.manifest"
* and even wider glob for -dbg:
"*-dbg.rootfs.tar.bz2"
* replace them with the exact filename we expect for given image
* be aware t
* this still assumes that IMAGE_LINK_NAME will contain IMAGE_BASENAME
which will be BPN 'multiconfig-image-packager' and that replacing
it with 'core-image-minimal' will match with the actual IMAGE_LINK_NAME
from core-image-minimal recipe - there is no good way to query
core-image-minimal's
* to better indicate how it's used in get_first_file
* cmd* is used in other places for actual shell commands
to execute
* RunQemuError('KERNEL not found: %s, %s or %s' % cmds)
also looked weird to me, but that works (to my python-noob surprise)
[YOCTO #12937]
Signed-off-by: Martin Jansa
-
* use IMAGE_LINK_NAME instead of hardcoding
core-image-minimal-${MACHINE} assumption
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/lib/oeqa/selftest/cases/minidebuginfo.py | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/mi
* it's not in self.td causing:
2023-03-12 18:06:29,591 - oe-selftest - DEBUG - Checking if qemux86-64 is not
this MACHINE
2023-03-12 18:06:29,594 - oe-selftest - INFO - ... ERROR
2023-03-12 18:06:29,594 - oe-selftest - INFO - Traceback (most recent call
last):
File "/OE/build/poky/meta
* use IMAGE_LINK_NAME instead of hardcoding
core-image-minimal-${MACHINE} assumption
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/lib/oeqa/selftest/cases/gdbserver.py | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/gdbserver.py
* use these variables instead of assuming:
"fitImage-its-%s-%s-%s" % (image_type, machine, machine)
notice that these files have no extension and the -machine suffix
is duplicated (once from core-image-minimal and once from
kernel-fitimage.bbclass:kernel_do_deploy:append
through KERNEL_FI
* to make it easier for projects to avoid default -${MACHINE} suffix if
the ${MACHINE} named DEPLOY_DIR_IMAGE works better for them
* also use IMAGE_LINK_NAME in IMAGE_NAME to make it more clear
that IMAGE_NAME is the same as IMAGE_LINK_NAME but with version
suffix
* adding it as separate v
* move it from kernel.bbclass, because it needs to stay in sync with
IMAGE_LINK_NAME structure
* image-artifact-names.bbclass is also inheritted from
kernel-artifact-names.bbclass
so every recipe which needs this variable probably already inherits one of
these
* fixes kernel-fitimage.bbclas
* this one is more tricky, because the test_rawcopy_plugin.wks.in file
is used while building core-image-minimal-mtdutils, but the image filename
inside wks.in is from core-image-minimal, so we cannot just let bitbake
expand IMAGE_LINK_NAME, use separate variable set in the same config fragme
* don't assume that every built image is named:
-.
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/lib/oeqa/selftest/cases/runqemu.py | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/runqemu.py
b/meta/lib/oeqa/selftest/cases/run
* use IMAGE_LINK_NAME instead of hardcoding
core-image-minimal-${MACHINE} assumption
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/lib/oeqa/selftest/cases/wic.py | 38 ++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/meta/lib/oeqa/selftest/ca
* with my build/conf/local.conf:
SSTATE_DIR = "/OE/build/poky/build/sstate-cache"
these devtool tests will first set own SSTATE_DIR and the original one set as
SSTATE_MIRROR:
2023-03-11 11:51:46,837 - oe-selftest - INFO -
test_devtool_update_recipe_append
(devtool.DevtoolUpdateTests.test_de
These changes are preparation for the actual changes from [YOCTO #12937],
but without changing anything in current artifacts naming schema.
Only change outside selftest was moving of INITRAMFS_IMAGE_NAME variable
and adding IMAGE_MACHINE_SUFFIX variable to make it easier to change both.
I've run
* this is one of the failures from distrodata.Distrodata.test_checkpkg:
2023-03-11 14:26:21,482 - oe-selftest - INFO -
==
2023-03-11 14:26:21,482 - oe-selftest - INFO - FAIL: test_checkpkg
(distrodata.Distrodata.test_checkpk
Running recipetool.RecipetoolTests.test_recipetool_handle_license_vars
followed by wic.Wic2.test_biosplusefi_plugin_qemu would show a failure of:
File "/media/build/poky/meta/lib/oeqa/utils/commands.py", line 351, in runqemu
qemu = oeqa.targetcontrol.QemuTarget(recipedata, targetlogger, imag
* avoid copying whole exec_prefix over base_prefix as there
were only zoneinfo files anyway
Signed-off-by: Martin Jansa
---
meta/recipes-extended/timezone/tzdata.bb | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-extended/timezone/tzdata.bb
b/me
Signed-off-by: Martin Jansa
---
meta/recipes-extended/timezone/timezone.inc | 6 --
meta/recipes-extended/timezone/tzcode-native.bb | 3 ---
meta/recipes-extended/timezone/tzdata.bb| 2 --
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-extended/timezon
You need to use kirkstone or newer to see the bitbake-driven network
disabling in action. Can you try on current poky master? You don't
need to port the whole build to that, just one sample recipe.
It is also expected that if you submit patches for master, they were
tested on master.
Alex
On Mon
Thank you very much, I tested your project and it worked.
So I'll try https for my git instead of ssh.
On Mon, 13 Mar 2023 at 10:49, Alex Kiernan wrote:
>
> For reference this was my test case:
>
> https://github.com/akiernan/uuid-test
>
> I was wondering if this was an ssh vs. https problem, bu
hmm, how is the network disabled ?
Because with the patch I provided , the git clone in do_compile is successful.
One major thing I forget to mention is that I use dunfell branch where
I backport all the cargo/rust relatives from master.
The backport was functional and straightforward, I just hav
For reference this was my test case:
https://github.com/akiernan/uuid-test
I was wondering if this was an ssh vs. https problem, but just
checking we've a mix of ssh and https access to local git repos.
On Mon, Mar 13, 2023 at 9:46 AM Alex Kiernan via
lists.openembedded.org
wrote:
>
> Are you l
Are you listing your ssh repos in your SRC_URI? We run with network
disabled everywhere other than fetch and with that patch we don't see
fetches from local ssh repos in compile.
On Mon, Mar 13, 2023 at 9:32 AM Frédéric Martinsons
wrote:
>
> Thanks for the patch alex, I did try it and the same ha
Hi all,
We are seeing some systemd service issues during the process of bumping Yocto
baseline from thud to langdale. The following service:
Unit]
Description="Nanocom TR600 Monitor Application slot %i"
RequiresMountsFor=/data
Wants=redis.service
After=redis.service
PartOf=tr600@%i.service tr600
Thanks for the patch alex, I did try it and the same happened (git
clone failure during do_compile), I'll
dig more on that and possibly submit patches if I found a way of
supporting git dependencies in Cargo.toml
On Mon, 13 Mar 2023 at 10:23, Alex Kiernan wrote:
>
> ISTR I tried this and ran into
ISTR I tried this and ran into a different set of different problems.
On Mon, Mar 13, 2023 at 9:20 AM Alexander Kanavin
wrote:
>
> Note that we're all rust neophytes, and rust support in yocto is still
> evolving towards maturity. If you can see better ways to do things,
> patches would be most w
Note that we're all rust neophytes, and rust support in yocto is still
evolving towards maturity. If you can see better ways to do things,
patches would be most welcome - but 'no network access except in
bitbake fetchers' is a core rule.
Alex
On Mon, 13 Mar 2023 at 10:14, Frédéric Martinsons
wro
- remove backported patches
- update relocate-modules.patch
Signed-off-by: Markus Volk
---
...-info-don-t-assume-million-in-one-ev.patch | 50
...build-do-not-use-can_run_host_binari.patch | 48
.../glib-2.0/glib-2.0/cpp-null.patch | 77 ---
...
Try with this patch:
https://patchwork.yoctoproject.org/project/oe-core/patch/20221030173815.10212-2-alex.kier...@gmail.com/
On Mon, Mar 13, 2023 at 9:14 AM Frederic Martinsons
wrote:
>
> I understand there should not be a fetch during build step , I'll try
> to find why .
> In the mean time, if
I understand there should not be a fetch during build step , I'll try
to find why .
In the mean time, if this is a strong rule, shouldn't we invoke "cargo
build" with --offline option ?
On Mon, 13 Mar 2023 at 09:38, Alexander Kanavin wrote:
>
> On Mon, 13 Mar 2023 at 09:29, Frédéric Martinsons
>
On Sun, 2023-03-12 at 14:07 +, Richard Purdie via
lists.openembedded.org wrote:
> On Sun, 2023-03-12 at 14:02 +, Richard Purdie via
> lists.openembedded.org wrote:
> > Having this base class as a separate file is just confusing. Merge with
> > the rest of the test code.
> >
> > Signed-off-
On Mon, 13 Mar 2023 at 09:29, Frédéric Martinsons
wrote:
> But the compile step tried to git clone anyway and so it failed like I
> showed in my first email.
You need to figure out why this happens, because it should not. We
have plenty of recipes that list crates in SRC_URI in oe-core, so you
co
Yes I did do that in a first place (because this is what cargo bitbake
give to me in a first place), but for git dependencies this doesn't
work.
So , to take the example again I had that in SRC_URI (after correcting
malformed url as tracked by
https://github.com/meta-rust/cargo-bitbake/issues/41):
Hi All,
QA for yocto-4.1.3.rc1 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
> -O
On Mon, 13 Mar 2023 at 01:12, Khem Raj wrote:
> This is working as intended, unlike glibc, musl provides stddef.h and
> it wants musl based platforms to use that,
> OE clang won't do that when the selected libc is glibc.
But this means gcc is not doing the right thing. It does take its own
stdde
We are in the feature freeze now (see weekly status emails). If there
are more pressing concerns for release stability (and there usually
are), the patchset won't be taken until after the release. If you want
it to go in sooner, help with those issues would be appreciated (you
can ask on #yocto irc
On Mon, 13 Mar 2023 at 08:29, wangmy wrote:
> When libxcb is compiled, it will read libdir from xcb-proto.pc to find the
> library.
> If delete this line, libxcb will report an error because it cannot find the
> directory of the library.
Which library in particular? Can you show the error, and
When libxcb is compiled, it will read libdir from xcb-proto.pc to find the
library.
If delete this line, libxcb will report an error because it cannot find the
directory of the library.
I haven't got any better way to solve this problem.
--
Best Regards
--
65 matches
Mail list logo
