Re: [oe-core][PATCH v2 2/2] valgrind: Disable ptest swapcontext.vgtest
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
> ---
> ...orarily-drd-tests-swapcontext.vgtest.patch | 28 +++
> .../valgrind/valgrind_3.17.0.bb | 1 +
> 2 files changed, 29 insertions(+)
> create mode 100644
> meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
>
> diff --git
> a/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
> b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
> new file mode 100644
> index 00..f217098650
> --- /dev/null
> +++
> b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
> @@ -0,0 +1,28 @@
> +From 0f1814a618eff4233e9e8379a8cb2dededdc5a8b Mon Sep 17 00:00:00 2001
> +From: Yi Fan Yu
> +Date: Tue, 23 Mar 2021 11:09:20 -0700
> +Subject: [PATCH] Disable temporarily drd/tests/swapcontext.vgtest
> +
> +New test introduced in valgrind 3.17.0.
> +Test fails on both qemuarm64 and qemux64.
> +
> +Upstream-Status: Pending [Needs more Investigation]
> +
> +Signed-off-by: Yi Fan Yu
> +---
> + drd/tests/swapcontext.vgtest | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/drd/tests/swapcontext.vgtest b/drd/tests/swapcontext.vgtest
> +index 98e3712c4..5492da31d 100644
> +--- a/drd/tests/swapcontext.vgtest
> b/drd/tests/swapcontext.vgtest
> +@@ -1,4 +1,4 @@
> +-prereq: test -e swapcontext && ./supported_libpthread
> ++prereq: false
> + vgopts: --read-var-info=yes --check-stack-var=yes --show-confl-seg=no
> --num-callers=2
> + prog: swapcontext
> + stderr_filter: filter_stderr
> +--
> +2.17.1
> +
> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
> b/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
> index 1e29896596..7a6b766121 100644
> --- a/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
> +++ b/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
> @@ -43,6 +43,7 @@ SRC_URI = "
> https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
>
> file://0001-none-tests-fdleak_cmsg.stderr.exp-adjust-tmp-paths.patch \
> file://0001-memcheck-tests-Fix-timerfd-syscall-test.patch \
> file://0001-Add-missing-musl.supp.patch \
> +
> file://0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch \
> "
> SRC_URI[md5sum] = "afe11b5572c3121a781433b7c0ab741b"
> SRC_URI[sha256sum] =
> "ad3aec668e813e40f238995f60796d9590eee64a16dff88421430630e69285a2"
> --
> 2.17.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149975):
https://lists.openembedded.org/g/openembedded-core/message/149975
Mute This Topic: https://lists.openembedded.org/mt/81615169/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] populate_sdk_ext: Avoid copying and producing .pyc files
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 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
> ---
> meta/classes/populate_sdk_ext.bbclass | 4 +++-
> meta/lib/oe/copy_buildsystem.py | 6 +++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/meta/classes/populate_sdk_ext.bbclass
> b/meta/classes/populate_sdk_ext.bbclass
> index 9112ab6c5e..14689ec6ac 100644
> --- a/meta/classes/populate_sdk_ext.bbclass
> +++ b/meta/classes/populate_sdk_ext.bbclass
> @@ -251,7 +251,9 @@ python copy_buildsystem () {
>
> # Create a layer for new recipes / appends
> bbpath = d.getVar('BBPATH')
> -bb.process.run(['devtool', '--bbpath', bbpath, '--basepath',
> baseoutpath, 'create-workspace', '--create-only', os.path.join(baseoutpath,
> 'workspace')])
> +env = os.environ.copy()
> +env['PYTHONDONTWRITEBYTECODE'] = '1'
> +bb.process.run(['devtool', '--bbpath', bbpath, '--basepath',
> baseoutpath, 'create-workspace', '--create-only', os.path.join(baseoutpath,
> 'workspace')], env=env)
>
> # Create bblayers.conf
> bb.utils.mkdirhier(baseoutpath + '/conf')
> diff --git a/meta/lib/oe/copy_buildsystem.py
> b/meta/lib/oe/copy_buildsystem.py
> index 31a84f5b06..d97bf9d1b9 100644
> --- a/meta/lib/oe/copy_buildsystem.py
> +++ b/meta/lib/oe/copy_buildsystem.py
> @@ -20,7 +20,7 @@ def _smart_copy(src, dest):
> mode = os.stat(src).st_mode
> if stat.S_ISDIR(mode):
> bb.utils.mkdirhier(dest)
> -cmd = "tar --exclude='.git' --xattrs --xattrs-include='*' -chf -
> -C %s -p . \
> +cmd = "tar --exclude='.git' --exclude='__pycache__' --xattrs
> --xattrs-include='*' -chf - -C %s -p . \
> | tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dest)
> subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
> else:
> @@ -259,7 +259,7 @@ def create_locked_sstate_cache(lockedsigs,
> input_sstate_cache, output_sstate_cac
> bb.note('Generating sstate-cache...')
>
> nativelsbstring = d.getVar('NATIVELSBSTRING')
> -bb.process.run("gen-lockedsig-cache %s %s %s %s %s" % (lockedsigs,
> input_sstate_cache, output_sstate_cache, nativelsbstring, filterfile or ''))
> +bb.process.run("PYTHONDONTWRITEBYTECODE=1 gen-lockedsig-cache %s %s
> %s %s %s" % (lockedsigs, input_sstate_cache, output_sstate_cache,
> nativelsbstring, filterfile or ''))
> if fixedlsbstring and nativelsbstring != fixedlsbstring:
> nativedir = output_sstate_cache + '/' + nativelsbstring
> if os.path.isdir(nativedir):
> @@ -286,7 +286,7 @@ def check_sstate_task_list(d, targets, filteroutfile,
> cmdprefix='', cwd=None, lo
> logparam = '-l %s' % logfile
> else:
> logparam = ''
> -cmd = "%sBB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1 oe-check-sstate %s
> -s -o %s %s" % (cmdprefix, targets, filteroutfile, logparam)
> +cmd = "%sPYTHONDONTWRITEBYTECODE=1 BB_SETSCENE_ENFORCE=1
> PSEUDO_DISABLED=1 oe-check-sstate %s -s -o %s %s" % (cmdprefix, targets,
> filteroutfile, logparam)
> env = dict(d.getVar('BB_ORIGENV', False))
> env.pop('BUILDDIR', '')
> env.pop('BBPATH', '')
> --
> 2.17.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149974):
https://lists.openembedded.org/g/openembedded-core/message/149974
Mute This Topic: https://lists.openembedded.org/mt/81615695/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] grub-efi: Fix build failure on RISCV32
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 have not run it no, but inspected the generate PE file and they look
ok. however, I think we should drop
this patch and instead just disable grub on rv32 until such time when
port is available. I have send a follow up
patch for that.
> From memory I don't think the original GRUB port would have been tested on
> RV32.
>
> Alistair
>
> > ---
> > ...sable-offset-overflow-check-for-rv32.patch | 45 +++
> > meta/recipes-bsp/grub/grub2.inc | 1 +
> > 2 files changed, 46 insertions(+)
> > create mode 100644
> > meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
> >
> > diff --git
> > a/meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
> >
> > b/meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
> > new file mode 100644
> > index 00..6547bf2261
> > --- /dev/null
> > +++
> > b/meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
> > @@ -0,0 +1,45 @@
> > +From ce1cea0563011698e4a70c9a60e7da66b57ab1d6 Mon Sep 17 00:00:00 2001
> > +From: Khem Raj
> > +Date: Wed, 24 Mar 2021 20:55:56 -0700
> > +Subject: [PATCH] Disable offset overflow check for rv32
> > +
> > +Fixes
> > +/tmp/grub/grub-mkimage: error: target 17c6 not reachable from pc=936.
> > +
> > +Upstream-Status: Reported [https://savannah.gnu.org/bugs/index.php?60283]
> > +Signed-off-by: Khem Raj
> > +---
> > + util/grub-mkimagexx.c | 6 --
> > + 1 file changed, 4 insertions(+), 2 deletions(-)
> > +
> > +diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
> > +index 00f49ccaa..6deb66226 100644
> > +--- a/util/grub-mkimagexx.c
> > b/util/grub-mkimagexx.c
> > +@@ -1297,9 +1297,10 @@ SUFFIX (relocate_addrs) (Elf_Ehdr *e, struct
> > section_metadata *smd,
> > +{
> > + grub_uint32_t hi20, lo12;
> > +
> > ++#ifdef MKIMAGE_ELF64
> > + if (off != (grub_int32_t)off)
> > +grub_util_error ("target %lx not reachable from
> > pc=%lx", (long)sym_addr, (long)((char *)target - (char *)e));
> > +-
> > ++#endif
> > + hi20 = (off + 0x800) & 0xf000;
> > + lo12 = (off - hi20) & 0xfff;
> > + t32[0] = grub_host_to_target32
> > ((grub_target_to_host32 (t32[0]) & 0xfff) | hi20);
> > +@@ -1336,9 +1337,10 @@ SUFFIX (relocate_addrs) (Elf_Ehdr *e, struct
> > section_metadata *smd,
> > +{
> > + grub_int32_t hi20;
> > +
> > ++#ifdef MKIMAGE_ELF64
> > + if (off != (grub_int32_t)off)
> > +grub_util_error ("target %lx not reachable from
> > pc=%lx", (long)sym_addr, (long)((char *)target - (char *)e));
> > +-
> > ++#endif
> > + hi20 = (off + 0x800) & 0xf000;
> > + *t32 = grub_host_to_target32 ((grub_target_to_host32
> > (*t32) & 0xfff) | hi20);
> > +}
> > +--
> > +2.31.0
> > +
> > diff --git a/meta/recipes-bsp/grub/grub2.inc
> > b/meta/recipes-bsp/grub/grub2.inc
> > index bcff676c26..d8a556e06c 100644
> > --- a/meta/recipes-bsp/grub/grub2.inc
> > +++ b/meta/recipes-bsp/grub/grub2.inc
> > @@ -19,6 +19,7 @@ SRC_URI =
> > "https://alpha.gnu.org/gnu/grub/grub-${REALPV}.tar.xz \
> >
> > file://grub-module-explicitly-keeps-symbole-.module_license.patch \
> > file://0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch \
> > file://determinism.patch \
> > + file://0001-Disable-offset-overflow-check-for-rv32.patch \
> > "
> >
> > SRC_URI[sha256sum] =
> > "2c87f1f21e2ab50043e6cd9163c08f1b6c3a6171556bf23ff9ed65b074145484"
> > --
> > 2.31.0
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149973):
https://lists.openembedded.org/g/openembedded-core/message/149973
Mute This Topic: https://lists.openembedded.org/mt/81595170/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] grub2: Disable for RISCV32
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 bcff676c26..d88c3fd3ad 100644 --- a/meta/recipes-bsp/grub/grub2.inc +++ b/meta/recipes-bsp/grub/grub2.inc @@ -33,7 +33,7 @@ UPSTREAM_CHECK_REGEX = "grub-(?P\d+(\.\d+)+)\.tar\.(gz|xz)" DEPENDS = "flex-native bison-native gettext-native" -COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*|riscv.*)-(linux.*|freebsd.*)' +COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*|riscv64)-(linux.*|freebsd.*)' COMPATIBLE_HOST_armv7a = 'null' COMPATIBLE_HOST_armv7ve = 'null' -- 2.31.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149972): https://lists.openembedded.org/g/openembedded-core/message/149972 Mute This Topic: https://lists.openembedded.org/mt/81621162/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] wpebackend-fdo: upgrade 1.8.0 -> 1.8.2
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 a/meta/recipes-sato/webkit/wpebackend-fdo_1.8.0.bb
b/meta/recipes-sato/webkit/wpebackend-fdo_1.8.2.bb
similarity index 89%
rename from meta/recipes-sato/webkit/wpebackend-fdo_1.8.0.bb
rename to meta/recipes-sato/webkit/wpebackend-fdo_1.8.2.bb
index 344aa9717c..2ce631a73c 100644
--- a/meta/recipes-sato/webkit/wpebackend-fdo_1.8.0.bb
+++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.8.2.bb
@@ -13,7 +13,7 @@ inherit meson features_check
REQUIRED_DISTRO_FEATURES = "opengl"
SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz;
-SRC_URI[sha256sum] =
"9652a99c75fe1c6eab0585b6395f4e104b2427e4d1f42969f1f77df29920d253"
+SRC_URI[sha256sum] =
"98c291071128326a72918d670a46ef63268c43267928560ac3b84b6aebb2d78d"
# This is a tweak of upstream-version-is-even needed because
# ipstream directory contains tarballs for other components as well.
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149971):
https://lists.openembedded.org/g/openembedded-core/message/149971
Mute This Topic: https://lists.openembedded.org/mt/81618848/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] systemd-boot: upgrade 247.4 -> 247.5
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 meta/recipes-core/systemd/{systemd-boot_247.4.bb =>
systemd-boot_247.5.bb} (100%)
rename meta/recipes-core/systemd/{systemd_247.4.bb => systemd_247.5.bb} (100%)
diff --git a/meta/recipes-core/systemd/systemd-boot_247.4.bb
b/meta/recipes-core/systemd/systemd-boot_247.5.bb
similarity index 100%
rename from meta/recipes-core/systemd/systemd-boot_247.4.bb
rename to meta/recipes-core/systemd/systemd-boot_247.5.bb
diff --git a/meta/recipes-core/systemd/systemd.inc
b/meta/recipes-core/systemd/systemd.inc
index 098bca98f1..87ee794f05 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -14,7 +14,7 @@ LICENSE = "GPLv2 & LGPLv2.1"
LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
-SRCREV = "069525e84a67375e27429cb490e8d28af78e673a"
+SRCREV = "c86f4f5f287258938d0c30354040c3b034b0c066"
SRCBRANCH = "v247-stable"
SRC_URI =
"git://github.com/systemd/systemd-stable.git;protocol=git;branch=${SRCBRANCH}"
diff --git a/meta/recipes-core/systemd/systemd_247.4.bb
b/meta/recipes-core/systemd/systemd_247.5.bb
similarity index 100%
rename from meta/recipes-core/systemd/systemd_247.4.bb
rename to meta/recipes-core/systemd/systemd_247.5.bb
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149970):
https://lists.openembedded.org/g/openembedded-core/message/149970
Mute This Topic: https://lists.openembedded.org/mt/81618837/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] epiphany: upgrade 3.38.2 -> 3.38.3
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
b/meta/recipes-gnome/epiphany/epiphany_3.38.3.bb
similarity index 93%
rename from meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
rename to meta/recipes-gnome/epiphany/epiphany_3.38.3.bb
index 04f340f133..889de16d00 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.38.2.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_3.38.3.bb
@@ -19,7 +19,7 @@ SRC_URI =
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}
file://migrator.patch \
file://distributor.patch \
"
-SRC_URI[archive.sha256sum] =
"8b05f2bcc1e80ecf4a10f6f01b3285087eb4cbdf5741dffb8c0355715ef5116d"
+SRC_URI[archive.sha256sum] =
"ce62c1fa3e442a9d6131fc884a6bc9a65cf06224c30d649c49624c2ebcb0d275"
# Developer mode enables debugging
PACKAGECONFIG[developer-mode] = "-Ddeveloper_mode=true,-Ddeveloper_mode=false"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149969):
https://lists.openembedded.org/g/openembedded-core/message/149969
Mute This Topic: https://lists.openembedded.org/mt/81618834/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] OpenEmbedded Happy Hour March 31 5pm/1700 UTC
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, Denys Dmytriyenko PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149968): https://lists.openembedded.org/g/openembedded-core/message/149968 Mute This Topic: https://lists.openembedded.org/mt/81618809/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] make-mod-scripts: Provide the correct objcopy to kernel make
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 provided in the process[2]
Lets fix this by passing OBJCOPY over to the kernel.
[1] https://pastebin.ubuntu.com/p/pNcQtb93wr/
[2] https://pastebin.ubuntu.com/p/vZGqgh9Sq5/
Signed-off-by: Nishanth Menon
---
NOTE:
1. This is a different problem and is not resolved with
https://lists.openembedded.org/g/openembedded-core/message/149943
2. Though reproduced during a dunfell build, this should probably
apply else where as well.
3. I have'nt been able to cleanly bisect things, but my best guess was
that this might be a consequence of kernel fixup exposing this.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5b8ca97fbf8300a5e21c393df25ce6f521e7939
meta/classes/kernel-arch.bbclass | 3 +++
meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 07ec242e63bb..3d25fc7ac531 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -60,9 +60,12 @@ TARGET_LD_KERNEL_ARCH ?= ""
HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
TARGET_AR_KERNEL_ARCH ?= ""
HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
+TARGET_OBJCOPY_KERNEL_ARCH ?= ""
+HOST_OBJCOPY_KERNEL_ARCH ?= "${TARGET_OBJCOPY_KERNEL_ARCH}"
KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd
${DEBUG_PREFIX_MAP} -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH}"
KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
+KERNEL_OBJCOPY = "${CCACHE}${HOST_PREFIX}objcopy ${HOST_OBJCOPY_KERNEL_ARCH}"
TOOLCHAIN = "gcc"
diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 87b7d240f51a..2d73e8093c2e 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -25,7 +25,7 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
${BUILD_LDFLAGS}" HOSTCPP="
do_configure() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
for t in prepare scripts_basic scripts; do
- oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
AR="${KERNEL_AR}" \
+ oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}"
AR="${KERNEL_AR}" OBJCOPY="${KERNEL_OBJCOPY}"\
-C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
done
}
--
2.31.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149967):
https://lists.openembedded.org/g/openembedded-core/message/149967
Mute This Topic: https://lists.openembedded.org/mt/81618199/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] documentation-audit.sh: Fix typo in specifying LICENSE_FLAGS_WHITELIST
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
+++ b/scripts/contrib/documentation-audit.sh
@@ -27,7 +27,7 @@ fi
echo "REMINDER: you need to build for MACHINE=qemux86 or you won't get useful
results"
echo "REMINDER: you need to set LICENSE_FLAGS_WHITELIST appropriately in
local.conf or "
-echo " you'll get false positives. For example, LICENSE_FLAGS_WHITELIST =
\"Commercial\""
+echo " you'll get false positives. For example, LICENSE_FLAGS_WHITELIST =
\"commercial\""
for pkg in `bitbake -s | awk '{ print \$1 }'`; do
if [[ "$pkg" == "Loading" || "$pkg" == "Loaded" ||
--
2.31.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149966):
https://lists.openembedded.org/g/openembedded-core/message/149966
Mute This Topic: https://lists.openembedded.org/mt/81618162/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] gst-examples,gstreamer1.0-libav: Add option to exclude from world build
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: Yann Dirson
---
meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb | 2 ++
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb | 3 +++
2 files changed, 5 insertions(+)
diff --git a/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
b/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
index 4670ab34db..196258e00f 100644
--- a/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
@@ -33,3 +33,5 @@ RRECOMMENDS_${PN} = "gstreamer1.0-plugins-base-meta \
${@bb.utils.contains("LICENSE_FLAGS_WHITELIST",
"commercial", "gstreamer1.0-libav", "", d)} \
${@bb.utils.contains("LICENSE_FLAGS_WHITELIST",
"commercial", "gstreamer1.0-plugins-ugly-meta", "", d)}"
RPROVIDES_${PN} += "gst-player gst-player-bin"
+
+EXCLUDE_FROM_WORLD = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST",
"commercial", "0", "1", d)}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
index 6a84f92f31..7c39e7da37 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
@@ -6,6 +6,7 @@ SECTION = "multimedia"
# ffmpeg has comercial license flags so add it as we need ffmpeg as a
dependency
LICENSE_FLAGS = "commercial"
+
LICENSE = "LGPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
file://ext/libav/gstav.h;beginline=1;endline=18;md5=a752c35267d8276fd9ca3db6994fca9c
\
@@ -22,3 +23,5 @@ inherit meson pkgconfig upstream-version-is-even
FILES_${PN} += "${libdir}/gstreamer-1.0/*.so"
FILES_${PN}-staticdev += "${libdir}/gstreamer-1.0/*.a"
+
+EXCLUDE_FROM_WORLD = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST",
"commercial", "0", "1", d)}"
--
2.31.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149965):
https://lists.openembedded.org/g/openembedded-core/message/149965
Mute This Topic: https://lists.openembedded.org/mt/81618084/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 0/1] Enable PR Service support in eSDK
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 + meta/files/ext-sdk-prepare.py | 17 + 2 files changed, 42 insertions(+) -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149964): https://lists.openembedded.org/g/openembedded-core/message/149964 Mute This Topic: https://lists.openembedded.org/mt/81617272/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/1] populate_sdk_ext: Add support for PR service
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 write out a conf/prserv.inc file into
the eSDK. On eSDK install, if a conf/prserv.inc file is present we then
import this file into the system.
This mechanism will work if the PRSERV_HOST is local or remote, as it pulls
the necessary data from the server and then imports it to a local database
on eSDK installation.
Note: the conf/prserv.inc file is not deleted at this time. It was left
for possible debugging purposes, but removing it is something we could decide
to do in the future.
Signed-off-by: Mark Hatle
Signed-off-by: Mark Hatle
---
meta/classes/populate_sdk_ext.bbclass | 25 +
meta/files/ext-sdk-prepare.py | 17 +
2 files changed, 42 insertions(+)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index 14689ec6ac..84232ed9f5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -375,6 +375,10 @@ python copy_buildsystem () {
# Map gcc-dependent uninative sstate cache for installer usage
f.write('SSTATE_MIRRORS += " file://universal/(.*)
file://universal-4.9/\\1 file://universal-4.9/(.*)
file://universal-4.8/\\1"\n\n')
+if d.getVar("PRSERV_HOST"):
+# Override this, we now include PR data, so it should only
point ot the local database
+f.write('PRSERV_HOST = "localhost:0"\n\n')
+
# Allow additional config through sdk-extra.conf
fn = bb.cookerdata.findConfigFile('sdk-extra.conf', d)
if fn:
@@ -398,6 +402,27 @@ python copy_buildsystem () {
bb.utils.mkdirhier(os.path.join(baseoutpath, 'cache'))
shutil.copyfile(builddir + '/cache/bb_unihashes.dat', baseoutpath +
'/cache/bb_unihashes.dat')
+# If PR Service is in use, we need to export this as well
+bb.note('Do we have a pr database?')
+if d.getVar("PRSERV_HOST"):
+bb.note('Writing PR database...')
+# Based on the code in classes/prexport.bbclass
+import oe.prservice
+#dump meta info of tables
+localdata = d.createCopy()
+localdata.setVar('PRSERV_DUMPOPT_COL', "1")
+localdata.setVar('PRSERV_DUMPDIR', os.path.join(baseoutpath, 'conf'))
+localdata.setVar('PRSERV_DUMPFILE', '${PRSERV_DUMPDIR}/prserv.inc')
+
+bb.note('PR Database write to %s' %
(localdata.getVar('PRSERV_DUMPFILE')))
+
+retval = oe.prservice.prserv_dump_db(localdata)
+if not retval:
+bb.error("prexport_handler: export failed!")
+return
+(metainfo, datainfo) = retval
+oe.prservice.prserv_export_tofile(localdata, metainfo, datainfo, True)
+
# Use templateconf.cfg file from builddir if exists
if os.path.exists(builddir + '/conf/templateconf.cfg') and
use_custom_templateconf == '1':
shutil.copyfile(builddir + '/conf/templateconf.cfg', baseoutpath +
'/conf/templateconf.cfg')
diff --git a/meta/files/ext-sdk-prepare.py b/meta/files/ext-sdk-prepare.py
index 163d5e9912..d191e5e19c 100644
--- a/meta/files/ext-sdk-prepare.py
+++ b/meta/files/ext-sdk-prepare.py
@@ -44,6 +44,23 @@ def main():
sdk_targets = []
else:
sdk_targets = ' '.join(sys.argv[2:]).split()
+
+prserv = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'conf',
'prserv.inc')
+if os.path.isfile(prserv):
+with open(logfile, 'a') as logf:
+logf.write('Importing PR data...\n')
+
+ret = run_command_interruptible('bitbake-prserv-tool import %s' %
prserv)
+
+lastlog = get_last_consolelog()
+if lastlog:
+with open(lastlog, 'r') as f:
+for line in f:
+logf.write(line)
+if ret:
+print('ERROR: PR data import failed: error log written to %s'
% logfile)
+return ret
+
if not sdk_targets:
# Just do a parse so the cache is primed
ret = run_command_interruptible('bitbake -p --quiet')
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149963):
https://lists.openembedded.org/g/openembedded-core/message/149963
Mute This Topic: https://lists.openembedded.org/mt/81617271/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Autobuilder data collection for intermittent bugs
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.
Initially i modified yocto-autobuilder-helper/config.json and added the
following 3 lines to existing templates (and created a commit) that were
being used so that the builds would start collecting the data.
+ "BB_HEARTBEAT_EVENT = '5'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'pwd; ls'"
I also created a template in yocto-autobuilder-helper/config.json
+ "data-collect" : {
+ "BUILDINFO" : true,
+ "BBTARGETS" : "core-image-minimal",
+ "extravars" : [
+ "BB_HEARTBEAT_EVENT = '5'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'pwd; ls'"
+ ]
+ },
and modified a builder to use the template:
"beaglebone-alt" : {
- "MACHINE" : "beaglebone-yocto",
- "TEMPLATE" : "altcfg-hw"
+ "MACHINE" : "qemux86-64",
+ "TEMPLATE" : "data-collect"
},
Restarted both the controller and the worker, and started the
beaglebone-alt build. Once the build started, i checked the conf file in
the build directory but those lines were not appended to the local.conf
file and hence no log files.
You shouldn't need to restart the controller, the worker should pull and
use the configuration from the helper branch specified.
I'd note that it writes the config to auto.conf, not local.conf.
It should also give output in the logs about what its doing. For example:
https://autobuilder.yoctoproject.org/typhoon/#/builders/106/builds/2144/steps/10/logs/stdio
is the "Write config" step of beaglebone-alt on the autobuilder where it
clearly says:
Writing /home/pokybuild/yocto-worker/beaglebone-alt/build/build/conf/auto.conf
with contents:
What do your logs say?
In summary, I have been trying to get the 3 lines from the "extravars"
above to appear in one of the local.conf files. However none of the
builds seems to have been altered.
I am wondering if the changes that I've made are even being picked up by
the controller. Am I missing something?
Is there an easier way to update the conf files?
Initially I'd like collect data on a single node and scale it to all the
nodes. Any ideas/suggestions are welcome!
What you're doing should work. Its hard to comment more without seeing to logs
but check you're looking at auto.conf.
Thanks for the update Sakib.
We're planning to follow Steve's example of getting commit access to
contrib branches of y-a-h and poky and using the YP AB to start custom
workers/job initially. We'll also keep working to duplicate the
AB behaviour locally. Trevor has asked Konrad for an additional system
or two since when jobs are running, the web UI is
painfully slow since it's runnig on the same node right now.
The one part that Sakib didn't ask about is how to get all the workers
to do the data collection but that's not urgent since we'll be doing
some smaller scale experiments tomorrow. If you can point out a helpful
example, that'd be good.
Hopefully we'll have a good collection of data showing what processes
are running when the IO latency is > 5 seconds sometime next week.
../Randy
Cheers,
Richard
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149962):
https://lists.openembedded.org/g/openembedded-core/message/149962
Mute This Topic: https://lists.openembedded.org/mt/81615102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] master eSDK hash problem with METADATA_REVISION and base-files:do_install
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% |#| Time: 0:00:00 WARNING: The base-files:do_install sig is computed to be 587ccfa9299e26094ae342f1ce3d782bfaf776c639013428a511770c3828d49a, but the sig is locked to 0c35f266f1e79b1f34260df1b8d677f7eb74a7f7241155601ed73a014c8e286c in SIGGEN_LOCKEDSIGS_t-qemuarm Loading cache: 100% |##| Time: 0:00:00 Initialising tasks: 100% |#| Time: 0:00:00 Running a bitbake diffsigs on this file, I get: basehash changed from cffec52acb67f62fe3812d0d42d52b1081f9150386f43f0426f5469b4a1a6a25 to 332259212c5e9a4ed2a7fe25b8ea77cb54fb6b82f7deed90179e145f1d0cf1b6 Variable METADATA_REVISION value changed from '3210cabe56d6cf6d51638e6f31f93110e40ab2cd' to '' So it appears that some of the recent work on METADATA_REVISION has broken hash computations in the base-files package due to the value being 'unknown' in one, and set in the other. --Mark -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149961): https://lists.openembedded.org/g/openembedded-core/message/149961 Mute This Topic: https://lists.openembedded.org/mt/81616842/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] populate_sdk_ext: Avoid copying and producing .pyc files
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
---
meta/classes/populate_sdk_ext.bbclass | 4 +++-
meta/lib/oe/copy_buildsystem.py | 6 +++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index 9112ab6c5e..14689ec6ac 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -251,7 +251,9 @@ python copy_buildsystem () {
# Create a layer for new recipes / appends
bbpath = d.getVar('BBPATH')
-bb.process.run(['devtool', '--bbpath', bbpath, '--basepath', baseoutpath,
'create-workspace', '--create-only', os.path.join(baseoutpath, 'workspace')])
+env = os.environ.copy()
+env['PYTHONDONTWRITEBYTECODE'] = '1'
+bb.process.run(['devtool', '--bbpath', bbpath, '--basepath', baseoutpath,
'create-workspace', '--create-only', os.path.join(baseoutpath, 'workspace')],
env=env)
# Create bblayers.conf
bb.utils.mkdirhier(baseoutpath + '/conf')
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 31a84f5b06..d97bf9d1b9 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -20,7 +20,7 @@ def _smart_copy(src, dest):
mode = os.stat(src).st_mode
if stat.S_ISDIR(mode):
bb.utils.mkdirhier(dest)
-cmd = "tar --exclude='.git' --xattrs --xattrs-include='*' -chf - -C %s
-p . \
+cmd = "tar --exclude='.git' --exclude='__pycache__' --xattrs
--xattrs-include='*' -chf - -C %s -p . \
| tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dest)
subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
else:
@@ -259,7 +259,7 @@ def create_locked_sstate_cache(lockedsigs,
input_sstate_cache, output_sstate_cac
bb.note('Generating sstate-cache...')
nativelsbstring = d.getVar('NATIVELSBSTRING')
-bb.process.run("gen-lockedsig-cache %s %s %s %s %s" % (lockedsigs,
input_sstate_cache, output_sstate_cache, nativelsbstring, filterfile or ''))
+bb.process.run("PYTHONDONTWRITEBYTECODE=1 gen-lockedsig-cache %s %s %s %s
%s" % (lockedsigs, input_sstate_cache, output_sstate_cache, nativelsbstring,
filterfile or ''))
if fixedlsbstring and nativelsbstring != fixedlsbstring:
nativedir = output_sstate_cache + '/' + nativelsbstring
if os.path.isdir(nativedir):
@@ -286,7 +286,7 @@ def check_sstate_task_list(d, targets, filteroutfile,
cmdprefix='', cwd=None, lo
logparam = '-l %s' % logfile
else:
logparam = ''
-cmd = "%sBB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1 oe-check-sstate %s -s -o
%s %s" % (cmdprefix, targets, filteroutfile, logparam)
+cmd = "%sPYTHONDONTWRITEBYTECODE=1 BB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1
oe-check-sstate %s -s -o %s %s" % (cmdprefix, targets, filteroutfile, logparam)
env = dict(d.getVar('BB_ORIGENV', False))
env.pop('BUILDDIR', '')
env.pop('BBPATH', '')
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149960):
https://lists.openembedded.org/g/openembedded-core/message/149960
Mute This Topic: https://lists.openembedded.org/mt/81615695/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Autobuilder data collection for intermittent bugs
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 yocto-autobuilder-helper/config.json and added the
> following 3 lines to existing templates (and created a commit) that were
> being used so that the builds would start collecting the data.
>
>
> + "BB_HEARTBEAT_EVENT = '5'",
> + "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
> + "BB_LOG_HOST_STAT_CMDS = 'pwd; ls'"
>
> I also created a template in yocto-autobuilder-helper/config.json
>
> + "data-collect" : {
> + "BUILDINFO" : true,
> + "BBTARGETS" : "core-image-minimal",
> + "extravars" : [
> + "BB_HEARTBEAT_EVENT = '5'",
> + "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
> + "BB_LOG_HOST_STAT_CMDS = 'pwd; ls'"
> + ]
> + },
>
> and modified a builder to use the template:
>
> "beaglebone-alt" : {
> - "MACHINE" : "beaglebone-yocto",
> - "TEMPLATE" : "altcfg-hw"
> + "MACHINE" : "qemux86-64",
> + "TEMPLATE" : "data-collect"
> },
>
> Restarted both the controller and the worker, and started the
> beaglebone-alt build. Once the build started, i checked the conf file in
> the build directory but those lines were not appended to the local.conf
> file and hence no log files.
You shouldn't need to restart the controller, the worker should pull and
use the configuration from the helper branch specified.
I'd note that it writes the config to auto.conf, not local.conf.
It should also give output in the logs about what its doing. For example:
https://autobuilder.yoctoproject.org/typhoon/#/builders/106/builds/2144/steps/10/logs/stdio
is the "Write config" step of beaglebone-alt on the autobuilder where it
clearly says:
Writing /home/pokybuild/yocto-worker/beaglebone-alt/build/build/conf/auto.conf
with contents:
What do your logs say?
> In summary, I have been trying to get the 3 lines from the "extravars"
> above to appear in one of the local.conf files. However none of the
> builds seems to have been altered.
>
> I am wondering if the changes that I've made are even being picked up by
> the controller. Am I missing something?
>
> Is there an easier way to update the conf files?
>
> Initially I'd like collect data on a single node and scale it to all the
> nodes. Any ideas/suggestions are welcome!
What you're doing should work. Its hard to comment more without seeing to logs
but check you're looking at auto.conf.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149959):
https://lists.openembedded.org/g/openembedded-core/message/149959
Mute This Topic: https://lists.openembedded.org/mt/81615102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe-core][PATCH v2 1/2] valgrind: update 3.16.1 -> 3.17.0
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 ppc64le: found in 74b74174d572fee4015b8f4e326db3cd949bcdc3
Other dropped patches
* helgrind intercept: found in d2d54dbcc74244adfc0c80b40862edf2b82f53b9
* drd musl fix: found in d2d54dbcc74244adfc0c80b40862edf2b82f53b9
TESTING RESULTS:
qemux86-64:
FAIL: drd/tests/swapcontext
3.17.0 3.16.1
===
TOTAL: 736726
PASSED: 694688
FAILED: 1 0
SKIPPED: 41 38
Signed-off-by: Yi Fan Yu
---
Changes for V2:
minor edit to commit msg
fix reproducibility
+# point the expanded @abs_top_builddir@ of the host to PTEST_PATH
+sed -i s:${S}:${PTEST_PATH}:g \
+${D}${PTEST_PATH}/memcheck/tests/linux/debuginfod-check.vgtest
---
.../valgrind/0001-Add-missing-musl.supp.patch | 72 +++
...gtest-hanging-on-newer-glibc-and-or-.patch | 200 --
.../valgrind/0001-drd-Port-to-Fedora-33.patch | 48 -
.../valgrind/valgrind/0001-drd-musl-fix.patch | 31 ---
...01-helgrind-Intercept-libc-functions.patch | 54 -
...ated-PowerPC-insns-aren-t-allowed-on.patch | 62 --
...eak_cmsg.stderr.exp-adjust-tmp-paths.patch | 2 +-
...ntext-APIs-are-not-available-on-musl.patch | 50 -
.../valgrind/valgrind/fixed-perl-path.patch | 20 +-
.../valgrind/valgrind/run-ptest | 3 +-
.../valgrind/valgrind/s390x_vec_op_t.patch| 24 ++-
...{valgrind_3.16.1.bb => valgrind_3.17.0.bb} | 25 ++-
12 files changed, 165 insertions(+), 426 deletions(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-drd-Port-to-Fedora-33.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-drd-musl-fix.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-helgrind-Intercept-libc-functions.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch
rename meta/recipes-devtools/valgrind/{valgrind_3.16.1.bb =>
valgrind_3.17.0.bb} (92%)
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
b/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
new file mode 100644
index 00..2a73f7e81f
--- /dev/null
+++ b/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
@@ -0,0 +1,72 @@
+From 61bc8664f93cd980831c9da4a3e8a385b089a0ab Mon Sep 17 00:00:00 2001
+From: Yi Fan Yu
+Date: Tue, 23 Mar 2021 09:32:22 -0700
+Subject: [PATCH] Add missing musl.supp
+
+3.17 did not ship musl.supp in the tarball.
+
+This is a workaround until next release.
+
+Upstream-Status: Backport [dde556d51f8226a6de564a00bf82536bb7042c54]
+
+Signed-off-by: Yi Fan Yu
+---
+ musl.supp | 46 ++
+ 1 file changed, 46 insertions(+)
+ create mode 100644 musl.supp
+
+diff --git a/musl.supp b/musl.supp
+new file mode 100644
+index 0..864172a24
+--- /dev/null
b/musl.supp
+@@ -0,0 +1,46 @@
++# Suppressions for musl libc
++# See: https://www.openwall.com/lists/musl/2017/06/15/4
++
++{
++ musl-dynlink-false-positive1
++ Memcheck:Leak
++ fun:calloc
++ fun:load_direct_deps
++ fun:load_deps
++ fun:load_deps
++ fun:__dls3
++ fun:__dls2b
++ fun:__dls2
++}
++
++{
++ musl-dynlink-false-positive2
++ Memcheck:Leak
++ fun:calloc
++ fun:load_direct_deps
++ fun:load_deps
++ fun:load_deps
++ fun:__dls3
++ fun:__dls2
++}
++
++{
++ musl-dynlink-false-positive3
++ Memcheck:Leak
++ fun:calloc
++ fun:load_library
++ fun:load_preload
++ fun:__dls3
++ fun:__dls2b
++ fun:__dls2
++}
++
++{
++ musl-dynlink-false-positive4
++ Memcheck:Leak
++ fun:calloc
++ fun:load_library
++ fun:load_preload
++ fun:__dls3
++ fun:__dls2
++}
+--
+2.17.1
+
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
b/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
deleted file mode 100644
index 98cbcd132c..00
---
a/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
+++ /dev/null
@@ -1,200 +0,0 @@
-From 83c24e31df6932a6d4fced179050c6d8d8c6f3b5 Mon Sep 17 00:00:00 2001
-From: Philippe Waroquiers
-Date: Sun, 7 Mar 2021 22:29:27 +0100
-Subject: [PATCH] Fix nlcontrolc.vgtest hanging on newer glibc and/or arm64
-
-This test verifies that GDB can interrupt a process with all threads
-blocked in a long select syscall.
-The test used to terminate by having
[oe-core][PATCH v2 2/2] valgrind: Disable ptest swapcontext.vgtest
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 mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
new file mode 100644
index 00..f217098650
--- /dev/null
+++
b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
@@ -0,0 +1,28 @@
+From 0f1814a618eff4233e9e8379a8cb2dededdc5a8b Mon Sep 17 00:00:00 2001
+From: Yi Fan Yu
+Date: Tue, 23 Mar 2021 11:09:20 -0700
+Subject: [PATCH] Disable temporarily drd/tests/swapcontext.vgtest
+
+New test introduced in valgrind 3.17.0.
+Test fails on both qemuarm64 and qemux64.
+
+Upstream-Status: Pending [Needs more Investigation]
+
+Signed-off-by: Yi Fan Yu
+---
+ drd/tests/swapcontext.vgtest | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drd/tests/swapcontext.vgtest b/drd/tests/swapcontext.vgtest
+index 98e3712c4..5492da31d 100644
+--- a/drd/tests/swapcontext.vgtest
b/drd/tests/swapcontext.vgtest
+@@ -1,4 +1,4 @@
+-prereq: test -e swapcontext && ./supported_libpthread
++prereq: false
+ vgopts: --read-var-info=yes --check-stack-var=yes --show-confl-seg=no
--num-callers=2
+ prog: swapcontext
+ stderr_filter: filter_stderr
+--
+2.17.1
+
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
index 1e29896596..7a6b766121 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
@@ -43,6 +43,7 @@ SRC_URI =
"https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
file://0001-none-tests-fdleak_cmsg.stderr.exp-adjust-tmp-paths.patch \
file://0001-memcheck-tests-Fix-timerfd-syscall-test.patch \
file://0001-Add-missing-musl.supp.patch \
+ file://0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch \
"
SRC_URI[md5sum] = "afe11b5572c3121a781433b7c0ab741b"
SRC_URI[sha256sum] =
"ad3aec668e813e40f238995f60796d9590eee64a16dff88421430630e69285a2"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149958):
https://lists.openembedded.org/g/openembedded-core/message/149958
Mute This Topic: https://lists.openembedded.org/mt/81615169/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Autobuilder data collection for intermittent bugs
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 existing templates (and created a commit) that were
being used so that the builds would start collecting the data.
+ "BB_HEARTBEAT_EVENT = '5'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'pwd; ls'"
I also created a template in yocto-autobuilder-helper/config.json
+ "data-collect" : {
+ "BUILDINFO" : true,
+ "BBTARGETS" : "core-image-minimal",
+ "extravars" : [
+ "BB_HEARTBEAT_EVENT = '5'",
+ "BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
+ "BB_LOG_HOST_STAT_CMDS = 'pwd; ls'"
+ ]
+ },
and modified a builder to use the template:
"beaglebone-alt" : {
- "MACHINE" : "beaglebone-yocto",
- "TEMPLATE" : "altcfg-hw"
+ "MACHINE" : "qemux86-64",
+ "TEMPLATE" : "data-collect"
},
Restarted both the controller and the worker, and started the
beaglebone-alt build. Once the build started, i checked the conf file in
the build directory but those lines were not appended to the local.conf
file and hence no log files.
In summary, I have been trying to get the 3 lines from the "extravars"
above to appear in one of the local.conf files. However none of the
builds seems to have been altered.
I am wondering if the changes that I've made are even being picked up by
the controller. Am I missing something?
Is there an easier way to update the conf files?
Initially I'd like collect data on a single node and scale it to all the
nodes. Any ideas/suggestions are welcome!
Sincerely,
Sakib Sajal
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149956):
https://lists.openembedded.org/g/openembedded-core/message/149956
Mute This Topic: https://lists.openembedded.org/mt/81615102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] linux-yocto/5.4: update to v5.4.107
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 crypto: x86/aes-ni-xts - use direct calls to and 4-way stride ae69c97bb76e crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg eeb0899e0073 crypto: x86 - Regularize glue function prototypes 187ae0463653 fuse: fix live lock in fuse_iget() 28e53acd3065 drm/i915/gvt: Fix vfio_edid issue for BXT/APL 5a7c72ffb412 drm/i915/gvt: Fix port number for BDW on EDID region setup 4ab29329668d drm/i915/gvt: Fix virtual display setup for BXT/APL e46f72e1f27c drm/i915/gvt: Fix mmio handler break on BXT/APL. 8cd68991b836 drm/i915/gvt: Set SNOOP for PAT3 on BXT/APL to workaround GPU BB hang 50f83ffc58ab btrfs: scrub: Don't check free space before marking a block group RO 591ea83fd2ce bpf, selftests: Fix up some test_verifier cases for unprivileged 4e4c85404a23 bpf: Add sanity check for upper ptr_limit 524471df8fa9 bpf: Simplify alu_limit masking for pointer arithmetic 2da0540739e4 bpf: Fix off-by-one for area size in creating mask to left ea8fb45eaac1 bpf: Prohibit alu ops for pointer types not defining ptr_limit 010c5bee66bd KVM: arm64: nvhe: Save the SPE context early 0437de26e28d Linux 5.4.106 b802b6ef28d6 xen/events: avoid handling the same event on two cpus at the same time 92aefc62f483 xen/events: don't unmask an event channel when an eoi is pending 43d0b82bb45c xen/events: reset affinity of 2-level event when tearing it down 38563c1ff081 KVM: arm64: Reject VM creation when the default IPA size is unsupported da2e37b55d4c KVM: arm64: Ensure I-cache isolation between vcpus of a same VM 4e2156c0d37b nvme: release namespace head reference on error eb565f052b3e nvme: unlink head after removing last namespace 4535fb9ec5fd KVM: arm64: Fix exclusive limit for IPA size e28b19ca2aeb x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2 c0e0ab60d0b1 binfmt_misc: fix possible deadlock in bm_register_write 106fea9ad246 powerpc/64s: Fix instruction encoding for lis in ppc_function_entry() 907f7f2cf0ff sched/membarrier: fix missing local execution of ipi_sync_rq_state() 2306580a95b7 zram: fix return value on writeback_store 29e28a134a49 include/linux/sched/mm.h: use rcu_dereference in in_vfork() 99f1960cae4f stop_machine: mark helpers __always_inline aaf92d0538d2 hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 88c79851b82d arm64: mm: use a 48-bit ID map when possible on 52-bit VA builds 73aa6f93e1e9 configfs: fix a use-after-free in __configfs_open_file babd55002dd4 block: rsxx: fix error return code of rsxx_pci_probe() 41deefab452a NFSv4.2: fix return value of _nfs4_get_security_label() 86954a52d829 NFS: Don't gratuitously clear the inode cache when lookup failed d29f9aa6a8b2 NFS: Don't revalidate the directory permissions on a lookup failure d5a69ed75931 SUNRPC: Set memalloc_nofs_save() for sync tasks 9c9ea7ac18b2 arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory 19bb2a20710d sh_eth: fix TRSCER mask for R7S72100 c3c1defad2dd staging: comedi: pcl818: Fix endian problem for AI command data c5916897a6e1 staging: comedi: pcl711: Fix endian problem for AI command data 7d8ec7bef320 staging: comedi: me4000: Fix endian problem for AI command data e70294943c89 staging: comedi: dmm32at: Fix endian problem for AI command data 47a2af64eea3 staging: comedi: das800: Fix endian problem for AI command data 0f2522ec71b6 staging: comedi: das6402: Fix endian problem for AI command data e91490b9edb9 staging: comedi: adv_pci1710: Fix endian problem for AI command data 4d6505edee5a staging: comedi: addi_apci_1500: Fix endian problem for command sample f258c1c26f64 staging: comedi: addi_apci_1032: Fix endian problem for COS sample e644fc4ab7bb staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan 8f586a59829b staging: rtl8712: Fix possible buffer overflow in r8712_sitesurvey_cmd 9fe42273b2c6 staging: ks7010: prevent buffer overflow in ks_wlan_set_scan() ab42f28d5f34 staging: rtl8188eu: fix potential memory corruption in rtw_check_beacon_data() 1a866057e970 staging: rtl8712: unterminated string leads to read overflow da5abe369b03 staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan() a311b6a7f099 staging: rtl8192u: fix ->ssid overflow in r8192_wx_set_scan() e4b52c7cbaaf misc: fastrpc: restrict user apps from sending kernel RPC messages 9009b59dfd5f misc/pvpanic: Export module FDT device table 0a58a400a93b usbip: fix vudc usbip_sockfd_store races leading to gpf 8a50dda5243e usbip: fix vhci_hcd attach_store() races
[OE-core] [PATCH 1/3] linux-yocto/5.10: update to v5.10.25
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 disconnection df8596f57743 Revert "nfsd4: a client's own opens needn't prevent delegations" 894ecf0cb505 Revert "nfsd4: remove check_conflicting_opens warning" d955f13ea212 fuse: fix live lock in fuse_iget() 2d7888b2c4cd RDMA/srp: Fix support for unpopulated and unbalanced NUMA nodes 3672c3ce622e bpf, selftests: Fix up some test_verifier cases for unprivileged 1010f17aaa78 bpf: Add sanity check for upper ptr_limit 6a3504bf4006 bpf: Simplify alu_limit masking for pointer arithmetic ac1b87a18c1f bpf: Fix off-by-one for area size in creating mask to left c4d37eea1c64 bpf: Prohibit alu ops for pointer types not defining ptr_limit bf93113d46f8 crypto: x86/aes-ni-xts - use direct calls to and 4-way stride fcfab1a9aa40 crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg 05d125f7524e Linux 5.10.24 1c0899636d44 RDMA/umem: Use ib_dma_max_seg_size instead of dma_get_max_seg_size 1dbce9ba2aa9 KVM: arm64: Fix nVHE hyp panic host context restore f67e5243d0f3 xen/events: avoid handling the same event on two cpus at the same time 30cdb862e831 xen/events: don't unmask an event channel when an eoi is pending 4c84191cbc3e mm/page_alloc.c: refactor initialization of struct page for holes in memory layout e7afadd0dbe2 KVM: arm64: Ensure I-cache isolation between vcpus of a same VM 518f98e39077 mm/madvise: replace ptrace attach requirement for process_madvise 2aaa79f69417 mm/userfaultfd: fix memory corruption due to writeprotect c3d70b1bf1ce KVM: arm64: Fix exclusive limit for IPA size ada8817ab674 KVM: arm64: Reject VM creation when the default IPA size is unsupported eeba4e4cc524 KVM: arm64: nvhe: Save the SPE context early a9779820bb97 KVM: arm64: Avoid corrupting vCPU context register in guest exit 17becbfca9fc KVM: arm64: Fix range alignment when walking page tables a688bf8cf550 KVM: kvmclock: Fix vCPUs > 64 can't be online/hotpluged 4ab5d1b70929 KVM: x86: Ensure deadline timer has truly expired before posting its IRQ e40384fcd600 x86/entry: Fix entry/exit mismatch on failed fast 32-bit syscalls a2bab396cb97 x86/sev-es: Use __copy_from_user_inatomic() 977b9f4190ad x86/sev-es: Correctly track IRQ states in runtime #VC handler 269424432731 x86/entry: Move nmi entry/exit into common code 752fbe0c8ddd x86/sev-es: Check regs->sp is trusted before adjusting #VC IST stack 871fd1e3ee8e x86/sev-es: Introduce ip_within_syscall_gap() helper d327d8632cdb x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2 5ab9464a2a3c binfmt_misc: fix possible deadlock in bm_register_write 0e4750f69c17 powerpc: Fix missing declaration of [en/dis]able_kernel_vsx() 1f372e89567b powerpc: Fix inverted SET_FULL_REGS bitop 9776812ee861 powerpc/64s: Fix instruction encoding for lis in ppc_function_entry() 8571c66401ea efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table 68b4378d910e sched/membarrier: fix missing local execution of ipi_sync_rq_state() 5f2f616343b1 linux/compiler-clang.h: define HAVE_BUILTIN_BSWAP* bc7c1b09f7a4 zram: fix return value on writeback_store 3cbe8f9193e6 include/linux/sched/mm.h: use rcu_dereference in in_vfork() 7da7542c04a4 stop_machine: mark helpers __always_inline 2a39eb7b8670 seqlock,lockdep: Fix seqcount_latch_init() 372734dc1897 powerpc/64s/exception: Clean up a missed SRR specifier df7dbfc24c33 hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() 896846b8151d perf/x86/intel: Set PERF_ATTACH_SCHED_CB for large PEBS and LBR 82ad50c112f8 perf/core: Flush PMU internal buffers for per-CPU events 3ebd4bd2eb6f arm64: mm: use a 48-bit ID map when possible on 52-bit VA builds 109720342efd configfs: fix a use-after-free in __configfs_open_file 6cf11f3a09a2 nvme-fc: fix racing controller reset and create association d1d918492e6e block: rsxx: fix error return code of rsxx_pci_probe() caa86901c863 NFSv4.2: fix return value of _nfs4_get_security_label() e181960ec51d NFS: Don't gratuitously clear the inode cache when lookup failed dd756d05bee5 NFS: Don't revalidate the directory permissions on a lookup failure faa48b23d0e3 SUNRPC: Set memalloc_nofs_save() for sync tasks 475a4307c14c arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory e50ada589497 cpufreq: qcom-hw: Fix return value check in qcom_cpufreq_hw_cpu_init() 7dfe37e9ea69 cpufreq: qcom-hw: fix dereferencing freed memory 'data' 75d9be57cf2e sh_eth: fix TRSCER mask for R7S72100 a854bd051465 staging: comedi: pcl818: Fix endian problem for AI command data
[OE-core] [PATCH 0/3] linux-yocto: -stable updates
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 commit ea455ca8671d3bc2a1097989bfaabe92f3ca37ab: build-appliance-image: Update to master head revision (2021-03-23 22:56:44 +) are available in the Git repository at: git://git.yoctoproject.org/poky-contrib zedd/kernel http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (3): linux-yocto/5.10: update to v5.10.25 linux-yocto/5.4: update to v5.4.107 linux-yocto-rt/5.10: update to -rt34 .../linux/linux-yocto-rt_5.10.bb | 6 ++--- .../linux/linux-yocto-rt_5.4.bb | 6 ++--- .../linux/linux-yocto-tiny_5.10.bb| 8 +++ .../linux/linux-yocto-tiny_5.4.bb | 8 +++ meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 +-- meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 - 6 files changed, 37 insertions(+), 37 deletions(-) -- 2.19.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149952): https://lists.openembedded.org/g/openembedded-core/message/149952 Mute This Topic: https://lists.openembedded.org/mt/81612931/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] linux-yocto-rt/5.10: update to -rt34
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
75e139bb405a v5.10.17-rt32
209e0ad0f61d printk: Update the printk code
f1e0daad5cd4 trace: Add the flags for need_resched_lazy()
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index 840cef88e2..cb34887cda 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -11,7 +11,7 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "5ae660cafcd609de82c450999487d4e6169f9f1f"
+SRCREV_machine ?= "be2935bce35f9adb6d0e735d42651e81a5094adf"
SRCREV_meta ?= "031f6c76e488a3563f35258c72ff1de3e25a512e"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
--
2.19.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149955):
https://lists.openembedded.org/g/openembedded-core/message/149955
Mute This Topic: https://lists.openembedded.org/mt/81612936/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] grub-efi: Fix build failure on RISCV32
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
>RV32.
Alistair
> ---
> ...sable-offset-overflow-check-for-rv32.patch | 45 +++
> meta/recipes-bsp/grub/grub2.inc | 1 +
> 2 files changed, 46 insertions(+)
> create mode 100644
> meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
>
> diff --git
> a/meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
>
> b/meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
> new file mode 100644
> index 00..6547bf2261
> --- /dev/null
> +++
> b/meta/recipes-bsp/grub/files/0001-Disable-offset-overflow-check-for-rv32.patch
> @@ -0,0 +1,45 @@
> +From ce1cea0563011698e4a70c9a60e7da66b57ab1d6 Mon Sep 17 00:00:00 2001
> +From: Khem Raj
> +Date: Wed, 24 Mar 2021 20:55:56 -0700
> +Subject: [PATCH] Disable offset overflow check for rv32
> +
> +Fixes
> +/tmp/grub/grub-mkimage: error: target 17c6 not reachable from pc=936.
> +
> +Upstream-Status: Reported [https://savannah.gnu.org/bugs/index.php?60283]
> +Signed-off-by: Khem Raj
> +---
> + util/grub-mkimagexx.c | 6 --
> + 1 file changed, 4 insertions(+), 2 deletions(-)
> +
> +diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
> +index 00f49ccaa..6deb66226 100644
> +--- a/util/grub-mkimagexx.c
> b/util/grub-mkimagexx.c
> +@@ -1297,9 +1297,10 @@ SUFFIX (relocate_addrs) (Elf_Ehdr *e, struct
> section_metadata *smd,
> +{
> + grub_uint32_t hi20, lo12;
> +
> ++#ifdef MKIMAGE_ELF64
> + if (off != (grub_int32_t)off)
> +grub_util_error ("target %lx not reachable from
> pc=%lx", (long)sym_addr, (long)((char *)target - (char *)e));
> +-
> ++#endif
> + hi20 = (off + 0x800) & 0xf000;
> + lo12 = (off - hi20) & 0xfff;
> + t32[0] = grub_host_to_target32 ((grub_target_to_host32
> (t32[0]) & 0xfff) | hi20);
> +@@ -1336,9 +1337,10 @@ SUFFIX (relocate_addrs) (Elf_Ehdr *e, struct
> section_metadata *smd,
> +{
> + grub_int32_t hi20;
> +
> ++#ifdef MKIMAGE_ELF64
> + if (off != (grub_int32_t)off)
> +grub_util_error ("target %lx not reachable from
> pc=%lx", (long)sym_addr, (long)((char *)target - (char *)e));
> +-
> ++#endif
> + hi20 = (off + 0x800) & 0xf000;
> + *t32 = grub_host_to_target32 ((grub_target_to_host32
> (*t32) & 0xfff) | hi20);
> +}
> +--
> +2.31.0
> +
> diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
> index bcff676c26..d8a556e06c 100644
> --- a/meta/recipes-bsp/grub/grub2.inc
> +++ b/meta/recipes-bsp/grub/grub2.inc
> @@ -19,6 +19,7 @@ SRC_URI =
> "https://alpha.gnu.org/gnu/grub/grub-${REALPV}.tar.xz \
> file://grub-module-explicitly-keeps-symbole-.module_license.patch
> \
> file://0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch \
> file://determinism.patch \
> + file://0001-Disable-offset-overflow-check-for-rv32.patch \
> "
>
> SRC_URI[sha256sum] =
> "2c87f1f21e2ab50043e6cd9163c08f1b6c3a6171556bf23ff9ed65b074145484"
> --
> 2.31.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149951):
https://lists.openembedded.org/g/openembedded-core/message/149951
Mute This Topic: https://lists.openembedded.org/mt/81595170/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH][gatesgarth][dunfell] openssl: update to 1.1.1k to fix CVE-2021-3450 and CVE-2021-3449
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 meta/recipes-connectivity/openssl/{openssl_1.1.1j.bb =>
openssl_1.1.1k.bb} (98%)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
index f054d2fdba..5f281197c9 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
@@ -23,7 +23,7 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
-SRC_URI[sha256sum] =
"aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf"
+SRC_URI[sha256sum] =
"892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5"
inherit lib_package multilib_header multilib_script ptest
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149950):
https://lists.openembedded.org/g/openembedded-core/message/149950
Mute This Topic: https://lists.openembedded.org/mt/81611322/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH][master] openssl: update to 1.1.1k to fix CVE-2021-3450 and CVE-2021-3449
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 meta/recipes-connectivity/openssl/{openssl_1.1.1j.bb =>
openssl_1.1.1k.bb} (98%)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
index ed6d7e0cd4..e518cb6a02 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
@@ -28,7 +28,7 @@ SRC_URI_append_riscv32 = " \
file://0004-Fixup-support-for-io_pgetevents_time64-syscall.patch \
"
-SRC_URI[sha256sum] =
"aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf"
+SRC_URI[sha256sum] =
"892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5"
inherit lib_package multilib_header multilib_script ptest
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149949):
https://lists.openembedded.org/g/openembedded-core/message/149949
Mute This Topic: https://lists.openembedded.org/mt/81611320/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 1/3] meson: fix native/host confusion in gobject-introspection
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 patches in your set? I just sent a mail which sort-of answers this question without seeing it. Basically, the change is that Meson now knows that it should call pkg-config-native for native pkgconfig lookups. Before, it was using pkg-config. As far as I can tell there is very little code which hits that codepath, so we didn't notice. When setting pkgconfig-native correctly, this broke. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149948): https://lists.openembedded.org/g/openembedded-core/message/149948 Mute This Topic: https://lists.openembedded.org/mt/81608826/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/2] meson: use native-file instead of environment variables
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 recipes too.
This means that when the G-I code uses a native pkgconfig lookup to
get target library dependencies, it goes terribly wrong.
Upstream are basically confused as to how "cross" and "G-I" are meant
to work, because they from a glance can't easily, so I expect to be
able to get this patch upstream as it doesn't break what already works
and is a step towards the correct model.
Ross
On Tue, 23 Mar 2021 at 21:28, Ross Burton via lists.openembedded.org
wrote:
>
> 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 | 49 --
> 1 file changed, 21 insertions(+), 28 deletions(-)
>
> diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> index a7644e70cb..290b39e1e0 100644
> --- a/meta/classes/meson.bbclass
> +++ b/meta/classes/meson.bbclass
> @@ -26,7 +26,8 @@ MESONOPTS = " --prefix ${prefix} \
>--sysconfdir ${sysconfdir} \
>--localstatedir ${localstatedir} \
>--sharedstatedir ${sharedstatedir} \
> - --wrap-mode nodownload"
> + --wrap-mode nodownload \
> + --native-file ${WORKDIR}/native.cross"
>
> EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
>
> @@ -121,9 +122,28 @@ system = '${@meson_operating_system('TARGET_OS', d)}'
> cpu_family = '${@meson_cpu_family('TARGET_ARCH', d)}'
> cpu = '${TARGET_ARCH}'
> endian = '${@meson_endian('TARGET', d)}'
> +EOF
> +
> +cat >${WORKDIR}/native.cross < +[binaries]
> +c = ${@meson_array('BUILD_CC', d)}
> +cpp = ${@meson_array('BUILD_CXX', d)}
> +ar = ${@meson_array('BUILD_AR', d)}
> +nm = ${@meson_array('BUILD_NM', d)}
> +strip = ${@meson_array('BUILD_STRIP', d)}
> +readelf = ${@meson_array('BUILD_READELF', d)}
> +pkgconfig = 'pkg-config-native'
> +
> +[properties]
> +needs_exe_wrapper = false
> +c_args = ${@meson_array('BUILD_CFLAGS', d)}
> +c_link_args = ${@meson_array('BUILD_LDFLAGS', d)}
> +cpp_args = ${@meson_array('BUILD_CXXFLAGS', d)}
> +cpp_link_args = ${@meson_array('BUILD_LDFLAGS', d)}
> EOF
> }
>
> +# Tell externalsrc that changes to this file require a reconfigure
> CONFIGURE_FILES = "meson.build"
>
> meson_do_configure() {
> @@ -140,33 +160,6 @@ meson_do_configure() {
> fi
> }
>
> -override_native_tools() {
> -# Set these so that meson uses the native tools for its build sanity
> tests,
> -# which require executables to be runnable. The cross file will still
> -# override these for the target build.
> -export CC="${BUILD_CC}"
> -export CXX="${BUILD_CXX}"
> -export LD="${BUILD_LD}"
> -export AR="${BUILD_AR}"
> -export STRIP="${BUILD_STRIP}"
> -# These contain *target* flags but will be used as *native* flags. The
> -# correct native flags will be passed via -Dc_args and so on, unset them
> so
> -# they don't interfere with tools invoked by Meson (such as g-ir-scanner)
> -unset CPPFLAGS CFLAGS CXXFLAGS LDFLAGS
> -}
> -
> -meson_do_configure_prepend_class-target() {
> -override_native_tools
> -}
> -
> -meson_do_configure_prepend_class-nativesdk() {
> -override_native_tools
> -}
> -
> -meson_do_configure_prepend_class-native() {
> -export PKG_CONFIG="pkg-config-native"
> -}
> -
> python meson_do_qa_configure() {
> import re
> warn_re = re.compile(r"^WARNING: Cross property (.+) is using default
> value (.+)$", re.MULTILINE)
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149947):
https://lists.openembedded.org/g/openembedded-core/message/149947
Mute This Topic: https://lists.openembedded.org/mt/81562048/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V2] linux-firmware: Package RSI 911x WiFi firmware
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 ? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149946): https://lists.openembedded.org/g/openembedded-core/message/149946 Mute This Topic: https://lists.openembedded.org/mt/81290193/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 1/3] meson: fix native/host confusion in gobject-introspection
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 Burton wrote:
> 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
> ---
> meta/recipes-devtools/meson/meson.inc | 1 +
> .../meson/meson/gi-target-dep.patch | 41 +++
> 2 files changed, 42 insertions(+)
> create mode 100644 meta/recipes-devtools/meson/meson/gi-target-dep.patch
>
> diff --git a/meta/recipes-devtools/meson/meson.inc
> b/meta/recipes-devtools/meson/meson.inc
> index fc3ca85fae..e186dede92 100644
> --- a/meta/recipes-devtools/meson/meson.inc
> +++ b/meta/recipes-devtools/meson/meson.inc
> @@ -15,6 +15,7 @@ SRC_URI = "
> https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> file://cross-prop-default.patch \
>
> file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
>
> file://0001-minstall-Correctly-set-uid-gid-of-installed-files.patch \
> + file://gi-target-dep.patch \
> "
> SRC_URI[sha256sum] =
> "72e1c782ba9bda204f4a1ed57f98d027d7b6eb9414c723eebbd6ec7f1955c8a6"
>
> diff --git a/meta/recipes-devtools/meson/meson/gi-target-dep.patch
> b/meta/recipes-devtools/meson/meson/gi-target-dep.patch
> new file mode 100644
> index 00..25b30ca27a
> --- /dev/null
> +++ b/meta/recipes-devtools/meson/meson/gi-target-dep.patch
> @@ -0,0 +1,41 @@
> +When building gobject-introspection we want the *native* binaries (as
> they need
> +to be executed) but *host* gobject-introspection libraries, as otherwise
> the
> +native pkg-config can be used and the build will try to link native and
> host
> +binaries together.
> +
> +Upstream-Status: Pending
> +Signed-off-by: Ross Burton
> +
> +diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
> +index f9660838e..2eefc3fc7 100644
> +--- a/mesonbuild/modules/gnome.py
> b/mesonbuild/modules/gnome.py
> +@@ -84,8 +84,8 @@ class GnomeModule(ExtensionModule):
> + mlog.bold('
> https://github.com/mesonbuild/meson/issues/1387'),
> + once=True)
> +
> +-def _get_native_dep(self, state, depname, required=True):
> +-kwargs = {'native': True, 'required': required}
> ++def _get_dep(self, state, depname, native=False, required=True):
> ++kwargs = {'native': native, 'required': required}
> + holder = self.interpreter.func_dependency(state.current_node,
> [depname], kwargs)
> + return holder.held_object
> +
> +@@ -101,7 +101,7 @@ class GnomeModule(ExtensionModule):
> + return ExternalProgram.from_entry(name, prog)
> +
> + # Check if pkgconfig has a variable
> +-dep = self._get_native_dep(state, depname, required=False)
> ++dep = self._get_dep(state, depname, native=True, required=False)
> + if dep.found() and dep.type_name == 'pkgconfig':
> + value = dep.get_pkgconfig_variable(varname, {})
> + if value:
> +@@ -481,7 +481,7 @@ class GnomeModule(ExtensionModule):
> +
> + def _get_gir_dep(self, state):
> + if not self.gir_dep:
> +-self.gir_dep = self._get_native_dep(state,
> 'gobject-introspection-1.0')
> ++self.gir_dep = self._get_dep(state,
> 'gobject-introspection-1.0')
> + self.giscanner = self._get_native_binary(state,
> 'g-ir-scanner', 'gobject-introspection-1.0', 'g_ir_scanner')
> + self.gicompiler = self._get_native_binary(state,
> 'g-ir-compiler', 'gobject-introspection-1.0', 'g_ir_compiler')
> + return self.gir_dep, self.giscanner, self.gicompiler
> --
> 2.25.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149945):
https://lists.openembedded.org/g/openembedded-core/message/149945
Mute This Topic: https://lists.openembedded.org/mt/81608826/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 2/3] bitbake.conf: ensure BUILD_* tools match target tools
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
+++ b/meta/conf/bitbake.conf
@@ -541,7 +541,10 @@ export BUILD_AR = "${BUILD_PREFIX}ar"
export BUILD_AS = "${BUILD_PREFIX}as ${BUILD_AS_ARCH}"
export BUILD_RANLIB = "${BUILD_PREFIX}ranlib"
export BUILD_STRIP = "${BUILD_PREFIX}strip"
+BUILD_OBJCOPY = "${BUILD_PREFIX}objcopy"
+BUILD_OBJDUMP = "${BUILD_PREFIX}objdump"
export BUILD_NM = "${BUILD_PREFIX}nm"
+BUILD_READELF = "${BUILD_PREFIX}readelf"
export MAKE = "make"
EXTRA_OEMAKE = ""
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149943):
https://lists.openembedded.org/g/openembedded-core/message/149943
Mute This Topic: https://lists.openembedded.org/mt/81608827/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 1/3] meson: fix native/host confusion in gobject-introspection
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
---
meta/recipes-devtools/meson/meson.inc | 1 +
.../meson/meson/gi-target-dep.patch | 41 +++
2 files changed, 42 insertions(+)
create mode 100644 meta/recipes-devtools/meson/meson/gi-target-dep.patch
diff --git a/meta/recipes-devtools/meson/meson.inc
b/meta/recipes-devtools/meson/meson.inc
index fc3ca85fae..e186dede92 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -15,6 +15,7 @@ SRC_URI =
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
file://cross-prop-default.patch \
file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
file://0001-minstall-Correctly-set-uid-gid-of-installed-files.patch
\
+ file://gi-target-dep.patch \
"
SRC_URI[sha256sum] =
"72e1c782ba9bda204f4a1ed57f98d027d7b6eb9414c723eebbd6ec7f1955c8a6"
diff --git a/meta/recipes-devtools/meson/meson/gi-target-dep.patch
b/meta/recipes-devtools/meson/meson/gi-target-dep.patch
new file mode 100644
index 00..25b30ca27a
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/gi-target-dep.patch
@@ -0,0 +1,41 @@
+When building gobject-introspection we want the *native* binaries (as they need
+to be executed) but *host* gobject-introspection libraries, as otherwise the
+native pkg-config can be used and the build will try to link native and host
+binaries together.
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton
+
+diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
+index f9660838e..2eefc3fc7 100644
+--- a/mesonbuild/modules/gnome.py
b/mesonbuild/modules/gnome.py
+@@ -84,8 +84,8 @@ class GnomeModule(ExtensionModule):
+
mlog.bold('https://github.com/mesonbuild/meson/issues/1387'),
+ once=True)
+
+-def _get_native_dep(self, state, depname, required=True):
+-kwargs = {'native': True, 'required': required}
++def _get_dep(self, state, depname, native=False, required=True):
++kwargs = {'native': native, 'required': required}
+ holder = self.interpreter.func_dependency(state.current_node,
[depname], kwargs)
+ return holder.held_object
+
+@@ -101,7 +101,7 @@ class GnomeModule(ExtensionModule):
+ return ExternalProgram.from_entry(name, prog)
+
+ # Check if pkgconfig has a variable
+-dep = self._get_native_dep(state, depname, required=False)
++dep = self._get_dep(state, depname, native=True, required=False)
+ if dep.found() and dep.type_name == 'pkgconfig':
+ value = dep.get_pkgconfig_variable(varname, {})
+ if value:
+@@ -481,7 +481,7 @@ class GnomeModule(ExtensionModule):
+
+ def _get_gir_dep(self, state):
+ if not self.gir_dep:
+-self.gir_dep = self._get_native_dep(state,
'gobject-introspection-1.0')
++self.gir_dep = self._get_dep(state, 'gobject-introspection-1.0')
+ self.giscanner = self._get_native_binary(state, 'g-ir-scanner',
'gobject-introspection-1.0', 'g_ir_scanner')
+ self.gicompiler = self._get_native_binary(state, 'g-ir-compiler',
'gobject-introspection-1.0', 'g_ir_compiler')
+ return self.gir_dep, self.giscanner, self.gicompiler
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149942):
https://lists.openembedded.org/g/openembedded-core/message/149942
Mute This Topic: https://lists.openembedded.org/mt/81608826/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 3/3] meson: use native-file instead of environment variables
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 +-
1 file changed, 24 insertions(+), 30 deletions(-)
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index a7644e70cb..bf9b02e06e 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -26,7 +26,8 @@ MESONOPTS = " --prefix ${prefix} \
--sysconfdir ${sysconfdir} \
--localstatedir ${localstatedir} \
--sharedstatedir ${sharedstatedir} \
- --wrap-mode nodownload"
+ --wrap-mode nodownload \
+ --native-file ${WORKDIR}/meson.native"
EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
@@ -102,12 +103,14 @@ cups-config = 'cups-config'
g-ir-scanner = '${STAGING_BINDIR}/g-ir-scanner-wrapper'
g-ir-compiler = '${STAGING_BINDIR}/g-ir-compiler-wrapper'
-[properties]
-needs_exe_wrapper = true
+[built-in options]
c_args = ${@meson_array('CFLAGS', d)}
c_link_args = ${@meson_array('LDFLAGS', d)}
cpp_args = ${@meson_array('CXXFLAGS', d)}
cpp_link_args = ${@meson_array('LDFLAGS', d)}
+
+[properties]
+needs_exe_wrapper = true
gtkdoc_exe_wrapper = '${B}/gtkdoc-qemuwrapper'
[host_machine]
@@ -121,9 +124,27 @@ system = '${@meson_operating_system('TARGET_OS', d)}'
cpu_family = '${@meson_cpu_family('TARGET_ARCH', d)}'
cpu = '${TARGET_ARCH}'
endian = '${@meson_endian('TARGET', d)}'
+EOF
+
+cat >${WORKDIR}/meson.native <
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149944):
https://lists.openembedded.org/g/openembedded-core/message/149944
Mute This Topic: https://lists.openembedded.org/mt/81608828/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
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
> > ; openembedded-core@lists.openembedded.org
> > Cc: bluelightn...@bluelightning.org; Khem Raj
> > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > recipe to allow bootstrapping
> >
> > 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: bluelightn...@bluelightning.org; Peter Kjellerstedt
> > > > ; Khem Raj
> > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > > > recipe to allow bootstrapping
> > > >
> > > > 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?
> > > > [build-deps]
> > > > >
> > > > >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226
> > > >
> > > > That failure was my fault when testing some fixes.
> > > >
> > > > I've sent out a patch which renames util-linux-uuid to util-linux-
> > libuuid
> > > > and sorts out the license issue Peter reported.
> > >
> > > I don't mind the recipe being renamed and cleaned up, but I would prefer
> > > to see my entire patch for the license parts being either integrated
> > before
> > > this or squashed into it, whichever you prefer. It does not make sense
> > to
> > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-linux,
> > > and setting the other LICENSE variables in util-linux.inc no longer
> > makes
> > > sense as they are only relevant for util-linux.
> >
> > I'm torn on that. Code with the other licenses is present, just not used
> > in the final output and I personally suspect that having one
> > LIC_FILES_CHKSUM
> > is going to be easier to maintain in the future rather than two separate
> > ones.
>
> I actually checked all the files that go into -dev and -src before suggesting
> this change, and all files are either marked as public domain or use a
> BSD-3-Clause license.
There is a difference between what ends up in ${S} and what ends up in the
binary packages. LICENSE clearly governs the latter. Its the scope of
LIC_FILES_CHECKSUM which there are differences of opinion on.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149941):
https://lists.openembedded.org/g/openembedded-core/message/149941
Mute This Topic: https://lists.openembedded.org/mt/81254724/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
> -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: [OE-core] [PATCH v11] util-linux: split uuid in separate > recipe to allow bootstrapping > > 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: bluelightn...@bluelightning.org; Peter Kjellerstedt > > > ; Khem Raj > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate > > > recipe to allow bootstrapping > > > > > > 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? > > > [build-deps] > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226 > > > > > > That failure was my fault when testing some fixes. > > > > > > I've sent out a patch which renames util-linux-uuid to util-linux- > libuuid > > > and sorts out the license issue Peter reported. > > > > I don't mind the recipe being renamed and cleaned up, but I would prefer > > to see my entire patch for the license parts being either integrated > before > > this or squashed into it, whichever you prefer. It does not make sense > to > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-linux, > > and setting the other LICENSE variables in util-linux.inc no longer > makes > > sense as they are only relevant for util-linux. > > I'm torn on that. Code with the other licenses is present, just not used > in the final output and I personally suspect that having one LIC_FILES_CHKSUM > is going to be easier to maintain in the future rather than two separate > ones. I actually checked all the files that go into -dev and -src before suggesting this change, and all files are either marked as public domain or use a BSD-3-Clause license. > Cheers, > > Richard //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149940): https://lists.openembedded.org/g/openembedded-core/message/149940 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] image,populate_sdk_base: move 'func' flag setting for sdk command vars
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 populate_sdk_base
directly, so move it to the latter.
[YOCTO #13998]
Signed-off-by: Christopher Larson
---
meta/classes/image.bbclass | 2 +-
meta/classes/populate_sdk_base.bbclass | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index b558653635..c36c7a9695 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -112,7 +112,7 @@ def rootfs_command_variables(d):
'IMAGE_PREPROCESS_COMMAND','RPM_PREPROCESS_COMMANDS','RPM_POSTPROCESS_COMMANDS','DEB_PREPROCESS_COMMANDS','DEB_POSTPROCESS_COMMANDS']
python () {
-variables = rootfs_command_variables(d) + sdk_command_variables(d)
+variables = rootfs_command_variables(d)
for var in variables:
if d.getVar(var, False):
d.setVarFlag(var, 'func', '1')
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index c8a7084d33..33ba3fc3c1 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -329,6 +329,13 @@ def sdk_variables(d):
do_populate_sdk[vardeps] += "${@sdk_variables(d)}"
+python () {
+variables = sdk_command_variables(d)
+for var in variables:
+if d.getVar(var, False):
+d.setVarFlag(var, 'func', '1')
+}
+
do_populate_sdk[file-checksums] += "${TOOLCHAIN_SHAR_REL_TMPL}:True \
${TOOLCHAIN_SHAR_EXT_TMPL}:True"
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149939):
https://lists.openembedded.org/g/openembedded-core/message/149939
Mute This Topic: https://lists.openembedded.org/mt/81606656/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
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 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 able to pass the MACHINE through the environment is a big win. We > could > > alter a config file in the shell script, but that would change a file > that > > we'd want under version control, and I really don't like it when builds > change > > files under version control. > > > > (The "40" machines is not exaggerated, I'm really involved in projects > that > > build for that many targets) > > > > Come to think of it, MACHINE is the one and only environment we ever > pass to > > bitbake. > > > > For release/test/production/debug/... etcetera I tend to use a different > > image, so you'd see: > > > > MACHINE=mach1 bitbake interesting-image interesting-image-dev > > you and mark are right, i was being a bit too draconian -- being > able to select MACHINE and DISTRO on the bitbake invocation line are > obvious benefits. > > just to refresh my memory, what is it that identifies the env vars > that are by default passed through without any need for extra > whitelisting? is that BB_ENV_EXTRAWHITE? i recall that contains > MACHINE and DISTRO already, so that might be all i care about. > > rday > > > > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149938): https://lists.openembedded.org/g/openembedded-core/message/149938 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
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: 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: [OE-core] [PATCH v11] util-linux: split uuid in separate > > > > recipe to allow bootstrapping > > > > > > > > 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? > > > > [build-deps] > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226 > > > > > > > > That failure was my fault when testing some fixes. > > > > > > > > I've sent out a patch which renames util-linux-uuid to > > > > util-linux-libuuid > > > > and sorts out the license issue Peter reported. > > > > > > I don't mind the recipe being renamed and cleaned up, but I would prefer > > > to see my entire patch for the license parts being either integrated > > > before > > > this or squashed into it, whichever you prefer. It does not make sense to > > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-linux, > > > and setting the other LICENSE variables in util-linux.inc no longer makes > > > sense as they are only relevant for util-linux. > > > > I'm torn on that. Code with the other licenses is present, just not used > > in the final output and I personally suspect that having one > > LIC_FILES_CHKSUM > > is going to be easier to maintain in the future rather than two separate > > ones. > > FWIW, in Debian the license definitions always cover the _sources_, not > the built binaries. IOW: even if you don't build and distribute a > subtool, the license metadata must cover it. I'd think this would be > even more important for Yocto since you exclusively distribute sources, > not binaries. ideally, it would be good to have both expressed distinctly since we also have tooling for end users to create manifests for whats strictly on target images. we perhaps need source license which is perhaps at recipe level and then target license which is at package level. > > -- > Kind regards, > Luca Boccassi > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149937): https://lists.openembedded.org/g/openembedded-core/message/149937 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
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 Bocassi ; > > > openembedded-core@lists.openembedded.org > > > Cc: bluelightn...@bluelightning.org; Peter Kjellerstedt > > > ; Khem Raj > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate > > > recipe to allow bootstrapping > > > > > > 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? > > > [build-deps] > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226 > > > > > > That failure was my fault when testing some fixes. > > > > > > I've sent out a patch which renames util-linux-uuid to util-linux-libuuid > > > and sorts out the license issue Peter reported. > > > > I don't mind the recipe being renamed and cleaned up, but I would prefer > > to see my entire patch for the license parts being either integrated before > > this or squashed into it, whichever you prefer. It does not make sense to > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-linux, > > and setting the other LICENSE variables in util-linux.inc no longer makes > > sense as they are only relevant for util-linux. > > I'm torn on that. Code with the other licenses is present, just not used > in the final output and I personally suspect that having one LIC_FILES_CHKSUM > is going to be easier to maintain in the future rather than two separate ones. FWIW, in Debian the license definitions always cover the _sources_, not the built binaries. IOW: even if you don't build and distribute a subtool, the license metadata must cover it. I'd think this would be even more important for Yocto since you exclusively distribute sources, not binaries. -- Kind regards, Luca Boccassi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149936): https://lists.openembedded.org/g/openembedded-core/message/149936 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH] bpftool: remove recipe from blacklist
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 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 1758430bc..e58bdd493 100644
> --- a/meta-oe/recipes-kernel/bpftool/bpftool.bb
> +++ b/meta-oe/recipes-kernel/bpftool/bpftool.bb
> @@ -32,4 +32,3 @@ python do_package_prepend() {
> }
>
> B = "${WORKDIR}/${BPN}-${PV}"
> -PNBLACKLIST[bpftool] ?= "Needs forward porting to kernel 5.2+"
> --
> 2.26.2.Cisco
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149935):
https://lists.openembedded.org/g/openembedded-core/message/149935
Mute This Topic: https://lists.openembedded.org/mt/81605266/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][PATCH] bpftool: remove recipe from blacklist
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 1758430bc..e58bdd493 100644
--- a/meta-oe/recipes-kernel/bpftool/bpftool.bb
+++ b/meta-oe/recipes-kernel/bpftool/bpftool.bb
@@ -32,4 +32,3 @@ python do_package_prepend() {
}
B = "${WORKDIR}/${BPN}-${PV}"
-PNBLACKLIST[bpftool] ?= "Needs forward porting to kernel 5.2+"
--
2.26.2.Cisco
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149934):
https://lists.openembedded.org/g/openembedded-core/message/149934
Mute This Topic: https://lists.openembedded.org/mt/81605266/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe-core][PATCH 1/2] valgrind: update 3.16.1 -> 3.17.0
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: openembedded-core@lists.openembedded.org
on behalf of Yi Fan Yu
Sent: Tuesday, March 23, 2021 22:50
To: openembedded-core@lists.openembedded.org
Subject: [oe-core][PATCH 1/2] valgrind: update 3.16.1 -> 3.17.0
Notable changes:
* libdir is now libexecdir
Added patches:
Add musl.supp: missing musl.supp in 3.17.0
Dropped backport patches:
* nlcontrolc: found in c79180a3afcf65902e578646c3b716cc749db406
* drd Fedora33: found in 15330adf7c2471fbaa6a0818db07078d81dbff97
Other dropped patches
* helgrind intercept: found in d2d54dbcc74244adfc0c80b40862edf2b82f53b9
* drd musl fix: found in d2d54dbcc74244adfc0c80b40862edf2b82f53b9
TESTING RESULTS:
qemux86-64:
FAIL: drd/tests/swapcontext
3.17.0 3.16.1
===
TOTAL: 736726
PASSED: 694688
FAILED: 1 0
SKIPPED: 41 38
Signed-off-by: Yi Fan Yu
---
.../valgrind/0001-Add-missing-musl.supp.patch | 72 +++
...gtest-hanging-on-newer-glibc-and-or-.patch | 200 --
.../valgrind/0001-drd-Port-to-Fedora-33.patch | 48 -
.../valgrind/valgrind/0001-drd-musl-fix.patch | 31 ---
...01-helgrind-Intercept-libc-functions.patch | 54 -
...ated-PowerPC-insns-aren-t-allowed-on.patch | 62 --
...eak_cmsg.stderr.exp-adjust-tmp-paths.patch | 2 +-
...ntext-APIs-are-not-available-on-musl.patch | 50 -
.../valgrind/valgrind/fixed-perl-path.patch | 20 +-
.../valgrind/valgrind/run-ptest | 3 +-
.../valgrind/valgrind/s390x_vec_op_t.patch| 24 ++-
...{valgrind_3.16.1.bb => valgrind_3.17.0.bb} | 20 +-
12 files changed, 160 insertions(+), 426 deletions(-)
create mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-drd-Port-to-Fedora-33.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-drd-musl-fix.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-helgrind-Intercept-libc-functions.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch
rename meta/recipes-devtools/valgrind/{valgrind_3.16.1.bb =>
valgrind_3.17.0.bb} (93%)
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
b/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
new file mode 100644
index 00..2a73f7e81f
--- /dev/null
+++ b/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
@@ -0,0 +1,72 @@
+From 61bc8664f93cd980831c9da4a3e8a385b089a0ab Mon Sep 17 00:00:00 2001
+From: Yi Fan Yu
+Date: Tue, 23 Mar 2021 09:32:22 -0700
+Subject: [PATCH] Add missing musl.supp
+
+3.17 did not ship musl.supp in the tarball.
+
+This is a workaround until next release.
+
+Upstream-Status: Backport [dde556d51f8226a6de564a00bf82536bb7042c54]
+
+Signed-off-by: Yi Fan Yu
+---
+ musl.supp | 46 ++
+ 1 file changed, 46 insertions(+)
+ create mode 100644 musl.supp
+
+diff --git a/musl.supp b/musl.supp
+new file mode 100644
+index 0..864172a24
+--- /dev/null
b/musl.supp
+@@ -0,0 +1,46 @@
++# Suppressions for musl libc
++# See: https://www.openwall.com/lists/musl/2017/06/15/4
++
++{
++ musl-dynlink-false-positive1
++ Memcheck:Leak
++ fun:calloc
++ fun:load_direct_deps
++ fun:load_deps
++ fun:load_deps
++ fun:__dls3
++ fun:__dls2b
++ fun:__dls2
++}
++
++{
++ musl-dynlink-false-positive2
++ Memcheck:Leak
++ fun:calloc
++ fun:load_direct_deps
++ fun:load_deps
++ fun:load_deps
++ fun:__dls3
++ fun:__dls2
++}
++
++{
++ musl-dynlink-false-positive3
++ Memcheck:Leak
++ fun:calloc
++ fun:load_library
++ fun:load_preload
++ fun:__dls3
++ fun:__dls2b
++ fun:__dls2
++}
++
++{
++ musl-dynlink-false-positive4
++ Memcheck:Leak
++ fun:calloc
++ fun:load_library
++ fun:load_preload
++ fun:__dls3
++ fun:__dls2
++}
+--
+2.17.1
+
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
b/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
deleted file mode 100644
index 98cbcd132c..00
---
a/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
+++ /dev/null
@@ -1,200 +0,0 @@
-From 83c24e31df6932a6d4fced179050c6d8d8c6f3b5 Mon Sep 17 00:00:00 2001
-From: Philippe Waroquiers
-Date: Sun, 7 Mar 2021 22:29:27 +0100
-Subject: [PATCH] Fix nlcontrolc.vgtest hanging on newer glibc and/or arm64
-
Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
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 >MACHINE=$machine bitbake image1 image2 image3 > done > > Being able to pass the MACHINE through the environment is a big win. We could > alter a config file in the shell script, but that would change a file that > we'd want under version control, and I really don't like it when builds change > files under version control. > > (The "40" machines is not exaggerated, I'm really involved in projects that > build for that many targets) > > Come to think of it, MACHINE is the one and only environment we ever pass to > bitbake. > > For release/test/production/debug/... etcetera I tend to use a different > image, so you'd see: > > MACHINE=mach1 bitbake interesting-image interesting-image-dev you and mark are right, i was being a bit too draconian -- being able to select MACHINE and DISTRO on the bitbake invocation line are obvious benefits. just to refresh my memory, what is it that identifies the env vars that are by default passed through without any need for extra whitelisting? is that BB_ENV_EXTRAWHITE? i recall that contains MACHINE and DISTRO already, so that might be all i care about. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149932): https://lists.openembedded.org/g/openembedded-core/message/149932 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
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 able to pass the MACHINE through the environment is a big win. We could alter a config file in the shell script, but that would change a file that we'd want under version control, and I really don't like it when builds change files under version control. (The "40" machines is not exaggerated, I'm really involved in projects that build for that many targets) Come to think of it, MACHINE is the one and only environment we ever pass to bitbake. For release/test/production/debug/... etcetera I tend to use a different image, so you'd see: MACHINE=mach1 bitbake interesting-image interesting-image-dev So "interesting-image" would be the product, while the "dev" version would apply debug tweaks that make the rootfs writeable and enable the serial console for login and things like that. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topic.nl Please consider the environment before printing this e-mail On 25-03-2021 15:08, Robert P. J. Day via lists.openembedded.org 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 info to the build, that info being used to specify things like a development versus manufacturing build, and so on. i suggested that i didn't think there was any really persuasive reasons to use environment variables this way, as there are more than enough configuration files to customize a build. i mentioned things like: * machine config files * distro config files * defining packagegroup files * defining image files and on and on and on. my point was that there are more than enough ways to support all the customization you might need, that taking advantage of shell environment variables strikes me as unnecessarily messy and, for that matter, dangerous if you forget so set the environment. thoughts? am i out of line in advising them to use what OE offers them, and not extract stuff from the environment? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149931): https://lists.openembedded.org/g/openembedded-core/message/149931 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
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: bluelightn...@bluelightning.org; Peter Kjellerstedt > > ; Khem Raj > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate > > recipe to allow bootstrapping > > > > 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? > > [build-deps] > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226 > > > > That failure was my fault when testing some fixes. > > > > I've sent out a patch which renames util-linux-uuid to util-linux-libuuid > > and sorts out the license issue Peter reported. > > I don't mind the recipe being renamed and cleaned up, but I would prefer > to see my entire patch for the license parts being either integrated before > this or squashed into it, whichever you prefer. It does not make sense to > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-linux, > and setting the other LICENSE variables in util-linux.inc no longer makes > sense as they are only relevant for util-linux. I'm torn on that. Code with the other licenses is present, just not used in the final output and I personally suspect that having one LIC_FILES_CHKSUM is going to be easier to maintain in the future rather than two separate ones. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149930): https://lists.openembedded.org/g/openembedded-core/message/149930 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
> -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: [OE-core] [PATCH v11] util-linux: split uuid in separate > recipe to allow bootstrapping > > 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? > [build-deps] > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226 > > That failure was my fault when testing some fixes. > > I've sent out a patch which renames util-linux-uuid to util-linux-libuuid > and sorts out the license issue Peter reported. I don't mind the recipe being renamed and cleaned up, but I would prefer to see my entire patch for the license parts being either integrated before this or squashed into it, whichever you prefer. It does not make sense to use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-linux, and setting the other LICENSE variables in util-linux.inc no longer makes sense as they are only relevant for util-linux. > I'm optimistic this fixes the various issues people have been having > and simplifies the recipe a bit as an added bonus. > > The patch has already tested cleanly on the autobuilder (the above warning > was from an earlier aborted build before I opted to rename the recipe). > > Khem: Thanks for the related meta-oe tweak, I think the rename whilst > slightly painful now is the best way forward overall. > > Cheers, > > Richard //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149929): https://lists.openembedded.org/g/openembedded-core/message/149929 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?
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 info to the build, that info being used > to specify things like a development versus manufacturing build, and > so on. > > i suggested that i didn't think there was any really persuasive > reasons to use environment variables this way, as there are more than > enough configuration files to customize a build. i mentioned things > like: > > * machine config files > * distro config files > * defining packagegroup files > * defining image files > > and on and on and on. > > my point was that there are more than enough ways to support all the > customization you might need, that taking advantage of shell > environment variables strikes me as unnecessarily messy and, for that > matter, dangerous if you forget so set the environment. > > thoughts? am i out of line in advising them to use what OE offers > them, and not extract stuff from the environment? I _always_ do builds like: MACHINE=zynqmp-generic DISTRO=petalinux bitbake core-image-minimal I don't want to have to update any configuration files to pass basic values into the system. This is also used heavily on my build systems so we can have a common configuration for all builds, but built across a wide breadth of components. I also occasionally use BB_ENV_EXTRAWHITE to add additional variables I might want to override. For instance, sometimes I want TMPDIR to go to a different location, instead of having to modify local.conf (and then remember to put it back the way it was) I can just add to the EXTRAWHITE, and call passing in TMPDIR. --Mark > rday > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149928): https://lists.openembedded.org/g/openembedded-core/message/149928 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] any *compelling* reasons to whitelist env vars for an OE build?
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 things like a development versus manufacturing build, and so on. i suggested that i didn't think there was any really persuasive reasons to use environment variables this way, as there are more than enough configuration files to customize a build. i mentioned things like: * machine config files * distro config files * defining packagegroup files * defining image files and on and on and on. my point was that there are more than enough ways to support all the customization you might need, that taking advantage of shell environment variables strikes me as unnecessarily messy and, for that matter, dangerous if you forget so set the environment. thoughts? am i out of line in advising them to use what OE offers them, and not extract stuff from the environment? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149927): https://lists.openembedded.org/g/openembedded-core/message/149927 Mute This Topic: https://lists.openembedded.org/mt/81603196/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] [RFC] ffmpeg: make LICENSE_FLAGS fine-grained
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 pull codecs
NONCOMMERCIAL_DEFAULT_PACKAGECONFIGS = " \
avdevice avfilter avformat swresample swscale postproc avresample \
alsa bzlib drm gpl lzma pic pthreads shared zlib \
${@bb.utils.contains('AVAILTUNES', 'mips32r2', 'mips32r2', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xv xcb', '', d)} \
"
NONCOMMERCIAL_NONDEFAULT_PACKAGECONFIGS = " \
altivec bzlib gsm jack openssl sdl2 \
"
PACKAGECONFIG ??= "avcodec theora \
${NONCOMMERCIAL_DEFAULT_PACKAGECONFIGS}"
I admit I'm not completely sure about every feature's status.
I tend to think that if ffmpeg relies on a lib providing an
implementation, and there
are patent-related risks, it should that lib setting a LICENSE_FLAG.
Eg. x264 and others
already sets the "commercial" flag, so I'm tempted to not add a
duplicate flag in
ffmpeg (in the same spirit as my patches against gst-libav and mpv).
Would it be
good enough ?
>
>
> Alex
>
> On Tue, 23 Mar 2021 at 17:38, Yann Dirson wrote:
>>
>> From: Yann Dirson
>>
>> The rationale here is that if the user can only whitelist "commercial"
>> to use any part of ffmpeg, even it the list of features is carefully
>> reviewed when switching the whitelisting on, there was nothing to
>> guard from inadvertently activating a new feature that would not have
>> been reviewed.
>>
>> This patch adds one LICENSE_FLAGS value for each feature, except for
>> those that bring no codec, trying to be on the same level of legal
>> safety - but then I may miss something.
>>
>> I tried to leave out of the safe NONCOMMERCIAL_PACKAGECONFIGS list
>> anything that brings a codec, notably libavcodec. I also did not look
>> at non-default features yet.
>>
>> There may still be a problem if any feature in ffmpeg gets activated
>> by default upstream and not registed as a PACKAGECONFIG feature. At
>> least any of those that depend on another lib would not be enabled,
>> that could be seen as a sufficient safeguard.
>> ---
>> meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb
>> b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb
>> index 08be38ca50..3a36c95151 100644
>> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb
>> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb
>> @@ -16,7 +16,17 @@ LICENSE_libavutil =
>> "${@bb.utils.contains('PACKAGECONFIG', 'gpl', 'GPLv2+', 'LGP
>> LICENSE_libpostproc = "GPLv2+"
>> LICENSE_libswresample = "${@bb.utils.contains('PACKAGECONFIG', 'gpl',
>> 'GPLv2+', 'LGPLv2.1+', d)}"
>> LICENSE_libswscale = "${@bb.utils.contains('PACKAGECONFIG', 'gpl',
>> 'GPLv2+', 'LGPLv2.1+', d)}"
>> -LICENSE_FLAGS = "commercial"
>> +
>> +# PACKAGECONFIG features that do not pull codecs
>> +NONCOMMERCIAL_PACKAGECONFIGS = " \
>> + alsa bzlib drm gpl lzma zlib xcb xv \
>> + avdevice avfilter avformat swresample swscale postproc avresample \
>> +"
>> +# An ffmpeg feature not in NONCOMMERCIAL_PACKAGECONFIGS should be
>> explicitly whitelisted.
>> +# See https://ffmpeg.org/legal.html
>> +LICENSE_FLAGS = "${@' '.join('commercial_' + cfg \
>> + for cfg in '${PACKAGECONFIG}'.split() \
>> + if cfg not in
>> '${NONCOMMERCIAL_PACKAGECONFIGS}'.split())}"
>>
>> LIC_FILES_CHKSUM =
>> "file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
>>
>> file://COPYING.GPLv3;md5=d32239bcb673463ab874e80d47fae504 \
>> --
>> 2.30.2
>>
>>
>>
>>
--
Yann Dirson
Blade / Shadow -- http://shadow.tech
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149926):
https://lists.openembedded.org/g/openembedded-core/message/149926
Mute This Topic: https://lists.openembedded.org/mt/81555357/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] rootfs.py: mask run-postinsts systemd service when unneeded
[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 passing. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149925): https://lists.openembedded.org/g/openembedded-core/message/149925 Mute This Topic: https://lists.openembedded.org/mt/81522036/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] rootfs.py: mask run-postinsts systemd service when unneeded
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): https://lists.openembedded.org/g/openembedded-core/message/149925 Mute This Topic: https://lists.openembedded.org/mt/81522036/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] rootfs.py: uninstall the run-postinsts package if not needed
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 service
as well which still ran on systems based on systemd even when
no post installations were found.
Rather than disabling/masking scripts for different initialization
managers we now simply remove/uninstall the run-postinsts package
when no post installations are found to be delayed till runtime.
This is also more aligned with the function (_uninstall_unneeded)
this functionality is triggered through.
Signed-off-by: Awais Belal
---
meta/lib/oe/rootfs.py | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 249c685dcf..5f81023040 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -250,13 +250,11 @@ class Rootfs(object, metaclass=ABCMeta):
def _uninstall_unneeded(self):
-# Remove unneeded init script symlinks
+# Remove the run-postinsts package if no delayed postinsts are found
delayed_postinsts = self._get_delayed_postinsts()
if delayed_postinsts is None:
-if
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${sysconfdir}/init.d/run-postinsts")):
-self._exec_shell_cmd(["update-rc.d", "-f", "-r",
- self.d.getVar('IMAGE_ROOTFS'),
- "run-postinsts", "remove"])
+if
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${sysconfdir}/init.d/run-postinsts"))
or
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${systemd_unitdir}/system/run-postinsts.service")):
+self.pm.remove(["run-postinsts"])
image_rorfs = bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs",
True, False, self.d)
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149924):
https://lists.openembedded.org/g/openembedded-core/message/149924
Mute This Topic: https://lists.openembedded.org/mt/81600237/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] openssh: Wait for local-fs before generating host keys
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 sshdgenkeys.service wait for /etc/fstab to be mounted and which should include alternative host keys paths. The requirement for /var and /run is left for backwards compatibility. Signed-off-by: Mattias Hansson --- meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service index fd81793d51..44831c9955 100644 --- a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service +++ b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service @@ -1,6 +1,8 @@ [Unit] Description=OpenSSH Key Generation +Requires=local-fs.target RequiresMountsFor=/var /run +After=local-fs.target [Service] ExecStart=@LIBEXECDIR@/sshd_check_keys -- 2.31.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149923): https://lists.openembedded.org/g/openembedded-core/message/149923 Mute This Topic: https://lists.openembedded.org/mt/81598424/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
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 util-linux-libuuid-dev, but it isn't a build dependency? > > [build-deps] > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226 > > That failure was my fault when testing some fixes. > > I've sent out a patch which renames util-linux-uuid to util-linux-libuuid > and sorts out the license issue Peter reported. > > I'm optimistic this fixes the various issues people have been having > and simplifies the recipe a bit as an added bonus. > > The patch has already tested cleanly on the autobuilder (the above warning > was from an earlier aborted build before I opted to rename the recipe). > > Khem: Thanks for the related meta-oe tweak, I think the rename whilst > slightly painful now is the best way forward overall. > > Cheers, > > Richard Looks good to me, thanks! -- Kind regards, Luca Boccassi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149922): https://lists.openembedded.org/g/openembedded-core/message/149922 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
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? > [build-deps] > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226 That failure was my fault when testing some fixes. I've sent out a patch which renames util-linux-uuid to util-linux-libuuid and sorts out the license issue Peter reported. I'm optimistic this fixes the various issues people have been having and simplifies the recipe a bit as an added bonus. The patch has already tested cleanly on the autobuilder (the above warning was from an earlier aborted build before I opted to rename the recipe). Khem: Thanks for the related meta-oe tweak, I think the rename whilst slightly painful now is the best way forward overall. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149921): https://lists.openembedded.org/g/openembedded-core/message/149921 Mute This Topic: https://lists.openembedded.org/mt/81254724/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] util-linux-libuuid: Simplify recipe and rename from util-linux-uuid
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 from bitbake.conf are used, avoiding
errors from situations where users have customised settings causing
failures.
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/maintainers.inc| 2 +-
...il-linux-uuid_2.36.2.bb => util-linux-libuuid_2.36.2.bb} | 6 +-
meta/recipes-core/util-linux/util-linux.inc | 1 -
meta/recipes-core/util-linux/util-linux_2.36.2.bb | 6 +++---
4 files changed, 5 insertions(+), 10 deletions(-)
rename meta/recipes-core/util-linux/{util-linux-uuid_2.36.2.bb =>
util-linux-libuuid_2.36.2.bb} (56%)
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index e1cdf40073c..62763318576 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -722,7 +722,7 @@ RECIPE_MAINTAINER_pn-update-rc.d = "Ross Burton
"
RECIPE_MAINTAINER_pn-usbinit = "Alexander Kanavin "
RECIPE_MAINTAINER_pn-usbutils = "Alexander Kanavin "
RECIPE_MAINTAINER_pn-util-linux = "Chen Qi "
-RECIPE_MAINTAINER_pn-util-linux-uuid = "Chen Qi "
+RECIPE_MAINTAINER_pn-util-linux-libuuid = "Chen Qi "
RECIPE_MAINTAINER_pn-util-macros = "Armin Kuster "
RECIPE_MAINTAINER_pn-v86d = "Alexander Kanavin "
RECIPE_MAINTAINER_pn-vala = "Alexander Kanavin "
diff --git a/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
b/meta/recipes-core/util-linux/util-linux-libuuid_2.36.2.bb
similarity index 56%
rename from meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
rename to meta/recipes-core/util-linux/util-linux-libuuid_2.36.2.bb
index 65e4d23b7e9..9612c491cd9 100644
--- a/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
+++ b/meta/recipes-core/util-linux/util-linux-libuuid_2.36.2.bb
@@ -7,11 +7,7 @@ inherit autotools gettext pkgconfig
S = "${WORKDIR}/util-linux-${PV}"
EXTRA_OECONF += "--disable-all-programs --enable-libuuid"
-PACKAGES = "util-linux-libuuid util-linux-libuuid-dev
util-linux-libuuid-staticdev util-linux-libuuid-dbg"
-FILES_util-linux-libuuid = "${libdir}/libuuid.so.*"
-FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${includedir}
${libdir}/pkgconfig"
-FILES_util-linux-libuuid-staticdev = "${libdir}/libuuid.a"
-FILES_util-linux-libuuid-dbg = "/usr/src ${libdir}/.debug"
+LICENSE = "BSD-3-Clause"
do_install_append() {
rm -rf ${D}${datadir} ${D}${bindir} ${D}${base_bindir} ${D}${sbindir}
${D}${base_sbindir} ${D}${exec_prefix}/sbin
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 4031c586c91..cbf6102ee0a 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -11,7 +11,6 @@ LICENSE_${PN}-libblkid = "LGPLv2.1+"
LICENSE_${PN}-libfdisk = "LGPLv2.1+"
LICENSE_${PN}-libmount = "LGPLv2.1+"
LICENSE_${PN}-libsmartcols = "LGPLv2.1+"
-LICENSE_${PN}-libuuid = "BSD-3-Clause"
LIC_FILES_CHKSUM =
"file://README.licensing;md5=0fd5c050c6187d2bf0a4492b7f4e33da \
file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
diff --git a/meta/recipes-core/util-linux/util-linux_2.36.2.bb
b/meta/recipes-core/util-linux/util-linux_2.36.2.bb
index 50a70cd4522..c79cf782d15 100644
--- a/meta/recipes-core/util-linux/util-linux_2.36.2.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.36.2.bb
@@ -2,7 +2,7 @@ require util-linux.inc
#gtk-doc is not enabled as it requires xmlto which requires util-linux
inherit autotools gettext manpages pkgconfig systemd update-alternatives
python3-dir bash-completion ptest
-DEPENDS = "libcap-ng ncurses virtual/crypt zlib util-linux-uuid"
+DEPENDS = "libcap-ng ncurses virtual/crypt zlib util-linux-libuuid"
PACKAGES =+ "${PN}-swaponoff"
PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pylibmount',
'${PN}-pylibmount', '', d)}"
@@ -49,7 +49,7 @@ python util_linux_binpackages () {
# we must execute before update-alternatives PACKAGE_PREPROCESS_FUNCS
PACKAGE_PREPROCESS_FUNCS =+ "util_linux_binpackages "
-# skip libuuid as it will be packaged by the util-linux-uuid recipe
+# skip libuuid as it will be packaged by the util-linux-libuuid recipe
python util_linux_libpackages() {
do_split_packages(d, root=d.getVar('UTIL_LINUX_LIBDIR'),
file_regex=r'^lib(?!uuid)(.*)\.so\..*$',
output_pattern='${PN}-lib%s',
@@ -201,7 +201,7 @@ do_install_append_class-native () {
rm -f ${D}${base_bindir}/kill
}
-# dm-verity support introduces a circular build dependency, so util-linux-uuid
is split out for target builds
+# dm-verity support introduces a circular build dependency, so
util-linux-libuuid is split out for target builds
# Need to build libuuid for uuidgen, but then delete
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
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
From: openembedded-core@lists.openembedded.org
on behalf of Luca Bocassi
Sent: Thursday, March 11, 2021 17:09
To: openembedded-core@lists.openembedded.org
Cc: richard.pur...@linuxfoundation.org; bluelightn...@bluelightning.org
Subject: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to
allow bootstrapping
From: Luca Boccassi
Recently util-linux gained an (optional) build dependency on libcryptsetup.
But libcryptsetup build-depends on util-linux for blkid (optional, can be
disabled)
and uuid (mandatory).
Split out util-linux-uuid in a different recipe to break the cycle.
https://github.com/karelzak/util-linux/pull/898
Signed-off-by: Luca Boccassi
---
v1: util-linux 2.35 is not out yet, but I'd like to get the preparatory work
underway as I'm not sure if this is the best approach or if there are
alternatives. Suggestions and comments very welcome. Thanks!
v2: changed packages names to reflect old ones (eg: libuuid1 ->
util-linux-libuuid)
and leave uuid build enable in main recipe to allow for uuidgen build to
happen,
as it does not have its own autoconf switch. Delete the library manualy from
the main recipe after build instead, and add dependency.
Might help to break loop python3 -> util-linux -> libselinux -> python3, as
it's
only libuuid that is needed, see
https://lists.yoctoproject.org/g/yocto/message/47570
v3: rebased and refactored to have a common util-linux.inc file
v4: added RDEPENDS on util-linux-libuuid on various packages to fix QA warnings
v5: remove RDEPENDS and instead have util-linux RDEPEND on util-linux-uuid.
Removed PACKAGES_remove and instead filter out libuuid via the package
generation
regex.
Rebased on util-linux 2.36.2.
v6: install libuuid.a in libuuid-dev
change rdepends on uuid to use binary package rather than source
add rdepends on uuid-dev to libuuid-dev
remove rprovides of libuuid-dev from uuid-dev
v7: do not use '_append' for RDEPENDS, as it is not supported by BBCLASSEXTEND,
use
simply '+='
v8: added missing libuuid-staticdev package
remove libx32/libuuid* too
v9: set RECIPE_MAINTAINER_pn-util-linux-uuid, same value as
RECIPE_MAINTAINER_pn-util-linux
v10: removed DEBIAN_NOAUTONAME
remove lib64/libuuid* too
v11: use ${D}${base_libdir}/libuuid* instead of manually specifying
/lib|/libx32|/lib64
meta/conf/distro/include/maintainers.inc | 1 +
.../util-linux/util-linux-uuid_2.36.2.bb | 20 +++
meta/recipes-core/util-linux/util-linux.inc | 41 +
.../util-linux/util-linux_2.36.2.bb | 57 +--
4 files changed, 77 insertions(+), 42 deletions(-)
create mode 100644 meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
create mode 100644 meta/recipes-core/util-linux/util-linux.inc
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 3d8e3d5de0..c6a97bc280 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -720,6 +720,7 @@ RECIPE_MAINTAINER_pn-update-rc.d = "Ross Burton
"
RECIPE_MAINTAINER_pn-usbinit = "Alexander Kanavin "
RECIPE_MAINTAINER_pn-usbutils = "Alexander Kanavin "
RECIPE_MAINTAINER_pn-util-linux = "Chen Qi "
+RECIPE_MAINTAINER_pn-util-linux-uuid = "Chen Qi "
RECIPE_MAINTAINER_pn-util-macros = "Armin Kuster "
RECIPE_MAINTAINER_pn-v86d = "Alexander Kanavin "
RECIPE_MAINTAINER_pn-vala = "Alexander Kanavin "
diff --git a/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
b/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
new file mode 100644
index 00..65e4d23b7e
--- /dev/null
+++ b/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
@@ -0,0 +1,20 @@
+# To allow util-linux to optionally build-depend on cryptsetup, libuuid is
+# split out of the main recipe, as it's needed by cryptsetup
+
+require util-linux.inc
+
+inherit autotools gettext pkgconfig
+
+S = "${WORKDIR}/util-linux-${PV}"
+EXTRA_OECONF += "--disable-all-programs --enable-libuuid"
+PACKAGES = "util-linux-libuuid util-linux-libuuid-dev
util-linux-libuuid-staticdev util-linux-libuuid-dbg"
+FILES_util-linux-libuuid = "${libdir}/libuuid.so.*"
+FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${includedir}
${libdir}/pkgconfig"
+FILES_util-linux-libuuid-staticdev = "${libdir}/libuuid.a"
+FILES_util-linux-libuuid-dbg = "/usr/src ${libdir}/.debug"
+
+do_install_append() {
+ rm -rf ${D}${datadir} ${D}${bindir} ${D}${base_bindir} ${D}${sbindir}
${D}${base_sbindir} ${D}${exec_prefix}/sbin
+}
+
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-core/util-linux/util-linux.inc
Re: [OE-core] [PATCH] libassuan: upgrade 2.5.4 -> 2.5.5
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], , :, [$2]) > - else > --LIBASSUAN_CFLAGS="" > --LIBASSUAN_LIBS="" > - ifelse([$3], , :, [$3]) > - fi > - AC_SUBST(LIBASSUAN_CFLAGS) > > How was the patch refreshed? This chunk should not have been removed, unless upstream has fixed the code, and even then needs to be separately explained. Please do use 'devtool upgrade'. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149918): https://lists.openembedded.org/g/openembedded-core/message/149918 Mute This Topic: https://lists.openembedded.org/mt/81590941/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
