Can you put the ticket link into the patch itself as well please?
Alex
On Thu, 25 Mar 2021 at 23:14, Yi Fan Yu wrote:
> New test introduced in valgrind 3.17.0.
> Test fails on both qemuarm64 and qemux64.
>
> [YOCTO #14324]
>
> Signed-off-by: Yi Fan Yu
> ---
>
Wait, I have to say neither reason is convincing. Pyc files are not
system-specific, they are the same on all systems. And pseudo issues should
be dealt with by fixing the issue, not working around the symptoms, no?
Alex
On Thu, 25 Mar 2021 at 23:44, Mark Hatle
wrote:
> Since pyc cache files
On Thu, Mar 25, 2021 at 12:48 PM Alistair Francis wrote:
>
> On Thu, Mar 25, 2021 at 12:15 AM Khem Raj wrote:
> >
> > Signed-off-by: Khem Raj
> > Cc: Alistair Francis
>
> I'm not sure if this is the right thing to do here.
>
> Have you tested this does GRUB boot with this check removed?
>
I
A full working port is not available yet, until such time disable it
Signed-off-by: Khem Raj
Cc: Alistair Francis
---
meta/recipes-bsp/grub/grub2.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index
Signed-off-by: Zheng Ruoqin
---
.../webkit/{wpebackend-fdo_1.8.0.bb => wpebackend-fdo_1.8.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-sato/webkit/{wpebackend-fdo_1.8.0.bb =>
wpebackend-fdo_1.8.2.bb} (89%)
diff --git
Signed-off-by: Zheng Ruoqin
---
.../systemd/{systemd-boot_247.4.bb => systemd-boot_247.5.bb}| 0
meta/recipes-core/systemd/systemd.inc | 2 +-
.../recipes-core/systemd/{systemd_247.4.bb => systemd_247.5.bb} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename
Signed-off-by: Zheng Ruoqin
---
.../epiphany/{epiphany_3.38.2.bb => epiphany_3.38.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-gnome/epiphany/{epiphany_3.38.2.bb => epiphany_3.38.3.bb}
(93%)
diff --git a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
Hi,
Just a reminder about our upcoming OpenEmbedded Happy Hour on March 31 for
Europe/US timezones @ 1700/5pm UTC (1pm ET / 10am PT):
https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+March+31=20210331T17
--
Regards,
When cross-compiling with v5.12-rc3, prepare fails[1] build of vdso at
the objcopy stage since it seems to be using the local host's objcopy
rather than the cross-compile version we want it to use.
This can be trivially reproduced in a localbuild of the kernel
following the build parameters
Signed-off-by: Khem Raj
---
scripts/contrib/documentation-audit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/contrib/documentation-audit.sh
b/scripts/contrib/documentation-audit.sh
index 1191f57a8e..f436f9bae0 100755
--- a/scripts/contrib/documentation-audit.sh
When LICENSE_FLAGS_WHITELIST does not have commercial in it then the
the dependencies like ffmpeg will become invisible and render these
packages unbuildable, therefore world build will report parse issues
its better to exclude them from world build in such cases
Signed-off-by: Khem Raj
Cc:
This is the first attempt at enabling the PR service in the eSDK. It appears
to work for me, but I expect I'm missing corner cases.
Any feedback is appreciatd.
Mark Hatle (1):
populate_sdk_ext: Add support for PR service
meta/classes/populate_sdk_ext.bbclass | 25 +
From: Mark Hatle
In the classes/populate_sdk_ext.bbclass the system already copies a number
of configurations, such as the hash equivalency data. However, the PR
service was being handled.
The new code works by checking if PRSERV_HOST is defined, if it is, use
the existing export functions to
On 2021-03-25 6:23 p.m., Richard Purdie wrote:
Hi Sakib,
On Thu, 2021-03-25 at 18:11 -0400, Sakib Sajal wrote:
I have been trying, with help from Randy, Trevor and Steve, to run some
experiments on an internal autobuilder instance to collect host data
during builds for signs of io latency.
Building an eSDK (all stock config):
MACHINE=qemuarm bitbake core-image-minimal -c populate_sdk_ext
I then install it, and get:
Checking sstate mirror object availability: 100%
Since pyc cache files are really system specific, no real reason to copy or
generate them during the eSDK build process. Also generating them has the
possibility of re-using inodes that pseudo may have been tracking, leading
a build failure.
Signed-off-by: Mark Hatle
---
Hi Sakib,
On Thu, 2021-03-25 at 18:11 -0400, Sakib Sajal wrote:
> I have been trying, with help from Randy, Trevor and Steve, to run some
> experiments on an internal autobuilder instance to collect host data
> during builds for signs of io latency.
>
> Initially i modified
Notable changes:
* library is now in libexecdir instead of libdir
Added patches:
* Add musl.supp: missing musl.supp in 3.17.0
Dropped backport patches:
* nlcontrolc: found in c79180a3afcf65902e578646c3b716cc749db406
* drd Fedora33: found in 15330adf7c2471fbaa6a0818db07078d81dbff97
* lmw lswi
New test introduced in valgrind 3.17.0.
Test fails on both qemuarm64 and qemux64.
[YOCTO #14324]
Signed-off-by: Yi Fan Yu
---
...orarily-drd-tests-swapcontext.vgtest.patch | 28 +++
.../valgrind/valgrind_3.17.0.bb | 1 +
2 files changed, 29 insertions(+)
create
Hi Richard,
I have been trying, with help from Randy, Trevor and Steve, to run some
experiments on an internal autobuilder instance to collect host data
during builds for signs of io latency.
Initially i modified yocto-autobuilder-helper/config.json and added the
following 3 lines to
From: Bruce Ashfield
Updating linux-yocto/5.4 to the latest korg -stable release that comprises
the following commits:
a65e78863443 Linux 5.4.107
5161cc4350de net: dsa: b53: Support setting learning on port
ebeefdc3d8ee net: dsa: tag_mtk: fix 802.1ad VLAN egress
6c3d86e6ffde
From: Bruce Ashfield
Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:
3ba56f490c7a Linux 5.10.25
dd0b7edb7794 net: dsa: b53: Support setting learning on port
0f6cab2350d5 ALSA: usb-audio: Don't avoid stopping the stream at
From: Bruce Ashfield
Richard,
I had some pings about v5.10.25, so I thought I'd send out this round of
-stable udpates while I finish up some other config warning cleanups.
These are routine -stable and -rt bugfix updates, and I don't expect any
issues.
Bruce
The following changes since
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto/5.10:
be2935bce35f v5.10.21-rt34
8078987238f9 softirq: Update the softirq/tasklet patches
0042f5e5ac7d mm: slub: Don't resize the location tracking cache on
PREEMPT_RT
69bcb4682eaa v5.10.21-rt33
On Thu, Mar 25, 2021 at 12:15 AM Khem Raj wrote:
>
> Signed-off-by: Khem Raj
> Cc: Alistair Francis
I'm not sure if this is the right thing to do here.
Have you tested this does GRUB boot with this check removed?
>From memory I don't think the original GRUB port would have been tested on
Only security issues fixed in this release according to
https://www.openssl.org/news/cl111.txt
Signed-off-by: Mikko Rapeli
---
.../openssl/{openssl_1.1.1j.bb => openssl_1.1.1k.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename
Only security issues fixed in this release according to
https://www.openssl.org/news/cl111.txt
Signed-off-by: Mikko Rapeli
---
.../openssl/{openssl_1.1.1j.bb => openssl_1.1.1k.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename
On Thu, 25 Mar 2021 at 18:15, Alexander Kanavin wrote:
> I don't think I fully understand this. Is g-i in meson projects already
> broken for a while (there was a bit of refactor in the latest meson version,
> which I tested, but perhaps not well enough), or is this necessary for the
> other
So v1 failed all over the AB, the root cause being that in master
Meson doesn't know that there's a specific pkg-config binary for all
native builds, but with this series it does. In master it only uses
pkg-config-native in native *recipes* but now it uses it for all
native lookups in target
On 3/12/21 9:57 PM, Marek Vasut wrote:
The RSI 911x WiFi firmware is already part of the linux-firmware
repository, package it to make it easily available.
Signed-off-by: Marek Vasut
Cc: Richard Purdie
Cc: Steve Sakoman
---
V2: Rebase on current oe-core/master
Bump ?
I don't think I fully understand this. Is g-i in meson projects already
broken for a while (there was a bit of refactor in the latest meson
version, which I tested, but perhaps not well enough), or is this necessary
for the other patches in your set?
Alex
On Thu, 25 Mar 2021 at 18:39, Ross
Add a few more tools to the BUILD_* list, to match the target tool list.
Signed-off-by: Ross Burton
---
meta/conf/bitbake.conf | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index ecd4d1638e..4c472156e9 100644
--- a/meta/conf/bitbake.conf
When building G-I we want to use *native* binaries (as they need to be
executed) but the *cross* libraries, as otherwise when using the correct
pkg-config binary in native lookups Meson will end up linking native and
cross libraries together.
Signed-off-by: Ross Burton
---
Meson now supports native-files, which are the same as cross files but
describe the native build.
By writing and using a native file which describes the tools to use, we
can drop the environment variable overriding.
Signed-off-by: Ross Burton
---
meta/classes/meson.bbclass | 54
On Thu, 2021-03-25 at 16:19 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: Richard Purdie
> > Sent: den 25 mars 2021 15:27
> > To: Peter Kjellerstedt ; Oleksiy Obitotskyi -
> > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca Bocassi
> > ;
> -Original Message-
> From: Richard Purdie
> Sent: den 25 mars 2021 15:27
> To: Peter Kjellerstedt ; Oleksiy Obitotskyi -
> X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca Bocassi
> ; openembedded-core@lists.openembedded.org
> Cc: bluelightn...@bluelightning.org; Khem Raj
> Subject: Re:
Setting the 'func' flag on the commands variables ensures that they are parsed
as shell, and therefore that the referenced commands contents are included in
checksums. Doing this only in image.bbclass means that this is missing in
recipes that are not images, but which inherit populate_sdk or
Just a quick note that you *can* script config file alterations without
having to alter files that may be under source control, that's what
auto.conf is for :)
On Thu, Mar 25, 2021 at 7:51 AM Robert P. J. Day
wrote:
> On Thu, 25 Mar 2021, Mike Looijmans wrote:
>
> > I for one use a whitelist
On Thu, Mar 25, 2021 at 8:45 AM Luca Boccassi wrote:
>
> On Thu, 2021-03-25 at 14:27 +, Richard Purdie wrote:
> > On Thu, 2021-03-25 at 14:22 +, Peter Kjellerstedt wrote:
> > > > -Original Message-
> > > > From: Richard Purdie
> > > > Sent: den 25 mars 2021 10:34
> > > > To:
On Thu, 2021-03-25 at 14:27 +, Richard Purdie wrote:
> On Thu, 2021-03-25 at 14:22 +, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: Richard Purdie
> > > Sent: den 25 mars 2021 10:34
> > > To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> > > ; Luca
Needs to go to openembedded-devel ML and add bpftool to
meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
On Thu, Mar 25, 2021 at 4:26 PM Denys Zagorui -X (dzagorui - GLOBALLOGIC
INC@Cisco) via lists.openembedded.org wrote:
> Have not seen build issues for 5.4 and 5.10
> kernels so
Have not seen build issues for 5.4 and 5.10
kernels so allow to build it
Signed-off-by: Denys Zagorui
---
meta-oe/recipes-kernel/bpftool/bpftool.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta-oe/recipes-kernel/bpftool/bpftool.bb
b/meta-oe/recipes-kernel/bpftool/bpftool.bb
index
Here is build and link to the diff-html:
https://autobuilder.yoctoproject.org/typhoon/#/builders/116/builds/126
https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210324-x8y0w43u/packages/diff-html/
Regards,
Oleksiy
From:
On Thu, 25 Mar 2021, Mike Looijmans wrote:
> I for one use a whitelist env vars daily, both hobby and work.
>
> We tend to build for multiple machines, so in general we'd have
> something like this running on the build server:
>
> for machine in mach1 mach2 mach3 mach4 ... mach40
> do
>
I for one use a whitelist env vars daily, both hobby and work.
We tend to build for multiple machines, so in general we'd have something like
this running on the build server:
for machine in mach1 mach2 mach3 mach4 ... mach40
do
MACHINE=$machine bitbake image1 image2 image3
done
Being
On Thu, 2021-03-25 at 14:22 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: Richard Purdie
> > Sent: den 25 mars 2021 10:34
> > To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> > ; Luca Bocassi ;
> > openembedded-core@lists.openembedded.org
> > Cc:
> -Original Message-
> From: Richard Purdie
> Sent: den 25 mars 2021 10:34
> To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> ; Luca Bocassi ;
> openembedded-core@lists.openembedded.org
> Cc: bluelightn...@bluelightning.org; Peter Kjellerstedt
> ; Khem Raj
> Subject: Re:
On 3/25/21 9:08 AM, Robert P. J. Day wrote:
>
> kind of a philosophical question, but i'm having a discussion with
> some new colleagues about how to customize an OE (actually, wind river
> linux) build, and these colleagues have, until now, used (whitelisted)
> environment variables to pass
kind of a philosophical question, but i'm having a discussion with
some new colleagues about how to customize an OE (actually, wind river
linux) build, and these colleagues have, until now, used (whitelisted)
environment variables to pass info to the build, that info being used
to specify
Hi Alex,
Le mar. 23 mars 2021 à 17:42, Alexander Kanavin
a écrit :
>
> Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones
> that are enabled and disabled, and use the former in PACKAGECONFIG itself?
You mean something like this ?
# PACKAGECONFIG features that do not
[Edited Message Follows]
Hi Oleksiy,
I've submitted
https://lists.openembedded.org/g/openembedded-core/topic/81600237 which should
supersede this I did not send it as v3 because it is a different solution. I've
also ran 'bitbake -c testimage core-image-sato' with the new solution and it is
Hi Oleksiy,
I've submitted
https://lists.openembedded.org/g/openembedded-core/topic/81600237 which should
supersede this I did not send it as v3 because it is a different solution.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149925):
The run-postinsts package runs post installation scripts
on target if packages request delayed post installations. When
no delayed post installations are found the sysV style scripts
are disabled for the package and hence it did not run on sysV
based systems. However, the package provides systemd
Currently, the sshdgenkeys.service wait for the host keys default paths
/var and /run. The service runs a script which picks up the host key
paths from the sshd_config which means that the paths are configurable
and can potentially be placed outside /var and /run.
This patch makes
On Thu, 2021-03-25 at 09:34 +, Richard Purdie wrote:
> On Thu, 2021-03-25 at 09:17 +, Oleksiy Obitotskyi -X (oobitots -
> GLOBALLOGIC INC at Cisco) wrote:
> > Could you look into this warning.
> >
> > WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-linux-dev
> > rdepends on
On Thu, 2021-03-25 at 09:17 +, Oleksiy Obitotskyi -X (oobitots -
GLOBALLOGIC INC at Cisco) wrote:
> Could you look into this warning.
>
> WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-linux-dev
> rdepends on util-linux-libuuid-dev, but it isn't a build dependency?
>
Rename the recipe from util-linux-uuid to util-linux-libuuid which means
we can drop the custom PACKAGES and FILES defintions which simplifies
things. Also move the LICENSE setting to the libuuid recipe so that
it is correctly applied to the right packages.
This means the standard definitions
Could you look into this warning.
WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-linux-dev rdepends
on util-linux-libuuid-dev, but it isn't a build dependency? [build-deps]
https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226
Regards,
Oleksiy
On Thu, 25 Mar 2021 at 00:47, wangmy wrote:
> -@@ -158,12 +88,8 @@ dnl
> - AC_DEFUN([AM_PATH_LIBASSUAN],
> - [ _AM_PATH_LIBASSUAN_COMMON($1)
> - if test $ok = yes; then
> --LIBASSUAN_CFLAGS=`$LIBASSUAN_CONFIG --cflags`
> --LIBASSUAN_LIBS=`$LIBASSUAN_CONFIG --libs`
> - ifelse([$2],
59 matches
Mail list logo